Vergleich von 2 code Varianten

[Martin (Gast)]

Hallo zusammen,

1)besteht ein Unterschied im Verhalten bei der Simulation?
2)besteht ein Unterschied im Verhalten bei der Synthese?

ein ziemlich bekanntes Pattern bei FSM ist im Code abgebildet ...

  A:process
  begin
    wait until rising_edge(clk);
    current_state <= next_state;
  end process;

  B:process(clk, next_state)
  begin
                if rising_edge(clk) then
        current_state <= next_state;
                end if;
  end process;

zu 1 würde ich meinen, dass A process nicht getriggert wird,
wenn next_state sich ändert. Allerdings wird B process zwar getriggert
auf events auf dem next_state Signal, aber da es im if rising_edge(clk)
steht quasi im Sand verläuft und nichts bewirkt.
Daher würde ich sagen, dass beides in der Simulation dasselbe
Verhalten zeigt.

Übrigens wenn ich next_state nicht in der sensitivity list vom
process B eintragen würde, sollte es an der Simulation auch nichts
ändern. Man liest ja in Büchern immer, dass alle gelesenen Signale
in die sensitivity list gehören, damit die kombinatorische Logik
synthetisiert wird.

gruss

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

  B:process(clk, next_state)
  begin
     if rising_edge(clk) then
        current_state <= next_state;
     end if;
  end process;

ist überbestimmt. Der Prozess wird für die Simulation bei einer Änderung 
von next_state zwar aufgerufen, weil aber die if-Bedingung nicht erfüllt 
ist sofort wieder beendet.

Korrekt wäre

  B:process(clk)
  begin
     if rising_edge(clk) then
        current_state <= next_state;
     end if;
  end process;

und dann ist das Verhalten wieder gleich.

EDIT:
> damit die kombinatorische Logik synthetisiert wird.
Die Synthese schert sich einen feuchten Kehrricht um die Sens-List. Du 
wirst nur freundlich darauf hingewiesen, dass da Signale fehlen, die 
automatisch hinzugefügt werden.
Die Simulation braucht aber die Signale in der Sens-List, weil sie 
darauf die Berechnung des Prozesses triggert.
Und so kann es leicht sein, dass du in kombinatorischen Prozessen bei 
unvollständiger Liste Unterschiede zwischen Simulation und Realität 
siehst :-o

[Morin (Gast)]

> Übrigens wenn ich next_state nicht in der sensitivity list vom
> process B eintragen würde, sollte es an der Simulation auch nichts
> ändern. Man liest ja in Büchern immer, dass alle gelesenen Signale
> in die sensitivity list gehören, damit die kombinatorische Logik
> synthetisiert wird.

Das ist so nicht ganz korrekt, aber auch nicht ganz falsch. Erstmal: 
VHDL definiert eine klare Bedeutung von sens. Lists, die auch in der 
Simulation korrekt wiedergegeben wird.

Die Synthese von kombinatorischen Prozessen dagegen weicht u.U. 
erheblich vom "korrekten" Verhalten ab: Die endgültige Synthese kann 
nur solche kombinatorischen Prozesse ab, in der alle Signale in der SL 
stehen, weil sich die Zielhardware derart verhält (z.B. die LUTs in 
FPGAs). Deshalb werden bei der Analyse deines VHDL-Codes "fehlende" 
Signale in die SL eingetragen. Weil das im Prinzip eine stillschweigende 
Änderung deines Codes ist, gibt es eine warning, um dich darauf 
aufmerksam zu machen.

[Sven P. (Gast)]

War das nich so, dass das ganze WAIT und AFTER etc. nur in der 
Simulation funktioniert?

[Marcus H. (mharnisch)]

Sven Pauli wrote:
> War das nich so, dass das ganze WAIT und AFTER etc. nur in der
> Simulation funktioniert?

Nein, nicht "das ganze".

Gruß
Marcus
http://www.doulos.com/

[Martin (Gast)]

[vhdl]
  B:process(clk, next_state)
  begin
     if rising_edge(clk) then
        current_state <= next_state;
     end if;
  end process;
[/vhdl
]
>ist überbestimmt. Der Prozess wird für die Simulation bei einer Änderung
>von next_state zwar aufgerufen, weil aber die if-Bedingung nicht erfüllt
>ist sofort wieder beendet.

das ist quasi ein HDL Analogon (wenn man es mal breit auslegt)
zur einer reinen Softwarefunktion bei der ein Parameter intern
nicht benutzt wird.

allerdings würde ich dennoch next_state drin lassen.
oder verlangsamt sich die Simulation dadurch erheblich?
immerhin dürfte next_state im Vergleich zum clk weniger
events haben.

in letzter Zeit tendiere ich für die Simulation und Synthese
zur Variante A

gruss

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

@ Morin
> Die endgültige Synthese kann nur solche kombinatorischen Prozesse ab,
> in der alle Signale in der SL stehen, weil sich die Zielhardware
> derart verhält (z.B. die LUTs in FPGAs).
Nein, das stimmt so nicht.

Der Synthese ist die Sensitivity-List schnurzegal. Die macht das 
Design so, wie es in dem Prozess beschrieben ist. Bei fehlenden Signalen 
gibt es bestenfalls noch ein paar Warnungen zum Thema "Es fehlen Signale 
in der Sens-List".

Die Simulation braucht in einem kombinatorischen Prozess alle 
Signale, die eine Änderung eines anderen Signals bewirken. Denn sonst 
wird der Prozess manchmal einfach nicht durchgerechnet.
In einem getakteten Prozess können sich Ausgangswerte nur dann ändern, 
wenn sich der Takt ändert. Deshalb muß da auch kein anderes Signal in 
die Liste.

Und dazu ein kleines Beispiel:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity abcxy is
    Port ( a : in  STD_LOGIC;
           b : in  STD_LOGIC;
           c : in  STD_LOGIC;
           x : out  STD_LOGIC;
           y : out  STD_LOGIC);
end abcxy;

architecture Behavioral of abcxy is
begin
  process(a)  -- a ist unnötig, aber eigentlich nötig: b und c
  begin
     if rising_edge(c) then
        x <= a;
     end if;
     y <= b;
  end process;
end Behavioral;

Die Synthese gibt ein paar Warnungen:

Analyzing Entity <abcxy> in library <work> (Architecture <Behavioral>).
WARNING:Xst:819 - "D:/Projekte/FPGA/RegVar/RegVar.vhd" line 19: The following signals are missing in the process sensitivity list:
   c.
WARNING:Xst:819 - "D:/Projekte/FPGA/RegVar/RegVar.vhd" line 17: The following signals are missing in the process sensitivity list:
   b.
Entity <abcxy> analyzed. Unit <abcxy> generated.

Macht aber alles so, wie ich es wollte:
getaktetes a  und  kombinatorisches b  (Bild: RTL-Schematics).



@  Martin (Gast)
> allerdings würde ich dennoch next_state drin lassen.
Ich nicht, das macht die Sache nur unübersichtlich.

> in letzter Zeit tendiere ich für die Simulation und Synthese
> zur Variante A
Ich auch, dann wird es garantiert ein getakteter Prozess.

[Morin (Gast)]

@Lothar
> Nein, das stimmt so nicht.
>
> Der Synthese ist die Sensitivity-List schnurzegal. Die macht das
> Design so, wie es in dem Prozess beschrieben ist. Bei fehlenden Signalen
> gibt es bestenfalls noch ein paar Warnungen zum Thema "Es fehlen Signale
> in der Sens-List".

Ich glaube, da gibt es ein Mißverständnis. Was du meinst ist, dass das 
konkrete Syntheseprogramm die SL einfach ignoriert, und da stimme ich 
dir auch zu. Was ich meinte war, dass das Syntheseprogramm ein Ergebnis 
produziert, welches einer SL entspricht, in der genau alle 
Eingangssignale vorkommen, was formal einer Änderung der SL entspricht.

Das sind letztendlich nur zwei verschiedene Sichtweisen des 
Syntheseprogramms: Konkrete Arbeitsweise des Codes oder Verhalten lt. 
VHDL-Standard. Ich muss aber zugeben, dass deine Beschreibung einfacher 
zu verstehen ist :/

@Martin
> allerdings würde ich dennoch next_state drin lassen.
> oder verlangsamt sich die Simulation dadurch erheblich?
> immerhin dürfte next_state im Vergleich zum clk weniger
> events haben.

Das kommt drauf an, wie oft sich next_state ändert und wie es berechnet 
wird. Wenn du überall unnötige Signale mit in die SL nimmst, kann sich 
das schon auswirken. Und wenn diese unnötigen Signale kombinatorisch 
berechnet werden, am besten noch mit vielen Einganssignalen, dann 
bekommst du simulierte Glitches, die jedesmal für nix den Prozess 
anlaufen lassen.