time-Signal mit Werte belegen

[Roberto (Gast)]

Hallo zusammen,

ich möchte gerne in einer Testbench eine Zeit ändern können.
Dazu möchte ich gerne ein Integer-Wert in einem Script setzen und danach 
entsprechend die Zeit ändern können.

-- port
PERIODE : OUT time;
...

-- signal
SIGNAL integer_wert : integer  := 0;

integer_wert wird dann via Textdatei/Script mit einem Wert belegt, den 
ich gerne auswerten/verwenden möchte.

PERIODE <= 100 us WHEN integer_wert = 100;

Ideal oder noch eleganter wäre auch irgendwie folgende Zuweisung:

PERIODE <= integer_wert us;

Aber beides geht irgendwie nicht.
Ich habe noch nie richtig mit dem time-Typ gearbeitet, mir fehlen 
scheinbar noch Grundkenntnisse, wie damit umzugehen ist.

Hat jemand eine Lösung parat?

Vielen Dank!
Rob

[Duke Scarring (Gast)]

Roberto schrieb:
> PERIODE <= integer_wert us;

Probiere mal folgendes:

  PERIODE <= integer_wert * 1 us;

Duke

[Andreas (Gast)]

Genau so

>

 PERIODE <= integer_wert * 1 us;

und wenn es richtig cool werden soll, kannst du dafür noch ein Generic 
vergeben und damit dann per Scriptruf bspw. im Modelim die Periodendauer 
einstellen.

sieht dann so aus (bsp Periodendauer ist dann fünfzig):

vsim -gMyGeneric=50 work.MyTb

Viele Grüße

[Roberto (Gast)]

Vielen, vielen Dank!
Diese Lösung ist wieder viel zu simpel zum selber drauf kommen *Kopf => 
Tisch*

Aber so richtig scheint es noch nicht zu funktionieren.
Ich bekomme jetzt zwar das compile durch, aber in der Simulation meckert 
er mir jetzt direkt bei 0ps an, dass PERIODE scheinbar noch keinen Wert 
hat, obwohl ich es meiner Meinung nach sauber initialisiere.

# ** Fatal: (vsim-3343) Negative time value (-9223372036854775807) in wait statement.

SIGNAL s_periode : integer  := 100;
...
PERIODE <= s_periode * 1 us;

Muss ich bei der Verwendung vom Typ "time" noch etwas anderes beachten, 
als bei normalen Signalen?

Vielen Dank!
Rob

[Klakx (Gast)]

vielleicht stört er sich, dass integer einen negativen bereich hat. 
probier mal die definition als natural (integer nehm ich sehr selten und 
wenn dann auch nur mit eingeschränkten bereich)

[Roberto (Gast)]

Leider nein, wenn ich es folgendermaßen erweitere/versuche

SIGNAL s_periode : integer range 0 to 200 := 100;

SIGNAL s_periode : natural := 100;

SIGNAL s_periode : positive:= 100;

kommt immer die identische Fehlermeldung:

# ** Fatal: (vsim-3343) Negative time value (-9223372036854775807) in wait statement.

:(

[Duke Scarring (Gast)]

Roberto schrieb:
> PERIODE <= s_periode * 1 us;
Steht das in einem Prozess?

Duke

[Roberto (Gast)]

Hallo,

Duke Scarring schrieb:
> Steht das in einem Prozess?

Nein, habe es als sequentielles statement geschrieben.

[Roberto (Gast)]

Bisher hatte ich die PERIODE als Konstante in einem package definiert. 
Da ich aber keine Lust hatte, das immer wieder neu zu kompilieren, habe 
ich mich für das Script entschieden.

Die Konstanten werden schon beim compile gesetzt und sind ab der ersten 
ps der Simulation fest gesetzt.

Alle anderen Signale/Variablen nehmen bei 0ps irgendwelche komischen 
Werte ein, die dann Einfluss auf die Simulation haben.
Das gleiche Problem habe ich jetzt an einer anderen Stelle, wo ich 
PERIODE auswerte. Dort habe ich bei einer range von 0 bis 127 auf einmal 
ganz am Anfang der Simulation eine -1 stehen, obwohl ich die 
entsprechende Variable mit 0 initialisiere!

Sehr merkwürdig...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Roberto schrieb:
> Alle anderen Signale/Variablen nehmen bei 0ps irgendwelche komischen
> Werte ein, die dann Einfluss auf die Simulation haben.
Das sind keine "komischen" Werte, sondern sehr definierte, nämlich 
jeweis der "linkeste" des entsprechenden Typs...

Roberto schrieb:
> Das gleiche Problem habe ich jetzt an einer anderen Stelle, wo ich
> PERIODE auswerte. Dort habe ich
Ja, wo denn? Ohne Quelltext kommt jeder "Rat" von "raten"...

[Roberto (Gast)]

Hallo,

Lothar Miller schrieb:
> Das sind keine "komischen" Werte, sondern sehr definierte, nämlich
> jeweis der "linkeste" des entsprechenden Typs...
Ja ok, an der Stelle habe ich mich sicher etwas "komisch" ausgedrückt ;)

Wie kann man denn verhindern, dass Signale zu Beginn der Saimulation den 
"Linkesten" Wert annehmen, wenn ein normales init  mit := bei der 
Definition nicht ausreicht?

Vielen Dank!
Rob

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Roberto schrieb:
> Wie kann man denn verhindern, dass Signale zu Beginn der Saimulation den
> "Linkesten" Wert annehmen, wenn ein normales init  mit := bei der
> Definition nicht ausreicht?
Zeig mal ein Beispiel, wo das nicht reicht...
Ich könnte mir da bestenfalls Signale vorstellen, die nicht speichern 
können, und von woanders einen Wert zugewiesen bekommen, der den 
Initwert überschreibt.