Embedded system design process_models

Embedded Systems Design: A Unified
Hardware/Software Introduction, (c) 2000 Vahid/Givargis
UNIT - IV: State Machine And
Concurrent Process Models
• Introduction
• models Vs. languages
• finite state machines with data path model (FSMD)
• using state machines
• program state machine model (PSM)
• concurrent process model
1

2
• Describing embedded system’s processing behavior
– Sequential program computation model
• A set of instructions execute sequentially
• One statement at a time
– Assembly language
– High level languages like C
Introduction

3
• Complexity increasing with increasing IC capacity
– Past: washing machines, small games, etc.
• Hundreds of lines of code
– Today: TV set-top boxes, Cell phone, etc.
• Hundreds of thousands of lines of code
– Describing the behavior becomes more complex
• Desired behavior often not fully understood in beginning
– Many implementation bugs due to description mistakes
/omissions
Introduction

4
• Describing embedded system’s processing behavior
– English (or other natural language) common starting point
• Precise description is difficult and gives no useful results
• Example: Motor Vehicle Code – thousands of pages long...
Introduction

5
An example of trying to be precise in English
• California Vehicle Code
– Right-of-way of crosswalks
• 21950. (a) The driver of a vehicle shall yield the right-of-way to a pedestrian
crossing the roadway within any marked crosswalk or within any unmarked
crosswalk at an intersection, except as otherwise provided in this chapter.
• (b) The provisions of this section shall not relieve a pedestrian from the duty
of using due care for his or her safety. No pedestrian shall suddenly leave a
curb or other place of safety and walk or run into the path of a vehicle which
is so close as to constitute an immediate hazard. No pedestrian shall
unnecessarily stop or delay traffic while in a marked or unmarked crosswalk.
• (c) The provisions of subdivision (b) shall not relieve a driver of a vehicle
from the duty of exercising due care for the safety of any pedestrian within
any marked crosswalk or within any unmarked crosswalk at an intersection.
– All that just for crossing the street (and there’s much more)!

6
Types of models
• How can we (precisely) capture behavior?
– We may think of languages (C, C++), but computation model
is the key
• Common computation models:
1. Sequential program model
• Statements, rules for composing statements, semantics for
executing one statement at a time
2. Communicating process model
• Multiple sequential programs running concurrently

7
Types of models
3. State machine model
• For control dominated systems
• A control dominated system is one whose behavior
consists mostly of monitoring control inputs and reacting
by setting control outputs
4. Dataflow model
• For data dominated systems
• A data dominated system’s behavior consists mostly of
transforming streams of input data into streams output data
5. Object-oriented model
• For breaking complex software into simpler, well-defined
pieces

8
Models vs. languages
• Computation models describe system behavior
– Conceptual notion (idea / belief), e.g., recipe
• Languages capture models
– Concrete form, e.g., English, C
Models
Languages
Recipe
SpanishEnglish Japanese
Poetry Story Sequent.
program
C++C Java
State
machine
Data-
flow
Recipes vs. English Sequential programs vs. C

9
Models vs. languages
• Variety of languages can capture one model
– E.g., sequential program model  C,C++, Java
• One language can capture variety of models
– E.g., C++ → sequential program model, object-oriented
model, state machine model
• Certain languages better at capturing certain computation
models
Models
Languages
Recipe
SpanishEnglish Japanese
Poetry Story Sequent.
program
C++C Java
State
machine
Data-
flow
Recipes vs. English Sequential programs vs. C

10
Text versus Graphics
• Models versus languages not to be confused with text versus
graphics
– Text and graphics are just two types of languages
• Text: letters, numbers
• Graphics: circles, arrows (plus some letters, numbers)
X = 1;
Y = X + 1;
X = 1
Y = X + 1

11
Introductory example: An elevator controller
• Simple elevator controller
• Two major blocks:
– Request Resolver resolves
various floor requests into
single requested floor
– Unit Control moves
elevator to this requested
floor
• Simple English description….
buttons
inside
elevator
Unit
Control
b1
down
open
Floor (current
floor)
...
Request
Resolver
...
up/down
buttons on
each
floor
b2
bN
up1
up2
dn2
dnN
req
up
System interface
up3
dn3

12
Introductory example: An elevator controller
“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…”
Partial English description
buttons
inside
elevator
Unit
Control
b1
down
open
floor
...
Request
Resolver
...
up/down
buttons on
each
floor
b2
bN
up1
up2
dn2
dnN
req
up
System interface
up3
dn3

13
Elevator controller using a sequential
program model
void Unit_Control ( )
{
up = down = 0; open = 1; //Initial condition
while (1) { // Infinite / super loop
while (req != floor)
open = 0; //close the door
if (req > floor) { up = 1 ; }
else { down = 1; }
while (req = = floor); // Same floor
up = down = 0;
open = 1; // Keep the door open
delay(10) ; // Wait for 10 seconds
} }
void main ( )
{
Call concurrently:
Unit_Control( ) and
Request_Resolver( )
}
Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN;
Outputs: bit up, down, open;
Global variables: int req;
void Request_Resolver ( )
{
while (1)
...
req = ...
...
}

14
Finite-state machine (FSM) model
• In a finite state machine (FSM) model we describe the system
behaviour as a set of possible states
• The system can only be in one of these states at a given time
• It describes the possible state transitions from one state to another
depending on input values
• It also describes the actions that occur when in a state or when
transitioning between states

15
• Two types of FSM
• 1. Moore type FSM
• It associates outputs with states
• i.e., H maps S  O
• 2. Mealy type FSM
• It associates outputs with state transitions
• i.e., H maps S x I  O
• Both these models are supported by modern tools

16
• Trying to capture this behavior as sequential program is a bit
awkward
• Instead, we might consider an FSM model, describing the system
as:
– Possible states
• E.g., Idle, GoingUp, GoingDn, DoorOpen
– Possible transitions from one state to another based on input
• 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)
• Try it...

17
Idle
GoingUp
req > floor
req < floor
!(req > floor)
!(timer < 10)
req < floor
DoorOpen
GoingDn
req > floor
u,d,o, t = 1,0,0,0
u,d,o,t = 0,0,1,0
u,d,o,t = 0,1,0,0
u,d,o,t = 0,0,1,1
u is up, d is down, o is open
req == floor
!(req<floor)
timer < 10
t is timer_start
Unit Control process using a state machine

18
Formal definition
• An FSM is a 6-tuple F <S, I, O, F, H, s0>
– S is a set of all states {s0, s1, …, sl}
– I is a set of inputs {i0, i1, …, im}
– O is a set of outputs {o0, o1, …, on}
– F is a next-state function (S x I → S)
– H is an output function (S → O)
– s0 is an initial state
• Moore-type
– Associates outputs with states (as given above, H maps S → O)
• Mealy-type
– Associates outputs with transitions (H maps S x I → O)
• Shorthand notations to simplify descriptions
– Implicitly assign 0 to all unassigned outputs in a state
– Implicitly AND every transition condition with clock edge (FSM is synchronous)

• Tuple:
• In mathematics, a tuple is a finite ordered list of
elements.
• An n-tuple is a sequence of n elements, where n is a
non-negative integer.
• There is only one 0-tuple, an empty sequence, or
empty tuple, as it is referred to.
• An n-tuple is defined inductively using the
construction of an ordered pair.
19

20
• We often use FSM to describe a single purpose processor
(hardware)
• Most hardware is synchronous
• The register updates are synchronized to clock pulses (e.g.,
registers are updated only on the rising or falling edge of a clock)
• Such an FSM would have every transition condition ANDed with
the clock edge

21
Finite-state machine with Data path (FSMD)
model
• When using an FSM for Embedded system design , the inputs and
outputs represent Boolean data types
• And the functions therefore represent Boolean functions with
Boolean operations
• This model may be sufficient for many purely control systems
that do not input or output data
• However, when we must deal with data, two new features would
be helpful
• 1. More complex data types (e.g., int, float)
• 2. Variables to store data

22
Finite-state machine with Data path (FSMD)
model
• Definition:
• An FSM model extended to support more complex data types and
variables as an FSM with data path or FSMD
• Many authors refer to it as extended FSM

23
Finite-state machine with datapath model
(FSMD)
• FSMD extends FSM: complex data types and variables for
storing data
– FSMs use only Boolean data types and operations, no
variables
• FSMD: 7-tuple <S, I , O, V, F, H, s0>
– S is a set of states {s0, s1, …, sl}
– I is a set of inputs {i0, i1, …, im}
– O is a set of outputs {o0, o1, …, on}
– V is a set of variables {v0, v1, …, vn}
– F is a next-state function (S x I x V → S)
– H is an action function (S → O + V)
– s0 is an initial state

24
Finite-state machine with datapath model
(FSMD)
• I,O,V may represent complex data types (i.e., integers, floating point, etc.)
• F, H may include arithmetic operations
• H is an action function, not just an output function
– Describes variable updates as well as outputs
• Complete system state now consists of current state, si, and values of all variables
Idle
GoingUp
req > floor
req < floor
!(req > floor)
!(timer < 10)
req < floor
DoorOpen
GoingDn
req > floor
u,d,o, t = 1,0,0,0
u,d,o,t = 0,0,1,0
u,d,o,t = 0,1,0,0
u,d,o,t =
0,0,1,1
req ==
floor
!(req<floor)
timer < 10
t is timer_start
We described UnitControl as an FSMD

25
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
!(req > floor)u,d,o, t = 1,0,0,0
u,d,o,t = 0,0,1,0
u,d,o,t = 0,1,0,0
u,d,o,t = 0,0,1,1
req < floor
req > floor
req == floor
req < floor
!(req<floor)
!(timer < 10)
timer < 10
t is timer_start
Idle
GoingUp
DoorOpen
GoingDn

26
State machine vs. sequential program model
• Different thought process used with each model
• State machine:
– Encourages designer to think of all possible states and transitions among states
based on all possible input conditions
• Sequential program model:
– Designed to transform data through series of instructions that may be iterated and
conditionally executed
• Advantages of State machine description
– More natural means of computing in those cases
– Not due to graphical representation (state diagram)
• Would still have same benefits if textual language used (i.e., state table)
• Besides, sequential program model could use graphical representation (i.e.,
flowchart)

27
Try Capturing Other Behaviors with an FSM
• E.g., Answering machine blinking light when there are
messages
• E.g., A simple telephone answering machine that
answers after 4 rings when activated
• E.g., A simple crosswalk traffic control light
• Others

28
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...

29
Language subset approach
#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;
UnitControl state machine in sequential programming language
GOINGUP: up=1; down=0; open=0;
timer_start=0;
if (req > floor) {state = GOINGUP;}
if (!(req>floor)){state =DOOROPEN;}
break;
GOINGDN: up=0; down=1; 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;
}
}
}

30
Language subset approach
• 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 = …;}

31
General template
#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;
}
}
}

32
HCFSM and the Statecharts language
• Hierarchical/concurrent Finite 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
A1 z
B
A2 z
x y
w
Without hierarchy
A1 z
B
A2
x y
A
w
With hierarchy

Hierarchy
• We use hierarchy to :
• Reduce number of transitions
• Enhance understandability
33

34
HCFSM and the Statecharts language
– States can execute concurrently
• Known as AND-decomposition
• Statecharts language
– Graphical language to capture HCFSM
– 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 (like
INTR) when returning from B (like
ISR) instead of initial state
C1
C2
x y
C
B
D1
D2
u v
D
Concurrency

35
Another example: UnitControl with
FireMode
• FireMode
– When fire is true, move elevator
to 1st floor and open door
Without hierarchy
Idle
GoingUp
req>floor
req<floor
!(req>floor)
timeout(10)
req<floor
DoorOpen
GoingDn
req>floor
u,d,o = 1,0,0
u,d,o = 0,0,1
u,d,o = 0,1,0
req==floor
!(req<floor)
fire
fire
fire
fire
FireGoingDn
floor>1
u,d,o = 0,1,0
u,d,o = 0,0,1
!fire
FireDrOpen
floor==1
fire
u,d,o = 0,0,1
UnitControl
fire
!fire
FireGoingDn
floor>1
u,d,o = 0,1,0
FireDrOpen
floor==1
fire
FireMode
u,d,o = 0,0,1
With hierarchy
Idle
GoingUp
req>floor
req<floor
!(req>floor)
timeout(10)
req<floor
DoorOpen
GoingDn
req>floor
u,d,o = 1,0,0
u,d,o = 0,0,1
u,d,o = 0,1,0
req==floor
!(req>floor)
u,d,o = 0,0,1
NormalMode
UnitControl
NormalMode
FireMode
fire!fire
UnitControl
ElevatorController
RequestResolver
...
With concurrent RequestResolver
– w/o hierarchy: Getting messy!
– w/ hierarchy: Simple!

Concurrency
NormalMode
FireMode
fire!fire
UnitControl
ElevatorController
RequestResolver
...
With concurrent RequestResolver
• Second extension of HCFSM model
• Concurrency allows us to use hierarchy to decompose a state
into two concurrent states (AND decomposistion)
• Other words, to group two concurrent states into a new
hierarchical state

37
Program-state machine model (PSM):
HCFSM plus sequential program model
• The PSM model extends finite state machine models to allow
use of sequential program code to define a state’s action
• Including extensions for complex data types (int, float) and
variables (same as FSMD)
• Also includes the extensions of HCFSM
• Thus PSM = HCFSM + Sequential program models
• Design can choose whichever model is most appropriate

38
• A PSM having many states, whose actions are all just
assignment statements
up = down = 0; open = 1;
while (1) {
while (req == floor);
open = 0;
if (req > floor) { up = 1;}
else {down = 1;}
while (req != floor);
open = 1;
delay(10);
} }
NormalMode
FireMode
up = 0; down = 1; open = 0;
while (floor > 1);
up = 0; down = 0; open = 1;
fire!fire
UnitControl
ElevatorController
RequestResolver
...
req = ...
...
int req;

39
• AND decompose : Unit control and request resolver
• OR- decompose: NormalMode and FireMode
• However, we described as sequential programs
• Black square originating within FireMode indicates !fire is a TOC
transition
– Transition from FireMode to NormalMode only after
FireMode completed

PSM
• PSM forces Stricter hierarchy than HCFSM used in Statecharts
– transition between sibling states (i.e., between states with the
same parent state) only
– single entry (we always enter the subroutine from one point
only)
– Exit can be any part of the state (just like HCFSM)
– Program-state may “complete”
• Reaches end of sequential program code
• FSM transition to special complete substate
40

41
• PSM has 2 types of transitions
– Transition-immediately (TI): taken when condition
is true, and regardless of source program-state
– Transition-on-completion (TOC): taken only if
condition is true AND source program-state is
complete
– SpecCharts language : First language to capture PSM
model easily, extension of VHDL
– SpecC language: Recently developed, extension of C to
capture PSM model

42
Role of appropriate model and language
• Finding appropriate model to capture embedded system is an important step
– Model shapes the way we think of the system
• Originally thought of sequence of actions, wrote sequential program
– First wait for requested floor to differ from target floor
– Then, we close the door
– Then, we move up or down to the desired floor
– Then, we open the door
– Then, we repeat this sequence
• To create state machine, we thought in terms of states and transitions
among states
– When system must react to changing inputs, state machine might
be best model
• HCFSM described FireMode easily, clearly

43
Role of appropriate model and language
• Language should capture model easily
– Ideally should have features that directly capture constructs
of model
– FireMode would be very complex in sequential program
• Checks inserted throughout code
– Other factors may force choice of different model
• Structured techniques can be used instead
– E.g., Template for state machine capture in sequential
program language

44
Concurrent Process Model
• Computation model:
• A computation model provides a set of objects and rules
operating on those object that help a designer describe a
system’s functionality
• A system’s functionality may be described using multiple
computational models
• Language:
• A language, provides semantics and constructs that enable a
designer to capture a computational model
• Some languages capture more than one computational model

45
Concurrent Process Model
• Concurrent process model:
• The concurrent process model is a model that allows us to
describe the functionality of a system in terms of two or more
concurrently executing subtasks
• Application:
• Concurrent process model is when describing systems that are
inherently multitasking.

46
Concurrent process model
• E.g., simple example:
– Read two numbers X and Y
– Display “Hello world.” every X seconds
– Display “How are you?” every Y seconds
• More effort would be required with
sequential program or state machine model
Simple concurrent process example
ConcurrentProcessExample() {
x = ReadX()
y = ReadY()
Call concurrently:
PrintHelloWorld(x) and
PrintHowAreYou(y)
}
PrintHelloWorld(x) {
while( 1 ) {
print "Hello world."
delay(x);
}
}
PrintHowAreYou(x) {
while( 1 ) {
print "How are you?"
delay(y);
}
}

47
Concurrent process model
Subroutine execution over time
time
ReadX ReadY
PrintHelloWorld
PrintHowAreYou
Simple concurrent process example
ConcurrentProcessExample() {
x = ReadX()
y = ReadY()
Call concurrently:
PrintHelloWorld(x) and
PrintHowAreYou(y)
}
PrintHelloWorld(x) {
while( 1 ) {
print "Hello world."
delay(x);
}
}
PrintHowAreYou(x) {
while( 1 ) {
print "How are you?"
delay(y);
}
}
Sample input and output
Enter X: 1
Enter Y: 2
Hello world. (Time = 1 s)
How are you? (Time = 2 s)
How are you? (Time = 4 s)
...

48
Concurrent processes
• Consider two examples
having separate tasks running
independently but sharing
data
• Difficult to write system
using sequential program
model
• Concurrent process model
easier
– Separate sequential
programs (processes) for
each task
– Programs communicate with
each other
Heartbeat Monitoring System
B[1..4]
Heart-beat
pulse
Task 1:
Read pulse
If pulse < Lo then
Activate Siren
If pulse > Hi then
Activate Siren
Sleep 1 second
Repeat
Task 2:
If B1/B2 pressed then
Lo = Lo +/– 1
If B3/B4 pressed then
Hi = Hi +/– 1
Sleep 500 ms
Repeat
Set-top Box
Input
Signal
Task 1:
Read Signal
Separate
Audio/Video
Send Audio to Task 2
Send Video to Task 3
Repeat
Task 2:
Wait on Task 1
Decode/output Audio
Repeat
Task 3:
Wait on Task 1
Decode/output Video
Repeat
Video
Audio

49
Implementation
• Implementation : Mapping of system’s functionality onto
hardware processors:
– captured using computational model(s)
– written in some language(s)
• Implementation choice independent from language(s) choice
• Implementation choice based on power, size, performance,
timing and cost requirements
• Final implementation tested for feasibility
– Also serves as blueprint/prototype for mass manufacturing
of final product

50
Implementation
The choice of computational
model(s) is based on whether it
allows the designer to describe
the system.
The choice of language(s) is
based on whether it captures the
computational model(s) used by
the designer.
The choice of implementation is
based on whether it meets
power, size, performance and
cost requirements.
Sequent.
program
State
machine
Data-
flow
Concurrent
processes
C/C++Pascal Java VHDL
Implementation A Implementation
B
Implementation
C

Comparison Table
Model Textual Graphical Suitability
Sequential Program
model
C, C++, Java Flow chart For Dataflow
FSM State Table State Diagram For control
dominated
FSMD - State Diagram with
variables and Complex
data types
For Control + data
HCFSM - State Chart FSMD + Hierarchy
and concurrency
PSM C, C++, Java
(sequential
program model)
SpecChart
SpecC
Combined HCFSM
+ Sequential model
+ State completion
Concurrent process
models
Java PSM + Concurrent
Processes
Inherently
multitasking system
51

Thank You
52

Embedded system design process_models

More Related Content

What's hot (20)

Similar to Embedded system design process_models (20)

Recently uploaded (20)

Embedded system design process_models