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)


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)


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)


Lesenswert?

Verilator ist ganz nett, aber leider nur für Verilog.

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


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)


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)


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)


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)


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


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)


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)


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)


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)


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


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)


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


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)


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)


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)


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)


Lesenswert?

muss man für GHDL tatsächlich noch Werbung machen?

ghdl -i xxx.vhd
ghdl -m xxx

von Martin S. (strubi)


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 :-)

von Hans Kanns (Gast)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

Hans Kanns schrieb:
> In Vivado kann man sich einen button generieren,

Kanns der Hans uns auch erklären, wie?

von Carl (Gast)


Lesenswert?


von Christoph Z. (christophz)


Lesenswert?

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.

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


Lesenswert?

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
von daniel__m (Gast)


Lesenswert?

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

von Markus W. (elektrowagi78) Benutzerseite


Lesenswert?

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.

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


Lesenswert?

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.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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