Hallo zusammen Ich bin damit beschäftigt, für ein zukünftiges Projekt mögliche FPGA zu evaluieren. Die Komplexität wird im Rahmen eines bestehenden Projektes liegen, also habe ich eine schönes Testcase. Komplexität (Stratix III): - 2 DDR2 memory I/F - 91 M9K, 4 M144K - 100 DSP units - 30000 ALUT - 360 I/O Alle Runs liefen auf demselben Computer. As Is: Altera Stratix III, QII 10.1, - SysxC: 200 MHz - Synthesis/P&R time: ~26' - Time to VHDL error detect: ~13" Evaluation: Altera Cyclone V, QII 12.1sp1 64-bit WebPack - SysxC: 150 MHz - Synthesis/P&R with Altera defaults - Synthesis/P&R time: ~35' - Time to VHDL error detect: ~5" Xilinx Artix-7, Vivado 2013.1 64-bit WebPack - SysxC: 150 MHz - Synthesis/P&R with Xilinx defaults - Synthesis/P&R time: ~1h49' (!) - Time to VHDL error detect: ~26' (i.e. 1560" !) Das Design geht in beide Kandidaten rein und es hat noch einiges an Reserve. Was mich aber erstaunt ist die exzessiv hohe Synthese/P&R-Zeit, welche das Xilinx-Device in Anspruch nimmt. Des weiteren geht es nur schon elend lange, bis VHDL-Fehler (z.B. doppelt getriebener Ausgang) überhaupt gemeldet werden. Wie sind da Eure Erfahrungen? Gibt es allenfalls Default-Settings, die sofort gekippt/geändert werden müssen um "normal" arbeiten zu können? Hinkt Xilinx wirklich dermassen hinter Altera her? Bin gespannt auf Eure Erfahrungen...
Peter K. schrieb: > Das Design geht in beide Kandidaten rein und es hat noch einiges an > Reserve. Was mich aber erstaunt ist die exzessiv hohe Synthese/P&R-Zeit, > welche das Xilinx-Device in Anspruch nimmt. Des weiteren geht es nur > schon elend lange, bis VHDL-Fehler (z.B. doppelt getriebener Ausgang) > überhaupt gemeldet werden. Deshalb schickt man ja den vhdl-code zuerst durch vcom (modelsim), der ist deutlich schneller im Erkennen von VHDL-Fehlern. Gruss
Viktor Victorious schrieb: > Deshalb schickt man ja den vhdl-code zuerst durch vcom (modelsim), der > ist deutlich schneller im Erkennen von VHDL-Fehlern. Heisst für mich: Du hast kapituliert (oder machst es Dir etwas einfach mit dem Hinweis). Im Ernst: Ich benutze die Altera-Free-Variante von Modelsim, die kann keine Cosimulation und wirft Dir einen Knebel zwischen die Beine, wenn Deine Anzahl Leaf-Cells einen Grenzwert überschreitet. Block-Simu mache ich also in Modelsim (und finde da auch lokale VHDL-Fehler). System-Verifikation/Debugging mit SignalTap (mit anschliessender Bug-Reproduktion auf Blocklevel) kann ich nicht simulieren, da bin ich froh wenn die Toolchain Probleme ASAP meldet. Bei der erreichten Performance im Test graut mir vor der Xilinx-Variante, und ich hoffe inständig, dass Altera mit einem guten Preis für ihr Device aufwartet...
Peter K. schrieb: > Viktor Victorious schrieb: >> Deshalb schickt man ja den vhdl-code zuerst durch vcom (modelsim), der >> ist deutlich schneller im Erkennen von VHDL-Fehlern. > > Heisst für mich: Du hast kapituliert (oder machst es Dir etwas einfach > mit dem Hinweis). Quatsch kapitulation, ich nehme einfach die tools die für den jeweiligen Job am besten geeignet sind. Und um Syntaxfehler ode multiple driver zu finden, braucht man keine volle synthese. P&R laufzeiten lassen sich schlecht aus der ferne diagnostizieren. Nach meine Erfahrung bedarf es wenige Handgriffe um auf eine Durchlaufzeit von ca 15 min oder darunter zu kommen. Abgesehen davon, das eine P&R am tag (über Nacht) genügt. Bauteientscheidung davon abhängig zu machen wie lange Hintergrundprozesse laufen ist quatsch. Gruß,
Wir lassen den Build Prozess auf einem Teamcity Server laufen, da brauch ich lokal höchstens mal eine Synthese, aber wie schon geschrieben vcom über Notepad++ aufrufen reicht in den allermeisten Fällen für den Syntax- und Fehler-Check.
Peter K. schrieb: > Was mich aber erstaunt ist die exzessiv hohe Synthese/P&R-Zeit, > welche das Xilinx-Device in Anspruch nimmt. Das ist nicht nu bei Vivado so. Ach die ISE (alt) macht seit einigen Versionen verdächtig lange rum, bis sie was auswirft. Ist so ein Gefühl.
Alles etwas überspitzt ausgedrückt: a) Ja, die Xilinx Tools sind langsamer, die Erfahrung mache ich auch ständig. Wird aber fast jeder hier abstreiten, sind auch 80-90% Xilinx Nutzer. b) du machst es unnötig schwer, weil du ein bereits auf Altera optimiertes Design verwendest c) das ist auch der Grund warum nur wenige den Hersteller wechseln d) wenn das kein Pipifax Design ist, dann würde ich bei der Größe IMMER eine komplette Simulation machen. Wenn dir Modelsim dafür zu teuer ist, dann ist schon zu 100% klar welches FPGA du nehmen wirst: den Xilinx Baustein mitsamt ISIM. e) Synthese wird nur genutzt um zu sehen ob dort das gleiche passiert wie in der Simulation. Signal Tap eignet sich allenfalls als langsames Debugging (ups, hab Signal xy bei der Synthese vergessen anzuschließen, also nochmal...), keinesfalls aber zur Verifikation. f) daraus folgt das Synthesezeiten nicht so wichtig sind, sie testen nur ob deine Simulation gut war. g) Bei mir hat das alles schon oft dazu geführt das ich lieber eine Synthese starte, weil das auf einem kleinen Cyclone schön schnell geht, als vernünftig zu simulieren => schwerer Fehler. Eine Simulation hält für immer, auch noch in 10 Jahren. Ein Syntheseergebnis kannst du schon nach einer Woche selbst bei bester Versionskontrolle kaum noch bewerten.
Simulant schrieb: > b) du machst es unnötig schwer, weil du ein bereits auf Altera > optimiertes Design verwendest Nein. Habe mir die Mühe genommen, sämtliche IP Cores (RAMs, MemCtrl, PLL, DCM, CORIC, MACs, fast Input Registers, etc.) auf Xilinx umzusetzen. Abgesehen davon war das Vor-Vorgänger-Projekt auch schon mal auf Xilinx. > f) daraus folgt das Synthesezeiten nicht so wichtig sind, sie testen nur > ob deine Simulation gut war. Falsch. Ich meine hier auch nicht die Simulation vom "Grundverhalten". Das Debugging von Fehlermeldungen aus Feldtests (soweit sie nicht relativ einfach durchschaubar sind) geht bei mir zur Zeit in etwa so: 1) Triage mit dem Signaltap, um die Fehler-Quelle zu lokalisieren. 2) Vollständige SignalTap-Instrumentation der I/O des "bösen" Blocks. 3) Reproduktion des Verhaltens in der Simulation & Korrektur. 4) Einfügen in die Block-Regression-Tests Dieses Vorgehen ist bei Events, die nach langer Zeit und Sensor-Daten-abhängig auftreten bei weitem die effizienteste Methode. > d) wenn das kein Pipifax Design ist, dann würde ich bei der Größe IMMER > eine komplette Simulation machen. Wenn dir Modelsim dafür zu teuer ist, > dann ist schon zu 100% klar welches FPGA du nehmen wirst: den Xilinx > Baustein mitsamt ISIM. Nicht ganz. Es sind ja die Xilinx-Rechenzeiten, die zur Diskussion stehen (mit der Altera-Lösung wäre ich ganz zufrieden, nur graut mir etwas vor der kommerziellen Entscheidung). Auch mit einer komplett-Simulation wird man nicht auf "Real-Case-Fallen" (wie oben beschrieben) verzichten wollen.
Ich arbeite seit 10 Jahren mit FPGAs und vor allem mit Altera. Wenn der Kunde Xilinx gewünscht hat, dann wurde eben auch auf Xilinx implementiert, aber ich vermied es wie es nur möglich war. Xilinx war für mich (ist schon Jahre her) sehr träge, zu viele spezielle Griffe waren notwendig, zu viele Tools buggy (MIGs der ersten Generation). Da fragte ich mich immer, wie man da überhaupt was vernünftiges machen konnte. Denke aber, dass wenn man sich auf einen Hersteller einschießt, dann kommt man mit dem auch gut zu recht. Was Compiler/Synthese/Fitter-Zeiten angeht, muss ich schon gestehen, dass ich von Altera positiv überrascht bin. Mittlerweile merke ich, dass mit dem neuesten Quartus wirklich alle Kerne ausgelastet werden und es einfach zügiger geht, als mit den älteren Versionen. Die Designs, die ich mache sind von klein bis sehr komplex. Ich simuliere nur, wenn ich gerade from scratch anfange und wenn es erstmal läuft, dann verzichte ich darauf meist. Ich kann sogar sagen, wenn ich erstmal ein Design erfolgreich simuliert habe und das erste Mal synthetisiert, dann simuliere ich nicht mehr :-o Die restliche Fehler (und die gibt es zu genüge) löse ich durch systematisches Nachdenken und wenn ich nicht weiter weiß auch mit Signal-Tap. So eine z.B. Video-Pipeline, NIOS, DDR2-Speicher, diverse I2C/SPI und UART-Protokolle klicke ich einfach zusammen und in 90% der Fälle funktioniert es auch sofort. Spätestens bei der zweiten Synthese läuft dann alles. Und noch was: wenn ich simuliere, dann sind die Entitys klein genug, dass ich die auch mit ModelSIM Starteredition simulieren kann. Vielleicht bin ich noch nicht in die Regionen vorgedrungen, dass ich auch Timingsimulationen machen soll, aber bis jetzt habe ich das noch NIE gebraucht. Wenn alles gut constraint ist und die Tools mir sagen, dass da keine "Violations" haben, was soll mir so eine Timingsimulation bringen? Ein glücklicher Altera-User Kest
Hast Du bei deinem Altera-Design evtl. Placement-Constraints o.Ä. verwendet, die in deinem Xilinx-Design nun nicht zur Verfügung stehen? Du sagst, dass Du alle IP-Cores von A nach X modifiziert hast. Ohne Simulation?
Dr. Schnaggels schrieb: > Hast Du bei deinem Altera-Design evtl. Placement-Constraints o.Ä. > verwendet, die in deinem Xilinx-Design nun nicht zur Verfügung stehen? Keine selbstdefinierten (die DDR2 Controller verwenden natürlich welche, aber die sind ja dann vom entsprechenden Vendor definiert). Ansonsten habe ich noch false/multicycle_paths welche korrekt portiert sind. Die Pads lasse ich die Tools selber auswählen (Ausnahme DDR2-Memory, wo ich die Vendor-Default-Constraints einsetze) > Du sagst, dass Du alle IP-Cores von A nach X modifiziert hast. Ohne > Simulation? Ja, natürlich, es sind ja nur Tool/Freq/FPGA-Fit-Test-Runs. Das muss reichen, zumal das Design sowieso nicht 1:1 portiert wird, sondern als Benchmark für ein zukünftiges mit ähnlicher Komplexität dient. Ich generiere jeweils den IPCore-Block mit demselben Interface wie bisher. Wenn sie nicht weggekürzt werden, ist schon mal nicht schlecht. Clocks werden alle mit der richtigen Frequenz rapportiert, also auch gut. Als Benchmark bezüglich Timing habe ich 9 verschieden Pfade (Pfadgruppen) definiert, die repräsentativ sein sollen und welche im Original-Design kritisch waren.
Simulant schrieb: > d) wenn das kein Pipifax Design ist, dann würde ich bei der Größe IMMER > eine komplette Simulation machen. Wenn dir Modelsim dafür zu teuer ist, > dann ist schon zu 100% klar welches FPGA du nehmen wirst: den Xilinx > Baustein mitsamt ISIM. Kest schrieb: > Ich kann sogar sagen, wenn ich > erstmal ein Design erfolgreich simuliert habe und das erste Mal > synthetisiert, dann simuliere ich nicht mehr :-o Die restliche Fehler > (und die gibt es zu genüge) löse ich durch systematisches Nachdenken und > wenn ich nicht weiter weiß auch mit Signal-Tap. Schön wie hier verschiedene Welten aufeinandertreffen. In meiner Welt ist die flexibilität und der Zeitbedarf auch der ausschlaggebende Punkt. Ganz einfach weil Fehler im FPGA Design viel zu hohe Kosten verursachen. Aber es ist auch klar, dass nich jeder einen FPGA hat der an 8*4 Leistungs-IGBTs (600 V, 300 A) dranhängt. Da simuliert man freiwillig (und freiwillig auch die volle timing simulation vor jedem Release). Peter K. schrieb: > Falsch. Ich meine hier auch nicht die Simulation vom "Grundverhalten". > Das Debugging von Fehlermeldungen aus Feldtests (soweit sie nicht > relativ einfach durchschaubar sind) geht bei mir zur Zeit in etwa so: > 1) Triage mit dem Signaltap, um die Fehler-Quelle zu lokalisieren. > 2) Vollständige SignalTap-Instrumentation der I/O des "bösen" Blocks. > 3) Reproduktion des Verhaltens in der Simulation & Korrektur. > 4) Einfügen in die Block-Regression-Tests Das sind genau die Fälle, die genau ein solches Vorgehen verlangen, ich finde das gut so. Genau da bin ich auch froh, dass es all die schönen Tools (SignalTap, Chip Scope, Reveal) gibt. Die Software Leute nennen das "Defect Driven Testing" = Fehler beheben und sicherstellen, dass er in Zukunft nie mehr auftreten kann (da darauf getestet wird).
Das müssen dann aber ziemlich triviale Fälle sein... Bei uns gibt es 4 Ebenen der Entwicklung. - Simulation - FPGA Register Tests auf der HW - Softwareabteilung - (interne) Anwender Mit jeder Stufe, behaupte ich, etwa verzehnfacht sich der Gesamtaufwand pro Bug. - Brauche ich 15 Minuten zum Debuggen eines Fehlers in der Simulation - sind es locker 3 Stunden nach der Synthese (Synthese alleine sind 2 std) - zur Softwareabteilung sind es locker 24 Mannstunden, allein der Abgleich mit den Kollegen + neue Version + Fixzeit gibt problemlos 3 Manntage. - Zu den Anwendern ists nochmal viel länger. Die können gar nicht einschätzen welcher Fehler das ist und wo der her kommt. Also wird gesucht wie man ihn Reproduzieren kann. Dann kommt die Softwareabteilung und sieht es sich an, wenn sie nichts finden können gehts zum FPGA Entwickler. Hier vielleicht nichts Faktor 10, aber 10 Manntage kommen da doch raus. Fazit: investiere ich 5 Tage in sinnvolle Simulation die auch nur EINEN Fehler findet spart das immer noch Zeit. Typischerweise findet man aber in 5 Tagen mehr als einen Fehler. Aber natürlich beherrschen wir alle die Fehlerfreie Programmierung. Da reicht ja schon ein 2 Tages Kurs: http://www.modulo3.de/test/seminare/entwicklung/fehlerfreie_programmierung.html
Hallo Simulant, hast Du den modulo3-Kurs schon besucht? Und?
Simulant schrieb: > Das müssen dann aber ziemlich triviale Fälle sein... > > Bei uns gibt es 4 Ebenen der Entwicklung. > - Simulation > - FPGA Register Tests auf der HW > - Softwareabteilung > - (interne) Anwender > > Mit jeder Stufe, behaupte ich, etwa verzehnfacht sich der Gesamtaufwand > pro Bug. Jetzt interessiert es mich wie ihr durch so viele Stufen die Dokumention durchhaltet? Zum Debuggen von VHDL gibt es eine schöne Seite http://www.stefanvhdl.com/
Als Nachtrag: Vivado (2013.1 64-bit) benutzt als Default maxThreads = 2. Setzt man das auf 4 (natürlch nur wenn die Cores auch vorhanden sind) wird zumindest P&R etwas schneller (mein Testdesign war danach knapp 25% schneller, aber immer noch Faktor 3 langsamer als Altera).
1 | set_param general.maxThreads 4 |
Entweder im *.tcl oder in der Commandline, im GUI habe ich es nicht gefunden.
Ist das wirklich ein reines VHDL oder sind da Cores verwendet? Altera hat mit einen Cores sehr viel vorbereitet. Infolge der einfacheren Logikstrukur gibt es besonders bei DSP-Funktionen bei Altera-Bausteinen weniger zu optimieren und es wird geradeaus gezimmert. Das könnte Xilinx auf Dauer ziemlich übel aufstossen, wenn die Designs immer mächtiger und die Synthesezeiten wichtiger werden. Ich befasse mich seit Kurzem wieder mit Vivado und ich sehe, dass es deutlich langsamer ist, als ISE :-(
Thomas Ulrich schrieb: > Ich befasse mich seit Kurzem wieder mit Vivado und ich sehe, dass es > deutlich langsamer ist, als ISE :-( Kann ich zumindest hier nicht bestätigen. Ich musste zwei Projekte von ISE in Vivado portieren, weil es ja für ISE nix neues mehr gibt. Beides Artix 7 mit MGTs, viel Block RAM Sachen usw, recht gut gefüllt. Unter Vivado ist das BitFile viel schneller fertig als in ISE (30 min gegenüber 50 min). Gleiche Projekteinstellungen und ohne GUI, also alles per Konsole. Das geht mit Vivado wirklich besser. run_synth1, run_imp1, write_bitstream. Fertig.
Christian R. schrieb: > Das geht mit Vivado wirklich besser. Schade nur, dass Vivado nur für die 7er Serie ist und die "kleinen" FPGAs noch nicht verfügbar sind (XC7A35T oder maximal XC7A50T). Genauso fehlen die Automotive-Versionen. Und PlanAhead (wohl ähnlich wie Vivado) trotz Intel Core-i7 Power eher sehr träge ist.
Bei mir ist Vivado (mit GUI) zumindest etwas schneller als ISE. Aber dafür dass Xilinx alles neu implementiert haben will ist es jetzt auch nicht so wahnsinnig viel. Und ich wundere mich noch immer, dass generell nicht noch viel stärker an der Performance der Tools optimiert wird... da verbringen ja auch die Mitarbeiter von Xilinx viel Zeit mit bei der Arbeit, bringt da dann auch direkt Vorteile wenn alles schneller läuft. Und die Kunden würden auch jubeln... Kann man die Algorithmen nicht (wenigstens teilweise) mit ner modernen GPU beschleunigen? Ach ne, wäre ja Ketzerei** - OK also mit einem FPGA beschleunigen? ;-) ** Aha... jetzt weiss ich warum das noch keiner der FPGA Hersteller gemacht hat: das wäre ja Werbung für GPUs! :->
Thomas Ulrich schrieb: > Ist das wirklich ein reines VHDL oder sind da Cores verwendet? Nein natürlich nicht, die untenstehenden Items sind alle mit Cores (instanziertes Blockmemory, I/F controller, instanzierte MAC, MULTADD): P. K. schrieb: > - 2 DDR2 memory I/F > - 91 M9K, 4 M144K > - 100 DSP units Ich habe bei der Migration von Stratix III nach Arria V (Xilinx hat, nicht zuletzt auch wegen des langsamen Tools vorerst den kürzeren gezoghen) nun alles ausser TGEN und MEM I/F inferiert. Werde das dann auch mal auf Artix 7 anwenden, wenn mal gerade nicht soviel los ist...
Sorry fürs ausgraben aber ja, kann ich bestätigen. Wollte mich jetzt die letzten Tage mal intensiver mit Vivado anfreunden aber ... NEIN! Habe nur ein paar kleine FSMs drinnen die mit LEDs verbunden sind, kein RAM, nix mit viel Mathe und trotzdem dauert es irre lange bis aus dem VHDL das Bitfile ferig ist. ISE ist um Welten schneller und auch das fand ich schon langsam ...
weiss nicht, ob's hier relevant ist, aber wenn Ihr unter Windows arbeitet, verbraten die Xilinx-Tools (und auch Lattice) eine Menge Rechenzeit nur für die GUI. Unter Linux ist's fast Faktor 2 schneller, und wenn man die Synthese direkt per Kommandozeile aufruft (Makefiles) ist es nochmal eine Ecke flotter. Nur so als Input..
-gb- schrieb: > Sorry fürs ausgraben aber ja, kann ich bestätigen. Wollte mich jetzt die > letzten Tage mal intensiver mit Vivado anfreunden aber ... NEIN! Naja bei der 7er Serie hat man nicht viel Alternative. > Habe nur ein paar kleine FSMs drinnen die mit LEDs verbunden sind, kein > RAM, nix mit viel Mathe und trotzdem dauert es irre lange bis aus dem > VHDL das Bitfile ferig ist. ISE ist um Welten schneller und auch das > fand ich schon langsam ... Hast du mal einen Direkt Vergleich gemacht? Ich kann das nämlich nicht direkt bestätigen, unter ISE dauert es auch lange bis ein A7 200 Bit File rauskommt. Da ist kaum Unterschied zu Vivado. Ich lasse aber direkt in Vivado meist nur die Synthese laufen, dann kommt alles ins SVN und der Build läuft dann auf einem TeamCity Build Server. Aber auch lokal kann ich mich da mit meiner HP Z620 auch nicht direkt beschweren...Vivado kann im Gegensatz zu Ise wenigstens mal Multi Threading. Ich hab das per TCL beim Startup auf 8 Kerne gesetzt da gehts recht flott.
Direkt vergleichen habe ich das nicht, aber jetzt im Artix 100 habe ich ein echt kleines Design nur zum ausprobieren und selbst wenn ich nur einen Switch mit einer LED verbinde braucht das deutlich lange. In ISE hab ich mit kleinen Spartan3/6 Zeug gemacht, das wurde auch lahm bei großen Designs aber bei so kleinem Zeug ist das schnell. Liegt das garnicht an der Komplexität des Designs sondern am verwendeten FPGA?
Ja, je größer das FPGA desto länger dauert das, auch wenn gar nix drin ist. Lass man ein Virtex 5 oder Spartan 6 Dedign in ISE laufen, das zieht sich auch. Ich kann ja bei Gelegenheit mal ein mini Design direkt vergleichen.
Oh nein!!! Habe ein Stratix 2 Board mit EP2S180 bei eBay erworben, hätte ich doch was kleineres genommen ... ohje Wieso ist das so und: Kann man das irgendwie einstellen wie lange das dauert? PAR ist oft irgendwie iterativ oft durchgelaufen und schon nach einem frühen schnellen Durchlauf stand da 0 unrouted, hat aber trotzdem noch lange optimiert. Kann man das aussschalten?
-gb- schrieb: > Wieso ist das so Mal anschaulich gesprochen: Stell Dir das FPGA als eine Straßenkarte vor. Eine Route innerhalb von Berlin zu berechnen geht schneller als von Lissabon nach Wladiwostok (13735km und 154h sagt Goolge ;-) ) Jetzt plant man im FPGA aber nicht nur eine Route und es gibt diverse Randbedingungen. Und man muss überhaupt erstmal jeweils Start und Ziel festlegen... raus kommt ein ca. 31 Megabit großer Bitstream beim A100T. > EP2S180 Naja das ist ja uralt, das A200T ist größer...
-gb- schrieb: > Oh nein!!! Habe ein Stratix 2 Board mit EP2S180 bei eBay erworben, hätte > ich doch was kleineres genommen ... ohje Das FPGA ist für die freie Version eh zu gross, Stratixe gehen nur bis Q 11.0, und da nur die kleinsten. Zur Geschwindigkeit: 1. z.B. ist ISE 14.5 etwas schneller als 14.7, liegt glaube ich an WebTalk und anderen "neueren" Gimmiks. 2. 14.5 startet die einzelnen Prozesse (Synth, Fit, ..) wesentlich schneller als Vivado, liegt glaube ich an überarbeiteter GUI. Auch Synthese+ISIM startet unter 14.5 deutlich schneller, ISIM ist ebenfalls reaktionsschneller (ob schneller in der Simulation alleine ist mir nicht aufgefallen) 3. Aus einem Design/Netlist ein Bitfile zu generieren dauert nur unwesentlich im vergleicht zur Synthese und Fitting. Mit der GUI/Implementierung kenne ich mich nicht aus, ob Xilinx vlt. komplett intern auf XML umgestellt hat?
Sigi schrieb: > Mit der GUI/Implementierung kenne ich mich nicht aus, > ob Xilinx vlt. komplett intern auf XML umgestellt hat? Komplett wohl nicht, aber sie haben einiges umgestellt. Die GUI enthält nun wesentlich mehr, als die ISE, ist meines Erachtens total überfrachtet und erinnert von der Farbgebung an das Ergebnis eines Grafikwettbewerbs. Hätte man sich mal besser auf die Inhalte besonnen. Es scheint den Jungs nicht abzugewöhnen zu sein, neue Prozessor Power mit ihrem Klickibuntikram zuzumüllen. Am Ende kommt es noch so, dass sie einen Teil des Overheads wieder entfernen, um dann wieder behaupten zu können, Vivado 2016 ist 10% schneller, als das alte. Fischköppe nennt man solche Leute, da, wo ich herkomme. Wenn wir in 5 Jahren 128 Bit-Betriebssysteme mit 64GB-Speicher und 24 Kernen mit 6GHz haben werden, dann finden die sicher auch dann eine Möglichkeit die Hardware abzubremsen.
Der Vivadohasser schrieb: > Die GUI ... ist meines Erachtens total überfrachtet und erinnert > von der Farbgebung an das Ergebnis eines Grafikwettbewerbs. Hätte > man sich mal besser auf die Inhalte besonnen. Dem zweiten Teil des Satzes stimme ich ausdrücklich zu. Zum ersten Satz muss ich feststellen, dass die Vivado-GUI bei Grafikwettbewerben definitiv nichts wird ernten können. Auch in Sachen usability sieht es düster aus: Vivado ist eines der schönen Beispiele, die aufzeigen, dass Softwerker gerne das einbauen, was sie selber für wichtig halten und es so gestalten, wie sie es selbst schön finden, aber nicht etwa das, was der Benutzer wirklich braucht und auch so, wie er es braucht! Solche Software ist nicht selten unbedienbar, was einfach darin liegt, da sie sich nicht am Notwendigen, sondern an dem "einfach Machbaren" orientiert. Niemand hat die Nutzer gefragt. Die Nutzer, die Ingenieure haben es auch nicht programmiert oder vorgegeben, sondern Softwerker mit ihren Chaoshirnen, bzw ehemalige Softwerker, die zu Projektleitern und Produktmanagern aufgestiegen sind. Funktionen werden oft einfach eingebaut, weil sie da sind, bzw. von einem Baukasten angeboten werden oder lustig aussehen - aber nicht, weil sie gefordert waren oder es klare Definitionen gab. Farben, Formen und Grafiken orientieren sich dann leider nicht an solchen Dingen, wie Blickführung, Generation eines Fokus des Benutzers zur Konzentration auf das Wesentliche und Betonung von Zentralfunktionen mit dem Ziel der Benutzerführung zur etwaigen Umsetzung einer Bedienstrategie, sondern es sind simpel durch die Hand eines oder mehrerer Entwickler eigenmächtig gestaltete Dinge. Daher enthalten viele Programme oft unnötige Blödeleien und Gimmicks, die Zeit, Platz und andere Resourcen verfressen, die dann aber auf Kosten der Funktion, des Komforts, der Sicherheit und der Testabdeckung geht. Statt leicht lesbare und auch unter schwierigen Bedingungen (schlechte Augen oder Brille beim Benutzer, Spiegelungen am Monitor, schlechte Beleuchtung etc) noch gut erkennbare Designs zu verwenden, wird alles ohne Sinn und Verstand blindlinks eingefärbt, sodass sich ein bunter Haufen an Grafiken und Farbklecksen ergibt, wobei viele Objekte Aufmerksamkeit erregen, indem sie groß sind, blinken oder Signalfarben verwenden, aber im aktuellen Nutzungsmodus des Programms völlig unbedeutend sind. Ein schönes Beispiel sind hier die chaotischen und überfrachteten Menüs, von denen es gleich mehrere auf dem Bildschirm gibt, welche alle erdenklichen Funktionen zu allen Zeiten anbieten, die oft überhaupt nicht gefragt oder einsetzbar sind. Da fehlt die hierarchische Steuerung und die Planung derselben. Eigentlich müssten die Funktionen des Programms von erfahrenen Nutzern definiert werden, die den design flow kennen, die Bedürfnisse des Benutzers abschätzen können und damit in der Lage sind, die Abläufe und damit die jeweils nötigen Funktionen und deren optische Präsenz auf dem Bildschirm zu definieren. In einem zweiten Schritt müssten dann Grafiker kommen, die um die Themen der Farbwirkung, der Kontraste, der Lesbarkeit etc. Bescheid wissen und die Formen, also die Art der Präsentation festlegen. In einem dritten Schritt müssten dann die Programmierer die Software einfach umsetzen und die GUI entsprechend ausformulieren. Wehe aber, man lässt die Programmierer / Softwareentwickler die GUI machen, Funktion und Formen definieren. Dann gute Nacht.
Sigi schrieb: > Zur Geschwindigkeit: > 1. z.B. ist ISE 14.5 etwas schneller als 14.7, liegt > glaube ich an WebTalk und anderen "neueren" Gimmiks. Das habe ich auch so in Erinnerung! Allerdings hatte die 14.5 ein Problem u.a. mit dem globlal optimzation beim Mappen und hat sich da festgerannt. Die haben da sicher intern einiges geändert. > 2. 14.5 startet die einzelnen Prozesse (Synth, Fit, ..) > wesentlich schneller als Vivado, liegt glaube ich > an überarbeiteter GUI. Zumindest bei kleinen Projekten ist die ISE nach meinen ersten Versuchen auch schneller fertig! Ich weiß nicht, was Vivado alles noch so tut, aber es scheinen einige Dinge wie Power Analyse etc pauschal mit angeschubst zu werden. Gfs werden auch Netzlisten mit erzeugt, die bei ISE erst per Schalter beauftragt werden müssen, wie z.B. das zeitintensive Erstellen einer Schaltungsrepräsentation.
Kest schrieb: > Was Compiler/Synthese/Fitter-Zeiten angeht, muss ich schon gestehen, > dass ich von Altera positiv überrascht bin. Du würdest also pauschal Altera empfehlen? gilt das auch im Vergleich Vivado und QSys? Ich habe den Eindruck, dass Altera mittlerweile nachgezogen hat, was die Buntigkeit und Kleckserei betrifft, die Jürgen hier so hart kritisert. Die Entwickler leben da schon ihren Spieltrieb aus. Das kann man auch bei anderen Elektronikprogrammen sehen.
Jürgen S. schrieb: > Zumindest bei kleinen Projekten ist die ISE nach meinen ersten Versuchen > auch schneller fertig! Ich weiß nicht, was Vivado alles noch so tut, > aber es scheinen einige Dinge wie Power Analyse etc pauschal mit > angeschubst zu werden. Gfs werden auch Netzlisten mit erzeugt, die bei > ISE erst per Schalter beauftragt werden müssen, wie z.B. das > zeitintensive Erstellen einer Schaltungsrepräsentation. Das scheint dann wirklich ziemlich projektabhängig zu sein. Ich hab gerade heute wieder ein Design für zwei Hardware-Revisions bauen lassen. Die alte Rev hat den Spartan 6 LX 75 drauf, die neue den Artix 7-75. Drin ist exakt das gleiche. Build mit ISE dauert 20min für den Spartan und Build mit Vivado dauert 14 min für den Artix. Jeweils komplett durch bis zum Prom File in der Command Line für ISE und in TCL für Vivado.
:
Bearbeitet durch User
Die Programme sind nicht vergleichbar. Vivado macht ganz andere Dinge, die ISE gar nicht konnte. Allein die Reports sind viel umfangreicher.
Vivado IST langsam und das liegt definitiv an dem chaotischen Programmierstil und dem Verhalten, alles grafisch machen zu wollen. Was dabei rauskommt, ist unübersichtlich, unvollständig und schlecht benutzbar. Hier mal meine persönliche Fehlerliste bei Vivado - Die Funktion des automatischen Verteilens der IOs für einen simplen runtest versagt. Es werden (manchmal) nicht alle IOs verteilt. Warum auch immer. - Diese Funktion ist - genau wie der Pinplanner - im tools Menü mal vorhanden und mal nicht. Wenn man nicht alle IOs verteilt hat, kommt man nicht mehr rein. Offenkundiges Fehlen einer funktionsgetriebenen Menüanzeigestrategie. - Das aktuelle Feld, z.B. das unten mit den Designruns ist in einem auffälligen hellblau gehalten. Bei einem groben Überfliegen des Schirms ist dies die dominante Farbe, obgleich eine Rahmenfarbe generell das unwichtigste überhaupt ist. Ein Hervorheben macht aber hier keinen Sinn, da Vivado über parallel zugreifbare Funktionen verfügt, weswegen das Memo des letzten Klicks mit der aktuellen Information und Aktivität überhaupt nichts zu tun haben muss und meist auch nicht hat. Es wird nichts aktiviert, worauf man sich später bezieht. Es sehe auch sonst keine Funktion oder Funktionstaste, die sich auf ein konkretes Fenster bezöge. Man hat also eine nutzlose Funktion. - Die Synthese hingegen läuft unauffällig rechts oben im Bild, man übersieht es leicht, wenn sie aktiv ist. Dort wäre ein grünes Unterlegfeld sicher sinnvoller, da eine grüne LED Aktivität signalisiert. Keiner drauf gekommen. Was war nochmals das Ziel von Hervorhebungen? - Es wird eine Unmenge von Fenstern geführt und damit ständig alle möglichen Infos gleichzeitig angezeigt, weil keine Anzeigestrategie vorliegt. Die Fenster buhlen um Aufmerksamkeit, erfordern mitunter ein Suchen Der Information und nehmen dem eigentlich wichtigen Fester den Platz weg, sodass man erst das wichtige Fenster vergrößern müsste, Obendrein zeigen sie teilweise veraltete und damit missverständliche Daten an. Sinnvollerweise müsste man die sofort ausgrauen, wenn der Informationsgehalt obsolet wird, aber dies erforderte wieder ein Bedienkonzept und eine daraus abgeleitete Führung und Anzeigestrategie. - Es wird eine unnötig komplizierte und nicht eindeutige Farbverlaufsgebung bei den Rahmen verwendet, welche es erschwert, die Rahmen den Fenstern zuzuordnen, in der Folge selbe zu greifen und zu ziehen. Z.T. bestehen seltsame Scheinüberlappungen. Alles Zeugs, das den Nutzen eher verschlechtert, als steigert und Programmierzeit gekostet hat, die bei der Beseitigung der bugs besser angelegt gewesen wäre. - Das Ein- und Ausklappen von Fenstern, wie dem Flow Navigator, geschieht nicht über denselben Schalter, sondern es gibt einen großen zum Ausklappen und einen anderen kleinen, zum Einklappen. Damit kann man es nicht ein-ausklappen um kurz zu schauen, sondern muss die Maus bewegen und zudem bei dem kleinen noch genau Zielen. Hochgradig unsinnig und widersprüchlich. Kostet mehr Entwicklungszeit und erschwert dem Nutzer die Bediengung, ganz zu schweigen von der sinnfreien Animation des sich Zurückziehens, um dann verspätet die anderen Fenster zu vergrößern. - Das Ein- und Ausklappen der Funktionen wie Synthese und Implementierung links sind ebenfalls animiert, was nichts als Zeit kostet, da man erst treffsicher klicken kann, wenn alles ausgeklappt ist. Eine typisch dumme Geschichte, die ein Programmierer dem anderen abguckt und denkt, er sei damit kreativ. - Das Anklicken dieser Funktionen links an sich, bringt mitunter verschiedene Bildschirmzustände hoch, bei denen aber nicht wirklich diejenigen Fenster gezeigt werden, die für diese Funktion jeweils nötig wären. Gleichzeit bleiben andere, nicht benötigte bestehen. Wieder das gleiche Thema: Offensichtlich kein Bedienkonzept hinterliegend. Da hat einer was programmiert, was ihm spontan in den Kopf gekommen ist! - Schlimmster Anfängerfehler: Die eingeblendeten Progressbalken beim Erzeugen von Designs oder Ausführen von Teilfunktionen sind animiert und springen hin und her, statt wie ursprünglich gedacht, EIN EINZIGES MAL VOLLAUFEN und damit eine ungefähre Anzeige der Restzeit zu ermöglichen. So hat man bei gestarteter Synthese keine Information, wie weit der Fortschritt ist, was aber für uns Benutzer sehr wichtig wäre. Das ist der kompletteste Blödsinn, den man immer öfters finden kann, weil ein Vollhonk es dem anderen nachprogrammiert, weil er es für eine tolle Idee hält. Ist nicht gerade politisch korrekt, das so zu formulieren, aber es ist einfach nur stupider Unfug! Allein dieser Aspekt zeigt mir, dass dort wild programmierende Kinder ihrem Spieltrieb nachgehen konnten und ihren "Gestaltungsideen" freien Lauf lassen durften, von denen sie selber wahrscheinlich sogar noch glauben, dass sie Ausdruck ihrer hohen Kreativität sind. :-(
hi, Vivado erscheint wirklich gemütlich: bis sich eine Ansicht schließt und eine neue geöffnet ist, bis Wizards starten, das ständige updaten der Hierarchie. Es gibt sicherlich noch viel Potential. Aber: Was ist denn ein durchgängiges Bedienkonzept. Kannst du das definieren? Das ist doch sowas von Subjektiv. Ein anderes Konzept stößt dem nächsten Anwender wieder schwer auf, weil er sich gegängelt und bevormundet fühlt. Dass man vieles einstellen kann (Hotkeys, Ansichten, etc) hilft auch nur bedingt, da man auch hier nicht mal eben irgendein Projekt anfangen kann, sondern erst einmal alle Einstellungen durchgehen muss. Bleibt für mich als größtes Manko die Geschwindigkeit, selbst auf einem Toprechner (i7-48xx) mit viel RAM sind die Wartezeiten lästig. Dabei wäre ich noch bereit bei der Synthese Eingeständnisse zu machen, aber die GUI muss definitiv schneller, reaktionsfreudiger, etc. werden. grüße
Kauft es mal eine SSD für den Rechner dann läuft auch gleich alles sehr geschmeidig. Schaut Euch doch mal den ISE oder Vivado Ordner an. Das sind ca. 20GB und mehr und dann alles so extrem kleine Datein. Da geht jede Festplatte in die Knie. Auch SSDs habe mit dieser Dateigröße Probleme jedoch ist die Geschwindigkeit schon mal 20 bis 40 mal schneller als mit HDDs. Wenn Ihr dann noch eine neue SSD im M.2 Format kauft dann geht das richtig ab. Außerdem ist es auch wichtig das der RAM Durchsatz ordentlich ist. Am besten ist so ein Quad Channel RAM Interface das kann so ca. 40GByte pro Sekunde übertragen während die 2 Channel Interfaces vor 3 Jahren gearade mal 10 bis 15GB/s schaffen. Leider ist die Benutzung von meheren Kernen nicht besonders gut umgesetzt. Ich würde einfach 1 Kern nehmen und dem ein komplettes Routing erzeugen. Die anderen 5 Kerne können das dann auch machen. Nach einem Durchlauf hat man dann 6 unterschiedliche Umsetzung und es muss "nur noch" verglichen werden welche Umsetzung von den Timings am besten ist.
Johann schrieb: > Kauft es mal eine SSD für den Rechner dann läuft auch gleich alles sehr > geschmeidig. Ich habe ein System mit 2 M2-SSDs und die lösen das Problem nicht wirklich, weil sie nur das erstmalige Laden von Vivado sowie der Dateien beschleunigen, nicht aber das Berechnen und das scheint mir das Entscheidendere. Ich habe dazu Tests gemacht und an anderer Stelle auch mal publiziert - auch was RAM-Disk angeht. Das liegt alles im Bereich von +/- 20%, es sei denn, man hat insgesamt zu wenig RAM und die Software muss unnötig auslagern. Sobald 16 GB RAM vorhanden sind, tut das nicht mehr soviel. Das Problem ist eher, dass Vivado überhaupt soviele Datein erzeugt, viele Zwischenstufen speichert und auch viele Kopien anlegt - nebst dem tyoischen Datenmüll. Die Multi-Core Thematik ist sicher ein Punkt. Warum das Routing nun ausgerechnet 4 Cores belegt und nicht mehr und wozu, bleibt natürlich im Dunkeln. Grundsätzlich mehrere Design-Lösungen parallel rechnen zu lassen, ist eher hinderlich, denke ich, weil die Ergebnisse nicht so sehr differieren werden, die Zahl das Platten- und Speicherzugriffe aber massiv in die Höhe gehen werden. Möglicherweise tut sich da in der Zukunft noch ein bischen was. Potenzial besteht zweifelsfrei, wenn man den Rückmeldungen derer Glauben schenken darf, die ihre Synthesen mit den Tools der Drittanbieter durchführen: Generell deutlich schneller fertig, die Designs sind kleiner und vor Allem oft viel taktfreudiger.
Jürgen S. schrieb: > Warum das Routing nun > ausgerechnet 4 Cores belegt und nicht mehr Ist voreingestellt, kann man aber mit 'set_param general.maxThreads 8' auf z.B. 8 Threads erhöhen.
Pat A. schrieb: > Ist voreingestellt, kann man aber mit 'set_param general.maxThreads 8' > auf z.B. 8 Threads erhöhen. Wo stellt man das ein? geht das auch für ISE? Was ist mit Quartus und Multitasking-Option? Kann es sein, dass Quartus per se deshalb schneller ist, weil sie mehr Kerne nutzen?
Quartus (13.1) nutzt bei mir (im Mittel) einen Kern. Das finde ich persönlich nicht so wahnsinnig innovativ.
Angehängte Dateien:
-
elapsed.png
32 KB
Andreas F. schrieb: > Das steht aber im Widerspruch zu der Aussage hier: > Beitrag "Re: Konfiguration eines FPGA-PCs" Mag sein, daß mein Quartus den Beitrag nicht gelesen hat. Im Beispiel sind's im zeitlichen Mittel zwar fast 1,5 Kerne, aber sehr viel mehr ist nicht drin.
:
Bearbeitet durch User
Markus F. schrieb: > Andreas F. schrieb: >> Das steht aber im Widerspruch zu der Aussage hier: >> Beitrag "Re: Konfiguration eines FPGA-PCs" > > Mag sein, daß mein Quartus den Beitrag nicht gelesen hat. Im Beispiel > sind's im zeitlichen Mittel zwar fast 1,5 Kerne, aber sehr viel mehr ist > nicht drin. Was für eine Version verwendest du? Meine geben folgende Meldung aus:
1 | Warning (20028): Parallel compilation is not licensed and has been disabled |
Sie verwenden dann stur 1.0 Prozessoren. Getestet mit Quartus Prime 16.0 und Quartus Lite 13.0.1 in der Web Edition.
Mike schrieb: > Parallel compilation is not licensed and has been disabled Mike schrieb: > Sie verwenden dann stur 1.0 Prozessoren. Getestet mit Quartus Prime 16.0 > und Quartus Lite 13.0.1 in der Web Edition. Das ist ein Thread zu Xilinx Vivado nicht Altera Qartus - IMHO ist es sinnvoll dafür einen extra Thread zu starten. -- Nicht jede quartus-variante unterstützt multithread: http://quartushelp.altera.com/15.0/mergedProjects/msgs/msgs/wqcu_parallel_no_license.htm
Mike schrieb: > Was für eine Version verwendest du? Meine geben folgende Meldung aus: > Warning (20028): Parallel compilation is not licensed and has been > disabled > > Sie verwenden dann stur 1.0 Prozessoren. Getestet mit Quartus Prime 16.0 > und Quartus Lite 13.0.1 in der Web Edition. 13.1 und 13.0sp1 (Ich hab' noch Cyclone II und III). Die Web Edition läßt sich nur mit aktiviertem TalkBack (Tools->Options->Internet Connectivity->TalkBack Options) zur Nutzung von mehreren Cores überreden. Mir ist das wurscht, meine Designs sind sowieso weit entfernt von nobelpreisverdächtig...
Brillianz der Gedanken schrieb: > Das ist ein Thread zu Xilinx Vivado nicht Altera Qartus - IMHO ist es > sinnvoll dafür einen extra Thread zu starten. Hier geht es bereits seit dem allerersten Post (hast Du den gelesen?) um einen Vergleich der Synthesezeiten Xilinx <-> Altera.
Markus F. schrieb: > Brillianz der Gedanken schrieb: >> Das ist ein Thread zu Xilinx Vivado nicht Altera Qartus - IMHO ist es >> sinnvoll dafür einen extra Thread zu starten. > > Hier geht es bereits seit dem allerersten Post (hast Du den gelesen?) um > einen Vergleich der Synthesezeiten Xilinx <-> Altera. Im Titel steht da nix, nur Vivado. Ein Vergleich zwische Quartus und Vivado macht für die Designpraxis den gleichen Sinn wie eine zwischen gcc für Linux auf ARM und Visual Studio für Windowa auf i32 -> nämlich Null. Sinnvoll sind threads die sich jeweils für Quartus oder Vivado oder ISE oder WhatEver mit dem Tuning der Laufzeit befassen.
Brillianz der Gedanken schrieb: > Im Titel steht da nix, nur Vivado. Vielleicht solltest du einmal mehr als nur den Titel lesen? Sonderlich brilliant muss man dafür nicht sein. > Ein Vergleich zwische Quartus und Vivado macht für die Designpraxis den > gleichen Sinn wie eine zwischen gcc für Linux auf ARM und Visual Studio > für Windowa auf i32 -> nämlich Null. Der OP hat für sein Projekt die Synthesezeiten von Xilinx und Altera verglichen. Sind immerhin die beiden größten Hersteller. Und er hat sich gewundert warum Xilinx so lange braucht. > Sinnvoll sind threads die sich jeweils für Quartus oder Vivado oder ISE > oder WhatEver mit dem Tuning der Laufzeit befassen. Der OP scheint da anderer Meinung zu sein und hat nach Tuningtipps gefragt. Du kannst natürlich neue Threads mit deinen Tipps aufmachen oder einen Artikel fürs Wiki schreiben. Der Hinweis von Markus F. mit der Aktivierung von Talk Back war übrigens recht gut. Das hat die Zeiten bei einem meiner größeren Projekte fast halbiert (17m25s -> 9m29s). Die Auslastung der CPUs gibt das eigentlich nicht her...
Brillianz der Gedanken schrieb: > Ein Vergleich zwische Quartus und Vivado macht für die Designpraxis den > gleichen Sinn wie eine zwischen gcc für Linux auf ARM und Visual Studio > für Windowa auf i32 -> nämlich Null. Was ist noch langweiliger als Angeln? Beim Angeln zugucken. Was ist noch blödsinniger als einen sinnlosen Fred aufzumachen? In einem sinnlosen Fred zu meckern, daß Beiträge Off-Topic wären. Schönen Sonntag noch!
:
Bearbeitet durch User
Geht es jetzt noch um das Thema oder die Selbstdarstellung der Diskussionsteilnehmer?
Andreas F. schrieb: > Pat A. schrieb: >> Ist voreingestellt, kann man aber mit 'set_param general.maxThreads 8' >> auf z.B. 8 Threads erhöhen. > Wo stellt man das ein? geht das auch für ISE? Was ist mit Quartus und > Multitasking-Option? Auf der TCL-Console eintippen? Habe es mal probiert mit "8". Einzige Beobachtung: Während zweier kurzen Phasen der Implementierung sieht man mal auf allen 12 Cores Aktivität und die Auslastung geht kurz auf "45%" hoch. Wären durchschnittlich 6 Kerne. Für 90% der Phasen bleibt es aber bei 4 Cores und einer Auslastung von maximal 30%, was dazu passt. Überwiegend ist das usage-tableau leer und es wird jeweils ein einziger Thread neu angeworfen. Durschnittlich sind die CPUs zu 10-20% aktiv. Das war es.
Mike schrieb: >> Ein Vergleich zwische Quartus und Vivado macht für die Designpraxis den >> gleichen Sinn wie eine zwischen gcc für Linux auf ARM und Visual Studio >> für Windowa auf i32 -> nämlich Null. > > Der OP hat für sein Projekt die Synthesezeiten von Xilinx und Altera > verglichen. Sind immerhin die beiden größten Hersteller. Und er hat sich > gewundert warum Xilinx so lange braucht. Synthese oder Gesamt tool-chain? Die RTL-Synthese ist zeitlich vernachlässigbar, Hautp-zeitfresser ist Place and Route. Und das ist eben nicht sonderlich gut parallisierbar und auch stark von der FPGA-Ziel Architektur abhängig. Xilinx hat nach meiner Erfahrung mehr und fein granulare Routing Resourcen als Altera mit den long|short coloums. Da muss der Router größere interne Tabellen aufbauen und braucht dadurch deutlich länger. Ein reines Software-problem ist das nicht. Viel kann man mit wohldosierten Placement-constraints rausholen, lies dir mal das durch: Beitrag "Routing Congestion verhindern" Deshalb ist IMHO die ganze Design-SoftwareQualität nicht sonderlich zielführend, wichtig ist das man das Design so constraint das es die Software einfach hat. Auslastungsgrad des FPGA's hat auch einen deutlichen Einfluß. Es ist nicht ungewöhnlich das ein design mit 90% LUT-Auslastung deutlich länger braucht als das deselbe design auf einem größeren FPGA mit 30% LUT-Auslastung. Noch kritischer wenn das period constraint an des maximum des speedgrades stößt. Wer sich für Details interessiert sei http://www.ecs.umass.edu/ece/tessier/tessier-phd.pdf empfohlen. PS: Mike schrieb: > Vielleicht solltest du einmal mehr als nur den Titel lesen? Sonderlich > brilliant muss man dafür nicht sein. Langsam krieg ich Halsscmerzen vor lauter Kopfschütteln. Der Titel passt nicht zum Thread-Inhalt, das muß er aber damit der Leser das Gesuchte schnell findet, jegliche Diskussion darüber ist reine Zeitverschwendung.
Markus F. schrieb: > In einem sinnlosen Fred zu meckern, daß Beiträge Off-Topic wären. Naja, ich denke so sinnlos war meine Frage seinerzeit nicht. Immerhin ist es ziemlich beunruhigend, wenn man umsteigen soll und für ein Design gleicher Komplexität mit ähnlich modernen FPGA auf einmal 3-3.5x mal so lange braucht für Synthesis/P&R. Da fragt man sich natürlich als Erstes: "Was mache ich falsch?". In der Zwischenzeit weiss ich, dass Vivado halt einfach elend langsam ist (dafür hatte Xilinx die 20nm-Chips rechtzeitig auf dem Markt). Und Fortschritte machen die ja auch. Die katastrophale Performance beim Einlesen der Source ist in den neueren Versionen nun ziemlich fix, und auch Synthesis/P&R hat Fortschritte gemacht: Sie brauchen jetzt nur noch doppelt solange wie Quartus Prime. ;-)
P. K. schrieb: > Sie brauchen jetzt nur noch > doppelt solange wie Quartus Prime. ;-) Ja, was denn nun? Xilinx war doch schneller, weil sie mehr Cores nutzen und Quartus nur einen, wie es hier im Forum hiess ?
Brillianz der Gedanken schrieb: > Die RTL-Synthese ist zeitlich > vernachlässigbar, Hautp-zeitfresser ist Place and Route. Was rechnest Du jetzt alles in P&R? Nach der alten Deklaration vom ISE z.B. ist der P&R-Schritt vielleicht ein Drittel. Das Mapping ist das , was dauert. > Wer sich für Details interessiert sei > http://www.ecs.umass.edu/ece/tessier/tessier-phd.pdf empfohlen. Interessant. Danke!
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.