Hallo, gibt es eigentlich eine Umgebungsvariable, die signalisiert unter welchem Simulator eine Simulation aktuell ausgeführt wird? Danke!
Wegstaben Verbuchsler schrieb: > Zu wenig Informationen. Was ist denn daran unklar? user schrieb: > Bei Modelsim kann man die Version mit > > vcom -version > > bekommen. Ich würde gerne innerhalb der Testbench bestimmen können, welcher Simulator gerade geöffnet ist. Bestimmte Dinge sind nämlich simulatorabhängig. Klar kann man sowas über ein generic, parameter oder define (in verilog) einstellen, aber das muss man ja jedesmal von Hand machen.
Bernie schrieb: > Testbench... > simulatorabhängig... Aehm, normalerweise ist eine TB _nicht_ simulatorabhaengig. Und zur Laufzeit rausfinden 'von welchem Simulator bin ich denn gestartet worden' duerfte auch etwas 'interessant' sein...
berndl schrieb: > normalerweise ist eine TB nicht simulatorabhaengig. Es gibt aber Fälle, wo man sehr wohl unterscheiden muss. Z.B. wenn ich auf ein internes Signal in meinem Design aus einer System Verilog Testbench zugreifen möchte. In Modelsim schreibt man:
1 | assign x = model.untermodul.signalname; |
In VCS und ncsim sind das jeweils unterschiedliche Funktionsaufrufe. Möchte man also eine TB haben, die mit allen Simulatoren funktioniert, muss man hier eine Fallunterscheidung machen.
>System Verilog sags halt gleich: bei Verilog, und ich denke auch bei System-Verilog gibts doch Compiler-defines welche dann am besten gleich beim Simulatoraufruf gesetzt werden (etwa so ncdingsda -define-ichbinjetzteinCadencemurks vcdingsda -define-undnuneinteuersynopsysteil) im code dann so `ifdef undnuneinteuersynopsysteil) compiledies `endif http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.html -> 19.0 Compiler Directives -- uiui, ist das ein Firmen Projekt?, die Uhrzeiten sehen ja nach richtig Stress aus....
bko schrieb: > uiui, ist das ein Firmen Projekt? Hm, eine Firma, die mehrere, verschiedene, teure Simulatoren kauft? Na ich weiß ja nicht.
bko schrieb: > sags halt gleich: bei Verilog, und ich denke auch bei System-Verilog > gibts doch Compiler-defines welche dann am besten gleich > beim Simulatoraufruf gesetzt werden > (etwa so ncdingsda -define-ichbinjetzteinCadencemurks > vcdingsda -define-undnuneinteuersynopsysteil) > im code dann so > > `ifdef undnuneinteuersynopsysteil) > compiledies > `endif Ja, so habe ich mir das auch überlegt. Wir haben eh verschiedene Makefiles für die Simulatoren. Da könnte man dann gleich das define setzen. > uiui, ist das ein Firmen Projekt?, Ja, aber... > die Uhrzeiten sehen ja nach richtig Stress aus.... ... das täuscht. Wir hatten das Problem vor zwei Wochen etwas unelegant gelöst (define direkt in TB gesetzt). Jetzt - wo Zeit ist - wollte ich über eine schönere Lösung nachdenken (lassen). ;-) Danke!
Beim Start der Simulation könntest Du ein TCL-Script ablaufen lassen, das Dir den Namen der ausgeführten Datei liefert: set executing [file tail [info nameofexecutable]] Bei ModelSim z.B. steht nach Ausführen der obigen Zeile in "executing" der String "vish.exe". Ohne "file tail" bekommst du komplette Pfadangabe, die Du dann bei Bedarf weiter analysieren kannst (z.B. mit regexp). Hannes
Bernie schrieb: >> normalerweise ist eine TB nicht simulatorabhaengig. > > Es gibt aber Fälle, wo man sehr wohl unterscheiden muss. Z.B. wenn ich > auf ein internes Signal in meinem Design aus einer System Verilog > Testbench zugreifen möchte. In Modelsim schreibt man:assign x = > model.untermodul.signalname; dafuer definiere ich im Design Signale (oder einen Record), die mittels 'translate off/on' fuer die Synthese unsichtbar gemacht werden, fuer die Simulation jedoch bis zum Toplevel durchgeroutet werden. Das wird allerdings kompliziert, wenn du ein 'force' eines Signals tief im Design machen willst. Aber wozu soll ein 'force' in so einem Umfeld gut sein?
Warum sollte man sein Design verschandeln, wenn die Testbench auch unabhängig arbeiten kann? Zur Frage: Solange der Simulator über ein Script gestartet wird ists einfach: eine Datei anlegen, wo der verwendete Simulator drinne steht und in der Simulation die Datei auslesen.
VHDL++ schrieb im Beitrag #3457422: > Warum sollte man sein Design verschandeln, wenn die Testbench auch > unabhängig arbeiten kann? > > Zur Frage: Solange der Simulator über ein Script gestartet wird ists > einfach: eine Datei anlegen, wo der verwendete Simulator drinne steht > und in der Simulation die Datei auslesen. Gegenfrage: Warum soll ich mir in Verilog/VHDL Simulatorabhaengigkeiten einfangen (oder OS-Abhaengigkeiten? Linux/Windows?)? Vlt. habe ich auch mal einen Simulator, der kein TCL oder sowas kann. Mit Bordmitteln (Verilog/VHDL konform) spielt das alles keine Rolle...
Bernie schrieb: > Wegstaben Verbuchsler schrieb: > Ich würde gerne innerhalb der Testbench bestimmen können, welcher > Simulator gerade geöffnet ist. Bestimmte Dinge sind nämlich > simulatorabhängig. Klar kann man sowas über ein generic, parameter oder > define (in verilog) einstellen, aber das muss man ja jedesmal von Hand > machen. Hm, auch bei simulatoren gibt es immer wieder neue Versionen und neue Simualtoren darunter open source drängen auf dem Markt. Mit simulatorabhängigen Code muss man dementsprechenden die Testbench ständig aktuallisiert werden sonst bindet man sich auf Gedeih und Verderb an einen oder wenigen Hersteller. Die Modellpflege wird dadurch auch nicht einfacher wenn man wegen der "optimierten" testbench jahrzehntelang eine bestimmte simulatorversion lizensieren muß. MfG,
Du hast zwei Chancen, entweder du steuerst den Aufruf mit einem Makefile. Oder du nutzt das vhpi Interface und löst eine C Routine aus, die die Info zurückliefert. Kann aber auch von Simulator sehr unterschiedlich von Erfolg gekrönt sein.
Bernie schrieb: > berndl schrieb: >> normalerweise ist eine TB nicht simulatorabhaengig. > > Es gibt aber Fälle, wo man sehr wohl unterscheiden muss. Z.B. wenn ich > auf ein internes Signal in meinem Design aus einer System Verilog > Testbench zugreifen möchte. In Modelsim schreibt man: >
1 | > assign x = model.untermodul.signalname; |
2 | > |
> > In VCS und ncsim sind das jeweils unterschiedliche Funktionsaufrufe. > Möchte man also eine TB haben, die mit allen Simulatoren funktioniert, > muss man hier eine Fallunterscheidung machen. Neben dem simulatorabhängigen erzwingen von signalwerten gibt es andere herstellerunabhängige Verifikationstechniken bei denen interne Signale stimuliert werden: 1) Modul-Testbench Jedes Untermodule bekommt seine eigene testbench. Das grenzt die Fehlersuhce deutlich ein und ist signifikant schneller. Hat man die Funktion des Moduls so nachgewiesen, braucht die top-testbench nur noch das interface zum Submodule prüfen und fertig. Am besten man nutzt ein FPGA-internen Bus wie wishbone dann braucht man dieses Businterface nur einmal schreiben/testen und bindet es dann als template in die einzelnen module 2) BIST - Build In Self Test In das Design wird ein Testmodul (Genreator+comperator+controlinterface) miteingebunden. Also der Stimuligenerator wie in der testbench als eigenes modul, das dann an die jeweilige Unit Under Test geschaltet wird. Die Outputs kommen an einen Vergleicher der ebenfalls mit Sollpattern gespeist wird und Nichtübereinstimmungen zählt. Entwirft man dieses Testmodul synthetisierbar hat man gleich einen Selbsttest für den FPGA. Gut für Produktionstest, Klimatest, Analyse von Rückläufern ... MfG,
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.