1Outline u Part 3: Models of Computation s FSMs s Discrete Event Systems s CFSMs s Data Flow Models s Petri Nets s The Tagged Signal Model

2 Design u From an idea… u … build something that performs a certain function u Never done directly: s some aspects are not considered at the beginning of the development s the designer wants to explore different possible implementations in order to maximize (or minimize) a cost function u Models can be used to reason about the properties of an object

3 Formalization Model of a design with precise unambiguous semantics: u Implicit or explicit relations: inputs, outputs and (possibly) state variables u Properties u “Cost” functions u Constraints Formalization of Design + Environment = closed system of equations and inequalities over some algebra.

4 Models of Computation: And There are More... u Continuous time (ODEs) u Spatial/temporal (PDEs) u Discrete time u Rendezvous u Synchronous/Reactive u Dataflow u... Tower of Babel, Bruegel, 1563 Each of these provides a formal framework for reasoning about certain aspects of embedded systems.

5 Model Of Computation Definition: A mathematical description that has a syntax and rules for computation of the behavior described by the syntax (semantics). Used to specify the semantics of computation and concurrency. Examples: Finite State Machine, Turing Machine, differential equation An MoC allows: u To capture unambiguously the required functionality u To verify correctness of the functional specification wrt properties u To synthesize part of the specification u To use different tools (all must “understand” the model) MOC needs to s be powerful enough for application domain s have appropriate synthesis and validation algorithms

6 Usefulness of a Model of Computation u u Expressiveness u u Generality u u Simplicity u u Compilability/ Synthesizability u u Verifiability The Conclusion One way to get all of these is to mix diverse, simple models of computation, while keeping compilation, synthesis, and verification separate for each MoC. To do that, we need to understand these MoCs relative to one another, and understand their interaction when combined in a single system design.

7 Common Models of Computation u Finite State Machines s finite state s no concurrency nor time u Data-Flow s Partial Order s Concurrent and Determinate s Stream of computation u Discrete-Event s Global Order (embedded in time) u Continuous Time The behavior of a design in general is described by a composition

8 Control versus Data Flow u Fuzzy distinction, yet useful for: s specification (language, model,...) s synthesis (scheduling, optimization,...) s validation (simulation, formal verification,...) u Rough classification: s control: t don’t know when data arrive (quick reaction) t time of arrival often matters more than value s data: t data arrive in regular streams (samples) t value matters most

9 Control versus Data Flow u Specification, synthesis and validation methods emphasize: s for control: t event/reaction relation t response time (Real Time scheduling for deadline satisfaction) (Real Time scheduling for deadline satisfaction) t priority among events and processes s for data: t functional dependency between input and output t memory/time efficiency (Dataflow scheduling for efficient pipelining) (Dataflow scheduling for efficient pipelining) t all events and processes are equal

10 Telecom/MM applications u Heterogeneous specifications including s data processing s control functions u Data processing, e.g. encryption, error correction… s computations done at regular (often short) intervals s efficiently specified and synthesized using DataFlow models u Control functions (data-dependent and real-time) s say when and how data computation is done s efficiently specified and synthesized using FSM models u Need a common model to perform global system analysis and optimization

11 12/09/1999 Reactive Real-time Systems u Reactive Real-Time Systems s “React” to external environment s Maintain permanent interaction s Ideally never terminate s timing constraints (real-time) u As opposed to s transformational systems s interactive systems

12 Models Of Computation for reactive systems u We need to consider essential aspects of reactive systems: s time/synchronization s concurrency s heterogeneity u Classify models based on: s how specify behavior s how specify communication s implementability s composability s availability of tools for validation and synthesis

13 Models Of Computation for reactive systems u Main MOCs: s Communicating Finite State Machines s Dataflow Process Networks s Petri Nets s Discrete Event s (Abstract) Codesign Finite State Machines u Main languages: s StateCharts s Esterel s Dataflow networks

14 Finite State Machines u Functional decomposition into states of operation u Typical domains of application: s control functions s protocols (telecom, computers,...) u Different communication mechanisms: s synchronous (classical FSMs, Moore ‘64, Kurshan ‘90) s asynchronous (CCS, Milner ‘80; CSP, Hoare ‘85)

15 FSM Example u Informal specification: If the driver turns on the key, and does not fasten the seat belt within 5 seconds then an alarm beeps for 5 seconds, or until the driver fastens the seat belt, or until the driver turns off the key

16 FSM Example KEY_ON => START_TIMER END_TIMER_5 => ALARM_ON KEY_OFF or BELT _ON => END_TIMER_10 or BELT_ON or KEY_OFF => ALARM_OFF If no condition is satisfied, implicit self-loop in the current state WAIT ALARM OFF

17 FSM Definition  FSM = ( I, O, S, r,  ) s I = { KEY_ON, KEY_OFF, BELT_ON, END_TIMER_5, END_TIMER_10 } s O = { START_TIMER, ALARM_ON, ALARM_OFF } s S = { OFF, WAIT, ALARM } s r = OFF   : 2 I  S  S e.g.  ( { KEY_OFF }, WAIT ) = OFF   : 2 I  S  O e.g.  ( { KEY_ON }, OFF ) = { START_TIMER } Set of all subsets of I (implicit “and”) All other inputs are implicitly absent

18 Non-deterministic FSMs   and  may be relations instead of functions :   2 I  S  S e.g.  ({KEY_OFF, END_TIMER_5}, WAIT) = {{OFF}, {ALARM}}   2 I  S  2 O u Non-determinism can be used to describe: s an unspecified behavior (incomplete specification) s an unknown behavior (environment modeling) implicit “and”implicit “or”

19 u E.g. error checking first partially specified: u Then completed as even parity : u Could be implemented as CRC later NDFSM: incomplete specification BIT or not BIT => BIT or not BIT => ERR BIT or not BIT =>... SYNC => BIT => not BIT => not BIT => ERR... SYNC => not BIT =>... BIT => not BIT => BIT => BIT => ERR 0178 p1p7 d7d1 08

20 12/09/1999 NDFSM: unknown behavior u Modeling the environment u Useful to: s optimize (don’t care conditions) s verify (exclude impossible cases) u E.g. driver model: u Can be refined E.g. introduce timing constraints (minimum reaction time 0.1 s) s0 => KEY_ON or KEY_OFF or BELT_ON

21 NDFSM: time range u Special case of unspecified/unknown behavior, but so common to deserve special treatment for efficiency E.g. delay between 6 and 10 s START => SEC => SEC => END SEC => START => SEC => END SEC => END SEC => END

22 12/09/1999 NDFSMs and FSMs u Formally FSMs and NDFSMs are equivalent (Rabin-Scott construction, Rabin ‘59) u In practice, NDFSMs are often more compact (exponential blowup for determinization) s1 s2 s3 s1 s2,s3 a a b a ca s3 b a s2 c ba s1,s3 c a c

23 Finite State Machines u Advantages: s Easy to use (graphical languages) s Powerful algorithms for t synthesis (SW and HW) t verification u Disadvantages: s Sometimes over-specify implementation (sequencing is fully specified) s Number of states can be unmanageable s Numerical computations cannot be specified compactly (need Extended FSMs)

24 Modeling Concurrency u Need to compose parts described by FSMs u Describe the system using a number of FSMs and interconnect them u How do the interconnected FSMs talk to each other?

25 FSM Composition u Bridle complexity via hierarchy: FSM product yields an FSM u Fundamental hypothesis: all the FSMs change state together ( synchronicity ) u System state = Cartesian product of component states (state explosion may be a problem...) E.g. seat belt control + timer START_TIMER => SEC => END_10_SEC END_5_SEC

26 FSM Composition OFF, 0 WAIT, 1 KEY_ON and START_TIMER => START_TIMER must be coherent WAIT, 2 SEC and not (KEY_OFF or BELT_ON) => OFF, 1 not SEC and (KEY_OFF or BELT_ON) => OFF, 2 SEC and (KEY_OFF or BELT_ON) => Belt Control Timer

27 FSM Composition Given M 1 = ( I 1, O 1, S 1, r 1,      and M 2 = ( I 2, O 2, S 2, r 2,      Find the composition M = ( I, O, S, r,  given a set of constraints of the form: C = { ( o, i 1, …, i n ) : o is connected to i 1, …, i n }

28 FSM Composition  Unconditional product M’ = ( I’, O’, S’, r’,  ’  ’ )  I’ = I 1 U I 2  O’ = O 1 U O 2 s S’ = S 1 x S 2 s r’ = r 1 x r 2   ’ = { ( A 1, A 2, s 1, s 2, t 1, t 2 ) : ( A 1, s 1, t 1 )     and ( A 2, s 2, t 2 )      ’ = { ( A 1, A 2, s 1, s 2, B 1, B 2 ) : ( A 1, s 1, B 1 )    and ( A 2, s 2, B 2 )    u Note:  A 1  I 1, A 2  I 2, B 1  O 1, B 2  O 2 s 2 X U Y = 2 X x 2 Y

29 FSM Composition u Constraint application   = { ( A 1, A 2, s 1, s 2, B 1, B 2 )  ’ : for all ( o, i 1, …, i n )  C o  B 1 U B 2 if and only if i j  A 1 U A 2 for all j } u The application of the constraint rules out the cases where the connected input and output have different values (present/absent).

30 FSM Composition I = I 1  I 2 O = O 1  O 2 S = S 1  S 2 Assume that o 1  O 1, i 3  I 2, o 1 = i 3 (communication)  and  are such that, e.g., for each pair:   1 ( { i 1 }, s 1 ) = t 1, 1 ( { i 1 }, s 1 ) = { o 1 }   2 ( { i 2, i 3 }, s 2 ) = t 2, 2 ( { i 2, i 3 }, s 2 ) = { o 2 } we have:   ( { i 1, i 2, i 3 }, ( s 1, s 2 ) ) = ( t 1, t 2 )  ( { i 1, i 2, i 3 }, ( s 1, s 2 ) ) = { o 1, o 2 } i.e. i 3 is in input pattern iff o 2 is in output pattern FSM 1 FSM 2 i1i1 i2i2 i3i3 o1o1 o2o2

31 FSM Composition u Problem: what if there is a cycle?  Moore machine:  depends on input and state, only on state + composition is always well-defined  Mealy machine:  and depend on input and state + composition may be undefined  what if 1 ( { i 1 }, s 1 ) = { o 1 } but o 2  2 ( { i 3 }, s 2 ) ? u Causality analysis in Mealy FSMs (Berry ‘98) FSM 1 FSM 2 i1i1 i3i3 o1o1 o2o2

32 Moore vs. Mealy u Theoretically, same computational power (almost) u In practice, different characteristics u Moore machines: s non-reactive (response delayed by 1 cycle) s easy to compose (always well-defined) s good for implementation t software is always “slow” t hardware is better when I/O is latched

33 Moore vs. Mealy u Mealy machines: s reactive (0 response time) s hard to compose (problem with combinational cycles) s problematic for implementation t software must be “fast enough” (synchronous hypothesis) t may be needed in hardware, for speed

34 Hierarchical FSM models u Problem: how to reduce the size of the representation? u Harel’s classical papers on StateCharts (language) and bounded concurrency (model): 3 orthogonal exponential reductions u Hierarchy: s state a “encloses” an FSM s being in a means FSM in a is active s states of a are called OR states s used to model pre-emption and exceptions u Concurrency: s two or more FSMs are simultaneously active s states are called AND states u Non-determinism: s used to abstract behavior error a recovery odd even done a1a2

35 Models Of Computation for reactive systems u Main MOCs: s Communicating Finite State Machines s Dataflow Process Networks s Petri Nets s Discrete Event s Codesign Finite State Machines u Main languages: s StateCharts s Esterel s Dataflow networks

36 StateCharts u An extension of conventional FSMs u Conventional FSMs are inappropriate for the behavioral description of complex control t flat and unstructured t inherently sequential in nature u StateCharts supports repeated decomposition of states into sub- states in an AND/OR fashion, combined with a synchronous (instantaneous broadcast) communication mechanism

37 State Decomposition u OR-States have sub-states that are related to each other by exclusive-or u AND-States have orthogonal state components (synchronous FSM composition) s AND-decomposition can be carried out on any level of states (more convenient than allowing only one level of communicating FSMs) u Basic States have no sub-states (bottom of hierarchy) u Root State : no parent states (top of hierarchy)

38 StateChart OR-decomposition S V T S V T f f f e h e h gg To be in state U the system must be either in state S or in state T U

39 StateChart AND-decomposition V,W V.Y V,Z V W X X,Y X,W X.Z R Q Z Y U R Q ST k e e e k To be in state U the system must be both in states S and T

40 StateCharts Syntax u The general syntax of an expression labeling a transition in a StateChart is e[c]/a,where s e is the event that triggers the transition s c is the condition that guards the transition (cannot be taken unless c is true when e occurs) s a is the action that is carried out if and when the transition is taken u For each transition label: s event condition and action are optional s an event can be the changing of a value s standard comparisons are allowed as conditions and assignment statements as actions

41 StateCharts Actions and Events u An action a on the edge leaving a state may also appear as an event triggering a transition going into an orthogonal state: s a state transition broadcasts an event visible immediately to all other FSMs, that can make transitions immediately and so on s executing the first transition will immediately cause the second transition to be taken simultaneously u Actions and events may be associated to the execution of orthogonal components : start(A), stopped(B)

42 Graphical Hierarchical FSM Languages u Multitude of commercial and non-commercial variants: s StateCharts, UML, StateFlow, … u Easy to use for control-dominated systems u Simulation (animated), SW and HW synthesis u Original StateCharts have problems with causality loops and instantaneous events: + circular dependencies can lead to paradoxes + behavior is implementation-dependent + not a truly synchronous language + Hierarchical states necessary for complex reactive system specification

43 Synchronous vs. Asynchronous FSMs u Synchronous (Esterel, StateCharts): s communication by shared variables that are read and written in zero time s communication and computation happens instantaneously at discrete time instants s all FSMs make a transition simultaneously (lock-step) s may be difficult to implement t multi-rate specifications t distributed/heterogeneous architectures

44 Synchronous vs. Asynchronous FSMs u A-synchronous FSMs: s free to proceed independently s do not execute a transition at the same time (except for CSP rendezvous) s may need to share notion of time: synchronization s easy to implement

45 Synchronization Base station - Base station Base station - Mobile stations Base station - Mobile station

46Handover u A Mobile Station moving across the cell boundary needs to maintain active connections without interruptions or degradations u Handover s tight inter-base-station synchronization (in GSM achieved using GPS) s asynchronous base station operation (UMTS)

47 Frame Synchronization u Medium Access Control Layer: TDMA s each active connection is assigned a number of time slots (channel) u A common notion of time is needed s each Base Station sends a frame synchronization pilot (FS) at the beginning of every frame to ensure that all Mobile Stations have the same slot counts FS

48 Bit Synchronization u Transmitter interleaves the payload data with a pilot sequence known by the receiver u Receiver extracts the clock from the pilot sequence and uses it to sample the payload data. PSPDPSPD... RX

49 Asynchronous communication u Blocking vs. non-Blocking s Blocking read t process can not test for emptiness of input t must wait for input to arrive before proceed s Blocking write t process must wait for successful write before continue s blocking write/blocking read (CSP, CCS) s non-blocking write/blocking read (FIFO, CFSMs, SDL) s non-blocking write/non-blocking read (shared variables) AB

50 Asynchronous communication u Buffers used to adapt when sender and receiver have different rate s what size? u Lossless vs. lossy s events/tokens may be lost s bounded memory: overflow or overwriting s need to block the sender u Single vs. multiple read s result of each write can be read at most once or several times AB

51 Communication Mechanisms u Rendez-Vous (CSP) s No space is allocated for the data, processes need to synchronize in some specific points to exchange data s Read and write occur simultaneously u FIFO s Bounded (ECFSMs, CFSMs) s Unbounded (SDL, ACFSMs, Kahn Process Networks, Petri Nets) u Shared memory s Multiple non-destructive reads are possible s Writes delete previously stored data

52 Communication models Unsynchronized Read-Modify-write Unbounded FIFO Bounded FIFO Single Rendezvous Multiple Rendezvous Transmitters many one many Receivers many one many Buffer Size one unbounded bounded one Blocking Reads no yes no yes no Blocking Writes no yes no maybe yes no Single Reads no yes