www.mikrocontroller.net

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


Autor: daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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
architecture main of main is
  signal x: std_logic := '0';
  signal y, z : std_logic;
  signal xevent, yevent, zevent : boolean;
  signal xactive, yactive, zactive : boolean;
begin

  x <= '0' after 1 ns, '1' after 10 ns, '1' after 15 ns,
      '1' after 20 ns, '0' after 30 ns;
  y <= x;
  z <= y;
  
  xevent <= x'event;
  yevent <= y'event;
  zevent <= z'event;
  
  xactive <= x'active;
  yactive <= y'active;
  zactive <= z'active;
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 ...

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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
  process (z, z'event) begin
     if z'event then
        zevent <= z;
     end if;
  end process;

In anderen Worten in der Anweisung
 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 :)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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 ;-)

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
process (z, z'event) begin
    if z'event then
        zevent <= z;
     end if;
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.