VHDL Simulationsmodell: Signal nach bestimmter Zeit rücksetzen

[anonymous (Gast)]

Hallo,

schreibe gerade an einem Simulationsmodell in VHDL (muss also nicht 
synthetisierbar sein) und hänge an folgendem Problem:
Zu einem bestimmten Zeitpunkt wird ein Signal (im Code unten WIP) aus 
einem Prozess heraus auf eins gesetzt. Ich will jetzt, dass dieses 
Signal nach einer bestimmten Zeitspanne wieder auf 0 gesetzt wird und 
zwar unabhängig von anderen Signalen und ohne den restlichen Betrieb des 
Modells zu blockieren.

Versucht habe ich das so mit einem weiteren Prozess:

PROCESS
  BEGIN
    IF WIP = '1' THEN
      wait for tPP;
      WIP <= '0';
    END IF;
    WAIT ON WIP;
  END PROCESS;

Allerdings funktioniert das nicht, anstatt dass das Signal überhaupt auf 
1 geht, wird es zu X. Wenn ich den Process rausnehme, geht das Signal 
korrekt auf 1, also scheinbar sorgt der Prozess dafür, dass irgendwie 
gleichzeitig 0 und 1 getrieben wird (Ansonsten wird das Signal nur von 
dem einem anderen Prozess getrieben, der zuvor aber nur einmal aktiviert 
wird).

Jemand ne Idee wo der Fehler liegt, bzw was ich anders machen muss?

[user (Gast)]

also wenn das signal auf X geht kann es sein das du 2 treiber hast, 
versuche mal das signal als std_ulogic anstatt std_logic zu definieren, 
dann werden dir 2 treiber als fehler gemeldet

[Christian R. (supachris)]

Ein Signal darf nur einen Treiber haben. Externe Tristates mal 
ausgenommen. So einfach ist das. Du musst dir was anderes ausdenken, wie 
du das Problem löst.

[Mathi (Gast)]

Für Simulationscode gibt es verschiedene Möglichkeiten ein Signal aus 
verschiedenen nebenläufigen Anweisungen zu treiben. Ein paar Stichworte 
dazu: guarded signals/blocks, disconnect und null.

[Klaus Falser (Gast)]

WIP <= '1', '0' after 100 ns;

[Lattice User (Gast)]

Ab VHDL 2008 gibt es die force/release statements für den Zweck.
Verilog kann das übrigens schon lange.

[Klaus F. (kfalser)]

Lattice User schrieb:
> Ab VHDL 2008 gibt es die force/release statements für den Zweck.
> Verilog kann das übrigens schon lange.

Ihr denkt alle viel zu kompliziert.
Die Schreibweise

WIP <= '1', '0' after tPP;

ist extra für diesen Fall gemacht, eventuell mus man noch das Kennwort 
inertial oder transport einfügen (ich verwende dies so selten, deshalb 
muss ich jedesmal nachschauen).

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

Klaus Falser schrieb:
> WIP <= '1', '0' after tPP;
> ist extra für diesen Fall gemacht
Nicht ganz, denn anonymous schrieb:
> Zu einem bestimmten Zeitpunkt wird ein Signal (im Code unten WIP) aus
> einem Prozess heraus auf eins gesetzt. Ich will jetzt, dass dieses
> Signal nach einer bestimmten Zeitspanne wieder auf 0 gesetzt wird und
> zwar unabhängig von anderen Signalen und ohne den restlichen Betrieb
> des Modells zu blockieren.
Hier soll offenbar mit einem 2. Treiber ein Fehler in eine bestehende 
Simulation/Datenstrom eingebaut werden...

[anonymous (Gast)]

Erstmal danke an alle.

Die Schreibweise
WIP <= '1', '0' after tPP;
hatte ich auch schon probiert, funktioniert so nicht.
Das eigentliche Problem ist glaube ich, dass ich noch zu sehr versuche 
VHDL so wie C zu programmieren...
Werde mir eine andere Lösung ausdenken!

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

anonymous schrieb:
> Das eigentliche Problem ist glaube ich, dass ich noch zu sehr versuche
> VHDL so wie C zu programmieren...
In einer Testbench geht das.
Da tun Schleifen das, was man als C-Programmierer von ihnen erwartet... 
;-)

[Klaus F. (kfalser)]

Lothar Miller schrieb:
> Hier soll offenbar mit einem 2. Treiber ein Fehler in eine bestehende
> Simulation/Datenstrom eingebaut werden...

Kann sein, vielleicht sollte der OP einmal genauer erlären was er 
braucht.

anonymous schrieb:
> hatte ich auch schon probiert, funktioniert so nicht.

Was hat nicht funktioniert?

[anonymous (Gast)]

Zeigte wenn ich mich recht erinnere das gleiche Verhalten wie die andere 
Variante, WIP geht auf X. Kann es jetzt nicht noch einmal nachprüfen, da 
ich das ganze mitlerweile umgeschrieben habe. Danke trotzdem.

[Klaus F. (kfalser)]

anonymous schrieb:
> WIP geht auf X.

Kann/darf nicht sein.
Wenn WIP nur von einem Prozess getrieben ist (Zuweisung nur in einem 
Prozess), dann kann es keinen Konflikt geben.

[Christian R. (supachris)]

anonymous schrieb:
> (Ansonsten wird das Signal nur von
> dem einem anderen Prozess getrieben, der zuvor aber nur einmal aktiviert
> wird).

Klaus Falser schrieb:
> Kann/darf nicht sein.
> Wenn WIP nur von einem Prozess getrieben ist (Zuweisung nur in einem
> Prozess), dann kann es keinen Konflikt geben.

Oben schrieb er ja, dass er es von (mindestens) 2 Prozessen aus treibt.

[Harald (Gast)]

Christian R. schrieb:
> Ein Signal darf nur einen Treiber haben.
Es darf zu jedem Zeitpunkt nur einen Treiber haben

zu unterschiedlichen Zeiten kann es beliebige Treiber haben

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

Harald schrieb:
> Christian R. schrieb:
>> Ein Signal darf nur einen Treiber haben.
> Es darf zu jedem Zeitpunkt nur einen Treiber haben
> zu unterschiedlichen Zeiten kann es beliebige Treiber haben
Wenn wir schon beim Haarspalten sind, dann darf ein Signal gleichzeitig 
mehrere Treiber haben, solange die entweder a) den selben Pegel treiben 
und/oder b) der entstehende Konflikt aufgelöst werden kann...

[Klaus F. (kfalser)]

Harald schrieb:
> Christian R. schrieb:
>> Ein Signal darf nur einen Treiber haben.
> Es darf zu jedem Zeitpunkt nur einen Treiber haben
>
> zu unterschiedlichen Zeiten kann es beliebige Treiber haben

Das ist so falsch.
Ein Signal hat im Laufe der Simulation immer gleich viele Treiber, diese 
werden beim Starten der Simulation (Elaboration) erzeugt.
Jeder Prozess, der ein Signal schreibt, erzeugt einen Treiber.

Falls für ein Signal mehrere Treiber existieren, muss für diesen Typ 
eine Resolve Funktion existieren.
Std_logic hat eine solche, diese erzeugt z.B. ein 'X' wenn ein Treiber 
das Signal auf '0' will und der andere auf '1';
std_ulogic hat keine Resolution Funktion ( u = unresolved), und kann 
deshalb niemals aus zwei Prozessen gleichzeitig getrieben werden.

Für die Synthese kann man angeben, welches Verhalten man für std_logic 
im Falle wünscht ('X' gibt's ja dann nicht mehr !).
Man kann das Treiben aus 2 Prozessen komplett unterbinden, oder man kann 
die Werte z.B. oder oder und verknüpfen.

Es gibt auch noch den Fall der Guarded Signale, da kann man eine Treiber 
deaktivieren, aber das verwendet man kaum oder nicht und ist für die 
Synthese meines Wissens nicht unterstützt.