Hey Leute, ich habe einen einfachen CIC filter: Stages/Ordnung (N) = 1 Rate Faktor (R) = 2048 Differential Delay = 1 Input Bitbreite = 24 Output Bitbreite = 24 (so wäre mein Wunsch) Es gibt die von Hogenauer vorgeschlagene "prune" Technik, bei der man eine bestimmte Anzahl von LSBs nach jedem Integrator/Comb "absägt". Diese Technik ist auch hier nochmal beschrieben: http://www.dsprelated.com/showcode/269.php Mein Problem ist, dass der dort angezeigte Matlab Code mit N=1 nicht funktioniert und ich selbst nicht in der Lage bin den Code schnell so umzubauen, dass auch N=1 geht. Meine Frage: Wieviel Bits kann ich nach meinem ersten Integrator und wieviel Bits nach dem Comb "abschneiden" (=truncate), wenn ich die "prune-Technik" nutzen möchte? Gruß Stefan
Ich bin mir nicht wirklich sicher, ob Hogenauers CIC überhaupt ein wirklich guter Dezimator ist. Selbst seine Fachkollegen hatten damals heftige Bedenken - vor allem wegen der Überläufe in den Akkumulatoren im Eingang. Ich nehme ganz stark an, daß das Ganze nur GENAU DANN überhaupt funktioniert, wenn die jeweiligen Bitbreiten in jeder verdammten Stufe so ausgetüftelt gewählt sind, daß die stattfindenden Überläufe sich irgendwie herausheben. Und jetzt fragst du, auf wieviel Bits du jeweils kürzen kannst, ohne daß du elende Artefakte damit erzeugst. Ich hatte dieses Artefakt-Problem vor einiger Zeit mit einem Mobiltelefon (Glofiish), wo die Programmierer daneben gegriffen hatten und deshalb die Verständigungsqualität unter aller Sau war. Wenn du mal den CIC-Generator bei den IP's von Xilinx benutzt hast, dann hast du dort feststellen müssen, daß die Bitanzahl schon bei mittleren Dezimationsgraden rapide in die Höhe schnellt. So von 14 Bit mal locker auf 72 Bit oder mehr. Das schluckt ne Menge an Logik, wenn man's per FPGA machen will. Sicherlich ist dreiviertel davon letztlich Hausnummer und sollte weggeschnitten werden. Aber wo, ohne daß man sich das Ergebnis versaut? Mal ne ganz grundsätzliche Frage: Warum überhaupt CIC? Das Dezimieren geht duch auch anders, mit nem laufenden Mittelwert - und der scheint mir sparsamer im Ressourcenverbrauch zu sein als CIC. Also schreib mal. W.S.
Ich hatte vor einiger Zeit auch mal mit CIC Filtern experimentiert. > Selbst seine Fachkollegen hatten damals heftige Bedenken - vor allem wegen > der Überläufe in den Akkumulatoren im Eingang. Das ist kein Problem. Es gibt da allerdings eine Formel (finde ich jetzt aber nicht), die angibt, wie viele Bits man mindestens braucht. Bei höherer Anzahl an Verzögerungsstufen und Stages war ich bei meiner Simulation mit 32 Bit schnell am Ende und musste auf 64 Bit Arithmetik ausweichen. Die Möglichkeit LSB's einzusparen ist bei Hardware möglicherweise interessant, aber nicht bei PC Anwendungen, weshalb ich mich nicht näher damit befasst hatte. Ich habe mich von CIC Filtern abgewendet, wegen des Frequenzgangs. Es wird oft empfohlen zur Korrektur ein FIR Filter nachzuschalten. Das halte ich für zu aufwändig, siehe unten. > Das Dezimieren geht duch auch anders, mit nem laufenden Mittelwert... Ja, das geht auch anders, aber ein gleitender Mittelwert scheint mir dafür aber zu aufwändig. Man kann auch dafür ein FIR Filter nehmen, das zwar alle nötigen Verzögerungsstufen hat, wobei aber nur jeder 1/N te Wert tatsächlich berechnet und weitergegeben wird. 1/N ist dabei das Dezimationsverhältnis.
Manfred M. schrieb: > Die Möglichkeit LSB's einzusparen ist bei Hardware möglicherweise > interessant, aber nicht bei PC Anwendungen, weshalb ich mich nicht näher > damit befasst hatte. > > Ich habe mich von CIC Filtern abgewendet, wegen des Frequenzgangs. Es > wird oft empfohlen zur Korrektur ein FIR Filter nachzuschalten. Das > halte ich für zu aufwändig, siehe unten. > >> Das Dezimieren geht duch auch anders, mit nem laufenden Mittelwert... > > Ja, das geht auch anders, aber ein gleitender Mittelwert scheint mir > dafür aber zu aufwändig. Man kann auch dafür ein FIR Filter nehmen, das > zwar alle nötigen Verzögerungsstufen hat, wobei aber nur jeder 1/N te > Wert tatsächlich berechnet und weitergegeben wird. 1/N ist dabei das > Dezimationsverhältnis. Man spart keine LSBs sondern MSBs. Es gibt zwar Wrap-Around, das macht aber nichts, so lange die Modulo-Arithmetik funktioniert.Es gibt noch ein paar Längen-Constraints.In Floating point würde das nicht funktionieren wenn man nicht das Modulo-Verhalten explizit hinprogrammiert. Im Zweier-Komplement ergibt sich das von alleine. Ein Integrator, dessen Eingang nicht durchschnittlich GENAU 0 ist, würde früher oder später auf jeden Fall überlaufen, auch bei 100 Bit oder noch mehr. Mit keinem Filter kann man mehr Bandbreite * dB Unterdrückung bei gegebenen Transistor & Power-Budget erzielen als mit einem CIC. Das bisschen Frequenzgangkorrektur mit FIR fällt da überhaupt nicht ins Gewicht. Es hat schon seinen Grund, warum CICs jetzt überall vorkommen. Wenn man nur ein FIR benutzen will, kostet jedes Tap einen Multiplizierer und nicht bloß Addierer wie beim CIC. Die Delayline-Stufen kosten im FPGA so viel wie ein Adder. (JaJa, SRL16, jetzt nicht gscheidhaferln.) Rick Lyons und Ray Andraka haben das oft genug beschrieben. Gruß, Gerhard
Angehängte Dateien:
-
CIC_03.png
24 KB
> Man spart keine LSBs sondern MSBs. Ne ne, das ist schon richtig. Warum das jetzt genau so ist, kann ich allerdings auch nicht erklären. Mr. R. Lyons schreibt dazu: > The specific effects of this LSB removal are, however, a complicated > issue; you can learn more about the issue by reading Hogenauer's paper. Ich stelle mir das so vor, das die LSBs durch das Kammfilter an Einfluss verlieren. In http://www.embedded.com/design/configurable-systems/4006446/Understanding-cascaded-integrator-comb-filters schreibt er auch: > There is some small flexibility in discarding some of the least > significant bits (LSBs) within the stages of a CIC filter, at the > expense of added noise at the filter's output. > In Floating point würde das nicht funktionieren Das kann ich bestätigen. > Mit keinem Filter kann man mehr Bandbreite * dB Unterdrückung bei > gegebenen Transistor & Power-Budget erzielen als mit einem CIC. Ich denke das hängt auch irgendwie von Dezimationsverhältnis ab. Ich wollte für einen Morsedecoder von 44.1kHz auf 8kHz dezimieren. Ein mögliches Filter hätte dann etwa so ausgesehen wie im Anhang gezeigt. Eine akzeptable Dämpfung im Bereich 3-4kHz bekomme ich nur bei total verbogenem Frequenzgang. Aber es ist natürlich ein Unterschied, ob man mit einem PC arbeitet oder direkt mit Hardware.
>Ich wollte für einen Morsedecoder von 44.1kHz auf 8kHz dezimieren. Ein > mögliches Filter hätte dann etwa so ausgesehen wie im Anhang gezeigt. > Eine akzeptable Dämpfung im Bereich 3-4kHz bekomme ich nur bei total > verbogenem Frequenzgang. Dafür ist CIC echt nicht geeignet. Eher, wenn man bei 44 Mega-Hz einen Kanal von ein paar KHz herausziehen will. Bei 44->8 ist man mit 2 Halbbandfiltern besser bedient. Das Bitwachstum bei CICs ist in Fredric J Harris, Prentice Hall, "Multirate Signal Processing for Communication Systems" gut & erschöpfend beschrieben. Gruß, Gerhard
Hey Leute, war ne Zeit lang nicht da, aber die Thematik "Pruning" hat sich für mich erledigt, da ich variable Dezimierungsfaktoren haben will. Da ich mir trotzdem ein paar Bit sparen will, shifte ich am Ausgang meines CICs einfach mein Signal um log2(Gain) Bits. Da ich immer 2er Potenzen bei den Faktoren nehme, geht das ohne größere Probleme. Mit einem kleinen Zusatzaufwand kann man ja das Ergebnis nach dem Shift noch runden und die LSBs abschneiden. Funktioniert bei mir gut. Der passband droop ist mir auch egal, da ich nur mein DC Signal brauche. Grüße Stefan
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.