CS 310 Embedded Computer Systems DESIGN

Transcription

1 1 EMBEDDED SYSTEM DESIGN

2 Embedded System Design 2

3 3 Specification

4 Introduction 4 Describing embedded d system s processing behavior Can be extremely difficult Complexity increasing with increasing IC capacity Past: washing machines, small games, etc. Hundreds of lines of code Today: TV set-top boxes, Cell phone, etc. Hundreds of thousands of lines of code Desired behavior often not fully understood in beginning Many implementation bugs due to description mistakes/omissions English (or other natural language) common starting point Precise description difficult to impossible Example: Motor Vehicle Code thousands of pages long...

5 5 An example of trying to be precise in English California Vehicle Code Right-of-way of crosswalks (a) The driver of a vehicle shall yield the right-of-way to a pedestrian crossing the roadway within any marked crosswalk or within any unmarked crosswalk at an intersection, except as otherwise provided in this chapter. (b) The provisions of this section shall not relieve a pedestrian from the duty of using due care for his or her safety. No pedestrian shall suddenly leave a curb or other place of safety and walk or run into the path of a vehicle which is so close as to constitute an immediate hazard. No pedestrian shall unnecessarily stop or delay traffic while in a marked or unmarked crosswalk. (c) The provisions of subdivision (b) shall not relieve a driver of a vehicle from the duty of exercising due care for the safety of any pedestrian within any marked crosswalk or within any unmarked crosswalk at an intersection. All that just for crossing the street (and there s much more)!

6 Models 6 Many different activities iti from initial iti idea to physical implementation all these activities operate on models and not on the real physical object. Model a simplification on another entity (physical thing or another model) contains exactly those characteristics and properties of the modeled entity that are relevant for a given task minimal wrt a task if it does not contain any other characteristics than those relevant for the task

7 Modeling and Design 7 Modeling Act of representing a system or subsystem formally Mathematical model Viewed as a set of assertions about properties of the system such as its functionality or physical dimensions Constructive model Defines a computational procedure that mimics a set of properties of the system Executable models Design Act of defining a system or subsystem Defining one or more models of the system Refining the models until the desired functionality is obtained within a set of constraints

8 Models 8 How can we (precisely) capture behavior? We may think of languages (C, C++) sequential program computation model Computation model is the key increasing complexity of ES functionality requires more advanced computation model Common computation models: Sequential program model Statements, rules for composing statements, semantics for executing them Communicating process model Multiple sequential programs running concurrently State machine model For control dominated systems, monitors control inputs, sets control outputs Dataflow model For data dominated d systems, transforms input data streams into output t streams Object-oriented model For breaking complex software into simpler, well-defined pieces

9 Models vs. languages 9 Models Poetry Recipe Story State Sequent. machine program Dataflow Languages English Spanish Japanese C C++ Java 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++, C++ Java One language can capture variety of models E.g., C++ sequential program model, object-oriented model, state machine model Certain languages better at capturing certain computation models

10 Models of computation - Definition - 10 Models of computation ti define [Lee, UCB, 1999]: What it means to be a component: Subroutine? Process? Thread? rules for composing those components The mechanisms by which components interact: Message passing? Rendez-vous? Possibly also: What components know about each other (global variables? Implicit behavior of other components)

11 11 Introductory example: An elevator controller Simple elevator controller Partial English description System interface 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 Unit Control req Request Resolver... b1 b2 bn up down open floor buttons inside elevator Try capturing in C up1 up2 dn2 up3 dn3 up/down buttons on each floor dnn

12 12 Elevator controller using a sequential program model 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); } } Partial English description 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 void RequestResolver() { while (1)... req = p } void main() { Call concurrently: UnitControl() and RequestResolver() } more precise than the English description for the UnitControl process Unit Control req Request Resolver System interface b1 b2 bn up1 up2 dn2 up3 dn3 dnn up down open floor buttons inside elevator up/down buttons on each floor

13 Finite-state machine (FSM) model 13 Trying to capture this behavior as sequential ential 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) Try it...

14 Finite-state machine (FSM) model 14 UnitControl 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 >fl floor!(timer < 10) Idle req < floor 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

15 Formal definition 15 An FSM is a 6-tuple F<S, I, O, F, H, s0> S is a set of all states {s 0, s 1,, s l } I is a set of inputs {i 0,i 1,,i m } O is a set of outputs {o 0, o 1,, o n } 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)

16 16 Finite-state machine with datapath model (FSMD) FSMD extends FSM: complex data types and variables for storing data FSMs use only Boolean data types and operations, no variables We described UnitControl as an FSMD FSMD: 7-tuple <S, I, O, V, F, H, s 0 > S is a set of states {s 0, s 1,, s l } I is a set of inputs {i 0, i 1,, i m } O is a set of outputs {o 0, o 1,, o n } u,d,o, t = 1,0,0,0 req > floor u,d,o,t = 0,0,1,0 req > floor GoingUp V is a set of variables {v 0, v 1,, v n } Idle 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 req == floor u,d,o,t = 0,1,0,0 GoingDn req < floor req < floor!(req > floor)!(timer < 10) DoorOpen!(req<floor) timer < 10 u,d,o,t = 0,0,1, u is up, d is down, o is open t is timer_start I,O,V may represent complex data types (i.e., 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, s i, and values of all variables

17 17 Describing a system as a state machine 1. List all possible states 2. Declare all variables (none in this example) 3. For each state, list possible transitions, with conditions, to other states 4. For each state and/or transition, list associated actions 5. For each state, ensure exclusive and complete exiting transition conditions No two exiting conditions can be true at same time Otherwise nondeterministic state machine One condition must be true at any given time Reducing explicit transitions should be avoided when first learning u,d,o, t = 1,0,0,0 udot=0010 u,d,o,t 0,0,1,0 req == floor u,d,o,t = 0,1,0,0 req > floor GoingUp!(req > floor) req > floor timer < 10 Idle GoingDn req < floor req < floor!(timer < 10)!(req<floor) DoorOpen u is up, d is down, o is open t is timer_start u,d,o,t = 0,0,1,1

18 18 State machine vs. sequential program model Different thought ht 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 State machine description excels in many cases More natural means of computing in those cases Not due to graphical representation (state diagram) Would still have same benefits if textual t language age used (i.e., state table) Besides, sequential program model could use graphical representation (i.e., flowchart)

19 HCFSM and the Statecharts language 19 Hierarchical/concurrent state machine model (HCFSM) Extension to state machine model 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 ORdecomposition States can execute concurrently Known as ANDdecomposition Without hierarchy With hierarchy A1 x A2 z A y w A1 z B x y z A2 Concurrency B C D C1 D1 x y u v C2 D2 w B

20 UnitControl with FireMode 20 u,d,o = 1,0,0 u,d,o = 0,0,1 req==floor u,d,o = 0,1,0 req>floor GoingUp req>floor Idle!(req>floor) timeout(10) DoorOpen fire req<floor!(req<floor) fire fire GoingDn FireGoingDn fire req<floor floor>1!fire UnitControl u,d,o = 0,0,1 u,d,o = 0,1,0 floor==1 u,d,o = 0,0,1 FireDrOpen fire FireMode When fire is true, move elevator to 1 st floor and open door w/o hierarchy: Getting messy! w/ hierarchy: Simple! With hierarchy Without hierarchy req>floor NormalMode UnitControl ElevatorController UnitControl RequestResolver NormalMode...!fire fire FireMode With concurrent RequestResolver u,d,o = 1,0,0 GoingUp!(req>floor) req>floor u,d,o = 0,0,1 Idle DoorOpen u,d,o do= 001 0,0,1 req==floor timeout(10) req<floor!(req>floor) u,d,o = 0,1,0 GoingDn req<floor fire FireMode FireGoingDn u,d,o = 0,1,0!fire floor==1 u,d,o = 0,0,1 floor>1 FireDrOpen fire

21 Program-state machine model (PSM): HCFSM plus sequential program model 21 Program-state s 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 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 fire is true AND source program- state is complete SpecCharts: extension of VHDL to capture PSM model SpecC: extension of C to capture PSM model FireMode up = 0; down = 1; open = 0; while (floor > 1); up = 0; down = 0; open = 1; ElevatorController int req; RequestResolver... req = 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

22 22 Role of appropriate model and language Finding appropriate model to capture embedded system is an important step Model shapes the way we think of the system Originally thought of sequence of actions, wrote sequential program First wait for requested floor to differ from target floor Then, we close the door Then, we move up or down to the desired floor Then, we open the door Then, we repeat this sequence To create state machine, we thought in terms of states and transitions among states When system must react to changing inputs, state machine might be best model HCFSM described FireMode easily, clearly Language should capture model easily Ideally should have features that directly capture constructs of model FireMode would be very complex in sequential program Checks inserted throughout code Other factors may force choice of different model Structured techniques can be used instead E.g., Template for state machine capture in sequential program language

23 23 Requirements for specification techniques (1) Hierarchy Humans not capable to understand systems containing more than ~5 objects. Most actual systems require more objects Behavioral hierarchy Examples: states, processes, procedures. Structural hierarchy Examples: processors, racks, printed circuit boards Timing behavior State-oriented behavior Required for reactive systems; classical automata insufficient.

24 24 Requirements for specification techniques (2) Event-handling (external or internal events) ents) No obstacles for efficient implementation 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..

25 25 Requirements for specification techniques (3) 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 Support for the design of large systems ( OO) Domain-specific support

26 26 Requirements for specification techniques (4) 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

27 27 Models of computation - Examples (1) - Communicating finite state machines (CFSMs): Discrete event model (VHDL, Verilog) a b c queue a:=5 b:=7 c:=8 a:=6 a:=9 time action

28 28 Models of computation - Examples (2) - Differential equations (Analog circuits, Physical Systems) 2 x 2 t b Asynchronous message passing (Kahn Process networks, dataflow models) Synchronous message passing (CSP, ADA: rendez-vous)

29 Models of Computation 29 State t Machine models FSM, StateCharts, SDL, CFSM focused on the state and the observable input-output behaviour Petri nets concurrency Communicating Processes Kahn processes, Communicating Sequential Processes (CSP) Dataflow models DFG, SDFG Discrete Event Systems VHDL, Verilog, SystemC, SpecC HW Models Unified Modeling Language g (UML) 2009 Fall CS310 Embedded Computer Systems

30 30 StateCharts: recap of classical automata t Classical automata: input X clock Internal state Z output Y Next state Z + computed by function Output computed by function Moore or Mealy automata = finite state machines (FSMs) Moore-automata: Y = (Z); Z + = (X, Z) Mealy-automata Y = (X, Z); Z + = (X, Z) Z0 e=1 Z1 0 1 e=1 e=1 Z3 Z2 3 e=1 2

31 StateCharts 31 Classical automata not useful for complex systems complex graphs cannot be understood by humans Introduction of hierarchy StateCharts [Harel, 1987]

32 Introducing hierarchy 32 FSM will be in exactly one of the substates of S if S is active (either in A or in B or..) superstate substates

33 Definitions 33 Current states of FSMs are also called active states. States which are not composed of other states are called basic states. States containing other states are called super-states. For each basic state s, the super-states containing s are called ancestor states. Super-states S are called OR-super-states, if exactly one of the sub-states states of S is active whenever S is active. ancestor state of E

34 Default state mechanism 34 Filled circle indicates substate entered whenever super-state is entered. Allows internal structure to be hidden for outside world.

35 History mechanism 35 For input m, S enters the state it was in before S was left (can be A, B, C, D, or E). If S is entered for the very first time, the default mechanism applies. History and default mechanisms can be used hierarchically. (behavior different from last slide)

36 36 Combining history and default state mechanism same meaning

37 Concurrency 37 Convenient ways of describing concurrency are required. AND-super-states: t FSM is in all (immediate) sub-states of a super-state; Example:

38 Entering and leaving AND-super-states states 38 Line-monitoring and key-monitoring are entered and left, when service switch is operated. incl.

39 Types of states 39 In StateCharts, states are either basic states, or AND-super-states, or OR-super-states.

40 Timers 40 Since time needs to be modeled in embedded systems, timers need to be modeled. In StateCharts, special edges can be used for timeouts. If event a does not happen while the system is in the left state for 20 ms, a timeout will take place.

41 Using timers in answering machine 41

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

43 The StateCharts simulation phases 43 How are edge labels evaluated? ated? Three phases: 1. Effect of external changes on events and conditions is 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. Separation into phases 2 and 3 guarantees deterministic and reproducible behavior.

44 Example 44 In phase 2, variables a and b are assigned to temporary variables. In phase 3, these are assigned to a and b. As a result, variables a and b are swapped. In a single phase environment, executing the left state first would assign the old value of b (=0) to a and b. Executing the right state first would assign the old value of a (=1) to a and b. The execution would be non-deterministic.

45 Reflects model of clocked hardware 45 In an actual clocked (synchronous) (y hardware system, both registers would be swapped as well. Same separation into phases found in other languages as well, especially those that are intended to model hardware.

46 Steps 46 Execution of a StateChart t t model consists of a sequence of (status, step) pairs Status= values of all variables + set of events + current time Step = execution of the three phases Status phase 2

47 Broadcast mechanism 47 Values of variables are visible to all parts of the StateChart model. New values become effective in phase 3 of the current step and are obtained by all parts of the model in the following step. StateCharts implicitly assumes a broadcast mechanism for variables. StateCharts is appropriate for local control systems (), but not for distributed applications for which updating variables might take some time ().

48 Lifetime of events 48 Events live until the step following the one in whi ch they are generated ( one shot-events ).

49 Evaluation of StateCharts (1) 49 Pros: Hierarchy allows arbitrary nesting of AND- and OR- superstates. Semantics defined in a follow-up paper to original paper. Large number of commercial simulation tools available (StateMate, StateFlow, BetterState,...) Available back-ends translate StateCharts into C or VHDL, thus enabling software or hardware implementations.

50 Evaluation of StateCharts (2) 50 Cons: Generated C programs frequently inefficient, Not useful for distributed applications, No program constructs, No description of non-functional behavior, No object-orientation, No description of structural hierarchy. Extensions: Module charts for description of structural hierarchy.