Sinn der Sensitivity List?

[jeff (Gast)]

Hallo,

ich habe mal eine Frage: Warum gibt es überhaupt eine Sensitivity List? 
Gibt es da irgendwelche sinnvollen Anwendungszwecke?

Ich rege mich mittlerweile zum tausendsten Mal auf, dass ich nach einer 
kleinen Moduländerung eine Stunde vor der Simulation verzweifle, da 
irgendetwas nicht mehr funktioniert. Nur um dann zu merken, dass die 
Sensitivity List nicht mehr aktuell ist.

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

jeff schrieb:
> Warum gibt es überhaupt eine Sensitivity List?
Für die Simulation.
> Gibt es da irgendwelche sinnvollen Anwendungszwecke?
Bei Änderung eines der Signale wird der Prozess in der Simulation neu 
berechnet. Das war eine signifikante Einsparung von Rechenzeit, die 
bei den ersten Computern noch recht kostbar war.

Und ausserdem war damit der Prozess schon halb dokumentiert:
In der Sensitivliste stehen alle signale, die eine Änderung eines Wertes 
bewirken können.

In VHDL2008 gibt es auch das Schlüsselwort all

 process (all) begin
  :
 end process;

[peter (Gast)]

Hallo,

die Sensitivity-Liste wird "hauptsächlich" für die Simulation benötigt. 
Denn der Prozes wird nur aktualisiert, bei Signalen die in der 
Sensitivity-Liste stehen.

Findet eine Signaländerung bei einem Signal welches nicht in der 
Sensitivity-Liste steht statt, hat das keine Auswirkung auf den Prozes. 
Somit sind die Auswirkungen auf weitere Signale nicht in der Simulation 
sichtbar.

Fehlen solche Signale in der Sensitivity-Liste stimmen Simulation und 
Implementierungsverhalten nicht überein.

[JBB (Gast)]

Die Liste dient dazu den Aufruf der Funktion zu steuern, damit nicht 
jede Funktion bei jedem Aufruf angefragt werden muss, was auch seine 
Probleme machen würde. Ursprüngluich sind das einfach Funktionsaufrufe 
gewesen, in denen Variablen übergeben wurden.

Durch Hinzufügen eines Signals in die SensList kann man das Verhalten 
der Simulation steuern. Man baut z.B. einen Takt rein, der dann die 
anderen Signale absampelt, obwohl es Kombinatorik ist. Das vereinfacht 
die Beschreibung bestimmter Verhaltensmuster. Ausserdem kann man so 
kombinatorischen code nutzen, der anderswo kombinatorisch bleiben soll, 
während er im FPGA getaktet laufen muss.

Modelsim ist ja nicht nur für FPGAs da :-9

Am Besten du stellst bei den Einstellungen wo auch das "vital" und die 
"Lib checks stehen" den "check synthesis" ein. Dann färben sich die 
files mit einem gelben Dreieick ein, wenn die sens list nicht der 
Synthese entspricht. Ich habe das für alle synthetisierbaren file 
aktiviert.

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

JBB schrieb:
> Man baut z.B. einen Takt rein, der dann die anderen Signale absampelt,
> obwohl es Kombinatorik ist.
> Das vereinfacht die Beschreibung bestimmter Verhaltensmuster.
Da sollte man aber schon überaus genau wissen, was man da tut...

> Modelsim ist ja nicht nur für FPGAs da :-9
Und es gibt dem Vernehmen nach auch noch andere Simulatoren (ISIM, 
Aldec, ghdl) ...

[Hannes (Gast)]

Vielleicht sollte man mal ein Beispiel einer trickreichen Nutzung einer 
snesitivity list geben,

[Klaus F. (kfalser)]

Hannes schrieb:
> Vielleicht sollte man mal ein Beispiel einer trickreichen Nutzung einer
> snesitivity list geben,

Besser nicht.
Die Sensitivity List macht so schon genug Verständnisschwierigkeiten, da 
braucht es nicht auch noch Getrickse ...

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

Hannes schrieb:
> Vielleicht sollte man mal ein Beispiel einer trickreichen Nutzung einer
> snesitivity list geben,
Ich kenne unvollständige Sensitivlisten eigentlich auch nur als Quelle 
von Problemen:
Beitrag "Re: Variable vs Signal"
Beitrag "Re: PWM Signal erzeugen"

[Paul (Gast)]

alles, was komplex ist, is Quell von Problemen

[jeff (Gast)]

Klaus Falser schrieb:
> Hannes schrieb:
>> Vielleicht sollte man mal ein Beispiel einer trickreichen Nutzung einer
>> snesitivity list geben,
>
> Besser nicht.
> Die Sensitivity List macht so schon genug Verständnisschwierigkeiten, da
> braucht es nicht auch noch Getrickse ...


Wo gibts es denn da Verständnisschwierigkeiten? Mir geht es ja eher 
darum, dass ich mit einigen Jahren Erfahrung noch nie eine sinnvolle 
Benutzung gesehen habe, die man nicht auch mit den üblichen Mitteln 
hinbekommt. Deswegen macht die Sensitivity List für mich persönlich 
wenig Sinn und führt  zu Problemen bei der Simulation, wenn man 'mal 
wieder' ein Signal vergessen hat.

Daher wäre ich schon an einem konkreten Beispiel interessiert und nicht 
so etwas wie "Man könnte ja evt. das und das damit machen..."

Danke übrings für die vielen Antworten :-)

[Klaus F. (kfalser)]

jeff schrieb:
> Wo gibts es denn da Verständnisschwierigkeiten?

Z.B. darin, dass Du das ganze auf die Synthese beziehst.
Ich wiederhole mich nun schon zum 1000. Mal, aber VHDL ist eine 
SIMULATIONS-Sprache, bzw. -beschreibung und die Sensitivity List dient 
dazu, Neuberechnungen von Ausgangssignalen anzustoßen.

[jeff (Gast)]

Klaus Falser schrieb:
> jeff schrieb:
>> Wo gibts es denn da Verständnisschwierigkeiten?
>
> Z.B. darin, dass Du das ganze auf die Synthese beziehst.
> Ich wiederhole mich nun schon zum 1000. Mal, aber VHDL ist eine
> SIMULATIONS-Sprache, bzw. -beschreibung und die Sensitivity List dient
> dazu, Neuberechnungen von Ausgangssignalen anzustoßen.

Dann hau doch mal ein reines 'SIMULATIONS'-Beispiel raus, wo man eine 
unvollständige Sensitivity List benötigt :-)

[Duke Scarring (Gast)]

jeff schrieb:
> führt  zu Problemen bei der Simulation, wenn man 'mal
> wieder' ein Signal vergessen hat.
Ich entschärfe dieses Problem, indem ich alle Signale, die in einen 
kombinatorischen Prozess reingehen zu einem (bzw. mehreren) record(s) 
zusammenfasse:

  type reg_t is record
    ...
  end record;

  type src_t is record
    ...
  end record;

  signal r, rin : reg_t;
  signal src : src_t;

begin

  comb : process(r, src, apbi)
    variable v         : reg_t;
  begin
    v := r; 
    ...
    do all logic here
    ...
    rin <= v;
  end process;

  seq: process
  begin
    wait until rising_edge( clk);
    r <= rin;
  end process;

  -- optional:
  module_instance : module
    port map (
      module_in  => r.module_in,
      module_out => src.module_out
    );

Damit sind automatisch alle Signale vom record mit in der 
sensitivity-list enthalten.

Duke

[Paul (Gast)]

Duke Scarring schrieb:
> Damit sind automatisch alle Signale vom record mit in der
>
> sensitivity-list enthalten.
Wie meinst Du das? Der Record ist doch was abstraktes, verwendet werden 
doch die Daten"r" und "rin".

und "Rin" ist z.B. nicht in der liste. (?)

[jeff (Gast)]

Paul schrieb:
> Duke Scarring schrieb:
>> Damit sind automatisch alle Signale vom record mit in der
>>
>> sensitivity-list enthalten.
> Wie meinst Du das? Der Record ist doch was abstraktes, verwendet werden
> doch die Daten"r" und "rin".
>
> und "Rin" ist z.B. nicht in der liste. (?)

Im Transition-Prozess arbeitest du doch ansich nur mit den 
Registerwerten r und nie mit r, alles weitere (nebenläufige) müsste dann 
in src stecken.

Interessanter Aufbau :-)

[jeff (Gast)]

jeff schrieb:

> Im Transition-Prozess arbeitest du doch ansich nur mit den
> Registerwerten r und nie mit r, alles weitere (nebenläufige) müsste dann
> in src stecken.

...Registerwerten r und nie mit rin... meine ich natürlich

[Rudolph (Gast)]

Duke Scarring schrieb:
> Ich entschärfe dieses Problem, indem ich alle Signale, die in einen
> kombinatorischen Prozess reingehen zu einem (bzw. mehreren) record(s)
> zusammenfasse

Ich entschärfe dieses Problem, indem ich Kombinatorik nicht in Prozesse 
schreibe ;-P. Da reduziert sich die Sensitivity List auf Clock und, wenn 
man den so will, Reset

[Duke Scarring (Gast)]

jeff schrieb:
> Im Transition-Prozess arbeitest du doch ansich nur mit den
> Registerwerten r und nie mit r, alles weitere (nebenläufige) müsste dann
> in src stecken.
Nein. In src werden die Signale zusammengefasst, die von Submodulen 
zurückkommen.

Wenn ich ein Register blareg brauche kommt das in den reg_t und ich 
lese zuerst aus v.blareg. Wenn ich eine Variable blavar brauche, kommt 
die auch mit in den reg_t rein. Der Unterschied: Ich weise ihr innerhalt 
des comb-Prozesses erst einen Wert zu, ehe ich ihn verwende.

Und weil bald Weihnachten ist, hier noch der Link zum entsprechenden 
Paper:
http://www.gaisler.com/doc/vhdl2proc.pdf

Duke

[Duke Scarring (Gast)]

Rudolph schrieb:
> Ich entschärfe dieses Problem, indem ich Kombinatorik nicht in Prozesse
> schreibe ;-P. Da reduziert sich die Sensitivity List auf Clock und, wenn
> man den so will, Reset
Das ist meine zweitliebste Methode :-)

Und wenn man dann noch das "wait until rising_edge( clk);" verwendet, 
kann man sich die sens-list gleich sparen.

Duke

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

Hatte ich es schon erwähnt?
Man verwendet von VHDL 2008 das process(all)...
Oder schreibt nur getaktete Prozesse... ;-)

[Klaus F. (kfalser)]

jeff schrieb:
> Klaus Falser schrieb:
>> jeff schrieb:
>>> Wo gibts es denn da Verständnisschwierigkeiten?
>>
>> Z.B. darin, dass Du das ganze auf die Synthese beziehst.
>> Ich wiederhole mich nun schon zum 1000. Mal, aber VHDL ist eine
>> SIMULATIONS-Sprache, bzw. -beschreibung und die Sensitivity List dient
>> dazu, Neuberechnungen von Ausgangssignalen anzustoßen.
>
> Dann hau doch mal ein reines 'SIMULATIONS'-Beispiel raus, wo man eine
> unvollständige Sensitivity List benötigt :-)

Wieso reines Simulationsmodell?
Ein FF ist ein klassisches Beispiel für einen Prozess mit einer 
unvollständigen Sensitivity List.

process(Clk, Reset) is 
begin 
    if Reset = '1' then 
        Q <= '0'; 
    elsif rising_edge(Clk) then 
        Q <= D;
    endif;
end process;

Der Prozess, bzw. die Neuberechung startet nur, wenn sich Reset oder Clk 
ändern. Das ist wie bei einem richtigen HW-FF, man kann den 
Daten-Eingang ändern wie viel man will, nur Reset und CLk ändern etwas 
am Ausgang.

Man könnte den D Eingang auch noch in die Sensitivity List aufnehmen, 
aber das vermindert die Effizienz der Simulation.

[Harry (Gast)]

>http://www.gaisler.com/doc/vhdl2proc.pdf

Das ist meines Erachtens einfach nur schlecht, viel zu viele 
Fehleranfälligkeiten bei dieser Kodierungsart.

[Harry (Gast)]

>Ich entschärfe dieses Problem, indem ich Kombinatorik nicht in Prozesse
>schreibe

Es gibt derart verschachtelte Kombinatorik, die man mit nebenläufigen 
Anweisungen nur sehr unübersichtlich beschreiben kann.

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

Harry schrieb:
> Es gibt derart verschachtelte Kombinatorik, die man mit nebenläufigen
> Anweisungen nur sehr unübersichtlich beschreiben kann.
Da hilft es oft, mal einen Schritt zurückzutreten...  ;-)

[Dani (Gast)]

http://embdev.net/topic/237855

[Duke Scarring (Gast)]

Harry schrieb:
>>http://www.gaisler.com/doc/vhdl2proc.pdf
>
> Das ist meines Erachtens einfach nur schlecht, viel zu viele
> Fehleranfälligkeiten bei dieser Kodierungsart.
Wie Du schon schreibst: Ansichtssache

Wobei mich schon interessieren würde, welche Art von Fehlern da 
auftreten sollen.

Außerdem möchte ich die Komplexität, die ich mit der 
Zwei-Prozess-Methode beschreiben kann, nicht mit klassichen 
nebenläufigen Anweisungen oder verteilt auf mehrere kombinatorische 
Prozesse schreiben wollen.

Duke

[Sigi (Gast)]

Duke Scarring schrieb:
>Wobei mich schon interessieren würde, welche Art von Fehlern da
>auftreten sollen.

VHDL2Proc wurde schon häufig in Foren diskutiert. Das Problem der
Sensitive-List ist das Vergessen von Signalen, ein Problem von
VHDL2Proc ist, das es idR irgendwo eine Strukture-Signal-Zuweisung
zwischen fremden Komponenten und der eigenen Struktur kommt. Und
genau hier kann der gleiche Fehler wie bei Sens.-Listen auftreten:
Es können Signale vergessen (oder sogar vertauscht) werden; uU
auch nicht sofort zu erkennen (Prinzip Telefonbuch abschreiben:
wo verdammte Hacke ist die Nummer von Frau Maier geblieben, und
warum sind Schulz und Schmitt vertauscht??).

[Duke Scarring (Gast)]

Sigi schrieb:
> ein Problem von
> VHDL2Proc ist, das es idR irgendwo eine Strukture-Signal-Zuweisung
> zwischen fremden Komponenten und der eigenen Struktur kommt. Und
> genau hier kann der gleiche Fehler wie bei Sens.-Listen auftreten:
> Es können Signale vergessen (oder sogar vertauscht) werden;
Genau dafür habe ich ja den src record. Darin sind alle Ausgänge von 
den jeweiligen Submodule (oder einer nebenläufigen RAM-Beschreibung) 
zusammengefasst. Der muß natürlich mit in der sens-list auftauchen.

Duke

[Fetz (Gast)]

jeff schrieb:
> Ich rege mich mittlerweile zum tausendsten Mal auf, dass ich nach einer
> kleinen Moduländerung eine Stunde vor der Simulation verzweifle, da
> irgendetwas nicht mehr funktioniert. Nur um dann zu merken, dass die
> Sensitivity List nicht mehr aktuell ist.

Dann muss ich dir leider berichten, dass du grundsätzlich was falsch 
machst.

Prozesse sind zu nahezu 100% immer mit dem Main-Clock getacktete 
Prozesse, weshalb dort auch nahezu ausschließlich nur der clock in der 
Sensitivity-List vorkommt.

Gerechtfertigte Ausnahmen sind z.B. ein SPI-Interface.

[Georg (Gast)]

Warum ein SPI Interface?

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

Weil dort auch mal ausnahmsweise der SPI-CLK zum Eintakten verwendet 
werden darf... ;-)

[Jeff (Gast)]

Fetz schrieb:
> jeff schrieb:
>> Ich rege mich mittlerweile zum tausendsten Mal auf, dass ich nach einer
>> kleinen Moduländerung eine Stunde vor der Simulation verzweifle, da
>> irgendetwas nicht mehr funktioniert. Nur um dann zu merken, dass die
>> Sensitivity List nicht mehr aktuell ist.
>
> Dann muss ich dir leider berichten, dass du grundsätzlich was falsch
> machst.
>
> Prozesse sind zu nahezu 100% immer mit dem Main-Clock getacktete
> Prozesse, weshalb dort auch nahezu ausschließlich nur der clock in der
> Sensitivity-List vorkommt.
>
> Gerechtfertigte Ausnahmen sind z.B. ein SPI-Interface.

Also ich baue meine Module alle so auf, dass ich einen Register Prozess 
habe und einen für die FSM-Transitionen (der dann die angesprochene 
Sensitivity-Liste benötigt). Mir war nicht klar, dass ich dabei 
grundsätzlich etwas falsch mache :-) Also wieder zurück zur 1-Prozess 
FSM.

[Fetz (Gast)]

Jeff schrieb:
> Also ich baue meine Module alle so auf, dass ich einen Register Prozess
> habe und einen für die FSM-Transitionen (der dann die angesprochene
> Sensitivity-Liste benötigt). Mir war nicht klar, dass ich dabei
> grundsätzlich etwas falsch mache :-) Also wieder zurück zur 1-Prozess
> FSM.

Das kannst du ja auch weiterhin machen ... Aber für jeden Prozess 
einfach

process(clk)
begin
  if clk'event and clk='1' then
    ...
  end if;
end process;

verwenden, dann kann vom Timing her nie was schief gehen und du brauchst 
kein weiteren Signale in deiner Sensitivity-List.

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

Jeff schrieb:
> Mir war nicht klar, dass ich dabei grundsätzlich etwas falsch mache :-)
Du machst mit dieser Methode nicht grundsätzlich was falsch, du fängst 
dir aber gern mal eine kombinatorische Schleife ein...
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife
...weil du im falschen Prozess die falsche Variable hochzählst...
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html
...und im Idealfall fliegt die Sensitivliste komplett raus...
http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html

Fetz schrieb:
> Aber für jeden Prozess
> einfach
> process(clk)
> begin
>   if clk'event and clk='1' then
>     ...
>   end if;
> end process;
> verwenden, dann kann vom Timing her nie was schief gehen
Man sollte sich allerdings Gedanken zum Thema "Latency" machen...