Sensitivity List

[Daniel K. (daniel_k80)]

Hallo zusammen,

ich habe ein Verständnisproblem bei der Sensitivity List in VHDL.
Bisher habe ich es so verstanden, dass in die Liste alle Signale 
eingetragen werden, die sich innerhalb des process Blocks ändern.
Nun habe ich aber vorher diesen Artikel gelesen:

http://www.lothar-miller.de/s9y/categories/34-Getakteter-Prozess

Im Unterpunkt "Takt im Prozess" steht nun folgendes:

architecture Behavioral of Beispiel is
begin
   -- Prozess ohne Sensitiv-Liste
   process begin
      wait until rising_edge(clk);
      if (sel1='1') then
         outp <= inp;
      else
         outp <= not inp;
      end if;
   end process;   
end Behavioral;

Wieso wird da die Liste weg gelassen? Und welche Bedeutung bzw. Funktion 
hat die Sensitivity List? Weil ich habe nach dem Lesen das Gefühl 
gehabt, dass mein bisheriges Verständnis dieser Liste falsch war.

Danke fürs aufschlauen!

Gruß
Daniel

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Daniel K. schrieb:
> Wieso wird da die Liste weg gelassen?
Was ist in der Beschreibung dort unverständlich?
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html

> Und welche Bedeutung bzw. Funktion hat die Sensitivity List?
Die Sensitivliste ist ausschließlich für den Simulator interessant. 
Der berechnet die Prozessergebnisse neu, wenn sich eines der signale in 
der Liste ändert.

Man kann jeden Prozess entweder mit "wait" oder mit einer Sensitivliste 
beschreiben. Man kann ein Und-Gatter in einem Prozess z.B. so 
beschreiben:

process (a,b) begin
  z <= a and b;
end process;

Oder alternativ so:

process begin    -- keine Sensitivliste
  wait on (a,b); -- aber ein wait
  z <= a and b;
end process;

Siehe die hier:
Beitrag "Re: Der vhdl-Schnipsel-Anfängerfragen Thread"
Beitrag "Re: Sensitivitätsliste in VHDL Code"
Beitrag "Re: Verschiedene Schreibweisen bei "process""

> Weil ich habe nach dem Lesen das Gefühl gehabt, dass mein bisheriges
> Verständnis dieser Liste falsch war.
Passiert vielen, die meinen, über diese Liste irgendwas im FPGA 
Verhalten ändern zu können... :-)
Manchmal tappt man über diese Liste auch ins Verderben. Wie z.B. im 
Beitrag "Re: Variable vs Signal" und nochmal weiter 
unten dort im Beitrag "Re: Variable vs Signal"

[Daniel K. (daniel_k80)]

Hallo Lothar,

danke für die Erklärung.

>Lothar Miller schrieb:

>>> Und welche Bedeutung bzw. Funktion hat die Sensitivity List?
>> Die Sensitivliste ist ausschließlich für den Simulator interessant.
>> Der berechnet die Prozessergebnisse neu, wenn sich eines der signale in
>> der Liste ändert.

Genau DAS hat mir gefehlt :)
Das kam bisher nie wirklich raus, wenn ich etwas über die Liste gelesen
habe.

[Da D. (dieter)]

Oder man ist auf der Höhe der Zeit* und schreibt einfach und überall:

process(all)
begin
...

*aktueller VHDL Standard ist VHDL2008

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Da Dieter schrieb:
> Oder man ist auf der Höhe der Zeit* und
... schaltet das Hirn aus.
Genau dieses "all" ist m.E. eines der blödsinnigsten Konstrukte der 
"Weiterentwicklung" von VHDL. Denn die Sensitivliste sollte doch 
eigentlich nochmal zum Nachdenken anregen, ob das denn wirklich so 
gemeint war...

> und schreibt einfach und überall: process(all)
Dann kann ich aber nicht mehr mit wait im Prozess arbeiten...  :-/

[Lattice User (Gast)]

Lothar Miller schrieb:

>
>> und schreibt einfach und überall: process(all)
> Dann kann ich aber nicht mehr mit wait im Prozess arbeiten...  :-/

Wenn es die gleichen Regeln wie das schon lange existierende @(*) in 
Verilog 2001 hat, ist es nur für combinatorische Prozesse erlaubt. Dein 
wait unit raising_edge(clk) ist also nicht in Gefahr.

Und für combinatorische Prozesse macht es durchaus Sinn, ein vergessenes 
Signal in der Sensitivity List bei der Verification ist vermutlich nicht 
wenige ASIC Bugs verantwortlich.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lattice User schrieb:
> ein vergessenes Signal in der Sensitivity List bei der Verification ist
> vermutlich nicht wenige ASIC Bugs verantwortlich.
Man sollte sich dann einfach auch mal den Compiler-Log ansehen. Da 
taucht das auch bei der Simulation auf. Und dann wie gesagt: 
Mitdenken... ;-)

Lattice User schrieb:
> Dein wait unit raising_edge(clk) ist also nicht in Gefahr.
Schon, wenn die Regel "Jeder Prozess mit (all)!" gilt. Denn ein Prozess 
mit Sensitivliste und wait geht nun mal nicht...

[Lattice User (Gast)]

Lothar Miller schrieb:
> Lattice User schrieb:
>> ein vergessenes Signal in der Sensitivity List bei der Verification ist
>> vermutlich nicht wenige ASIC Bugs verantwortlich.
> Man sollte sich dann einfach auch mal den Compiler-Log ansehen. Da
> taucht das auch bei der Simulation auf. Und dann wie gesagt:
> Mitdenken... ;-)

Solche Warnungen im Log zu suchen und dann das fehlende Signal 
nachträglich einzutragen hat mit Mitdenken nichts zu tun. Das ist eine 
Arbeit die der Compiler besser kann, und vor allem vergisst er es nicht 
unter Zeitdruck.

Die Sensitivityliste diente ja mal dazu die Simulation zu beschleunigen.

>
> Lattice User schrieb:
>> Dein wait unit raising_edge(clk) ist also nicht in Gefahr.
> Schon, wenn die Regel "Jeder Prozess mit (all)!" gilt. Denn ein Prozess
> mit Sensitivliste und wait geht nun mal nicht...

Ich bezweifle dass die Regel "Jeder Prozess mit (all)!" wirklich gilt. 
Aber Zugang zum Standard habe ich nicht.

[VHDLogiker (Gast)]

Daniel K. schrieb:
> Bisher habe ich es so verstanden, dass in die Liste alle Signale
> eingetragen werden, die sich innerhalb des process Blocks ändern.

Man glaubt es nicht, aber genau das wird in einem (von mir erlebten)
VHDL-Kurs gelehrt.

Ich kann mich des Eindrucks nicht erwehren dass "in diesen"
Lehrinstituten Leute sitzen die sonst in der Industrie keine
Beschäftigung bekommen haben.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lattice User schrieb:
> dann das fehlende Signal nachträglich einzutragen hat mit Mitdenken
> nichts zu tun.
Nein, sondern eher, ob es dort rein gehört und was es macht. Ich bin 
mir sicher, dass die (all)-Medaille (wie alle pauschalen 
Erleichterungen) zwei Seiten hat...

VHDLogiker schrieb:
> Daniel K. schrieb:
>> Bisher habe ich es so verstanden, dass in die Liste alle Signale
>> eingetragen werden, die sich innerhalb des process Blocks ändern.
> Man glaubt es nicht, aber genau das wird in einem (von mir erlebten)
> VHDL-Kurs gelehrt.
Da hat aber einer grundsätzlich was nicht verstanden oder kann es nicht 
vermitteln.
Nochmal die Kurzform: es müssen alle Signale rein, die eine 
Neuberechnung des Prozesses erfordern.
Und es müssten auch Variablen rein, wenn sie speichernd sind (Lesen 
vor dem ersten Schreiben im Prozess) und eine Neuberechnung erforderlich 
machen. Aber leider können Variablen nicht in die Liste aufgenommen 
werden...

Lattice User schrieb:
> Ich bezweifle dass die Regel "Jeder Prozess mit (all)!" wirklich gilt.
Nein, es ist ja keine Regel aus dem Standard, sondern eine persönliche 
Regel, die man selbst mit sich ausmacht, wie Da Dieter im 
Beitrag "Re: Sensitivity List" eben "einfach und 
überall" einen Prozess seit VHDL 2008 so schreibt.

Da erscheint mir das unäre AND und das unäre OR schon sinnvoller. 
Insbesondere, weil man es auch auf Teilvektoren anwenden kann:

enable <= (and addr(12 downto 5)) and (or addr(4 downto 0));

Wobei man das mit dem reduce Package natürlich auch einfach so schreiben 
könnte:

enable <= '1' when and_reduce(addr(12 downto 5)) and or_reduce(addr(4 downto 0));

[FPGA-Neuling (Gast)]

VHDLogiker schrieb:
> Daniel K. schrieb:
>> Bisher habe ich es so verstanden, dass in die Liste alle Signale
>> eingetragen werden, die sich innerhalb des process Blocks ändern.
>
> Man glaubt es nicht, aber genau das wird in einem (von mir erlebten)
> VHDL-Kurs gelehrt.
Das verstehe ich nicht. Warum ist das nicht so?
Wenn das Signal sich nicht ändert, muss der process doch auch nicht 
ausgelöst werden?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

FPGA-Neuling schrieb im Beitrag #4133004:
>>> dass in die Liste alle Signale
>>> eingetragen werden, die sich innerhalb des process Blocks ändern.
>> Man glaubt es nicht, aber genau das wird in einem (von mir erlebten)
>> VHDL-Kurs gelehrt.
> Das verstehe ich nicht. Warum ist das nicht so?
Es müssen nicht alle die Signale eingetragen werden, die sich ändern, 
sondern alle die, die eine Neuberechnung des Prozesses nötig machen.

Hier müssen z.B. a und b nicht in die Sensitivliste, obwohl sie sich 
ändern können:

 process (d,e,f) begin
   a <= d+e;
   b <= f+3;
 end process;

Bei einem komplett synchronen Prozess muss also sogar "nur" der Takt in 
die Sensitivliste...

 process (clk) begin
   if rising_edge(clk) then
     a <= d+e;
     b <= f+3;
   end if;
 end process;

> Wenn das Signal sich nicht ändert, muss der process doch auch nicht
> ausgelöst werden?
Richtig. Wobei "ausgelöst" eine arg unglückliche Wortwahl ist, "neu 
berechnet" wäre korrekt...

[Klakx (Gast)]

Die process (all) Geschichte ist interessant, jedoch nur wenn man einen 
schlauen Compiler hat. Sonst rennt der Simulator immer in den process 
was viel Rechenzeit brauch.

Im asic flow fallen die fehlenden sensitivities auf. Spätestens im lint 
Check oder eher in der Synthese..

[Klaus F. (kfalser)]

Da Dieter schrieb:
> Oder man ist auf der Höhe der Zeit* und schreibt einfach und überall:

 process(all)
 begin ...

>
> *aktueller VHDL Standard ist VHDL2008

Auf den ersten Blick mag das ja angenehm sein, aber für den 
Simulator-Hersteller (oder vielleicht sogar für die Performance der 
Simulation) der reinste Horror.
Beispiel die Beschreibung eines synchronen FF:

 process(all)
 begin
   if reset = '1' then
     q <= '0';
   elsif rising_edge(clk) then 
     q <= d; 
   end if;     
 end

In diesem Fall sind die Signale clk, reset, d involviert.
Der Prozess muss aber nur ausgeführt werden, wenn sich clk und reset 
ändern.
Wird der Prozess ausgeführt, weil sich d ändert, ist die Berechnung 
unnötig und verlangsamt die Simulation.

Bei einem asynchronen FF

 process(all)
 begin
   if rising_edge(clk) then 
     if reset = '1' then
        q <= '0';
     else 
       q <= d;
     endif; 
   end if;     
 end

ist die Berechnung sogar bei Änderung von reset unnötig.

Möglicherweise machen die Simulator-Hersteller irgendwelche Analysen um 
zu erkennen, welche Signale wirklich eine Neuberechnung notwendig 
machen, aber ob das so einfach ist...?

Ich würde weiterhin bei einem getakteten Prozess clk (und ev. reset) 
hinschreiben, das 'all' würde ich für große kombinatorische Prozesse 
reservieren.
clk und all haben übrigens gleich viel Buchstaben, man spart eh nicht 
viel :-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klaus Falser schrieb:
> für den Simulator-Hersteller (oder vielleicht sogar für die Performance
> der Simulation) der reinste Horror.
Ich vermute, dass der Compiler zwischenzeitlich durchaus so schlau ist, 
dass er solche simple (Un-)Abhängigkeiten erkennt und Redundanzen 
entfernen kann.

> Möglicherweise machen die Simulator-Hersteller irgendwelche Analysen um
> zu erkennen, welche Signale wirklich eine Neuberechnung notwendig
> machen, aber ob das so einfach ist...?
Die Synthesizer machen das schon lange: du kannst eine unvollständige 
oder komplett falsche Sensitivliste hinschreiben, dann macht dich der 
Synthesizer freundlich drauf aufmerksam, dass die Liste unvollständig 
ist und deshalb die Simulation nicht mehr zur Hardware passt. Es ist 
naheliegend, dass die Simulatoren das auch können könnten...

[Klaus F. (kfalser)]

Lothar Miller schrieb:
> Die Synthesizer machen das schon lange: du kannst eine unvollständige
> oder komplett falsche Sensitivliste hinschreiben, dann macht dich der
> Synthesizer freundlich drauf aufmerksam, dass die Liste unvollständig
> ist und deshalb die Simulation nicht mehr zur Hardware passt. Es ist
> naheliegend, dass die Simulatoren das auch können könnten...

Die Synthesehersteller haben es einfacher.
Die brauchen nur nur bestimmte, relativ einfache Strukturen erkennen.

 process(all)
 begin
   if reset = '1' then
     q <= '0';
   elsif rising_edge(clk) then 
     q <= d; 
   end if;     
 end

Im Simulator hat man jede Freiheit.

 process(all)
 begin
   if (sel = '1') then 
      if rising_edge(clk1) then 
         q <= d1; 
      end if;
   else 
     if rising_edge(clk2) then 
         q <= d2; 
      end if;
   end if;     
 end