Forum: FPGA, VHDL & Co. Aktuellen Simulator herausfinden


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bernie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gibt es eigentlich eine Umgebungsvariable, die signalisiert unter 
welchem Simulator eine Simulation aktuell ausgeführt wird?

Danke!

von Wegstaben V. (wegstabenverbuchsler)


Bewertung
0 lesenswert
nicht lesenswert
Hä?

Zu wenig Informationen.

: Bearbeitet durch User
von user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bei Modelsim kann man die Version mit

vcom -version

bekommen.

von Bernie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Bernie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von bko (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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....

von Christian R. (supachris)


Bewertung
0 lesenswert
nicht lesenswert
bko schrieb:
> uiui, ist das ein Firmen Projekt?

Hm, eine Firma, die mehrere, verschiedene, teure Simulatoren kauft? Na 
ich weiß ja nicht.

von Bernie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Hannes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von VHDL++ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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,

von René D. (Firma: www.dossmatik.de) (dose)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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,

: Bearbeitet durch User

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.