Fixed Point genauigkeit für DFT und Windowing

[Holger F. (Gast)]

Wie bekomme ich heraus was übliche geforderte Genauigkeiten für die DFT 
im FPGA mittels Fixed point Berechnung ist. Es geht darum Sinussignale 
mit festern Frequenz zu sampeln und davon eine DFT zu berechnen. Davor 
findet noch eine Fensterung statt. Die Fensterung würde bei meinen 18x18 
Multiplizierern schon 36bits zurückgeben. Wenn ich nun damit 
weiterrechne kommt aus meinr DFT 71 bits heraus. Das kommt mir viel vor 
aber wo soll man abschneiden? Die Daten werden übrigens mit 14 bit ADCs 
aufgenommen.

[VHDL-Polizei (Gast)]

Suche im Forum erbringt:

Beitrag "Rauschleistung eines Netzwerks"

Beitrag "2s Complement nach fixed point"

Beitrag "Frage VHDL Division"

Beitrag "Integer Division mit Rest"

Beitrag "Fixed point DFT"

Dort ist das alles (Mul, Runden, Reste, Division) behandelt.

[J. S. (engineer)]

Holger F. schrieb:
> Wie bekomme ich heraus was übliche geforderte Genauigkeiten für die DFT
> im FPGA mittels Fixed point Berechnung ist.

Das hat eigentlich mit VHDL wenig zu tun sondern mit der Genauigkeit der 
Daten. Rauschen, das in die FFT eingeht, wird sich entsprechend der 
Auflösung abbilden. Im Extremfall fordert ein schmalbandiges Signal, das 
sich nur in wenigen Stellen abbildet, die Auflösung, die das Signal 
selbst mitbringt, um unverfälscht prozessiert zu werden. Im Normalfaöö 
verteilt sich das Spektrum auf alle Frequenzen.

Um sicher zu sein, braucht die FFT daher theoretisch 1-2 Bit mehr an 
Y-Auflösung, als das Eingangssignal. Die gleiche Rechnung gilt das 
Fenstern.

Theorie: 14 Bit ADC, 28 Bit MUL -> 18 Bit Ergebnis -> 20 Bit DFT.
Real: 12 Bit Signalqualität, 16 Bit Mul-Ergebnis, 16 Bit DFT.

[-gb- (Gast)]

Jürgen S. schrieb:
> Theorie: 14 Bit ADC, 28 Bit MUL -> 18 Bit Ergebnis -> 20 Bit DFT.
Woher kommt hier die 28Bit in der Multiplikation? Wo in der FFT sitzt 
die?

[J. S. (engineer)]

Die Betragsbildung bei der Berechnung der FFT-Werte erfordert jeweils 
Quadrierungen. Brutto betrachtet, kommt aus einem 14 Bit Vektor 
zwischenzeitlich immer ein 28er raus. Praktisch (und mit etwas genauem 
Hinschauen) sind es 26, wovon das Bit 1 immer Null ist. Wenn man das 
noch veränderliche Bit 0 absorbiert, hat man real 24 Bit, mit denen man 
weiterrechnen kann, ohne irgendetwas an Genauigkeit zu verlieren. Ab 
dann gilt die Betrachtung oben zum Rauschen, Fenstern und eben der 
physikalischen Genauigkeit.

[Detlef _. (detlef_a)]

Hi,

https://de.wikipedia.org/wiki/Satz_von_Parseval sagt aus, dass die 
Energie im Zeit- und Frequenzbereich gleich sind. Damit wird die 
Dynamikanforderung an die FFT datenabhängig: transformiert man eine 
einzelne Sinuswelle der Amplitude 1 in einem 1024er Fenster dann hat die 
FFT die maximale Amplitude von 512. Das ist der worst-case, für 
Breitband wird das besser. Die FFT von 1024 samples hat 9stages, in 
jedem 'gewinnst' Du im schlechtesten Fall ein Bit.

Für integer Rechnung sieht das also so aus: 1024er Fenster sind 10Bit 
plus die Bit des ADC, z.B.14 macht 24Bit. Dein Multiplizierer kann 18Bit 
für die Koeffizienten und 18Bit für die Daten. Die Daten muss Du also um 
6Bit abschneiden, dann bleiben von Deinem ADC noch 8 Bit übrig. Das will 
und tut man nicht.

Die Profis, z.B. DSL-Chips mit mehreren 10^9 multiply/add per sec., 
machen dynamische Skalierung. Die merken sich in jeder Stage der FFT das 
Maximum und skalieren ggf. runter.

Cheers
Detlef

[A. F. (chefdesigner)]

Detlef _. schrieb:
> transformiert man eine
> einzelne Sinuswelle der Amplitude 1 in einem 1024er Fenster dann hat die
> FFT die maximale Amplitude von 512.

"Fenster" heißt bei dir wohl "Anzahl der FFT-Punkte", nehme ich an. Das 
ist aber nur die Zeitachse. Was ist mit der Amplitudenachse? Die muss 
sicher auch mindestens bei 1024 sein, oder?

[Bernd G. (Gast)]

Holger F. schrieb:
> für die DFT im FPGA

falsches Unterforum?

Holger F. schrieb:
> Die Daten werden übrigens mit 14 bit ADCs aufgenommen.
Dann würde man zusehen, mindestens dies 14 Bits durch die Rechnung zu 
ziehen, würde ich sagen. Multiplikationen unterwegs passend abschneiden.