FINITE STATE MACHINES

• State Processes
• State Coding
• FSM Types
• Medvedev
• Moore
• Mealy
• Registered Output
• The standard versions known in theory
are Medvedev, Moore and Mealy
machines. However, there are far more
versions than these three. It is for example
recommended for several reasons to
place storing elements (registers, Flip
Flops) at the module outputs. By doing
this, additional versions of finite state
machines can be built
One "State" Process
• FSM_FF: process (CLK, RESET)
• begin
• if RESET='1' then
• STATE <= START ;
• elsif CLK'event and CLK='1' then
• case STATE is
• when START => if X=GO_MID then
• STATE <= MIDDLE ;
• end if ;
• when MIDDLE => if X=GO_STOP then
• STATE <= STOP ;
• end if ;
• when STOP => if X=GO_START then
• STATE <= START ;
• end if ;
• when others => STATE <= START ;
• end case ;
• end if ;
• end process FSM_FF ;
•
Two "State" Processes
FSM_FF: process (CLK, RESET) begin
• if RESET='1' then
• STATE <= START ;
• elsif CLK'event and CLK='1' then
• STATE <= NEXT_STATE ;
• end if;
• end process FSM_FF ;

• FSM_LOGIC: process ( STATE , X)

• begin
• NEXT_STATE <= STATE ;
• case STATE is
• when START => if X=GO_MID then
• NEXT_STATE <= MIDDLE ;
• end if ;
• when MIDDLE => ...
• when others => NEXT_STATE <= START ;
• end case ;
• end process FSM_LOGIC ;
• The signal NEXT_STATE is examined explicitly this
time. It is inserted in the block diagram between the logic
and the storing elements. In the bubble diagram no
changes have to be made at this point, as the behaviour
remains the same.

• The VHDL source code contains two processes. The

logic for the NEXT_STATE calculation is described in a
separate process. The result is a clocked process
describing the storing elements and another purely
combinational process describing the logic. In the CASE
statement, again, the current state is checked and the
input values are examined. If the state has to change,
then NEXT_STATE and STATE will differ. With the next
occurence of the active clock edge, this new state will be
taken over as the current state.
• Structure and Readability
• Asynchronous combinatoric ≠ synchronous storing
elements
=> 2 processes
• FSM states change with special input changes
=> 1 process more comprehensible
• Graphical FSM (without output equations) resembles
one state process
=> 1 process
• Simulation
Error detection easier with two state processes
=> 2 processes
• Synthesis
2 state processes can lead to smaller generic net list
and therefore to better synthesis results
=> 2 processes
 State Encoding
State encoding responsible
for safety of FSM
• A finite state machine is an abstract description of digital
hardware. It is a synthesis requirement that the states of
the automaton are described as binary values or the
synthesis tool itself will transform the state names into a
binary description on his own. This transformation is
called state encoding.

• Most synthesis tools select a binary code by default,

except the designer specifies another code explicitly.

• type STATE_TYPE is ( START, MIDDLE, STOP ) ;

signal STATE : STATE_TYPE ;
 Default encoding: binary

• START -> " 00 "

• MIDDLE -> " 01 "
• STOP -> " 10 "
 Speed optimized default
encoding: one hot
• START -> " 001 "
• MIDDLE -> " 010 "
• STOP -> " 100 “
• A frequently used code which is needed for
speed optimized circuits is the "one-out-of-n"
code which is also called one hot code. Here,
one bit is used for every state of the automaton.
E.g. if the automat has 11 states, then the state
vector contains 11 bits. The bit of the vector
which is set to '1' represents the current state of
the automaton.
 Problem-Invalid States
• As the automat consists only of 3 states and two
FFs can represent up to 4 states ("00", "01",
"10", "11"), there is one invalid state which leads
to an unsafe state machine, i.e. the behaviour of
the design when accidentally entering this state
is not determined.

• Ususally, a mechanism has to be provided which

corrects the erronous entering of an invalid
state.
 Extension of Case Statement
type STATE_TYPE is (START, MIDDLE, STOP) ;
signal STATE : STATE_TYPE ;
···
case STATE is
when START => · · ·
when MIDDLE => · · ·
when STOP => · · ·

when others => · · ·

end case ;
• The most obvious method to intercept invalid states is to
insert a 'when others' branch in the CASE statement.
With this branch, all values of the examined expression
(here: STATE) that are not included in the other
branches of the CASE statement are covered. The
intention is to intercept all illegal states and to restart the
automaton with its reset state (here: START).

• VHDL is a very strict language. Therefore, during

simulation, only the values defined by the type definition
of a signal can be accessed. For this reason, invalid
states do not exist in the simulation and consequently
can not be simulated. Furthermore the synthetisized
circuit is also not necessarily safe. Some synthesis tools
ignore the 'when others' branch as, by definition, there
are no values to cover in this branch.

• Inserting a 'when others' branch into the case statement

is not a good solution for creating a safe state machine.
 Adding Dummy states
• type STATE_TYPE is (START, MIDDLE, STOP,
DUMMY) ;
• signal STATE : STATE_TYPE ;
• ···
• case STATE is
• when START => ···
• when MIDDLE => ···
• when STOP => ···

• when DUMMY => ··· -- or when others

• end case ;
• The second way is to define additional
values for the enumeration type. So many
values have to be added that after state
encoding invalid values can no longer
occur. If an automaton contains for
example 20 states, 5 Flip Flops are
needed with a binary code. With 5 FFs
one can distinguish 32 values (2^5=32).
Thus, 12 additional values have to be
added to the enumeration type of the state
machine.
• By adding additional values to the enumeration
type, one gets a state machine whose behaviour
in case of errors can now be simulated.
• The synthesis also results in a safe circuit
representing the original state machine.
However this method is somewhat awkward as
one has to insert many so called dummy states
eventually.
• Furthermore, this method is only suitable when
binary coding for the states of the automaton is
used. If one has added for example these 12
additional values for a safe state machine, he
will get 12 redundant Flip Flop when he switches
the state encoding to the one hot code as an
extra bit is needed for every state.
• It is impossible to make a state machine safe by
inserting additional values for dummy states if a
one hot code is used. Every new value would
lead to an additional FF and therefore would
only increase the amount of invalid state values
after synthesis.

• Therefore the method of inserting additional

values into the enumeration type is not a good
solution, too, as it is applicable to binary state
encoding, only.
 Hand Coding
• subtype STATE_TYPE is std_ulogic_vector (1 downto 0) ;
• signal STATE : STATE_TYPE ;

• constant START : STATE_TYPE := "01";

• constant MIDDLE : STATE_TYPE := "11";
• constant STOP : STATE_TYPE := "00";
• ···
• case STATE is
• when START => ···
• when MIDDLE => ···
• when STOP => ···
• when others => ···
• end case ;
• The best method of state encoding is hand
coding, i.e. the designer decides by himself
which code will be used.

• This is done by using a vector type instead of an

enumeration type. This vector type can based
upon the 'std_(u)logic_vector' type for exmple.
The width of this vector depends on the code
chosen. The state signal is now of this vector
type, which is the reason for the term "state
vector".
• In the next step, constants are defined which represent
the corresponding states of the automaton. These
constants are set to the state vector values according to
the selected code. With these constants, the code can
be fixed by the designer and can not be altered by the
synthesis tool. This VHDL model is also 100 percent
portable. The behaviour in case of errors can be verified
in a simulation as the state vector can assume all values
that might occur in real hardware, now.

• The only drawback to mention is a little more effort in

writing the VHDL code. This is especially true when the
code is changed. The hand coding alternative is the best
method to design a safe finite state machine and is
furthermore portable among different synthesis tools.
FSM: Medvedev
• The output vector resembles the state vector: Y=S

• The difference between the three types of state

machines known in theory (Medevedev, Moore and
Mealy machines) is the way the output is generated.

• In the Medvedev machine the value of the output is

identical with the state vector of the finite state
machine.
• That means, the logic for the output consists only out of
wires; namely the connection from the state vector
registers to the output ports. This is done in VHDL by a
simple signal assignment which is shown in the example
above. Concurrent assignments are used here.
One Process

architecture RTL of MEDVEDEV is

...
begin

REG: process (CLK, RESET)

begin
-- State Registers Inference with Logic Block
end process REG ;

Y <= S ;

end RTL ;
 Two Processes
• architecture RTL of MEDVEDEV is
• ...
• begin
• REG: process (CLK, RESET)
• begin
• -- State Registers Inference
• end process REG ;

• CMB: process (X, STATE)

• begin
• -- Next State Logic
• end process CMB ;

• Y <= S ;
• end RTL ;
Medvedev Example
• architecture RTL of MEDVEDEV_TEST is
• signal STATE,NEXTSTATE : STATE_TYPE ;
• begin
• REG: process (CLK, RESET)
• begin
• if RESET=`1` then
• STATE <= START ;
• elsif CLK`event and CLK=`1` then
• STATE <= NEXTSTATE ;
• end if ;
• end process REG;
•
• CMB: process (A,B,STATE) begin
• NEXT_STATE <= STATE;
• case STATE is
• when START => if (A or B)=`0` then
• NEXTSTATE <= MIDDLE ;
• end if ;
• when MIDDLE => if (A and B)=`1` then
• NEXTSTATE <= STOP ;
• end if ;
• when STOP => if (A xor B)=`1` then
• NEXTSTATE <= START ;
• end if ;
• when others => NEXTSTATE <= START ;
• end case ;
• end process CMB ;
• -- concurrent signal assignments for output
• (Y,Z) <= STATE ;
• end RTL ;
• Defining constants
• Control of encoding
• Safe FSM
• Simulatable
• Portable design
• More effort
Medvedev Example
architecture RTL of MEDVEDEV_TEST is
signal STATE,NEXTSTATE : STATE_TYPE ;
begin
REG: process (CLK, RESET)
begin
if RESET=`1` then
STATE <= START ;
elsif CLK`event and CLK=`1` then
STATE <= NEXTSTATE ;
end if ;
end process REG;
• CMB: process (A,B,STATE) begin
• NEXT_STATE <= STATE;
• case STATE is
• when START => if (A or B)=`0` then
• NEXTSTATE <= MIDDLE ;
• end if ;
• when MIDDLE => if (A and B)=`1` then
• NEXTSTATE <= STOP ;
• end if ;
• when STOP => if (A xor B)=`1` then
• NEXTSTATE <= START ;
• end if ;
• when others => NEXTSTATE <= START ;
• end case ;
• end process CMB ;
• -- concurrent signal assignments for output
• (Y,Z) <= STATE ;
• end RTL ;
 (Y,Z) = STATE => Medvedev
machine
• In the waveform one can see the
progression over time of the signal values
of the design during simulation. It is
apparent that it must be a Medvedev
automaton, because the values of the
output vector (represented by the two
singals Y and Z) change synchronously
with the state vector.
FSM: Moore
 TWO PROCESSORS

architecture RTL of MOORE is

...
begin
REG: process (CLK, RESET)
begin
-- State Registers Inference with Next State Logic
end process REG ;
OUTPUT: process (STATE)
begin
-- Output Logic
end process OUTPUT ;
end RTL ;
 THREE PROCESSES
architecture RTL of MOORE is
...
begin
REG: -- Clocked Process
CMB: -- Combinational Process

OUTPUT: process (STATE)

begin
-- Output Logic
end process OUTPUT ;
end RTL ;
• The value of the output vector is a function of the
current state. This is the reason for the second
logic block in the block diagram, located after
the storing elements. This logic block holds the
hardware which is needed to calculate the
output values out of the current state of the
automaton.

• In the VHDL source code, this logic is

implemented with an own combinational
process. As the value of the output vector
depends on the current value of the state vector,
only, no other signals appear in the sensitivity
list of the process.
• architecture RTL of MOORE_TEST is
• signal STATE,NEXTSTATE :
STATE_TYPE ;
• begin
• REG: process (CLK, RESET) begin
• if RESET=`1` then STATE <=
START ;
• elsif CLK`event and CLK=`1` then
• STATE <= NEXTSTATE ;
• end if ; end process REG ;
•
• CMB: process (A,B,STATE) begin
• NEXT_STATE <= STATE;
• case STATE is
• when START => if (A or B)=`0` then
• NEXTSTATE <= MIDDLE ;
• end if ;
• when MIDDLE => if (A and B)=`1` then
• NEXTSTATE <= STOP ;
• end if ;
• when STOP => if (A xor B)=`1` then
• NEXTSTATE <= START ;
• end if ;
• when others => NEXTSTATE <= START ;
• end case ; end process CMB ;
• -- concurrent signal assignments for output
• Y <= ,1` when STATE=MIDDLE else ,0` ;
• Z <= ,1` when STATE=MIDDLE
• or STATE=STOP else ,0` ;
• end RTL ;
• The difference to the Medvedev automaton can
be recognized in the difference between the
state encoding and the corresponding values for
the output vector. Both values are specified in
the bubbles. The values for the output vector (Y,
Z) are the same as in the Medvedev automaton.
However the state encoding is now based upon
a binary code.

• In the VHDL source code, the ouput logic is not

contained in a combinational process because
of space limitation. Instead, it is implemented via
separate concurrent signal assignments. One
can see that the output values are calculated out
of the state vector values.
 MOORE MACHINE
• (Y,Z) changes simultaneously with STATE
=> Moore machine
• Again, the characteristics of the Moore
automaton can be seen clearly in the
waveform. The values of the output vector
change simultaneously with the values of
the state vector. But this time the values of
the output vector differ from those of the
state vector.
FSM: Mealy
• The output vector is a function of the state
vector
and the input vector: Y = f(X,S)
 TWO PROCESSES
• architecture RTL of MEALY is
• ...
• begin
• MED: process (CLK, RESET)
• begin
• -- State Registers Inference with Next State Logic
• end process MED ;

• OUTPUT: process (STATE, X)

• begin
• -- Output Logic
• end process OUTPUT ;
• end RTL ;
 THREE PROCESSES
• architecture RTL of MEALY is
• ...
• begin
• REG: -- Clocked Process

• CMB: -- Combinational Process

• OUTPUT: process (STATE, X)

• begin
• -- Output Logic
• end process OUTPUT ;
• end RTL ;
• Here, a Mealy automat is shown.

• The value of the output vector is a function of the

current values of the state vector and of the
input vector. This is why a line is drawn in the
block diagram from the input vector to the logic
block calculating the output vector. In the VHDL
source code, the input vector is now listed in the
senisitivity list of the corresponding process.
Mealy Example
• architecture RTL of MEALY_TEST is
signal STATE,NEXTSTATE :
STATE_TYPE ;
begin
REG: · · · -- clocked STATE process

CMB: · · · -- Like Medvedev and Moore

Examples
• OUTPUT: process (STATE, A, B)
• begin
• case STATE is
• when START =>
• Y <= `0` ;
• Z <= A and B ;
• when MIDLLE =>
• Y <= A nor B ;
• Z <= '1' ;
• when STOP =>
• Y <= A nand B ;
• Z <= A or B ;
• when others =>
• Y <= `0` ;
• Z <= '0' ;
• end case;
• end process OUTPUT;
• end RTL ;
• In contrast to the other two types of automatons
decribed before, the output values can not be
simply written into the corresponding state
bubble here. Complete functions have to be
written down which differ from state to state.
These functions are often "hidden" behind the
state bubble, instead of explicitly displayed in the
graphic.
• In the VHDL source code, the calculation of the
ouput values is described with concurrent signal
assignments, again. One can see that the input
signals appear on the right side of the
assignments and are therefore part of the output
function, now.
• (Y,Z) changes with input => Mealy
machine
• Note the "spikes" of Y and Z in the
waveform
• FSM has to be modeled carefully in order
to avoid spikes in normal operation
• Again, one can see the characteristics of the
Mealy automaton clearly in the waveform. The
most remarkable feature is the fact that the
output values change together with the values of
the input vector, sometimes.
• Furthermore, they change together with changes
of the state vector values, of course. As one can
see, this can lead to so called spikes, i.e. signal
pulses with a smaller width than the clock
period. This can lead to a misbehaviour in the
blocks following thereafter
• . Of course, this has to be avoided and the
designer must take special care when modeling
a Mealy automaton in a form similar to the one
described here.
 MODELLING ASPECTS
• Medvedev is too inflexible
• Moore is preferred because of safe
operation
• Mealy more flexible, but danger of
Spikes
• Unnecessary long paths (maximum clock
period)
• Combinational feed back loops
 Registered Output

• Avoiding long paths and uncertain timing

With one additional clock period
Without additional clock period
(Mealy)
• As shown before, combinational feedback
loops can occur if two Mealy automatons
are connected in a row. These loops can
be avoided if the outputs are "clocked", i.e.
if the outputs are connected to Flip Flops.
With this, the feedback loop is broken up.
• Generally, clocked outputs are used to avoid long paths
between Flip Flops and thus assure a safe timing
behavior. By clocking all outputs, the output logic is
separated from the next logic block of the subsequent
module and by this the path through logic elements is
shortened and higher clock frequencies are possible.
• Furthermore, synthesis tools often have problems when
optimizing logic paths which pass module boundaries for
speed. By clocking the outputs, these problems can be
solved. Another advantage is that the successive module
can work with safe input data. "Safe" means that the
data changes with the active clock edge, only, and thus
spikes are ruled out. So the designer of the successive
modul has more options in designing the module.
• Two versions are known for clocking the
output. In the first version, an additional
delay of one clock period is created. Here,
Flip Flops are simply inserted between the
output logic and the state machine outputs
without any other changes. By this, the
new values of the outputs arrive after the
next active clock edge. However, this
delay, sometimes, can not be accepted.
• In the second version, Flip Flops are
present at the state machine output and
the output logic uses the NEXT_STATE
signal in addition to the state vector. For
bigger state machines, this can lead to
incomprehensible dependencies and
relatively long paths as two logic blocks
are connected in a row, again. But this
version of a state machine is the most
flexible and the fastest (in terms of delay)
which provides safe (clocked) output
signals.
Registered output-Example
• architecture RTL of REG_TEST is
• signal Y_I , Z_I : std_ulogic ;
• signal STATE,NEXTSTATE : STATE_TYPE ;
• begin
• REG: · · · -- clocked STATE process

• CMB: · · · -- Like other Examples

• OUTPUT: process (STATE, A, B)

• begin
• case STATE is
• when START =>
• Y_I<= `0` ;
• Z_I<= A and B ;
• ···
• end process OUTPUT