Transcript No Slide Title

CMP502 – Embedded Systems
Models of Computation
CMP502 - Embedded Systems
Outline
1. Introduction
2. Continuous Time
3. Discrete Event
4. Discrete Time
5. Synchronous / Reactive
6. Example: An Elevator Controller
7. Finite State Machines
8. Communicating Sequential Processes
9. Dataflow
10. Petri nets
11. Example of heterogeneous modeling
CMP502 - Embedded Systems
1. Introduction
• embedded systems have architectures that combine
different types of components
– dedicated hardware – digital and analog
– software for different application domains – control, signal
processing
– different types of processors – RISC, DSP, VLIW
– multiprocessors running concurrent tasks
• function of each component / system can be better
described by an appropriate Model of Computation
• heterogeneous descriptions may be necessary
CMP502 - Embedded Systems
Introduction
• MoCs have different ways to describe ...
– concurrency
– communication (and synchronization)
– time
– composition, hierarchy
– primitive behavior (sequential, parallel)
• imperative, declarative commands
• some models can be formally manipulated
– transformations, for synthesis
– proofs (properties, equivalences), for formal verification
CMP502 - Embedded Systems
Properties of models
• properties that are inherent in the MoC
– they hold for all specifications described using that MoC
• properties that can be verified syntactically for a given
specification
– they can be shown to hold with a simple analysis
• properties that must be verified semantically for a given
specification
– they can be shown to hold by executing, at least implicitly, the
specification for all inputs that can occur
CMP502 - Embedded Systems
Models vs. languages
Poetry
Recipe
Story
State
machine
Sequent.
program
Dataflow
English
Spanish
Japanese
C
C++
Java
Models
Languages
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, state machine model
• certain languages better at capturing certain computation models
© Vahid/Givargis 2000
CMP502 - Embedded Systems
2. Continuous time
• outputs related to inputs by linear or nonlinear algebraic
or differential equations as a function of time
• useful for modeling physical systems, analog circuits,
MEMS, mechanical systems, interaction with the
environment
• needs differential equations solvers
• mixed-signal modeling: continuous time + digital domains
• languages: Simulink, VHDL-AMS
CMP502 - Embedded Systems
3. Discrete event
• signal is a sequence of events, tagged with time stamps
• actions are attached to events
• semantics: time stamps define a global ordering of events
– events with the earliest time stamps are processed first
– events seen by any component have monotonically increasing time
stamps
• embodied in languages as VHDL and Verilog
• most efficient for large systems, with frequently idle or
autonomously operating sections
• becomes expensive as the system activity increases
– sorting of time stamps may be computationally costly
– global ordering of events is challenging in a distributed model
CMP502 - Embedded Systems
Discrete event
• other problems
– handling of simultaneous events
– zero-delay feedback loops
• example
– B is a zero-delay component
– after A fires, both B and C have tokes at their inputs and may be invoked
– the behavior of C can change if B is invoked first
A
B
A fires
C
A
B
C
B fires
C has two tokens at the inputs
Does C fire once or twice?
• simulators that leave the situation ambiguous are non-determinate
• possible solution: infinitesimal delay
– if B has an infinitesimal delay, its output tokens have different time stamps
CMP502 - Embedded Systems
4. Discrete time (or synchronous)
• events occur synchronously, according to a clock
• totally ordered model: events are unambiguously either
simultaneous or one precedes the other
• differently from the discrete event model, all signals have
events at all clock ticks
– sorting is not required, model is computationally simpler
– simulators are cycle-based
• multirate systems are a variation where every n-th event in
one signal aligns with the events in another
– excellent for clocked synchronous systems
– inefficient where events occur irregularly
CMP502 - Embedded Systems
5. Synchronous / Reactive
• generalizes the multirate discrete-time model without
paying the price of a discrete-event model
• system = concurrently-executing synchronized modules
• modules communicate through signals that are either
present or absent in each clock tick
– signal is a sequence of events that is aligned with a clock
• clock defines a global ordering of events
– two events are either simultaneous (share the same clock tick) or
one precedes the other
• modules are reactive because they only compute and
produce output events in instants with at least one input
event
• examples of languages: Esterel, Signal, Lustre
CMP502 - Embedded Systems
6. Example: an elevator controller
• simple elevator controller
– Request Resolver resolves various floor
requests into single requested floor
– Unit Control moves elevator to this
requested floor
“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…”
© Vahid/Givargis 2000
System interface
up
down
open
Unit
Control
floor
req
Request
Resolver
...
...
b1
b2
bN
up1
up2
dn2
up3
dn3
buttons
inside
elevator
up/down
buttons
on each
floor
dnN
CMP502 - Embedded Systems
Elevator controller using a 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);
}
}
© Vahid/Givargis 2000
void RequestResolver()
{
while (1)
...
req = ...
...
}
void main()
{
Call concurrently:
UnitControl() and
RequestResolver()
}
CMP502 - Embedded Systems
7. Finite State Machines
• 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)
CMP502 - Embedded Systems
Finite-state machine (FSM) model
• trying to capture the behavior of the elevator controller 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)
© Vahid/Givargis 2000
CMP502 - Embedded Systems
Finite-state machine (FSM) model
UnitControl process using an FSM
req > floor
u,d,o, t = 1,0,0,0
GoingUp
!(req > floor)
timer < 10
req > floor
u,d,o,t = 0,0,1,0
req == floor
u,d,o,t = 0,1,0,0
!(timer < 10)
Idle
DoorOpen
u,d,o,t = 0,0,1,1
req < floor
GoingDn
!(req<floor)
u is up, d is down, o is open
req < floor
© Vahid/Givargis 2000
t is timer_start
CMP502 - Embedded Systems
FSM with datapath model (FSMD)
• FSMD : 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
• I,O,V may represent complex data types (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
© Vahid/Givargis 2000
CMP502 - Embedded Systems
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
© Vahid/Givargis 2000
CMP502 - Embedded Systems
Capturing state machines in
sequential programming languages
• despite benefits of FSM model, 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 installed to support state machine language
• automatically generates code in sequential programming language
• drawback: must support additional tool (licensing costs, upgrades,
training, etc.)
– most common approach: language subset
© Vahid/Givargis 2000
CMP502 - Embedded Systems
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 = …;}
© Vahid/Givargis 2000
#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;
}
}
}
CMP502 - Embedded Systems
Dealing with FSM drawbacks
• FSM’s are impractical for modeling concurrency or
memory because of state explosion
– single machine mimicking the concurrent execution of a group of
machines has a number of states equal to the product of the
number of states of each machine
– memory has as many states as number of values that can be stored
at each location raised to the power of the number of locations
• solutions that reduce exponentially the number of states
– hierarchy: state represents an enclosed state machine
• being in state A means that the machine is in one of the states enclosed
by A (OR states)
• modeling the notion of preemption
– concurrency: two or more states are simultaneously active (AND
states)
– nondeterminism: reduce complexity by abstraction
© Vahid/Givargis 2000
CMP502 - Embedded Systems
Hierarchical and concurrent FSM’s
• hierarchical / concurrent state
machine model (HCFSM)
– extension to FSM 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
Without hierarchy
A
z
A1
x
With hierarchy
y
w
A2
B
x
z
Concurrency
B
• known as AND-decomposition
– graphical language to capture
HCFSM
© Vahid/Givargis 2000
y w
A2
– states can execute concurrently
• Statecharts
z
A1
C
D
C1
x
D1
y
C2
u
v
D2
CMP502 - Embedded Systems
B
UnitControl with FireMode
req>floor
u,d,o = 1,0,0
u,d,o = 0,0,1
req==floor
u,d,o = 0,1,0
UnitControl
GoingUp
!(req>floor)
req>floor
timeout(10)
Idle
DoorOpen
fire
fire
req<floor
!(req<floor)
fire
FireGoingDn
GoingDn
fire
floor>1
req<floor
!fire
u,d,o = 0,0,1
u,d,o = 0,1,0
floor==1 u,d,o = 0,0,1
FireDrOpen
FireMode
– when fire is true, move elevator
to 1st floor and open door
– w/o hierarchy: getting messy!
– w/ hierarchy: simple
With hierarchy
fire
Without hierarchy
UnitControl
NormalMode
req>floor
u,d,o = 1,0,0
ElevatorController
UnitControl
u,d,o = 0,0,1
RequestResolver
NormalMode
...
!fire
fire
GoingUp
Idle
req==floor
u,d,o = 0,1,0
!(req>floor)
req>floor
req<floor
GoingDn
timeout(10)
!(req>floor)
fire
!fire
© Vahid/Givargis 2000
u,d,o = 0,0,1
req<floor
FireMode
With concurrent RequestResolver
DoorOpen
FireMode
u,d,o = 0,1,0
FireGoingDn
floor==1 u,d,o = 0,0,1
floor>1
FireDrOpen
fire
CMP502 - Embedded Systems
Program-state machine model (PSM): HCFSM
plus sequential program model
•
program-state’s actions can be FSM or
sequential program
– designer can choose most appropriate
•
stricter hierarchy than HCFSM used in
Statecharts
– transition between sibling states only, single
entry
– program-state may “complete”
• reaches end of sequential program code, OR
• FSM transition to special complete substate
– PSM has 2 types of transitions
• transition-immediately (TI): taken
regardless of source program-state
•
• transition-on-completion (TOC): taken only
if condition is true AND source program•
state is complete
•
•
SpecCharts: extension of VHDL to capture
PSM model
SpecC: extension of C to capture PSM model
ElevatorController
int req;
UnitControl
NormalMode
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);
}
}
!fire
RequestResolver
...
req = ...
...
fire
FireMode
up = 0; down = 1; open = 0;
while (floor > 1);
up = 0; down = 0; open = 1;
NormalMode and FireMode described as
sequential programs
black square originating within FireMode
indicates !fire is a TOC transition
–
transition from FireMode to NormalMode
only after FireMode completed
CMP502 - Embedded Systems
© Vahid/Givargis 2000
8. Communicating sequential 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
© Vahid/Givargis 2000
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
CMP502 - Embedded Systems
Video
Audio
Communication among processes
• processes need to communicate data and signals to solve their
computation problem
– processes that don’t communicate are just independent programs
solving separate problems
• basic example: producer/consumer
– e.g., A decodes video packets, B displays decoded packets on a screen
• how do we achieve this communication?
– two basic methods
• shared memory
• message passing
encoded
video
packets
processA() {
// Decode packet
// Send packet to B
}
}
© Vahid/Givargis 2000
decoded
video
packets
void processB() {
// Get packet from A
// Display packet
}
to display
CMP502 - Embedded Systems
Shared memory
•
•
processes read and write shared variables
– no time overhead, easy to implement
– but, hard to use – mistakes are common
example: producer/consumer with a mistake
–
–
–
–
–
•
share buffer[N], count
• count = # of valid data items in buffer
processA produces data items and stores in buffer
• if buffer is full, must wait
processB consumes data items from buffer
• if buffer is empty, must wait
error when both processes try to update count concurrently
(lines 10 and 19)
• count has initial value 3
• A loads count = 3 from memory into R1 (R1 = 3)
• A increments R1 => 4
• B loads count = 3 from memory into R2 (R2 = 3)
• B decrements R2 => 2
• A stores R1 back to count in memory (count = 4)
• B stores R2 back to count in memory (count = 2)
count now has incorrect value of 2
solution: critical section, mutual exclusion
01:
02:
03:
04:
05:
06:
07:
08:
09:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
data_type buffer[N];
int count = 0;
void processA() {
int i;
while( 1 ) {
produce(&data);
while(count == N);/*loop*/
buffer[i] = data;
i = (i + 1) % N;
count = count + 1;
}
}
void processB() {
int i;
while( 1 ) {
while(count == 0);/*loop*/
data = buffer[i];
i = (i + 1) % N;
count = count - 1;
consume(&data);
}
}
void main() {
create_process(processA);
create_process(processB);
}
CMP502 - Embedded Systems
© Vahid/Givargis 2000
Message passing
• data explicitly sent from one process to
another
– sending process performs special operation,
send
– receiving process must perform special
operation, receive, to receive the data
– both operations must explicitly specify
which process it is sending to or receiving
from
– receive is blocking, send may or may not be
blocking
• safer model, but less flexible
© Vahid/Givargis 2000
void processA() {
while( 1 ) {
produce(&data)
send(B, &data);
/* region 1 */
receive(B, &data);
consume(&data);
}
}
void processB() {
while( 1 ) {
receive(A, &data);
transform(&data)
send(A, &data);
/* region 2 */
}
}
CMP502 - Embedded Systems
9. Dataflow model
•
•
derivative of concurrent process model
nodes represent transformations
– may execute concurrently
•
Z = (A + B) * (C - D)
A
edges represent flow of tokens (streams of data) from
one node to another
B C
+
•
•
•
when all of node’s input edges have at least one
token, node may fire
when node fires, it consumes input tokens, processes
transformation and generates output token
nodes may fire simultaneously
several commercial tools support graphical
languages for capture of dataflow model
– can automatically translate to concurrent process
model for implementation
– each node becomes a process
© Vahid/Givargis 2000
–
t1 t2
*
– may or may not have token at any given time
•
D
Z
Nodes with arithmetic
transformations
A
B C
modulate
D
convolve
t1 t2
transform
Z
Nodes with more complex
transformations
CMP502 - Embedded Systems
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
– each edge labeled with # of tokens consumed/produced at each firing
can statically schedule nodes, so can easily use sequential program model
– possible if one cycle through the schedule returns the graph to its original
state (same number of tokens in each arc after the cycle as before)
– doesn’t need RTOS and its overhead
algorithms developed for scheduling nodes into “single-appearance” schedules
– only one statement needed to call each node’s associated procedure
• allows procedure inlining without code explosion, reducing overhead even more
dataflow graph
static scheduling
CMP502 - Embedded Systems
Kahn process networks
Kahn
process
networks
Dataflow
process
networks
variants of dataflow models
• concurrent processes communicate by passing streams of data tokens
through unidirectional, unbounded FIFO channels
• writes to the channel are non-blocking and succeed immediately
• reads block until there is sufficient data in the channel
• process cannot test an input channel for availability of data and then
branch conditionally, because testing is a read
• this restriction assures that the program is determinate: outputs are
entirely determined by the inputs and aspects of the program specified
by the programmer
CMP502 - Embedded Systems
10. Petri nets
• transitions, places, firings, tokens, marking
• interesting for very different classes of problems
– process control, asynchronous communication, scheduling, etc.
• large body of theoretical results
– reachability, deadlocks, liveness
– many questions can be answered in finite time
• many variants, for reducing number of transitions
– colored, timed, hierarchical, valued, etc.
CMP502 - Embedded Systems
11. Example of heterogeneous model
• benchmark for specification of heterogeneous systems
• physical plant: crane with a load, moving along a track
• control
– assures smooth movement, without bumps and oscillations
– verifies if displacement does not exceed limits and if angle of the
load is acceptable (emergency break)
– auto-test of sensors
CMP502 - Embedded Systems
First modeling of the crane
physical plant
controls car movement,
sensor checking,
output forces to Actuators
drives the dc motor (speed),
control breaks and
emergency break
checks plausibility of car
position and load angle
CMP502 - Embedded Systems
First modeling of the crane
• physical plant Plant_rk is an object with continuous
behavior
• all other objects have discrete behavior
• M_Control combines two computation models
– control algorithm for movement is a discrete computation of the
state-variable method
q n+1=A*q n + B*[Motor_Voltage Car_Position]T at each 10 ms
– sensor checking is an FSM
• Diagnosis is an FSM
• Actuators is a sequential algorithm
CMP502 - Embedded Systems
References
•
•
•
Chang, Kalavade and Lee. Effective Heterogeneous Design and Co-simulation.
NATO Advanced Study Institute Workshop, 1995.
Edwards, Lavagno, Lee and Sangiovanni-Vincentelli. Design of Embedded
Systems: Formal Models, Validation, and Synthesis. Proceedings of the IEEE,
Vol. 85, No. 3, March 1997. pp 366-390
Vahid and Givardis. Embedded System Design: A Unified Hardware/Software
Introduction. John Wiley & Sons, 2002. Slides available at
http://www.cs.ucr.edu/content/esd/
CMP502 - Embedded Systems