Hi leute, ich habe in der Vergangenheit meine Projekte immer mit ISE / Vivado simuliert. Leider muss ich bei Vivado in den neueren Versionen feststellen, dass sie mit ihren Simulatoren Probleme haben und teilweise die Simulationen nicht auf die aktuellsten Files zurückgreifen. Sprich: Man ändert etwas im HDL code, simuliert aber dann eine vorherige Version des files - wieso auch immer - Ich würde daher gerne mal auf einen anderen HDL Simulator umsteigen, der möglichst "lightweight" ist und Vivado nur noch zur Synthese nutzen. Was könnt Ihr empfehlen für die Nutzung unter Win? Danke & Gruß Markus
Vivado nervt schrieb: > Sprich: Man ändert etwas im HDL code, simuliert aber dann eine vorherige > Version des files - wieso auch immer - Benutze makefiles! Oder gewöhne dir sonst einen Erwachsenen Umgang mit Softwaretools an. Den Fehler, das du andere Sourcen verwendest als du eigentlich verwenden wolltest, berichtigst Du nicht durch Wechsel auf ein neues tool. Im Gegenteil, du wirst gegen neue und andere Anfängerfehler kämpfen. http://opencpi.github.io/Vivado_Usage.pdf
Vivado nervt schrieb: > Leider muss ich bei Vivado in den neueren Versionen feststellen, dass > sie mit ihren Simulatoren Probleme haben und teilweise die Simulationen > nicht auf die aktuellsten Files zurückgreifen. > > Sprich: Man ändert etwas im HDL code, simuliert aber dann eine vorherige > Version des files - wieso auch immer - Das ist aber ganz klar ein Layer 8 Problem. Da wuerde ich mal anfangen mich ordentlich mit meinen Tools auseinander zusetzen. ;-)
Eigentlich kennt man dieses Verhalten eher von der ISE, oder? Also files anklicken, um sie zu bearbeiten, dann doppelt haben und die aktuelle Änderunge im anderen Editor die konterkariert wird. Ich meine, Vivado hötte das abgestellt? Manfred Malicious schrieb: > Benutze makefiles! Oder gewöhne dir sonst einen Erwachsenen Umgang mit > Softwaretools an. Das löst das Problem nicht und erzeugt nur Mehraufwand, wenn ich nach jeder Mickiänderung das makefile ändern muss. Die Schwierigkeit bei Xilnx ist, dass das tools etwas nicht immer neu compiliert, obwohl es eine Änderung in den Sourcen gibt. Zu lösen nur mit pauschalem immer wieder neu angeschubsten Neucompilieren.
Vivado nervt schrieb: > Ich würde daher gerne mal auf einen anderen HDL Simulator > umsteigen, der möglichst "lightweight" ist und Vivado nur > noch zur Synthese nutzen. Neben Vivado gibt es auch Quartus oder ISE, die können auch simulieren. Ansonsten gibt es noch Verilator (für Verilog) und GHDL (für VHDL), die aber beide nicht miteinander interagieren können. Du darfst dir also dein bevorzugtes Gift selbst aussuchen. :-) Manfred Malicious schrieb: > Benutze makefiles! Oder gewöhne dir sonst > einen Erwachsenen Umgang mit Softwaretools an. Makefiles sind ein für Vivado gänzlich ungeeignetes Werkzeug. Vielleicht solltest du etwas nachdenken, bevor du Gülle absonderst. Weltbester FPGA-Pongo schrieb im Beitrag #6333322: > Das löst das Problem nicht und erzeugt nur Mehraufwand, > wenn ich nach jeder Mickiänderung das makefile ändern muss. Der Sinn von Makefiles ist es, dass man diese eben nicht ständig ändern muss...
S. R. schrieb: > Manfred Malicious schrieb: >> Benutze makefiles! > Makefiles sind ein für Vivado gänzlich ungeeignetes Werkzeug. > Vielleicht solltest du etwas nachdenken, bevor du Gülle absonderst. Danke gleichfalls, Was macht Vivado angeblich make-flow untauglich ß!?
Weltbester FPGA-Pongo schrieb im Beitrag #6333322: > Zu lösen nur mit pauschalem immer > wieder neu angeschubsten Neucompilieren. Genau das schafft make, aber eben nicht mit stupiden pauschal anstupsen, sondern nur nach Änderung in den Sourcefiles. Das Problem ist, das sich mit Vivado immer weniger Entwickler bemühen, den Überblick zu behalten, welche files zum source gehören und welche nicht. Und es nicht schaffen den Builtprozess über die cmd-line anzustossen.
S. R. schrieb: > Neben Vivado gibt es auch Quartus … die ja ModelSim als Simulator dabei haben. Benutze ich gerade (für Lattice), der merkt es sehr wohl, wenn sich das Datum einer Datei geändert hat. Neu compilieren muss man sie danach natürlich im Simulator noch, aber man bekommt eine Warnung, wenn man die Simulation startet ohne das zu tun. Vermutlich könnte man sie auch via "make" neu compilieren, wenn man das denn will, aber einen wirklichen Vorteil sehe ich da auch nicht gegenüber dem Compilieren via GUI. Für die Simulation wird man ja die GUI ohnehin haben wollen, zur Auswahl der Signale sowie der Waveform-Darstellung. Schätzungsweise kann man das alles auch über die Kommandozeile anwerfen und dann eine VCD-Datei schreiben lassen, aber das lohnt sich wohl nur für umfangreichere Simulationen, die so lange dauern, dass man in der Zeit nicht mehr vor der Kiste sitzen will.
:
Bearbeitet durch Moderator
S. R. schrieb: > Neben Vivado gibt es auch Quartus oder ISE, die können auch simulieren. > Ansonsten gibt es noch Verilator (für Verilog) und GHDL (für VHDL), die > aber beide nicht miteinander interagieren können. Icarus Verilog koennte man sonst noch nennen, der kann VPI, und somit auch Co-Simulieren (aka interagieren). Somit kann man z.B. mit Python-Frontends wie MyHDL durchaus mixed-simulation-Modelle durchkloppen. Ansonsten kann ich nur sagen, dass ein make-basierter Workflow die bisher einzige bullet-proof-Methode war, um alles von A-Z (von der SoC-Beschreibung bis zur CI) sauber durchzusynchronisieren. GHDL kriegt's auch ziemlich gut hin, nur das neuzubauen, was veraendert wurde.
Manfred Malicious schrieb: > Was macht Vivado angeblich make-flow untauglich ß!? Vivado funktioniert nicht nach dem "mache aus einer Datei A durch Befehle C eine Datei B"-Prinzip und damit kann make seine Stärken nicht ausspielen. Ich habe auch einen "make-flow", sowohl für Vivado als auch für ISE. In beiden Fällen erzeugt das Makefile einfach nur ein Vivado-Projekt und lässt dann Vivado auf dem Ding rumnuckeln. Solange man nicht das gesamte Projekt neu generieren muss, ist das nur ein etwas kompliziert aussehendes Shellscript. Dummerweise ist das die einzige Möglichkeit, alle Quelldateien zuverlässig miteinander zu verknoten, da es kein ordentliches Abhängigkeitsmanagement gibt. Eine VHDL-Datei hängt über "work" grundsätzlich von allen anderen VHDL-Dateien ab.
S. R. schrieb: > Eine VHDL-Datei hängt über "work" > grundsätzlich von allen anderen VHDL-Dateien ab. Wenn der Synthesizer eine vernuenftige Analyze macht (wie z.B. synplify), sollte das nicht sein. Man kann sich die Dependencies bei grossen Projekten aus GHDL rausextrahieren und im ISE-Flow per Makefiles einzelne Blackbox-Netzlisten bauen, die man dann fuer P&R zusammenlinkt. Man muss natuerlich a priori seine Componentenbibliothek effizient organisiert haben. Wuerde mich sehr wundern, wenn das bei neueren Vivado-Releases nicht mehr ginge, ansonsten muesste man eigentlich das gleiche Ergebnis mit Aufruf von vivado im Batch-Mode und TCL bekommen koennen.
Martin S. schrieb: > Wenn der Synthesizer eine vernuenftige Analyze macht > (wie z.B. synplify), sollte das nicht sein. Dummerweise ist make aber kein Synthesizer und kann das darum nicht... (GHDL sehe ich als Sonderfall an. Damit mag es zuverlässig gehen, habe ich nur für kleine Projekte mal gemacht. Lief.) Martin S. schrieb: > Wuerde mich sehr wundern, wenn das bei neueren Vivado-Releases nicht > mehr ginge, ansonsten muesste man eigentlich das gleiche Ergebnis mit > Aufruf von vivado im Batch-Mode und TCL bekommen koennen. Eben: Make ist hier ein ungeeignetes Werkzeug. Besser ist es, das alles direkt mit Vivado-Tcl und passenden Scripten zu machen. Die kann man zwar auch in ein Makefile verklappen, aber dann nutzt man make nur als Shell und nicht dafür, wofür es vorgesehen ist. Also kein "make-flow".
:
Bearbeitet durch User
S. R. schrieb: > Eine VHDL-Datei hängt über "work" > grundsätzlich von allen anderen VHDL-Dateien ab. Das ist falsch. work ist einfach nur ein Handler auf die aktuelle Lib in der sich eine Datei befindet. Nicht mehr. Das Konzept sieht man aber immer wieder falsch verstanden und angewendet. Dieser Artikel schafft ganz gut Abhilfe: https://insights.sigasi.com/tech/work-not-vhdl-library/
Tobias B. schrieb: > Das ist falsch. work ist einfach nur ein Handler auf die > aktuelle Lib in der sich eine Datei befindet. Nicht mehr. Dennoch hängt im Prinzip jede VHDL-Datei von jeder anderen VHDL-Datei ab, denn um die Abhängigkeiten zu ermitteln, muss man sämtliche Dateien parsen. Ob "work" nun eine Lib ist oder nicht ist egal.
S. R. schrieb: > Tobias B. schrieb: >> Das ist falsch. work ist einfach nur ein Handler auf die >> aktuelle Lib in der sich eine Datei befindet. Nicht mehr. > > Dennoch hängt im Prinzip jede VHDL-Datei von jeder anderen VHDL-Datei > ab, denn um die Abhängigkeiten zu ermitteln, muss man sämtliche Dateien > parsen. > > Ob "work" nun eine Lib ist oder nicht ist egal. Auch das ist nicht korrekt, das Library Konzept ist genau dafuer da um diese verschachtelten Abhaengigkeiten zu vermeiden. Genauso kann die Synthese auf Library Level arbeiten ohne das Design flach" machen zu muessen (Stichwort "Keep Hierarchy"). Ebenso die Simulationstools, die auch nur den Code nachkompilieren muessen der geaendert wurde und deren Abhaenigkeiten von Top to Bottom. Sieht man ganz gut wenn man z.B. VUnit verwendet. ;-) Wenn du allerdings mit "component" Instanzierungen arbeitest, ja dann hast du recht. Kann ich aber keinesfalls empfehlen, das fuehrt zwangslaeufig zu unsauberen Projekten, vorallem wenn diese anfangen zu wachsen. Aber wie schon gesagt, das sieht man wirklich sehr haeufig, auch unter denen die schon lange VHDL machen, dass sie das Library Konzept nicht sinnvoll anwenden und sich damit einer Menge Moeglichkeiten berauben. Da empfiehlt es sich wirklich da mal tiefer einzusteigen. Grosse Designs werden einfacher zu warten und IPs schoen gekapselt.
Manfred Malicious schrieb: > Genau das schafft make, aber eben nicht mit stupiden pauschal anstupsen, > sondern nur nach Änderung in den Sourcefiles. Das Problem ist, das sich > mit Vivado immer weniger Entwickler bemühen, den Überblick zu behalten, > welche files zum source gehören und welche nicht. Und es nicht schaffen > den Builtprozess über die cmd-line anzustossen. Nicht benötigte Sourcen sind wohl weniger das Problem. Das Ding ist, dass der dödelige Editor es nicht schafft, eine Aktualisierung weiterzugeben und eben bei ISE durchaus 2 files gleichzeitig in Bearbeitung sein können. Wenn man es ganz sicher machen will, dann muss man komplett ohne IDE arbeiten, also EDITOR und BUILD getrennt extern nutzen. Dann bleibt noch das Problem, dass der Synthesizer dann intern gerne auf alten Müll zurückgreift, weil er es nicht mitbekommt, dass ein file neu compiliert wird. Eigentlich ist es ein Witz, dass das nach wie vor nicht 100% sicher automatisch geht und man mit scripten herumwurschteln muss, was eigentlich stupide Arbeit ist, die automatisiert erledigt werden könnte.
S. R. schrieb: > Dennoch hängt im Prinzip jede VHDL-Datei von jeder anderen VHDL-Datei > ab, denn um die Abhängigkeiten zu ermitteln, muss man sämtliche Dateien > parsen. Ja, genau das ist Teil des 'analyze'-Schritts, den eigentlich jedes vernuenftige Synthesizer-Tool macht. Funktioniert schlussendlich genauso wie bei gcc wie mit *.c und *.o, es fallen Dependency-Dateien (*.d) raus, die make zur Aufloesung verwendet, es sind hier halt *.v* -> *.ngc oder allenfalls *.*if. S. R. schrieb: > Eben: Make ist hier ein ungeeignetes Werkzeug. Das sehe ich nicht so, weil du durchaus einen Flow 'aus A mach B, aber nur wenn sich was geaendert hat' hinbekommen kannst, mit der xst-toolchain (ISE) laeuft das seit Jahren so (damit beschleunige ich meinen Build deutlich), und die einzelnen Schritte kannst du per TCL-Batch bei Vivado immer noch aufrufen, wenn es aus irgendeinem Grund mit den binaries nicht geht. Aber wie Tobias betont, muss man halt analog zur SW-Library von Anfang an ein aufgeraeumtes Konzept fahren und sich einfach von dem Wunsch trennen, dass die FPGA-IDEs das irgendwann mit der Synchronisierung 100%ig hinkriegen.
S. R. schrieb: > Dennoch hängt im Prinzip jede VHDL-Datei von jeder anderen VHDL-Datei > ab, denn um die Abhängigkeiten zu ermitteln, muss man sämtliche Dateien > parsen. Für Modelsim funktioniert das ganz gut mit vmk: https://sourceforge.net/projects/vmk/ Nutze ich seit vielen Jahren. S. R. schrieb: > aber dann nutzt man make nur als Shell Das macht nix, alles ist besser als x-mal in der GUI rumzuklicken, nur um das fertige Bitfile ins FPGA zu bekommen... Duke
muss man für GHDL tatsächlich noch Werbung machen? ghdl -i xxx.vhd ghdl -m xxx
Ich mach' auch mal noch Werbung fuer Klicki, ohne Bunti, da offenbar doch vielerorts Abneigung gegen pure Kommandozeile oder eine Linux-Installation aufflammt: https://mybinder.org/v2/gh/hackfin/hdlplayground/master?filepath=work%2Findex.ipynb In Kuerze: * Im Browser mit GHDL spielen, Blinky simulieren * Synthetisieren und post-synthesis/map verifizieren * Fuer Lattice ECP5: PnR und Target programmieren NB: nicht alle edit-links funktionieren im Binder (sondern nur lokal). Kann ich nix fuer :-)
Duke Scarring schrieb: > Das macht nix, alles ist besser als x-mal in der GUI rumzuklicken, nur > um das fertige Bitfile ins FPGA zu bekommen... In Vivado kann man sich einen button generieren, der mit einem einzigen Klick: * die Datei umbenennt * sie ins Archiv verschiebt * sie Versioniert und in einem Ladeverzeichnis kopiert * das ROM-File genriert * das MAP-File generiert * ein BAT anschubst, welches alles in SVN versioniert * SVN anschubst um es ins REP zu schieben * während parallel das ROM passend verschoben und benannt wird * damit dann der HW-Manager startet Ich habe an die 20 solcher Buttons, die allesmögliche sauber erledigen und muss einmal draufdrücken, während die Kollegen die gerne sripten immer erst in ein Verzeichnis hoppeln müssen, um dann einen start Befehl auszuführen wöhrend sie der ganzen Welt einreden, dass ihre 1980-Vorgehensweise die Schnellste ist.
Hans Kanns schrieb: > In Vivado kann man sich einen button generieren, Kanns der Hans uns auch erklären, wie?
S. R. schrieb: > Hans Kanns schrieb: >> In Vivado kann man sich einen button generieren, > > Kanns der Hans uns auch erklären, wie? Interessant ist es sicherlich. Wie schon erwähnt wurde, alles ist besser als x-mal Klicken um Zufälligerweise von mehreren Entwicklern an verschiedenen Tagen das selbe Ergebnis zu bekommen. Ob das Scripts oder eine gescheit konfigurierte IDE ist, ist im ersten Schritt mal egal. Konkret zu diesem Ansatz kommt mir (auch etwas unserer Kundschaft geschuldet) die Frage, ob diese Vivado Buttons dann zur Vivado Installation gehören oder zum Projekt? Wir haben hier ja auch verschiedene Versionen von allen Tools aus Gründen, darum sollten so Sachen bei uns zum Projekt gehören aber das kann in anderen Firmen (z. B. nur eine Produktlinie oder Vivado gleich auch in VM oder container) auch flexibler gehandhabt sein.
Christoph Z. schrieb: > Interessant ist es sicherlich. Wie schon erwähnt wurde, alles ist besser > als x-mal Klicken um Zufälligerweise von mehreren Entwicklern an > verschiedenen Tagen das selbe Ergebnis zu bekommen. Ob das Scripts oder > eine gescheit konfigurierte IDE ist, ist im ersten Schritt mal egal. Wenn du Vivado offen hast, dann schau mal unter: Tools -> Custom Commands. Ist dann eigentlich selbst erklaerend. Christoph Z. schrieb: > Konkret zu diesem Ansatz kommt mir (auch etwas unserer Kundschaft > geschuldet) die Frage, ob diese Vivado Buttons dann zur Vivado > Installation gehören oder zum Projekt? Ist fuer die gesamte Installation, sprich ein erzeugter Button erscheint in jedem Projekt. Ob das auch auf Projektbasis geht weiss ich allerdings nicht, UG894 ist der richtige USerguide dazu, muesste man bei Interesse mal reinschauen ob sich da was findet. Kleiner Nachtrag: Man kann die Buttons via Tcl Script generieren, sprich wenn man ein Tcl Skript hat, welches einem das Projekt baut, kann man sich auch entsprechende Buttons generieren. Ob die jetzt aber dauerhaft bleiben oder nur in dem Projekt zu sehen sind, kann ich leider nicht sagen :-(
:
Bearbeitet durch User
Hi, wie schon erwähnt sind diese Buttons projektübergreifend. Schön wäre ein "on-project-open-hook" in Vivado, um je nach Projekt individuell etwas ablaufen lassen zu können (Buttons, auto open bd, etc). Vivado kann das von Haus aus jedoch nicht, aber ich habe mir eine Vivado_init.tcl geschrieben, welche das open_project Kommando modifiziert:
1 | rename open_project open_project_builtin |
2 | proc open_project args {
|
3 | open_project_builtin {*}$args
|
4 | set env_tcl [get_property DIRECTORY [current_project]]/env.tcl |
5 | if {[file exists "${env_tcl}"]} {
|
6 | puts "sourcing ${env_tcl}"
|
7 | source "${env_tcl}"
|
8 | } |
9 | } |
Damit ist es mir Möglich, eine beliebige tcl-Datei automatisch auszuführen. grüße
daniel__m schrieb: > wie schon erwähnt sind diese Buttons projektübergreifend. Man könnte mit einem INIT-TCL passend zu jedem Projekt eine Serie solcher buttons in der GUI installieren.
M. W. schrieb: > Man könnte mit einem INIT-TCL passend zu jedem Projekt eine Serie > solcher buttons in der GUI installieren. Ich weiss aber nicht ob die dann bleiben. Wenn man das via Menue macht, werden auch einfach nur die Tcl Kommandos ausgefuehrt. Muesste man mal ausprobieren ob der Tcl Flow anderst ist.
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.