Forum: FPGA, VHDL & Co. Unterschied zwischen EVENT und ACTIVE


von daniel (Gast)


Angehängte Dateien:

Lesenswert?

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
architecture main of main is
2
  signal x: std_logic := '0';
3
  signal y, z : std_logic;
4
  signal xevent, yevent, zevent : boolean;
5
  signal xactive, yactive, zactive : boolean;
6
begin
7
8
  x <= '0' after 1 ns, '1' after 10 ns, '1' after 15 ns,
9
      '1' after 20 ns, '0' after 30 ns;
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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Gast (Gast)


Lesenswert?

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.

von daniel (Gast)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

'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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

@  daniel
Deine Concurrent-Beschreibung ist:
1
  zevent <= z'event;
die äquivalente Prozess-Beschreibung sieht so aus:
1
  process (z) begin
2
     if z'event then
3
        zevent <= z;
4
     end if;
5
  end process;
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
     if z'active then
3
        zactive <= z;
4
     end if;
5
  end process;
Auch hier wird der Prozess nur dann neu berechnet, wenn sich z ändert.

von daniel (Gast)


Lesenswert?

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
     if z'event then
3
        zevent <= z;
4
     end if;
5
  end process;

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Klaus Falser (Gast)


Lesenswert?

1
process (z, z'event) begin
2
    if z'event then
3
        zevent <= z;
4
     end if;
5
end process;

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.