Forum: FPGA, VHDL & Co. Probleme mit state machine


von Andreas B. (loopy83)


Lesenswert?

Hallo,

ich habe ein Problem mit folgender state machine:
1
type cam_state_type is (WARTEN_RES, ENDE_RES);
2
signal cam_state2 : cam_state_type := WARTEN_RES;
3
4
reset_all <= RESET and reset2;
5
  
6
  reset_sl <= PER_RESET when rising_edge(CLOCK_IN_0);
7
8
  process (CLOCK_IN_0)
9
  begin
10
    if rising_edge(CLOCK_IN_0) then
11
      if reset_sl = '0' then
12
        cam_state2 <= WARTEN_RES;
13
        reset2 <= '0';
14
      else
15
        case cam_state2 is
16
        
17
          -- WARTEN_RES
18
          when WARTEN_RES =>
19
            reset2 <= '0';
20
            if GPIO = '0' then
21
              cam_state2 <= ENDE_RES;
22
            end if;
23
            
24
          --ENDE_RES
25
          when ENDE_RES =>
26
            reset2 <= '1';
27
            
28
          -- OTHERS
29
          when others =>
30
            cam_state2 <= WARTEN_RES;
31
        end case;
32
      end if;
33
    end if;
34
  end process;

Zur Aufgabe:
der externe RESET wird irgendwann auf '1' gesetzt.
Danach soll der reset2 erst auf '1' gehen, wenn das GPIO signal '0' ist.
Dann bleibt reset2 solange '1', bis der externe RESET wieder Reset gibt.

Nun habe ich das Problem, dass nach dem Beschreiben des FPGA alles 
wunderbar funktioniert. Also RESET ist '0', wird dann auf '1' gesetzt, 
alles läuft los, bis dann irgendwann RESET wieder auf '0' geht.
Nach diesem ersten Durchlauf wird reset2 nicht mehr auf '1' gesetzt, 
deswegen vermute ich das Problem in dieser statemachine.

Ich habe die Sache 100mal durchgedacht und kann nirgendwo erkennen, wo 
cam_state2 irgendwann ins Nirvana springt oder wo das Problem liegt.

Hat jemand einen Hinweis für mich?

Vielen Dank!
Andi

von Mathi (Gast)


Lesenswert?

Andreas B. schrieb:
>           --ENDE_RES
>           when ENDE_RES =>
>             reset2 <= '1';

Du gehst ja auch nicht mehr aus dem Zustand heraus. Deswegen bleibt 
reset2 auf '1'.
Ein others wird nämlich nicht synthtisiert...

von Mathi (Gast)


Lesenswert?

Ach, Mist.. wer ordentlich liest ist klar im vorteil...

von Andreas B. (loopy83)


Lesenswert?

Hallo,

aber ganz am Anfang im
1
 if reset_sl = '0' then
2
        cam_state2 <= WARTEN_RES;
3
        reset2 <= '0';
wird doch der Ausstieg definiert zum Warte state... nämlich wenn RESET = 
'0' ist. Und das tritt ja zwischendurch definitiv ein.

Danke, Andi :)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Dorthin springt die FSM garantiert nicht, denn für others wird 
keinerlei Logik generiert, weil alle Zustände von cam_state2 verwendet 
werden:
1
          -- OTHERS
2
          when others =>
3
            cam_state2 <= WARTEN_RES;
Siehe dazu http://www.lothar-miller.de/s9y/categories/25-when-others

> Nach diesem ersten Durchlauf wird reset2 nicht mehr auf '1' gesetzt,
> deswegen vermute ich das Problem in dieser statemachine.
Nachdem die FSM nur 2 Zustände hat, kann sie eigentlich nur im ersten 
hängen, denn im 2. Zustand wäre reset2 ja definitiv '1'.

Woher kommt der PER_RESET, der das garantiert beeinflussen könnte?

BTW:
1
           if GPIO = '0' then
Ich würde hierhin auch ein Fragezeichen setzen, wenn GPIO nicht 
einsynchronisiert ist

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.