Hallo!
Ich arbeite gerade daran, ein Design in einem Virtex 5 auf ca. 200 MHz
zu bringen. Wenn man ein paar Pipelinestufen in typische
Speicher-Multiplizierer-Addierer-Ketten einbaut, so ist man recht
schnell weit über 100 MHz.
Will man darüber hinaus gehen, so beginnen bei zu langen Setup-Paths
aber plötzlich net-Delays zu dominieren, wenn ein Signal einen hohen
Fanout hat. Bei einem Fanout von 5-15 treten bereits Delays von ca. 2 ns
Sekunden auf.
- Ist das normal?
- Und wie kann man das beheben? Soll man das Treiben dieser Signale
ebenfalls pipelinen, so dass der hohe Fanout baumförmig erreicht wird?
Wenn ja, muss man das (für aktuelle Xilinx-Tools) explizit baumförmig
machen, oder optimiert die Synthese da selbst?
Falls ihr mehr Infos braucht, so liefere ich die gerne nach.
ich halt schrieb:> wenn ein Signal einen hohen> Fanout hat. Bei einem Fanout von 5-15 treten bereits Delays von ca. 2 ns> Sekunden auf.
Du Glücklicher. Wenn du bei 4ns und fanout 1 bist, dann hast du den
Punkt erreicht wo du dich beschweren darfst.
ich halt schrieb:> Und wie kann man das beheben?
per Hand platzieren
Das der Mapper vom V5 und V6 nix taugt gibt sogar Xilinx inoffiziell zu
Soll wohl mit den neuen Tools besser werden, allerdings sind die nur ab
der 7er Generation vorfügbar...
ich halt schrieb:> - Und wie kann man das beheben? Soll man das Treiben dieser Signale> ebenfalls pipelinen, so dass der hohe Fanout baumförmig erreicht wird?
Das würde ich als erstes versuchen, wenn es Dein Design zuläßt.
> Wenn ja, muss man das (für aktuelle Xilinx-Tools) explizit baumförmig> machen, oder optimiert die Synthese da selbst?
Hmm. Sowohl als auch. Im MIG hab ich mal sowas für einen Resetbaum
gesehen. Da wurde eine Pipeline mit einem Maxfanout constraint. Und
register duplication muss natürlich auch aktiviert sein.
Duke
routing delay schrieb:> per Hand platzieren>> Das der Mapper vom V5 und V6 nix taugt gibt sogar Xilinx inoffiziell zu
Das heisst letztlich, dass jedes Design jenseits von 100 MHz schnell
eine sehr haarige Sache werden kann...? (Nicht weil man schlecht
arbeitet, sondern weil die Implementationstool nicht gut sind.)
ähmm.. schrieb:> 2ns = 500 MHz
Ich hatte den TO so verstanden, das das die Routing Delays sind. Die
Logic Delays (ähnlicher Größenordnung) kommen da noch dazu.
ich halt schrieb:> Nicht weil man schlecht> arbeitet, sondern weil die Implementationstool nicht gut sind.
Ich würde das nicht so direkt auf die Tools schieben sondern auf die
Algorithmen. Die skalieren nicht mit der Zahl der verfügbaren
Logikelemente (siehe Travelling Salesman).
Duke
Duke Scarring schrieb:> ähmm.. schrieb:>> 2ns = 500 MHz> Ich hatte den TO so verstanden, das das die Routing Delays sind. Die> Logic Delays (ähnlicher Größenordnung) kommen da noch dazu.
So ist es. Ich habe beispielsweise jetzt sogar ein Signal mit einem
Fanout 1, das rund 2 ns Routing Delay bringt. Das finde ich schon etwas
seltsam... So kann man ein Design auch nicht vernünftig beschleunigen,
da im Gegensatz zu Logic Delays hier Pipelining nicht wirklich hilft.
> ein Signal mit einem Fanout 1, das rund 2 ns Routing Delay bringt.
Schau mal im FPGA-Editor nach, welche Umwege das machen muss. Manchmal
helfen Location-Constraints schon viel weiter. Allerdings ist meine
Erfahrung, dass man die eher grossflächig einsetzen sollte. Zu penibles
Abzählen der Slices und exaktes Aneinanderklatschen der Module ist eher
hinderlich.
ich halt schrieb:> Das heisst letztlich, dass jedes Design jenseits von 100 MHz schnell> eine sehr haarige Sache werden kann...?
Je nach Designgröße gibts bei 200Mhz im V6 schon Probleme bei einem
Fanout von 1 und einem Logiklevel von 1.
Beispiel: Block von 10% aller Slices im V6 läuft mit >>300Mhz. Zusammen
mit dem restlichen Design(~60-70% Gesamt belegt inkl dem Block) schafft
er manchmal nichtmal 200. Ist aber purer Zufall, d.h. smartxplorer
hilft da irgentwann. Eine Lösung ist das trotzdem nicht.
ich halt schrieb:> So kann man ein Design auch nicht vernünftig beschleunigen,> da im Gegensatz zu Logic Delays hier Pipelining nicht wirklich hilft.
eigentlich hilft es gar nichts.
Du kannst auch 4 FF-Stufen dazwischen bauen, wenn der Mapper nix taugt
liegt eine davon im Nirgentwo und du hast doch wieder ein riesen routing
delay.
Am besten hast du noch eine Chance wenn du überschaubare Blöcke machst
und diese räumlich eingrenzt, dann kann der Mapper nicht zu viel falsch
machen.
Das Interface zwischen den Blöcken muss dann so schmal wie möglich sein,
ggf per Hand eine FF-Stufe dazwischen platziert.
In jedem Fall aber ufert das aus und irgentwann schießt man sich ins
Knie wenn ein neuer Block dazu kommt und nirgends so richtig passt. Dann
fängt man bei 0 an und ohne floorplanning geht dann gar nix mehr.
> Dann fängt man bei 0 an und ohne floorplanning geht dann gar nix mehr.
Da merkt man halt, dass FPGA-SW noch ca. 30 Jahre Entwicklungsvorsprung
gegenüber Compilern aufholen muss. Noch Anfang der 90er ist der i860
trotz seiner für die damaligen Zeit wirklich wahnsinnigen
FPU-Performance im HPC-Bereich gefloppt, weil die Compiler mit dem
komplexen Befehlsscheduling für die vielen Pipelines nicht
zurechtgekommen sind. Heute macht das sogar der gcc recht tauglich...
Was auch nicht verwunderlich ist: die Hersteller machen ihre Tools
selbst.
Die Synthese zur Netzliste kann man austauschen, danach wirds
problematisch, denn die ganze Struktur ist nicht öffentlich.
Manche versuchen da ran zu gehen (synplify, Mentor) aber mehr als ein
großer Bug kommt da nicht raus, was man ihnen nichtmal vorwerfen kann.
Dazu noch die erhöhte Komplexität der Aufgabe und schon kann man alles
vergessen.
>Manche versuchen da ran zu gehen (synplify, Mentor) aber mehr als ein>großer Bug kommt da nicht raus,
Was genau meinst Du? SynplifyPro macht einen guten Job.
Stachele schrieb:> Was genau meinst Du? SynplifyPro macht einen guten Job.
Ja, bei der Synthese.
Hier geht es aber um Place&Route. Ganz andere Baustelle.
Das war gemeint, z.b. das Platzieren mit SynplifiyPremier bzw dem Mentor
Pendant.
Der Bau der Netzliste ist längst kein Problem mehr, das beherrschen alle
gut. MMn am ehesten mit einem Softwarecompiler vergleichbar. Danach erst
wirds haarig.
routing delay schrieb:> Der Bau der Netzliste ist längst kein Problem mehr, das beherrschen alle> gut. MMn am ehesten mit einem Softwarecompiler vergleichbar. Danach erst> wirds haarig.
Place & Route ist mit Leiterplattendesign vergleichbar.
Hat da schon mal jemand einen Alogrithmus gesehen, der Autoplace und
Autoroute perfekt hinbekommt?
Duke
Duke Scarring schrieb:
>Hat da schon mal jemand einen Alogrithmus gesehen, der Autoplace und>Autoroute perfekt hinbekommt?
Perfekt geht weder was im Compilerbau noch im P&R (exp-Aufwand!).
Z.B. ist im Compilerbau die Registerzuweisung per Graphcoloring
"gut" hinzubekommen.
P&R wird ebenfalls mit Algos aus dem Bereich Graphenalgos heuristisch
gelöst. Ein interesantes Buch zu diesem Thema ist "Graph Drawing"
von G. Battista etal., insbesondere die "Orhoghonalen Algos" für's
P&R in FPGAs.
