Embedded System Requirements, Specification and Modelling
K. TatasSources:
Hermann Kopetz, “Real-Time Systems: Design Principles for Distributed Embedded Applications”, Springer, 2011Wayne Wolf, “High-Performance Embedded Computing: Architectures, Applications, and Methodologies”, Morgan Kaufmann, 2006Wayne Wolf, “Computers as components: Principles of embedded computing design”, Morgan Kaufmann Publishers, 2000
2
Introduction Distributed Embedded System Models Design/Abstraction Levels Embedded System Design Flow Embedded System Requirements Embedded System Specifications Object-oriented Design Unified Modeling Language (UML) SystemC and TLM
3
Classification of Embedded Systems
Real-time Hard deadline
Failsafe Fail-operational
Soft and firm deadline Non-Real-time
4
Fail-Safe hard-deadline RT systems
If a safe state can be identified and quickly reached upon the occurrence of a failure, then we call the system fail-safe.
Failsafeness is a characteristic of the controlled object, not the computer system.
In case a failure is detected in a railway signaling system, it is possible to set all signals to red and thus stop all the trains in order to bring the system to a safe state.
In failsafe applications the computer system must have a high error-detection coverage.
Often a watchdog, is required to monitor the operation of the computer system and put it in safe state.
5
Fail-Operational hard-deadline RT systems
In fail-operational applications, threre is no safe state a flight control system aboard an
airplane. The computer system must remain
operational and provide a minimal level of service even in the case of a failure to avoid a catastrophe
6
Guaranteed response systems a design that operates correctly even in the
case of a peak load and fault scenario is a system with a guaranteed response.
The probability of failure of a perfect system with guaranteed response is reduced to the probability that the assumptions about the peak load and the number and types of faults do not hold in reality.
This probability is called assumption coverage [Pow95].
Guaranteed response systems require careful planning and extensive analysis during the design phase.
7
Best-effort systems If an analytic response guarantee cannot be
given, we speak of a best-effort design. Best-effort systems do not require a rigorous
specification of the load- and fault-hypothesis. The design proceeds according to best effort the sufficiency of the design is established
during the test and integration phases. It is difficult to establish that a best-effort design
operates correctly in a rare-event scenario. Many non safety-critical real-time systems are
designed as best-effort systems.
8
Resource adequacy Guaranteed response systems are based on the
principle of resource adequacy, i.e., there are enough computing resources available to handle the specified peak load and the fault scenario.
Many non safety-critical real-time system designs are based on the principle of resource inadequacy.
If providing sufficient resources to handle every possible situation is not economically viable, then a dynamic resource allocation strategy based on resource sharing and probabilistic arguments about the expected load and fault scenarios is used
Hard realtime systems must be designed according to the guaranteed response paradigm that requires the availability of adequate resources.
9
Distributed RT system model From the POV of an outside observer, a real-
time (RT) system can be decomposed into three communicating subsystems:
a controlled object (the physical subsystem, the behavior of which is governed by the laws of physics),
a “distributed” computer subsystem (the cyber system, the behavior of which is governed by the programs that are executed on digital computers)
a human user or operator The distributed computer system consists of
computational nodes that interact by the exchange of messages.
A computational node can host one or more computational components.
10
RT System block diagram
11
Example
12
Local clocks Every node of a distributed system has
a local oscillator that ticks with a frequency determined by the physical parameters of the oscillator.
Typical maximum drift rates r of physical clocks are in the range from 10^-2 to 10^-7 us/s, or lower, depending on the quality (and price) of the resonator
Local real-time clocks in each node have a a varying drift rate
13
Clock synchronization The global ticks of all correct nodes must
occur within a specified precision P clock synchronization should not depend
on the correctness of a single clock A subset of the local oscillator’s microticks
is interpreted as the global time ticks at the node.
These global time ticks increment the local node’s global time counter.
14
Event-Triggered Control Versus Time-Triggered Control
Event-triggered control is based on processor interrupts from external devices
Time-triggered control is based on polling external devices at regular intervals
15
Example of event-triggered controlint led = 77;
volatile int state = LOW;
void setup(){ pinMode(led, OUTPUT); attachInterrupt(1, blink, RISING);}
void loop(){ digitalWrite(led, state);}
void blink(){ state = !state;}
16
Example of time-triggered controlint led = 77;int sw = 2;volatile int state = LOW;
void setup(){ pinMode(led, OUTPUT);
digitalWrite(led, state); }
void loop(){ if (digitalRead(sw)==HIGH)
state = !state; delay(1000); }
17
Question
Which time of triggering would be more efficient for an elevator control system?
What do you think are the advantages/disadvantages of each?
18
Power consumption The concept of energy refers to a scalar quantity that
describes the capability of work that can be performed by a system
The intensity of the work, that is the energy used up per unit of time, is called power. Energy is thus the integral of power over time.
There exist different forms of energy, such as potential energy, kinetic energy, thermal energy (heat), electrical energy, chemical energy, and radiation energy
The first law of thermodynamics, relating to the conservation of energy, states that in a closed system, the total sum of all forms of energy is constant.
The second law of thermodynamics states that thermal energy can only be partially transformed to other forms of energy.
19
Energy Estimation
The energy that is needed by a computing device to execute a program can be
expressed as the sum of the following four terms:
20
Computation energy The computation power main
component is dynamic power
And the energy is equal to Ecomp=Ceff*V^2*f*N Where N is the number of executed
instructions
21
Memory energy Memory power consumption is higher
than computation power consumption Depends on the type of memory being
accessed Scratchpad memory that is within an IP-core. Shared on-chip memory accessed via the NoC. Off-chip memory, e.g., a large DRAM, that is
accessed via the NoC and a memory gateway to the memory chip.
gross estimation: a memory access for a 32 bytes block of on-chip memory requires 1000 nJ and access to the off-chip memory requires about twenty times as much, i.e., 20 mJ.
22
Communication Energy
The energy needed by a sender Etx to transport a bit string of k bytes can be approximated by:
while the energy needed by the receiver Erx can be approximated by
23
Energy for wired communication
Etr = d*Ceffunit*V^2 Where d is the distance Ceffunit approx 1 pF/cm in on-chip
interconnect V is the supply voltage
24
Energy for wireless communication
For wireless communication, the transmit energy per bit can be approximated by
Etr = b*d^2
25
ASIC vs FPGA vs CPU power consumption
26
Energy Sources There are three energy sources:
energy from the power grid, energy from a battery energy harvested from the environment
27
Batteries
An erratic power request pattern from the computer system could reduce the nominal battery power by as much as 50%
In this case an ultra capacitor is needed to spikes
28
Example Evaluate the feasibility of an 2AA battery-
powered embedded system with an operating frequency of 500 MHz that:
Is idle 90% of the time There is no computation power when idle When not idle it executes 1 instruction per
clock cycle All instructions come from on-chip memory
and they are four bytes long The effective capacitance is 1nF It sends 1KB/h of data wirelessly to a
distance of 100 m b=100 pJ/(bit/m^2).
29
Design/Abstraction Level
Algorithmic Level
Architecture Level
Register-Transfer Level
Gate Level
Transistor Level
Manual
Manual
Automatic
Automatic
Specification: Document, Pseudocode, block diagramTools: MATLAB, C++, SystemC, etc.Output: Verified algorithm
Specification: Document, block diagram, executableTools: UML, SystemCOutput: Hardware/Software partitioning
Specification: Document, block diagram, executableTools: VHDL, Verilog, SystemVerilog, SystemCOutput: RTL description
30
Embedded System Design Flow Traditional Embedded System
Design Flow
31
Problems with Traditional Design Flow Gaps (manual translation) between
Algorithm and Architecture level, and between Architecture level and RTL
Document specifications can be misinterpreted by design teams
Raising the level of abstraction that allows automatic translation to lower levels is required as system complexity increases
Software has to wait for hardware before being debugged
32
Embedded System Requirements Essentially turning a concept into a
product Asking potential customers,
understanding their needs determining the best feature and
price point Sales and marketing usually
responsible R&D engineers should contribute
33
Embedded System Requirements
Functional: describe each function of the system Input: Output: Processing:
Non-functional: system properties not related to its function
Cost Time-to-market Reliability Portability Maintainability Security
34
Requirements should be Concise:
Brief yet complete and unambiguous Structured:
Requirements should be numbered Black-box view:
Not concerned with implementation Verifiable:
Able to check if they are met by the implementation
35
Example: Digital Camera Requirements Draft Functional:
R1. Image capture Input: Light from lens Output: Pixels corresponding to light at 10.2 Mpixels
R2. Image compression Input: Pixels of uncompressed image Output: Pixels of compressed image (compression ratio: 4:1)
R3. Image Display Input: Pixels of compressed image Output: Pixels of display on 4x3 inch LCD display
R3.1 Zoom Image display Input: Pixels of compressed image, zoom area, zoom ratio Output: Pixels of display at
R4. Image transfer Input: Pixels of compressed image Output: USB stream of pixels of compressed image
36
Example: Digital Camera Requirements Draft
Non-Functional: R5. Cost: 150€ R6. Weight: 800 g R7. Power consumption (number of
photographs away from mains) R8. Security
37
Embedded System Specifications Natural language specifications are
attractive and still used. However, it lacks key requirements for specification techniques:
necessary to check specifications for completeness
absence of contradictions should be possible to derive
implementations from the specification in a systematic way
Therefore, specifications should be captured in machine readable, formal languages.
38
Some required features of Specification languages
Hierarchy: Humans can only handle few objects Behavioral Structural
Timing: Real-time operation Event-handling: Reactive
External events Internal events
Concurrency: Hardware inherently concurrent Synchronization and communication: Executability: Should not be misinterpreted Readability: Both human and machine readable Portability: Should not be machine-dependent
39
System modeling
Need languages to describe systems: useful across several levels of
abstraction; understandable within and between
organizations. Block diagrams are a start, but
don’t cover everything.
40
Object-oriented design (1/3)
It encourages the design to be described as a number of interacting objects, rather than a few monolithic blocks of code
At least some of those objects will correspond to real pieces of software or hardware in the system. We can also use UML to model the outside world that interacts with our system.
41
Object-oriented design (2/3)
Object-oriented specification can be seen in two complementary ways:
Object-oriented specification allows a system to be described in a way that closely models real-world objects and their interactions
Object-oriented specification provides a basic set of primitives that can be used to describe a systems with particular attributes, irrespective of the relationships of those system’s components to real-world objects.
42
Object-oriented design (3/3)
Object-oriented (OO) design: A generalization of object-oriented programming.
Object = state + methods. State provides each object with its
own identity. Methods provide an abstract interface
to the object.
43
OO implementation in C++
class display {pixels : pixeltype[IMAX,JMAX];
public:display() { }pixeltype pixel(int i, int j) { return pixels[i,j]; }void set_pixel(pixeltype val, int i, int j) { pixels[i,j] = val; }
}
44
OO implementation in C
typedef struct { pixels: pixeltype[IMAX,JMAX]; } display;
display d1;pixeltype pixelval(pixel *px, int i, int j) { return px[i,j]; }
45
Objects and classes
Class: object type. Class defines the object’s state
elements but state values may change over time.
Class defines the methods used to interact with all objects of that type. Each object has its own state.
46
OO design principles
Some objects will closely correspond to real-world objects. Some objects may be useful only for
description or implementation. Objects provide interfaces to
read/write state, hiding the object’s implementation from the rest of the system.
47
UML
Developed by Booch et al. Goals:
object-oriented; visual; useful at many levels of abstraction; usable for all aspects of design.
48
UML diagrams (1/2) Structural Modeling Diagrams
Structure diagrams define the static architecture of a model. Package diagrams are used to divide the model into logical
containers, or 'packages', and describe the interactions between them at a high level.
Class or Structural diagrams define the basic building blocks of a model: the types, classes and general materials used to construct a full model.
Object diagrams show how instances of structural elements are related and used at run-time
Composite Structure diagrams provide a means of layering an element's structure and focusing on inner detail, construction and relationships
Component diagrams are used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface
Deployment diagrams show the physical disposition of significant artifacts within a real-world setting.
49
UML diagrams (2/2) Behavioral Modeling Diagrams
Behavior diagrams capture the varieties of interaction and instantaneous states within a model as it 'executes' over time
Use Case diagrams are used to model user/system interactions. They define behavior, requirements and constraints in the form of scripts or scenarios.
Activity diagrams have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process.
State Machine diagrams are essential to understanding the instant to instant condition, or "run state" of a model when it executes.
Communication diagrams show the network, and sequence, of messages or communications between objects at run-time, during a collaboration instance.
Sequence diagrams are closely related to communication diagrams and show the sequence of messages passed between objects using a vertical timeline.
Timing diagrams fuse sequence and state diagrams to provide a view of an object's state over time, and messages which modify that state.
Interaction Overview diagrams fuse activity and sequence diagrams to allow interaction fragments to be easily combined with decision points and flows.
50
Activity Diagram
51
Use Case Diagram
52
Sequence Diagram
53
Collaboration Diagram
54
UML object
d1: Display
pixels: array[] of pixelselementsmenu_items
pixels is a2-D array
comment
object nameclass name
attributes
55
Class Diagram
56
UML class
Display
pixelselementsmenu_items
mouse_click()draw_box
operations
class name
57
The class interface
The operations provide the abstract interface between the class’s implementation and other classes.
Operations may have arguments, return values.
An operation can examine and/or modify the object’s state.
58
Choose your interface properly If the interface is too small/specialized:
object is hard to use for even one application; even harder to reuse.
If the interface is too large: class becomes too cumbersome for designers
to understand; implementation may be too slow; spec and implementation are probably buggy.
59
Relationships between objects and classes
Association: objects communicate but one does not own the other.
Aggregation: a complex object is made of several smaller objects.
Composition: aggregation in which owner does not allow access to its components.
Generalization: define one class in terms of another.
60
Class derivation
May want to define one class in terms of another. Derived class inherits attributes,
operations of base class.
Derived_class
Base_class
UMLgeneralization
61
Class derivation exampleDisplay
pixelselementsmenu_items
pixel()set_pixel()mouse_click()draw_box
BW_display Color_map_display
baseclass
derived class
62
Multiple inheritance
Speaker Display
Multimedia_display
base classes
derived class
63
Links and associations
Link: describes relationships between objects.
Association: describes relationship between classes.
64
Link example Link defines the contains relationship:
message
msg = msg1length = 1102
message
msg = msg2length = 2114
message set
count = 2
65
Association example
message
msg: ADPCM_streamlength : integer
message set
count : integer
0..* 1
contains
# contained messages # containing message sets
66
Stereotypes
Stereotype: recurring combination of elements in an object or class.
Example: <<foo>>
67
Behavioral description
Several ways to describe behavior: internal view; external view.
68
State machines
a b
state state name
transition
69
Event-driven state machines
Behavioral descriptions are written as event-driven state machines. Machine changes state when
receiving an input. An event may come from inside or
outside of the system.
70
Types of events
Signal: asynchronous event. Call: synchronized communication. Timer: activated by time.
71
Signal event
<<signal>>mouse_click
leftorright: buttonx, y: position
declaration
a
b
mouse_click(x,y,button)
event description
72
Call event
c d
draw_box(10,5,3,2,blue)
73
Timer event
e f
tm(time-value)
74
Example state machine
regionfound
got menuitem
calledmenu item
foundobject
objecthighlighted
start
finish
mouse_click(x,y,button)/find_region(region)
input/outputregion = menu/which_menu(i) call_menu(I)
region = drawing/find_object(objid) highlight(objid)
75
Sequence diagram
Shows sequence of operations over time.
Relates behaviors of multiple objects.
76
Sequence diagram example
m: Mouse d1: Display u: Menu
mouse_click(x,y,button)which_menu(x,y,i)
call_menu(i)
time
77
Component Diagrams
78
Deployment Diagrams
79
Example
Write a brief requirements document for an ATM
Use UML diagrams to specify ATM functionality
80
Traditional Design Methodology
81
Languages traditionally used in Embedded System Design
Specification/modeling UML SDL C/C++
Hardware design VHDL Verilog
Software design C/C++ Java Assembly
Verification VHDL/Verilog SystemVerilog Tcl/tk Vera
82
C/C++ unsuitable to describe hardware
No support for Signals, protocols No notion of time, Clocks, time sequenced
operations No concurrency (Hardware is inherently
concurrent, operates in parallel) No reactivity No hardware data types (Bit type, bit-vector
type, multi-valued logic types, signed and unsigned integer types, fixed-point types)
83
SystemC A library of C++ classes
Processes (for concurrency) Clocks (for time) Modules, ports, signals (for hierarchy) Waiting, watching (for reactivity) Hardware data types
A modeling style for modeling systems consisting of multiple
design domains, abstraction levels, architectural components, real-life constraints
A light-weight simulation kernel for high-speed cycle-accurate simulation
84
Design Language Comparison
UML Matlab SystemC SystemVerilog Verilog VHDL Vera
Requirements YES YES YES NO NO NO NO
Architecture YES YES YES NO NO NO NO
HW/SW NO NO YES NO NO NO NO
Behavior NO NO YES YES NO YES NO
Functional Verification
NO NO YES YES NO NO YES
Testbench NO NO YES YES YES YES YES
RTL NO NO YES YES YES YES NO
Gates NO NO NO YES YES YES NO
Transistors NO NO NO YES YES NO NO
85
SystemC v1.0
VHDL-like capabilities Simulation kernel Fixed point arithmetic data types Signals (communication channels) Modules Module hierarchy
86
C++ fundamental concepts
Classes: User-defined types Variables and functions can be
declared in a class Objects: Class instance Constructor: Function for
initializing objects
87
SystemC v1.0 Modules are basic building blocks of a SystemC design
A module contains processes (functionality) and/or sub-modules (hierarchical structure)
SC_MODULE( module_name ) {// Declaration of module ports// Declaration of module signals// Declaration of processes// Declaration of sub-modulesSC_CTOR( module_name ) { // Module constructor// Specification of process type and sensitivity// Sub-module instantiation and port mapping}// Initialization of module signals};
88
Ports External interface of a module Passing data from and to processes / sub-modules Triggering of actions within the module A port has a mode (direction) and a type
mode: in, out, inout type: C++ type, SystemC type, user-defined type// input port declarationsc_in< type > in_port_name;// output port declarationsc_out< type > out_port_name;// bidirectional port declarationsc_inout< type > inout_port_name;
Vector port / port array: sc_out< int > result [32];
89
Signals Connects a port of one module to the port of
another module Local to a module Signal semantics is the same as VHDL and Verilog
deferred assignment semantics A signal has a type: C++ type, SystemC type,
user-defined type// signal declarationsc_signal< type > signal_name;
Vector signal / signal array:sc_signal< double > a[4];
Internal data storage not by signals but by local variables
Local variable types: C++ types, SystemC types, user-defined types
90
Clocks SystemC provides a special object sc_clock Clocks generate timing signals to synchronize
events Multiple clocks with arbitrary phase relations are
supported Clock generation:
sc_clock clock_name (“label”, period, duty_ratio, offset, start_value);
Example: sc_clock my_clk (“CLK”, 20, 0.5, 5, true);
Clock binding: Example: my_module.clk( my_clk.signal() );
91
SystemC data types sc_bit: 2-value single bit (‘0’, ‘1’) sc_logic: 4-value single bit (‘0’, ‘1’, ‘X’, ‘Z’) sc_int: 1 to 64 bit signed integer sc_uint: 1 to 64 bit unsigned integer sc_bigint: arbitrary sized signed integer sc_biguint: arbitrary sized unsigned integer sc_bv: arbitrary length 2-value vector sc_lv: arbitrary length 4-value vector sc_fixed: templated signed fixed point sc_ufixed: templated unsigned fixed point sc_fix: untemplated signed fixed point sc_ufix: untemplated unsigned fixed point
92
Templated signed fixed point type: sc_fixed
sc_fixed< wl, iwl, q_mode, o_mode, n_bits > var_name (init_val);
Arguments: wl - total number of bits iwl - number of integer bits q_mode - quantization mode (optional) o_mode - overflow_mode (optional) n_bits - number of bits for overflow
mode (optional)
93
Templated signed fixed point type: sc_fixed
94
Hierarchy
95
Hierarchy
96
Processes
97
SystemC v2.0
Complete library rewrite to upgrade into true SLDL
Events as primitive behavior triggers
Channels, Interfaces and Ports Much more powerful modeling
for Transaction Level
98
SystemC 3.0 (future)
Modeling of OSs Support of embedded S/W
models
99
Transaction-Level Modeling (TLM) with SystemC
TLM simulation is 100-10,000 times faster than RTL simulation
100
Interfaces, ports/exports, signals
101
Events
Three types of notification Instant (same time, same delta) Delayed (same time, next delta) Annotated (after annotated time)
102
Simulation time If modeling at RTL, SystemC is not faster
than VHDL Simulation is faster when modeling at
higher level of abstraction Keep events to a minimum (use single events
instead of signals for synchronization) Use native C++ data types instead of
SystemC (VHDL-like) Use pointers instead of copying data
103
Coding Styles
Untimed modeling (UT) Loosely-timed modeling (LT) Approximately-timed modeling
(AT)
104
Untimed Model A functional model that can minimally
consist of a single execution thread No notion of time Can be executed without passage of
simulation time Useful for
validating algorithm partitioning into blocks Developing software on untimed model of
hardware Not useful for performance analysis
105
Loosely-timed model
Uses set of interfaces that allows delay annotation
Communication is structured in two phases Begin request Begin response
106
Loosely-timed modeling
Simulation time advances in quantums
107
Approximately-timed modeling
108
TLM Design Flow
Implement algorithm in software Create algorithmic system level as
functional reference and partition into modules
Refine to LT model Perform HW/SW trade-off analysis Refine to AT