Help with state mahine resets

[Mike Treseler]

I get inconsistent simulation results

Maybe your reset and trigger pulses are
too close or overlapping.

-- Mike Treseler

 

[Tom Neal]

I get inconsistent simulation results using modelsim 3 XE when I
simulate the reseting of this simple state machine example at various
levels of simulation.

When I simulate at the behavior level, the state changes from S1 to S0
on the rising edge of the reset pulse.

When I simulate at the post translation level, the state changes from
S0 to S1 on the falling edge of the reset pulse.

When I simulate at the post map and post place & route level, the
state is at S1 before and after the reset puulse.

I am confused. Any help appreciated.

Tom

-------------------------------------------------------------------------------------------------------------

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

entity test is
port (
Sysclk: in std_logic;
Reset: in std_logic;
Trigger: in std_logic;

state0 : out std_logic;
state1 : out std_logic;
state2 : out std_logic
);
end test;

architecture Behavioral of test is
type statetype is (S1,S0,S2);
signal state : statetype;
begin

process(sysclk,reset)
begin
if (Reset='1') then
state<=s0;
elsif (rising_edge(sysclk)) then

case state is
when s0 =>
if (trigger='1') then
state<=S1;
end if;
when S1 =>
state<=s2;
when S2 =>
state<=S0;
end case;

end if;
end process;

state0<='1' when (state=S0) else '0';
state1<='1' when (state=S1) else '0';
state2<='1' when (state=S2) else '0';


end Behavioral;

 

[Tom Neal]

As a follow-up to this message. This is simple example of something
that I saw in a larger design. To illustrate the problem, I only
pulsed thr reset signal for 50 ns. Both trigger and sysclk were kept
at a '0'.

As I understand it, the power-up state of the state machine should be
S1 from the order given in the type statement.

type statetype is (S1, S0, S2).

and the reset state should be S0 from

if (reset='1') then
state<=S0;

In the later simulations, the state never goes to S0 after the reset
pulse.

BTW I am using Modelsim 3 XE 6.0a

Tom

 

[Neo]

synthesis dosent support intial values. so you have to activate reset
to get the fsm to a initial state. assertng reset should make the state
go to S0.

 

[Tom Neal]

After reset pulse in behavorial and post translate simulations, the
state is S0. After reset pulse in post-map and post-place simulation,
the state remains at S1.

Apparently the ordering of the terms in the typse statement implies an
initial value for signals of the type.

But still don't really understand the behavior of the post-map and
post- simulations.

Tom

 

[Mike Treseler]

As a follow-up to this message. This is simple example of something
that I saw in a larger design. To illustrate the problem, I only
pulsed thr reset signal for 50 ns.

Some fpgas have their own power-up resets.
You might have to wait a while to apply
the external reset on a timing sim.

-- Mike Treseler

 

[Weng Tianxiang]

Try this way:
Move the following two statements out of process.

type statetype is (S1,S0,S2);
signal state : statetype;

It should be meaningful in global scope, not in local process scope.

If state is within a process, its values are fotgotten after one rising
edge. Next time, its starting value is random data, it would destroy
your data of state machine.

Weng

 

[Mike Treseler]

Move the following two statements out of process.

type statetype is (S1,S0,S2);
signal state : statetype;

The OP already has these in architecture scope.
He also stated that the functional sim works fine.
If there is a problem, it's not scope.

-- Mike Treseler

 

[Weng Tianxiang]

Sorry for mistake pointed by Mike.

'When I simulate at the behavior level, the state changes from S1 to S0

on the rising edge of the reset pulse. '

It is not a problem. You may change reset signal rising edge time and
falling edge time, you will get different values based on different
values. Because reset is an asynchonous signal that has no time
relations with your clock.

Make sure two things during simulations:
1. Your reset is active-high signal. Usually it is an active-low
signal.

2. From time 0, your reset must be '1', then '0'. If you skip some
times, state machines is running away and when reset is going high, it
reset state machine to S0. So it is very normal.

The error is to change reset from active-high to active-low:
If(reset = '1') then
....

changed to
If(reset = '0') then
....

And then you will get the same simulation results for two runs.

When