VHDL Simulationsmodell: Signal nach bestimmter Zeit rücksetzen

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.

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).

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 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... 
;-)

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 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.

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 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...

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.