Tag,
S'EVENT is true if signal S has had an event this simulation cycle.
S'ACTIVE is true if signal S is active during current simulation
cycle.
Die Erklärung ist viel zu knapp. Weil ich das nicht verstanden habe,
habe ich folgenden Code geschrieben
1
architecturemainofmainis
2
signalx:std_logic:='0';
3
signaly,z:std_logic;
4
signalxevent,yevent,zevent:boolean;
5
signalxactive,yactive,zactive:boolean;
6
begin
7
8
x<='0'after1ns,'1'after10ns,'1'after15ns,
9
'1'after20ns,'0'after30ns;
10
y<=x;
11
z<=y;
12
13
xevent<=x'event;
14
yevent<=y'event;
15
zevent<=z'event;
16
17
xactive<=x'active;
18
yactive<=y'active;
19
zactive<=z'active;
20
end;
Die Simulation mit ModelSim ergibt das Bild im Anhang.
Wie ich sehe, gibt es keinen Unterschied zwischen sig'event und
sig'active.(?) Wozu gibt es beides?
Und noch etwas erstaunt mich: Warum verbleiben die event Werte auf true
wenn neuer Simulationzyklus anfängt?
So long .. daniel
> Warum verbleiben die event Werte auf true> wenn neuer Simulationzyklus anfängt?
Weil nur mit einem neuen Event die Simulation durchgerechnet wird.
Solange auf den beteiligten Signalen Ruhe herrscht, wird nichts mehr neu
berechnet.
Sonst müsste der Simulator jede Femtosekunde deines Designs
durchrechnnen, und dafür reicht weder deine Rechenleistung noch deine
Zeit.
Soweit ich weiss, arbeiten die meisten diskreten Simulatoren über
zeitgesteurte Listen, in denen sie sich Signalwege auf "Wiedervorlage"
legen: Wenn das Ergebnis einer Berechung zum Zeitpunkt 0 nach 7ns
vorliegt, schiebt er es 7000 Positionen nach hinten. Den
Zeitvergleichszähler schieben sie dann zum nächstnötigen Listenwert, der
aus dem Minimum der Zeitwerte gebildet wird, die beim letzten Durchgang
angefallen sind. Um Rechenzeit zu sparen, werden aehnliche Zeitpunkte
zusammengefasst. Daher brauchen die meisten Simulatoren auch ein
definiertes Zeitintervall.
Bei einer voll ereignisgesteuerten Simulation gäbe es bei "krummen"
Clocks und Verzögerungen sehr schnell eine Riesenliste mit demnächst
abzuarbeitenden Events.
Bei einer Pfad-gesteuerten Simulation ist das nicht so: Da sind
allemöglichen Verzögerungen bis auf undenkbar kleinste Zeitabschnitte
möglich - jeder Pfad kostet trotzdem dieselbe Rechenzeit. Für
Digitalschaltungen ist das aber viel zu aufwändig.
S'EVENT is true if signal S has had an event this simulation cycle.
S'ACTIVE is true if signal S is active during current simulation
Übrigens fällt mir auf, dass das die Erklärungen rekursiv sind.
Auf die Art: Eine Kugel hat eine Kugelform.
Zum Thema:
@Lothar
Ich glaube Du hast mich etwas missverstanden(oder ich Deine Antwort).
Angenommen der Simulator bewegt sich vor zum Zeitpunkt (10 ns, 0 delta)
an dem für x eine '1' eingetragen ist. Der Simulator schaut was
x im Moment für einen Wert hat. Wenn x='1' ist, dann passiert auf
x kein event <=> x'event = false. Wenn dagegen x='0' ist, dann
x'event = true. Jetzt werden Prozesse ermittelt, die auf x-Evente
"hören". Da wäre zB y <= x; Anweisung. Delta-cycle wird inkrementiert
und wir kommen am Zeitpunkt (10 ns, 1 delta) an.
Ist zu diesem Zeitpunkt x'event immernoch true? Immerhin wird in
diesem delta cycle x nicht seinen Wert ändern.
Analog zu dieser Überlegung: y'event war @(10 ns, 0 delta) false,
da ja nur x eine Transaktion hatte. y'event wird aber @(10 ns, 1 delta)
true werden, da neuer Wert zugewiesen wird.
Das heisst, die sig'event brauchen nicht über den ganzen Simulations-
zeitpunkt (10 ns, all delta) konstant zu sein. Was ich mich
jetzt frage: Dürfen sie aus welchen Gründen auch immer nur von
false->true übergehen oder auch in die andere Richtung.
Der Teufel steckt im Detail.
Meine Meinung war die, dass nach dem Simulator die "Hörer"-Prozesse
von x aufgeweckt und ausgeführt hat, und gegebenfalls weitere
Prozesse angestossen hat, kommt es zur Ruhe .. und alle signale
haben ihre events auf false. Erst jetzt springt Simulator weiter
(braucht also keine femtosekunden durchzuschleifen) zum Listeneintrag
der zeitlich am nächsten kommt.
Hmm ...
'event wird nur dann true wenn sich das Signal ändert.
'active wird dann true, wenn eine neue Zuweisung gemacht wird.
In deinem Beispiel ist
x'event zu den Zeiten 1 ns, 11 ns und 76 ns true
x'active zu den Zeiten 1 ns, 11 ns, 26 ns, 46 ns, 76 ns true
EDIT : Die Zeiten addieren sich nicht, entschuldigung .
Also :
x'event zu den Zeiten 1 ns, 10 ns und 30 ns true
x'active zu den Zeiten 1 ns, 10 ns, 15 ns, 20 ns, 30 ns true
die äquivalente Prozess-Beschreibung sieht so aus:
1
process(z)begin
2
ifz'eventthen
3
zevent<=z;
4
endif;
5
endprocess;
Und jetzt wird klar: der Prozess (und auch die entsprechende
Concurrent-Beschreibung) wird nur dann neu berechnet, wenn sich z
ändert.
> In deinem Beispiel ist> x'event zu den Zeiten 1 ns, 10 ns und 30 ns true
Aber entsprechend meiner Beschreibung oben wirst du da dann nicht einen
kurzen (delta t = 0) Spike/Peak/Event auf zevent sehen, sondern es wird
einfach nur der Pegel übernommen.
Und wenn du das Spiel mit 'active machst, kommt nicht so sehr viel
anderes heraus:
1
process(z)begin
2
ifz'activethen
3
zactive<=z;
4
endif;
5
endprocess;
Auch hier wird der Prozess nur dann neu berechnet, wenn sich z ändert.
Danke Lothar, Gast und Klaus.
Wenn es so ist wie Lothar es erklärt, dann ist add list * Kommadno
in ModelSim nicht wirklich nützlich.
Ich dachte z'event ist ein boolesches Signal und die Anweisung von oben
wäre
1
process(z,z'event)begin
2
ifz'eventthen
3
zevent<=z;
4
endif;
5
endprocess;
In anderen Worten in der Anweisung
1
zevent<=z'event;
würde ein Event am z'event stattfinden und der Wert sich übertragen.
Mal testen ob ModelSim z'event'event'event schluckt :)
> Mal testen ob ModelSim z'event'event'event schluckt :)
Bin gespannt und habe auch schon eine Vermutung.
Ich warte mal ab, was du zu dem Thema zu berichten hast ;-)
Das sollte nicht compilieren.
Warten kann man nur auf ein Signal, und z'event ist kein signal.
Du kannst aber auf z'transaction warten, das wäre ein signal.