FSM in VHDL

[Bigyellow]

Hi

which one is correct
1)
if reset = '0' then
..
elsif clk'event and clk = '1' then
current_state <= next_state;
case current_state
when ....
when ....
end case
end if;

or
2)
if reset = '0' then
..
elsif clk'event and clk = '1' then
current_state <= next_state;
case next_state
when ....
when ....
end case
end if;

The fisrt looks reseanable. but I am afraid that when the current_state
is a signal, I can not read the current_state immediately in the case
statement, when the current_state is changed. is it right?

 

Bigyellow wrote:

Hi

which one is correct
1)
if reset = '0' then
..
elsif clk'event and clk = '1' then
current_state <= next_state;
case current_state
when ....
when ....
end case
end if;

or
2)
if reset = '0' then
..
elsif clk'event and clk = '1' then
current_state <= next_state;
case next_state
when ....
when ....
end case
end if;

The fisrt looks reseanable. but I am afraid that when the
current_state
is a signal, I can not read the current_state immediately in the case
statement, when the current_state is changed. is it right?

The first is correct. In a state machine decisions are based on the
current state and the state of signals in the current state; this
includes the decision on which state is to be the next state. When you
are in state A the signal A is asserted and and you can read it
immediately. Think about it, if you are in state A you may exit to
state B or state F depending on conditions in state A so "case
next_state" isn't helpful.

 

[Neo]

The first is correct though the second is not wrong but if followed is
sure to get you sacked. state machines outputs depend on the current
state or current state with inputs.
since you are putting the output logic also inside the clock statement
your ouputs will be available after a clock delay. That is not required
and you can seperate the case statement into a seperate process
sensitive only to the current state then you can have the outputs in
the same clock the state changes.

 

[Bigyellow]

Thanks for all replies.

Yes, I have tried to sperated the output into another process, and in
that process, I case current_state

The reason why I put the output logic under the clock process is I have
a lot of outputs, and sometimes a output needs keep the value which is
assigned in previous state, so a latch is generated.

So I think is I use current_state as variable, I can read it
immediately in the clock process,
and if the current_state is a signal, after I assign it, I only can
read it in the next clock cycle, is it right?

 

I have designed many state machines and have never used a variable for
current_state or next_state. A state machine is a synchronous process
and this means that if the present state is A and the next state is B
you cannot read B until the next clock transition after you assign it.
I don't why that should be a problem. Why would you want to read a
state value before you get to that state? In a given state you assign
values to signals and exit to the next state either automatically on
the next clock transition or on the clock transition after a certain
signal value is asserted or unasserted. You need be concerned with the
events in the next state only when the state machine is in that state.
Actually, you can assign a signal value as you leave the present state
so that it will have that value in the next state. In no case I can
think of are you required to "read" the next state's value until the
state machine is in that state which, of course, makes it the present
state.

Charles