Hallo,
ich stehe da irgendwie auf dem Schlauch. Folgender VHDL Code

entity ResetGenerator is
    Port ( RESET_IN : in  STD_LOGIC;
           CLK_IN : in  STD_LOGIC;
           STATE_OUT: out std_logic_vector(1 downto 0);
           RESET_OUT : out  STD_LOGIC);
end ResetGenerator;

architecture Behavioral of ResetGenerator is

signal state: bit_vector(1 downto 0);

begin
  process(state, RESET_IN, CLK_IN)
  begin
    if rising_edge(CLK_IN) then
      case state is
  when "00" =>
    state <= "00";
    RESET_OUT <= '0';
    if RESET_IN = '1' then
      state <= "01";
      RESET_OUT <= '1';
    end if;
  when "01" =>
    state <= "11";
    RESET_OUT <= '1';
  when "11" =>
    state <= "10";
    RESET_OUT <= '0';
  when "10" =>
    state <= "10";
    RESET_OUT <= '0';
    if RESET_IN = '0' then
      state <= "00";
      RESET_OUT <= '0';
    end if;
  when others =>
    state <= "00";
      end case;
    end if;
  end process;
  STATE_OUT <= to_stdlogicvector(state);
end Behavioral;

Soll ein RESET_IN Signal entgegennehmen, für zwei CLK_IN Zyklen eine
'1' auf das Ausgangssignal RESET_OUT legen und danach warten, bis das
Eingangssignal wieder auf Null geht, damit das ganze wieder von vorn
beginnen kann.
Board ist ein Spartan 3AN Prototypenboard von DIGILENT, ich benutze ISE
13.2.
CLK_IN ist der 50MHz Quarz, RESET_IN einer der Taster.
RESET_OUT, STATE_OUT und auch der Taster sind auf LEDs gelegt,
das RESET_OUT-Signal wird zusätzlich noch mit einem Oszi überprüft.

Wenn ich jetzt das ganze ausprobiere:
Taste gedrückt: LED für Taste an, STATE_OUT ist "10"
Taste losgelassen: LED für Taste aus, STATE_OUT ist "00"
Es wird beim Drücken der Taste ein 40ns Impuls erzeugt.
So weit so gut...
Tippe ich jetzt mehrfach auf den Taster hängt das ganze nach kurzer 
Zeit.
Wenn es hängt:
Taste gedrückt: LED für Taste an, STATE_OUT ist _"00"_
Taste losgelassen: LED für Taste aus, STATE_OUT ist "00"
Es wird beim Drücken der Taste KEIN 40ns Impuls erzeugt.

Wie kann das sein? Was habe ich da nicht begriffen?

Gruß, Patric

so kann man das besser lesen

entity ResetGenerator is
    Port ( RESET_IN : in  STD_LOGIC;
           CLK_IN : in  STD_LOGIC;
           STATE_OUT: out std_logic_vector(1 downto 0);
           RESET_OUT : out  STD_LOGIC);
end ResetGenerator;

architecture Behavioral of ResetGenerator is

signal state: bit_vector(1 downto 0);

begin
  process(state, RESET_IN, CLK_IN)
  begin
    if rising_edge(CLK_IN) then
      case state is
        when "00" =>
          state <= "00";
          RESET_OUT <= '0';
          if RESET_IN = '1' then
            state <= "01";
            RESET_OUT <= '1';
          end if;
        when "01" =>
          state <= "11";
          RESET_OUT <= '1';
        when "11" =>
          state <= "10";
          RESET_OUT <= '0';
        when "10" =>
          state <= "10";
          RESET_OUT <= '0';
          if RESET_IN = '0' then
            state <= "00";
            RESET_OUT <= '0';
          end if;
        when others =>
          state <= "00";
      end case;
    end if;
  end process;
  STATE_OUT <= to_stdlogicvector(state);
end Behavioral;

keine fundierten Tipps, aber:

1. hast du das ganze mal simuliert?
2. die Fehlerbeschreibung klingt, als ob du irgendwo Probleme mit einem 
prellenden Taster hättest

Ok, wie geht das mit der Lesbarkeit?

Und Danke erstmal für die Antwort.

zu 1. nein ich habe es nicht simuliert (kenne mich da mit den Tools 
(noch)
nicht so ganz aus.

zu 2. Müsste es nicht egal sein, ob der Taster prellt? Das Ding hängt
komplett. Selbst wenn der Taster irgendwo prellt müsste sich das ganze 
doch
wieder fangen, da es keinen Zustand gibt, der als Sackgasse in Frage 
kommt?
Der Taster funktioniert laut LED und die 50MHz sind auch weiterhin da
(Oszi geprüft).

Warnungen:
Ja, jede Menge, die aber nichts mit dem entsprechenden Fetzen Hardware
zu tun haben. Nur für den ResetGenerator beschwert sich das Tool über 
den
default case (zu recht) und schmeisst ihn weg.

Ich habe das Ganze noch eben mal mit einem globalen asynchronen Reset
versehen (weiterer Taster). Es dauert gefühlt 5* so lang bis das Ganze 
hängt.
Aber es lässt sich wieder zum Leben erwecken indem man state auf "00" 
zwingt
und RESET_OUT auf '0'.

Kann ein bit_vector noch andere Zustände annehmen als "00" "01" "11" 
"10"?

Derzeitiger Code:

entity ResetGenerator is
    Port ( RESET_IN : in  STD_LOGIC;
         RESET: in STD_LOGIC;
           CLK_IN : in  STD_LOGIC;
        STATE_OUT: out std_logic_vector(1 downto 0);
           RESET_OUT : out  STD_LOGIC);
end ResetGenerator;

architecture Behavioral of ResetGenerator is

signal state: bit_vector(1 downto 0);

begin
  process(RESET, state, RESET_IN, CLK_IN)
  begin
    if RESET = '1' then
      state <= "00";
      RESET_OUT <= '0';
    else
      if rising_edge(CLK_IN) then
        case state is
          when "00" => 
            state <= "00";
            RESET_OUT <= '0';
            if RESET_IN = '1' then
              state <= "01";
              RESET_OUT <= '1';
            end if;
          when "01" =>
            state <= "11";
            RESET_OUT <= '1';
          when "11" =>
            state <= "10";
            RESET_OUT <= '0';
          when "10" =>
            state <= "10";
            RESET_OUT <= '0';
            if RESET_IN = '0' then
              state <= "00";
              RESET_OUT <= '0';
            end if;
          when others =>
            state <= "00";
        end case;
      end if;
    end if;
  end process;    
  STATE_OUT <= to_stdlogicvector(state);
end Behavioral;

Toll die Formatierung funktioniert ziemlich gut :)

Danke Achim!

Also die Antwort auf meine Frage mit den Zuständen des bit_vectors wäre 
dann ein nein, aber das Synthesetool weiss es besser?
Ich dachte ich hätte das RESET_IN Signal über die Statemachine 
einsynchronisiert. Nun gut dann werde ich mir morgen mal ISE genauer 
ansehen, oder kannst Du mir sagen wo ich Einfluss auf die SM-Generation 
nehmen kann?

Ach Quartus war irgendwie einfacher :)

Aber das werde ich mir mal genauer zu Gemüte führen, ich habe schon an 
meinem Verstand gezweifelt. Immerhin ist es ja schon ein Gray-Code.

Achim S. schrieb:
> Nö: du wertest das Signal zwar nur bei der steigenden Taktflanke aus,
> aber das Signals kann sich genau zu diesem Zeitpunkt ändern.
Und noch nicht mal das ist das Problem. Das kommt nämlich gleich danach: 
nicht alle Flipflops der FSM sehen den selben Pegel. Das ist der 
eigentliche Knackpunkt.

  process(RESET, state, RESET_IN, CLK_IN)
  begin
    if RESET = '1' then
      state <= "00";
      RESET_OUT <= '0';
    else
      if rising_edge(CLK_IN) then

Diese Sensitivliste ist überbestimmt. Da muss der Simulator zu viel tun, 
denn er wird unnötigerweise bei einer Änderung von state und RESET_IN zu 
einer Neuberechnung genötigt!


Patric vL schrieb:
> Ach Quartus war irgendwie einfacher :)
Das hat nichts mit Quartus zu tun. Auch Altera kocht da mit dem selben 
Wasser: unterschiedliche Laufzeiten von asynchronen Signalen, die direkt 
in eine FSM gehen, führen per Definition zu Fehlern.

> Nun gut dann werde ich mir morgen mal ISE genauer ansehen, oder kannst
> Du mir sagen wo ich Einfluss auf die SM-Generation nehmen kann?
Als Faustformel: wenn du durch eine geänderte FSM-Implementierung ein 
anderes Verhalten der FSM bekommst, dann hast du mit an Sicherheit 
grenzender Wahrscheinlichkeit einen Designfehler, der irgendwas mit 
Laufzeiten und/oder der Verdrahtung zu tun hat.

Patric vL schrieb:
> Ich habe das Ganze noch eben mal mit einem globalen asynchronen Reset
> versehen (weiterer Taster). Es dauert gefühlt 5* so lang bis das Ganze
> hängt.
Wie gesagt: andere Verdrahtung, anderes Verhalten.
Ursache: nicht einsynchronisierter Eingang, der direkt in die FSM geht.

Ein asynchroner Reset, wieder mal...

  process(RESET, state, RESET_IN, CLK_IN)
  begin
    if RESET = '1' then

Dazu den Klassiker im Beitrag "Xilinx und die Resets"
Und das lesenswerte WP272 von Xilinx.

Hallo Achim S.,
hallo Lothar M.,

zu dem Punkt Synthesetool erkennt Statemachine:
Beim Schematic sind tatsächlich 4 FlipFlops zu erkennen. Ich durchschaue
das Schematic nicht ganz, aber es sieht nach einer OneHot-Codierung aus.
Beim Menuepunkt "FSM Encoding Algorithm" war "Auto" eingetragen.
Ich habe das RESET-Signal erstmal wieder rausgenommen (war eh nur um zu
prüfen, ob man einen augenscheinlichen "00" state auf "00" resetten 
kann)
und ich habe "FSM Encoding Algorithm" auf "None" gesetzt damit 
funktioniert
der folgende Code:

process(CLK_IN)
  begin
    if rising_edge(CLK_IN) then
      case state is
        when "00" => 
          state <= "00";
          RESET_OUT <= '0';
          if RESET_IN = '1' then
            state <= "01";
            RESET_OUT <= '1';
          end if;
        when "01" =>
          state <= "11";
          RESET_OUT <= '1';
        when "11" =>
          state <= "10";
          RESET_OUT <= '0';
        when "10" =>
          state <= "10";
          RESET_OUT <= '0';
          if RESET_IN = '0' then
            state <= "00";
            RESET_OUT <= '0';
          end if;
        when others => 
          state <= "00";
      end case;
    end if;
  end process;

zumindest habe ich nach 5min Finger wundtippen keinen Hänger gehabt (ich
weiss, dass dies kein Beweis ist).

zum Punkt einsynchronisieren des RESET_IN Signales:
Ich habe in einem zweiten process das RESET_IN Signal mit CLK_IN 
synchronisiert und dabei das Signal synced_reset generiert und dieses
statt RESET_IN verwendet. Code:

process (CLK_IN)
  begin
    if rising_edge(CLK_IN) then
      synced_reset <= RESET_IN;
    end if;
  end process;

  process(CLK_IN)
  begin
    if rising_edge(CLK_IN) then
      case state is
        when "00" => 
          state <= "00";
          RESET_OUT <= '0';
          if synced_reset = '1' then
            state <= "01";
            RESET_OUT <= '1';
          end if;
        when "01" =>
          state <= "11";
          RESET_OUT <= '1';
        when "11" =>
          state <= "10";
          RESET_OUT <= '0';
        when "10" =>
          state <= "10";
          RESET_OUT <= '0';
          if synced_reset = '0' then
            state <= "00";
            RESET_OUT <= '0';
          end if;
        when others => 
          state <= "00";
      end case;
    end if;
  end process;

"FSM Encoding Algorithm" wurde wieder auf "Auto" gesetzt. Im Schematic
konnte ich jetzt keine OneHot-Codierung finden. Daher habe ich
"FSM Encoding Algorithm" auf "OneHot" gesetzt ich konnte aber immer noch
keine OneHot-Codierung im Schematic finden. Die "Auto" und "OneHot"
Versionen habe ich getestet (diesmal mit Funktionsgenerator) und auch
diesmal hängt nichts.

Fazit:
An sich war die Gray-Codierung nicht falsch, aber das Synthesetool
hat eine OneHot-Codierung daraus gemacht und die knirscht, weil das 
RESET_IN-Signal dadurch nicht (mehr?) synchronisiert war.

Ich danke Euch, ich war nämlich kurz davor meinen Verstand zu verlieren,
abgesehen davon fallen mir spontan drei Stellen ein, bei denen diese
Art Fehler auch noch dazwischen funkt.

Gruß, Patric

@Martin

Soweit ich das verstanden habe wird bei der Synthese

    RESET_OUT <= '0';
    if RESET_IN = '1' then
      state <= "01";
      RESET_OUT <= '1';
    end if;

Der Anweisungsblock von oben nach unten interpretiert und der letzte
Zustand "gilt". Das macht den Code lesbarer, weil man oben quasi
erstmal den Default-Zustand definieren kann und unten auf die
Einzelfälle eingehen kann.
In einem meiner Bücher wurde das als guter Stil propagiert.

@Achim S.

Spontan hätte ich ja gesagt, dass, da beim Gray-Code ja immer nur ein
Bit kippt alles in Ordnung sein sollte, aber nach längerem Meditieren
kommen mir Zweifel.

Ich habe dass jetzt noch mal mit Funktionsgenerator, "None",
Gray-Codierung und ohne Synchronisierung durchlaufen lassen, mit Oszi
auf Nachleuchten unendlich und siehe da: manche Impulse sind nur 20ns
lang. Also es scheint ein "Durchrutschen" von "00" auf "11" zu geben.
Ich ziehe mein Fazit zurück :( War zugegebenermassen nur ein Versuch
wenigstens ein wenig Recht zu haben ;)
ABER meine Gray-Version würde wenigstens nicht hängenbleiben (jaja
ich weiss unsauber ist unsauber).

@martin (Gast)
Lesbarkeit ist immer gut. Würde denn eine solche Codierung auch
hängenbleiben können? Die bit_vector[2]-Gray-Version hat ja durch
die Synthese als OneHot zusätzliche "illegale" States erzeugt, die sich
mit when others nicht abfangen liessen, weil es semantisch vollständig
auscodiert war.

martin schrieb:
> Zwei verschiedene Zuweisungen  auf 'state' , welche soll
> denn bitteschön gelten?
Wie üblich beim Prozess: die letzte Zuweisung an ein Signal gewinnt...
Der "Zwischenzustand" existiert in diesm Fall gar nicht. Nehmen wir mal 
diese (etwas unsinnige und umständliche) Beschreibung:

process (clk) begin
   if rising_edge(clk) then
       Ausgang <= '0';
       if Eingang='1' then
          Ausgang <= '1';
       end if;
   end if;
end process;

Frage:
Was macht bei einer Taktflanke der Ausgang, wenn der Eingang '1' ist?
Antwort:
Der Ausgang ist fest auf '1'. Da gibt es keine auch noch so kurzen 
Spikes nach '0', obwohl da eine Defaultzuweisung (Ausgang <= '0') steht.

Patric vL schrieb:
> ABER meine Gray-Version würde wenigstens nicht hängenbleiben (jaja
> ich weiss unsauber ist unsauber).
Glück gehabt, denn du hast alle Zustände verwendet.
Wenn das jetzt aber nicht sowas simples wäre, sondern eine FSM, die z.B. 
einen Getränkeautomaten steuert, dann käme z.B. der Kaffee und dann wäre 
Ende. Oder es käme nur ein Becher, oder kein Pulver...

EDIT:
Zweiter! Duke hatte das mit dem "gewinnen" schon erwähnt... ;-)