Rechenvorschrift optimieren, da FF-Verbrauch enorm

[Ärger (Gast)]

Ich führe das Ergebnis einer FFT auf den Eingang zurück und möchte die 
Latzenz möglichst gering halten. Leider ist der FFT-Ausgang unskaliert 
und hat basierend auf der Länge und der Eingangsdatenbreite einen 28 Bit 
breiten Ausgang für R und I. Jetzt kommt's: Die von Xilinx angebotene 
Wurzel braucht unfassbare 50 Takte, um zum Ergebnis zu gelangen. Wie 
kann man das kürzen?

Mein Problem ist auch, dass das Ergebnis der Wurzel noch addiert werden 
muss, wodurch ich den Offset dann 50 Register lang mitschleppen muss. 
Das sind 50x32 FFs. Kann doch nicht sein, oder?

[Jürgen (Gast)]

Wieso verwendest du anstelle der FFs nicht einfach ein FIFO? Beim 
Systemstart einmal die 50 Takte Delay zwischen Ein- und Ausgang 
berücksichtigen und danach kannst du einfach permanent schreiben und 
lesen. Natürlich vorrausgesetzt du brauchst die Daten in der 
Zwischenzeit nicht.

[Ärger (Gast)]

Nee so einfach ist das nicht. Das Ganze ist eine komplexere Rechenkette 
und Offset wird jeweils neu gebildet, passend zu Rest.

Der Ast sieht ungefähr so aus:

Offset = Funktion von Daten
P = SQR (R*R + I*I) + (-Offset)

und wird permantent ausgeführt. Ausserdem wird ja direkt 
weitergerechnet.

[MJF (Gast)]

Hallo,

vielleicht hilft der CORDIC-Algorithmus weiter. Denn kann man voll 
"gestreamt" aufbauen. Beim Betrag ist die Konvergenz recht schnell.

Andere Idee ist, die Wurzel mit einem Shifter und einer Tabelle mit 
linearer Interpolation aufzubauen. Braucht auch wenig Pipeline-Stufen.

Gruss

Markus

[Ärger (Gast)]

Ach so, ich hatte es nicht erwähnt- ich verwende den Cordic. Kommt aus 
dem System-Generator. Ich weiss nicht, ob und wie ich den 
umparametrieren kann.

[MJF (Gast)]

Ärger schrieb:
> Ach so, ich hatte es nicht erwähnt- ich verwende den Cordic. Kommt
> aus
> dem System-Generator. Ich weiss nicht, ob und wie ich den
> umparametrieren kann.

Den Core habe ich noch nicht verwendet, deshalb kann auch da nicht 
weiterhelfen. Der CORDIC-Algorithmus ist nicht besonders schwierig, 
versuche ihn doch nachzubauen, es gibt bestimmt gute Literatur darüber. 
Mit weniger als 20 Iterationen bekommst Du schon sehr große 
Genauigkeiten.

Gruss

Markus

[Lattice User (Gast)]

Ärger schrieb:

> Mein Problem ist auch, dass das Ergebnis der Wurzel noch addiert werden
> muss, wodurch ich den Offset dann 50 Register lang mitschleppen muss.
> Das sind 50x32 FFs. Kann doch nicht sein, oder?

Das kann man als RAM based Shiftregister resourcenschonend realisieren.

[Duke Scarring (Gast)]

Ärger schrieb:
> Jetzt kommt's: Die von Xilinx angebotene
> Wurzel braucht unfassbare 50 Takte, um zum Ergebnis zu gelangen. Wie
> kann man das kürzen?
Cordic wurde ja schon angesprochen. Ansonsten ist zwei Takte pro Bit für 
eine Wurzelberechnung kein schlechter Wert (macht mein IP-Core auch).

> Mein Problem ist auch, dass das Ergebnis der Wurzel noch addiert werden
> muss, wodurch ich den Offset dann 50 Register lang mitschleppen muss.
> Das sind 50x32 FFs. Kann doch nicht sein, oder?
Wie oft kommt denn vorne ein neuer Wert rein? Mit jedem Takt?
Die Alternative mit dem FIFO bzw. RAM benötigt halt BRAMs. Was in Deinem 
Design wertvoller ist (BRAM, DSP48 oder FFs) kannst nur Du entscheiden.

Duke