Ich habe mir gerade ein Video zum PlanAhead Tool von Xilinx angesehen und bin ganz angetan von den Optimierungsmethoden, die dort vorgestellt werden. Eine Sache, die ich besonders interessant finde, ist die Möglichkeit, direkt auf der Chipfläche einzelne Bereiche (Partitionen) zu bestimmen, in die alle Logikelemente dedizierter Funktionsblöcke des Designs hineingelegt werden können. Man kann diese Auswahl neuerdings sogar auf RTL-Ebene bestimmen. Hierdurch lassen sich zeitkritische Anteile der gesamten Logik in einen definierten Bereich auf der Chipfläche legen, die sonst willkürlich verstreut wären und man kann damit (laut Demonstrationsvideo) das Timing der gesamten Logik signifikant verbessern wenn entsprechende Voraussetzungen vorliegen. Die Anwendung dieser Methode setzt allerdings entsprechendes fundiertes Grundwissen über den Transfer der erzeugten Logik auf die Chipfläche voraus. Mich würde sehr interessieren, ob hier im Forum schon jemand mit diesen Optimierungsmöglichkeiten arbeitet und wie die erzielbaren Resultate in der Praxis aussehen. Danke schon mal für entsprechende Infos. MfG Norbert
Sicher es gibt Fälle, in denen man Logikzellen per Hand platzieren kann und so das timing besser trifft, aber im Prinzip tut das die Synthese und dann ist es mir Schnurz, ob weit verteilte Logik da verschwendereisch gesetzt wurde. Etwas anderes ist das Ausnutzen der letzten Reserven, um ein grossens Design in einen kleinen Chip gerade so reinzuquetschen: Das würde ich aber zunächst dadurch versuchen, in dem ich XST meide und ein third-party tool verwende, das Synthes und Platzierung in Konjunktion betreibt und gtu beherrscht. Die Xilinx Methode, erst mal im Rahmen der "Synthese" alles vorzuverarbeiten und dann Mapping und Placing nachzubereiten um dann wieder Register zuzusetzen oder wegzunehmen, die vorher schon hinzugefügt werden, wird immer ein Verschwender sein! Wir beobachten Ergebnisse, bei denen die XST Zeiten um 15% unterboten wurden, be minimal sogar kleinerem Resourcenverbrauch. Das Basln auf RTL Ebene ist höchst ineffektiv und läuft auch in genau die falsche Richtung: Wir werden mit Designs immer grösser und gehen bei SOC sogar Verweschwendung ein, um schnell zu entwickeln,
Präzisierung: Mit "XST Zeiten" meine ich die maximale delay Zeit = 1/Taktfrequenz des Designs. Die Synthese selber dauert dabei natürlich nicht selten länger, als eine XST Synthese.
Norbert schrieb: > man kann damit (laut > Demonstrationsvideo) das Timing der gesamten Logik signifikant > verbessern wenn entsprechende Voraussetzungen vorliegen. Dazu muß man erstmal eine 'fertige' Logik haben, die das vorgegebene Timing nicht schafft. Ich würde die Geschichte als letzen Ausweg sehen, wenn sonst nix mehr hilft. Sonst muß man u.U. mit jeder neu implementierten Funktion das Placement anpassen. Duke
Norbert schrieb: > Mich würde sehr interessieren, ob hier im Forum schon jemand mit diesen > Optimierungsmöglichkeiten arbeitet und wie die erzielbaren Resultate in > der Praxis aussehen. Das sind normalerweise Funktionen, die Telecom-Anwender wie z.B. Cisco brauchen, um das letzte Quäntchen Taktfrequenz aus ihrem 20k€ FPGA herauszuquetschen. Oder um das (Teil-)Design als Baugruppe zigfach reproduzierbar duplizieren zu können. Ich habe das noch nie gebraucht, mir haben Constraints bisher immer gereicht... > man kann damit (laut Demonstrationsvideo) das Timing der gesamten Logik > signifikant verbessern ... sagte der Verkäufer.
Lothar Miller schrieb: >> man kann damit (laut Demonstrationsvideo) das Timing der gesamten Logik >> signifikant verbessern > ... sagte der Verkäufer. Ok, danke Lothar. Ich hab mir schon gedacht, dass hier ein nicht unbedeutender Werbefaktor mit drin ist. Also doch besser andere Mittel zur Optimierung auswählen. Norbert
Duke Scarring schrieb: > Dazu muß man erstmal eine 'fertige' Logik haben, die das vorgegebene > Timing nicht schafft. Ok, die ist ja schon da. Es wird in dem Video auch explizit darauf hingewiesen, dass das Ganze auf RTL-Ebene stattfindet. In dem konkreten Beispiel ist es ein USB Softcore, dessen Timing durch Anwendung dieser Methodik optimiert wird. > Ich würde die Geschichte als letzen Ausweg sehen, wenn sonst nix mehr > hilft. Sonst muß man u.U. mit jeder neu implementierten Funktion das > Placement anpassen. Vielen Dank für den Hinweis. Ist immer gut wenn jemand mit viel praktischer Erfahrung Hinweise geben kann, nach der man vorgehen sollte. Gruß, Norbert
Norbert schrieb: > In dem konkreten > Beispiel ist es ein USB Softcore, dessen Timing durch Anwendung dieser > Methodik optimiert wird. Also DAS ist für mich der doppelte Widerspruch in sich. Man nimmt eine performance fordernde Funktion, portiert sie aber nicht in Hardware, sondern in Form eines virtuellen Ablaufs (= Software) auf einem Standardsystem (= CPU), bläht die Funktion auf Realisationsebene / Logikebene extrem auf und verschwendet dabei soviele Resourcen, dass der Durchsatz sowas von in den Keller geht, nimmt dann obendrein auch noch eine Soft-CPU, die nochmal langsamer und platzverschwendender ist, als eine Hard-CPU, verschwendet als physikalische Optionen und geht dann in die RTL-Ebene hinein, um dort 10% rauszukitzeln. Vollkommener Q.....sch. Das ist so, als würde Sebastian Vettel keinen Red Bull Renault benutzten, um schnell zu sein, sondern sich virtuell vorwärst bewegen, indem er in einer langen Kette von Renault R4 auf einem Autoreisezug von einem Dach zum anderen hopst, um vorwärst zu kommen während sein Chefmechaniker an der Tyristorsteuerung der Zugelektronik fummelt, um ihn 5% schneller zu machen.
J. S. schrieb: > Das ist so, als würde Sebastian Vettel... Da triffst du den Nagel auf den Kopf. Ich sehe darin auch eher einen akademischen "Nutzen", ganz ähnlich wie bei der ach so hochgepriesenen partielle Rekonfiguration.
J. S. schrieb: > Das ist so, als würde Sebastian Vettel keinen Red Bull Renault > benutzten Muhaaaa.. den Vergleich musste ich zweimal lesen, weil er so lustig ist. Besser kann man´s glaub nicht ausdrücken :-) Aber ganz abgesehen davon finde ich es grundsätzlich nicht verkehrt, wenn man die Möglichkeit hat, mit einem vernünftigen Tool "ganz nah" am Chip rumzukratzen. Es kann, wenn auch selten, vorkommen, dass es einfacher ist, ein Problem durch manuellen Eingriff zu lösen, als es über Constraints zu beschreiben. Aber die Notwendigkeit so eines Eingriffs wird wohl normalerweise eher die Ausnahme bleiben.
Hm, ich mache ein grobes Vorplazieren von Toplevel-Modulen eigentlich schon lange. Ohne Planahead, nur per ucf. Wenn man sich nicht dazu hinreissen lässt, zu kleine Bereiche vorzugeben, geht das schon ganz gut und liefert gegenüber "planlosem" Mapping schnellere Routingzeiten und auch konsistenteres Timing. Man muss etwas rumprobieren (hängt auch an den IOs), aber ich schau im FPGA-Editor, wieviel Slices das Modul braucht und nehm dann so die 5-6fache Fläche. Wenn viele Leitungen zwischen zwei Modulen da sind, dann sollten die auch gut zur Hälfte überlappen. Mehr Trennung und Vorschriften sind eher kontraproduktiv, ein 'INST "MODULE*" LOC=....' reicht schon.
Was meinst Du mit "konsistenterem" Timing? In welcher Hinsicht ist ein Timing konsistenter als ein anderes?
Juergen S. schrieb: > Was meinst Du mit "konsistenterem" Timing? In welcher Hinsicht ist ein > Timing konsistenter als ein anderes? Ich vermute, es ist ein reproduzierbareres Timing bei unterschiedlichen Syntheseläufen gemeint. Das kann ich nämlich bestätigen. Ich platziere gerne Deserializer Blöcke manuell direkt neben die IOs. Ansonsten landen die mal direkt daneben, oder auch mal ganz wo anders, so dass das Timing nicht immer eingehalten wird.
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.