Ich will mich seit langem mal wieder mit HDL beschäftigen. Mir geht es für den Anfang vor allem um die Simulation und Verifikation einfacher Designs für Testzwecke. VHDL würde ich bevorzugen, würde mich aber zur Not auch in Verilog einarbeiten. Ich rätsele jetzt, auf welche Toolchain ich zurück greifen sollte? Aus dem Xilinx Webpack ist inzwischen ja ein anscheinend kontrovers diskutiertes Monstrum namens Vivado geworden. Und dann gibt es noch Quartus und die Lattice-Tools. Boards habe ich für alle drei. Am liebsten wäre mir allerdings eine open-source toolchain, bei der Ich nicht von irgendwelchen Lizenzen abhängig bin. Hier gibt es auch viel Auswahl: http://www.clifford.at/yosys/links.html https://semiwiki.com/wikis/industry-wikis/eda-open-source-tools-wiki/ Für mich ist die Praxistauglichkeit dieser ganzen Toolchains höchsts unklar. Hat jemand eine Empfehlung für eine eher unkomplizierte Variante?
Hm ok, das hier sieht spannend aus: https://www.edaplayground.com/
Gast
#6636953
Für Synthese oder nur Simulation? Für Simulation gibt es GHDL mit GTKWave.
Tim . schrieb: > Hat jemand eine Empfehlung für eine eher unkomplizierte Variante? Haette noch das hier anzubieten: https://github.com/hackfin/hdlplayground Dahinter stecken die ueblichen Verdaechtigen (yosys, iverilog, ghdl), als Frontend wird die Jupyter-Notebook-Umgebung missbraucht, so dass man's in einem Google-Binder laufen lassen kann (sonst natuerlich lokal als Docker-VM). Hauptfokus liegt aber auf MyHDL als top-level HDL, dementsprechend gibt's kaum integrierte VHDL-Beispiele. Grundsaetzlich kann yosys/nextpnr auf Lattice ECP5 schon komplexe Projekte schaukeln und macht recht Freude, da schnell. Vergleich: RISC-V SoC (mit Video-Encoder): - Lattice Diamond 3.11: 5-8 Minuten, davon Download fast 30 Sek - yosys/nextpnr: 1-2 Minuten Allerdings gibts Abstriche bei yosys: das Memory-Subsystem ist eine chaotische Baustelle, True Dual-Port mapping geht nur mit Hacks. Und Optimierung auf f_max ist noch so ein anderes Thema, macht Synplify besser.
Dussel schrieb: > Für Synthese oder nur Simulation? Für Simulation gibt es GHDL mit > GTKWave. Bezüglich der Synthese sieht es für VHDL immer noch etwas düster aus, oder? Allerdings scheint man GHDL erweitern zu wollen. Martin S. schrieb: > Haette noch das hier anzubieten: > > https://github.com/hackfin/hdlplayground Sie gut aus, vielen Dank!
Gast
#6637257
Tim . schrieb: > Dussel schrieb: >> Für Synthese oder nur Simulation? Für Simulation gibt es GHDL mit >> GTKWave. > > Bezüglich der Synthese sieht es für VHDL immer noch etwas düster aus, > oder? Allerdings scheint man GHDL erweitern zu wollen. Soweit ich weiß, versucht Yosys Synthese zu ermöglichen. Da aber vieles im Aufbau eines FPGA Firmengeheimnis ist, ist das ziemlich schwer und es ist auch nicht gesagt, dass die Resourcen am Ende effektiv genutzt werden.
Tim . schrieb: > Bezüglich der Synthese sieht es für VHDL immer noch etwas düster aus, > oder? Allerdings scheint man GHDL erweitern zu wollen. Das laeuft schon recht robust, grosse Teile des SoC sind VHDL. Siehe auch https://github.com/hackfin/masocist/tree/ghdlsynth_release oder https://github.com/antonblanchard/microwatt. Dussel schrieb: > Soweit ich weiß, versucht Yosys Synthese zu ermöglichen. Da aber vieles > im Aufbau eines FPGA Firmengeheimnis ist, ist das ziemlich schwer und es > ist auch nicht gesagt, dass die Resourcen am Ende effektiv genutzt > werden. Reverse Engineering ist gar nicht so wild, eher knifflig sind die rechtlichen Aspekte des 'Whiteboxing' (Offenlegung der gefundenen Informationen), da sind die Hersteller unterschiedlich entspannt. Und wie gesagt, yosys/nextpnr kriegen es beim ECP5 brauchbar hin.
Gast
#6637358
Tim . schrieb: > Am liebsten wäre mir allerdings eine open-source toolchain, bei der Ich > nicht von irgendwelchen Lizenzen abhängig bin. Auch Open Source kommt mit Lizenzen (bspw. CC-GPL), dein Argument ist also nicht wirklich eins. Tatsächlich scheint das Problem eher die Kosten zu sein, aber auch da hat so ziemlich jeder toolhersteller ein Angebot an kostenloser Nutzung. Oder zu Studentenfreundlichen Preisen. > Hat jemand eine Empfehlung für eine eher unkomplizierte Variante? Weil es dir um Simulation geht, nimm GHDL und lerner die klassischen tools wie makefile und tcl/python scripte. Und nutze Linux statt Windows.
Gast
#6637369
Ich habe gestern Intel Quartus für das Max1000 auf Ubuntu installiert. Das ging einigermaßen problemlos. Etwas knifflig ist vielleicht das man die udev-rules von Hand setzen muss. Aber auch da gibt es im MAX1000 Manual eine Anleitung.
So, habe mich jetzt mit GHDL, GTKWAVR und makefiles durchgeschlagen und mein uraltes CPU-Design* simulieren können. Siehe Projektfiles im Anhang. Es hat sich natürlich einiges an den Standards verändert, bzw. ist striker geworden und es gibt jetzt einen Haufen Warnungen. Sonst funktioniert aber alles. Ich frage mich an dieser Stelle aber, ob es nicht sinnvoller wäre auf Verilog umzusteigen? Ich weiß, dass das schon immer ein kontroverse Diskussion war. Allerdings scheint sich im Bereich der offenen Toolchains eher Verilog durchgesetzt zu haben, wie man an deutlich mehr tools und auch an den installationszahlen der extensions in VSCODE sieht. Die kommerziellen Hersteller halten sich natürlich neutral. Gibt es da stichhaltige Gegenargumente? *https://github.com/cpldcpu/MCPU
Für VSCode gibt es auch genug "Extensions" für VHDL. Persönlich habe ich "Modern VHDL 1.05". icarus verilog + GTKWave funktionieren auch prima. In der Firma haben wir verilog, auch wenn hier in DE ist, war auch selbst überrascht. VHDL kommt aber auch langsam dazu.
>https://github.com/cpldcpu/MCPU I like it. >Ich frage mich an dieser Stelle aber, ob es nicht sinnvoller wäre auf >Verilog umzusteigen? Ich hol schon mal Popcorn. Meine Prophezeiung nach ein paar durchaus sachlichen Beiträgen, werden nur noch persönliche Vorlieben vorgetragen. Mein Tipp, benutze das was Dir besser gefällt...
Gast
#6646970
Jonas B. schrieb: > Ich hol schon mal Popcorn. Gute Idee :-) Wenn ich Verilog-Code als Input habe, schreibe ich mir das nach VHDL um :-) Dafür mache ich mir als erstes eine Testbench (in VHDL), wo die Stimuli auf das Verilog-DUT und auf das VHDL-DUT gehen. Dann kann ich an den Ausgangssignalen sehen, ob meine Umsetzung korrekt ist. Bei der Gelegenheit bekommt man auch gleich Verständnis für die Schaltung, was dann im nächsten Schritt, der eigentlichen Codeerweiterung bzw. Anpassung, auch nützlich ist. So im direkten Vergleich fällt mir auf, das man einige Dinge in Verilog rudimentärer lösen muß. Zum Beispiel gibt es keinen ENUM-Typ. In VHDL geht das dann etwas eleganter und ist weniger fehlerträchtig. Duke
Duke Scarring schrieb: > Wenn ich Verilog-Code als Input habe, schreibe ich mir das nach VHDL um > :-) Fuer sowas gibt's doch `iverilog -tvhdl` (leider ohne parameter->generics). Tim . schrieb: > Ich frage mich an dieser Stelle aber, ob es nicht sinnvoller wäre auf > Verilog umzusteigen? Ich weiß, dass das schon immer ein kontroverse > Diskussion war. Es gibt zumindest lang diskutierte Gruende, warum man keine komplexe DSP mit Verilog machen sollte. Ich wuerde auch keine CPU mehr in einer der V*-Sprachen schreiben, da sich zuviele implizit-verworrene Fehler einschleichen koennen und man das mit aufwendigen Testbenches kompensieren muss. Die Python-Loesungen MyHDL und (n)migen machen da eine bessere Nummer, im Hinblick auf formale Verifikation. Sehr cool ist auch das 'libhwt' Oekosystem.
Ok, an der Kontroverse hat sich offensichtlich in den letzten Jahren nichts geändert :). Ich habe jetzt auch entdeckt, dass es ein erste Version von Yosys mit GHDL als Frontend gibt. Das reduziert den Zwang auf Verilog umzusteigen etwas. MyHDL sieht spannend aus. Aber das letzte Release ist von 2018? So etwas wirkt immer verdächtig.
Duke Scarring schrieb: > So im direkten Vergleich fällt mir auf, das man einige Dinge in Verilog > rudimentärer lösen muß. Zum Beispiel gibt es keinen ENUM-Typ. Ja, klassisches Verilog würde ich nie machen wollen. Über SystemVerilog könnte man mit mir diskutieren. Bei den meisten Fragestellern werden die zwei aber gleichgesetzt.
Tim . schrieb: > Ich habe jetzt auch entdeckt, dass es ein erste > Version von Yosys mit GHDL als Frontend gibt. Das reduziert den Zwang > auf Verilog umzusteigen etwas. Steht doch schon oben. Im obengenannten hdlplayground ist das GHDL-Plugin inkl. Beispiele enthalten. Allerdings nicht auf dem letzten Stand. Tim . schrieb: > MyHDL sieht spannend aus. Aber das letzte Release ist von 2018? So etwas > wirkt immer verdächtig. Ich wuerde sagen: Eher das Gegenteil. Aber korrekt, es findet momentan keine Weiterentwicklung in 'upstream' statt, was betr. einiger Feature-Requests sehr frustrierend ist, d.h. man muss damit leben oder seinen eigenen Fork unterhalten. Dafuer ist es stabil (10 jahre alter Code uebersetzt immer noch korrekt) und die Bugs sind ueberschaubar. Irgendwann kommt myhdl2 :-) Apropos: im hdlplayground ist auch ein weiteres Minimalbeispiel fuer einen 8-bitter inkl. Assembler (https://github.com/pcornier/1pCPU/blob/master/pCPU.ipynb) verlinkt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.