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.
Aber egal… Dieser Link. eschreibt das Disaster hervorragend: https://zipcpu.com/zipcpu/2019/02/09/cpu-blinky.html
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.
Und so-ganz nebenbei. Am AXI kommst Du nicht vorbei. Völlig ungeeignet. Leider.
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.
Und siehe da https://docs.xilinx.com/api/khub/maps/2YbsAuBf7Fni7AIl_5bCZg/resources/PuL2u5s3pnsQBleh8K9LiA/content?Ft-Calling-App=ft%2Fturnkey-portal&Ft-Calling-App-Version=4.0.20&filename=X25618-pg051_c1_block.jpg das langsame AXI lite ist nur für einfache Hausmeistertätigkeiten gedacht. Die Daten kommen und gehen über AXI Stream.
…und die kompilierzeiten. mir fehlt geradezu mich wiederins bett zu legen, wenn ich „bitstream“ ergeugen will🤓
Lass gut sein. Du hast offensichtlich nichts mit komplizierten IPS zu tun. Dennoch danke!
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.