1. Embedded System Requirements, Specification and Modelling
K. Tatas
Sources:
Hermann Kopetz, “Real-Time Systems: Design Principles for Distributed Embedded Applications”, Springer, 2011
Wayne Wolf, “High-Performance Embedded Computing: Architectures, Applications, and Methodologies”, Morgan Kaufmann, 2006
Wayne 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 control
int 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 control
int 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

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
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 object name class name d1: Display pixels is a 2-D array
pixels: array[] of pixels
elements
menu_items
attributes
comment

55. Class Diagram

56. UML class Display class name pixels elements menu_items mouse_click()
draw_box
operations

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
UML
generalization
Base_class

61. Class derivation example
Display
base
class
pixels
elements
menu_items
pixel()
set_pixel()
mouse_click()
draw_box
derived class
BW_display
Color_map_display

62. Multiple inheritance base classes Speaker Display Multimedia_display
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 = msg1
length = 1102
message set
count = 2
message
msg = msg2
length = 2114

65. Association example # contained messages # containing message sets
0..* 1
msg: ADPCM_stream
length : integer
count : integer
contains

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
transition a b
state
state name

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 a leftorright: button
x, y: position
mouse_click(x,y,button) b
declaration
event description

72. Call event
draw_box(10,5,3,2,blue) c d

73. Timer event
tm(time-value) e f

74. Example state machine start finish input/output region found got menu
region = menu/
which_menu(i)
mouse_click(x,y,button)/
find_region(region)
call_menu(I)
region
found
got menu
item
called
menu item
region = drawing/
find_object(objid)
highlight(objid)
object
highlighted
found
object

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)
time
call_menu(i)

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 A modeling style
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 NO
Architecture
HW/SW
Behavior
Functional Verification
Testbench
RTL
Gates
Transistors

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-modules
SC_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 declaration
sc_in< type > in_port_name;
// output port declaration
sc_out< type > out_port_name;
// bidirectional port declaration
sc_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 declaration
sc_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 ,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