www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Quiz - parallele FPGA-Funktionsweise


Autor: Quizer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Eine kleine Verständnisfrage:

Braucht das dargestellte FIR-Filter auf einem FPGA (mit genügend 
Multiplizierern) zur Berechnung eines Ausgangswertes:

a) einen Taktzyklus (?die Multiplikationen finden bei steigender Flanke, 
das Aufaddieren der Teilprodukte bei fallender Flanke statt?)
b) zwei Taktzyklen (?einen für die Multiplikationen, einen für die 
Akkumulierung der Teilprodukte?)
c) weder noch ?

Da bin ich mal gespannt ;)

Autor: Quizer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
sorry, hab ne .psd Datei angehangen.. hier nochmal als JPEG.

Autor: Quizer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur zur Absicherung: die Copy-Rights für das Bild hat Xilinx ;)

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weder noch:

Das kommt auf die Implementierung an, wie viele zusaetzliche Register du 
einbaust. Das Addieren von 256 Zahlen ist keine triviale Sache, die 
innerhalb von wenigen Nanosekunden erledigt waere.

Wenn dein Takt langsam genug ist (schaetzungweise <10MHz im Spartan 3), 
dann kann man das sicher auch in nur einem Taktzyklus abarbeiten, sonst 
muss man dort mit Pipelining arbeiten und zusaetzliche 
Zwischenergebnisse berechnen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ...zur Berechnung eines Ausgangswertes...
Also, genügend (und genügend schnelle) Kombinatorik (Multiplizierer und 
LUTs) vorausgesetzt, braucht diese Schaltung einen Takt nur zum 
Weiterschieben der Eingangsdaten.
Weder die Multiplikation noch die Addition ist eine getaktete Operation.
Also Lösung c, weil zur Berechnung kein Takt nötig ist.

Autor: Quizer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jan .M: Pipeline-Register würden zwar den Durchsatz erhöhen, aber die 
Berechnung eines Ausgangswertes würde doch durch die zusätzlichen 
Verzögerungen durch die Pipeline-Register mehr Zeit in Anspruch nehmen, 
oder?

@ Lothar Miller: was genau ist damit gemeint, dass keine Berechnung 
notwendig ist? Es muss doch jeweils ein Eingangswert mit einem 
Filterkoeffizienten multipliziert werden und das Ergebnis zum vorherigen 
Ergebnis hinzuaddiert werden oder nicht?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne die Verschiebeoperation asynchron zu machen und die Operationen 
explizit aufzubauen, benötigt man n-1 Register und kann es in n Takten 
machen. Die Addition schachtelt man rekursiv rein. Das macht aber kein 
Mensch so, sondern baut pLatzoptimiert.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> was genau ist damit gemeint, dass keine Berechnung nötig ist...

Nein, meine Aussage war, dass
> zur Berechnung kein Takt nötig ist.

Die Rechnungen, die in dem Filter vorkommen sind prinzipiell nur 
kombinatorisch und benötigen daher keinen Takt. Ich kann z.B. eine 
Addition in VHDL einfach so beschreiben:
  r <= b + c;
--> kein Takt nötig.

Dasselbe geht mit einer Multiplikation:
  w <= e * f;
--> wiederum: kein Takt nötig

Beide Grund-Rechenoperationen können daher taktlos synthetisiert werden.
Und mit den von dir angegebenen Rahmenbedingungen:
1) mit genügend Multiplizierern
2) keine Architektur
3) keine Angabe zur gewünschten Arbeitsgeschwindigkeit
kann ich daher sagen:
Zur Berechnung des Ausgangswertes ist kein Takt notwendig.

Allein zum Eintakten der Daten in das Filter brauche ich getaktete 
Register (deshalb heißen die Dinger oben im Bild ja auch Reg).

In der Praxis hat man Vorgaben zu den Ressourcen (nicht beliebig viele 
Addierer und Multiplizierer) und auch Vorgaben zur Geschwindigkeit. Da 
muss man dann das ganze Design oder Teile davon sequentiell abarbeiten.

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bekommt man da in der Praxis keine Probleme mit den racing conditions? 
weil 256 Filtertaps sind ja (gefühlt) schon eine ganze menge wenn man 
das ohne Takt (asynchron) machen will.

Gruß

Autor: Quizer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Lothar Miller: Sorry, hatte Dich erst falsch verstanden.. aber auch bei 
kombinatorischer Logik kann ich doch die Teilergebnisse erst 
aufaddieren, nach dem die Multiplikationen stattgefunden haben.

Beispielsweise beim Code:
c <= a * b;
d <= d + c;

so wird für Zeile 2 doch im selben Takt noch nicht das Ergebnis von a * 
b für c, sondern der vorherige Wert von c (was immer der sein mag) 
verwendet. Also irgendwo spielt doch in Hardware ein Takt, oder 
zummindest ein zeitliche Komponente eine Rolle (die Signale, die durch 
die synthetisierte kombinatorische Logik geführt werden, brauchen doch 
eine gewisse Zeit, die Operationen finden wohl kaum mit delta_t=0 
statt).

Um ein wenig Klarheit in den Kontext meiner Frage zu bringen, habe ich 
die beiden Folien der XUP Präsentration in den Anhang gepackt. Es geht 
dabei um das Aufzeigen der Vorteile von FPGAs im Vergleich zu DSPs.

Autor: Quizer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anhang Teil2

Autor: Quizer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
"Bitte einen längeren Text eingeben" (nervig)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> so wird für Zeile 2 doch im selben Takt noch nicht das
> Ergebnis von a * b für c, sondern der vorherige Wert von c verwendet.
Oh nein.
Wenn ich das taktlos und concurrent beschreibe, wird das wirklich 
parallel aufgebaut. Hier z.B. eine kleine Beschreibung mit 4 
Registerwerten multipliziert mit 4 Koeffizienten und anschliessender 
Summation. Im ganzen Design weit und breit kein Takt.
Der Takt ist nur für das Filter nötig, um neue Registerwerte (für a,b,c 
und d) zu laden, aber das passiert nicht hier in dieser Beschreibung.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity muladd is
    Port ( a  : in  SIGNED (3 downto 0); -- Eingangswerte v. Registern
           b  : in  SIGNED (3 downto 0);
           c  : in  SIGNED (3 downto 0);
           d  : in  SIGNED (3 downto 0);
           ca : in  SIGNED (3 downto 0); -- Koeffizienten
           cb : in  SIGNED (3 downto 0);
           cc : in  SIGNED (3 downto 0);
           cd : in  SIGNED (3 downto 0);
           e  : out SIGNED (9 downto 0));
end muladd;

architecture Behavioral of muladd is
signal ma : SIGNED (7 downto 0); -- Multiplikationsergebinsse
signal mb : SIGNED (7 downto 0);
signal mc : SIGNED (7 downto 0);
signal md : SIGNED (7 downto 0);
begin
   ma <= a * ca;
   mb <= b * cb;
   mc <= c * cc;
   md <= d * cd;
   e <= ma + mb + mc + md;
end Behavioral;
Im Bild dazu die RTL Schematics. Auch hier klar zu sehen: die clk-Pins 
sind nicht angeschlossen, weil asynchrone Multiplizierer verwendet 
werden.


> aber auch bei kombinatorischer Logik kann ich doch die Teilergebnisse
> erst aufaddieren, nach dem die Multiplikationen stattgefunden haben.
Richtig, rein kombinatorisch aufgebaut wird das Design ziemlich groß und 
zäh. Denn die Multiplikationen laufen zwar (wirklich) parallel, das 
daraus berechnete Additionsergenbnis wird aber geraume Zeit vor sich hin 
glitchen.

> Es geht dabei um ... Vorteile von FPGAs im Vergleich zu DSPs.
Auf dem Bild von Xilinx sieht man dann auch: For Academic Use Only
In der Praxis wird kaum einer einen so großen Filter tatsächlich 
komplett Kombinatorisch aufbauen, dazu sind die Ressourcen zu wertvoll 
;-)

Autor: Quizer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zunächst einmal vielen Dank für die Mühe..

Gerade die Stelle
das
daraus berechnete Additionsergenbnis wird aber geraume Zeit vor sich hin
glitchen
wirft bei mir ja die Frage auf, wie lang das Aufaddieren dauert.. je 
nach Takt könnte diese Dauer doch (vor allem bei sovielen Teilprodukten) 
länger dauern als ein Taktzyklus, oder?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt drauf an, wie schnell die Logikgatter sind und wieviele 
Logik-Ebenen hintereinander sind. Auch schnelle FPGAs haben endliche 
Schaltzeiten.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  wie lang das Aufaddieren dauert....
>  je nach Takt könnte diese länger dauern als ein Taktzyklus, oder?
Ja.
Dein Takt, der die Daten einschiebt und/oder weiterverarbeitet muß 
natürlich langsam genug sein. Ob es reicht sagt dir die Statische 
Timinganalyse, wenn du es mal implementiert hast.

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

kennt sich desbezüglich jemand mit einem DSP48A Slice aus? JEDES dieser 
Slices kann ja eine Vor-Addition, eine Multiplikation und eine 
Nach-Addition durchführen. Da ein solches Slice keinen Takteingang hat, 
heißt das doch, das die Logik kombinatorisch ist und dass das Ergebnis 
immer bei einer Signaländerung am Eingang sofort (bzw. nur mit einer 
minimalen Schaltzeitverzögerung) am Ausgang bereit steht, richtig? Und 
da im Datenblatt steht, dass der Slice maximal mit einem Takt von 250 
MHz läuft, kann man davon ausgehen, dass diese Schaltzeit 1/250MHz 
beträgt oder sehe ich das ganze falsch? Wieso steht da überhaupt was vom 
maximal verwendbaren Takt, wenn das Teil gar nicht getaktet werden kann?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wieso steht da überhaupt was vom maximal verwendbaren Takt,
> wenn das Teil gar nicht getaktet werden kann?
Weil davor und danach wieder alles getaktet und hübsch synchron sein 
sollte und sein wird. Und dann ist natuürlich interessant, wie schnell 
dieser Takt sein darf.

Im Xilinx User-Guide 431 steht
>>> Full-speed operation is 250 MHz when using the pipeline registers.
Und Pipeline Register waren schon immer das Mittel, wenn es darum ging, 
die Taktfrequenz auf Kosten der Latency hochzuschrauben. Siehe dazu den 
Beitrag "Re: failed paths im Timing analyzer"

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk ging noch gar nicht ab, warum?

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal... echt nett, wie Du allen hier auf die Sprünge hilfst ;)

Und umso netter wäre es, wenn du dich auch noch kurz zu meinen anderen 
Aussagen äußern würderst:

"Da ein solches Slice keinen Takteingang hat,
heißt das doch, das die Logik kombinatorisch ist und dass das Ergebnis
immer bei einer Signaländerung am Eingang sofort (bzw. nur mit einer
minimalen Schaltzeitverzögerung) am Ausgang bereit steht, richtig?
Und da im Datenblatt steht, dass der Slice maximal mit einem Takt von 
250
MHz läuft, kann man davon ausgehen, dass diese Schaltzeit (bei maximalem 
Pipelining) 1/250MHz beträgt oder?"

Pipelining macht aber doch nur Sinn, wenn ich hohe Datenanforderungen 
habe.. wenn ich z.B. ein FIR Filter habe, dass als Eingang alle 1/48kHz 
neue Audiodaten erhält, dann macht der Einsatz von Pipelineregistern ja 
keinen Sinn, weil diese dann nur zu einer zusätzlichen Latenz führen 
würden, oder? Weil, es ist doch so:
Alle 1/48kHz = 20833ns liegt ein Eingangswert am Eingang an, wird 
Blitzschnell (nur mit einer Schaltzeit) und parallel abgearbeitet, und 
das FIR-Filter wartet den Rest des Taktes auf einen neuen Eingangswert.
Sehe ich das falsch?

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerd (Gast),

du kannst die DSP-Komponenten bei entsprechend gesetzten Generic-Werten
auch ohne Register verwenden. In diesem Fall hast du eine 
kombinatorische
Schaltung. Aus der in der Tabelle abzulesenden max. Taktrate ergibt sich
dann die Gatterlaufzeit (die eben umgekehrt die Frequenz bestimmt). Bei
250MHz ergibt sich so eine Gatterlaufzeit von 4 ns.

Wenn du vor oder nach der Multiplikation noch weitere komb. Logik
verwendest, dann kannst du die Pipeline-Register im Eingang bzw. im
Ausgang auch weglassen (eben auf Kosten der Gatterlaufzeit, bei 48KHz
wohl kein Problem).

Gruss

jörg

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Da ein solches Slice keinen Takteingang hat...
Doch, ein DSP48A-Slice hat durchaus einen Takteingang. Dieser geht auf 
die vielen Register, die nach jeder kombinatorischen Elementaroperation 
in dem Slice eingebaut sind.

> wenn ich z.B. ein FIR Filter habe, dass als Eingang alle 1/48kHz
> neue Audiodaten erhält, dann macht der Einsatz von Pipelineregistern ja
> keinen Sinn, weil diese dann nur zu einer zusätzlichen Latenz führen
> würden, oder?
Prinzipiell ist keine Signalverarbeitung ohne Latenz möglich, für ein 
Filter brauche ich mehrere Eingangsdaten, damit ich ein Ergebnis 
berechnen kann.

Die Pipelineregister innerhalb des Slices sind so angeordnet, dass 
dazwischen nie mehr als 4ns-(ts+th) vergehen, so kommt Xilinx auf eine 
maximale_Taktfrequenz von 250MHz. Ein Wert muss aber u.U. bis zu 5 
solcher Stufen hintereinder durchlaufen, bis das Ergebnis am Ausgang 
erscheint. Fazit: komplette Rechenzeit vom Eingang bis zum Ausgang 20ns 
= 50MHz maximale_Rechengeschwindigkeit.

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn die Verwendung von Pipelineregistern (bei Erstellung eines 
parallelen FIR-Filters mit Hilfe von DSP48A-Slices) bei einer geringen 
Datenrate von nur 48kHz nun
a) kontraproduktiv (führt also zu schlechteren Ergebnissen),
b) produktiv (auch bei 48kHz sind die Pipelinregister sinnvoll, da 
insgesamt auch da der Durchsatz erhöht wird)
oder
c) das Ergebnis ist in diesem Fall das Gleiche, nur dass das Ergebnis 
mit einer höheren Latenz erscheint (also kein Nutzen durch 
Pipelineregister, aber gleiches Ergebnis mit höherer Latenz als ohne 
Verwendung von jeglichen Pipelineregistern).

Gruß

Gerd

Autor: Joko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerd

a)nein
b)nein
c)ja

aber bei 48kHz sollte man sich ernsthaft überlegen,
das parallele FIR-Filter in ein serielles zu überführen,
und mit einem N-fachen Arbeitstakt zu arbeiten, da man
bei 'richtigem Aufbau' eine Menge Ressourcen einsparen kann.
Speziell: N Multiplizierer -> 1 Multiplizierer

'richtiger Aufbau' meint hier, daß man versuchen sollte,
die Eingangsmultiplexer (für den einen Multiplizierer) zu
vermeiden, indem Memory (SRL16, distributed RAM oder BlockRAM)
diese Funktionalität übernimmt
    http://www.xilinx.com/publications/xcellonline/xce...

/Jochen

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Anregung auch folgender Link:
http://janick.bergeron.com/ -> Earlier Work, Top-Down Design Using VHDL

Duke

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.
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.