Forum: FPGA, VHDL & Co. FIR-Filterkoeffizienten und -Arithmetik trennen


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 Stephan K. (Firma: FAU Erlangen) (sofa1780)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebes Forum,

Ich stelle mir folgende Frage:
Ist es sinvoll möglich die Filterkoeffizienten von der Filterarithmetik 
bei einem FPGA zu trennen, sodass die Koeffizienten im Nachhinein, nach 
der Synthes über bspw. eine UART-Verbindung, in gewissen Grenzen, 
geändert werden können?

Dem Anhang ist eine kleine Skizze beigefügt, auf dieser ist eine FSM, 
ein Speicher für die Koeffizienten und ein Block für die 
Filterarithmetik zu sehen. Dabei steuert die FSM die Freigabe der 
Koeffizienten, sollte einmal der Fall auftreten, dass diese während des 
Betriebes, also online, verändert werden.

In meiner Vorstellung also:
- Nun gibt es zwei denkbare Arbeitsweisen des FIR Filters - Parallel und
  Seriell.
- Bei serieller Arbeitsweise könnte man, wenn die Taktrate der Clock und
  die Abtastrate des Filter es zulassen, mit einer Datenleitung für die
  Koeffizienten und weiteren Zwischenspeichern auskommen.
  Bei paralleler Arbeitsweise hingegen müssen bei jedem Takt die
  Koeffizienten bereits anliegen und man benötigt dem entsprechend so
  viele Datenleitungen wie Koeffizienten (Multipliziert mit der
  Wortbreite der Koeffizienten).

  Ein Beispiel: 3 Koeffizienten á 14 Bit (3*14 = 42)
  Bei der Synthese/Verdrahtung werden folglich für die Verbindung zw.
  Koeffizienten und Arithmetik 42 Leitungen verdrahtet.

Meine Fragen an dieser Stelle:
- Stelle ich mir den Sachverhalt richtig vor?
- Ist nicht dann der Ressourchenverbrauch bei der Verdrahtung extrem!
  hoch? Bspw. bei einer Filterordnung von N = 50-100.
- Gibt es auch andere Möglichkeiten dies zu realisieren oder die
  Filtereigenschaften, explizite die Koeffizienten, ohne ein erneutes
  Synthetisieren zu ändern?

Bisher waren die Koeffizienten als Konstannten mit synthetisiert worden. 
Dies soll jedoch in Zukunft anders realisiert werden. Daher meine Frage 
an die experten.

Lieben Dank schoneinmal im Vorfeld.

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Stephan K. schrieb:
> Bisher waren die Koeffizienten als Konstannten mit synthetisiert worden.

Ich bin mir nicht sicher, ob die Idee eines FIR im FPGA wirklich gut 
ist. Immerhin benötigst du pro Tap ja eine Multiplikation und für alle 
zusammen eine Addition über alle Produkte.

Wenn man das parallel ausführen will, kommt ne Menge Holz zusammen und 
meine Befürchtung ist, daß das den Rahmen sprengt ode du einen Chip 
brauchst, der weit außerhalb meines Finanzhorizonts liegt.

Über wieviel Taps im Kernel reden wir denn? Bei 201 Taps brauchst du 201 
Multiplikatoren und einen 201 Input-Adder. Da nützen auch Ideen zum 
Pipelining garnix, um das zu verringern.

Wenn du das Ganze seriell machen willst, an was für eine Taktfrequenz 
hattest du dabei gedacht? Immerhin muß diese dann Tapanzahl*Samplerate 
sein und auch da kommt ne Menge Holz zusammen - diesmal nicht LUT's, 
sondern MHz.

Aber wenn deine bisherigen Entwürfe durchgelaufen sind und 
funktionieren, dann sollte es durchaus möglich sein, die Koeffizienten 
ladbar zu machen.

Die würden dann ja ohnehin als verteiltes RAM mitten im Logikmeer stehen 
und mir würde dazu nur einfallen, selbige seriell zu laden, also quasi 
als großes Schieberegister quer durch den ganzen Chip.

W.S.

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Idee eines FIR im FPGA

Also in Büchern habe ich diesen Ansatz schon merhfach gelesen, zuletzt 
in "VHDL-Synthese" von "Jürgen Reichardt". Möglich schon und auch 
relativ schnell.

> Über wieviel Taps im Kernel reden wir

Wir reden von so an die 88 Taps.
Ich arbeite mit einem CycloneIV (DE2-115 Dev-Board), dieser hat 266 
14x14 Multiplikatoren. Ich benötige letzlich 3 FIR Filter bei N=88 
(88*3=264) ist somit also schluss.
Das Signal kommt von einem ADA-Daugtherboard mit max. 65 MSPS, diess 
kann ich jedoch nicht gänzlich ausreizen, da sonst die Ordnungen des FIR 
zu hoch werden würden.

> was für eine Taktfrequenz hattest du dabei gedacht?

Im Umkehrschluss würde dies bedeuten, dass ich bei einer Taktrate von 65 
MHz mit ca. 738 kHz (65e6/88) sampeln könnte. Wobei ich über ne PLL auch 
die Taktfrequenz auf ca. 100 MHz erhöhen könnte, danach wirds zu ungenau 
denke ich.

Danke für die bisherige Meinung!!

Gruß.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klar geht das, prinzipiell macht man das so auch.
Aber: Du musst ev. was zu deinen Randbedingungen (Clock, Resourcen) 
erzählen. Typischerweise frisst dir der serielle Ansatz die wenigsten 
Resourcen (DSP slices) weg, wenn aber die Geschwindigkeit nicht reicht, 
musst du dein Problem a la divide et impera behandeln.
Wenn du hochparallel arbeiten musst, kommst du mit den MAC-Units bzw. 
den harten DSP-Slices ev. ans Limit, dann läuft das typischerweise auf 
eine distributed-RAM-Geschichte für die Koeffizienten raus, und das mit 
dem zweiten Port oder Muxer zum Reinschreiben von aussen wirkt ab einer 
gewissen Anzahl sehr "verstopfend" beim Routing.
Beim klassischen seriellen Ansatz nimmst du typischerweise ein 
Dualport-BlockRAM, und kannst über den zweiten Port im laufenden Betrieb 
die Parameter ändern.

von Jürgen S. (engineer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Sicher wird das gemacht und das nicht nur bei FPGAs. Die 
Filterkoeffizienten stehen dann in Registern, in RAMs oder in der 
pipeline. Bei FPGAs ist diese Betrachtung deshalb interessant, weil bei 
der Synthese strukturelle Optimierungen vorgenommen werden können, d.h. 
jegliche Multiplikation kann bei bekannten Koeffizienten vereinfacht 
werden. D.h. bedeutet Runterbrechen auf stufenweise Additionen, die an 
ihrerseits in LUTs aufgespalten werden und zur Mehrfachtermnutzung 
führen.

Ob und wieviel das bringt, hängt von den Koeffizienten und der 
Abspaltung ab. Manches geht automatisch und wird von der Synthese 
beschreibungsunabhängig gefunden, manches aber eben auch nicht. Man kann 
die K's ja entsprechend der Aufgabe und der Architektur skalieren und 
optimieren, um zu besonders einfachen Koeffizienten und damit kleinen 
Filtern zu gelangen, die trotzdem noch in der Spec sind. Die Auflösung 
der Daten, die Aussteuerung und der Bandverlauf des Filters, vor allem 
auch der Frequenzgang der Daten sind dabei zu beachten. Ein 
Messtechnikfilter für 0 .. 20kHz und 16 Bit, ist das z.B. aufwändiger, 
als eines für 20Hz bis 20kHz bei 20Bit, wenn es Audiodaten mit typischem 
Frequenzgang sind.

Das ist die eigentliche Aufgabe bei der Signalverarbeitung mit FPGAs.

Ansonsten einfach die Steinzeit-Hammer-Methode und die 
Standard-Koeffizienten von MATLAB oder dem CoreGen berechnen lassen und 
nehmen, was man kriegt.

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, ja geht problemlos, habe ich schon gemacht. Wenn man das FIR 
Filter in eine eigene Componente auslagert muss man dorthin aber die 
Koeffizienten weiterreichen. Man baut sich halt eine Logik die das 
macht.

Stephan K. schrieb:
> Wir reden von so an die 88 Taps.
> Ich arbeite mit einem CycloneIV (DE2-115 Dev-Board), dieser hat 266
> 14x14 Multiplikatoren. Ich benötige letzlich 3 FIR Filter bei N=88
> (88*3=264) ist somit also schluss.
> Das Signal kommt von einem ADA-Daugtherboard mit max. 65 MSPS, diess
> kann ich jedoch nicht gänzlich ausreizen, da sonst die Ordnungen des FIR
> zu hoch werden würden.

Brauchst Du wirklich so viele Taps?

Stephan K. schrieb:
> Im Umkehrschluss würde dies bedeuten, dass ich bei einer Taktrate von 65
> MHz mit ca. 738 kHz (65e6/88) sampeln könnte. Wobei ich über ne PLL auch
> die Taktfrequenz auf ca. 100 MHz erhöhen könnte, danach wirds zu ungenau
> denke ich.

Wenn Du das Filter parallel baust kannst Du die volle Samplerate 
(65MSamples/s) in Echtzeit filtern.

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Du musst ev. was zu deinen Randbedingungen (Clock, Resourcen) erzählen.

Die Randbedingungen sind das Entwicklerboard DE2-115 und ein 
ADA-Daughterboard von Terasic. D.h. ich arbeite mit einem Cyclone IV
Modell: EP4CE115) und einem parallelen 14 Bit AD-Wandler mit 65 MSPS.

Zum Cyclone IV:
-LEs:              114,480
-Memory:           3,888 Kbits
-I/O:              528
-18x18 Multiplyer: 266
-Clock networks:   20
-PLLs:             4
-Clocks:           4
-Clock speed:      50 MHz

Jürgen S schrieb:
> Ein Messtechnikfilter für 0 .. 20kHz und 16 Bit, ist das z.B. aufwändiger.

Und genau um so einen handelt es sich. Der Frequenzbereich passst auch 
einigermaßen.

Jürgen S schrieb:
> ..die Steinzeit-Hammer-Methode und die Standard-Koeffizienten von MATLAB.
Gustl Buheitel schrieb:
> Brauchst Du wirklich so viele Taps?

Wie komme ich denn besser an Koeffizienten, wenn nicht über Matlab? In 
den bisherigen Büchern wurde letztlich immer empfohlen, die 
Koeffizienten über diesen Weg zu berechnen.
Ist dies die Ursache für die vielen benötigten/errechneten Taps?
Ich mein, wenn die Koeffizienten symmetrisch sind kann ich prinzipiell 
mit halb so vielen Taps arbeiten, wenn ich den Begriff "Taps" richtig 
verstehe.

Gustl Buheitel schrieb:
> Wenn Du das Filter parallel baust kannst Du die volle Samplerate
> (65MSamples/s) in Echtzeit filtern.

Hierzu:
Jürgen S schrieb:
> Die Auflösung der Daten, die Aussteuerung und der Bandverlauf des
> Filters, vor allem auch der Frequenzgang der Daten sind dabei (bei der
> Berechnung der Koeffizienten)zu beachten.

Insbesondere bei der erhöhung der Samplerate meiner akquirierten Daten 
am AD-Wandler (auf 65 MSPS), sprich die Auflösung steigt, muss 
zwangsläufig auch die Ordnung des Filters erhöht werden. Ich würde sogar 
soweit gehen und behaupten, dass die Ordung des Filters mit der 
Auflösung der zu filternden Daten proportional einher geht.


Lieben Dank noch einmal an alle, für die bisher sehr konstruktiven 
Antworten!! =)

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Stephan K. schrieb:
> Insbesondere bei der Erhöhung der Samplerate meiner akquirierten Daten
> am AD-Wandler (auf 65 MSPS), sprich die Auflösung steigt, muss
> zwangsläufig auch die Ordnung des Filters erhöht werden. Ich würde sogar
> soweit gehen und behaupten, dass die Ordnung des Filters mit der
> Auflösung der zu filternden Daten proportional einher geht.

OK, du willst also langsamer sampeln? Kann man da nicht einen Kompromiss 
machen aus schnell sampeln, dann erstmal ein schlechtes billiges Filter 
wie einen gleitenden Mittelwert der keine Multiplizierer kostet, und 
danach dann das FIR Filter.

von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> OK, du willst also langsamer sampeln? Kann man da nicht einen Kompromiss
> machen aus schnell sampeln, dann erstmal ein schlechtes billiges Filter
> wie einen gleitenden Mittelwert der keine Multiplizierer kostet, und
> danach dann das FIR Filter.

Hmm, der Ansatz scheint mit garnicht mal blöde! Ich denke, das versuche 
ich mal.

Das langsamer sampeln war angedacht um eine geringere Ordung und evtl. 
ein serielles FIR zu realisieren.

: Bearbeitet durch User
von Jürgen S. (engineer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Stephan K. schrieb:
> Ich würde sogar soweit gehen und behaupten, dass die Ordung des
> Filters mit der Auflösung der zu filternden Daten proportional einher geht.
Da bist Du nicht der einzige, der diese Erkenntnis hat :-)

Ich wiederum würde soweit gehen, zu behaupten, dass auch die 
Abtastfrequenz (in-)direkt in die Ordnungszahl eingeht.

Aber jetzt mal im Ernst:

Wer sich näher mit der Wirkung der FIR-Filter befasst, der erkennt 
eigentlich durchs Anschauen der Filterkoeffizienten, wie sie wirken und 
die Schlussfolgerung, dass steigende Anforderungen an Genauigkeit, 
Spektrum, Trennvermögen der Bänder und eine erhöhte Abtastrate 
unweigerlich eine steigende Dichte dieser Punkte zur Folge haben müssen! 
Es ist freilich so, dass nicht mit allen Parametern linear erfolgt, 
d.h.die Forderungen nach gleichzeitig doppelter Abtastfrequenz und 
Genauigkeit erfordert nicht etwa auch gleichsam einer Verdopplung der 
Koeffizientengenauigkeit UND - anzahl. Da dominiert oft ein Faktor den 
anderen.

Wie man zu optimalen Koeffizienten gelangt:

Viele Filter bauen, Länge und Tiefe variieren, durchsimulieren und 
Messen und das Ganze mit Anforderungen vergleichen und daran Prinzipien 
erkennen.

Ein paar einfache Regeln gibt es freilich:

Wenn Du z.B. 16 Bit Daten mit 20Hz bis 20kHz erfassen möchtest und mit 
48kHz abtastest, dann ist irgendwie schlüssig, dass 128 TAPs ein bissl 
wenig sein werden, weil der Überdeckungsbereich von 48000/128 gerade mal 
375Hz Auflösung sind. Du darfst jetzt mal schätzen, wieviele FilterTAPs 
man braucht, um auf unter 16Hz "runterzukommen" und dann mit 384KHz 
abzutasten und dabei 24Bit Audio zu verarbeiten, dass es studiotauglich 
wird und welche Systemtaktfrequenz ein FPGA haben muss, um das 
vollsequenziell zu lösen.
Dann musst Du noch abschätzen, wie genau diese Mimik aus "analoger" 
Sicht ist, d.h. wieviel Fehler die Restwelligkeit bringt und kannst 
daraus die nötige Koeffizientengenauigkeit berechnen.

Wenn man das richtig "dick" baut, kommt man auch Filter, die an die 
20Bit Güte haben. Wenn man die Architektur klug aufbaut und die 
Koeffizienten optimiert, kommt man auf eine Architaktur, die im pipeline 
Betrieb mit 128 Multipliern auskommt und 32 Kanäle mit voller Bandbreite 
gleichzeitig berechnen kann.

http://www.96khz.org/htm/spectrumanalyzer2.htm

Mit etwas Gehirnschmalz auch als Kompressor:

http://www.96khz.org/htm/multibandcompressor2.htm

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stephan K. schrieb:
> Ist es sinvoll möglich die Filterkoeffizienten von der Filterarithmetik
> bei einem FPGA zu trennen, sodass die Koeffizienten im Nachhinein, nach
> der Synthes über bspw. eine UART-Verbindung, in gewissen Grenzen,
> geändert werden können?

Wenn du die FIR nicht parallel berechnen muss, sondern per MAC, dann ist 
das trivial. Man nimmt dazu ein Dual-Port-RAM. Ein Port zum Beschreiben, 
der andere liest für den MAC.

Parallel ist es schwieriger, aber nicht unmöglich ...

Die Antwort ist: It depends ... Du musst dir vorher Gedanken darüber 
machen, wie lang dein FIR ist und wie schnell du Ergebnisse benötigst, 
dann kannst du dich entscheiden.

Ich hab schon 1024-Tap FIR Filter als MAC implementiert (44,1kHz), ich 
hab auch schon 64-Tap-FIR-Filter parallel implementiert (4,318...MHz) 
... Kommt halt drauf an, was du brauchst.

: Bearbeitet durch User
von Stephan K. (Firma: FAU Erlangen) (sofa1780)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Du darfst jetzt mal schätzen, wieviele FilterTAPs man braucht, um auf
> unter 16Hz "runterzukommen" und dann mit 384KHz abzutasten und dabei 24Bit Audio
> zu verarbeiten, dass es studiotauglich

So an die 24000 Taps, wenn nicht es doppelte, wenn ich bedenke, dass für 
eine so große Bittiefe ein Multiplier (bsp.: 18x18) alleine nicht 
reicht.
Das ist eine ganz schöne Menge an Holz!

Da gehört bei eine FIR mit 128 Multiplier bei 32 Kanälen mit voller 
Bandbreit sicher einiges an Erfahrung und Gehirnschmalz dazu.

Wie ja auch schon erwähnt:
> Viele Filter bauen, Länge und Tiefe variieren, durchsimulieren und
> messen und das Ganze mit Anforderungen vergleichen und daran Prinzipien
> erkennen.

Zu einem endgültigen Resultat bin ich zwar noch nicht gekommen, aber ich 
habe mich mal weiter mit dem Erfahrungsgewinn befasst.


Ein großes Dankeschön nochmal an euch alle für die schnelle und sehr 
hilfreiche Disskusion!

In diesem Sinne noch allen miteinander einen hohen Wirkungsgrad. ;)

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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