Modeling Embedded Systems. Tajana Simunic Rosing Department of Computer Science and Engineering University of California, San Diego.

Transcription

1 Modeling Embedded Systems Department of Computer Science and Engineering University of California, San Diego. 1

2 ES Design Hardware components Hardware Verification and Validation 2

3 Models, Languages and Tools State machine Sequent. program Dataflow Concurrent processes Verilog C/C++ Java VHDL Implementation A Implementation B Implementation C 3

4 Components of a formal design model n Functional specification Relationships between inputs, outputs & states n Properties Relations between I/O/S that can be checked against the functional specification 3 types: inherent in model of computation, those that can be verified syntactically & semantically for a given specification n Performance indices Evaluate quality of design n Constraints On performance indices, usually inequalities 4

5 Design: n Design process A set of components interacting with each other and with the environment that is not a part of design Model of Computation (MOC): n Defines the behavior and interaction of the design blocks Design process: n Takes a model at a higher level of abstraction and refines it to a lower level along with mapping constraints, performance indices and properties to the same level Validation: n Process of checking if design is correct Simulation/emulation, formal verification of specification or implementation Synthesis: n Design refinement where more abstract specifications are translated into less abstract specifications 5

6 n State Models of Computation Elements e.g. in HW : n n n Decidability Combinational states: one state for a given time t Sequential states: multiple states possible for time t Can a property be determined in a finite amount of time? n Concurrency and communication Embedded systems usually have coordinated concurrent processes -> communication required 6

7 Modes of Communication 7

8 Communication n Message Passing Non-blocking Blocking send () send () receive () receive () Extended rendezvous n Shared memory send () process a {.. P(S) //obtain lock.. // critical section V(S) //release lock } process b {.. P(S) //obtain lock.. // critical section V(S) //release lock } receive () ack 8

9 Models of computation comparison Communication/ local computations Communicating finite state machines Shared memory StateCharts Message passing Synchronous Asynchronous SDL Data flow (Not useful) Kahn networks, DFG, SDF Petri nets various versions of Petri Nets Discrete event (DE) model VHDL*, Verilog*, SystemC*, Only experimental systems, e.g. distributed DE in Ptolemy Von Neumann model + C, C++, Java C, C++, Java & libraries, ADA *Classification based on implementation with centralized data structures + Consists of a processing unit, control unit and storage for instructions & data

10 Model of Computation Examples n State machine models FSM, StateCharts, SDL n Petri nets n Communicating processes Kahn processes, Communicating Sequential Processes n Ada n Dataflow models DFG, SDFG n Discrete event models VHDL, Verilog, SystemC, SpecC n Synchronous languages Cycle based models, Esterel, Lustre 10

11 Classical automata input I clock Internal state S output O Moore-automata: O = H(S); S + = f(i, S) Mealy-automata O = H(I, S); S + = f(i, S) S0 e=1 S1 0 1 e=1 e=1 S3 S2 3 e=1 2 11

12 Finite-state machines (FSMs) Elevator Control process using a state machine req > floor u,d,o, t = 1,0,0,0 GoingUp!(req > floor) u,d,o,t = 0,0,1,0 req == floor req > floor Idle req < floor!(timer < 10) DoorOpen timer < 10 u,d,o,t = 0,0,1,1 u,d,o,t = 0,1,0,0 GoingDn req < floor!(req<floor) u is up, d is down, o is open t is timer_start 12

13 Elevator Control with Fire Mode req>floor UnitControl u,d,o = 1,0,0 GoingUp!(req>floor) req>floor u,d,o = 0,0,1 Idle timeout(10) DoorOpen u,d,o = 0,0,1 req==floor u,d,o = 0,1,0 req<floor GoingDn!(req<floor) fire fire fire fire FireGoingDn u,d,o = 0,1,0 floor==1 u,d,o = 0,0,1 req<floor floor>1 FireDrOpen!fire fire n FireMode When fire is true, move elevator to 1 st floor and open door 13

14 Models of Computation n State Machine Models FSM, StateCharts, CFSM, SDL n Petri nets n Communicating Processes Kahn processes, Communicating Sequential Processes n Ada n Dataflow models DFG, SDFG n Discrete Event Systems VHDL, Verilog, SystemC, SpecC n Synchronous languages Cycle based models, Esterel, Lustre 14

15 StateCharts: Hierarchy 15

16 Back to Elevator Example ElevatorController! fire UnitControl NormalMode FireMode fire RequestResolver... req>floor NormalMode UnitControl u,d,o = 1,0,0 u,d,o = 0,0,1 req==floor u,d,o = 0,1,0 GoingUp req>floor Idle req<floor GoingDn!(req>floor) timeout(10)!(req>floor) DoorOpen u,d,o = 0,0,1 req<floor!fire fire FireMode FireGoingDn u,d,o = 0,1,0 floor==1 u,d,o = 0,0,1 floor>1 FireDrOpen fire 16

17 StateCharts: Default state 17

18 StateCharts: History 18

19 History & default state same meaning 19

20 StateCharts: Concurrency 20

21 Conditional Transitions 21

22 StateCharts: Timers 22

23 Example: Answering machine 23

24 StateCharts: edge labels event [condition] / reaction n Events: Exist only until the next evaluation of the model Can be either internally or externally generated n Conditions: Refer to values of variables that keep their value until they are reassigned n Reactions: Can either be assignments for variables or creation of events n Example: service-off [not in Lproc] / service:=0 24

25 Source: B. P. Douglass & ilogix Propagations and Broadcasts 25

26 StateCharts: Simulation phase 1 Status phase 2 phase 3 Status= values of all variables + set of events + current time Step = execution of the three phases Three phases: 1. Effects of external changes on events and conditions are evaluated, 2. The set of transitions to be made in the current step and right hand sides of assignments are computed, 3. Transitions become effective, variables obtain new values. 26

27 StateCharts Simulation Example

28 Statecharts Example 1 e A B C f Statechart Example h g k m D e h A B C g f m k k D k Equivalent FSM Representation 28

29 Statecharts Example 2 f A B n g k E Statechart Example C D m h n n g g AC h AD BC h BD f f k m m m m Equivalent FSM Representation E 29

30 StateCharts: Application Examples n Power converter system for trams, metros & trains System-level modeling and automated code generation Guarantee latencies less than 10 microseconds Cut development time by 50% Time from design completion to first prototype down to 1hr from 3 months Defect free code automatically generated for a number of RTOS implementations 30 By Alstom

31 StateCharts: Application Examples n Development of defibrillator and pacemaker technology Model system behavior before requirements are finalized Check that SW provides mathematically consistent representation of the product s system correct and unambiguous representation of model behavior More accurate and extensive verification guarantee device works 100% of the time for at least 7-10yrs Cut product verification costs by 20% 15-20% overall cost reduction per projects on future development 31 By Guidant CRM

32 StateCharts: Application Examples n Jet engine electronic controller design System level specification and consistency check Construction of on-screen simulation of the cockpit display Evaluate correctness in normal and faulty operation modes Project so successful that now StateCharts are used for: n Independent overspeed protection system n Thrust reverse control system n Engine fuel control system By BMW 32

33 StateCharts: Summary n Hierarchy n AND- and OR-super states n Default state, History n Timing behavior n State oriented behavior n Edge labels n Concurrency n Synchronization & communication Broadcast, shared memory n Simulation n Cross compiling 33

34 Models of Computation n State Machine Models FSM, StateCharts, SDL n Petri nets n Communicating Processes Kahn processes, Communicating Sequential Processes n Ada n Dataflow models DFG, SDFG n Discrete Event Systems VHDL, Verilog, SystemC, SpecC n Synchronous languages Cycle based models, Esterel, Lustre 34

35 SDL n Designed for specification of distributed systems. n n Dates back to early 70s,formal semantics defined in the late 80s, updates from 1984 to 1999 by International Telecommunication Union (ITU) Provides textual and graphical formats n Similar to StateCharts, each FSM is called a process, but it uses message passing instead of shared memory for communication n Supports operations on data

36 SDL-representation of FSMs/processes state input output

37 Communication among SDL-FSMs n Communication between FSMs (or processes ) is based on message-passing, assuming a potentially indefinitely large FIFO-queue. Each process fetches next entry from FIFO, checks if input enables transition, if yes: transition takes place, if no: input is ignored (exception: SAVEmechanism).

38 Determinate? n Let tokens be arriving at FIFO at the same time: F Order in which they are stored is unknown: All orders are legal so simulators can show different behaviors for the same input, all of which are correct.

39 Operations on data n Variables can be declared locally for processes. n Their type can be predefined or defined in SDL itself. n SDL supports abstract data types (ADTs)

40 Process interaction diagrams n Interaction between processes can be described in process interaction diagrams, which are a special case of block diagrams n In addition to processes, these diagrams contain channels and declarations of local signals., B

41 Hierarchy in SDL n Process interaction diagrams can be included in blocks. The root block is called system. Processes cannot contain other processes, unlike in StateCharts.

42 Timers n Timers can be declared locally n Elapsed timers put signal into queue, but are not necessarily processed immediately n RESET removes a timer also from FIFO-queue.

43 Description of network protocols

44 Vending machine example Machine sells pretzels, chips, cookies, & doughnuts Accepts nickels, dime, quarters, and half-dollars It is not a distributed application. [J.M. Bergé, O. Levia, J. Roullard: High-Level System Modeling, Kluwer Academic Publishers, 1995]

45 Overall view of vending machine

46 p Decode Requests

47 Chip Handler no yes no yes

48 SDL: Real World Example n ADSL design Ideal language for telecom design; communication between components and their different states of operation can be easily modeled with SDL Object orientation and automatic code generation significantly simplified system design verification Early testing done on SDL significant savings in the cost of expensive test equiptment By Siemens 48

49 SDL summary FSM model for the components, Non-blocking message passing for communication, Implementation requires bound for the maximum length of FIFOs; may be very difficult to compute, Not necessarily determinate Timer concept adequate just for soft deadlines, Limited way of using hierarchies, Limited programming language support, No description of non-functional properties, Excellent for distributed applications (used for ISDN), Commercial tools available (see

50 Models of Computation n State Machine Models FSM, StateCharts, SDL, CFSM n Petri nets n Communicating Processes Kahn processes, Communicating Sequential Processes n Ada n Dataflow models DFG, SDFG n Discrete Event Systems VHDL, Verilog, SystemC, SpecC n Synchronous languages Cycle based models, Esterel, Lustre 50

51 Petri net definitions n H 2 OExample Source: Murata 89 51

52 Petri net Train tracks model 52

53 Concurrency, Causality, Choice 53

54 Concurrency, Causality, Choice 54

55 Concurrency, Causality, Choice 55

56 Concurrency, Causality, Choice 56

57 Concurrency, Causality, Choice 57

58 Petri nets: confusion J n Concurrency & conflict lead to confusion. Symmetric Asymmetric Source: Murata 89 58

59 Conflict for resource track 59

60 Communication Protocol 60

61 Communication Protocol 61

62 Communication Protocol 62

63 Communication Protocol 63

64 Communication Protocol 64

65 Communication Protocol 65

66 Producer-Consumer Problem 66

67 Producer-Consumer Problem 67

68 Producer-Consumer Problem 68

69 Producer-Consumer Problem 69

70 Producer-Consumer Problem 70

71 Producer-Consumer Problem 71

72 Producer-Consumer Problem 72

73 Producer-Consumer Problem 73

74 Producer-Consumer Problem 74

75 Producer-Consumer Problem 75

76 Producer-Consumer Problem 76

77 Producer-Consumer Problem 77

78 Producer-Consumer Problem 78

79 Producer-Consumer Problem 79

80 Producer-Consumer with Priority n Modeling synchronization control when sharing resources n Multiprocessor CPUs, distributed systems 80

81 Petri net definitions n H 2 OExample Source: Murata 89 81

82 n Behavioral Reachability n Petri Net Properties Marking M reachable from marking Mo k - Boundedness n n Liveness n Number of tokens in each place does not exceed finite number k Safe if 1-bounded n Structural Controlability Can fire any transition of the net related to absence of deadlocks n Any marking can be reached from any other marking Structural boundednes Conservativeness weighted sum of tokens constant 82

83 PN Properties - Reachability 83

84 PN Properties Deadlock-free 84

85 PN Properties Deadlock-free 85

86 Petri Net Liveness n L0-live (dead): a particular transition can never fire In the figure below, t 0 can never fire n see reachability graph

87 Petri Net Liveness n L1-live: a particular transition can fire at least once for some firing sequence In the figure below, t 1 can only fire once, for some firing sequence

88 Petri Net Liveness n L2-live: a particular transition can fire k times for a particular firing sequence, for any k. In the figure below, t 2 can only fire once, twice, etc, for different firing sequences

89 Petri Net Liveness n L3-live: a particular transition can fire infinitely in a particular firing sequence. In the figure below, t 3 can fire infinitely for the firing sequence t 3, t 3, t 3, t 3, Note that the number of times t 1 and t 2, fire is finite for any firing sequence.

90 PN Properties - Boundedness 90

91 PN Properties - Boundedness 91

92 PN Properties - Boundedness 92

93 PN Properties - Boundedness 93

94 PN Properties - Boundedness 94

95 PN Properties - Conservation 95

96 PN Properties - Conservation 96

97 PN Properties - Conservation 97

98 Petri Nets - Analysis n Structural Incidence matrix n State Space Analysis techniques Coverability Tree Reachability Graph 98

99 PN Properties Analysis Incident Matrix State Equations 99

100 Petri Nets Coverability Tree 100

101 n Assume e=6 Mo=[0 12] Example n Can we reach M=[6 0] from Mo? n Can it be statically scheduled? n What size buffers are needed at P1 & P2? T1 2 P1 3 4 P2 e T2 101

102 Petri nets: Applications n Model, simulate and analyze networking protocols (e.g. TCP, Ethernet, etc) n Model, simulate and analyze complex network elements (e.g. router, switch, optical mux); check their logical behavior n Design and analyze network performance and AoS with logical models of traffic generators, protocols and network elements n Study network behavior characteristics (e.g. throughput, blocking probability etc) By Siemens 102

103 Petri nets in practice n Example apps: TCP performance Security system design and automated code geneeration MAC design. 103

104 Petri Nets - Summary n PN Graph places (buffers), transitions (action), tokens (data) n Firing rule Transition enabled if enough tokens in a place n Properties Structural (consistency, structural boundedness) Behavioral (reachability, boundedness, etc.) n Analysis techniques n Applications Modeling of resources, mutual exclusion, synchronization 104

105 Models of Computation n State Machine Models FSM, StateCharts, SDL, CFSM n Petri nets n Communicating Processes Communicating Sequential Processes, Ada, Kahn processes n Dataflow models DFG, SDFG n Discrete Event Systems VHDL, Verilog, SystemC, SpecC n Synchronous languages Cycle based models, Esterel, Lustre n HW Models n Unified Modeling Language (UML) 105

106 Process n A sequential program Executes concurrently with other processes n Basic operations on processes Create & terminate, suspend & resume, join n Process communication Shared memory (and mutexes) Message passing Rendezvous Unit Control Request Resolver System interface req b1 b2 bn up1 up2 dn2 up3 dn3 dnn up down open floor buttons inside elevator up/down buttons on each floor 106

107 ADA-rendez-vous task screen_out is entry call_ch(val:character; x, y: integer); entry call_int(z, x, y: integer); end screen_out; task body screen_out is... select accept call_ch... do.. end call_ch; or accept call_int... do.. end call_int; end select; Sending a message: begin screen_out.call_ch('z',10,20); exception when tasking_error => (exception handling) end; 107

108 Task graphs Sequence constraint Nodes are a program described in some programming language 108

109 Task graphs - Timing Arrival time deadline ] 109

110 Task graphs - I/O 110

111 Task graphs - Shared resources 111

112 Task graphs - Periodic schedules.. infinite task graphs 112

113 Task graphs - Hierarchy 113

114 Models of Computation n n n n n n n n n State Machine Models FSM, StateCharts, SDL, CFSM Petri nets Communicating Processes Communicating Sequential Processes, Ada Dataflow models Kahn processes DFG, SDFG Discrete Event Systems VHDL, Verilog, SystemC, SpecC Synchronous languages Cycle based models, Esterel, Lustre Petri nets HW Models Unified Modeling Language (UML) 114

115 Kahn process network KPN - executable task graphs Communication is via infinitely large FIFOs Nonblocking write, blocking read => DETERMINATE channel process Important properties of KPN: Continuous Output signals can be gradually produced; never have to consume all input to produce some output Monotonic Output depends on input but doesn t change previous output Continuous monotonic processes => ITERATIVE 115

116 Petri net model of a Kahn process n KPNs are deterministic: Output determined by n Process, network, initial tokens 116

117 Modeling Embedded Systems Department of Computer Science and Engineering University of California, San Diego. 117

118 Dataflow Process Networks A C D Z = (A + B) * (C - D) A B C D + t1 t2 B n Dataflow: Maps input tokens to output tokens Outputs function of current inputs n No need to keep state on suspend/ resume Scheduling for resource sharing A B C D modulate t1 transform Z t2 convolve Nodes with more complex transformations * Z Nodes with arithmetic transformations 118

119 Dataflow process examples n HW resource scheduling Constraints: 2 mult, 2 ALU NOP 0 List scheduler Additional constraints n Performance n Power n Area etc. T1 T2 T3 * 1 2 * * 3 4 * * 7 6 * 8 + < T NOP n 119

120 Synchronous dataflow 120

121 SDF notation n Nodes have rates of data production or consumption. n Edges have delays. Delays do not change rates, only the amount of data stored in the system at startup

122 SDF examples n1 1 2 n n3 n1 1 D 1 2D 1 1 n2 n3

123 SDF Scheduling n By building a set of flow and conservation equations 3a 2b = 0 4b 3d = 0 b 3c = 0 2c a = 0 d 2a = 0 Solution: a = 2c; b = 3c; d = 4c Possible schedules: BBBCDDDDAA BDBDBCADDA BBDDBDDCAA 123

124 Dataflow process examples n Design of a first b WLAN card New product combines RF, MAC and PHY; lots of DSP Implemented on an ASIC Previous design hand coded VHDL n System level design with COSSAP by Synopsys Explore architectural trade-offs what in gates, what on DSP Scheduling trade-offs: latency, area, propagation delay between clocks, and vendor library n Results: Reduced time to market by a factor of TWO! Architectural exploration within 10% of actual measurements in terms of timing and area by Symbol Tech. 124

125 Models of Computation n n n n n n n n n State Machine Models FSM, StateCharts, SDL, CFSM Petri nets Communicating Processes Kahn processes, Communicating Sequential Processes Ada Dataflow models DFG, SDFG Discrete Event Systems VHDL, Verilog, SystemC, SpecC Synchronous languages Cycle based models, Esterel, Lustre HW Models Unified Modeling Language (UML) 125

126 Discrete Events n Notion of time is fundamental: global order events are objects which carry ordered time info there is a casual relationship between events n DE simulator maintains global event queue Verilog, VHDL n Expensive - ordering tame stamps can be time consuming n Large state & Low Activity => Effective simulation n Simultaneous events lead to non-determinacy require complex conflict resolution schemes e.g. delta delays 126

127 Simultaneous Events in the Discrete Event Model t A B C t B has 0 delay B has delta delay t t A B C t t+ A B C 127

128 VHDL: Entities entity full_adder is port(a, b, carry_in: in Bit; -- input ports sum,carry_out: out Bit); --output ports end full_adder; 128

129 VHDL: Architectures architecture structure of full_adder is component half_adder port (in1,in2:in Bit; carry, sum:out Bit); end component; component or_gate port (in1, in2:in Bit; o:out Bit); end component; signal x, y, z: Bit; begin -- local signals -- port map section i1: half_adder port map (a, b, x, y); i2: half_adder port map (y, carry_in, z, sum); i3: or_gate port map (x, z, carry_out); end structure; architecture behavior of full_adder is begin sum <= (a xor b) xor carry_in after 10 Ns; carry_out <= (a and b) or (a and carry_in) or (b and carry_in) after 10 Ns; end behavior; 129

130 VHDL: signal strengths 130

131 VHDL processes & waits Processes model HW parallelism process begin a <= b after 10 ns end Waits: wait until signal list; wait until a; wait until condition; wait until c='1'; wait for duration; wait for 10 ns; wait; suspend indefinitely wait on = sensitivity list process begin prod <= x and y ; wait on x,y; end process; process (x, y) begin prod <= x and y ; end process; 131

132 VHDL Simulation 132

133 VHDL Simulation of an RS FF nd δ st δ ns 0ns+δ 0ns+2δ R S Q nq architecture one of RS_Flipflop is begin process: (R,S,Q,nQ) begin Q <= R nor nq; nq <= S nor Q; end process; end one; δ cycles reflect the fact that no real gate comes with zero delay. 133

134 VHDL Summary n Entities and architectures n Multiple-valued logic n Modeling hardware parallelism by processes Wait statements and sensitvity lists n VHDL simulation cycle δ cycles 134

135 SystemC: Motivation 135

136 SystemC: Methodology 136

137 Models of Computation n n n n n n n n n State Machine Models FSM, StateCharts, SDL, CFSM Petri nets Communicating Processes Kahn processes, Communicating Sequential Processes Ada Dataflow models DFG, SDFG Discrete Event Systems VHDL, Verilog, SystemC, SpecC Synchronous reactive languages Cycle based models, Esterel, Lustre HW Models Unified Modeling Language (UML) 137

138 Reactive Synchronous Languages n Assumptions Instantaneous reactions Discrete event Static n Cycle based models Excellent for (single) clocked synchronous circuits n Control flow oriented (imperative) languages Esterel n Data flow languages Lustre, Signal n Deterministic behavior n Simulation, software and hardware synthesis, verification

139 Lustre example 139

140 Reactive Synchronous Models: Esterel Statements n Emit S n Present S then p else q end n Pause n P; Q, P Q n Loop p end n Await S n Abort p when S n Suspend p when S n Sustain S = (loop emit S; pause end) 140

141 Abort Statement Normal termination Aborted termination Aborted termination, Emit A preempted Normal termination B not checked in the first cycle (like await) 141

142 Esterel Examples 142

143 Esterel Examples 143

144 Time in Esterel n Global clock with precise control over when events appear At every tick: read inputs, compute, output n Statements A bounded number in one cycle n Emit, present, loop Take multiple cycles: n Pause, await, sustain n Causality analysis Deterministic & non-contradictory 144

145 Esterel Application Examples TI used Esterel to automatically synthesize full coverage tests for a safety-critical design Showed functional coverage covered only 30% of the design, with Esterl 100% covered Airbus Significant decrease in errors due to increase in automated code generation (40-70%) e.g fly by wire controls & automatic flight control 70%, display computer 50%, warning & maintenance computer 40% Major increase in productivity 145

146 Esterel Summary Reactive synchronous language Control flow oriented Imperative syntax Synchrony assumption useful for safety critical embedded systems Convert timing relations to causal ordering Used in verification e.g. TI, Airbus 146

147 Models of Computation n n n n n n n n n State Machine Models FSM, StateCharts, SDL, CFSM Petri nets Communicating Processes Kahn processes, Communicating Sequential Processes Ada Dataflow models DFG, SDFG Synchronous languages Cycle based models, Esterel, Lustre Discrete Event Systems VHDL, Verilog, SystemC, SpecC HW Models Unified Modeling Language (UML) 147

148 Levels of hardware modeling 1. System level 2. Algorithmic level 3. Instruction set level 4. Register-transfer level (RTL) 5. Gate-level models 6. Switch-level models 7. Circuit-level models 8. Device-level models 9. Layout models 10. Process and device models 148

149 Instruction level Assembler (MIPS) Simulated semantics and $1,$2,$3 Reg[1]:=Reg[2] Reg[3] or $1,$2,$3 Reg[1]:=Reg[2] Reg[3] andi $1,$2,100 Reg[1]:=Reg[2] 100 sll $1,$2,10 Reg[1]:=Reg[2] << 10 srl $1,$2,10 Reg[1]:=Reg[2] >>

150 Register transfer level: MIPS PCWrite PC B PCWriteC IorD 0 1 MemWrite MemRead i2 a2 a1 Memory IRWrite Instruction register IR * 31:26 25:21 20:16 15:11 15:0 25:0 MemToReg Controller RegDest RegWrite i3 a3 a2 a1 Reg Speicher sign_ extend o2 o1 ALUSelB 4 <<2 ALUSelA ALUOp ALU alu_ control TargetWrite T PCSource * "00 31:

151 Gate-level model 151

152 Switch level model 152

153 Circuit level model 153

154 Device level Measured and simulated currents 154

155 Layout model powhi din dout powlo 155

156 Process model Simulated Measured 156

157 Models of Computation n State Machine Models FSM, StateCharts, SDL, CFSM n Petri nets n Ada n Communicating Processes Kahn processes, Communicating Sequential Processes n Dataflow models DFG, SDFG n Synchronous languages Cycle based models, Esterel, Lustre n Discrete Event Systems VHDL, Verilog, SystemC, SpecC n HW Models n Unified Modeling Language (UML) 157

158 From: UML (Unified modeling language) 158

159 UML - StateCharts 159

160 UML Extended Petri Nets swimlane 160

161 UML UML Summary - State machine diagram (StateChart-like) - Activity diagram (extended Petri nets) - Deployment diagram (exec. arch.) - Use case diagram - Package diagram (hierarchy) - Class diagrams - Timing diagrams (UML 2.0), UML for real-time 161

162 Models and Languages Summary n Multiple models and languages are essential for highlevel design Managing complexity by abstraction Formality ensures refinement correctness Model choice depends on n Class of applications n Required operations (synthesis, scheduling,...) n Multiple MOCs can co-exist during all phases of design Specification Architectural mapping and simulation Synthesis, code generation, scheduling Detailed design and implementation Co-simulation 162

163 Sources and References n Peter Marwedel, Embedded Systems Design, n Frank Vahid, Tony Givargis, Embedded System Design, Wiley, n Wayne Wolf, Computers as Components, Morgan Kaufmann, n Axel Jantsch, Modeling Embedded Systems and SOCs, Morgan Kaufmann, n Alberto UCB n Mani UCLA n Rajesh UCSD n Nikil UCI 163