Datum:
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?
Datum:
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
Datum:
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.
Datum:
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.
Datum:
WIP <= '1', '0' after 100 ns;
Datum:
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).
Datum:
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...
Datum:
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!
Datum:
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... ;-)
Datum:
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?
Datum:
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.
Datum:
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.
Datum:
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.
Datum:
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
Datum:
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...
Datum:
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.
