Hallo, ich würde euch gerne XNetSim vorstellen. Dabei handelt es sich um einen HDL-Simulator, welchen ich entwickelt habe. Anders als GHDL oder iverilog enthält er keinen Parser. Stattdessen werden Xilinx Netzlisten simuliert. Man erzeugt sich mit Xilinx utilities eine Netzliste im EDIF format und kann diese dann mit XNetSim in eine cpp-Datei umwandeln. Diese kann dann mit gcc kompiliert werden und mit einer in C++ geschriebenen Testbench gelinkt werden. XNetSim ist im allgemeinen deutlich performanter als GHDL in der Ausführung, allerdings langsamer bei der Kompilierung. Ein Vorteil gegenüber GHDL die "Bug-kompatibilität" zum Xilinx synthesizer. Außerdem ist das erstellen von Testbenches C++ komfortabler, beispielsweise lässt sich bequem eine Binärdatei schreiben oder lesen. Leider bietet XNetSim zur Zeit keinen Support zum Ausgeben von .vcd-Dateien und damit kann auch kein GtkWave zur Visualisierung verwendet werden. Projektseite: http://xnetsim.sourceforge.net/
Ich hab mir das mal angeschaut. Es gibt einfach viel zu viele funktionale beschränkungen. Warum keine umsetzung EDIF->SystemC netzliste mit darunterliegender library für die primitives? Fertig. * alles drin (asynchrone set's, beliebige anzahl von clock's ...) * simulations kernel dabei, inclusive ausgabe von waves * Standardisiert!!! Wenn du zeit hast, wäre der weg über die backannotierte vhdl/verilog netzliste mit SDF timing sogar noch besser. Damit könnte man sogar das Zeitverhalten mit reinbringen.
Ottmar schrieb: > Wenn du zeit hast, wäre der weg über die backannotierte vhdl/verilog > netzliste mit SDF timing sogar noch besser. Damit könnte man sogar das > Zeitverhalten mit reinbringen. Warum sollte man das nochmal ausprogrammieren? Das macht doch ein VHDL Simulator?
Primäres Ziel von XNetSim ist Performance. Ich habe zwar noch nie mit SystemC gearbeitet, deswegen kann ich jetzt falsch liegen - aber ich vermute, dass die Benutzung einer Primitivlibrary für SystemC um Größenordnungen langsamer wäre (vermutlich langsamer als GHDL). Die Performance des Simulators kann entscheidend sein wenn man größere Systeme über längere Zeit simulieren muss (beispielsweise einen Hardwareraytracer).
Ich möchte deine Arbeit nicht schlecht machen, weil Du sicher viel Zeit hineingesteckt hast, aber meiner Meinung nach fehlt wahrscheinlich der Nutzen. Das Szenario ist doch eigentlich folgendes : 1) Man entwickelt ein VHDL oder Verilog Programm und debuggt/verifiziert es mittels VHDL (Verilog) Testbenches. Dabei kann man verschieden Ebenen der Abstraktion verwenden, am Ende hat man RTL Modelle, welche die Synthese ersteht. 2) Man synthetisiert die Modelle und bekommt eine Netzliste. Will man diese Netzliste verifizieren um die Synthese zu kontrollieren, dann ist es doch einfacher, die bestehenden Testbenches wiederzuverwenden, welche man im Schritt 1) ohnehin entwickelt hat. Die Testbenches neu zu schreiben ist aufwendig und fehleranfällig, weil man nicht weiß, ob sie mit den Originalen übereinstimmen. Ein Debuggen auf dieser Ebene ist komplex und aufwändig, deshalb macht man eines Simulation an dieser Stelle in der FPGA-Welt eh nur, wenn man irgendwelche unerklärbaren Probleme hat. Das ist wie beim normalen Programmieren, zuerst ist immer der Compiler schuld, aber am Ende findet sich meistens eine andere Erklärung. 3) Man routet das Design und bekommt wieder eine Netzliste, diesmal mit den Timinginformationen. Es gelten wiederum alle Argumente aus Schritt 2). Etwas anderes wäre es, wenn man direkt in System C entwickelt und die C Testbenches schon hat, aber darüber kenne ich mich überhaupt nicht aus.
Die Idee an XNetSim ist, dass man die Testbenches eben nicht in VHDL schreibt. Man überspringt also deinen "Schritt 1" und muss daher auch keine bestehenden Testbenches neu entwickeln. Das Debuggen der Netzliste ist nicht zwingend komplizierter als das Debuggen von VHDL-Code. Natürlich hat man beim Debuggen von VHDL-Code mehr Möglichkeiten interne Signale anzuzeigen, da zu diesem Zeitpunkt noch genügend semantische Information (Signalname/-typ, Designhierarchie) vorhanden ist. Dies lässt sich allerdings lösen indem man zum Debuggen mit XNetSim eine spezielle Netzliste synthetisiert, welche interne Signale nach aussen leitet. Eine Möglichkeit ist die Verwendung des C-Präprozessors (#ifdef XNETSIM_DEBUG ...). Ich finde dass C++ eine wesentlich mächtigere und komfortablere Sprache zur erstellung von Testbenches ist als VHDL. Alternativ zu XNetSim könnte man natürlich auch Verilog/C++ oder SystemC einsetzen. Ich möchte nochmals betonen dass es bei XNetSim vor allem Performance, Bug-kompatibilität zum Xilinx synthesizer und Benutzbarkeit geht. Diese drei Punkte konnte mir bisher keine Simulationsumgebung bieten. SystemC finde ich persönlich unbenutzbar - es stellt für mich keine Alternative dar.
Alexander Schade schrieb: > Das Debuggen der Netzliste ist nicht zwingend komplizierter als das > Debuggen von VHDL-Code Das ist ein bischen als ob man sagen würde: Das Debuggen von Assemblerprogrammen ist nicht komplizierter als das Debuggen von C/C++ Programmen. > Natürlich hat man beim Debuggen von VHDL-Code > mehr Möglichkeiten interne Signale anzuzeigen, da zu diesem Zeitpunkt > noch genügend semantische Information (Signalname/-typ, > Designhierarchie) vorhanden ist. Es geht nicht nur um die Darstellung interner Signale, es geht um die Korrektheit des Designs selbst. Man kenn in VHDL nicht initialisierte Signale oder Konflikte finden (std_logic unterscheidet zwischen mehr als 0 und 1), man kann Bereichsüberläufe finden, usw. In der Netzliste hast Du nur mehr 1 oder 0. Deshalb kann man auf Schritt 1) (siehe oben) eben nicht verzichten. > Ich finde dass C++ eine wesentlich mächtigere und komfortablere Sprache > zur erstellung von Testbenches ist als VHDL. Darf ich fragen, wieviel Erfahrung Du mit VHDL und FPGA Entwurf hast? > Ich möchte nochmals betonen dass es bei XNetSim vor allem Performance, > Bug-kompatibilität zum Xilinx synthesizer und Benutzbarkeit geht. Performance kann sein, das kann ich nicht beurteilen. Diese geht aber eben zu Lasten der Information, die man aus so einer Simulation herausbekommt. Wie gesagt, ich möchte Dein Programm nicht schlecht machen, aber Du hast es hier vorgestellt und damit zur Diskussion gestellt und ich sehe die Benutzbarkeit eben nicht.
> Wie gesagt, ich möchte Dein Programm nicht schlecht machen, aber Du hast > es hier vorgestellt und damit zur Diskussion gestellt und ich sehe die > Benutzbarkeit eben nicht. Das ist richtig, ich habe mein Projekt hier zur Diskussion gestellt. Ich habe gegen Ihre Meinung auch überhaupt nichts einzuwenden. Viel mehr bedanke ich mich für Ihr Feedback und würde mich freuen, wenn sich auch noch andere zu diesem Thema äußern.
habe gegen Ihre Meinung auch überhaupt nichts einzuwenden. Viel mehr > bedanke ich mich für Ihr Feedback und würde mich freuen, wenn sich auch > noch andere zu diesem Thema äußern. Komentar: Als Ausgabefile eignet sich das Format ghw für VHDL besser. Eine C++ Simulator als Ziel. Dazu muss ich jein sagen. SystemC ist eine Verrecker geworden. Das hast du selber schon so eingesehen. Wie der Simulator intern läuft ist eine Frage die fast uninteressant ist. Wichtig ist das Simulierte muss mit dem was gefittet wird übereinstimmen. Ich komme mit GHDL gut zurecht. GHDL hat auch eine C Schnittstelle. http://www.myhdl.org/doku.php/dev:vhdl_cosim Diese kann nicht alles und ist auch nicht sonderlich dokumentiert. Ich würde mich freuen, wenn es eine Ergänzung zu GHDL wäre. Gerade die UNISIM lässt sich bescheiden simulieren. Da hat Xilinx bei Herstellerspezifischen Komponenten den VHDL Code nicht ganz sauber. Als Intergation mit GHDL gäbe es eine Kampftwertsteigerung. Dann hättes du einen Teil beigetragen und kannst bereits wichtige Komponenten mit nutzen, als wieder ein Simulator unter den Simulatoren die nicht wieder alles können. Auch die Entwickler der "Freien Tools" müssen sich organisieren und zusammenarbeiten. Generell: Eine Schnittstelle zu C finde ich ganz gut. Die Hohheit muss VHDL haben.So kann man am Anfang Komponenten ich C schreiben und Simuliern und nach und nach die in C geschriebenen Komponenten durch VHDL ersetzen. Schön wäre es, wenn es noch ein ordentliche Dokumentationstool wie UML oder ähnliches gebe.
Da ja hier viele den Nutzen nicht gesehen haben, ich habe da womöglich einen: In der Firma haben wir ein System, dass zu einem Teil aus FPGA besteht zum anderen einen Prozessor einsetzt. Ich glaube ich werde mir XNetSim aus genau einem Grund genauer ansehen: er eignet sich vermutlich dazu das Zusammenspiel zwischen unserem Prozessor und dem FPGA zu debuggen. Hauptsächlich um unsere Software zu debuggen haben wir die Funktionalität, die im FPGA abläuft noch einmal in C nachgeschrieben (mit all dem Aufwand und der Fehlerträchtigkeit). Dies ließe sich durch XNetSim vermeiden, wenn ich die Netzlisten dazu nutzen kann ein Softwaremodell des FPGAs zu erstellen. Also danke für die Arbeit, ich bin mal gespannt, wann ich dazu komme. Es könnte ein Baustein sein, den ich schon lange gesucht habe! Zum Thema Verifizierung des Designs schließe ich mich den Gedanken der anderen Teilnehmer hier an. Wir haben begonnen mit Typen in VHDL sehr penibel zu arbeiten, da dies häufig auch schon Hinweise auf Designfehler liefern kann.
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.