Forum: FPGA, VHDL & Co. 8192-FFT aufteilen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Maximilian L. (Firma: Vector Informatik GmbH) (maxlau93)


Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich bräuchte eure Hilfe für ein Projekt. Ich muss ein spezielles Signal, 
welches zwischen 2 und 30 MHz liegt, sampeln und damit die FFT 
durchführen. Ich möchte die FFT auf einem FPGA Evaluation Board 
ausführen. Ich muss dabei bestimmte Carrier-Frequenzen (9KHz) abtasten 
und auswerten. Mein ADC sampelt mit 13 Bit (8192 Samples) und hat eine 
Auflösung von 14 Bit und eine fS von ca. 75 MHz. Ich möchte die FFT ca. 
100x durchführen (da eine Messzeit von 10ms vorgegeben ist) und die 
Daten in einem externen Speicher ablegen. Mein Problem ist folgendes: 
FPGA Evaluation Boards, die in meiner Preisklasse liegen (300-500€), 
haben nicht genug Resourcen (block RAM), um die 8192-FFT mit einem FFT 
IP Core (Xilinx) durchzuführen. Mein Gedanke war nun die FFT einfach 
aufzuteilen, sprich statt einmal eine 8192-FFT, 8x eine 1024-FFT. Das 
würde Resourcen schonen und wäre von einem nicht allzu teuren FPGA Eval 
Board möglich.
Ist so eine Aufteilung bei konstantem Signal eigentlich umsetzbar?
Muss ich hierbei nur die richtige Fensterung und damit die richtige 
Bandbreite jeweils zum Abtasten auswählen?
Noch eine kleine Frage zum ADC: Wie binde ich diesen am besten für meine 
Zwecke an den FPGA an? FMC-connector?

Ich würde mich sehr freuen, wenn Ihr mir helfen könntet.
Grüße Max

von liggi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Max,

bei mir gibt der IP-Generator von Xilinx ein Bedarf von ca. 20 BRAMs 
aus. Das sollte also problemlos in einen XC7S25 reinpassen.

Was meinst du mit konstantem Signal? Also rein DC oder meinst du ein 
periodisches Signal?

Viele Grüße,

liggi

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Maximilian L. schrieb:
> Ich möchte die FFT ca. 100x durchführen (da eine Messzeit von 10ms
> vorgegeben ist)
Ich kann diesen Gedankengang nicht nachvollziehen...

> Mein ADC sampelt mit 13 Bit (8192 Samples) und hat eine Auflösung von
> 14 Bit und eine fS von ca. 75 MHz.
Auch diesen nicht...

> Noch eine kleine Frage zum ADC: Wie binde ich diesen am besten für meine
> Zwecke an den FPGA an?
Am besten so, dass eine zuverlässige Datenübertragung mit der nötigen 
Datenrate möglich ist. Welcher ADC ist das denn?

Insgesamt vermischst du in deinen Fragen verschiedenste Designebenen: 
von der Struktur über das Verfahren und dem Ablauf bis hin zur Physik.

Maximilian L. schrieb:
> Ich muss dabei bestimmte Carrier-Frequenzen (9KHz) abtasten und
> auswerten.
Und warum willst du da mit einer 8k FFT herummachen? Welche 
Informationen willst du aus dem Spektrum entnehmen?
Wenn du das Vorhandensein einer bestimmten voraus bekannten Frequenz 
(9kHz) erkennen willst, dann wäre eine DFT nach H. Goertzel deutlich 
ressourcensparender:
https://de.wikipedia.org/wiki/Goertzel-Algorithmus

: Bearbeitet durch Moderator
von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du hast eine Samplerate von 75 MHz und willst eine 8k-FFT machen. Damit 
kommst Du auf Deine Bin-Breite von 9,1 kHz. Wenn Du kontinuierlich eine 
FFT machen willst, hast Du für eine FFT 8192 Samples Zeit. Das sind 109 
µs.

Wenn Deine FFT langsamer ist, hast Du zwei Möglichkeiten:
1. alle Daten zwischenspeichern und peu á peu abarbeiten oder
2. mehrere FFT parallel implementieren


Maximilian L. schrieb:
> Noch eine kleine Frage zum ADC: Wie binde ich diesen am besten für meine
> Zwecke an den FPGA an? FMC-connector?
Das hängt von Deinem ADC ab.

Duke

von Weltbester FPGA-Pongo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Maximilian L. schrieb:
> um die 8192-FFT mit einem FFT
> IP Core (Xilinx) durchzuführen. Mein Gedanke war nun die FFT einfach
> aufzuteilen, sprich statt einmal eine 8192-FFT, 8x eine 1024-FFT.
Dann müsste die in Achteln geshifted werden, mit overlapped 
Verarbeitung, moving Window, etc und damit dürftest Du überfordert sein, 
nehme ich an.

liggi schrieb:
> bei mir gibt der IP-Generator von Xilinx ein Bedarf von ca. 20 BRAMs
> aus. Das sollte also problemlos in einen XC7S25 reinpassen.
Das sehe ich ähnlich, eine 8192 habe ich schon mit einem S3 vor 15 
Jahren gemacht.

Der TE hat ein anderes Problem: Er kommt aus der SW-Ecke und versteht 
den Aufbau der HW nicht, nutzt aber eine FFT als IP der neueren 
Generation mit AXI-interface, die nicht genügend ge"taylord" ist. 
Wahrscheinlich läuft die noch (un)skaliert, mit zeitoptimiertem 
butterfly und womöglich float-Implementierung. Da muss man erst einmal 
ran, eine in HW implementierte FFT zu verstehen, dann die IP zu 
verstehen und für seinen Fall zu constrainen. Das ist zugegeben nicht zu 
einfach. Als ich das letzte mal einen XI-FFT-Core angepasst habe, musste 
ich auch erstmal 1h Doku lesen und probieren, bis ich den soweit runter 
hatte, wie ich ihn brauche. Da ist Copy und Paste von VHDL immer noch 
einfacher.

Aber zur Frage:

Der Ansatz die FFT mehrfach zu rechnen ist leider ziemlich daneben. In 
den Fällen, in denen HW- resourcen eng sind, würde man das ohnehin nicht 
auf die Art machen, sondern mit mehr Rechenpower, statt Speicherung also 
"on the fly" arbeiten. Die modernen FPGAs sind da ja schnell genug für 
und können Teil-MUL sogar in fabric logic. Dazu muss man die twiddles 
eben selber formulieren. Dies wiederum erfordert Wissen um die FFT.

Umgekehrt gäbe es die Möglichkeit, die Architektur zu vereinfachen und 
eine echte SIN/COS FIR-Filterung zu betreiben, und dies zu 
parallelisieren, um auf die Bandbreite zu kommen. Das hat auch Vorteile 
hinsichtlich der Auflösung der Frequenz um einen bestimmten Punkt herum. 
Das geht dann in Richtung Görzel. So ist nämlich die 8192 gfs dort, wo 
benötigt, eventuell immer noch zu grob.

Ich sehe hier wieder dasselbe Problem, wie das in vielen solcher 
Zulieferfirmen, mit denen ich zu tun habe: Junge Leute ohne fundiertes 
Wissen denken sich Lösungen aus, die komplett am Notwendigen vorbei 
gehen. Brauchen fett Hardware, viel Strom, viel Fläche und Bauzeit und 
sind trotzdem langsam und zudem noch ungenauer, als was kleines und 
kompaktes, das speziell angepasst wird. Baukastenlösung eben, wie ein 
Zahnrad aus Lego.

Um einen Carrier in einem bestimmten Frequenzbereich zu messen, braucht 
es eigentlich nur 2-3 Faltungen um die Ziel-F herum mit einem 
akkumulierenden Multiplizierer, so wie man das früher in Analog gebaut 
hat. Das wären komplex 2x3 Multiplier, in Xilinx maximal 12 MULs mit 24 
Bitx36Bit, ganz ohne RAM.

Aber das kann ja heute keiner mehr. Die Topologie "FPGA" sieht heute so 
aus, wie bei MATLAB: Erst mal alles in ein fettes RAM und dann irgendwas 
drauflos gelassen, was asynchron iterativ darauf ackert, so wie man eben 
Daten in Softwaresystemen wie Computern handhabt. Schuld sind gerade 
solche Firmen wie Xilinx, die ihren Kunden viele Cores nur noch mit 
CPU-Interface anbieten und so erst dafür sorgen, dass die Programmierer 
unreflektiert ihre erlernte Methodik anwenden und gar nicht darauf 
kommen, das auch mit einer an die Anwendung angepassten Hardware zu 
machen, was ja die eigentliche Idee einer programmierbaren Hardware ist. 
FPGAs verkommen so zu einer Sammlung von Standardlogiken, die nur noch 
mit Abläufen verbunden werden.

Schade umd das schöne Silizium. Um so unverständlicher, dass diese 
Klimmzüge ausgerechnet deshalb gemacht werden, weil Hardware eingespart 
werden soll. Wer Hardware einsparen will, der muss Cores, CPUs und 
Softwareabläufe möglichst aus dem System rauslassen und mit den wenigen 
Resourcen eine anwendungsoptimierte HW erstellen. Resourcen spart man 
mit intelligenter Entwicklung. Baukasten IP ist das Gegenteil: 
Entwicklung sparen durch den Einsatz von mehr Hardware.

Beitrag #6323268 wurde von einem Moderator gelöscht.
von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Maximilian L. schrieb:
> Mein Problem ist folgendes:
> FPGA Evaluation Boards, die in meiner Preisklasse liegen
Da stimmt aber detwas nicht. Auch mit einem 10 Jahre alten C4 war das 
schon möglich:
http://www.96khz.org/htm/spectrumanalyzer2.htm

Die TE0725, die ich inzwischen für meinen Synth nutze, kosten unter 
100,- Netto und da passen mehrere LANEs an 65536er FFTs rein, die auf 
bis zu 297MHz hoppeln.

Maximilian L. schrieb:
> Ich muss ein spezielles Signal,
> welches zwischen 2 und 30 MHz liegt, sampeln und damit die FFT
> durchführen.
Dh. das ist die Bandreite des Signals oder die Frequenz des Signals 
selbst?

> Ich muss dabei bestimmte Carrier-Frequenzen (9KHz) abtasten
> und auswerten.
D.h. es sind mehrere Carrier gleichzeitig?

von Pink Shell (Gast)


Bewertung
0 lesenswert
nicht lesenswert
... und was sind die 8192 genau?

- 8192 Samples, die nacheiander auf der Zeitachse zu finden sind, oder
- 8192 Samples auf der vertikalen Achse, die Du für uns aus den 13 bit 
ausgerechnet hast?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.