CIC Filter overflow bei Comb Verständnisproblem

[Uwe (rax)]

Hallo zusammen,
ich steh gerade echt auf dem Schlauch bei dem Versuch die CIC Filter 
richtig zu verstehen. Hab dazu "Von Hand" ein Dezimationsfilter in 
Matlab geschrieben. Das funktioniert auch prinzipiell solange, bis es zu 
einem Überlauf kommt. Die 3. Integrator Stufe springt von +(großer Wert) 
zu -(2^Bitbreite+Überlaufdifferenz), genau so wie er es soll. Nur bei 
den Comb Filter kommt es dann zum Problem, was meines erachtens auch 
logisch ist. Bei den Comb Stufen wird ja der aktuelle Wert mit dem 
letzten Wert subtrahiert und dabei kommt zum Zeitpunkt des Überlaufes 
eine Zahl heraus, die kleiner als meine Bitbreite ist.

Ich hab das Gefühl da stimmt was nicht :)
Anbei noch die Matlab Plots der jeweiligen Stufen. Ab Sample ~700 kommt 
es in der 3. Integrationsstufe zum ersten Überlauf. Da das Ganze mit R=8 
läuft, tritt der Fehler bei Sample ~80 in der 1. Comb Stufe auf.

[A. F. (chefdesigner)]

Soweit ich mich erinnere, müssen die Integrationsstufen so weit gefasst 
sein, dass sie nicht überlaufen. Es gibt aber einen Trick, bei dem das 
Differenzbilden unter bestimmten Randbedingungen auch dann funktioniert, 
weil der Unterlauf in binären Zahlen auf dieselbe Differenz hinaus 
läuft.

Mach mal den Integrator 3 groß genug und schaue, ob die Rechnung als 
solche stimmt und was bei der ersten Differenzbildung heraus kommt und 
bei der, wei welcher der Überlauf in der limitierten Version erfolgt. 
Eventuell sieht man da wie man es machen muss. Ich glaube, es kommt auf 
den größer-kleiner-Vergleich an, bei dem noch 2n-1 addiert werden 
müssen.

[Uwe (rax)]

Der Tipp war genau richtig, vielen Dank!
Meine Behandlung bei einem wrap around von -2^n ins positive ist falsch.
Ich war zu geizig für den Fixed Point Designer und hab das Ganze in 
int32 implementiert…

Beispiel mit n = 5 -> Wertebereich geht also von -16 bis +15:
Vom Wert 12 wird +6 addiert, das gibt -14.
-14 - 12 = -26, das Ganze muss jetzt mit 2^n addiert werden:
-26 + 32 = 6. Passt, so müsste es gehen.

Melde mich nochmal wenn es läuft.

So wie ich es übrigens verstanden habe ist EIN Überlauf bei den 
Integrationsstufen innerhalb von 2 downsampling Abtastungen erlaubt. Es 
geht ja darum, dass die Differenzinformation nicht verloren geht. Bei 2 
oder mehr Überläufen während 2 Abtastungen geht die Info flöten, also 
müssen die Integrationsstufen so breit sein, dass das nicht passiert.

[A. F. (chefdesigner)]

Uwe schrieb:
> Bei 2
> oder mehr Überläufen während 2 Abtastungen geht die Info flöten, also
> müssen die Integrationsstufen so breit sein, dass das nicht passiert.
Das klingt mir aber unsicher. Würde bedeuten, dass die 
Funktionssicherheit von dem Verhältnis der Abtastfrequenzen links und 
rechts vom Kammfilter abhinge. Sollte sich das (nicht) ausrechnen 
lassen?

1) 3-fach-Dezimierung um Faktor 64 -> 4*4*4 -> 2 Bit mehr beim 
Akumulieren -> 1 Bit mehr benötigt.
2) 2-fach-Dezimierung um Faktor 256 -> 16*16 -> 4 Bit mehr beim 
Akumulieren -> 3 Bit mehr benötigt.

Stimmt das?
Oder doch besser sicherheitshalber groß und breit genug bauen?

[Uwe (rax)]

Andreas F. schrieb:
> Würde bedeuten, dass die
> Funktionssicherheit von dem Verhältnis der Abtastfrequenzen links und
> rechts vom Kammfilter abhinge.

Jein, die Registerbitbreite ist abhängig von der Eingangsbitbreite + 
Stages * log2(R). Das heißt umso größer R ist, desto länger wird 
zwischen 2 Abtastungen aufintegriert, und umso breiter müssen die 
Register sein.
Was ich jetzt aber zusätzlich nicht verstehe ist, dass die Bitbreite von 
einer Integrationsstufe zur nächsten eigentlich immer mehr anwachsen 
müsste. In der Literatur und in irgendwelchen Tutorials findet man immer 
nur folgendes Bildchen: 
https://s3.amazonaws.com/embeddedrelated/user/14446/CIC_digital_filters_fig12.png
Hier sind alle Integrationsstufen 21 Bit breit. Wenn ich jetzt aber in 
der 2. Stufe schon an der oberen Grenze bin, dann kommt es bei der 3. 
Stufe logischerweise nach jedem Sample zum Überlauf...?

Das Überlauf bzw. Unterlauf Problem in den Comb Stufen hab ich jetzt 
tatsächlich hinbekommen. Der oben beschriebene Ansatz war korrekt.

[-gb- (Gast)]

Uwe schrieb:
> dass die Bitbreite von einer Integrationsstufe zur nächsten
> eigentlich immer mehr anwachsen müsste.
Ja sicher, dem ist so. Mehr noch, es kommt irgendwann automatisch zu 
einem Überlauf. Der ist nur so spät, dass er bei der Differenzbildung 
nicht mehr relevant ist, weil pro Dezimationsstufe immer nur ein 
Underrun / Overrun auftreten kann, der kompensiert wird.

Nimm ein Beispiel:

Ein Sinus ab 0 Grad liefert erst nur Positive, dann gleich viele 
negative Anteile. Das Integral daüber ist immer Positiv, bildet einen 
Hügel und kommt wieder auf 0. Das 2. Integral wächst stufenförmig an. 
Das dritte wächst linear beschleunigt über alle Grenzen.

[J. S. (engineer)]

Uwe schrieb:
> Hier sind alle Integrationsstufen 21 Bit breit. Wenn ich jetzt aber in
> der 2. Stufe schon an der oberen Grenze bin, dann kommt es bei der 3.
> Stufe logischerweise nach jedem Sample zum Überlauf...?
Das darf nicht passieren. Nur der letzte darf überlaufen, oder man 
behandelt den Überlauf. Das gilt auch für die anderen genannten Fälle 
des Unterlaufs, oder dann wenn man nicht einen binären Faktor nutzt. 
Dann aber steigt sofort der Aufwand.