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.
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.
