Probleme mit Statemachine

[Chris (Gast)]

Hallo,
entweder es is schon zu spät oder ich werde bekloppt.
Habe bis jetz meines Erachtens immer so eine StateMachine kodiert, die 
auch immer funktionierte.
Mein Problem ist folgendes:
Das busy-signal wird richtig gesetzt, aber der state wird nicht sofort 
gewechselt. z.b Zeitpunkt 50ms müsste state in work gehen und nicht erst 
bei 70ms...
Was übersehe ich da gerade?
Gruß
Chris

architecture Behavioral of wishbone_master is
  
  type state_type is (IDLE, WORK);
  signal state, state_next: state_type;
  signal tmp_busy  : STD_LOGIC;
  signal tmp_dat_o : STD_LOGIC_VECTOR(31 downto 0);
  signal tmp_adr_o : STD_LOGIC_VECTOR(10 downto 0);
  signal tmp_dat_i : STD_LOGIC_VECTOR(31 downto 0);
  signal tmp_we_o  : STD_LOGIC;
  
begin
  
  busy  <= tmp_busy;
  dat_o <= tmp_dat_o;
  adr_o <= tmp_adr_o;
  rd    <= tmp_dat_i;
  we_o  <= tmp_we_o;
  
  process(clk)
  begin
    if rising_edge(clk) then
      if rst = '1' then
        state <= idle;
      else
        state <= state_next;
      end if;
    end if;
  end process;
  
  process(state,cmd,ack_i)
  begin
    
    state_next <= state;
    tmp_busy   <= '0';
    tmp_we_o   <= '0';
    stb_o      <= '0';
    
    case state is
      when IDLE =>
        state_next <= IDLE;
        if cmd(0) = '1'  then  -- 0|1 lesen 1|1 schreiben
          state_next <= WORK;
          tmp_busy <= '1';
          tmp_we_o <= cmd(1);
          stb_o <= '1';
          cyc_o <= '1';
          tmp_dat_o <= wd;
          tmp_adr_o <= a(10 downto 0);
          tmp_dat_i <= dat_i;
        end if;
      
      when WORK =>
        state_next <= WORK;
        tmp_busy <= '1';
        stb_o <= '1';
        cyc_o <= '1';
        tmp_dat_o <= wd;
        tmp_adr_o <= a(10 downto 0);
        tmp_dat_i <= dat_i;
        
        if ack_i = '1' then
          state_next <= IDLE;
          tmp_busy <= '0';
          stb_o <= '0';
          cyc_o <= '0';
        end if;
    end case;
    
  end process;
  
end Behavioral;

[Leonard Lebewohl (Gast)]

Chris schrieb:

Ohne zeiten für den takt oder simu-waveform fällt es schwer denn problem 
zu versetehen. Mit fällt nur auf das tmp_busy ungetaktet ist und state 
getaktet (so wie es sein soll). Daraus folgt das sich zuers tmp_busy 
ändert und dann state zu WORK wechselt. Vielleicht liegt das problem 
auch an dem taktteiler, 50 Milisekunden sind nicht gerade typisch für 
einen takt. Taktet deine statemachine wirklich im kHz - Bereich ?!.

MfG,


> Hallo,
> entweder es is schon zu spät oder ich werde bekloppt.
> Habe bis jetz meines Erachtens immer so eine StateMachine kodiert, die
> auch immer funktionierte.
> Mein Problem ist folgendes:
> Das busy-signal wird richtig gesetzt, aber der state wird nicht sofort
> gewechselt. z.b Zeitpunkt 50ms müsste state in work gehen und nicht erst
> bei 70ms...

[Leonard Lebewohl (Gast)]

Vielleicht hält der rst den statemachine im IDLE?

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

Leonard Lebewohl schrieb:
> Mit fällt nur auf das tmp_busy ungetaktet ist und state getaktet (so
> wie es sein soll).
Mir fällt auf, dass in der Sensitivliste des kombinatorischen Prozesses 
fast alle nötigen Signale (dat_i, a und wd) fehlen...

Chris schrieb:
> Das busy-signal wird richtig gesetzt, aber der state wird nicht sofort
> gewechselt.
Ja nun, das busy Signal ist ja auch kombinatorisch, der State getaktet. 
Wie sieht das denn mit dem Zeitbezug zwischen state_next und (tmp_)busy 
aus? Kommen die gelichzeitig?

Was ist das für eine angehängte Datei namens "plot"? Mach doch einfach 
Screenshots im png oder gif Format...

[Chris (Gast)]

Hallo,
sorry die plot datei stellt die simulations datei dar. irgendwie hatte 
die keine endung.... sollte jetzt klappen.
Ist das nicht egal mit welchem takt ich das takte? zur einfachen und 
schnelleren simulation habe ich einfach 20 ms als periode angenommen, 
hier meine testbench:

--------------------------------------------------------------------------------
-- Company: 
-- Engineer:
--
-- Create Date:   14:09:08 11/11/2013
-- Design Name:   
-- Module Name:   /home/kppe13d/Komplexprakitkum/brutal-pineapple/MIPS/data_memory_tb.vhd
-- Project Name:  MIPS_Proc
-- Target Device:  
-- Tool versions:  
-- Description:   
-- 
-- VHDL Test Bench Created by ISE for module: data_memory
-- 
-- Dependencies:
-- 
-- Revision:
-- Revision 0.01 - File Created
-- Additional Comments:
--
-- Notes: 
-- This testbench has been automatically generated using types std_logic and
-- std_logic_vector for the ports of the unit under test.  Xilinx recommends
-- that these types always be used for the top-level I/O of a design in order
-- to guarantee that the testbench will bind correctly to the post-implementation 
-- simulation model.
--------------------------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
use work.mips_constants.all;
 
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--USE ieee.numeric_std.ALL;
 
ENTITY data_memory_tb IS
END data_memory_tb;
 
ARCHITECTURE behavior OF data_memory_tb IS 
 
    -- Component Declaration for the Unit Under Test (UUT)
 
    COMPONENT data_memory
    PORT(
      clk  : in STD_LOGIC;
      rst  : in STD_LOGIC;
      cmd  : in STD_LOGIC_VECTOR(1 downto 0);
      wd   : in STD_LOGIC_VECTOR(31 downto 0);
      a    : in STD_LOGIC_VECTOR(31 downto 0);
      rd   : out STD_LOGIC_VECTOR(31 downto 0);
      busy : out STD_LOGIC
        );
    END COMPONENT;
    

   --Inputs
      signal clk : STD_LOGIC :='0';
      signal rst : STD_LOGIC :='0';
      signal cmd : STD_LOGIC_VECTOR(1 downto 0);
      signal wd  : STD_LOGIC_VECTOR(31 downto 0);
      signal a   : STD_LOGIC_VECTOR(31 downto 0);
   --Outputs
      signal rd  : STD_LOGIC_VECTOR(31 downto 0);
      signal busy: STD_LOGIC;
  -- Indicates end of simulation
  signal finished : std_logic := '0';
BEGIN
 
  -- Instantiate the Unit Under Test (UUT)
   uut: data_memory PORT MAP (
      clk => clk,
      rst => rst,
      cmd => cmd,
      wd => wd,
      a => a,
      rd => rd,
      busy => busy
        );
  
  -- Generate Clock
  clk <= not clk after 10 ms when finished ='0' else clk;
   
  -- Stimulus process
   stim_proc: process
   begin    
      -- hold reset state for 100 ns.
    rst <= '1';
    cmd <= b"11";
    wait until rising_edge(clk);
    cmd <= b"00";
    rst <= '0';
    wait until rising_edge(clk);
      -- insert stimulus here 
    wait until rising_edge(clk);
    cmd <= b"01";
    a <= x"00000001";
    wait until rising_edge(clk);
    cmd <= b"00";
    wait until rising_edge(clk);
    cmd <= b"11";
    a <= x"00000001";
    wd <= x"ffffffff";
    wait for 100ms;
    finished <= '1';
    --Test 1
   end process;

END;

[Chris (Gast)]

komisch, state_next macht genau das was ich haben will???

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

Chris schrieb:
> komisch, state_next macht genau das was ich haben will???
Herzlichen Glühstrumpf, du hast das entdeckt, was man "synchrones 
Design" nennt: nach der Taktflanke herrscht Hektik im FPGA, bis alle 
signale durch die Kombinatorik gelaufen sind. Und rechtzeitig vor dem 
nächsten Takt muss alles ruhig sein, damit die Flipflops korrekte Daten 
übernehmen können.

Ich empfehle dir, dass du mal das buch "VHDL Synthese" von 
Reichardt&Schwarz genauer anschaust...

[Chris (Gast)]

Hallo,
stimmt schon hab mir das heute morgen nochmal angeguckt und eigentlich 
ziemlich logisch, dass das so nicht klappen kann. habe jetzt eine 
asynchrone version implementiert, wobei ich mir jetzt unsicher bin ob 
man sowas macht. in unserem praktikum wurden wir geimpft bloß alles 
immer synchron zu implementieren, alles andere sei böse :(
vielleicht könnt ihr mir ja eine beurteilung zu meinem jetztigen entwurf 
geben.
Aufgabenstellung: (handelt sich um enen mips proc mit wishbone 
anbindung)
ich soll einen master für einen wishbone slave programmieren, wie man 
vielleicht aus den signalen erkennen kann.
Lösung:
dafür habe ich jetzt ein data_memory als art top-level erstellt das die 
signale: clk,rst,cmd,wd,a von der pipeline erhält und als ausgabe rd und 
busy ausgibt.
intern werden dann diese signale an den wishbone-master weitergegeben, 
was ich jetzt asynchron programmiert habe.
Sollte man sowas so lösen? oder ist das garnicht gut? das asynchrone 
macht mich etwas verrückt

siehe meine beiden files unten

-- data_memory.vhd

library ieee;
use ieee.std_logic_1164.all;

entity data_memory is
  Port(
    clk  : in std_logic;
    rst  : in std_logic;
    cmd  : in std_logic_vector(1 downto 0);
    wd   : in std_logic_vector(31 downto 0);
    a    : in std_logic_vector(31 downto 0);
    
    rd   : out std_logic_vector(31 downto 0);
    busy : out std_logic
  );
end data_memory;

architecture Behavioral of data_memory is

  -- Wishbone buffers
  signal dat_i_con : std_logic_vector(31 downto 0);
  signal ack_i_con : std_logic;
  signal adr_o_con : std_logic_vector(10 downto 0);
  signal dat_o_con : std_logic_vector(31 downto 0);
  signal we_o_con  : std_logic;
  signal stb_o_con : std_logic;
  signal cyc_o_con : std_logic;

  -- Bootram buffers
  signal ram_ce_con : std_logic;
  signal ram_we_con : std_logic_vector(3 downto 0);
  signal ram_a_con  : std_logic_vector(12 downto 2);
  signal ram_d_con  : std_logic_vector(31 downto 0);
  signal ram_q_con  : std_logic_vector(31 downto 0);

begin

  WishboneMaster: entity work.wishbone_master
  port map(
  
    -- Top level signals
    clk  => clk,
    rst  => rst,
    cmd  => cmd,
    wd   => wd,
    a    => a,
    rd   => rd,
    busy => busy,
    
    -- Wishbone signals
    dat_i => dat_i_con,
    ack_i => ack_i_con,
    adr_o => adr_o_con,
    dat_o => dat_o_con,
    we_o  => we_o_con,
    stb_o => stb_o_con,
    cyc_o => cyc_o_con
    
  );
  
  WishboneSlave: entity work.bootram_wb
  generic map (
    A_BITS      => 13,
    BA_BITS     => 2,
    D_BITS      => 32,
    PIPE_STAGES => 1
  )
  port map(
    
    -- Generic signals
    clk => clk,
    rst => rst,
    
    -- Wishbone signals
    wb_dat_o => dat_i_con,
    wb_ack_o => ack_i_con,
    wb_adr_i => adr_o_con,
    wb_dat_i => dat_o_con,
    wb_we_i  => we_o_con,
    wb_sel_i => "1111", --sel_o_con,
    wb_stb_i => stb_o_con,
    wb_cyc_i => cyc_o_con,
    wb_cti_i => "000",
    wb_bte_i => "00",
    
    -- Bootram signals
    ram_ce => ram_ce_con,
    ram_we => ram_we_con,
    ram_a  => ram_a_con,
    ram_d  => ram_d_con,
    ram_q  => ram_q_con
    
  );
  
  BootRam: entity work.bootram_mips
  port map(
  
    -- Generic signals
    clk => clk,
    
    -- Bootram signals
    ce1 => ram_ce_con,
    we1 => ram_we_con,
    a1  => ram_a_con,
    d1  => ram_d_con,
    q1  => ram_q_con,
    ce2 => '0',
    a2  => b"00000000000",
    q2  => x"00000000"
  
  );
  
end Behavioral;

-- wishbone_master.vhd

library ieee;
use ieee.std_logic_1164.all;

entity wishbone_master is

  Port(
    -- Memory interface
    clk : in  std_logic;
    rst : in  std_logic;
    cmd : in  std_logic_vector(1 downto 0);
    wd  : in  std_logic_vector(31 downto 0);
    a   : in  std_logic_vector(31 downto 0);
    rd  : out std_logic_vector(31 downto 0);
    
    -- Wishbone interface
    dat_i : in  std_logic_vector(31 downto 0);
    ack_i : in  std_logic;
    adr_o : out std_logic_vector(12 downto 2);
    dat_o : out std_logic_vector(31 downto 0);
    we_o  : out std_logic;
    stb_o : out std_logic;
    cyc_o : out std_logic;
    busy  : out std_logic
  );
  
end wishbone_master;

architecture Behavioral of wishbone_master is
  
  type state_type is (IDLE, WORK);
  signal state     : state_type;
  signal tmp_dat_o : std_logic_vector(31 downto 0);
  signal tmp_adr_o : std_logic_vector(10 downto 0);
  signal tmp_dat_i : std_logic_vector(31 downto 0);
  signal tmp_we_o  : std_logic;
  
begin
  
  dat_o <= tmp_dat_o;
  adr_o <= tmp_adr_o;
  rd    <= tmp_dat_i;
  we_o  <= tmp_we_o;
  
  process(cmd,ack_i,rst,a)
  begin
    
    -- Initializations
    busy       <= '0';
    stb_o      <= '0';
    
    if rst = '1' then
      state <= IDLE;
    else
      case state is
        when IDLE =>
          
          if cmd(0) = '1' then -- 0|1 = read, 1|1 = write
            state     <= WORK;
            busy      <= '1';
            stb_o     <= '1';
            cyc_o     <= '1';
            tmp_we_o  <= cmd(1);
            tmp_dat_o <= wd;
            tmp_adr_o <= a(10 downto 0);
            tmp_dat_i <= dat_i;
          else 
            state     <= IDLE;
          end if;
        
        when WORK =>
          
          if ack_i = '1' then
            state <= IDLE;
            busy  <= '0';
            stb_o <= '0';
            cyc_o <= '0';
          else
            state     <= WORK;
            busy      <= '1';
            stb_o     <= '1';
            cyc_o     <= '1';
          end if;
        
      end case;
    end if;
  end process;
  
end Behavioral;

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

Chris schrieb:

  process(cmd,ack_i,rst,a)
    begin
          :
             tmp_dat_o <= wd;
             :
             tmp_dat_i <= dat_i;
  end process;

Ich meine, ich hätte dazu schon mal was geschrieben...

Das hier ghet natürlich nicht, denn das wäre eine komplett asynchrone 
Statemachine. Sowas ist im echten Leben nicht beherrschbar:

  process(cmd,ack_i,rst,a)
  begin
    :    
    if rst = '1' then
      state <= IDLE;
    else
      case state is
         when IDLE =>
          :
            state     <= WORK;

Mein Tipp immer noch: besorg dir das angesprochene Buch.

[Chris (Gast)]

Sooooo, hab das Buch noch ergattern können, zwar nur ne Version von 2000 
aber ich denke seitdem sollte sich bei so grundlegenden Sachen wohl 
nichts getan haben. Hab auch noch paar Quellcodes im Inet durchforstet 
und komme jetzt auf folgende Lösung für einen Wishbone-Master in VHDL:
Wir sollten über einen Bootram testen und wenn ich mich nicht ganz irre 
scheint alles in der Simulation zupassen :) Hoffentlich klappt dann auch 
die Synthese
Vielen Dank Lothar, irgendwie stand ich gestern Nacht, heute morgen aufm 
Schlauch :D
Was meintest du mit den tmp_* Signalen? Hab das jetzt auch ausgebessert 
soweit wie ich konnte. Sieht das vernünftig aus?

-- wishbone_master.vhd

library ieee;
use ieee.std_logic_1164.all;

entity wishbone_master is

  Port(
    -- Memory interface
    clk : in  std_logic;
    rst : in  std_logic;
    cmd : in  std_logic;
    wd  : in  std_logic_vector(31 downto 0);
    a   : in  std_logic_vector(31 downto 0);
    rd  : out std_logic_vector(31 downto 0);
    
    -- Wishbone interface
    dat_i : in  std_logic_vector(31 downto 0);
    ack_i : in  std_logic;
    adr_o : out std_logic_vector(12 downto 2);
    dat_o : out std_logic_vector(31 downto 0);
    we_o  : out std_logic;
    stb_o : out std_logic;
    cyc_o : out std_logic;
    done  : out std_logic
  );
  
end wishbone_master;

architecture Behavioral of wishbone_master is
  
  type state_type is (S_IDLE, S_READ, S_WRITE, S_FINITE);
  signal state,next_state  : state_type;

begin
  adr_o <= a(10 downto 0);
  dat_o <= wd;
  rd <= dat_i;
  process(clk)
  begin
    if rising_edge(clk) then
      if (rst = '1') then
        state <= S_IDLE;
      else
        state <= next_state;
      end if;
    end if;
  end process;
  
  process(state)
  begin
   cyc_o <= '0';
   stb_o <= '0';
   we_o  <= '0';   
   done  <= '0';
   case (state) is
      when S_IDLE =>
         cyc_o  <= '0';
         stb_o  <= '0';
         we_o  <= '0';
      when S_READ  =>
         cyc_o  <= '1';
         stb_o  <= '1';
         we_o  <= '0';
      when S_WRITE  =>
         cyc_o  <= '1';
         stb_o  <= '1';
         we_o  <= '1';
      when S_FINITE =>
         done <= '1';
      when others =>
         null;
   end case;
  end process;
  
  process (state,cmd,ack_i)
  begin
    next_state <= state;
    case state is
      when S_IDLE =>
        if cmd = '0' then
          next_state  <= S_READ;
        else
          next_state  <= S_WRITE;
        end if;
        
      when S_READ =>
        if (ack_i = '1') then
          next_state <= S_FINITE;
        end if;
        
      when S_WRITE =>
        if (ack_i = '1') then
          next_state <= S_FINITE;
        end if;
      
      when S_FINITE =>
        next_state <= S_IDLE;
      
      when others =>
        next_state <= S_FINITE;
    end case;
    
  end process;
end Behavioral;

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

Chris schrieb:
> Was meintest du mit den tmp_* Signalen?
Ich meinte, dass sie in der Sensitivliste des kombinatorischen Prozesses 
fehlten und deshalb die Simulation nicht zur Realität gepasst hätte...

> Wir sollten über einen Bootram testen und wenn ich mich nicht ganz irre
> scheint alles in der Simulation zupassen :)
Bei der letzten Version sieht das gut aus, die Sensitivlisten passen.

> Hoffentlich klappt dann auch die Synthese
Viel Erfolg... ;-)

[pks (Gast)]

Warum ist nur die Zwei-Prozess-Schreibweise bei FSMs so beliebt :-(

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

pks schrieb:
> Warum ist nur die Zwei-Prozess-Schreibweise bei FSMs so beliebt :-(
Sie ist nicht unbedingt beliebt, aber sie wird gelehrt...

Ich verweise auf die immer wieder auftauchenden Diskussionen hier im 
Forum wie z.B. im Beitrag "FSM möglichst einfach und übersichtlich" und die 
Zusammenfassung auf 
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

[Chris (Gast)]

Hi,
ich muss zugeben, dass in zwei prozesse aufzuteilen hab ich gesehen und 
fand dies sehr zugänglich. gelehrt wurde uns das so aber nicht muss ich 
sagen. wobei was wird schon gelehrt, hier fpga+board, vhdl kann man hier 
nachlesen macht doch mal...