mikrocontroller.net

Forum: FPGA, VHDL & Co. Viviado braucht ewig zum synthetisieren


Autor: Vivado (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magst das Projekt mal teilen? Dann kann ich mal einen Blick drauf 
werfen.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Erfahrung nach sind die Programme da ziemlich langsam. Quartus 
hat auch immer eine Minute gebraucht, bis es mal Fehler im Code gefunden 
hat.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Vivado (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ..

Autor: Christian R. (supachris)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-/

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vancouver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: daniel__m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: daniel__m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.