FIFO und FFT bei hoher Abtastrate

Hallo,
seit kurzen beschäftige ich mich mit FPGAs unter Labview. Es handelt sich um eine NI PXIe-7965R mit einem ADC Adapter NI 5761R. Dem Manual nach sollen bis zu 250MS/s möglich sein.
In dem Programm wird ein Kanal mit 40MHz abgetastet und diese Daten über einen FIFO zur Verarbeitung an eine FFT übergeben.
Nun zu meiner Frage, ist es möglich gleichzeit in einen FIFO zu schreiben und aus ihm zu lesen? Und bis zu welchen Abtastraten könne FIFOS verwendet werden? In der Hilfe habe ich gelesen, dass Blockmemory FIFO eine Verzögerung von bis zu 6 Takten hat.
Desweiteren ist mir die Latenzzeit der FFT nicht vollständig klar. Wenn ich die FFT in einer SingleTickLoop betreibe, dann muss ich eine gewiise Anzahl an Takten warten, biss ich ein Ergebnis erhalte. Doch was passiert in dieser Zeit? Nimmt die FFT in dieser Zeit weiter Werte auf? Und müssen alle Werte eines Frames am stück ausgelesen werden, ohne dass der Eingang Input Valid der FFT auf False geht?
Fragen über fragen, ich hoffe ihr könnt mich ein wenig erleuchten.

Danke schonmal im Voraus.

Das VI, um das es geht:
  ProcDataMinimal_3_FPGA.vi (Größe: 161,54 KB / Downloads: 367)

Anzeige

Für einen FPGA-Anfänger ist das ein ziemlich harter Brocken.

Ich würde Dir empfehlen, dass zunächst in kleinere Happen zu zerteilen:
- FPGA-Grundlagen: was ist bei der Programmierung auf dem FPGA anders als auf Host?
- FPGA-DAQ: Was ist der Unterschied zw. der reinen Abtastung des (digitalen) Signals und dem erfassten Wert, für die Speicherung/Verarbeitung? Welchen Messdatenstrom kann ich handlen?
- FIFO-Grundlagen: Was gibt es für FIFOs? Welche brauche ich?
- FPGA-FFT: Was macht die FFT auf FPGA? Was bedeuten die Ergebnisse? Wohin will ich mit den Ergebnissen?

Wenn du zu den einzelnen Punkten Beispiele gesehen, probiert und verstanden hast, dann kann man versuchen eine Kombination anzugehen.
Wenn du weitere Hilfestellung brauchst, dann beschreibe einfach das konkrete Problem, an dem du festsitzt.

Gruß

Erstmal Danke für deine Antwort.
Ich bin der Meinung, die FPGA Grundlagen verstanden zu haben und die damit einhergehenden Unterschiede zwischen FPGA und Host Programmierung.
Bei der Datenerfassung mit FPGA gibt es doch eigentlich nur 1 Möglichkeit zum Erfassen: Über einen Eigenschaftsknoten des FPGAs den gewünschten Eingang abfragen. Die Datenübertragung zum Host ist über Interface Komponenten (Variablen -> nicht Echtzeit, Datenverlust) oder Pufferspeicher (FIFOs -> Echtzeit, kein Datenverlust) möglich.
Damit kommen wir zu den Puffern. Habe noch etwas recherchiert und herausgefunden, dass zum Übertragen von Daten zwischen 2 Schleifen mit unterschiedlichem Zyklus nur BlockMemory in Frage kommt (wie bereits von mir genutzt). Die Einstellung beim FIFO habe ich (mittlerweile) alle verstanden, bis auf 'ControlLogic'. Das ist mir nicht ganz klar, aber mit der Auswahl 'Target Optimal' fährt man nach der Hilfe scheinbar ganz gut, da sie den 'besten' Modus auswählt. Die einzige Unklarheit herrscht über das Verhalten beim gleichzeitigen Lese- und Schreibzugriff (nicht auf das selbe Element).
Die FFT macht mir irgendwie immer noch Probleme. So ganz verstehe ich die Arbeitsweise in einer SCTL (Single Cycle Timed Loop, 'Ein Tick Schleife') noch nicht ganz. Könnte mir das jemand näher erläutern? Also ich möchte nicht den Algorithmus der FFT verstehen, ich denke das ist auch nicht unbedingt nötig, sondern eher wie die Daten am Eingang beschaffen sein müssen, damit am Ende etwas korrektes raus kommt.

Nochmal zusammengefasst sind meine momentanen Probleme:
Ist gleichzeitiges Lesen und Schreiben in einem Blockmemory-FIFO möglich, ohne dabei Daten zu verlieren?
Wie arbeitet die FFT korrekt in einer SCTL?

Nach einigen Wochen intensiver Arbeit bin ich nun der Lösung ein ganzes Stück näher gekommen.
Um die auftretende Latenz (ich nenne das jetzt einfach mal so, in Ermangelung eines besseren Begriffs) der FIFOs zu umgehen nutze ich nun mehrere FIFOs, die in einer Festen Reihenfolge benutzt werden. Das klappt soweit ganz gut und ich konnte damit die erreichbare Abtastrate erhöhen. Das einzige Problem, was ich habe ist, dass ich nicht weiß, wie ich das Schreiben und Lesen in der Art synchronisieren kann, dass die Daten auch in der richtigen Reihenfolge ausgelesen werden. Derzeit scheint das nämlich nicht zu stimmen, da die Ausgabe des Spektrums bei zwei Puffern auch zwei Peaks zeigt, obwohl nur einer vorhanden sein sollte. Interessanterweise ist ein Peak immer korrekt und der Andere ist am halben Spektrum gespiegelt.
Nun ja, das bringt mich wieder zur FFT und ihrer Funktionsweise, da ich glaube, dass das irgendwie damit zusammenhängt.
Ich betreibe die FFT in einer SCTL mit einem Cycle pro Sample und 512 Elementen im Forward modus. Eine Latenz von ca. 1600 Zyklen wird mir damit angezeigt.
Wenn die FFT 1 Zyklus pro Sample benötigt, heißt das ich gebe ihr 512 mal pro Zyklus einen Datenwert und erhalte nach 1600 Zyklen das Ergebnis?
Oder Funktioniert das irgendwie anders, bin da gerade irgendwie überfordert und die Hilfe is zwar nicht schlecht aber aus ihr werde ich in dieser Hinsicht auch nicht so recht schlau.

Wäre toll, wenn da jemand etwas Licht ins dunkle bringen könnte.

Hallo,

finde ich super dass du soviel Eigenleistung vorschiebst und nicht einfach darauf wartest alles vorgekaut zu bekommen!
Mittlerweile hat man auch das Gefühl, du weißt wovon du schreibst bei FPGA.

Nun konkret: Ich arbeite zwar viel mit FPGA, aber überhaupt nicht mit der FFT-Funktion. Kannst du mal das VI hochladen?
Ich habe noch nicht ganz verstanden wie deine Datenübertragung läuft... da würde das VI helfen.

Die SCTL macht genau das: Ein Schleifendurchlauf wird in einem Takt abgearbeitet. Die Länge des Taktes hängt von deiner Clockrate ab. bspw. 40Mhz -> 25ns Taktzeit. Damit erklären sich auch einige Kompilierfehler: Ist der "kritische" logische Pfad (streng genommen dessen Signallänge auf dem FPGA) zu lang, würde das Signal am Ende der Schleife zu spät ankommen, also länger als ein Takt brauchen. Das ist per Definition verboten, also schlägt in so einem Fall die Kompilierung fehl. Dann muss man entweder die Frequenz verringern, oder den "kritischen" logischen Pfad verkürzen durch einfach weniger Logik hintereinander; vllt Pipelining oder Codeoptimierung.
Aber warum nun die SCTL überhaupt benutzen?
Nun: Bei der SCTL wird ein nicht zu unterschätzender Teil der (Logik-)Ressourcen eingespart, da man (der Compiler) die sog. "Enable-Chain" weglassen kann. Das heißt, es ist von vornherein klar, dass all Logikbausteine in der Loop in einem Takt drankommen; es muss nicht mehr auf den "richtigen" Takt gewartet werden. Das hat wie gesagt zur Folge, dass man weniger "Platz" verbraucht und u.U. sogar schneller takten kann als ohne SCTL.

War das hilfreich?


Gruß

Hallo,
erstmal sry für die lange Wartezeit. Inzwischen hat sich einiges geklärt und das möchte ich mal fix hier mit Präsentieren.

FFT
Die FFT arbeitet in einer SCTL mit 1 Cycle/Sample. Dabei nimmt die FFT also pro Zyklus genau einen Wert entgegen und zwar immer. Nach der Latenzzeit (waren glaub ich 1600 Zyklen) kommt dann das erste Ergebnis hinten raus. Und dann auch pro Zyklus ein weiteres Sample. Dass heißt für eine 512 Elemente FFT braucht man
Latenzzeit + ( Sample * Zyklen/Sample )
Zyklen, um hinten ein komplettes Spektrum zu erhalten. Nagut, besser gesagt den Real und Imaginärteil des Spektrums. Verrechnen darf man das dan Selbst. (z.B. mit dem High Throughput Multiply)

FIFO
Ich hatte ja immer über die hohen Latenzen gejammert, die bei Target scoped FIFOs immer auftraten. Nun im Endeffekt haben sich diese nicht aufgelöst. Sondern ich habe einfach die Speichzerimplementierung gewechselt. Von Blockmemory auf Look-Up Table. Da gibts keine Latenzen und alles flutscht nur so. Über die Belegung auf dem FPGA habe ich mir zwar sorgen gemacht, doch mit der Optimierung, die der Compiler da macht passt am Ende doch alles, trotz 2Kanälen mit je 4048 Elemente FFT, Multiplizierer mit 5-Fach-Pipeline, und vielen, vielen Puffern zwischendurch. So ca. 4000 Elemente 16bit, 100 32bit und 50 64bit.

Schlussendlich ist es mir jetzt möglich ein Signal kontinuierlich mit einer FFT zu verarbeiten und das Spektrum auszuwerten bei bis zu 40 MHz.

PS: die Compilezeiten steigen bei großen Projekten rapide an. Gegen Ende hatte ich über 3 Stunden für ein Bitfile gebraucht.