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