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:> 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,
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten