Hat jemand von Euch schon einmal mit Verilator gerarbeitet? Ich habe
mich mal ein wenig mit dem Tool beschäftigt und bin recht angetan. Die
Idee, ein synthetisierbares (System)Verilog-Modell in C++ zu
transformieren und eine C++-Testbench zu schreiben, finde ich
interessant. Die Autoren behaupten, dass die Simulation schneller läuft
als jedes kommerzielle Tool. Zumindest was Modelsim/Questa angeht, kann
ich das bestätigen für die Modelle, die ich bisher probiert habe.
Es gibt natürlich ein paar Nachteile: Jedes Modul muss als
synthetisierbarer (System)Verilog-Code vorliegen (ja, obwohl es ein
Simulationstool ist). Netzlisten, VHDL-Modelle oder verschlüsseltes Zeug
funktioniert nicht. Auch viele Simulationsmodelle von Xilinx lassen sich
nicht übersetzen, weil der Code Sprachelemente außerhalb des
Synthesis-Subsets enthält. Da hilft nur Inference, wo immer es geht (was
mir persönlich ohnehin lieber ist als generierte IPs aus irgendwelchen
obskuren Generatoren).
Ich denke, man kann auch Funktionen in C++ implementieren und in die
Simulation einbinden, falls kein synthetisierbarer Verilog-Core
verfügbar ist.
Ein paar Klimmzüge erfordern auch Designs mit mehreren Clockdomains,
aber das funktioniert wohl auch irgendwie, habe ich aber noch nicht
getestet. VCD-Traces können auch erzeugt werden, ebenso wie die Ausgabe
von internen Signalzuständen mit printf(). Alle internen Signale des
Modells sind aus der C++-Testbench über Referenzen zugreifbar.
Verilator ist in aktiver Entwicklung (Version 4.016 ist ein paar Tage
alt) und wird von den Opensource-HW-Leuten rege verwendet, z.B. in der
RISC-V-Community.
Anmerkungen, Erfahrungen, Kritik dazu?
Ich hab ein paar (fast)voll Chip Simulatoren damit gemacht. Weil die
Firmware Entwickler damit besser zu recht kommen als mit einem Verilog
Simulation. Aber unser Codebase ist synthethisierbar weil es für einen
ASIC benutzt wird.
Muss du ein bisschen in C oder C++ dazu programmieren und hast was
brauchbares was nicht post-mortem ist.
Weltbester FPGA-Pongno schrieb im Beitrag #5881192:
> Muss man das noch kommentieren?
Die gleichen Einschränkungen wie bei GHDL: Kein Verilog, keine
Netzlisten, keine verschlüsselten Cores.
Moin,
muss doch gerade den Thread nochmal aufwecken..
Ich wuerde gerne ein Design (auch mal wieder RISC-V-basiert), was in
VHDL und Verilog ausgegeben werden kann, sauber fuer beide Seiten
verifizieren. Fuer VHDL ist das soweit abgehakt. Fuer die Verilog-Seite
gibt es jedoch ein paar echte Stolperfallen, da viel implizite
Konversion vor sich geht, ergo gewisse Szenarien nicht ganz abzudecken
sind (bzw. sich die Auslegung des 'Standards' nicht direkt erschliesst).
Mit 'works for me'-Zustand waere ich aber zufrieden, darum wuerde ich
alles einfach auf den Simulator abwaelzen, und hoffen, dass der das
schon richtig umsetzt. Mit Icarus verilog geht das so so la la.
Jetzt gibt's da ein neues Framework "Renode", was so etwa meiner
gewohnten Co-Simulations-Umgebung zu entsprechen scheint, was neuerdings
Verilator unterstuetzt.
Fragen:
- Jemand damit schon gearbeitet?
- Gibt's bei Verilator irgendwelche Ueberraschungen zu erwarten, also
sowas wie: Simulation ok, Synthese-Ergebnis rechnet falsch (weil man
wieder irgendwo eine implizite Konversion stehen hat)?
Vancouver schrieb:> VHDL-Modelle oder verschlüsseltes Zeug> funktioniert nicht.
... und Tschüss! Gerade die umfangreichen Cores und daraus gewonnenen
Netzlisten sind ja die Hauptbremse bei der Simulation. Dafür braucht man
eine Lösung. Also NETLIST2SYSTEMVERILOG oder sowas, wollte man mit
externen Simulatoren arbeiten.
Jürgen S. schrieb:> Also NETLIST2SYSTEMVERILOG oder sowas, wollte man mit> externen Simulatoren arbeiten.
Netzlisten kann man sich notfalls ja von den Tools wieder in V* ausgeben
lassen (aber hat dann natuerlich die Bremse drin). Ansonsten soll es
auch Leute geben, die mit xlxunprotect.py und Konsorten arbeiten.
Will aber in der RISC-V-Welt sowieso keiner mehr, da das
OpenSource-Moment viel zu gross ist.
Martin S. schrieb:> Gibt's bei Verilator irgendwelche Ueberraschungen zu erwarten, also> sowas wie: Simulation ok, Synthese-Ergebnis rechnet falsch (weil man> wieder irgendwo eine implizite Konversion stehen hat)?
Nach meiner Erfahrung bisher nicht. Verilator simuliert ja keine reinen
Simulationsmodelle sondern nur synthesefähigen Code. Zudem legt
Verilator den SystemVerilog-Standard deutlich strenger aus als z.B.
Modelsim. Bei einem Modell, dass in Modelsim problemlos läuft, hagelt es
in Verilator typischerweise Warnings. Mann kann ich dann überlegen, die
abzuschalten oder den Code glatt zu ziehen. Was hingegen in Verilator
läuft, synthetisiert auch korrekt.
Und ja, wenn man komplexe IPs simulieren will, die nicht im Sourcecode
vorliegen, ist man mit Verilator aufgeschmissen. Da muss man dann
entweder selbst ein vereinfachtes Modell schreiben, oder versuchen,
diesen Teil in C++ nachzubilden. In vielen Fällen lassen sich
vereinfachte Modelle relativ leicht schreiben, weil Verilator zwar
synthesefähigen Code erwartet, aber nur zyklengenau simuliert. Man kann
dann das Modell so schreiben, dass es simulierbar ist, aber in der
Realität ein grottenschlechtes Timing hätte, wenn man es tatsächlich
simulieren würde.
Die "Rückübersetzung" eines Designs in Verilog (z.B. mit Vivado) habe
ich einmal probiert, aber das ließ sich nicht simulieren, weil der so
erzeugte Code Statements enthielt, die außerhalb des Sythesesubsets
liegen und daher nicht von Verilator simuliert werden können. Klingt
paradox, ist aber so. Ich habe das aber nicht weiter verfolgt,
vielleicht geht es doch irgendwie.
Man muss sich halt vor Augen halten, dass Verilator ausdrücklich für
OpenSource-Designs gedacht ist und auch keinen Ersatz für einen
klassischen Event-Driven Simulator darstellt.
Vancouver schrieb:> aber in der> Realität ein grottenschlechtes Timing hätte, wenn man es tatsächlich> simulieren würde.
synthetisieren würde meinte ich, sorry
Vancouver schrieb:> Die "Rückübersetzung" eines Designs in Verilog (z.B. mit Vivado) habe> ich einmal probiert, aber das ließ sich nicht simulieren, weil der so> erzeugte Code Statements enthielt, die außerhalb des Sythesesubsets> liegen und daher nicht von Verilator simuliert werden können. Klingt> paradox, ist aber so. Ich habe das aber nicht weiter verfolgt,> vielleicht geht es doch irgendwie.
Hab' das nur mit ISE und GHDL bisher hinbekommen. Bei anderen
Herstellern auch mal mit icarus. Wenn ich jetzt nicht falsch liege, hat
das Tool einfach die Netzliste in vereinfachte (logische)
FPGA-Primitiven wieder ausgegeben, und deren Simulationsmodelle lagen
wohl alle vor.
Xilinx scheint aber immer noch ab und an den Standard zwecks Vendor
Lock-in zu verstuemmeln, weiss nicht, wie der Stand mit Vivado ist.
Danke auf jeden Fall mal fuer den Hinweis betr. Verilator. Vielleicht
ist doch irgendwann mal ein Umstieg faellig...
Martin S. schrieb:> Wenn ich jetzt nicht falsch liege, hat> das Tool einfach die Netzliste in vereinfachte (logische)> FPGA-Primitiven wieder ausgegeben, und deren Simulationsmodelle lagen> wohl alle vor.
Ja, genau das wird gemacht. Aber Verilator möchte wie gesagt
synthesefähigen Code haben, und die Post-Synthesis-Modelle sind
anscheinend nicht synthetisierbar. GHDL hingegen versteht auch reine
Simulationsmodelle.
