bleibe in Zustand hängen, warum?

[Ole (Gast)]

Hi!

Habe einen Zustandsautomaten programmiert und bleibe nun in einem 
Zustand hängen. Ist folgende Abfrage gültig?

when Z_3S =>     if QINT > 30 then 
                    FOLGE_Z <= Z0;
                  else FOLGE_Z <= Z_3S;
                  end if;

Hier wird im Zustand Z_3S abgefragt, ob der Zähler QINT (integer) größer 
als 30 ist. Ist dem so, dann wird auf den Grundzustand Z0 gewechselt, 
ansonsten im Zustand Z_3S geblieben. Eine Simulation mit Modelsim zeigt 
nun aber, dass der Zustand Z_3S nie verlassen wird, obwohl der Zähler 
bereits weit über 30 hinausläuft.
Woran kann das liegen?

Vielen Dank für Tipps,

bg, Ole





Zur weiteren Information hier noch der gesamte Code:

----------------------------------------------------------------------------------
-- Company: 
-- Engineer: 
-- 
-- Create Date:    19:14:23 10/09/2012 
-- Design Name: 
-- Module Name:    Versuch1VBb - Behavioral 
-- Project Name: 
-- Target Devices: 
-- Tool versions: 
-- Description:   wenn sw7 komplett geschlossen -> taster auslesen und entsprechenden 
--           code auf LEDs ausgeben
--
-- Dependencies: 
--
-- Revision: 
-- Revision 0.01 - File Created
-- Additional Comments: 
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity Versuch1VBb is
    Port ( SW7 : in  BIT_VECTOR (3 downto 0);  -- Switch SW7
           CLK,RESET : in BIT;        
        TASTER: in BIT_VECTOR (4 downto 0);  -- Taster up, enter, down, left, right
           LED : out  BIT_VECTOR (3 downto 0);  -- 4 LEDs
        TEST_QINT: out integer;    -- für testbench
        TEST_ZUSTAND: out integer;                -- für testbench
        TEST_RESET: out bit);                    -- für testbench
end Versuch1VBb;

architecture Verhalten of Versuch1VBb is
type ZUSTAENDE is (Z0, Z_UP, Z_ENTER, Z_DOWN, Z_LEFT, Z_RIGHT, Z_3S);
-- Z0 = Grundzustand
-- Z_UP..Z_RIGHT = Taster drücken
-- Z_3S = 3 sekunden warten
signal ZUSTAND, FOLGE_Z: ZUSTAENDE;
signal QINT: integer;
signal ZAEHLERRESET : bit;

begin
----SPEICHER----
Z_SPEICHER: process(CLK, RESET)
  begin
    if RESET='1' then ZUSTAND <= Z0; --bei reset in Z0 gehen
    elsif CLK='1' and CLK'event then
      if SW7 = "1111" then ZUSTAND <= FOLGE_Z;
      end if;
    end if;
  end process Z_Speicher;

----UEBERGANGSSCHALTNETZ----
UE_SN: process (TASTER, ZUSTAND)
  begin
    case ZUSTAND is
      when Z0 =>     case TASTER is
                  when "11110" => FOLGE_Z <= Z_UP;
                  when "11101" => FOLGE_Z <= Z_ENTER;
                  when "11011" => FOLGE_Z <= Z_DOWN;
                  when "10111" => FOLGE_Z <= Z_LEFT;
                  when "01111" => FOLGE_Z <= Z_RIGHT;
                  when others  => FOLGE_Z <= Z0;
                end case;
      when Z_UP =>     FOLGE_Z <= Z_3S;
      when Z_ENTER =>   FOLGE_Z <= Z_3S;
      when Z_DOWN =>   FOLGE_Z <= Z_3S;
      when Z_LEFT =>   FOLGE_Z <= Z_3S;
      when Z_RIGHT =>   FOLGE_Z <= Z_3S;
      when Z_3S =>     if QINT > 30 then 
                    FOLGE_Z <= Z0;
                  else FOLGE_Z <= Z_3S;
                  end if;
    end case;
  end process UE_SN;

----AUSGANGSSCHALTNETZ----
A_SN: process (ZUSTAND)
  begin
    case ZUSTAND is
      when Z0 =>       LED <= "1111";
                  TEST_ZUSTAND <= 0;
      when Z_UP =>     LED <= "1001";
                  ZAEHLERRESET <= '1';
                  TEST_ZUSTAND <= 1;
      when Z_ENTER =>   LED <= "0000";
                  ZAEHLERRESET <= '1';
      when Z_DOWN =>   LED <= "0110";
                  ZAEHLERRESET <= '1';
      when Z_LEFT =>   LED <= "0101";
                  ZAEHLERRESET <= '1';
      when Z_RIGHT =>   LED <= "1010";
                  ZAEHLERRESET <= '1';
      when Z_3S =>    ZAEHLERRESET <= '0';
                  TEST_ZUSTAND <= 6;
    end case;
  end process A_SN;

----TIMER----                
ZAEHLER: process (CLK)
  begin
    if CLK='1' and CLK'event then
    TEST_RESET <= ZAEHLERRESET;  
      if ZAEHLERRESET = '1' then
        QINT <= 0;
      else
        QINT <= QINT + 1;
      end if;
    TEST_QINT <= QINT;
    end if;
  end process ZAEHLER;

end Verhalten;

[Maik F. (sabuty)]

Für die Simulation fehlt QINT in der Sensitivity List deines Prozesses:

UE_SN: process (TASTER, ZUSTAND, QINT)

[user (Gast)]

du hast in der Sensivity-Liste den Zähler vergessen

UE_SN: process (TASTER, ZUSTAND, QINT)


Tipp: du kannst auch Modelsim zur Ausgabe eines solchen Fehlers 
veranlassen
Trage in der modelsim.ini folgendes ein:

CheckSynthesis = 1

[Ole (Gast)]

Danke euch, das wars!

Nun scheint alles bestens zu funktionieren :)

Werde dann auch mal CheckSynthesis = 1 probieren.

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

Ole schrieb:
> Nun scheint alles bestens zu funktionieren :)
In der Simulation: Ja.
Ind der Praxis: Nie und nimmer.
Warum bin ich mir da so sicher?
Weil du hier asynchrone Eingänge einfach ohne Einsynchronisieren auf 
eine FSM loslässt:

   TASTER: in BIT_VECTOR (4 downto 0);  -- Taster up, enter, down, left, right

   when Z0 =>     case TASTER is

http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html



Und ob du da Probleme mit prellenden Tasten haben kannst, da blicke ich 
noch nicht so recht durch mit den verwurstelten Zählerreset. Ich würde 
da auf jeden Fall erst mal die Taster entprellen und dann eine 
Flankenerkennung dahinter hängen: 
http://www.lothar-miller.de/s9y/categories/5-Entprellung
Aber irgendwie habe ich den Eindruck, dass du was einfaches kompliziert 
machst...  :-/
Was willst du denn erreichen?

[Ole (Gast)]

Hallo Lothar!

Vielen Dank für deine Kritik.
Erreicht werden soll folgendes: Wenn der Vierfachswitch SW7 komplett 
geschlossen ist, sollen die fünf Taster Up, Enter, Down, Left und Right 
ausgelesen werden. Jedem Taster ist ein LED-Code zugeordnet, welcher 
nach dem Drücken 3 Sekunden lang anliegen soll.
Bspw. sollen bei der Taste Up die LEDs 0110 anzeigen, also die mittleren 
beiden sollen 3 Sekunden leuchten.

Du hast im Übrigen Recht, ich habe diesen Code noch nicht auf einem 
Board ausprobiert. Ob es zu Laufzeitproblemen kommt, kann ich demnach 
nicht sagen.

Die prellenden Taster halte ich für vernachlässigbar, da ja ganze drei 
Sekunden gewartet werden soll. Ich glaube nicht, dass dem menschlichen 
Nutzer dann auffällt, ob der so eben losgelassene Taster noch ein paar 
mal in den nächsten µs den Zähler resettet. Für zeitlich kritische 
Anwendungen hast du natürlich Recht.

OT: Mein Lob an deine sehr gut verständliche Homepage! Habe darin eben 
gelesen und bin über den synchronen Reset gestolpert. Ich habe gelernt, 
dass der Reset aus Sicherheitgründen assynchron auszuführen ist. Falls 
mal der Takt ausfällt, ist es dann immer noch möglich, die zu steuernde 
Maschine (oder andere Dinge) auf einen Grundzustand zurück zu bringen.

Vielen Dank noch mal für deine Hilfe,
bg, Ole

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

Ole schrieb:
> Ich habe gelernt, dass der Reset aus Sicherheitgründen assynchron
> auszuführen ist. Falls mal der Takt ausfällt, ist es dann immer noch
> möglich, die zu steuernde  Maschine (oder andere Dinge) auf einen
> Grundzustand zurück zu bringen.
Das eine hat mit dem Anderen nichts zu tun. Es gibt in der 
Sicherheitstechnik andere Methoden, Ausgänge sicher zu schalten. Denn 
um die geht es da ja ausschließlich. Du müsstest also nur den 
Ausgangstreiber mit dem Reset in einen sicheren Zustand bringen. 
Sicherheitstechnisch reicht es nämlich gar nicht aus, ein so tief 
vergrabenes Bauteil wie das FPGA "sicher" zu machen, und sich dann drauf 
zu verlassen, dass die nachfolgenden Bauteile sicher abschalten.

> Falls mal der Takt ausfällt
Dann ist der Reset sicher eines der kleineren Probleme!
Ich hatte im Feld noch nie einen ausgefallenen Quarzoszillator.

Dass ein asynchroner Reset im FPGA Ressourcen frisst, das zeigt der 
Beitrag "Xilinx und die Resets"
Für andere Hersteller lont es sich, das Handbuch zu lesen. Und wenn 
schon, dann sollte der Reset zwar asynchron kommen (können), aber nur 
synchron weggehen dürfen! Denn sonst läuft dir dein Sytem mal an und mal 
nicht. Ich konnte das seinerzeit auch nicht glauben, ist aber so...  ;-)

> Die prellenden Taster halte ich für vernachlässigbar
Wenn du es nur nicht vergisst, dass die Dinger potentiell unsauber sind, 
dann kannst du das schon machen.

> OT: Mein Lob an deine sehr gut verständliche Homepage!
Danke.

[Ole (Gast)]

Hallo!

Lothar hatte Recht, auf einem Board ging mit dem Code schon mal gar 
nichts. Lag wahrscheinlich an Latches.
Demnach wurde nun noch mal ein neuer Code entwickelt, indem vor allem 
die Signale "LAUFEN" und "FERTIG" eingeführt wurden. Wenn "LAUFEN" 1 
ist, zählt der Zähler hoch und stellt nach 3 Sekunden "FERTIG" auf 1. 
Solange "FERTIG" nicht 1 ist, kann nicht in einen anderen Zustand 
gewechselt werden.
Daraus ergibt sich die Logik, dass FERTIG und LAUFEN nicht gleichzeitig 
1 bzw. 0 sein können.
Genau das tritt jedoch leider ein, wie bei der angehängten 
Timing-Simulation ersichtlich.

Was genau funktioniert da nicht?

----------------------------------------------------------------------------------
-- Company: 
-- Engineer: 
-- 
-- Create Date:    19:14:23 10/09/2012 
-- Design Name: 
-- Module Name:    Versuch1VBb - Behavioral 
-- Project Name: 
-- Target Devices: 
-- Tool versions: 
-- Description:   wenn sw7 komplett geschlossen -> taster auslesen und entsprechenden 
--           code auf LEDs ausgeben
--
-- Dependencies: 
--
-- Revision: 
-- Revision 0.01 - File Created
-- Additional Comments: 
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity Versuch1VBb is
    Port ( DIPSW : in  BIT_VECTOR (3 downto 0);  -- Switch SW7
           CLK,RESET : in BIT;        
        TASTER: in BIT_VECTOR (4 downto 0);  -- Taster up, enter, down, left, right
           LED : out  BIT_VECTOR (3 downto 0));  -- 4 LEDs
end Versuch1VBb;

architecture Verhalten of Versuch1VBb is
type ZUSTAENDE is (Z0, Z_UP, Z_ENTER, Z_DOWN, Z_LEFT, Z_RIGHT);
------ Z0 = Grundzustand
------ Z_UP..Z_RIGHT = Taster drücken

signal ZUSTAND, FOLGE_Z: ZUSTAENDE;
signal LAUFEN: bit :='0';
signal FERTIG: bit :='1';
signal QINT: integer :=0;

begin

----SPEICHER----
Z_SPEICHER: process(CLK, RESET)
  begin
    if RESET='0' then ZUSTAND <= Z0;   --bei reset in Z0 gehen
    elsif CLK='1' and CLK'event then
      if DIPSW = "1111" then         -- nur reagieren, wenn alle schalter geschlossen sind (LVTTL)
         ZUSTAND <= FOLGE_Z;         -- berechneten folgezustand zu aktuellem zustand machen
      end if;
    end if;
  end process Z_Speicher;

----UEBERGANGSSCHALTNETZ----
UE_SN: process (TASTER, ZUSTAND, FERTIG)
  begin
    if FERTIG='1' then        -- Zustandswechsel nur, wenn der zähler fertig ist
      case ZUSTAND is
        when Z0 =>     case TASTER is    -- Z0 = grundzustand, es wird auf eingabe gewartet
                    when "11110" => FOLGE_Z <= Z_ENTER;        
                    when "11101" => FOLGE_Z <= Z_UP;
                    when "11011" => FOLGE_Z <= Z_DOWN;
                    when "10111" => FOLGE_Z <= Z_LEFT;
                    when "01111" => FOLGE_Z <= Z_RIGHT;
                    when others  => FOLGE_Z <= Z0;
                  end case;
        when Z_UP =>     FOLGE_Z <= Z0;
        when Z_ENTER =>   FOLGE_Z <= Z0;
        when Z_DOWN =>   FOLGE_Z <= Z0;
        when Z_LEFT =>   FOLGE_Z <= Z0;
        when Z_RIGHT =>   FOLGE_Z <= Z0;
      end case;
    else
      FOLGE_Z<=ZUSTAND;    -- aktuellen zustand beibehalten, wenn zähler zählt
    end if;
  end process UE_SN;

----AUSGANGSSCHALTNETZ----
A_SN: process (ZUSTAND)
  begin
    case ZUSTAND is
      when Z0 =>       LED <= "1111";     --LEDs aus
                  LAUFEN <= '0';    --zähler darf nicht zählen
      when Z_UP =>     LED <= "1001";    --LEDcode bei tasterdruck ausgeben
                  LAUFEN <= '1';    --zähler darf zählen
      when Z_ENTER =>   LED <= "0000";
                  LAUFEN <= '1';
      when Z_DOWN =>   LED <= "0110";
                  LAUFEN <= '1';
      when Z_LEFT =>   LED <= "0101";
                  LAUFEN <= '1';
      when Z_RIGHT =>   LED <= "1010";
                  LAUFEN <= '1';
    end case;
  end process A_SN;

----TIMER----                
ZAEHLER: process (CLK, LAUFEN)
  
  begin
    
    if CLK='1' and CLK'event then  
      if LAUFEN = '1' then        -- nur zählen, wenn LAUFEN 1
        if QINT > 300000000 then    -- 3 sekunden zählen
          FERTIG <= '1';
        else 
          FERTIG <= '0';
        end if;
        QINT <= QINT + 1;
      else
        QINT <= 0;            -- wenn LAUFEN 0, zähler null setzen
      end if;
      
    end if;
  end process ZAEHLER;

end Verhalten;

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

Ich verrate dir nicht, wo der Fehler liegt, aber ich kann dir sagen, 
dass es von der Mischung synchroner und asychroner Prozesse kommt und 
sich "Latency" nennt.
Nur so viel: du kommst beim Zurücksetzten von LAUFEN 1 Takt "zu spät"
(= to late) , weil du den Umweg über ein weiteres Signal machst. Dieser 
Umweg kostet dich 1 Takt.


BTW:

ZAEHLER: process (CLK, LAUFEN)
begin
    if CLK='1' and CLK'event then 
    ...

Dieser Prozess ist nur auf clk sensitiv...

[Ole (Gast)]

Hi!

Danke für deine Hilfe! Dieses doppelte Signal war tatsächlich ein Dorn 
im Auge, jedoch fand ich es einfach schön, vom Timer ein Signal 
zurückgeben zu können.
Nun wird im Übergangsschaltnetz einfach wieder auf den Zählerstatus 
abgefragt. Herausgekommen ist Folgendes:

----------------------------------------------------------------------------------
-- Company: 
-- Engineer: 
-- 
-- Create Date:    19:14:23 10/09/2012 
-- Design Name: 
-- Module Name:    Versuch1VBb - Behavioral 
-- Project Name: 
-- Target Devices: 
-- Tool versions: 
-- Description:   wenn sw7 komplett geschlossen -> taster auslesen und entsprechenden 
--           code auf LEDs ausgeben
--
-- Dependencies: 
--
-- Revision: 
-- Revision 0.01 - File Created
-- Additional Comments: 
--
----------------------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
--use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity Versuch1VBb is
    Port ( DIPSW : in  BIT_VECTOR (3 downto 0);  -- Switch SW7
           CLK,RESET : in BIT;        
        TASTER: in BIT_VECTOR (4 downto 0);  -- Taster up, enter, down, left, right
           LED : out  BIT_VECTOR (3 downto 0));  -- 4 LEDs
end Versuch1VBb;

architecture Verhalten of Versuch1VBb is
type ZUSTAENDE is (Z0, Z_UP, Z_ENTER, Z_DOWN, Z_LEFT, Z_RIGHT);
------ Z0 = Grundzustand
------ Z_UP..Z_RIGHT = Taster drücken
signal ZUSTAND, FOLGE_Z: ZUSTAENDE;
signal LAUFEN: bit :='0';
signal QINT: integer := 31;

begin

----SPEICHER----
Z_SPEICHER: process(CLK, RESET)
  begin
    if RESET='0' then ZUSTAND <= Z0; --bei reset in Z0 gehen
    elsif CLK='1' and CLK'event then
      if DIPSW = "1111" then 
         ZUSTAND <= FOLGE_Z;
      end if;
    end if;
  end process Z_Speicher;

----UEBERGANGSSCHALTNETZ----
UE_SN: process (TASTER, ZUSTAND, QINT)
  begin
      if ZUSTAND = Z0 then
        case TASTER is
          when "11110" => FOLGE_Z <= Z_ENTER;        
          when "11101" => FOLGE_Z <= Z_UP;
          when "11011" => FOLGE_Z <= Z_DOWN;
          when "10111" => FOLGE_Z <= Z_LEFT;
          when "01111" => FOLGE_Z <= Z_RIGHT;
          when others  => FOLGE_Z <= Z0;
        end case;
      else
        if QINT >300000000 then
          FOLGE_Z <= Z0;
        else
          FOLGE_Z <= ZUSTAND;
        end if;
      end if;
  end process UE_SN;

----AUSGANGSSCHALTNETZ----
A_SN: process (ZUSTAND)
  begin
    case ZUSTAND is
      when Z0 =>       LED <= "1111";
                  LAUFEN <= '0';
      when Z_UP =>     LED <= "1001";
                  LAUFEN <= '1';
      when Z_ENTER =>   LED <= "0000";
                  LAUFEN <= '1';
      when Z_DOWN =>   LED <= "0110";
                  LAUFEN <= '1';
      when Z_LEFT =>   LED <= "0101";
                  LAUFEN <= '1';
      when Z_RIGHT =>   LED <= "1010";
                  LAUFEN <= '1';
    end case;
  end process A_SN;

----TIMER----                
ZAEHLER: process (CLK)  
  begin    
    if CLK='1' and CLK'event then  
      if LAUFEN = '1' then
        QINT <= QINT + 1;
      else
        QINT <= 0;
      end if;
    end if;
  end process ZAEHLER;

end Verhalten;

Blöderweise kann das leider wieder noch nicht auf einem Board 
ausprobiert werden, in der Simulation läuft es aber zu mindest schon 
mal.

Ich frage mich, was du gegen die asynchronen Prozesse hast. Im 
Übergangsschaltnetz wird der Folgezustand berechnet und später dann der 
Zustand in SPEICHER aktualisiert. Letzteres passiert Taktsynchron. Das 
Ausgangsschaltnetz habe ich bis jetzt noch nicht synchron gesehen.
Zusätzlich vertraue ich auf den jetzigen Code, da laut Synthetisierer 
keine Latches erzeugt werden.

Danke nochmals, lg,
Ole

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

Ole schrieb:
> Ich frage mich, was du gegen die asynchronen Prozesse hast. Im
> Übergangsschaltnetz wird der Folgezustand berechnet und später dann der
> Zustand in SPEICHER aktualisiert. Letzteres passiert Taktsynchron.
Und wie hast du dir die Latency eingefangen? Weil du die verschlungenen 
Wege vom einen zum anderen Signal nicht mehr nachvollziehen konntest. 
Und noch immer machst du einen unnötigen Umweg über den State, um deinen 
Zähler zurückzusetzen. Dein Zähler wird einen Takt zu spät 
zurückgesetzt. Auch das ist ein Takt Latency.

Lies einfach mal das durch:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

> Das Ausgangsschaltnetz habe ich bis jetzt noch nicht synchron gesehen.
Gegenfrage: Wofür braucht man ein Ausgangsschaltnetz, wenn man jeden 
Ausgang registrieren kann, weil im IO-Pin vom FPGA sowieso ein Flipflop 
ist?

> Zusätzlich vertraue ich auf den jetzigen Code,
> da laut Synthetisierer keine Latches erzeugt werden.
Gut, wenn du deinen Beschreibungsstil gefunden hast und damit glücklich 
bist...

> Danke nochmals
Keine Ursache.

[Bronco (Gast)]

Ole schrieb:
> Ich frage mich, was du gegen die asynchronen Prozesse hast.

Als ich mit VHDL angefangen hab, hab ich mal einen einfachen 
Zustandsautomat geschrieben, der ohne Takt auskommen sollte.
Auf einem CPLD ausprobiert: geht!
Auf einem FPGA ausprobiert: geht nicht!
Tatsächlich nahm der Automat im FPGA Zustände ein, die es in meinem Code 
überhaupt nicht gab.
Wie kann das sein?

Der Zustand (in Deinem Fall "ZUSTAENDE") wird als Bitwort kodiert, d.h. 
der tatsächliche Zustand des Automaten ergibt sich aus der Kombination 
der einzelnen Bits im Wort.
Im FPGA werden nun die Bits unterschiedliche Laufzeiten haben, d.h. beim 
Übergang von einem Zustand in einen anderen, wird es vorkommen, daß es 
zwischenzeitlich auch ein ganz anderer Zustand im Bitwort steht.
Mit Takt ist das kein Problem, weil das Bitwort zu einem ganz bestimmten 
Zeitpunkt "geschrieben" und "gelesen" wird und dazwischen der Zustand 
egal ist.
Ohne Takt reagiert der Automat sofort auf jede Änderung, dann verrennt 
er sich und Du kommst in Teufels Küche.