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.)
2ns = 500 MHz 5 ns = 200 MHz 500 MHz verdammt schwierig. 200 MHz sollten ja wohl mach bar sein.
ä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.
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.