CMP 502 Embedded Systems Models of Computation CMP
CMP 502 – Embedded Systems Models of Computation CMP 502 - 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 CMP 502 - 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 CMP 502 - Embedded Systems
Introduction • Mo. Cs 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), formal verification CMP 502 - Embedded Systems
Properties of models • properties that are inherent in the Mo. C – they hold for all specifications described using that Mo. C • 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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. . . b 1 b 2 b. N up 1 up 2 dn 2 up 3 dn 3 buttons inside elevator up/down buttons on each floor dn. N CMP 502 - Embedded Systems
Elevator controller using a sequential program model Inputs: int floor; bit b 1. . b. N; up 1. . up. N-1; dn 2. . dn. N; Outputs: bit up, down, open; Global variables: int req; void Unit. Control() { 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 Request. Resolver() { while (1). . . req =. . . } void main() { Call concurrently: Unit. Control() and Request. Resolver() } CMP 502 - Embedded Systems
7. Finite State Machines • an FSM is a 6 -tuple F<S, I, O, F, H, s 0> – – – S is a set of all states {s 0, s 1, …, sl} I is a set of inputs {i 0, i 1, …, im} O is a set of outputs {o 0, o 1, …, on} F is a next-state function (S x I → S) H is an output function (S → O) s 0 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) CMP 502 - 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, Going. Up, Going. Dn, Door. Open – possible transitions from one state to another based on input • e. g. , req > floor – actions that occur in each state • e. g. , in the Going. Up state u, d, o, t = 1, 0, 0, 0 (up = 1, down, open, and timer_start = 0) © Vahid/Givargis 2000 CMP 502 - Embedded Systems
Finite-state machine (FSM) model Unit. Control process using an FSM req > floor u, d, o, t = 1, 0, 0, 0 Going. Up !(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 Door. Open u, d, o, t = 0, 0, 1, 1 req < floor Going. Dn !(req<floor) u is up, d is down, o is open req < floor © Vahid/Givargis 2000 t is timer_start CMP 502 - 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, s 0> – – – – S is a set of states {s 0, s 1, …, sl} I is a set of inputs {i 0, i 1, …, im} O is a set of outputs {o 0, o 1, …, on} V is a set of variables {v 0, v 1, …, vn} F is a next-state function (S x I x V → S) H is an action function (S → O + V) s 0 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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 Unit. Control 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 IDLE 0 #define GOINGUP 1 #define GOINGDN 2 #define DOOROPEN 3 void Unit. Control() { 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; } } } CMP 502 - 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 CMP 502 - 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 A 1 x With hierarchy y w A 2 B x z Concurrency B • known as AND-decomposition – graphical language to capture HCFSM © Vahid/Givargis 2000 y w A 2 – states can execute concurrently • Statecharts z A 1 C D C 1 x D 1 y C 2 u v D 2 CMP 502 - Embedded Systems B
Unit. Control with Fire. Mode req>floor u, d, o = 1, 0, 0 u, d, o = 0, 0, 1 req==floor u, d, o = 0, 1, 0 Unit. Control Going. Up !(req>floor) req>floor timeout(10) Idle Door. Open fire req<floor !(req<floor) fire Fire. Going. Dn 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 Fire. Dr. Open Fire. Mode – when fire is true, move elevator to 1 st floor and open door – w/o hierarchy: getting messy! – w/ hierarchy: simple With hierarchy fire Without hierarchy Unit. Control Normal. Mode req>floor u, d, o = 1, 0, 0 Elevator. Controller Unit. Control u, d, o = 0, 0, 1 Request. Resolver Normal. Mode. . . !fire Going. Up Idle req==floor u, d, o = 0, 1, 0 !(req>floor) req>floor req<floor Going. Dn timeout(10) !(req>floor) fire !fire © Vahid/Givargis 2000 u, d, o = 0, 0, 1 req<floor Fire. Mode With concurrent Request. Resolver Door. Open Fire. Mode u, d, o = 0, 1, 0 Fire. Going. Dn floor==1 u, d, o = 0, 0, 1 floor>1 Fire. Dr. Open fire CMP 502 - 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 • • Spec. Charts: extension of VHDL to capture PSM model Spec. C: extension of C to capture PSM model © Vahid/Givargis 2000 Elevator. Controller int req; Unit. Control Normal. Mode 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 Request. Resolver. . . req =. . . fire Fire. Mode up = 0; down = 1; open = 0; while (floor > 1); up = 0; down = 0; open = 1; Normal. Mode and Fire. Mode described as sequential programs black square originating within Fire. Mode indicates !fire is a TOC transition – transition from Fire. Mode to Normal. Mode only after Fire. Mode completed CMP 502 - Embedded Systems
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 B 1/B 2 pressed then Lo = Lo +/– 1 If B 3/B 4 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 CMP 502 - 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 process. A() { // Decode packet // Send packet to B } } © Vahid/Givargis 2000 decoded video packets void process. B() { // Get packet from A // Display packet } to display CMP 502 - 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 process. A produces data items and stores in buffer • if buffer is full, must wait process. B 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 R 1 (R 1 = 3) • A increments R 1 => 4 • B loads count = 3 from memory into R 2 (R 2 = 3) • B decrements R 2 => 2 • A stores R 1 back to count in memory (count = 4) • B stores R 2 back to count in memory (count = 2) count now has incorrect value of 2 solution: critical section, mutual exclusion © Vahid/Givargis 2000 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 process. A() { int i; while( 1 ) { produce(&data); while(count == N); /*loop*/ buffer[i] = data; i = (i + 1) % N; count = count + 1; } } void process. B() { int i; while( 1 ) { while(count == 0); /*loop*/ data = buffer[i]; i = (i + 1) % N; count = count - 1; consume(&data); } } void main() { create_process(process. A); create_process(process. B); } CMP 502 - Embedded Systems
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 process. A() { while( 1 ) { produce(&data) send(B, &data); /* region 1 */ receive(B, &data); consume(&data); } } void process. B() { while( 1 ) { receive(A, &data); transform(&data) send(A, &data); /* region 2 */ } } CMP 502 - 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 – t 1 t 2 * – may or may not have token at any given time • D Z Nodes with arithmetic transformations A B C modulate D convolve t 1 t 2 transform Z Nodes with more complex transformations CMP 502 - 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 CMP 502 - Embedded Systems
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 CMP 502 - 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. CMP 502 - 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 CMP 502 - 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 CMP 502 - 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 CMP 502 - 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/ CMP 502 - Embedded Systems
- Slides: 36