Title: Embedded System Design
1Embedded System Design
2Embedded System Design
3Specification
4Requirements for specification techniques (1)
- HierarchyHumans not capable to understand
systems containing more than 5 objects.Most
actual systems require more objects - Behavioral hierarchyExamples states, processes,
procedures. - Structural hierarchyExamples processors, racks,
printed circuit boards - Timing behavior
- State-oriented behavior
- Required for reactive systems
- classical automata insufficient.
5Requirements for specification techniques (2)
- Event-handling (external or internal events)
- No obstacles for efficient implementation
- Support for the design of dependable
systemsUnambiguous 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.
.
6Requirements 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
7Requirements 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
8Modeling and Design
- 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
9Models of computation - Definition -
- How can we (precisely) capture behavior?
- We may think of languages (C, C), but
computation model is the key - Models of computation define Lee, UCB, 1999
- What it means to be a component
- Subroutine? Process? Thread?
- 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)
10Models vs. languages
- 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,
object-oriented model, state machine model - Certain languages better at capturing certain
computation models
11Models and languages
- 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 systems, transforms input data
streams into output streams - Object-oriented model
- For breaking complex software into simpler,
well-defined pieces
12Models of computation- Examples (1) -
- Communicating finite state machines (CFSMs)
- Discrete event model (VHDL, Verilog)
queue
a b c
time action
5 10 13 15 19
13Models of computation- Examples (2) -
- Differential equations (Analog circuits, Physical
Systems)
- Asynchronous message passing (Kahn Process
networks, dataflow models)
- Synchronous message passing (CSP, ADA
rendez-vous)
14StateCharts recap of classical automata
Moore or Mealy automata finite state machines
(FSMs)
Next state Z computed by function ?Output
computed by function ?
e1
Z0
Z1
- Moore-automataY ? (Z) Z ? (X, Z)
- Mealy-automataY ? (X, Z) Z ? (X, Z)
0
1
e1
e1
Z2
Z3
2
3
e1
15StateCharts
- Classical automata not useful for complex systems
- complex graphs cannot be understood by humans
- Introduction of hierarchy ? StateCharts Harel,
1987
16Introducing hierarchy
FSM will be in exactly one of the substates of S
if S is active(either in A or in B or ..)
superstate
substates
17Definitions
- 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 of S is active
whenever S is active.
18Default state mechanism
- Filled circle indicates sub-state entered
whenever super-state is entered. - Allows internal structure to be hidden for
outside world.
19History mechanism
- 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)
20Combining history and default state mechanism
same meaning
21Concurrency
- Convenient ways of describing concurrency are
required. - AND-super-states FSM is in all (immediate)
sub-states of a super-state Example
22Entering and leaving AND-super-states
- Line-monitoring and key-monitoring are entered
and left, when service switch is operated.
incl.
23Types of states
- In StateCharts, states are either
- basic states, or
- AND-super-states, or
- OR-super-states.
24Timers
- 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.
25Using timers in answering machine
26General form of edge labels
- 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 / service0
27The StateCharts simulation phases
- How are edge labels evaluated?
- Three phases
- Effect of external changes on events and
conditions is evaluated, - The set of transitions to be made in the current
step and right hand sides of assignments are
computed, - Transitions become effective, variables obtain
new values. - Separation into phases 2 and 3 guarantees
deterministic and reproducible behavior.
28Example
- 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.
29Reflects model of clocked hardware
In an actual clocked (synchronous) 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.
30Steps
Execution of a StateChart 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
31Broadcast mechanism
- 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 (?).
32Lifetime of events
- Events live until the step following the one in
which they are generated (one shot-events).
33Evaluation of StateCharts (1)
- 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.
34Evaluation of StateCharts (2)
- 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.