VHDL: Sinn der Sensitivity List

Du verwechselst Ursache und Wirkung ;-)

Die Kombinatorik ist nur ein Sonderfall aller möglichen Beschreibungen 
in einem Prozess. Du weisst, dass es so sein soll, in der Sprache gibt 
man es dann durch alle Eingangssignale in der Sensitivitylist an.

Warum sollte man für sowas Spezialregeln einführen, es gibt auch Fälle 
(gerade bei Testbenches) wo man eben nicht auf alles reagieren will und 
eine implizite Speicherung wünscht.

Sicher ist die Sensitivitylist eine Hilfe für den Simulator, unbedingt 
nötig ist sie aber nicht, man weiss ja statisch, was im Prozess 
abgefragt wird... Sie ist in erster Linie einfach ein Sprachelement, um 
auf bestimmte Events zu triggern und nicht auf alles.

>Hat jemand schon mal ein kleines Tool gefunden, mit dem man VHDL-Code
>auf solche Dinge untersuchen kann?

Je nach Simulator-Variante gibt es ein Compile-Häkchen für die Option 
"Synthesis Check". Dadurch werden unvollständige Sensitivitätslisten 
aufgedeckt.

Gruß,
SuperWilly

@Matthias G.:
> Hat jemand schon mal ein kleines Tool gefunden, mit dem man VHDL-Code
> auf solche Dinge untersuchen kann?

Naja, klein nicht, sicher auch nicht billig und der Check der 
Sensitivity List ist auch nicht der Hauptzeck der Software: 
http://www.onespin-solutions.com/

Duke

der emacs-Editor kamm die Sensitivity-List zumindest automatisch updaten

Ok, ich scheine demnach zumindest nicht völlig auf dem Holzweg zu sein 
:-)

Die Sensitivity List ist demnach hauptsächlich ein Funktionsverhinderer, 
statt (in seltenen Fällen und nur in der 
Simulation?)Funktionserweiterung ;-).

Wie funktioniet ein automatischer Update der Sensitivity List? Werden 
einfach alle Signale, die geprüft oder zugewiesen werden, eingetragen?

Gummibärchen schrieb:
> Hallo VHDL-Profis,
>
> im besonderen bei kombinatorischen Prozessen kann ich den Sinn der
> Sensitivity List nicht nachvollziehen. Man kann zwar gebetsmühlenartig
> nachlesen, dass der Prozess nur auf Änderung der spezifizierten Signale
> reagiert. Das kann ich bei einer reinen Kombinatorik aber nicht
> nachvollziehen. Schließlich werden hier alle benutzten Signale quasi
> kontinuierlich und gleichzeitig verarbeitet.

Ja, aber die Signale werden hier als zeitdiskrete Binäre Signale 
modelliert

>
> Dient die Sensitivity List etwa nur dazu, dem Simulator entscheidende
> Hinweise zu liefern? Immerhin läßt sich das Simulationsergebnis mit der
> Sensitivity List beeinflussen, auch im positiven Sinne. Aber in einer
> parallel arbeitenden realen Hardware? Gibt es erhellende Beispiele?


Ja, die Simulator arbeitet "event driven", also ereignis gesteuert. 
Zitat aus "Handbuch der Electronic Design Automatisation":

... ältere simulatoren berechnetetn die signalwerte einer 
digitalschaltung f. jeden schaltungsknoten in Abhängigkeit. von der 
zeit. Dies führte zu sehr hohen Simulationszeiten. Die heute verwendeten 
ereignisgesteuerten Simulatoren simulieren nur dan den neuen Signalwert, 
wenn eine Signaländerung am Bauelementeeingang erfolgt ist. .... Alle 
Ereignisse werden für jeden werden ... in einer Ereignisliste ... 
protokolliert. ..."


In der sens. list stehen nun genau die Signale, deren Änderungen events 
sind.

Gruß

> Den VHDL-Modus vom Emacs habe ich mir allerdings noch nicht angesehen,
> werde ich mal tun.

Solltest du. Mit dem Stutter-Mode schreibt es sich wirklich sehr 
schnell. Auch der Speedbar zum Navigieren in den diversen Entities ist 
recht praktisch.

Hier ist ein reduziertes Beispiel, welches mein aktuelles Problem 
darstellt. Eigentlich sollte "vom Fleck weg" in 'result' und 
'inst_literal' der Wert 0x01 stehen. Tut es aber nicht. Momentan befasse 
ich mich nur mit der Simulation, denn, wenn die schon nicht tut, was sie 
soll. Im Singlestep wird beim Loslaufen der Prozess durchlaufen, aber 
die Zuweisungen tun nix!?

Und hier der Code. Was das insgesamt sein soll, kann man erkennen ;-)

1

library ieee;

2

use ieee.std_logic_1164.all;

3

use ieee.numeric_std.all;

4

5

entity pic_testbench is

6

end entity pic_testbench;

7

8

architecture bhv of pic_testbench is

9

10

  component pic is

11

    port( clk    : in  std_logic;

12

          sigout : out std_logic);

13

  end component;

14

15

  signal clk    : std_logic := '1';

16

  signal sigout : std_logic;

17

18

begin

19

  dut : pic

20

    port map (

21

      clk    => clk,

22

      sigout => sigout);

23

24

  clk <= not clk after 10.0 ns;

25

end architecture;

1

library ieee;

2

use ieee.std_logic_1164.all;

3

use ieee.numeric_std.all;

4

5

entity pic is

6

  port( clk    : in  std_logic;

7

       sigout : out std_logic);

8

end pic;

9

10

architecture behavioral of pic is

11

12

  constant rom_depth  : integer := 2;

13

  constant rom_size   : integer := 2**rom_depth;

14

15

   subtype t_byte is unsigned (7 downto 0);

16

   subtype t_inst is unsigned (13 downto 0);

17

  subtype t_rom_address is unsigned (rom_depth-1 downto 0);

18

  type t_rom is array (0 to rom_size-1) of t_inst;

19

20

   signal rom : t_rom := (

21

      "11000000000001",

22

      "00000100000000",

23

      others => "00000000000000");

24

25

  signal pc           : t_rom_address := to_unsigned(0,rom_depth);

26

  signal inst         : t_inst        := "00000000000000";

27

  signal inst_literal : t_byte        := "00000000";

28

  signal result       : t_byte        := "00000000";

29

30

begin

31

  process (rom,pc)

32

  begin

33

    inst <= rom(to_integer(pc));

34

    inst_literal <= inst(7 downto 0);

35

    result <= inst_literal;

36

  end process;

37

38

end behavioral;

Signalzuweisungen werden nicht nicht sofort ausgeführt, sondern erst 
beim Verlassen des Prozesses. Schreib
inst_literal <= inst(7 downto 0);
    result <= inst_literal;

ausserhalb des prozesses und es funzt.

Schau dir mal als beispiel für instruction fetch einen anderen prozessor 
in VHDL an (opencores).

Hm ja, stimmt, da hat es funktioniert, aber ich dachte, es ist 
strukturierter, wenn ich alles in einen Prozess packe. Das faszinierende 
ist, dass die Zuweisung in der Simulaion nie stattfindet, siehe 
Screenshot. 'result' bleibt auf 0x00. Aber folgende Beobachtungen:

Wenn ich alle Signale in die Sensitivity List schreibe, funktioniert 
alles wie erwartet.

Im Singlestep wird der Prozess am Anfang dreimal durchlaufen, bis alle 
Signale ihre endgültigen Werte erreicht haben. Das hängt aber sicherlich 
mit den Interna des Simulators zusammen.

Gummibärchen schrieb:
> Hm ja, stimmt, da hat es funktioniert, aber ich dachte, es ist
> strukturierter, wenn ich alles in einen Prozess packe. Das faszinierende
> ist, dass die Zuweisung in der Simulaion nie stattfindet, siehe
> Screenshot. 'result' bleibt auf 0x00. Aber folgende Beobachtungen:

Die Zuweisung findet statt, da aber der selbe Wert eingeschrieben wird, 
sieht man dies nicht. Lasse doch den Erstwert weg, oder verwendet einen 
anderen als 0, dann siehst du die Zuweisung:

 signal inst_literal : t_byte  ;
  signal result       : t_byte ;

(wobei ich mir nicht sicher bin, ob das mit deinem Typ funktioniert, 
besser is da std_logig, da gibt es den Zustand U wie Unassigned (nicht 
zugewiesen). Aber du kannst es auch mit unterschiedlichen Startwerten 
"sichtbar" machen:

 signal inst_literal : t_byte  := "10000000";

  signal result       : t_byte "00001000";

Gruß





>
> Wenn ich alle Signale in die Sensitivity List schreibe, funktioniert
> alles wie erwartet.
>
> Im Singlestep wird der Prozess am Anfang dreimal durchlaufen, bis alle
> Signale ihre endgültigen Werte erreicht haben. Das hängt aber sicherlich
> mit den Interna des Simulators zusammen.

Ich glaube ich hab's verstanden. Lothar's Satz war der entscheidende: 
"Erst nach dem Durchlauf werden die dabei
berechneten Werte an die Signale zugewiesen"

Deswegen durchläuft der Einzelschritt des Simulators den Prozess auch 
drei mal.

>Warum schreibst du so simple kombinatorische Zuweisungen nicht einfach
>concurrent? Dann bist du die ganze Sensitivlistenverwalterei los...
Ich dachte, wenn ich alles in dem Prozess mache, der es benötigt, ist es 
strukturierter. Aber für einen Newbie wie mich ist Strukturiertheit wohl 
noch relativ :-)

Auf jeden Fall funktioniert jetzt alles wie es soll. Vielen Dank an 
alle!

Die Simulation ist immer richtig.
Falsch ist die Hardware.