Embedded Systems Design: A Unified

Hardware/Software Introduction

Chapter 8: State Machine and

Concurrent Process Model

1
 Outline

• Models vs. Languages

• State Machine Model
– FSM/FSMD
– HCFSM and Statecharts Language
– Program-State Machine (PSM) Model
• Concurrent Process Model
– Communication
– Synchronization
– Implementation
• Dataflow Model
• Real-Time Systems
Embedded Systems Design: A Unified 2
Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Introduction

• Describing embedded system’s processing behavior

– Can be extremely difficult
• 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
• Desired behavior often not fully understood in beginning
– Many implementation bugs due to description mistakes/omissions
– English (or other natural language) common starting point
• Precise description difficult to impossible
• Example: Motor Vehicle Code – thousands of pages long...

Embedded Systems Design: A Unified 3

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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)!

Embedded Systems Design: A Unified 4

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Models and languages
• How can we (precisely) capture behavior?
– We may think of languages (C, C++), but computation model is the key
• Common computation models:
– Sequential program model
• Statements, rules for composing statements, semantics for executing them
– Communicating process model
• Multiple sequential programs running concurrently
– State machine model
• For control dominated systems, monitors control inputs, sets control outputs
– Dataflow model
• For data dominated systems, transforms input data streams into output streams
– Object-oriented model
• For breaking complex software into simpler, well-defined pieces

Embedded Systems Design: A Unified 5

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Models vs. languages
Poetry Recipe Story State Sequent. Data-
Models machine program flow

Languages English Spanish Japanese C C++ Java

Recipes vs. English Sequential programs vs. C

• Computation models describe system behavior

– Conceptual notion, e.g., recipe, sequential program
• Languages capture models
– Concrete form, e.g., English, C
• 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

Embedded Systems Design: A Unified 6

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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; X=1

Y = X + 1;

Y=X+1

Embedded Systems Design: A Unified 7

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Introductory example: An elevator controller

Partial English description System interface

• Simple elevator “Move the elevator either up or down Unit up

Control
controller to reach the requested floor. Once at
the requested floor, open the door for
down
open
at least 10 seconds, and keep it open
– Request Resolver until the requested floor changes. floor

resolves various floor Ensure the door is never open while

moving. Don’t change directions
req
Request
requests into single unless there are no higher requests Resolver
b1 buttons
when moving up or no lower requests inside
requested floor when moving down…”
... b2
bN
elevator

– Unit Control moves up1 up/down

up2 buttons
elevator to this requested dn2 on each
up3 floor
floor dn3
...
• Try capturing in C... dnN

Embedded Systems Design: A Unified 8

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Elevator controller using a sequential
program model
System interface
Sequential program model
Partial English description
Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN;
Unit up
Outputs: bit up, down, open;
Global variables: int req; “Move the elevator either up or down Control down
void UnitControl() void RequestResolver() to reach the requested floor. Once at open
{ { the requested floor, open the door for
up = down = 0; open = 1; while (1) floor
while (1) { ...
at least 10 seconds, and keep it open
until the requested floor changes. req
while (req == floor); req = ...
open = 0; ... Ensure the door is never open while Request
if (req > floor) { up = 1;} } Resolver
else {down = 1;}
moving. Don’t change directions b1 buttons
void main()
while (req != floor); unless there are no higher requests b2
inside
{ ... elevator
up = down = 0; Call concurrently: when moving up or no lower requests bN
open = 1; UnitControl() and when moving down…”
delay(10); RequestResolver() up1
} up/down
} up2 buttons
}
dn2 on each
up3 floor
dn3
You might have come up with something having ...
even more if statements. dnN

Embedded Systems Design: A Unified 9

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Finite-state machine (FSM) model
• 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...

Embedded Systems Design: A Unified 10

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Finite-state machine (FSM) model

UnitControl process using a state machine

req > floor

u,d,o, t = 1,0,0,0 GoingUp !(req > floor)

req > floor timer < 10

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

Embedded Systems Design: A Unified 11

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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)

Embedded Systems Design: A Unified 12

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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
We described UnitControl as an FSMD
• FSMD: 7-tuple <S, I , O, V, F, H, s0>
req > floor
– S is a set of states {s0, s1, …, sl}
u,d,o, t = 1,0,0,0 !(req > floor)
– I is a set of inputs {i0, i1, …, im} GoingUp
req > floor timer < 10
– O is a set of outputs {o0, o1, …, on} u,d,o,t = 0,0,1,0
Idle
!(timer < 10)
DoorOpen
req == floor u,d,o,t = 0,0,1,1
– V is a set of variables {v0, v1, …, vn} req < floor
!(req<floor)
– F is a next-state function (S x I x V → S) u,d,o,t = 0,1,0,0 GoingDn
u is up, d is down, o is open
– H is an action function (S → O + V) req < floor t is timer_start
– s0 is an initial state
• 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, s i, and values of all variables
Embedded Systems Design: A Unified 13
Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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, req > floor
list associated actions
5. For each state, ensure exclusive u,d,o, t = 1,0,0,0 GoingUp !(req > floor)
and complete exiting transition
conditions req > floor timer < 10

u,d,o,t = 0,0,1,0
• No two exiting conditions can Idle !(timer < 10) DoorOpen
be true at same time req == floor
req < floor
u,d,o,t = 0,0,1,1

– Otherwise nondeterministic
state machine u,d,o,t = 0,1,0,0
!(req<floor)
GoingDn
• One condition must be true at
any given time u is up, d is down, o is open
req < floor
– Reducing explicit transitions t is timer_start

should be avoided when first

learning
Embedded Systems Design: A Unified 14
Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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
• State machine description excels in many cases
– 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)

Embedded Systems Design: A Unified 15

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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

Embedded Systems Design: A Unified 16

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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...

Embedded Systems Design: A Unified 17

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Language subset approach
• Follow rules (template) for capturing
state machine constructs in equivalent #define IDLE0
#define GOINGUP1
sequential language constructs #define GOINGDN2
#define DOOROPEN3
• Used with software (e.g.,C) and void UnitControl() {
int state = IDLE;
hardware languages (e.g.,VHDL) while (1) {
switch (state) {
• Capturing UnitControl state machine IDLE: up=0; down=0; open=1; timer_start=0;
if (req==floor) {state = IDLE;}
in C if (req > floor) {state = GOINGUP;}
if (req < floor) {state = GOINGDN;}
– Enumerate all states (#define) break;
GOINGUP: up=1; down=0; open=0; timer_start=0;
– Declare state variable initialized to if (req > floor) {state = GOINGUP;}
initial state (IDLE) if (!(req>floor)) {state = DOOROPEN;}
break;
– Single switch statement branches to GOINGDN: up=1; down=0; open=0; timer_start=0;
if (req < floor) {state = GOINGDN;}
current state’s case if (!(req<floor)) {state = DOOROPEN;}
break;
– Each case has actions DOOROPEN: up=0; down=0; open=1; timer_start=1;
• up, down, open, timer_start if (timer < 10) {state = DOOROPEN;}
if (!(timer<10)){state = IDLE;}
– Each case checks transition conditions }
break;
}
to determine next state }

• if(…) {state = …;} UnitControl state machine in sequential programming language

Embedded Systems Design: A Unified 18

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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;
}
}
}

Embedded Systems Design: A Unified 19

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 HCFSM and the Statecharts language
• Hierarchical/concurrent state machine model
(HCFSM)
– Extension to state machine model to support Without hierarchy With hierarchy
hierarchy and concurrency A
– States can be decomposed into another state A1 z
A1 z
x w
machine y B x y B
• With hierarchy has identical functionality as Without w
A2 z
hierarchy, but has one less transition (z) A2

• Known as OR-decomposition
– States can execute concurrently
• Known as AND-decomposition
Concurrency
• Statecharts
B
– Graphical language to capture HCFSM C D
– timeout: transition with time limit as condition C1 D1

– history: remember last substate OR-decomposed x y u v

state A was in before transitioning to another state B C2 D2

• Return to saved substate of A when returning from B
instead of initial state

Embedded Systems Design: A Unified 20

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 UnitControl with FireMode
req>floor UnitControl

u,d,o = 1,0,0 GoingUp

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

u,d,o = 1,0,0 GoingUp

!(req>floor)
req>floor
ElevatorController u,d,o = 0,0,1 u,d,o = 0,0,1
Idle DoorOpen
UnitControl RequestResolver req==floor timeout(10)
req<floor !(req>floor)
NormalMode u,d,o = 0,1,0 GoingDn
...
!fire fire req<floor
FireMode FireMode
fire
FireGoingDn u,d,o = 0,1,0
!fire
floor==1 u,d,o = 0,0,1
floor>1
With concurrent RequestResolver FireDrOpen
fire

Embedded Systems Design: A Unified 21

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Program-state machine model (PSM):
HCFSM plus sequential program model
• Program-state’s actions can be FSM or ElevatorController
int req;
sequential program UnitControl RequestResolver
NormalMode
– Designer can choose most appropriate up = down = 0; open = 1; ...
while (1) { req = ...
• Stricter hierarchy than HCFSM used in while (req == floor); ...
open = 0;
Statecharts if (req > floor) { up = 1;}
else {down = 1;}
– transition between sibling states only, single entry while (req != floor);
open = 1;
– Program-state may “complete” delay(10);
}
• Reaches end of sequential program code, OR }
!fire fire
• FSM transition to special complete substate FireMode
up = 0; down = 1; open = 0;
• PSM has 2 types of transitions while (floor > 1);
– Transition-immediately (TI): taken regardless of up = 0; down = 0; open = 1;
source program-state
– Transition-on-completion (TOC): taken only if
condition is true AND source program-state is • NormalMode and FireMode described as
complete sequential programs
– SpecCharts: extension of VHDL to capture PSM • Black square originating within FireMode
model indicates !fire is a TOC transition
– SpecC: extension of C to capture PSM model – Transition from FireMode to NormalMode
only after FireMode completed

Embedded Systems Design: A Unified 22

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 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
• 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

Embedded Systems Design: A Unified 23

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Concurrent process model
• Describes functionality of system in terms of two or more
concurrently executing subtasks
ConcurrentProcessExample() { • Many systems easier to describe with concurrent process model
x = ReadX()
y = ReadY() because inherently multitasking
Call concurrently:
PrintHelloWorld(x) and • E.g., simple example:
PrintHowAreYou(y)
} – Read two numbers X and Y
PrintHelloWorld(x) {
while( 1 ) { – Display “Hello world.” every X seconds
print "Hello world."
delay(x); – Display “How are you?” every Y seconds
}
} • More effort would be required with sequential program or state
PrintHowAreYou(x) {
while( 1 ) { machine model
print "How are you?"
delay(y);
} Enter X: 1
} Enter Y: 2
Hello world. (Time = 1 s)
PrintHelloWorld
Hello world. (Time = 2 s)
Simple concurrent process example ReadX ReadY How are you? (Time = 2 s)
Hello world. (Time = 3 s)
PrintHowAreYou
How are you? (Time = 4 s)
Hello world. (Time = 4 s)
time ...

Subroutine execution over time Sample input and output

Embedded Systems Design: A Unified 24

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Dataflow model
• Derivative of concurrent process model Z = (A + B) * (C - D)
• Nodes represent transformations
– May execute concurrently A B C D

• Edges represent flow of tokens (data) from one node to another + –

– May or may not have token at any given time t1 t2

• When all of node’s input edges have at least one token, node may *

fire
Z
• When node fires, it consumes input tokens processes Nodes with arithmetic
transformation and generates output token transformations
• Nodes may fire simultaneously A B C D
• Several commercial tools support graphical languages for capture
of dataflow model modulate convolve
t1 t2
– Can automatically translate to concurrent process model for
transform
implementation
– Each node becomes a process Z
Nodes with more complex
transformations

Embedded Systems Design: A Unified 25

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Synchronous dataflow
• With digital signal-processors (DSPs), data flows at fixed rate
• Multiple tokens consumed and produced per firing
• Synchronous dataflow model takes advantage of this A B C D
– Each edge labeled with number of tokens consumed/produced
each firing mA mB mC mD

– Can statically schedule nodes, so can easily use sequential modulate convolve

program model mt1 t1 t2 ct2

• Don’t need real-time operating system and its overhead tt1 tt2
transform
• How would you map this model to a sequential programming
language? Try it... tZ

• Algorithms developed for scheduling nodes into “single- Z

appearance” schedules
Synchronous dataflow
– Only one statement needed to call each node’s associated
procedure
• Allows procedure inlining without code explosion, thus reducing
overhead even more

Embedded Systems Design: A Unified 26

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Concurrent processes and real-time systems

Embedded Systems Design: A Unified 27

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Concurrent processes
• Consider two examples Heartbeat Monitoring System
having separate tasks running Task 1:
Read pulse
Task 2:
If B1/B2 pressed then

independently but sharing If pulse < Lo then Lo = Lo +/– 1

Heart-beat
B[1..4]
Activate Siren If B3/B4 pressed then

pulse
If pulse > Hi then Hi = Hi +/– 1
data Activate Siren
Sleep 1 second
Sleep 500 ms
Repeat
• Difficult to write system Repeat

using sequential program

model
• Concurrent process model
Set-top Box
easier Task 1: Task 2:
Read Signal Wait on Task 1
– Separate sequential Separate Audio/Video Decode/output Audio
Send Audio to Task 2 Repeat

Audio
Video
Signal

programs (processes) for

Input

Send Video to Task 3

Repeat Task 3:
each task Wait on Task 1
Decode/output Video
– Programs communicate with Repeat

each other

Embedded Systems Design: A Unified 28

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Process
• A sequential program, typically an infinite loop
– Executes concurrently with other processes
– We are about to enter the world of “concurrent programming”
• Basic operations on processes
– Create and terminate
• Create is like a procedure call but caller doesn’t wait
– Created process can itself create new processes
• Terminate kills a process, destroying all data
• In HelloWord/HowAreYou example, we only created processes
– Suspend and resume
• Suspend puts a process on hold, saving state for later execution
• Resume starts the process again where it left off
– Join
• A process suspends until a particular child process finishes execution

Embedded Systems Design: A Unified 29

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Communication among processes
• Processes need to communicate data and Encoded video
packets
signals to solve their computation problem processA() {
– Processes that don’t communicate are just // Decode packet
// Communicate packet

independent programs solving separate problems to B

}
}
• Basic example: producer/consumer
– Process A produces data items, Process B consumes
Decoded video
them packets
– E.g., A decodes video packets, B display decoded void processB() {
// Get packet from A

packets on a screen }
// Display packet

• How do we achieve this communication?

– Two basic methods
• Shared memory To display

• Message passing

Embedded Systems Design: A Unified 30

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Shared Memory
• Processes read and write shared variables 01: data_type buffer[N];
02: int count = 0;
– No time overhead, easy to implement 03: void processA() {
04: int i;
– But, hard to use – mistakes are common 05:
06:
while( 1 ) {
produce(&data);
• Example: Producer/consumer with a mistake 07:
08:
while( count == N );/*loop*/
buffer[i] = data;
– Share buffer[N], count 09: i = (i + 1) % N;
10: count = count + 1;
• count = # of valid data items in buffer
11: }
– processA produces data items and stores in buffer 12: }
• 13: void processB() {
If buffer is full, must wait
14: int i;
– processB consumes data items from buffer 15: while( 1 ) {
• If buffer is empty, must wait 16: while( count == 0 );/*loop*/
17: data = buffer[i];
– Error when both processes try to update count concurrently (lines 10 and 19) 18: i = (i + 1) % N;
and the following execution sequence occurs. Say “count” is 3. 19: count = count - 1;
20: consume(&data);
• A loads count (count = 3) from memory into register R1 (R1 = 3) 21: }
• A increments R1 (R1 = 4) 22: }
• B loads count (count = 3) from memory into register R2 (R2 = 3) 23: void main() {
24: create_process(processA);
• B decrements R2 (R2 = 2) 25: create_process(processB);
• A stores R1 back to count in memory (count = 4) 26: }
• B stores R2 back to count in memory (count = 2)
– count now has incorrect value of 2

Embedded Systems Design: A Unified 31

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Message Passing

• Message passing
– Data explicitly sent from one process to void processA() {
while( 1 ) {
another produce(&data)
send(B, &data);
/* region 1 */
• Sending process performs special operation, receive(B, &data);
consume(&data);
send }
}
• Receiving process must perform special
void processB() {
operation, receive, to receive the data while( 1 ) {
receive(A, &data);
• Both operations must explicitly specify which transform(&data)
send(A, &data);
process it is sending to or receiving from }
/* region 2 */

• Receive is blocking, send may or may not be }

blocking
– Safer model, but less flexible

Embedded Systems Design: A Unified 32

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Back to Shared Memory: Mutual Exclusion
• Certain sections of code should not be performed concurrently
– Critical section
• Possibly noncontiguous section of code where simultaneous updates, by multiple
processes to a shared memory location, can occur
• When a process enters the critical section, all other processes must be locked
out until it leaves the critical section
– Mutex
• A shared object used for locking and unlocking segment of shared data
• Disallows read/write access to memory it guards
• Multiple processes can perform lock operation simultaneously, but only one process
will acquire lock
• All other processes trying to obtain lock will be put in blocked state until unlock
operation performed by acquiring process when it exits critical section
• These processes will then be placed in runnable state and will compete for lock again

Embedded Systems Design: A Unified 33

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Correct Shared Memory Solution to the
Consumer-Producer Problem
• The primitive mutex is used to ensure critical sections are 01: data_type buffer[N];
02: int count = 0;
executed in mutual exclusion of each other 03: mutex count_mutex;
04: void processA() {
• Following the same execution sequence as before: 05: int i;
– A/B execute lock operation on count_mutex 06:
07:
while( 1 ) {
produce(&data);
– Either A or B will acquire lock 08: while( count == N );/*loop*/
09: buffer[i] = data;
• Say B acquires it 10: i = (i + 1) % N;
• A will be put in blocked state 11: count_mutex.lock();
12: count = count + 1;
– B loads count (count = 3) from memory into register R2 (R2 13: count_mutex.unlock();
= 3) 14: }
15: }
– B decrements R2 (R2 = 2) 16: void processB() {
17: int i;
– B stores R2 back to count in memory (count = 2) 18: while( 1 ) {
– B executes unlock operation 19:
20:
while( count == 0 );/*loop*/
data = buffer[i];
• A is placed in runnable state again 21: i = (i + 1) % N;
22: count_mutex.lock();
– A loads count (count = 2) from memory into register R1 (R1 23: count = count - 1;
= 2) 24: count_mutex.unlock();
25: consume(&data);
– A increments R1 (R1 = 3) 26: }
– A stores R1 back to count in memory (count = 3) 27:
28:
}
void main() {
• Count now has correct value of 3 29:
30:
create_process(processA);
create_process(processB);
31: }

Embedded Systems Design: A Unified 34

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Process Communication

• Try modeling “req” value of our System interface

elevator controller Unit

Control
up
down

– Using shared memory open

floor
– Using shared memory and mutexes req
Request

– Using message passing Resolver

b1 buttons
inside
... b2 elevator
bN

up1 up/down
up2 buttons
dn2 on each
up3 floor
dn3
...
dnN

Embedded Systems Design: A Unified 35

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 A Common Problem in Concurrent
Programming: Deadlock
• Deadlock: A condition where 2 or more processes are
blocked waiting for the other to unlock critical sections of
code
– Both processes are then in blocked state 01: mutex mutex1, mutex2;
– Cannot execute unlock operation so will wait forever 02: void processA() {
03: while( 1 ) {
• Example code has 2 different critical sections of code that 04:
05:
…
mutex1.lock();
can be accessed simultaneously 06:
07:
/* critical section
mutex2.lock();
1 */

– 2 locks needed (mutex1, mutex2) 08: /* critical section 2 */

09: mutex2.unlock();
– Following execution sequence produces deadlock 10: /* critical section 1 */
11: mutex1.unlock();
• A executes lock operation on mutex1 (and acquires it) 12: }
13: }
• B executes lock operation on mutex2( and acquires it) 14: void processB() {
• A/B both execute in critical sections 1 and 2, respectively 15: while( 1 ) {
16: …
• A executes lock operation on mutex2 17: mutex2.lock();
– 18: /* critical section 2 */
A blocked until B unlocks mutex2 19: mutex1.lock();
• B executes lock operation on mutex1 20: /* critical section 1 */
21: mutex1.unlock();
– B blocked until A unlocks mutex1 22: /* critical section 2 */
• DEADLOCK! 23: mutex2.unlock();
24: }
• One deadlock elimination protocol requires locking of 25: }

numbered mutexes in increasing order and two-phase

locking (2PL)
– Acquire locks in 1st phase only, release locks in 2 nd phase
Embedded Systems Design: A Unified 36
Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Synchronization among processes
• Sometimes concurrently running processes must synchronize their execution
– When a process must wait for:
• another process to compute some value
• reach a known point in their execution
• signal some condition
• Recall producer-consumer problem
– processA must wait if buffer is full
– processB must wait if buffer is empty
– This is called busy-waiting
• Process executing loops instead of being blocked
• CPU time wasted
• More efficient methods
– Join operation, and blocking send and receive discussed earlier
• Both block the process so it doesn’t waste CPU time
– Condition variables and monitors

Embedded Systems Design: A Unified 37

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Condition variables
• Condition variable is an object that has 2 operations, signal and wait
• When process performs a wait on a condition variable, the process is blocked
until another process performs a signal on the same condition variable
• How is this done?
– Process A acquires lock on a mutex
– Process A performs wait, passing this mutex
• Causes mutex to be unlocked
– Process B can now acquire lock on same mutex
– Process B enters critical section
• Computes some value and/or make condition true
– Process B performs signal when condition true
• Causes process A to implicitly reacquire mutex lock
• Process A becomes runnable

Embedded Systems Design: A Unified 38

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Condition variable example:
consumer-producer
• 2 condition variables Consumer-producer using condition variables
– buffer_empty 01: data_type buffer[N];
02: int count = 0;
• Signals at least 1 free location available in buffer 03: mutex cs_mutex;
04: condition buffer_empty, buffer_full;
– buffer_full 06: void processA() {
07: int i;
• Signals at least 1 valid data item in buffer 08: while( 1 ) {
09: produce(&data);
• processA: 10: cs_mutex.lock();
11: if( count == N ) buffer_empty.wait(cs_mutex);
– produces data item 13: buffer[i] = data;
– 14: i = (i + 1) % N;
acquires lock (cs_mutex) for critical section 15: count = count + 1;
– checks value of count 16: cs_mutex.unlock();
17: buffer_full.signal();
– if count = N, buffer is full 18: }
19: }
• performs wait operation on buffer_empty 20: void processB() {
21: int i;
• this releases the lock on cs_mutex allowing 22: while( 1 ) {
processB to enter critical section, consume data 23: cs_mutex.lock();
24: if( count == 0 ) buffer_full.wait(cs_mutex);
item and free location in buffer 26: data = buffer[i];
27: i = (i + 1) % N;
• processB then performs signal 28: count = count - 1;
– 29: cs_mutex.unlock();
if count < N, buffer is not full 30: buffer_empty.signal();
• processA inserts data into buffer 31: consume(&data);
32: }
• increments count 33: }
34: void main() {
• signals processB making it runnable if it has 35: create_process(processA); create_process(processB);
37: }
performed a wait operation on buffer_full

Embedded Systems Design: A Unified 39

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Monitors
• Collection of data and methods or subroutines that
operate on data similar to an object-oriented Monitor
paradigm Monitor
DATA
• Monitor guarantees only 1 process can execute Waiting DATA
inside monitor at a time CODE
CODE

• (a) Process X executes while Process Y has to wait

Process Process
Process Process
X
• (b) Process X performs wait on a condition Y
X Y
– Process Y allowed to enter and execute (a) (b)

Monitor Monitor
• (c) Process Y signals condition Process X waiting on DATA Waiting DATA
– Process Y blocked
CODE CODE
– Process X allowed to continue executing

• (d) Process X finishes executing in monitor or waits

Process Process
on a condition again X Y
Process
X
Process
Y
– Process Y made runnable again (c) (d)

Embedded Systems Design: A Unified 40

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Monitor example: consumer-producer
• Single monitor encapsulates both 01: Monitor {
processes along with buffer and count 02:
03:
data_type buffer[N];
int count = 0;
• One process will be allowed to begin 04:
06:
condition buffer_full, condition buffer_empty;
void processA() {
executing first 07: int i;
08: while( 1 ) {
• If processB allowed to execute first 09: produce(&data);
10: if( count == N ) buffer_empty.wait();
– Will execute until it finds count = 0 12: buffer[i] = data;
13: i = (i + 1) % N;
– Will perform wait on buffer_full condition 14: count = count + 1;
variable 15: buffer_full.signal();
16: }
– processA now allowed to enter monitor 17: }
and execute 18: void processB() {
19: int i;
– processA produces data item 20: while( 1 ) {
21: if( count == 0 ) buffer_full.wait();
– finds count < N so writes to buffer and 23: data = buffer[i];
increments count 24: i = (i + 1) % N;
25: count = count - 1;
– processA performs signal on buffer_full 26: buffer_empty.signal();
condition variable 27: consume(&data);
28: buffer_full.signal();
– processA blocked 29: }
30: }
– processB reenters monitor and continues 31: } /* end monitor */
execution, consumes data, etc. 32: void main() {
33: create_process(processA); create_process(processB);
35: }

Embedded Systems Design: A Unified 41

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Implementation
• Mapping of system’s functionality
The choice of
onto hardware processors: computational
State Sequent. Data- Concurrent model(s) is based
– captured using computational machine program flow processes on whether it
allows the designer
model(s) to describe the
– written in some language(s) system.

• Implementation choice independent The choice of

from language(s) choice Pascal C/C++ Java VHDL
language(s) is
based on whether it
• Implementation choice based on captures the
computational
power, size, performance, timing and model(s) used by
the designer.
cost requirements
• Final implementation tested for The choice of
implementation is
feasibility based on whether it
Implementation A Implementation Implementation meets power, size,
– Also serves as blueprint/prototype for B C performance and
cost requirements.
mass manufacturing of final product

Embedded Systems Design: A Unified 42

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Concurrent process model:
implementation
• Can use single and/or general-purpose processors
• (a) Multiple processors, each executing one process Processor A
Process1
– True multitasking (parallel processing) Processor B
Process2
munication Bus
– General-purpose processors (a) Process3 Processor C
• Use programming language like C and compile to Process4
Processor D
instructions of processor
• Expensive and in most cases not necessary
– Custom single-purpose processors Process1
Process2
• More common General Purpose
(b) Process3 Processor
• (b) One general-purpose processor running all Process4
processes
– Most processes don’t use 100% of processor time
Processor A
– Can share processor time and still achieve necessary
Process1
execution rates
Process2
munication Bus
General
• (c) Combination of (a) and (b) (c) Process3 Purpose
Process4 Processor
– Multiple processes run on one general-purpose
processor while one or more processes run on own
single_purpose processor

Embedded Systems Design: A Unified 43

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Implementation:
multiple processes sharing single processor
• Can manually rewrite processes as a single sequential program
– Ok for simple examples, but extremely difficult for complex examples
– Automated techniques have evolved but not common
– E.g., simple Hello World concurrent program from before would look like:
I = 1; T = 0;
while (1) {
Delay(I); T = T + 1;
if X modulo T is 0 then call PrintHelloWorld
if Y modulo T is 0 then call PrintHowAreYou
}
• Can use multitasking operating system
– Much more common
– Operating system schedules processes, allocates storage, and interfaces to peripherals, etc.
– Real-time operating system (RTOS) can guarantee execution rate constraints are met
– Describe concurrent processes with languages having built-in processes (Java, Ada, etc.) or a sequential
programming language with library support for concurrent processes (C, C++, etc. using POSIX
threads for example)
• Can convert processes to sequential program with process scheduling right in code
– Less overhead (no operating system)
– More complex/harder to maintain

Embedded Systems Design: A Unified 44

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Processes vs. threads
• Different meanings when operating system terminology
• Regular processes
– Heavyweight process
– Own virtual address space (stack, data, code)
– System resources (e.g., open files)
• Threads
– Lightweight process
– Subprocess within process
– Only program counter, stack, and registers
– Shares address space, system resources with other threads
• Allows quicker communication between threads
– Small compared to heavyweight processes
• Can be created quickly
• Low cost switching between threads

Embedded Systems Design: A Unified 45

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Implementation:
suspending, resuming, and joining
• Multiple processes mapped to single-purpose processors
– Built into processor’s implementation
– Could be extra input signal that is asserted when process suspended
– Additional logic needed for determining process completion
• Extra output signals indicating process done

• Multiple processes mapped to single general-purpose processor

– Built into programming language or special multitasking library like POSIX
– Language or library may rely on operating system to handle

Embedded Systems Design: A Unified 46

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Implementation: process scheduling
• Must meet timing requirements when multiple concurrent processes
implemented on single general-purpose processor
– Not true multitasking
• Scheduler
– Special process that decides when and for how long each process is executed
– Implemented as preemptive or nonpreemptive scheduler
– Preemptive
• Determines how long a process executes before preempting to allow another process
to execute
– Time quantum: predetermined amount of execution time preemptive scheduler allows each
process (may be 10 to 100s of milliseconds long)
• Determines which process will be next to run
– Nonpreemptive
• Only determines which process is next after current process finishes execution

Embedded Systems Design: A Unified 47

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Scheduling: priority
• Process with highest priority always selected first by scheduler
– Typically determined statically during creation and dynamically during
execution
• FIFO
– Runnable processes added to end of FIFO as created or become runnable
– Front process removed from FIFO when time quantum of current process is up
or process is blocked
• Priority queue
– Runnable processes again added as created or become runnable
– Process with highest priority chosen when new process needed
– If multiple processes with same highest priority value then selects from them
using first-come first-served
– Called priority scheduling when nonpreemptive
– Called round-robin when preemptive

Embedded Systems Design: A Unified 48

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Priority assignment
• Period of process
– Repeating time interval the process must complete one execution within
• E.g., period = 100 ms
• Process must execute once every 100 ms Rate monotonic
– Usually determined by the description of the system Process Period Priority
• E.g., refresh rate of display is 27 times/sec
A 25 ms 5
• Period = 37 ms B 50 ms 3
• Execution deadline C
D
12 ms 6
100 ms 1
– Amount of time process must be completed by after it has started E 40 ms 4
F 75 ms 2
• E.g., execution time = 5 ms, deadline = 20 ms, period = 100 ms
• Process must complete execution within 20 ms after it has begun regardless of its period
• Process begins at start of period, runs for 4 ms then is preempted Deadline monotonic
• Process suspended for 14 ms, then runs for the remaining 1 ms
Process Deadline Priority
• Completed within 4 + 14 + 1 = 19 ms which meets deadline of 20 ms
• Without deadline process could be suspended for much longer G 17 ms 5
H 50 ms 2
• Rate monotonic scheduling I 32 ms 3
J 10 ms 6
– Processes with shorter periods have higher priority K 140 ms 1
– Typically used when execution deadline = period L 32 ms 4

• Deadline monotonic scheduling

– Processes with shorter deadlines have higher priority
– Typically used when execution deadline < period

Embedded Systems Design: A Unified 49

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Real-time systems
• Systems composed of 2 or more cooperating, concurrent processes with
stringent execution time constraints
– E.g., set-top boxes have separate processes that read or decode video and/or
sound concurrently and must decode 20 frames/sec for output to appear
continuous
– Other examples with stringent time constraints are:
• digital cell phones
• navigation and process control systems
• assembly line monitoring systems
• multimedia and networking systems
• etc.
– Communication and synchronization between processes for these systems is
critical
– Therefore, concurrent process model best suited for describing these systems

Embedded Systems Design: A Unified 50

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Real-time operating systems (RTOS)
• Provide mechanisms, primitives, and guidelines for building real-time embedded systems
• Windows CE
– Built specifically for embedded systems and appliance market
– Scalable real-time 32-bit platform
– Supports Windows API
– Perfect for systems designed to interface with Internet
– Preemptive priority scheduling with 256 priority levels per process
– Kernel is 400 Kbytes
• QNX
– Real-time microkernel surrounded by optional processes (resource managers) that provide POSIX and
UNIX compatibility
• Microkernels typically support only the most basic services
• Optional resource managers allow scalability from small ROM-based systems to huge multiprocessor systems
connected by various networking and communication technologies
– Preemptive process scheduling using FIFO, round-robin, adaptive, or priority-driven scheduling
– 32 priority levels per process
– Microkernel < 10 Kbytes and complies with POSIX real-time standard

Embedded Systems Design: A Unified 51

Hardware/Software Introduction, (c) 2000 Vahid/Givargis
 Summary

• Computation models are distinct from languages

• Sequential program model is popular
– Most common languages like C support it directly
• State machine models good for control
– Extensions like HCFSM provide additional power
– PSM combines state machines and sequential programs
• Concurrent process model for multi-task systems
– Communication and synchronization methods exist
– Scheduling is critical
• Dataflow model good for signal processing
Embedded Systems Design: A Unified 52
Hardware/Software Introduction, (c) 2000 Vahid/Givargis