1. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 1 Hardware/Software Codesign of Embedded Systems SYSTEM MODELS Voicu Groza SITE Hall, Room 5017 562 5800 ext. 2159 Groza@SITE.uOttawa.ca

2. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 2 SPECIFICATIONS After Peter Marwedel, Univ. Dortmund, Germany

3. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 3 Specifications After Peter Marwedel, Univ. Dortmund, Germany

4. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 4 Specification of embedded systems: Requirements for specification techniques (1) –Hierarchy Humans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects  Hierarchy Behavioral hierarchy Examples: states, processes, procedures. Structural hierarchy Examples: processors, racks, printed circuit boards proc After Peter Marwedel, Univ. Dortmund, Germany

5. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 5 Specification of embedded systems: Requirements for specification techniques (2) –Timing behavior. State-oriented behavior Required for reactive systems; classical automata insufficient. –Event-handling (external or internal events) –No obstacles for efficient implementation After Peter Marwedel, Univ. Dortmund, Germany

6. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 6 Requirements for specification techniques (3) –Support for the design of dependable systems Unambiguous semantics,... –Exception-oriented behavior Not acceptable to describe exceptions for every state. We will see, how all the arrows labeled k can be replaced by a single one.. After Peter Marwedel, Univ. Dortmund, Germany

7. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 7 Requirements for specification techniques (4) –Concurrency Real-life systems are concurrent –Synchronization and communication Components have to communicate! –Presence of programming elements For example, arithmetic operations, loops, and function calls should be available –Executability (no algebraic specification) –Support for the design of large systems (  OO) –Domain-specific support After Peter Marwedel, Univ. Dortmund, Germany

8. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 8 Requirements for specification techniques (5) –Readability –Portability and flexibility –Termination It should be clear, at which time all computations are completed –Support for non-standard I/O devices Direct access to switches, displays,... –Non-functional properties fault-tolerance, disposability, EMC-properties, weight, size, user friendliness, extendibility, expected life time, power consumption... –Adequate model of computation After Peter Marwedel, Univ. Dortmund, Germany

9. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 9 Models of computation - Definition - Models of computation define: –Components and an execution model for computations for each component –Communication model for exchange of information between components. Message passing? Rendez-vous? See also  Work by Ed Lee, UCB  Axel Jantsch: Modeling Embedded Systems and Soc's: Concurrency and Time in Models of Computation, Morgan-Kaufman, 2004 After Peter Marwedel, Univ. Dortmund, Germany

10. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 10 Components (1)  Discrete event model abcabc time action a:=5 b:=7 c:=8 a:=6 a:=9 queue 5 10 13 15 19 5 7 8 6  Von Neumann model Sequential execution, program memory etc. After Peter Marwedel, Univ. Dortmund, Germany

11. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 11 Components (2) –Finite state machines –Differential equations After Peter Marwedel, Univ. Dortmund, Germany

12. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 12 Communication Asynchronous message passing  Shared memory Synchronous message passing –Message passing Transmission of messages over channels memoryComp-1Comp-2 After Peter Marwedel, Univ. Dortmund, Germany

13. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 13 Combined models - languages presented later in this chapter - –SDL (Synchronous data Flow, 1987) FSM+synchronous message passing –StateCharts FSM+shared memory –CSP (Communicating Sequential Processes – Hoare, 1985), ADA von Neumann execution+synchronous message passing –…. After Peter Marwedel, Univ. Dortmund, Germany

14. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 14 Problems with thread-based concurrency “Even the core … notion of “computable” is at odds with the requirements of embedded software. In this notion, useful computation terminates, but termination is undecidable. In embedded software, termination is failure, and yet to get predictable timing, subcomputations must decidably terminate. The lack of timing in the core abstraction is a flaw, from the perspective of embedded software, and threads as a concurrency model are a poor match for embedded systems. … they work well only … where best-effort scheduling policies are sufficient. What is needed is nearly a reinvention of computer science.” Ed Lee: Absolutely Positively on Time, IEEE Computer, July, 2005  Ptolemy simulations  Search for non-thread-based, non-von-Neumann MoCs After Peter Marwedel, Univ. Dortmund, Germany

15. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 15 Ptolemy Ptolemy (UC Berkeley) is an environment for simulating multiple models of computation. Available examples are restricted to a subset of the supported models of computation. http://ptolemy.berkeley.edu/ After Peter Marwedel, Univ. Dortmund, Germany

16. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 16 Facing reality No language that meets all language requirements  using compromises After Peter Marwedel, Univ. Dortmund, Germany

17. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 17 CONCEPTUAL MODELS System Specification Models Finite State Machines (FSM) Algorithmic State Machines (ASM) Non-deterministic FSM (NDFSM) Extended FSM Codesign FSM

18. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 18 System Specification Models Formal system consisting of objects & composition rules, used for describing a system ’ s characteristics A model provides: –clear and unambiguous description of the system function –documentation of the initial design process –no constraints to the implementation –easy application of Computer Aided Design (design space exploration, partitioning, synthesis, validation, testing) A model has to be –complete –comprehensible to designers (natural)

19. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 19 Models and Architectures Highest level of abstraction of a system: Model = conceptual view = how a system works DESIGN PROCESS designers describe the system functionality in a language that is most appropriate for the model Architecture = implementation view = how a system will be manufactured

20. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 20 System Specification Models * Distinguish between models and languages (a language implies one or more models) * Main models for embedded systems: –State-oriented (Petri Nets, Finite State Machines) –Activity-oriented (data-flow graph, flow-charts) –Structure-oriented –Data-oriented –Heterogeneous (control/data flow graph, OO, queuing)

21. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 21 System Specification Models * Model choice depends on: - Application domain, e.g., data flow for digital signal processing, finite state machines for control, simulation engine for hardware,... * Language choice depends on: - Available tools - Personal taste and/or company policy - Underlying model (the language must have a semantics in the chosen model)

22. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 22 Control versus Data Flow * Fuzzy distinction, yet useful for: - specification (language, model,...) - synthesis (scheduling, optimization,...) - validation (simulation, formal verification,...) * Rough classification: - control: - don't know when data arrive (quick reaction) - time of arrival often matters more than value - data: - data arrive in regular streams (samples) - value matters most

23. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 23 Control versus Data Flow * Specification, synthesis and validation methods emphasize: - for control: - event/reaction relation - response time (Real Time scheduling for deadline satisfaction) - priority among events and processes - for data: - functional dependency between input and output - memory/time efficiency (data flow scheduling for efficient pipelining) - all events and processes are equal

24. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 24 Finite State Machines Functional decomposition into states of operation Inputs and outputs are sequences of events Typical domains of application: - control functions - protocols (telecom, computers,...) * Different communication mechanisms: - synchronous (classical FSMs, Moore, Mealy) - asynchronous (Communicating Sequential Process - CSP, Hoare `85)

25. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 25 The term Synchronous … … has been used in the literature to mean at least three rather different concepts: 1. ``Clocked'', describing a system where all the components are synchronized by a global signal, as opposed to asynchronous systems where synchronization is a local property. 2. ``Zero reaction time'', describing a system where the components react instantaneously to an event. 3. ``Without acknowledge'', describing a communication protocol where the sender does not wait for the receiver to acknowledge the reception of the message. In the following, we will use the first meaning, unless explicitly noted (for example the expression ``synchronous programming language'' refers to the second meaning).

26. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 26 Recap of classical automata Classical automata: Moore-automata: Y = (Z); Z + =  (X, Z) Mealy-automata Y = (X, Z); Z + =  (X, Z) Moore-automata: Y = (Z); Z + =  (X, Z) Mealy-automata Y = (X, Z); Z + =  (X, Z) Internal state Z input Xoutput Y Next state Z + computed by function  Output computed by function Z0Z1 Z2Z3 e=1 0 1 2 3 clock Moore + Mealy automata=finite state machines (FSMs)

27. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 27 FSM Example * 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

28. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 28 FSM Example State Diagram KEY_ON=>START_TIMER (KEY_OFF or BELT_ON) => END_TIMER_5 => ALARM_ON (BELT_ON or END_TIMER_10 or KEY_OFF) => ALARM_OFF WAIT OFF ALARM If no condition is satisfied, implicit self-loop in the current state

29. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 29 FSM Definition -FSM = (I, O, S, S 0, , ) previous notation (X,Y, Z, X 0, , ) - I = { KEY_ON, KEY_OFF, BELT_ON, END_TIMER_5, END_TIMER_10 } - O = { START_TIMER, ALARM_ON, ALARM_OFF } - S = { OFF, WAIT, ALARM } - S 0 = OFF -  : 2 I × S -> S e.g.  ({KEY_OFF}, WAIT) = OFF - : 2 I × S -> 2 O e.g. ({KEY_ON}, OFF) = {START_TIMER} Set of all subsets of I (implicit ``and'') All other inputs are implicitly absent

30. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 30 Symbolic State Transition Table OFF1xxxxWAIT001 OFF0xxxxOFF000 WAITx1x0xOFF000 WAITxx10xOFF000 WAITxxx1xALARM010 WAITx000xWAIT000 ALARMxx1xxOFF100 ALARMxxxx1OFF100 ALARMx1xxxOFF100 ALARMx00x0ALARM000 KEY_ON KEY_OFF BELT_ON END_TIMER_5 END_TIMER_10 ALARM_OFF ALARM_ON START_TIMER PRESENT STATE NEXT STATE I N P U T SO U T P U T S

31. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 31 Architecture used in a register level implementation State register KEY_ON...... END_TIMER_10 START_TIMER ALARM_ON Combinational Logic 

32. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 32 Register Level Implementation Architecture of Mealy FSM State register : 2 I × S -> 2 O Combinational Logic KEY_ON END_TIMER_10 START_TIMER ALARM_ON  : 2 I × S -> S

33. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 33 State register : S -> 2 O Combinational Logic KEY_ON END_TIMER_10 START_TIMER ALARM_ON  : 2 I × S -> S Register Level Implementation Architecture of Moore FSM

34. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 34 Algorithmic State Machine (ASM) The following are the major steps in the ASM methodology: Create an algorithm, using pseudocode, to describe the desired operation of the device Convert the pseudocode into an ASM chart (the basic brick = ASM block) Design the datapath based on the ASM chart Create a detailed ASM chart based on the datapath Design the control logic based on the detailed ASM chart Combination of datapath and control logic makes up the actual logic system that will solves the original problem.

35. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 35 TF ASM Example

36. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 36 Non-deterministic FSM (NDFSM) *  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 * Non ­ determinism can be used to describe: - an unspecified behavior (incomplete specification) - an unknown behavior (environment modeling) implicit ``and'’ implicit ``or''

37. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 37 NDFSM: incomplete specification E.g. Error checking first partially specified:... 0 1 78 SYNC => Then completed as even parity:... BIT=> Could be implemented as CRC later BIT=> BIT => ERR BIT=> 0 p1 d1 p7 d7 8 BIT=> BIT=> ERR SYNC => BIT or BIT=> BIT or BIT=>ERR BIT or BIT=>

38. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 38 NDFSM: unknown behavior s0s0 * Modeling the environment * Useful to: - optimize (don't care conditions) - verify (exclude impossible cases) * E.g. driver model: * Can be refined E.g. introduce timing constraints (minimum reaction time 0.1 s) => KEY_ON or KEY_OFF or BELT_ON

39. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 39 NDFSM: time range 1 7 6 5 432 9 8 0 SEC=> SEC => END SEC=> END START=> SEC=>END SEC=> END * Special case of unspecified/unknown behavior, but so common to deserve special treatment for efficiency * E.g. undetermined delay between 6 and 10 s START=>

40. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 40 NDFSMs and FSMs s1 a c c s2 s3s2,s3 s1 s1,s3 s2 a a b a c s3 ab a c a b * Formally FSMs and NDFSMs are equivalent * In practice, NDFSMs are often more compact (exponential blowup for determinization)

41. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 41 FSM Composition E = {S, S 0, I, O, T} and M = {S’, S’ 0, I’, O’, T’} The composition of E and M, denoted E || M, can be defined by a partition I = I 0 U I 1 of the inputs of the first machine E and a partition O’ = O’ 0 U O’ 1 of the outputs of the second machine M, such that I 1 = O’ 1 and O = I’. Additionally, I 0 must be disjoint from O’. The new FSM, E || M, can be defined as follows: —set of states, S X S’; —input variables, I 0, —output variables O U O’, —initial states, S 0 X S’ 0, —transition relation T || O’ 1 = I 1 I = I 0 U I 1 O FSM E I1I1 O O’ O U O’

42. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 42 FSM Composition 1 8765 43 2 0 9 START_TIMER => SEC => END_5_SEC SEC => END_5_SEC SEC => * Bridle complexity via hierarchy: FSM product yields an FSM * Fundamental hypothesis: all the FSMs change state together (synchronicity) * System state = Cartesian product of component states (state explosion may be a problem...) * E.g. seat belt control + timer

43. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 43 FSM Composition KEY_ON and START_TIMER => START_TIMER OFF, 0 OFF, 2 WAIT, 2 OFF, 1 WAIT, 1 SEC and (KEY_OFF or BELT_ON) => Etc., etc., SEC and (KEY_OFF or BELT_ON) => SEC and (KEY_OFF or BELT_ON) =>

44. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 44 FSM Composition Given –M 1 = (I 1, O 1, S 1, r 1,  1, 1 ) –M 2 = (I 2, O 2, S 2, r 2,  2, 2 ) Find the composition M = (I, O, S, r, , ) given a set of constraints of the form C = {(o, i 1, i 2,,..., i n ) : o is connected to i 1, i 2,,..., i n }

45. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 45 Given –M 1 = (I 1, O 1, S 1, r 1,  1, 1 ) –M 2 = (I 2, O 2, S 2, r 2,  2, 2 ) Find the composition M = (I, O, S, r, , ) given a set of constraints of the form I 2 = I’ 2 U I” 2 C = {O 1 is connected to I” 2 } I1I1 1 2 I’ 2 I” 2 I’ 2 I” 2

46. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 46 FSM Composition * product of FSM 1 and FSM 2 * I = I 1  I ’ 2 * O = O 1  O 2 * Assume e.g. that o 1  I 2, o 1  O 1 (communication) * S = S 1 × S 2 *  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, o 1 }, s 2 ) = t 2, 2 ({i 2 }, s 2 ) = {o 2 } we have: -  ({ i 1, i 2, o 1 }, (s 1, s 2 )) = (t 1, t 2 ), - ({ i 1, i 2, o 1 }, (s 1, s 2 )) = {o 1, o 2 }

47. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 47 FSM Composition Unconditional product M’=(I’,O’,S’,r’,  ’, ’) I’= I 1  I 2 O’= O 1  O 2 S’= S 1  S 2  ’= {(A 1, A 2, s 1, s 2, t 1, t 2 ):(A 1, s 1, t 1 )   1 & (A 2, s 2, t 2 )   2 } ’= {(A 1, A 2, s 1, s 2, B 1, B 2 ):(A 1, s 1, B 1 )  1 & (A 2, s 2, B 2 )  2 } Note: A 1  I 1, A 2  I 2, B 1  O 1, B 2  O 2 2 X  Y  2 X x 2 Y Constraint application = {(A 1, A 2, s 1, s 2, B 1, B 2 )  ’: for all (o, i 1, i 2,,..., i n )  C o  B 1  B 2 = if and only if i j  A 1  A 2 for all j} The application of the constraint rules out the cases where the connected input and output have different values.

48. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 48 FSM Composition 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 2 },s 2 )? FSM 1 FSM 2 o1o1 i2i2 i1i1 o2o2

49. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 49 Summary of Finite State Machines Car OR 5min 10sec 30sec 10sec SGSY HYHG * Advantages: - Easy to use (graphical languages) - Powerful algorithms for - synthesis (SW and HW) - verification * Disadvantages: - Sometimes over-specify implementation (sequencing is fully specified) - Numerical computations cannot be specified compactly (need extended FSMs)

50. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 50 Define –a set of storage variables VAR –a set of expressions EXP = {f(x,y,z,…) | x,y,z,…  VAR} –a set of storage assignments A = {X  e | X  VAR, e  EXP} –A set of status expressions STAT = {Rel(a,b) | a,b  EXP} FSMD defined as the quintuple Where: f: S x (I  STAT)  S h: S x (I  STAT)  O  A Extended FSM with a Datapath (FSMD) S1 start (curr_floor != req_floor) / output:= curr_floor - req_floor; curr_floor := req_floor (curr_floor = req_floor) / output := 0

51. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 51 Extended FSM Example Ch. B Ch. D Proc.2Ch. AProc. 1 Process 1: forever { x = 0; y = 0; while (x < 10) { y = y + get_data (B); x = x + 1; } put_data (A, y / 10); } Process 2: forever { a = get_data (A); if (a < 0) put_data (C, a); else put_data (D, ­ a); } Ch. C

52. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 52 put_data (C,-a) Extended FSM Example x = 0 y = 0 y = y +get_data (B) x = x + 1 Put_data (A,y/10) x < 10 Y N s1 s2 s3 put_data (D,a) a < 0 A = get_data (A) Y N t2 t3 t1 proc. 1 proc. 2

53. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 53 Extended FSM primitives initial state state YN decision transition FSM/data connection constant variable communication channel loading operator s1 s2 < 10 0 x B +1

54. Voicu Groza, 2008 SITE, 2008 - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS 54 s3 s1t1 Formal Extended FSM Example s2 00 yB D C proc. 1 < 0 < 10 x aA - YN t3t2 +1 /10 + proc. 2 Y N