FSM debuggen

nospam@example.com (Lothar Miller) — Wed, 08 Jul 2009 20:35:00 +0200

Wenn ich eine State-Machine in der Hardware debuggen will, ist es oft sinnvoll, auf ein paar LEDs oder Ausgangspins am Logikanalyzer zu sehen, was gerade in der SM abgeht. Die manuelle Variante ist nun, dem Debugport die States in einem extra dafür gerschriebenen Prozess die Information zuzuordnen:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.ALL;

entity DebugFSM is
    Port ( clk : in  STD_LOGIC;
           state_as_vector : out  STD_LOGIC_VECTOR (3 downto 0));
end DebugFSM;

architecture Behavioral of DebugFSM is
type states is (s0,s1,s2,s3,s4,s5);
signal state : states := s0;
begin
   process begin
     wait until rising_edge(clk);
    case state is 
       when s0 => state <= s1;
       :
       when s5 => state <= s0;
       when others  => state <= s0;
     end case;
   end process;

   -- Kombinatorisches Zuweisen der States auf die Debug-Signale
   process (state) begin
    case state is 
       when s0 => state_as_vector <= "0000";
       when s1 => state_as_vector <= "0001";
       when s2 => state_as_vector <= "0010";
       when s3 => state_as_vector <= "0011";
       when s4 => state_as_vector <= "0100";
       when s5 => state_as_vector <= "0101";
     end case;
   end process;

end Behavioral;

Wesentlich eleganter geht es allerdings, wenn das attribut 'pos auf den Aufzählungstyp angewendet wird:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.ALL;

entity DebugFSM is
    Port ( clk : in  STD_LOGIC;
           state_as_vector : out  STD_LOGIC_VECTOR (3 downto 0));
end DebugFSM;

architecture Behavioral of DebugFSM is
type states is (s0,s1,s2,s3,s4,s5);
signal state : states := s0;
begin
   process begin
     wait until rising_edge(clk);
    case state is 
       when s0 => state <= s1;
       :
       when s5 => state <= s0;
       when others  => state <= s0;
     end case;
   end process;

   -- Zuweisen der States auf die Debug-Signale
   state_as_vector <= std_logic_vector(to_unsigned(states'pos(state),4));

end Behavioral;

Da Zählung (Enumeration) des entsprechenden Zustandes links mit 0 beginnt, bestimmt die Position auch den Zahlenwert. Die beiden beschriebenen Beispiele verhalten sich also unabhängig von der tatsächlichen Implementation der Statemachine (Binär, One-Hot, Gray,...) gleich.

Ein- oder Zwei-Prozess-Schreibweise für FSM

nospam@example.com (Lothar Miller) — Tue, 23 Jun 2009 10:37:23 +0200

Immer wieder kommt die Diskussion auf, ob denn jetzt die Ein- oder Zwei-Prozess-Darstellung von Zustandsautomaten einfacher zu verstehen und implementieren sei.

Wenn man aus der schulmäßigen Logik herkommt, dann wird ein Automat auf eine Weiterschaltlogik (die den Folgezustand ermittelt) und einen Zustandsspeicher abgebildet.

Es wird also eine Abbildung in zwei Prozesse nahegelegt:
1) der eine Prozess übernimmt taktgesteuert den Folgezustand, der
2) vom anderen Prozess aus den Eingangssignalen und/oder dem aktuellen Zustand ermittelt wird.

Damit könnte ein einfacher Automat mit den Zuständen reset, idle, work und done so aussehen:

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

entity FSM is
    Port ( clk : in  STD_LOGIC;
           rst : in  STD_LOGIC;
           start : in  STD_LOGIC;
           stop  : in  STD_LOGIC;
           dout  : out  STD_LOGIC_VECTOR (3 downto 0));
end FSM;

architecture Verhalten of FSM is

type state_t is (reset, idle, work, done);
signal state, next_state : state_t := idle;
signal counter, next_counter : unsigned(3 downto 0) := "0000";

begin
   process begin
      wait until rising_edge(clk);
      state   <= next_state;
      counter <= next_counter;
   end process;

   process (state, rst, start, stop, delay, counter)
   begin      
      next_counter <= (others=>'0');
      case state is
         when reset => next_state   <= idle;
                      
         when idle  => if (start='1') then
                          next_state <= work;
                       end if;
        
         when work  => if (stop='1') then
                          next_state <= done;
                       end if;
                       next_counter <= counter+1;

         when done  => if (stop='0') then
                          next_state <= idle;
                       end if;
      end case;
      if (rst='1') then
         next_state <= reset;
      end if;
   end process;
  
   dout <= std_logic_vector(counter);

end Verhalten;

Aus dem Zustand idle kommend, wird mit dem Signal start der Zustand work angesprungen. Im Zustand work wird der Zähler solange hochgezählt, bis das Signal stop aktiv wird. Danach geht es über den Zustand done zurück nach idle. Wird der Eingang rst aktiv, so geht es ohne Umleitung in den Zustand reset. Parallel wird der Zähler counter concurrent auf dout ausgegeben.

Weil ein Zähler auch nur eine FSM ist, muß für das Hochzählen von counter in der Kombinatorik der Folge-Zählerstand next_counter ermittelt werden. Dieser wird dann mit dem nächsten Takt auf counter übernommen.

Bis hierher war es eigentlich noch übersichtlich.
Jetzt möchte ich aber gerne das Hochzählen von counter im Zustand work etwas gemächlicher gestalten. Ein Verzögerungszähler für 10 Takte delay (von 0 bis 9) vor dem Hochzählen von counter muß her.
Jetzt könnte ich das Spiel genauso wie mit counter und next_counter machen, aber diesmal bin ich zu faul und nehme den Verzögerungszähler delay einfach gleich in den getakteten Teil:

architecture Verhalten of FSM is
type state_t is (reset, idle, work, done);
signal state, next_state : state_t := idle;
signal delay : integer range 0 to 9 := 0;
signal counter, next_counter : unsigned(3 downto 0) := "0000";

begin
   process begin
      wait until rising_edge(clk);
      state   <= next_state;
      counter <= next_counter;

      if(state=idle) then -- in idle: Delay-Zähler zurücksetzen
         delay <= 0;                     
      end if;

      if(state=work) then -- in work: hier wird gezählt
         if (delay < 9) then  -- solange kleiner 9:
            delay <= delay+1; -- zählen
         else
            delay <= 0;       -- sonst zurücksetzen
         end if;
      end if;
   end process;

   process (state, rst, start, stop, delay, counter)
   begin      
      next_counter <= (others=>'0');
      case state is
         when reset => next_state   <= idle;
                      
         when idle  => if (start='1') then
                          next_state <= work;
                       end if;
        
         when work  => if (delay = 9) then           -- wenn das Delay abgelaufen ist:
                          next_counter <= counter+1; -- counter um eins hochzählen
                       end if;
                      
                       if (stop='1') then
                          next_state <= done;
                       end if;
  

         when done  => if (stop='0') then
                          next_state <= idle;
                       end if;
      end case;
      if (rst='1') then
         next_state <= reset;
      end if;
   end process;
  
   dout <= std_logic_vector(counter);

end Verhalten;

Fertig. Hurra, die Simulation zeigt, dass es geht:

Simulation: counter mit delay

Aber wer sich den Code ein halbes Jahr später anschaut, wird den Kopf schütteln, und sich fragen, wie und was da wann wozu verwendet wird.

Ich schreibe deshalb meine State-Machines nur noch in der Ein-Prozess-Darstellung. In dieser Darstellungsart wandert einfach nur die Weiterschaltlogik in den getakteten Teil. Das obige Beispiel sieht also so aus:

architecture Verhalten of FSM is
type state_t is (reset, idle, work, done);
signal state : state_t := idle;
signal delay : integer range 0 to 9 := 0;
signal counter : unsigned(3 downto 0) := "0000";

begin

   process begin
      wait until rising_edge(clk);
      case state is
         when reset => counter <= (others=>'0');
                       state   <= idle;
                      
         when idle  => delay   <= 0;
                       if (start='1') then
                          state <= work;
                       end if;
        
         when work  => if (delay < 9) then      -- solange kleiner 9:
                          delay <= delay+1;     -- zählen
                       else                     -- sonst:
                          delay   <= 0;         -- zurücksetzen
                          counter <= counter+1; -- und counter hochzählen
                       end if;

                       if (stop='1') then
                          state <= done;
                       end if;

         when done  => if (stop='0') then
                          state <= idle;
                       end if;
      end case;
      if (rst='1') then
         state <= reset;
      end if;
   end process;
  
   dout <= std_logic_vector(counter);

end Verhalten;

Diese Ein-Prozess-Beschreibung ergibt genau das selbe Simulationsergebnis, sie hat aber deutliche Vorteile:
1) Deutlich weniger Schreibaufwand und bessere Übersicht
2) Ich brauche weniger Signale (next_counter, next_state)
3) Das Ganze ist garantiert synchron
4) Die Ausgangssignale sind registriert und damit synchron
5) Es werden garantiert keine Kombinatorischen Schleifen erzeugt

Lothar Miller - FSM

FSM debuggen

Ein- oder Zwei-Prozess-Schreibweise für FSM