Hallo Leute, ich brauche, um meine Bachelor-Arbeit zu schreiben, unter Anderem einen Round Robin arbiter in Form von Verilg Code. Das ganze war auch nicht so schwierig, bis ich von meinem Betreuer erfahren habe, dass die Arbitrierung in einem Taktzyklus erfolgen muss. Die Breite des Request und Grant Vektors müssen dynamisch sein, also via Parameter einstellbar. Habe dazu leider wenig bis gar nichts im Internet gefunden und wollte mal fragen ob jemand dazu irgendwelche Tipps hat? Danke & Gruß
ich glaube der Ram IPCORE von xilinx benutzt auch sowas!! Vllt bringt es was sich die Core-Datein anzugucken... Mehr kann ich dazu leider nicht sagen. Sry
Was meinst du genau mit "in einem Taktzyklus"? 0 Taktzyklen Verzögerung? Das ist in der Tat problematisch: erstens ist es recht aufwändig umzusetzen, zweitens wird der kritische Pfad sehr lang. Wenn du einen Arbiter möchtest, der mit einem Taktzyklus Verzögerung arbeitet, ist das kein Problem: da gibt es zahlreiche Ansätze. Einer der einfachsten und besten Ansätze arbeitet mit Maskierung, sodass der aktuelle Grant im nächsten Taktzyklus niedrigste Priorität erhält. Hier ist eine einfache Implementierung in VHDL: https://bitbucket.org/grigorig/axisnoc_router/src/53d77a1e1e6a7f525bd06b721903ce03bd0b6037/src/ArbiterRR.vhd?at=master Um Arbiter mit vielen Lines effizient umzusetzen, habe ich auch einen Tree Arbiter implementiert: https://bitbucket.org/grigorig/axisnoc_router/src/53d77a1e1e6a7f525bd06b721903ce03bd0b6037/src/ArbiterTreeRR.vhd?at=master Der Code ist nicht schwer zu verstehen, das müsstest du leicht in Verilog umsetzen können.
Ganz nebenbei, wenn es ein MUSS sein soll, dass die Arbitrierung im gleichen Taktzyklus stattfindet, ich glaube dann lauft ihr auf eine Sackgasse zu. Worum geht es denn konkret?
Es geht hier um ein auf einem FPGA laufenden SoC System mit mehreren Softcores. Ich muss ein Konzentratormodul schreiben, sodass mehrere Softcores in den Konzentrator Daten reinschreiben können und diese Daten dann schlussendlich alle an einen einzigen weitergeleitet werden. Im Konzentrator selber ist ein zentraler FIFO-Buffer in dem alle Daten zusammenlaufen. Die Zuteilung auf dem Buffer muss über einen RR Arbitrierer erfolgen. Habe es aber inzwischen hinbekommen, habe das Schaltbild hier auf dieser Seite eben in Verilog umgesetzt und funktioniert auch wie gewünscht, aber danke für eure Antworten! :) http://rtlery.com/articles/how-design-round-robin-arbiter Hatte die ganze Zeit über Verzweigungen und ein Zählregister eine Art for-schleife gebaut, was aber natürlich je nach Request-Status teilweise mehrere Takte gebraucht hat.
Markus schrieb: > Das ganze war auch nicht so schwierig, bis ich von meinem Betreuer > erfahren habe, dass die Arbitrierung in einem Taktzyklus erfolgen muss. Bei angenommen 1MHz Taktfrequenz ist das gar nicht so schwer... Was? Schneller? Wie schnell?
Markus schrieb: > Ich muss ein Konzentratormodul schreiben, sodass mehrere Softcores in > den Konzentrator Daten reinschreiben können und diese Daten dann > schlussendlich alle an einen einzigen weitergeleitet werden. > > Im Konzentrator selber ist ein zentraler FIFO-Buffer in dem alle Daten > zusammenlaufen. > > Die Zuteilung auf dem Buffer muss über einen RR Arbitrierer erfolgen. Spendier doch einfach jedem Softcore einen kleinen FIFO und steuere den Zugriff auf den Sammel-FIFO mit einem Arbiter. Dann sind die Latenzen nicht mehr so wichtig. Wenn du die typischen Softcore-Interfaces wie FSL oder AXI4-Stream verwendest ist der FIFO eh sehr sinnvoll.
Lothar Miller schrieb: > Markus schrieb: >> Das ganze war auch nicht so schwierig, bis ich von meinem Betreuer >> erfahren habe, dass die Arbitrierung in einem Taktzyklus erfolgen muss. > Bei angenommen 1MHz Taktfrequenz ist das gar nicht so schwer... > > Was? Schneller? Wie schnell? Das System läuft im Moment entweder mit wahlweise 27 MHz oder 60 MHz.
Markus schrieb: > Das System läuft im Moment entweder mit wahlweise 27 MHz oder 60 MHz. D.h. der Arbeiter soll einfach den Bus an den nächsten vergeben, wenn der Bus frei ist. Sobald der Bus sowieso blockiert/vergeben ist, gibt es keine Grant und es muss evtl. sowieso mehrere Takte gewartet werden... Markus schrieb: > Die Breite des Request und Grant Vektors müssen dynamisch sein, also via > Parameter einstellbar. Wie ist das gemeint? "Dynamisch" pro Zyklus? > also via Parameter einstellbar. Es ist in erster Näherung egal, ob du Parameter fix (z.B. über Generics) codierst oder einstellbar machst. In der Praxis wird eine einstellbare Parametrierung aber auf jeden Fall Zeit kosten, weil ja mehr Logik zur Umschaltung nötig ist. Ein knappes Zeitpolster wird also noch mehr strapaziert. Ich würde den Arbiter erst mal mit festen Grenzen zum Laufen bekommen, und dann sehen, was zur Parametrierung zusätzlich nötig ist.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.