Beschreibung einer State Machine

[VHDL-Anfänger (Gast)]

Hallo,

ich wollte nur einmal wissen, ob irgendwas dagegen spricht, eine State 
Machine wie folgt zu beschreiben

process (Clk)
   variable state : integer := 0;
begin
   if (Clk'event and Clk = '1') then
      if (Reset = '1') then
         state := 0;
      else
         case state is
            when 0 =>   x <= '0';
                        state := 1;
            when 1 =>   x <= '1';
                        state := 0;
            when others => state := 0;
         end case;
      end if;
   end if;
end;

Diese Beschreibung funktioniert ja, ist allerdings wesentlich kürzer als 
in den Templates vorgegeben und für mich auch übersichtlicher, da alles 
in einem Process.
Die Moore State Machine setzt sich in meinem Template aus drei Prozessen 
zusammen. Hat dies gegenüber meiner Variante irgend welche Vorteile?

Danke für Hilfe.

[Marcus W. (Gast)]

> auch übersichtlicher, da alles
> in einem Process.

Es gibt die 1-Prozess Methode und die 2-Prozess Methode, Lothar Miller 
beschreibts ganz gut:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

Einen groben Schnitzer hast dir aber erlaubt:
Der Zustandsspeicher sollte ein Signal sein, keine Variable.

Gruß

[VHDL-Anfänger (Gast)]

warum?

[kein VHDL-Anfänger (Gast)]

Mach dir einmal die Unterschiede zwischen variable und signal klar, dann 
kommst du schon selber drauf.

[VHDL-Anfänger (Gast)]

Die variable gilt nur für den process... auf dem board funktionierts so 
jedenfalls.
Kann die State Machine dadurch ihren state verliehren?

[Marcus W. (Gast)]

Siehe:
http://www.mikrocontroller.net/articles/VHDL#Grundregeln_f.C3.BCr_synthetisierbaren_VHDL-Code

> Variablen nur dann verwenden, wenn man genau verstanden hat was der
> Unterschied zu einem Signal ist, und sich das Problem nicht auch mit
> Signalen lösen lässt

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

> Kann die State Machine dadurch ihren state verliehren?
Nein, aber du kannst ihn ausserhalb des Prozesses nicht verwenden. Und 
das macht irgendwelche concurrent-Abfragen oder Zuweisungen unmöglich.
Siehe auch den Beitrag "Variable vs Signal"

BTW:

  variable state : integer := 0;

Dadurch macht der Synthesizer deine Zustandsvariable (weil integer) erst 
mal 32 Bit breit. Und später muß das Ganze dann mühevoll wieder 
herausoptimiert werden...
Wenn schon diese explizite Zustandsdefinition, dann mit range

  variable state : integer ragne 0 to 1 := 0;

Besser ist aber die Zustrandsdefinition über einen type.

[nixda (Gast)]

das "warum" ist schon richtig,

man kann auch mit variablen states beschreiben (die werden also zu FFs) 
:-) . das hat nichts mit variable und signal zu tun.

also signale:

- kannst du innerhalb + ausserhalb eines processes verwenden
- das update erfolgt erst am ende des aktuellen "delta" steps

variablen:

- nur innerhalb einen process
- update sofort

ja und wie werden variablen states? indem es einen pfad im getakteten 
process gibt der die variable liest bevor die geschrieben wird. und das 
ist hier der fall.

btw1: nicht das man das so machen muss oder das dies gut ist, aber 
manchmal kann man das gebrauchen.

btw2: die beschreibung sieht zwar lang aus aber was solls

mfg

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

> variablen:
> - update sofort
Aber Achtung: es ist nicht so, dass dieser sofort übernommene Wert 
irgendwo sichtbar wäre (jaja, ok im Simulator vielleicht...). Übernommen 
und damit sichtbar wird der aktuelle Wert einer Variablen (wie bei 
Signalen auch) erst bei der nächsten Taktflanke. Alles was zwischen zwei 
Taktflanken passiert, kann "nur" Kombinatorik sein.

[VHDL-Anfänger (Gast)]

Ok vielen dank für eure Hilfe.

[nixda (Gast)]

servus,

>Übernommen
>und damit sichtbar wird der aktuelle Wert einer Variablen (wie bei
>Signalen auch) erst bei der nächsten Taktflanke.

zuweisungen an variablen sind sofort im simulator sichtbar. da ist 
nichts mit taktflanke oder delta. durch die synthese veraendert sich 
nicht die semantik von vhdl (sonst waere ja die simualtion etwas 
sinnlos). das was sich veraendern kann ist das "delta" verhalten (und 
damit das timing zwischen den flanken)
.

>Alles was zwischen zwei
>Taktflanken passiert, kann "nur" Kombinatorik sein.
im prinzip##mfg

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

> zuweisungen an variablen sind sofort im simulator sichtbar.
Aber eben "nur" dort. In der Hardware gibt es keine solche 
Zwischenwerte, wie Variablen sie annehmen können. Insbesondere gibt es 
die Reihenfolge aus der Prozessbeschreibung nicht.

Wenn ich sowas in VDHL beschreibe:

process (input)
variable x := integer;
begin
   if (input(0)='1') then 
     x <= 111;
   end if;
   if (input(1)='1') then 
     x <= 222;
   end if;
   if (input(2)='1') then 
     x <= 333;
   end if;
end process;

Hier wird, wenn input = "111" ist, in der Hardware der Variablen x 
niemals der Wert 111 oder 222 zugewiesen, wie das im Simulator durchaus 
zu sehen ist. Weil die letzte Zuweisung im Prozess gilt, gibt es in der 
Hardware nur den Wert 333.

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

Nehmen wir mal diese simple Beschreibung:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity BadVariable is
    Port ( input : in  STD_LOGIC_VECTOR (2 downto 0);
           y : out  STD_LOGIC_VECTOR (2 downto 0);
           z : out  STD_LOGIC_VECTOR (2 downto 0));
end BadVariable;

architecture Behavioral of BadVariable is
begin
   process (input)
   variable x : std_logic_vector(2 downto 0);
   begin
      z <= x;
      x := "000";
      if (input(0)='1') then 
        x := "001";
      end if;
      if (input(1)='1') then 
        x := "011";
      end if;
      if (input(2)='1') then 
        x := "111";
      end if;
      y <= x;
   end process;
end Behavioral;

Was passiert hier mit z, wenn input z.B. von 001 nach 011 wechselt?

Im Simulator behält (=speichert) z den vorherigen Wert von x.
Also ist hier z=001 und y=011.

In der realen Hardware werden aber keinerlei Speicherglieder 
implementiert.

Schon schön böse, diese Variablen, oder?

[nixda (Gast)]

ja und,

bei variablen ist jede zuweisung im simulator sichtbar (ob dieser wert 
nach der synthese irgendwo sichbar ist steht auf einem anderen  blatt) - 
bei signalen ist nur das letzte assignment sichtbar (welches am ende des 
aktuellen delta cycles ausgefuehrt wird).

regards

[nixda (Gast)]

>Schon schön böse, diese Variablen, oder?

mir ist schon bewusst, dass zwischen simulation und synthese 
unterschiede sind :-)

die ganzen templates, etc dienen eigentlich nur dazu simulation&synthese 
resultat moeglichst gleich zu halten bzw ueberhaupt eine (sinnvolle) 
hardware zu beschreiben.

mfg/