FSM springt nicht in nächsten Status

[Richard B. (rbrose)]

Hallo,

ich habe folgendes Problem:

Ich habe eine FSM die nicht in den nächsten Status springt:

state_switcher : process (CLK)
begin
  if rising_edge(CLK) then
    if Reset = '1' then
      State <= Power_Up;
    else
      State <= Next_State;
    end if;
  end if;
end process state_switcher;

stateMachine : process (State)
begin

  case (State) is
    when Power_Up =>
      Next_State <= Power_Up_Delay;
      
    when Power_Up_Delay =>
      if (Delay_45ms = "1000100101010100010000") then
        Next_State <= Off_Power_Up_Delay;
      else
        Next_State <= Power_Up_Delay;
      end if;
      
    when Off_Power_Up_Delay =>
      Next_State <= Write_Data;

Er bleibt immer im Power_Up_Delay Status.

Das ist hier der Delay Process:

---------------------------------------------------------------------------------------------
-- Power Up Delay.
---------------------------------------------------------------------------------------------
-- Power Up Delay Switch.
process (State)
begin
   if ((State = Power_Up) or (State = Power_Up_Delay)) then
    Delay_45ms_E <= '1';
   else
    Delay_45ms_E <= '0';
   end if;
end process;

-- 45ms Delay Element.
process (Clk)
begin  
   if (Clk'event and Clk = '1') then
      if Reset = '1' then
      Delay_45ms <= "0000000000000000000000";
      else
      if (Delay_45ms_E = '1') then
        Delay_45ms <= Delay_45ms + 1;
      end if;
      end if;
   end if;
end process;

Was ist das Problem? Anbei ein Auszug auf dem ModelSim.

Danke.

[Xenu (Gast)]

Du hast vergessen das Signal "Delay_45ms" mit in die Sensitivitätsliste 
des Prozesses aufzunehmen.

Ach ja, "state" heisst "Zustand" und nicht "Status" (state machine = 
Zustandsautomat).

[lkmiller (Gast)]

>Ich habe eine FSM die nicht in den nächsten Status springt
Die SM wird in der Realität schon weiterspringen.

Du müsstest eigentlich schreiben:
Ich habe eine FSM die in der Simulation nicht in den nächsten Status 
springt

[Eman (Gast)]

Ich hab das jetzt hier schon dreimal gesehen, dass die State-Machine in 
einen taktgesteuerten und taktlosen Teil getrennt ist.
Hat das irgendwelche Vorteile gegenüber der "normalen" Lösung mit halt 
einer taktgesteuerten Machine?

[lkmiller (Gast)]

Ja:
Weil das ziemlich schnell keiner mehr kapiert
kann man sein geistiges Eigentum besser vor Diebstahl schützen.

Es ist wohl eher so, wie man das gelernt hat.
Ich habe alle Schreibweisen ausprobiert (3, 2, 1-Prozess) und bin bei 
der 1-Prozess-SM geblieeben, weil man keine Signale in der SensList 
vergessen kann.

Kombinatorik schreibe ich dann gerne concurrent, also statt

-- Power Up Delay Switch.
process (State)
begin
   if ((State = Power_Up) or (State = Power_Up_Delay)) then
    Delay_45ms_E <= '1';
   else
    Delay_45ms_E <= '0';
   end if;
end process;

kürzer:

-- Power Up Delay Switch.
Delay_45ms_E <= '1' when ((State=Power_Up) or (State=Power_Up_Delay)) else '0';

[lkmiller (Gast)]

Das wäre in etwa die Kurzschreibweise in 1 Prozess:

:
signal Delay_45ms : integer;
:
:
state_switcher : process (CLK)
begin
  if rising_edge(CLK) then
    if Reset = '1' then -- das ist ja wohl auch der Power-Up-Zustand?
      State <= Power_Up_Delay;
      Delay_45ms <= 0;
    else
      case (State) is
      when Power_Up_Delay =>
        Delay_45ms <= Delay_45ms + 1;
        if (Delay_45ms = 2250000) then -- offenbar ein 50MHz-Takt?
          State <= Off_Power_Up_Delay;
        end if;

      when Off_Power_Up_Delay =>
        State <= Write_Data;
:
:

Wäre doch viel zu einfach zu kopieren/kapieren?

[Morin (Gast)]

> Ich hab das jetzt hier schon dreimal gesehen, dass die State-Machine in
> einen taktgesteuerten und taktlosen Teil getrennt ist.
> Hat das irgendwelche Vorteile gegenüber der "normalen" Lösung mit halt
> einer taktgesteuerten Machine?

Wird oft noch so gelehrt, von Lehrern/Profs/was auch immer, die noch aus 
einer Zeit kommen, in der man eine FSM von Hand implementieren musste 
(und das geht mit der Trennung sehr viel einfacher).

[lkmiller (Gast)]

Wenn jemand von der Viel-Prozess-Schreibweise zur Ein-Prozess-Methode 
wechselt kann der sich da schnell mal 1 Takt Latency einhandeln (weil ja 
der Zustand der Signale erst mit dem nächsten Takt geändert wird).
Aber das ist nur ein kurzer Lernprozess, danach wird alles viel 
einfacher.

Es gibt z.B. keine mehrfachen Zuweisungen an Signale, alle 
Abhängigkeiten stehen im selben Prozess, und der ist zur größten Freude 
auch noch getaktet.....

[Richard B. (rbrose)]

Ahh stimmt hab die Sensitivitätsliste vergessen.

Ok. Nächste Frage: Wieso habe ich in ModelSim bei 45000000 ns = 45 ms 
nur 1125000 als Wert bei delay_45ms? Wie rechne ich da richtig?

Muss ich 45000000 * 20 = 900000000 nehmen weil mein CPU Clock mit 20ns 
Verzögerung kommt?

clock : PROCESS
   begin
   wait for 20 ns; CLK  <= not CLK;
end PROCESS clock;

Wie ist die Verzögerung im realen System? Bei einem Spartan 3E XC3S500E 
/ FG320 und Speed auf -4 ?

20 ns? Oder gilt der Wert nur für I/O Toggle?

[Roger S. (edge)]

Richard B. wrote:
> Ok. Nächste Frage: Wieso habe ich in ModelSim bei 45000000 ns = 45 ms
> nur 1125000 als Wert bei delay_45ms? Wie rechne ich da richtig?
>
> Muss ich 45000000 * 20 = 900000000 nehmen weil mein CPU Clock mit 20ns
> Verzögerung kommt?

Ist das ein Scherz? Du teilst deine Wartezeit durch die Periodendauer 
deines CPU clocks. ModelSim gibt dir ja schon die korrekte Antwort.
Dein Clock hat im uebrigen keine 20ns Verzoegerung, sondern eine halbe 
Periodendauer von 20ns.

Cheers, Roger

[lkmiller (Gast)]

Also (concurrent, ohne process)

CLK  <= not CLK after 10ns; -- gibt 50MHz-Takt: 10ns low, 10ns high

[Richard B. (rbrose)]

Also stimmt das, dass der Spartan 3E 900000000 Takte machen muss um 45 
ms zu kriegen?

Ist das schon vorgeben das der Spartan 3E eine Periodendauer von 20ns 
hat? Oder muss man die Konfigurieren?

Danke!

[lkmiller (Gast)]

>Also stimmt das, dass der Spartan 3E 900000000 Takte machen muss
>um 45ms zu kriegen?
Das wäre richtig bei einer Taktfrequenz von 20GHz.

Du schreibst doch selber ...if(Delay_45ms = 2250000)...
Das heisst, du wartest 2250000 Takte für 45ms, das sind dann 50MHz.

Datenblatt. Von Xilinx.

Da gibt es Takteingänge, der Spartan 3 kann ohne externen Takt gar nix.
(OK, OK, er kann Kombinatorik).

BTW:
Lattice MachXO können den eingebauten Oszillator, der zum Laden des 
FPGAs verwendet wird, auch für User-Zwecke verwenden.

[Richard B. (rbrose)]

@lkmiller

Beim state_switcher : process (CLK) brauch ich dann nicht mehr die 
Sensitivitätsliste erweitern? Weil der process getaktet wird?

[lkmiller (Gast)]

Richtig, nur CLK in die Liste.

Die sensitivity-list eines process ist nur für die Simulation 
interessant. Wenn sich der Zustand eines der Signale in der Liste 
ändert, wird die Simulation neu berechnet.
Die Synthese legt mit einer unvollständigen Liste ein paar Warnungen 
vor, macht aber sonst alles richtig (fügt die Signale selbständig ein).

Und in dem von mir beschriebenen getakteten Prozess kann sich nur was 
ändern, wenn sich CLK ändert. Und dann wird alles neu berechnet.
Bei der fallenden Flanke ist die Berechnung dann auch gleich fertig, da 
gibts nix zu tun. Bei der steigenden Flanke gehts dafür aber richtig zur 
Sache.