Hallöle,
nachdem ich mich eine Weile mit Xilinx-Cores beschäftigt habe, und
bereits komplexe Pipelines mit den Float-Generatoren gebaut habe, wollte
ich nun alles mal selber machen und mir eine Pipeline bauen, die eine
Multiplikation von 2 Posit-Nummern durchführt. Im Idealfall würde ich
gerne die DSPs vom FPGA nutzen (per Inferenz) und AXI-Streams anbieten,
die - wie die Float-IPs von Xilinx - in jeder Pipeline-Stufe einen Wert
haben können, und dies auch funktioniert, wenn der Consumer danach nicht
ready ist. Ein erster Prototyp existiert, dieser hat jedoch das Problem,
dass ein sehr langer kombinatorischer Pfad entsteht, da alle
ready-Signale jeder Pipeline-Stufe miteinander kombiniert werden, und
das mehrstufig. Xilinx löst das Problem irgendwie, ich komme nur auf die
Idee, jede Stufe mit einem "fully registered slice" auszustatten,
welches die ready-Signale abkoppelt, dafür jedoch pro Pipeline-Stufe die
doppelten Register braucht. Versteht einer, was ich meine und kann mir
einen Tipp geben? Ich plane noch, die Pipeline zu verlängern (zurzeit 6
Stufen) und würde gerne bei möglichst geringem Ressourcen-Aufwand die
höchste Performance in Taktrate.
dzopf schrieb:> fully registered slic
Hi,
das sind im Prinzip kleine, 2-stufige Fifos, welche das ready-Signal
aufbrechen und somit den "Snake-Path" verkleinern.
Und das scheint mir sehr ineffizient zu sein, um nur das ready-Signal
aufzusplitten. Außerdem stellt sich mir die Frage, ob ich bei diesen
Register Slices überhaupt eine DSP mit allen internen Registern
inferieren kann...
dzopf schrieb:> sehr ineffizient
das ist relativ und kommt auf die Umsetzung an. Sofern "nur" Register
en-masse verwendet werden, ist es weniger kritisch, da die "billig" sind
und üblicherweise keine Problem darstellen.
Alternativ habe ich es so umgesetzt, dass ich am Ende ein Fifo packe und
die Eingangsdaten "fire-and-forget" durch die Module schicke. Das Fifo
steuert das Losschicken der Daten und muss natürlich die richtige
Mindestgröße haben, dass es im Worst-Case alle Daten der Module
aufnehmen kann (Latenz), wenn just in dem Moment das Down-Stream-Modul
sein Ready wegnimmt.
dzopf schrieb:> ürde gerne bei möglichst geringem Ressourcen-Aufwand die> höchste Performance in Taktrate.
Was ist bei Dir ein "geringer Bedarf" und was "eine hohe Taktrate"? Die
DSPs kann man alternierend mit 500MHz takten (multi Cycle) sequenziell
300MHz. So schnell sind die AXI-Busse normal nicht.
Die Nutzung der DSPs sind nur ein Beispiel gewesen, mir ging es auch um
die Frage, wie man lange kombinatorische Pfade, die bei Pipelines
aufgrund des ready-Signals entstehen, vermeidet. Die Idee mit der FIFO
am Ende klingt schonmal gut, aber wird bei komplexeren Pipelines nicht
immer funktionieren (bspw. wenn die Pipeline divergiert und mehrere
FIFOs füttert, müsste man alle FIFOs auf deren Acceptance prüfen - wobei
das bei registrierten Almost-Full-Signalen eigentlich hinhauen sollte).
Meine Designs sind bisher immer sehr sparsam an Registern gewesen, bzw.
war die Anzahl der LUTs immer höher. Bei aktuellen Bausteinen (habe den
Cyclone 10 GX als Grundlage) ist die Anzahl der Register ja doppelt so
hoch wie die der LUTs, es sollte also nichts dagegen sprechen, jede
Pipeline-Stufe mit zwei Register-Sätzen auszustatten. Ich habe mich
daran versucht, ein Code-Pattern zu entwickelt, um meine bisherige
Implementierung möglichst einfach zu erweitern, aber ohne viel
Boilerplate-Code wird das leider nichts. Ich arbeite nach der
Gaisler-Methode, siehe Beispiel. Hier ist das alles noch sehr einfach,
wird aber kompliziert, wenn die Pipeline-Stufe mehr als nur eine
einfache Operation durchführt. Zurzeit versuche ich mich an einem
Pattern, das auch bspw. eine Summation von einer Zahlenfolge durchführt,
dabei aber auch zwei Output-Registersätze besitzt.
Per review würde ich sage, das sieht doch vielversprechend aus.
Wenn es um mehrere in- / outputs geht, evtl. wird es vereinfacher, wenn
man erst per glue-logic die in-Streams zu einem Stream synchronisiert
und auch ausgangsseitig erst im 2. Schritt per glue-logic aufsplittet.
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