Hallo,
leider musste ich notgedrungen von Altera auf Xilinx wechseln. Naja, der
nächste Wechsel steht schon wieder bevor🙂. Aufgefallen ist mir, im
Gegensatz zu Quartus, dass Vivado ewig rumrechnet und die Performance,
in diesem Falle Microblaze, wirklich unterirdisch ist. Performance
Cyclone 4xx vs xc7axx 2:1. Kosten 1:2. Wird sich das nervige
rumgeschiebe von Bildchen in Vivado durchsetzen? Ich auf jeden Fall,
erreiche mit Vidvado und diesem unsäglichen AXI4-Bus nicht mehr die
Performance, die Ich mit uralten Cyclones und Nios2 erreicht habe. Geht
Euch das ebenso?
Wenn du Microcontroller vergleichen willst, dann musst du auch sagen wie
du die konfiguriert hast. Den uBlaze kann man auch klein und langsam
bauen.
Und zu dem Bildchen rumschieben:
Das muss man zum Glück nicht machen, man kann wie auch bei Altera/Intel
das HDL selber schreiben und so die volle Kontrolle behalten.
Danke für Deine Antwort. Nein, mit Mikrocontrollern hat in meinem Fall
nichts zu tun. Für Xilinx scheint mir das ne tolle Sache zu sein. Ich
flansche an einen Soft-Soc einen universellen Bus. So wie den AXI4. Der
Avalonbus hat Latenzen, ich weiss jetzt nich, 1 bis 2 oder 3 beats. Der
Axi auf einmal 20 cyclen. allein der zugriff auf den temac(Ethernet-mac)
dauert ewig. das kompilieren dauert ewig. das baugeil ist sauteuer. Bin
ich echt alleine?
Ich schrieb:> Danke für Deine Antwort. Nein, mit Mikrocontrollern hat in meinem> Fall> nichts zu tun. Für Xilinx scheint mir das ne tolle Sache zu sein. Ich> flansche an einen Soft-Soc einen universellen Bus. So wie den AXI4. Und verdiene
mir eine goldene Nase. Der
> Avalonbus hat Latenzen, ich weiss jetzt nich, 1 bis 2 oder 3 beats. Der> Axi auf einmal 20 cyclen. allein der zugriff auf den temac(Ethernet-mac) beim
Xilinx
> dauert ewig. das kompilieren dauert ewig. das baugeil ist sauteuer. Bin> ich echt alleine?
Ich schrieb:> Nein, mit Mikrocontrollern hat in meinem Fall nichts zu tun.Ich schrieb:> die Performance, in diesem Falle Microblaze, wirklich unterirdisch ist.
Was denn nun? Der uBlaze ist ein Mikrocontroller. Nur eben im FPGA.
Ich schrieb:> Der Axi auf einmal 20 cyclen.
Da fehlen einfach Details. Axi kann auch mit deutlich weniger Takten
Daten schaufeln.
Ich schrieb:> das kompilieren dauert ewig.
Das ist leider so bei großen FPGAs um das mit Altera/Intel zu
vergleichen wäre jetzt interessant welche FPGAs du vergleichen willst.
Der dickste xc7a ist eben sehr fett. Und dann wären auch die Designs
interessant denn wenn die das FPGA gut füllen wird es langsam.
Ich schrieb:> das baugeil ist sauteuer.
Ja so ist das, ist vermutlich ein dickes FPGA und aktuell sind die
schlecht verfügbar und daher noch extra teuer.
Ich schrieb:> Cyclone 4xx vs xc7axx
Wenn du die vergleichen willst dann ist das womöglich unfair, der
dickste Artix7 ist ca. doppelt so dick wie der dickste Cyclone4. Klar
kostet der dann ne Ecke mehr.
Ach herrje. Nichts liegt mir ferner, als einen Kriege auszulösen. Nein,
ich vergleiche schon ähnliche Baugeile. Wo bisher ein ep4c30 musses nun
ein xc7a35 sein. bei deutlich schlechterer Performance. Ich verstehe
schon Xilinx. Öffne den Markt mit …(alleine das axi interafce ding)
zusammen klickbaren modulen und verkaufe die entsprechend riesigen
fpgas.
Keine Sorge, bin auch Pazifist.
Ich schrieb:> Wo bisher ein ep4c30 musses nun ein xc7a35 sein. bei deutlich> schlechterer Performance.
Das ist leider weiterhin sehr schwammig. Was verstehst du unter
Performance? Wie ist der Nios2 und wie der uBlaze konfiguriert? Ja die
kann man jeweils auch so konfigurieren dass die langsam sind.
Ich schrieb:> alleine das axi interafce ding
Ist eben ein Standard und auch nicht von Xilinx sondern von ARM. Und man
muss es nicht nutzen. Man kann weiterhin alles schön in eigenem HDL
machen. Ein Interface hin zu AXI schreiben ist auch nicht schwer. Dann
kann man auf seinen eigenen Bus oder nach Whishbone, ... gehen.
Ich schrieb:> verkaufe die entsprechend riesigen fpgas.
Die ich gerne fülle. Ganz ohne uBlaze und AXI Kram.
Nios2 liefert mir die Performance. Mit Avalon erreiche ich bei schreiben
tatsächlich 1:1. Beim Microvlaze bin ich eher bei 15 zu 1. Wie gesagt.
Ich will damit Geld verdienen. Hast Du ein Lösung, immer gerne her
damit😎
Sorry. Musste wieder den VPN wechseln.
> verkaufe die entsprechend riesigen fpgas.
Die ich gerne fülle. Ganz ohne uBlaze und AXI Kram.
Und die IPs sind alle von Dir? Ok, ich kenne Deinen Job nicht, aber ich
habe, zumindest hoffe ich es, einen Weg weg von Vivado gefunden. Aber
wie gesagt. Das ist kein haten sondern nur Meinung.
Ich schrieb:> Dieser Link. eschreibt das Disaster hervorragend:
Ist das jetzt Kritik am GPIO Controller? Dann schreibe selber einen.
Aber ja, wie auch da in einem der weiteren Links steht:
Dafür sollte man Logik und keine CPU verwenden.
Ich schrieb:> Nios2 liefert mir die Performance.
Du hast immer noch nicht definiert was du mit Performance meinst.
Fließkommarechnungen je Zeiteinheit wäre typisch um die Performance
einer CPU zu messen.
Ich schrieb:> Mit Avalon erreiche ich bei schreiben tatsächlich 1:1.
Was meinst du mit 1:1? 1:1=1. Du meinst wohl was wie Preis : Leistung.
Aber was steht bei dir links und rechts? Eine Zahl ist da nutzlos.
Ich schrieb:> Ich will damit Geld verdienen.
Dann hättest du das vorher simulieren und dich für die aus deiner Sicht
optimale Lösung entscheiden können. Oder ein Evalboard kaufen und
ausprobieren.
Jedenfalls kann AXI durchaus schnell sein und den uBlaze kann man sich
konfigurieren. Und man kann sogar andere CPUs nehmen, es herrscht kein
Mangel an Softcores.
Ich schrieb:> Und die IPs sind alle von Dir?
Privat ja, beruflich teilweise. Aber was heißt schon IP? Man hat eine
Aufgabe die man lösen will und dann schreibt man die passende Hardware.
Gerade bei Signalverarbeitung kann das recht schnell umfangreich werden
und auch dicke FPGAs füllen. Als IPs verpacke ich das nicht, ist eben
ein gewachsener Zoo aus vielen VHDL Dateien.
Ich schrieb:
> Dieser Link. eschreibt das Disaster hervorragend:
Ist das jetzt Kritik am GPIO Controller? Dann schreibe selber einen.
Aber ja, wie auch da in einem der weiteren Links steht:
Dafür sollte man Logik und keine CPU verwenden.
Nein, ist ist Kritik an der Umsetzung. Über dieses Interface muss ich
leider mit demTEMAC und dem DMA Controller kommunizieren. Hölle. Egal.
Wenn Dich das nicht betrifft isses ja ok.
Ich schrieb:> Über dieses Interface muss ich leider mit demTEMAC und dem DMA> Controller kommunizieren.
Ich kenne den Temac nicht, vermutlich ist das AXI da aber nur das
Interface um irgendwas zu steuern und einzustellen, die schnellen Daten
kommen doch sowieso nicht aus einem Softcore?!
Ich schrieb:> Am AXI kommst Du nicht vorbei. Völlig ungeeignet.
Doch, da kommt man prima dran vorbei wenn man auf IPs mit AXI
verzichtet. Aber AXI kann eben auch schnell sein, sehr schnell. Mehrere
GBytes/s sogar nur eben nicht aus einem Softcore heraus.
Wishbone oder Avalon…das wäre eine Lösung. Stattdessen muss man sich mit
nem 100MHz (ja, Deiner läuft mit 130) rumärgern, weil jeder verfluchte
Zugriff etliche Takgzyklen dauert.
Egal.Ich muss halt mit IPs arbeiten die vorhanden sind. Meine Probleme
enstehen erst durch dieses Gexöns, was Xilinx natürlich, wenn man sie
wiederkaufen kann, ordentlich kohle bringt. egal. ich bin geradezu back
to the roots und schreibe einen dma controller. erstaunlich, mit wie
wenig le man auskommt.
Ich schrieb:> Ich auf jeden Fall,> erreiche mit Vidvado und diesem unsäglichen AXI4-Bus nicht mehr die> Performance, die Ich mit uralten Cyclones und Nios2 erreicht habe. Geht> Euch das ebenso?
Nö, du bist halt zu blöde für Xilinx. Du kriegst ja nichtmal hin,
konkrete Angaben zum verwendetetn Nios-typ Taktfrequenz und Performance
zu machen.
Und wenn Du AXI nicht magst kannst auch einen Standalone mikroblaze
nehmen
https://www.mikrocontroller.net/articles/Xilinx_Microblaze_MCS_Workflow
Ich schrieb:> …und die kompilierzeiten. mir fehlt geradezu mich wiederins bett zu> legen, wenn ich „bitstream“ ergeugen will
Synthesezeiten von reichlich bis zu acht Stunden hatte ich auch schon
bei einem Projekt. Da hat abends der Letzte die Synthese angestoßen und
früh der Erste die FPGAs mit neuen Files bespielt.
Der Ansatz: ein Bit ändern, Synthese starten und schauen ob es geht,
klappt dann natürlich nicht mehr...
Duke
Liegt ganz massiv am verwendeten PC. Ein Run bis zum Bitfile dauert auf
meinem neuen Labor-PC mit i9-12900 jetzt nur noch 10 statt vorher 45 min
auf dem ollen i7-6700. Und nicht vergessen, die Nutzung der parallelen
CPU Cores einzustellen.
Christian R. schrieb:> Liegt ganz massiv am verwendeten PC.
Wir hatten damals schon die schnellsten Rechner genutzt, die man
bezahlen konnte. Parallelisierung ging mit ISE nicht, war aber egal, da
eh mehrere FPGA-Images gebaut werden mussten.
Ja, heute würde dieses Projekt bestimmt schneller bauen, aber heute
würde man auch wieder ein größeres FPGA nehmen (und evtl. nicht
mehrere). Oder man würde mehr Funktionen reinpacken...
Am Ende wird das Mehr an Rechenleistung doch wieder aufgefressen :-)
Duke
Christian R. schrieb:> Ein Run bis zum Bitfile dauert auf> meinem neuen Labor-PC mit i9-12900 jetzt nur noch 10 statt vorher 45 min> auf dem ollen i7-6700. Und nicht vergessen, die Nutzung der parallelen> CPU Cores einzustellen.
4:1?
Das lässt sich aber sicher nicht durch die Rechengeschwindigkeit und
auch nicht mit der Zahl der Cores erklären. Sicher, dass das Werkzeug
dasselbe war, also dieselbe Version?
Ich würde vermuten, dass es in so einem krassen Fall, die RAM-Resourcen
sind, also Menge und Zugriffsgeschwindigkeit. Irgendwelche SSDs im Spiel
die auf RAM gespiegelt wurden?
Was haben denn die beiden Rechner für Leistungsindexwerte?
Ralf schrieb:> 4:1?
Naja ... 30 MByte vs. 8 MByte Cache und gleichzeitig 5,1 Ghz vs. 4 GHz
jeweils im Turbo und gut die doppelte Speicherbandbreite.
Aber was bringt denn wirklich die Bestleistung?
Ist es sinnvoll eine CPU mit vielen Kernen und hohem Maximaltakt wie den
i9-13900k zu kaufen?
Der hat im Turbo 5,8 GHz, die kann der bei Last auf allen Kernen
vermutlich nicht lange halten, aber vielleicht machen Vivado/Quartus
eher viel Last auf wenigen Kernen und die takten dann dauerhaft auf dem
hohen Turbotakt.
Und dann haben CPUs mit vielen keren oft auch viel Cache. Zwar nicht je
Kern, aber L3 der geteilt wird und deutlich schneller angebunden ist als
das DRAM.
Und dann haben manche CPUs mehrere Speichercontroller. Werden die
parallel wie ein RAID0 genutzt oder kann man dadurch die Schreibrate
nicht steigern?
Ralf schrieb:> Christian R. schrieb:>>> Ein Run bis zum Bitfile dauert auf>> meinem neuen Labor-PC mit i9-12900 jetzt nur noch 10 statt vorher 45 min>> auf dem ollen i7-6700. Und nicht vergessen, die Nutzung der parallelen>> CPU Cores einzustellen.>> 4:1?> Das lässt sich aber sicher nicht durch die Rechengeschwindigkeit und> auch nicht mit der Zahl der Cores erklären. Sicher, dass das Werkzeug> dasselbe war, also dieselbe Version?> Ich würde vermuten, dass es in so einem krassen Fall, die RAM-Resourcen> sind, also Menge und Zugriffsgeschwindigkeit. Irgendwelche SSDs im Spiel> die auf RAM gespiegelt wurden?> Was haben denn die beiden Rechner für Leistungsindexwerte?
Ja, ich hab mich auch gewundert und das mit mehreren Designs
verifiziert. Beide PCs haben 32GB RAM und eine PCIe SSD mit 1TB. Damals
in 6700 noch auf PCIe Karte, jetzt halt direkt.
Vivado ist jeweils 2020.1 und das gleiche Design. Max parallel Threads
in Vivado jeweils auf 8.
Der 12900 ist eh erstaunlich durch bigLITTLE. Der rennt sehr gut.
Prinzipiell parallelisiert Vivado allerdings schlecht.
Leistungsindex? Gibt's das bei Windows 10 noch? Bei 7 ging das doch
schon bei unseren PCs immer auf 7,9 und mehr hat die Anzeige nicht
gekonnt.
Kai D. schrieb:> Eventuell ein richtiges benchmark-tool nehmen?
Das taugt auch nix.
Ein Computer ist nun mal in Rechenoperationen/s, Zahl der Kerne,
Speicherbandbreite und IO-Bandbreite begrenzt. Einer dieser Faktoren ist
immer das Limit. Welcher Faktor das ist, hängt von der Applikation ab.
FPGA-Synthese ist anders als Apfelmännchen und das ist wieder anders als
Ego-Shooter oder Benchmark.
Duke
-gb- schrieb:> Ist es sinnvoll eine CPU mit vielen Kernen und hohem Maximaltakt wie den> i9-13900k zu kaufen?
Das frage ich mich auch gerade:
Beitrag "64-Kerne für Simulation und Berechnungen?"
Taktgeschwindigkeit ist ja mal sicher ein Vorteil gegenüber mehr CPUs,
das merke ich bei Einzelanwendungen. Aber sehr viel ist da nicht drin.
Die sind ja alle so ziemlich am Anschlag. 5 zu 4 bringt es da wohl nicht
wirklich, auch wenn sich das gigantisch anhört.
Ich habe 3,5GHz x 12 und die werden bei Grafiksimulation voll genutzt.
Es wird nichts heruntergetaktet, das System ist mit einer
Leistungs-Heatpipe gekühlt.
-gb- schrieb:> 30 MByte vs. 8 MByte Cache und gleichzeitig
Das ist eine gute Erklärung!
Auch das Betriebssystem hat einen Einfluss auf die Geschwindingkeit des
Bauens.
Das Bauen der Images war zumindest in früheren Vivado Versionen unter
Linux deutlich schneller als unter Windows.
Selbst eine Linux VM unter Windows brachte noch Geschwindigkeitsvorteile
gegenüber dem Bauen unter Windows.
Zuletzt habe ich es aber nicht mehr so verfolgt, da meine letzten
Projekte allesamt überschaubare Buildzeiten hatten und außerdem dank
ausgiebiger Simulation nur selten FPGA Images erzeugt werden müssen.
Ich schrieb:> Disaster
D-e-saster :-)
Und es ist eigentlich keins, wenn sich mit einer CPU ein Port auf
"3,8MHz" toggeln lässt. Mit einem 12-Bit-Zugriff lässt sich so immerhin
ein komplettes UART-Bitmuster in ein externes latch schreiben und
übernehmen, das dann mit dem n-fachen Takt rausgeschoben werden kann.
Bei meiner MIDI-Lösung aus den 80ern ging das sogar mit dem damaligen
"Hochleistungs-RISC" 6502, der mit zwei Zugriffen Startbit,
8-Bit-Muster, Stops + Parity schrieb. Das Latch hatte 16 bit wurde aber
schon nach 10+1 Takten resettet. Getaktet wurde mit dem doppelten
Horizontaltakt aus dem VC20 mit rund 31 kHz, mit dem er das MIDI
rausgehauen hat. Damit gingen theoretisch 3kHz MIDI Daten raus.
Mit dem heutigen Micoblaze sind mit der gleichen Mimik 32 Bit möglich.
Bei einer Aktualisierung von 3MHz sind 100Mbit brutto seriell erzielbar.
Morph schrieb:> Zuletzt habe ich es aber nicht mehr so verfolgt
Nun, X publiziert mit jeder neuen Vivadoversion eine
Synthesezeiteinsparung von bis zu 50%. Die letzten 10 V-Versionen
sollten also den Bedarf auf 1/1000stel eingedampt haben. Wenn die so
weiter machen, ist das BIT-file demnächst fertig, bevor die Synthese
überhaupt gestartet wurde.
Jürgen S. schrieb:> Nun, X publiziert mit jeder neuen Vivadoversion eine> Synthesezeiteinsparung von bis zu 50%.
:-)
Dafür steigt die Chipfläche der verkauften Bausteine.
> Die letzten 10 V-Versionen> sollten also den Bedarf auf 1/1000stel eingedampt haben.
Für einen XC9536XL kommt das hin...
Duke
Jürgen S. schrieb:> Nun, X publiziert mit jeder neuen Vivadoversion eine> Synthesezeiteinsparung von bis zu 50%. Die letzten 10 V-Versionen> sollten also den Bedarf auf 1/1000stel eingedampt haben.
Kann man positiv sehen.
Andererseits heisst das aber ja wohl leider Gottes, dass die Burschen
seither einigermassen Mist programmiert haben. An der Problemstellung
hat sich ja wohl nichts geändert; wenn in der Software tatsächlich noch
solche "Reserven" drinstecken, liegt der Verdacht nahe.
Oder hat's da erst die AMD-Jungs gebraucht, um denen zu zeigen, wie man
das richtig macht? Dann wäre dem Merger ja tatsächlich was abzugewinnen
(kann ich bei Intel so - leider - nicht bestätigen).
Markus F. schrieb:> Andererseits heisst das aber ja wohl leider Gottes, dass die Burschen> seither einigermassen Mist programmiert haben. An der Problemstellung> hat sich ja wohl nichts geändert; wenn in der Software tatsächlich noch> solche "Reserven" drinstecken, liegt der Verdacht nahe.
Die Sache ist zweischneidig:
Ganz sicher ist es so wie du sagst, dass es da noch viel Potenzial gibt
und das hat seinen Grund in mehreren Punkten, von denen zumindest der
letzte nicht vom Hersteller zu vertreten ist:
1) Xilinx hat immer schon sehr lange sein altes Zeugs mitgeschleppt und
es nicht verstanden, eine gut funktionierende stabile SW hinzustellen,
weswegen es an der Umsetzung krankte. Man hat mit Scripten und eigenen
Definitionsn gearbeitet und zudem es nicht verstanden sich den
Betriebssystemen rasch anzupassen. Ich erinnere an die Probleme mit ISE
bei Win XP und später Win 7 sowie die DOS-ähnlichen Programmstruktur
beim Aufruf von Subfunktionen.
2) Man hat bei der Neuerung, sei es Umstieg auf Vivado oder XDCs immer
erstmal Probleme gehabt, diese neuen Strategien einzuführen. Sehr lange
hat man an der XST festgehalten, was die Firmen dazu gezwungen hat, auf
z.B. Synplifiy zu setzen.
3) Man hat im Zuge der Entwicklung der Beschreibungssprachen auch neue
mathematische Verfahren entwickelt, was die Umsetzung von virtueller
Beschreibung in HW angeht und das ist ein kontinuierlicher
Verbesserungsprozess, weswegen man auch mit denselben Möglichkeiten von
heute, eine Schaltung um 2000 nicht so gut hätte umsetzen können.
Es gibt aber noch die andere Seite der Schneide:
Die immer größer werdenden FPGAs zwingen zu einfacheren
Platzierungstechniken, um vernünftige Synthesezeiten zu erzielen, was zu
eben schlechteren Ergebnissen führen muss. Seit 15 Jahren kann man
beobachten, dass es häufiger vorkommt, dass man an alten Designs etwas
ändern muss und dann die Synthese nur mit dem alten tool es noch packt.
In der Anfangszeit musste ich sogar ein design für den Artik 100 noch
mit der ISE bauen, weil es Vivado nicht hinbekommen hat, wobei das wohl
an Punkt 2) gelegen haben dürfte.
Duke Scarring schrieb:> Dafür steigt die Chipfläche der verkauften Bausteine.
Ja und zwar offenbar zum Teil zwangsläufig aber eben z.T. auch
strategisch.
Da muss man dann mal schauen, ob im Grenzfall nicht ein Drittanbieter
das design doch ins nächst kleinere FPGA quetscht.
