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.
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".
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
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.
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 :-(
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.
