Wie schnell ist Quartus und Vivado auf unterschiedlichen CPUs

Gast #7256485
Lesenswert?

Aufgrund einer anderen Diskussion hier und auch im Matlab-Forum ist mir 
ein Gedanke gekommen, den ich mal in den Raum stelle:

Bei Matlab gibt es den Effekt, das es auf AMD-Maschinen langsamer läuft, 
weil angeblich bestimmte Prozessor-Optimierungen von AMD nicht genutzt 
werden, während von Intel alles verwendet wird, was geht und Tempo 
bringt.

Wie sieht das bei FPGA-Design-Software aus:

Jetzt, nachdem Intel das "alte era" gekauft hat, ist davon ausgehen, 
dass Quartus vorwiegend für Intel Maschinen optimiert wird. Würde ich 
jedenfalls zu machen. Zumindest würde man mal zusehen, dass es keine 
Nachteile gibt.

Umgekehrt nehme ich an, dass AMD bei der Erzeugung von Vivado darauf 
bedacht sein wird, möglichst AMD-CPU Reserven zu benutzen, um es zu 
beschleunigen. Sollte AMD also durch die Compiler benachteilgt worden 
sein, könnte sich das bei Vivado demnächst ändern.

?
Gast #7256759
Lesenswert?

Mach doch den Anfang und entwerfe einen Benchmark. Denk darüber nach was 
so erfüllt sein muss damit da ordentliche Vergleiche rauskommen, dann 
schreibst du HDL und Constraints, testest das erstmal bei dir und dann 
wenn du das gut findest machst du ein öffentliches Repo auf und pflegst 
eine Tabelle mit den Ergebnissen die dir die Benutzer zuschicken.
Gast #7256823
Lesenswert?

Bei der Designsoftware spielt eher das OS eine Rolle. Unter Linux laufen 
die Tools Faktor 1.5 bis 3 schneller gegenueber der Windows-Version, 
eine Menge Memory vorausgesetzt, so dass nur Prozesseffekte und kein 
Swapping ins Spiel kommt.
Matlab ist eine ganz andere Anforderung an die CPU als Synthese oder 
PnR. Bei AMD vs Intel wirst du hier typischerweise keinen Unterschied 
merken.
Bei ganz grossen Designs macht es teilweise Sinn, die Tools nur noch per 
Kommandozeile aufzurufen, die oft involvierten QT-Oberflaechen verbraten 
teils auch eine Menge Zyklen.
Gast #7256994
Lesenswert?

Kritiker schrieb:
> Umgekehrt nehme ich an, dass AMD bei der Erzeugung von Vivado darauf
> bedacht sein wird, möglichst AMD-CPU Reserven zu benutzen, um es zu
> beschleunigen. Sollte AMD also durch die Compiler benachteilgt worden
> sein, könnte sich das bei Vivado demnächst ändern.

Jaja, Weihnachten ist die Zeit für speculatius und Verschwörungstheorien 
gehen in pseudo-intellektuellen Kreisen ganzjährig.

Scripte ne vernüftige Toolchain das spart mehr zeit als über 
Industriepolitk zu phantasieren. Und die Rechenzeit halbiert sich 
ohenhin aller zwei Jahre, dank dem Moore sein Gesetz.
Gast #7259596
Lesenswert?

Leider sind Alteras im Moment nicht zu bekommen. Ok, Xilinx ist auch 
fürchterlich. Ich musste einige Designs vom NIOS zum Microblaze 
umstellen. Fazit: Wer Zeit hat darf ruhig Vivado nehmen. Wer keine 
Performance-Anforderungen an IO und extern an den Bus angeschlossene 
Hardware hat, kann gerne diesen verdammten AXI-Kram nutzen. Also, wenn 
um Performance geht:NIOS
Gast #7259612
Lesenswert?

Ich schrieb:
> Also, wenn um Performance geht:NIOS

Jo genau, die Performance eines FPGAs misst man daran wie performant ein 
Mikrocontroller ist.
Egal ob uBlaze oder Nios, die sind meistens nur für leichtere 
Hausmeistertätigkeit im FPGA, Daten schaufeln und viel rechnen macht man 
nicht damit, wer einen FPGA nur wie einen uC verwendet der hat FPGA 
nicht verstanden oder verzichtet bewusst auch die Vorteile vom FPGA 
gegenüber eines uCs.

Ich schrieb:
> Design unter Quartus: 4min. Portiertes Design unter Vivado: 35min.

Ohne das Design ist die Aussage wertlos.
Gast #7259626
Lesenswert?

-gb- schrieb:
> Ich schrieb:
>> Also, wenn um Performance geht:NIOS
>
> Jo genau, die Performance eines FPGAs misst man daran wie performant ein
> Mikrocontroller ist.

Auch wenn ich es Leuten wie Dir kaum zumuten mag, lese einfach die 
Fragestellung. Ansonsten gebe ich Dir recht. Ein SOC war nicht im Spiel. 
Sollte er es sein, dann Gnade Vivado-Nutzern Gott.
Gast #7259643
Lesenswert?

In der Fragestellung steht nix zu Soft CPU. Es geht drum Vivado und 
Quartus zu vergleichen auf verschiedenen CPUs.

Wenn man das machen will, dann braucht man ein möglichst identisches 
Design das keine FPGA Eigenheiten von Intel/AMD verwendet. Also keine 
IP. Und dann wählt man zwei möglichst gut vergleichbare FPGAs (Anzahl an 
LUTs und Speedgrade) und setzt gleiche Constraints.

Wenn du hier ein Design mit einem minimal konfigurierten uBlaze gegen 
ein Design mit einem maximal konfiguriertem Nios vergleichst oder einmal 
einen Takt von 100 MHz und ein andermal einen Takt von 50 MHz constraint 
hast, dann brauchen die Toolchains natürlich unterschiedlich lange.

Will sagen: Aussagen haben nur einen Wert wenn man ein fast identisches 
Design verwendet oder die mehreren Designs herzeigt die man da verwendet 
hat. Dann kann man nämlich draufgucken und selber zu einem Schluss 
kommen ob das ein fairer Vergleich war.
Gast #7259657
Lesenswert?

Weil deine Antwort keinen Aussagewert hat.
Entweder das sind fast identische Designs, dann hätte das einen 
Aussagewert, aber weil du den nios erwähnt hast ist das wohl nicht der 
Fall.
Oder du zeigst welche zwei Designs da verwendet wurden.

Ein Test ohne Angabe zu den Testbedingungen ist sinnlos.
Das ist wie ein Wettrennen mal mit Adidas mal mit Nike Schuhen und der 
Typ mit den Nike ist immer Faktor zwei schneller.
Nur wurde nicht gesagt, dass der auch eine kürzere Strecke läuft.
Gast #7260349
Lesenswert?

-gb- schrieb:
> Typ mit den Nike ist immer Faktor zwei schneller.
In der Tat sind Läufer mit Nikeschuhen um die 0,6% schneller. Das liegt 
an der Carbon-Feder-Technik, die einige Schuhe drin haben, welche aber 
nur den ausgesuchten Nike-Langläufern zur Verfügung stehen. Dieser 
Vorteil macht auf der Marathonstrecke rund 45 Sekunden aus.

Zurück zum Thema:

Es sollte möglich sein, ein Natives Design ohne die Spezialitäten der 
Hersteller zu benutzen und die Überkreuztests machen zu lassen:

PC mit AMD-CPU + Xilinx Vivado
PC mit AMD-CPU + Intel Quartus
PC mit Intel-CPU + Xilinx Vivado
PC mit Intel-CPU + Intel Quartus
#7260538
Lesenswert?

tipp schrieb:
> Natives Design ohne die Spezialitäten der
> Hersteller zu benutzen und die Überkreuztests machen

Exakt! Müsste nur Jemand machen. Und dann müsste man Ergebnisse 
einsammeln, eine Tabelle pflegen und das irgendwie so, dass die Benutzer 
die man testen lässt nicht betrügen.

Erstmal ist die Frage:

Welches Quartus und welches Vivado? Die Gratisversionen die dann 
langsamer sind oder jeweils die kostenpflichtige Version? Daraus ergibt 
sich dann auch die Frage nach den FPGAs die man vergleichen will.
Und was will man überhaupt vergleichen? Den kompletten 
Toolchaindurchlauf oder nur einen Schritt von Synthese, P&R, Assembler?
Gast #7260940
Lesenswert?

Ich habe ein Projekt aufgrund des FPGAs Mangel auf mehrere Plattformen 
portiert. Erfahrung: Vivado=Grusel. Efinix, Altera=Gleichwertig. Jetzt 
kommt da gleich wieder ein „gb“ um die Ecke der findet, dass diese 
Erfahrungen nicht ausreichend sind. „gb“, die Pfeiffe, ist wieder 
einmal, hier leider oft vorkommend, eine pfeiffe, die keine erfahrung 
oder expertise hat und nur einfach mal was schreiben will.
#7261529
Lesenswert?

-gb- schrieb:
> und dann
> wenn du das gut findest machst du ein öffentliches Repo auf und pflegst
> eine Tabelle mit den Ergebnissen die dir die Benutzer zuschicken.

Ich liefere gerne Ergebnisse zu Libero/Libero SoC vs. Vivado.

Knusper Knusper Knatsche, wer knabbert an meiner D schrieb im Beitrag 
#7256994:
> Und die Rechenzeit halbiert sich
> ohenhin aller zwei Jahre, dank dem Moore sein Gesetz.

Nein, die theoretisch verfügbare Rechenleistung verdoppelt sich (Weil 
sich die Transistor Anzahl verdoppelt - Das sagt die Beobachtung von 
Moore aus). Seit etwa 10 Jahren steigt die single-thread Performance 
kaum noch, nur die Anzahl Kerne/Threads steigt (und entsprechend die 
gesammt Rechenleistung). Und genau da ist das Problem mit den 
Simulations, Synthese und P&R Tools, die laufen bis heute hauptsächlich 
single threaded. Questa kann multithreaded Simulieren, wenn man die 
Partitionierung als Entwickler selber macht (ist jedenfalls mein letzter 
Stand). Alle Tools können mehrere P&R Versuche parallel machen, aber 
jeder einzelne bleibt single-threaded.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren