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?
Vancouver schrieb: > Netzlisten, VHDL-Modelle oder verschlüsseltes Zeug > funktioniert nicht. Muss man das noch kommentieren?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.