Forum: FPGA, VHDL & Co. Kostenloser HDL Simulator


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Vivado nervt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Manfred Malicious (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von abs (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Verilator ist ganz nett, aber leider nur für Verilog.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Manfred Malicious (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ß!?

von Manfred Malicious (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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/

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Markus F. (mfro)


Bewertung
1 lesenswert
nicht lesenswert
muss man für GHDL tatsächlich noch Werbung machen?

ghdl -i xxx.vhd
ghdl -m xxx

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.