1
FINITE STATE MACHINE
Finite-state machine (FSM) model

A discrete system operates in a sequence of
discrete steps

E.g Model of a system that keeps track of the number of
cars in parking garage

each entry or departure is modeled as a discrete event
FSM- Notion of state



Intuitively, the state of a system is its condition at a
particular point in time
Formally, we define the state to be an encoding of
everything about the past that has an effect on the
system’s reaction to current or future inputs. The state
is a summary of the past.
Transitions between states govern the discrete
dynamics of the state machine and the mapping of
input valuations to output valuations

Visual Notation for FSM
The action specifies what outputs are produced on each reaction.
An action is an assignment of values (or absent) to the output ports.
The guard determines whether
the transition may be taken on
a reaction. A guard is a
predicate
FSM – Garage Example
FSMD

Visual Notation for FSMD
FSMD
Example: An elevator controller
8

Simple elevator
controller



Request Resolver resolves
various floor requests into
single requested floor
Unit Control moves
elevator to this requested
floor
Try capturing in C...
Partial English
description
“Move the elevator either
up or down to reach the
requested floor. Once at
the requested floor, open
the door for at least 10
seconds, and keep it
open until the requested
floor changes. Ensure the
door is never open while
moving. Don’t change
directions unless there
are no higher requests
when moving up or no
lower requests when
moving down…”
System
interface
up
Unit
Control
down
open
floor
req
Request
Resolver
...
buttons
b1
inside
b2 elevator
bN
up1
up2
dn2
up3
dn3
...
dnN
up/down
buttons
on each
floor
9
Elevator controller using a
sequential program model
Sequential program model
Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN;
Outputs: bit up, down, open;
Global variables: int req;
void UnitControl()
{
up = down = 0; open = 1;
while (1) {
while (req == floor);
open = 0;
if (req > floor) { up = 1;}
else {down = 1;}
while (req != floor);
up = down = 0;
open = 1;
delay(10);
}
}
void RequestResolver()
{
while (1)
...
req = ...
...
}
void main()
{
Call concurrently:
UnitControl() and
RequestResolver()
}
System
interface
up
Unit
Control
down
open
floor
req
Request
Resolver
...
buttons
b1
inside
b2 elevator
bN
up1
up2
dn2
up3
dn3
...
dnN
up/down
buttons
on each
floor
Finite-state machine (FSM) model
10


Trying to capture behavior as sequential program is a bit
awkward
Instead, we might consider an FSM model, describing the system
as:

Possible states


Possible transitions from one state to another based on input


E.g., Idle, GoingUp, GoingDn, DoorOpen
E.g., req > floor
Actions that occur in each state

E.g., In the GoingUp state, u,d,o,t = 1,0,0,0 (up = 1, down, open, and timer_start =
0)
11
Describing a system as a state
machine
1. List all possible states
2. Declare all variables (none in this example)
3. For each state, list possible transitions, with conditions, to other states
4. For each state and/or transition, list
associated actions
5. For each state, ensure exclusive and
complete exiting transition conditions

No two exiting conditions can
be true at same time


Otherwise nondeterministic
state machine
One condition must be true at
any given time

Reducing explicit transitions
should be avoided when first
learning
req > floor
GoingUp
!(req > floor)
timer < 10
req > floor
u,d,o, t = 1,0,0,0
Idle
req == floor
u,d,o,t = 0,0,1,0
!(timer < 10) DoorOpen
u,d,o,t = 0,0,1,1
req < floor
u,d,o,t = 0,1,0,0
!(req<floor)
GoingDn
u is up, d is down, o is open
req < floor
t is timer_start
FSM-UART

UART- Universal Asynchronous Receiver/Transmiter

Used for serial communication over serial port
 Baud
Rate
 Start,
Stop bits
FSM-Soda Machine
Suppose you have a soda machine:
When turned on, the machine waits for money
When a quarter is deposited, the machine waits for another
quarter
When a second quarter is deposited, the machine waits for a
selection
When the user presses “COKE,” a coke is dispensed
When the user takes the bottle, the machine waits again
When the user presses either “SPRITE” or “DIET COKE,” a Sprite
or a diet Coke is dispensed
When the user takes the bottle, the machine waits again
Design FSM
• Automated Answering machine
• ATM Controller
• Traffic Light
15/03/12
HCFSM and the Statechart language
15

Hierarchical/concurrent state machine model
(HCFSM)



Extension to state machine model to support hierarchy
and concurrency
States can be decomposed into another state machine

With hierarchy has identical functionality as Without
hierarchy, but has one less transition (z)

Known as OR-decomposition
With hierarchy
Without
hierarchy
A1
yw
x
A2
A
z
A1
B
x
z
A2
States can execute concurrently

Concurrenc
y B
Known as AND-decomposition
C

Statecharts
C2
timeout: transition with time limit as condition

history: remember last substate OR-decomposed state
A was in before transitioning to another state B

Return to saved substate of A when returning from B
instead of initial state
D1
y
Graphical language to capture HCFSM

D
C1
x

y
u
v
D2
z
B
w
UnitControl with FireMode
16
req>floor
u,d,o = 1,0,0
UnitControl

GoingUp
req>floor
u,d,o = 0,0,1
timeout(10)
Idle
req==floor
req<floor
GoingDn
u,d,o = 0,1,0
FireMode
!(req>floor)
!(req<floor)
fire
fire
req<floor
DoorOpen
fire
fire
FireGoingDn
floor>1
!fire
u,d,o = 0,0,1


u,d,o = 0,1,0
floor==1 u,d,o = 0,0,1
FireDrOpen

When fire is true, move elevator to
1st
floor
and open
door messy!
w/o
hierarchy:
Getting
w/ hierarchy: Simple!
With hierarchy
fire
Without hierarchy
UnitControl
NormalMode
req>floor
u,d,o = 1,0,0
GoingUp
!(req>floor)
req>floor
ElevatorController
UnitControl
RequestResolver
NormalMode
fire
Idle
req==floor
u,d,o = 0,1,0
...
!fire
u,d,o = 0,0,1
req<floor
GoingDn
timeout(10)
!(req>floor)
u,d,o = 0,0,1
req<floor
FireMode
fire
!fire
With concurrent
RequestResolver
DoorOpen
FireMode
u,d,o = 0,1,0
FireGoingDn
floor==1 u,d,o = 0,0,1
floor>1
FireDrOpen
fire
Gather Cash
Idle
take
bottle
q
dispense
coke
q
idle
q
25c
cb
dispense
diet coke
50c
take
bottle
q
50c
cd
cs
take
bottle
25c
Take bottle
Dispense Product
paid
dispense
sprite
coke
Diet
Coke
cb
cd
Sprite
cs
Exceptions
Bottles can get stuck in the machine
An automatic indicator will notify the system when a bottle is stuck
When this occurs, the machine will not accept any money or issue any bottles until
the bottle is cleared
When the bottle is cleared, the machine will wait for money again
State machine changes
How many new states are required?
How many new transitions?
Hierarchical FSM
OK
Gather Cash
Idle
clear bottle
take
bottle
idle
q
25c
cb
cd
take
bottle
dispense
sprite
50c
stuck
Clear
bottle
Dispense Product
paid
Stuck
bottle
cs
take
bottle
q
Take bottle
dispense
diet coke
50c
25c
stuck
bottle
dispense
coke
q
q
coke
Stuck
Diet
Coke
cb
cd
Sprite
cs
20
Capturing state machines in
sequential programming language

Despite benefits of state machine model, most popular development tools use
sequential programming language

C, C++, Java, Ada, VHDL, Verilog, etc.

Development tools are complex and expensive, therefore not easy to adapt or replace


Must protect investment
Two approaches to capturing state machine model with sequential programming
language

Front-end tool approach



Additional tool installed to support state machine language

Graphical and/or textual state machine languages

May support graphical simulation

Automatically generate code in sequential programming language that is input to main development tool
Drawback: must support additional tool (licensing costs, upgrades, training, etc.)
Language subset approach

Most common approach...
Language subset approach
21



Follow rules (template) for capturing
state machine constructs in equivalent
sequential language constructs
Used with software (e.g.,C) and
hardware languages (e.g.,VHDL)
Capturing UnitControl state machine in
C

Enumerate all states (#define)

Declare state variable initialized to
initial state (IDLE)

Single switch statement branches to
current state’s case

Each case has actions


up, down, open, timer_start
Each case checks transition conditions to
determine next state

if(…) {state = …;}
#define IDLE0
#define GOINGUP1
#define GOINGDN2
#define DOOROPEN3
void UnitControl() {
int state = IDLE;
while (1) {
switch (state) {
IDLE: up=0; down=0; open=1; timer_start=0;
if
(req==floor) {state = IDLE;}
if
(req > floor) {state = GOINGUP;}
if
(req < floor) {state = GOINGDN;}
break;
GOINGUP: up=1; down=0; open=0; timer_start=0;
if
(req > floor) {state = GOINGUP;}
if
(!(req>floor)) {state = DOOROPEN;}
break;
GOINGDN: up=1; down=0; open=0; timer_start=0;
if
(req < floor) {state = GOINGDN;}
if
(!(req<floor)) {state = DOOROPEN;}
break;
DOOROPEN: up=0; down=0; open=1; timer_start=1;
if (timer < 10) {state = DOOROPEN;}
if (!(timer<10)){state = IDLE;}
break;
}
}
}
UnitControl state machine in sequential programming language
General template
22
#define S0
0
#define S1
1
...
#define SN
N
void StateMachine() {
int state = S0; // or whatever is the initial state.
while (1) {
switch (state) {
S0:
// Insert S0’s actions here & Insert transitions Ti leaving S0:
if( T0’s condition is true ) {state = T0’s next state; /*actions*/ }
if( T1’s condition is true ) {state = T1’s next state; /*actions*/ }
...
if( Tm’s condition is true ) {state = Tm’s next state; /*actions*/ }
break;
S1:
// Insert S1’s actions here
// Insert transitions Ti leaving S1
break;
...
SN:
// Insert SN’s actions here
// Insert transitions Ti leaving SN
break;
}
}
}
VHDL Template
Architecture <arch_name> of <entity_name> IS
(Declaration of states and signals)
TYPE state is (state1,state2……...stateN);
SIGNAL present_state,next_state : state;
e.g. type states is (IDLE,STARTTX,BIT0,BIT1,BIT2,BIT3,BIT4,BIT5,BIT6,BIT7,STOPTX);
SIGNAL pr_state,nx_state : state;
Begin
---------------------------State Memory---------------------------------------------
PROCESS(reset,clock)
BEGIN
IF(reset=‘1’) then
pr_state<=state0;
ELSIF (clk’EVENT and clk=‘1’) THEN
pr_state<= nx_state;
END IF;
END PROCESS;
VHDL Template
---------------------------------Next state and output logic ---------------------------------------PROCESS(input, pr_state)
BEGIN
CASE pr_state IS
WHEN state0 =>
IF(input = …) THEN
output<=<value>
nx_state<=state1;
ELSE …
END IF;
WHEN state1 =>
IF(input = …) THEN
output<=<value>
nx_state<=state2;
ELSE …
END IF;
.
.
.
END CASE;
END PROCESS;
VHDL Template
process(pr_state,txData,enable)
begin
case pr_state is
when IDLE => tx<='1'; if(enable='1') then nx_state<=STARTTX; else nx_state<=IDLE; end if;
when STARTTX => tx<='0';
nx_state<=BIT0;
when BIT0 => tx<=txData(0); nx_state<=BIT1;
when BIT1 => tx<=txData(1); nx_state<=BIT2;
when BIT2 => tx<=txData(2); nx_state<=BIT3;
when BIT3 => tx<=txData(3); nx_state<=BIT4;
when BIT4 => tx<=txData(4); nx_state<=BIT5;
when BIT5 => tx<=txData(5); nx_state<=BIT6;
when BIT6 => tx<=txData(6); nx_state<=BIT7;
when BIT7 => tx<=txData(7); nx_state<=STOPTX;
when STOPTX => tx<='1';
end case;
end process;
nx_state<=IDLE;
Verilog Template
---------------state memory-----------always @ (posedge clock)
pr_state<=nx_state;
---------------next state logic------------always @ (input,pr_state) begin
case(pr_state)
STATE1: if(input==…)
output=<value>;
nx_state=STATE2;
.
.
.