Alternative way to implement state machines in VHDL - vhdl

Question

I have seen many state machines implemented like this one from Altera:
ARCHITECTURE a OF state_machine IS
TYPE STATE_TYPE IS (s0, s1, s2);
SIGNAL state : STATE_TYPE;
BEGIN
PROCESS (clk, reset)
BEGIN
IF reset = '1' THEN
state <= s0;
ELSIF (clk'EVENT AND clk = '1') THEN
CASE state IS
WHEN ...
An alterantive to that would be this:
ARCHITECTURE a OF state_machine IS
TYPE STATE_TYPE IS (s0, s1, s2);
BEGIN
PROCESS (clk, reset)
VARIABLE state : STATE_TYPE := s0;
BEGIN
IF reset = '1' THEN
state <= s0;
ELSIF (clk'EVENT AND clk = '1') THEN
CASE state IS
WHEN ...
What are the pros (if any) and cons of doing it the alternative way? I have only seen the alternative in one place and I'm guessing there must be some good reason for that.

Answer 1

I like to keep local things local, so if the state information is needed only within the process, I use a variable. In that case, I also like to declare the state type inside the process:
ARCHITECTURE a OF state_machine IS
BEGIN
PROCESS (clk, reset)
TYPE STATE_TYPE IS (s0, s1, s2);
VARIABLE state : STATE_TYPE := s0;
BEGIN
...
In the rare cases where I need to access the state of an FSM from another process (e.g. interactive state machines), I'll use a signal for storing the state.
The signal vs. variable decision if often a matter of taste. Some developers think that variables are evil and will never use them. Others (like me) use them whenever they can to keep local things local. As a bonus, since variables are more lightweight objects than signals, they also simulate faster.

Answer 2

Using a variable to hold state would mean you couldn't look at state with a waveform viewer.
There might be some synchronization issues with signal inputs used for branching, delta cycle mismatch in zero time models.
Any state machine outputs derived from state would require signals in any event - every concurrent statement has a process equivalent, a VHDL simulator executes processes, processes communicate via signals.
The only pluses that come to mind is that it would be a more compact model (code size) and execute a bit faster.

Answer 3

I often use a variable called state. It keeps the definition hidden, private to just the process that is using it. If you have 2 communicating state machines in one process, they can both have a variable called state local to themselves. Sometimes that works well. Other times it's confusing!
As with many code-style issues, you have to decide on the most readable way to do things. There's no functional reason not to use variables (of any sort, not just state variables).
One other thing you can do with a variable is read the intended next state at the end of the process, which can be useful when you need to reduce latency of outputs. Again, care is needed as you can create long chains of logic inadvertently which can slow the design down.

Answer 4

Variables are great if you are determining a partial sum or intermediate product that is to be used further down in your process in the same clock cycle. However if a variable is not driven every clock cycle then a latch will be inferred. Since you will want the state to be 'remembered' for the next clock cycle then you will get a latch if you use a variable without an assistant register signal. To clarify...
signal state_sig : state_type;
begin
process(clk, rst)
variable state : state_type := s0;
begin
if rst = '1' then
state_sig <= s0;
elsif rising_edge(clk) then
state := state_sig
case state is
when s0 =>
if blah = '0' then
state := s1;
end if;
....
....
end case;
if state = s1 then state := s2; end if;
state_sig <= state;
end if;
end process;
In the above example you are able to avoid going in the state s1 by modifying the state variable before it gets registered. A quick and dirty way of changing the state machine behaviour. However the state_sig signal must be used to 'remember' the state to avoid latch inferral.