Hi, ich benutze für Privat das Vivado v2018.3 (64-bit) (Webversion) auf Ubuntu. Beim Synthetisieren von einem Counter schlafe ich glatt ein so ewig dauert es. AUffällig lang hält es sich bei dem Schritt "Running write_bitstream" auf. Gibt es möglichkeiten diesen Vorgang etwas zu beschleunigen? übrigens, das synthetisieren dauert bei mir 4 minuten und das obwohl meine CPU's sich langweilen.
Bei Vivado hilft es oft nur die Single-Thread Performance zu erhöhen, sprich CPU mit viel GHz kaufen. 4 Minuten ist ja noch nicht viel... ich warte selbst mit einem Core i7 mit 3.5 GHz manchmal 30 Minuten für einen Durchlauf. Hängt natürlich vom FPGA und dessen Komplexität ab. Nicht alles lässt sich parallelisieren. Auf jeden Fall solltest du dir mal "set_param general.maxThreads" angucken
Magst das Projekt mal teilen? Dann kann ich mal einen Blick drauf werfen.
Meiner Erfahrung nach sind die Programme da ziemlich langsam. Quartus hat auch immer eine Minute gebraucht, bis es mal Fehler im Code gefunden hat.
Vivado schrieb: > synthetisieren dauert bei mir 4 minuten vier Minuten? Skandalös. Ich hatte vorhin eine Synthese, die lief 190 Minuten. Und hat dann das Timing (knapp) verfehlt. Im nächsten Anlauf klappt's bestimmt ;)
Ja mir ist klar das die Zeiten explodieren werden. Ich habe mir aus spaß mal nen Addierer mit 1024 bit und 7 Operanten gebaut. Quartus II hatte daran 4 Tage gerechnet :D Aber 4 Minuten nur um einen 16 bit Zähler zu bauen ..
Das write bitstream dauert für einen gegebenen FPGA Typ immer gleich lange, egal wie leer oder voll der ist. 4 Minuten, pah. Lächerlich, das ist ja quasi nur Write Bitstream. :D
Christian R. schrieb: > 4 Minuten, pah. Lächerlich, das ist ja quasi nur Write Bitstream. :D 4 Minuten sind ja auch nur die Synthese. Vll dauert ihm auch der Rest u lange, das steht da mt keinem Wort. :-/
Vivado schrieb: > übrigens, das synthetisieren dauert bei mir 4 minuten > und das obwohl meine CPU's sich langweilen. Wenn im FPGA noch genug Platz ist, dann geht die Synthese meiner Erfahrung nach recht schnell (ein paar Minuten ist "recht schnell"). In dem Augenblick, wo der FPGA langsam voll wird, explodieren die Zeiten - auch dann, wenn das Timing äußerst unkritisch ist. Will man das Design dann noch beschleunigen, hilft nur viel Geduld. Zumindest in der Webpack-Version sind nur sehr wenige Prozeßschritte parallelisert. Wenn man stattdessen mehrere Synthesen gleichzeitig laufen lassen könnte, hätte man wenigstens was davon...
Tobias B. schrieb: > Christian R. schrieb: > 4 Minuten, pah. Lächerlich, das ist ja quasi nur Write Bitstream. :D > > 4 Minuten sind ja auch nur die Synthese. Vll dauert ihm auch der Rest u > lange, das steht da mt keinem Wort. :-/ Achso, so wie er es geschrieben hatte, klang es so als würde er den gesamten Prozess bis zum Bitstream als Synthese bezeichnen. Write bitstream ist anscheinend für ihn ein Teil davon: Vivado schrieb: > Beim Synthetisieren von einem Counter schlafe ich glatt ein so ewig > dauert es. AUffällig lang hält es sich bei dem Schritt "Running > write_bitstream" auf
Christian R. schrieb: > Achso, so wie er es geschrieben hatte, klang es so als würde er den > gesamten Prozess bis zum Bitstream als Synthese bezeichnen. Write > bitstream ist anscheinend für ihn ein Teil davon: Ja, ist irgendwie nicht eindeutig. Es fehlen auch ein paar Infos, z.B. ob Batch oder GUI Mode verwendet wurde oder wie lange die einzelnen Teilprozesse dauern. Das Projekt mal anderen zur Verfuegung zu stellen koennte auch helfen. Dann kann jeder der Interesse hat ein Bitfile generieren und berichten ob es unerwartet lange dauerte.
Ich arbeite gerade an einem Design das 90% der LUTs eines Artix7-35 verbraucht und dabei mäßige Timing-Constraints benötigt. Vivado benötigt für die komplette Synthese/Implementierung/Bitfileerzeugung ca. 20min im Script-Mode, also ohne GUI. Zeitweise werden alle Cores verwendet, meistens aber nur einer, eine gute Singlecore-Performance ist bei Vivado also schon wichtig. Ich habe zwar keine exakten Vergleiche, aber gefühlt läuft Vivado im Script-Mode deutlich flotter als mit der GUI.
hi, ich hatte es auch, dass er bei "write_bitstream" eine gefühlte Ewigkeit einfach "nichts" tat, keine CPU, keine Festplatte (bzw. SSD), kein Netzwerktraffik. Irgendwie sah es nach einem Timeout aus und tatsächlich, er versucht irgendeine "link-lokal" Adresse (169.254....) anzusprechen, die es bei nicht gibt. Ich habe diese Adresse einfach einer Netzwerkkarte zusätzlich gegeben und der Schritt "write_bitstream" lief dann erheblich schneller, auch wenn der ganze Vorgang von Synthese bis Bitstream einfach ätzend langsam ist. Zum Vergleich, ich hatte mal ein gaaanz kleines VHDL Modul mit Lattice Diamond für einen MachXO2 und für einen Artix7-S6 übersetzten lassen: Lattice < 15sec, Xilinx > 4min grüße
daniel__m schrieb: > MachXO2 und für einen Artix7-S6 übersetzten lassen: Lattice < 15sec, > Xilinx > 4min Äpfel und Birnen. MachXO2 ist ein CPLD mit einer überschaubaren Anzahl Makrozellen. Sowas macht Xilinx ISE bei fast leer auch in wengen Sekunden. Selbst der Artix ist da wesentlich komplexer und das Erzeugen des Bitstreams dauert dann halt wesentlich länger. Aber insgesamt ist die Xilinx Software schon vergleichsweise langsam. Das ist wahr. Wobei es sich mit Vivaro schon gebessert hat, vor allem wenn man die parallele CPU Nutzung auf 8 stellt.
Christian R. schrieb: > Aber insgesamt ist die Xilinx Software schon vergleichsweise langsam. > Das ist wahr. Wobei es sich mit Vivaro schon gebessert hat, vor allem > wenn man die parallele CPU Nutzung auf 8 stellt. Was aber nur für einige Prozeßschritte gilt und mit der WebPACK-Edition noch weniger. Leider.
Christian R. schrieb: > Äpfel und Birnen. MachXO2 ist ein CPLD mit einer überschaubaren Anzahl > Makrozellen. Sowas macht Xilinx ISE bei fast leer auch in wengen > Sekunden. Der MachXO2 ist schon eher ein FPGA (verwendet wurde der 4000er). Von den Resourcen dem A7S6 nicht unähnlich, jedenfalls rechtfertigt das nicht weit über Faktor 16 in der Laufzeit. Das einzige, was ich Xilinx zugute schreibe ist, dass deren SW (Vivado, nicht die alte, aber schnellere ISE) auch mit wahnsinnig großen FPGAs/SOCs umgehen können muss. Das wird sicherlich einen trade-off haben, so dass kleinst-FPGAs schlecht da stehen. Xilinx Versuch mit OOC (zumindest bei der Synthese) ist m.M.n. auch erst bei größeren Cores interessant, da das Starten der SW (was für jeden OOC-Run gemacht wird) vergleichsweise lange dauert (trotz i7700 + NVMe + Linux). Und bei mir immer wieder für "Spass" sorgt, so dass ich es eher selten nutze.
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.