Ich bin neu in VHDL und Xilinx. Beim durchgehen bin ich über die Sache mit den DSP48-Blöcken gestolpert. Ich habe mich gefragt, warum man eigentlich DSP48-Blöcke anstelle von Logik für Multiplikationen verwendet. Welche Vorteile gibt es hierbei? Es wäre cool, wenn jemand das für einen DSP-Neuling wie mich aufklären könnte!
Der H. schrieb: > Ich bin neu in VHDL und Xilinx. Beim durchgehen bin ich über die Sache > mit den DSP48-Blöcken gestolpert. Ich habe mich gefragt, warum man > eigentlich DSP48-Blöcke anstelle von Logik für Multiplikationen > verwendet. Welche Vorteile gibt es hierbei? > > > Es wäre cool, wenn jemand das für einen DSP-Neuling wie mich aufklären > könnte! DSP48 ist schneller und nimmt weniger FPGA resourcen.
:
Bearbeitet durch User
Der H. schrieb: > Ich habe mich gefragt, warum man > eigentlich DSP48-Blöcke anstelle von Logik für Multiplikationen > verwendet. Macht man nicht, ein DSP48-Block beinhaltet einen Multiplizierer (die Kuller mit dem 'X'), schau dir bittedas Blockbild an. Vor dem DSP48 gabs dem MUL18-Block. https://www.researchgate.net/profile/Bogdan-Pasca/publication/281658777/figure/fig4/AS:669422771515396@1536614234180/Overview-of-the-Xilinx-DSP48.png > Es wäre cool, wenn jemand das für einen DSP-Neuling wie mich aufklären > könnte! Lass Dich auf ne Schulung schicken. Wahrsheinlich verwechselst du DSP "digital signal processing" mit "Digital signal processor", der DSP48 ist kein DS-Prozessor wie dunnemals der TMS320 . https://docs.xilinx.com/v/u/en-US/ug479_7Series_DSP48E1 Und macht dich mal schlau, wieviel LUT-Logicresourcen ein MUL schluckt.
Eine Multiplikation mit 48-bit-Ergebnis in LUTs zu bauen braucht ziemlich viel Platz. Da man Mutliplikationen aber häufig braucht, hat Xilinx die DSP-Blöcke eingebaut, die sind kleiner und viel schneller und können noch mehr als nur multiplizieren. Im Synthesis-Guide steht irgendwo, wie du festlegen kannst, ob bei einer Multiplikation ein DSP-48 oder eine LUT-Struktur verwendet werden soll. Manchmal kann es auch sinnvoll sein, einen Multiplier aus LUTs zu bauen, z.B. bei kleineren Multiplikationen. Und wie schon jemand geschrieben hat, der Begriff DSP-48 ist etwas irreführend. Man kann diese Macros auch für andere Anwendungen als Signalverarbeitung verwenden.
Vielen Dank für die Antworten! Dass der DSP48 kein Prozessor ist, ist mir klar, das sieht man ja am Blockschaltbild :) Da fehlt der Prozessorkern Ich habe noch einen Knoten im Kopf warum der DSP48 schneller ist als die Multiplikation - da der DSP48 auch eine Multiplikation enthält Ich würde es mir nun mit den vorherigen Antworten so erklären, dass der DSP48 eine dezidierte Logik hat während eine reine Multiplikation auf dem FPGA mit den CLBs, also durch LUTs realisiert wird. Ist das richtig?
Der H. schrieb: > Vielen Dank für die Antworten! > > Dass der DSP48 kein Prozessor ist, ist mir klar, das sieht man ja am > Blockschaltbild :) Da fehlt der Prozessorkern > > Ich habe noch einen Knoten im Kopf warum der DSP48 schneller ist als die > Multiplikation - da der DSP48 auch eine Multiplikation enthält > > Ich würde es mir nun mit den vorherigen Antworten so erklären, dass der > DSP48 eine dezidierte Logik hat während eine reine Multiplikation auf > dem FPGA mit den CLBs, also durch LUTs realisiert wird. > > Ist das richtig? ja.
Angehängte Dateien:
-
FPGA_Evolution.PNG
200 KB
> Ich würde es mir nun mit den vorherigen Antworten so erklären, dass der > DSP48 eine dezidierte Logik hat während eine reine Multiplikation auf > dem FPGA mit den CLBs, also durch LUTs realisiert wird. > > Ist das richtig? Es trifft nicht ganz den Kern. Das Problem resp. die Bremse sind weniger die LUT's selbst als die interconnects, also die Laufzeit zwischen den LUT's über die FPGA-routing Resourcen. Ein Hardware-Multiplizierer kann man sich als ein großes Feld aus mehreren Hundert XOR-Gattern vorstellen. Als extra-Bauelement ist der sehr Kompakt und hat damit eine geringe Durchlaufzeit. Diese Struktur aus Slices nachgebaut, verlangt nun mehrere hundert slices, deren LUT's zwar sehr schnell durchlaufen werden, aber zwischen den LUT fallen zusätzliche pico- bis nanosekunden an. Ohne die blauen Blöcke im Anhang li.u. müsste man vielleicht jedes vierte von den grünen Blöcken verwenden um einen DSP-Block zu ersetzen. Und dieser Ersatz ist natürlich deutlich langsamer weil die Signal dort weitaus größere Strecken durchlaufen müssen.
Der H. schrieb: > Ich würde es mir nun mit den vorherigen Antworten so erklären, dass der > DSP48 eine dezidierte Logik hat während eine reine Multiplikation auf > dem FPGA mit den CLBs, also durch LUTs realisiert wird. > Der DSP48-Block kann eine ganze Menge, u.a. Multiplizieren. Also wenn du eine Mutliplikation durchführen musst und noch DSP48 frei sind, kannst du die Multiplikation darauf rechnen. Das verplempert keine LUTs die du für andere Dinge brauchst, und ist viel schneller als mit LUTs. Im Grunde das gleiche wie mit Speicher im FPGA: Du kannst Speicherarrays aus Flipflops aufbauen, das ist aber nur sinnvoll bei kleinen Speichern. Oder du kannst die LUTs dafür verwenden, oder eben die großen Blockrams, die sind genau dafür gemacht.
Antti L. schrieb: > DSP48 ist schneller und nimmt weniger FPGA resourcen. So kann man das nicht sage, denke ich. Durch die ausdrückliche Wahl des DSP-Elementes legt man sich auf diesen Block fest. Bei der einfachen Multiplikation bleibt es erst einmal offen, wie es gemacht wird. Der Synthesizer entscheidet dann, ob er ein DSP-Element nicht oder nicht. Ich lasse immer alles in nativem VHDL beschreiben, statt einer Festlegung. Dann lässt sich der Code transferieren. Oder gibt es irgendeinen Vorteil, ein DSP ausdrücklich einzufügen?
Andi F. schrieb: > Oder gibt es irgendeinen Vorteil, ein DSP ausdrücklich einzufügen? Nein, Inferenz ist immer die bessere Lösung, weil der Code leichter ztu simulieren und technologieunabhängig ist. Aber manchmal erkennen die Tools nicht, dass die Funktion in einen DSP48 gemapt werden kann, dann muss man die Instanz selbst erzeugen, oder man bekommt ein Kuchenblech mit LUTs geliefert.
Vancouver schrieb: > Im Grunde das gleiche wie mit Speicher im FPGA: Du kannst Speicherarrays > aus Flipflops aufbauen, das ist aber nur sinnvoll bei kleinen Speichern. Diese sind aber schneller, als ein BLock-RAM, wie wir getestet haben!
🐻 Bernie - Bär schrieb: > Diese sind aber schneller, als ein BLock-RAM, wie wir getestet haben! Genau wie ein Multiplizierer aus LEs auf einem Cyclone I nicht unbedingt langsamer ist, als ein DSP-Block auf einem Cyclone II, III, ...
🐻 Bernie - Bär schrieb: > Diese sind aber schneller, als ein BLock-RAM, wie wir getestet haben! Bei welcher Speichergröße? Und wieviel schneller? Welche FPGA? Kleine Speicher können als FF-Arrays durchaus schneller sein als Blockrams, wenn die Addresslogik und die Multiplexerkaskaden entsprechend klein ausfallen. Aber dass ein Speicher in der Größe eines Blockrams mit FFs schneller ist, scheint mir doch eher seltsam.
Vancouver schrieb: > dass ein Speicher in der Größe eines Blockrams mit FFs > schneller ist, scheint mir doch eher seltsam. Richtig, die Adressdecoder sind super langsam. Allerdings verteilen sich kleine RAMs mit deren Logik als FFs und LUTs so schön gleichmäßig in der Schaltung, dass kleine RAMs von z.B. nur 128 Speicheradressen sehr viel näher am Geschehen sind, wenn der FPGA voll ist. Deshalb ist das routing kurz und man bekommt die Daten schon im nächsten Takt. Bei langsamen FPGAs von 100MHz abwärts geht es auch mit größeren Speicherflächen und breiteren Multiplexern.
Bernd G. schrieb: > Allerdings verteilen sich > kleine RAMs mit deren Logik als FFs und LUTs so schön gleichmäßig in der > Schaltung, nur als sogenannte distributed RAMs. Die BRAMs liegen ja dort, wo sie liegen :-) Vancouver schrieb: > Kleine > Speicher können als FF-Arrays durchaus schneller sein als Blockrams, die sind sogar ganz ausnahmslos schneller. Die angeblichen 450MHz die z.B. die BRAM in einem A7 bringen, verlieren sich schnell auf dem Weg zur Schaltung. Oft müssen fabric FFs nachgeschaltet werden, um überhaupt wieder die 200 zu packen. Besonders kritisch sind Schaltungen die Resets brauchen, die tief in kaskadierte BRAMs gehen. Da sind FFs oft die bessere Alternative.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.