System-level Design of
Embedded Systems
Franco Fummi
[email protected]
Dip.di Informatica
Università di Verona
Donatella Sciuto
[email protected]
Dip. di Elettronica
Politecnico di Milano
Contents
Hw/Sw
Hw/Sw Systems Description
embedded systems
Architecture
Simulation problem
Modeling problem
Current solution
Hw/Sw
Hw/Sw Synthesis
Hw Performance Evaluation
Sw Performance Evaluation
The role of R.T.O.S.
2
Introduction
Electronic systems consist of:
HW platform
SW application layers
Interfaces
Analog components
Sensors and transducers
Main trends:
Migration from analog to digital processing
Broader systemsystem-level integration to support
SystemSystem-OnOn-a-Chip (SOC) approach
3
Challenges in the design of
embedded systems
increasing application complexity even in standard
and large volume products
large systems with legacy functions
mixture of event driven and data flow tasks
flexiblity requirements
examples: multimedia, automotive, mobile communication
increasing target system complexity
mixture of different technologies, processor types, and design
styles
large systemssystems-onon-a-chip combining components from
different sources (IP market)
numerous constraints and design objectives
reduced and overlapping design cycles
Hardware/software codesign
Hardware/software coco-design:
Combined design of hardware and software
co-design classic design
Goals
design process optimization
Increased design productivity
design optimization
Improved product quality
HW SW
HW SW
Tasks
coco-specification and coco-modeling
coco-verification
coco-design process integration and optimization
design optimization and coco-synthesis
Co-design advantages
Explore different design alternatives in the
architectural design space
Tune HW to SW and vicevice-versa
Reduce the system design time
Support coherent design specification at the
systemsystem-level
Facilitate the rere-use of HW and SW parts
Provide integrated environment for the
synthesis and validation of HW and SW
components
6
Digital system classification
APPLICATION DOMAIN
Computer
Telecom
Automotive
SYSTEM TYPE
General-Purpose Systems
Embedded Systems
PROGRAMMABILITY
Application-level
Instruction-level
Hardware-level
IMPLEMENTATION
Technology
Design style
Level of integration
7
Co-design of embedded systems
Design of dedicated computing and control
systems
Embedded controllers
OnOn-line control of manufacturing process
Robots guidance and control
Aircraft, automobile and ship control
Data processing and communication
systems
Telecom
RadioRadio-navigation
8
Co-design of embedded systems
Design of dedicated HW parts
Different design styles:
CoCo-processors, embedded cores, ASIPs,
ASIPs, ...
Widely varying design scale
Design of dedicated SW parts
SpecialSpecial-purpose operating systems
Drivers of peripheral devices
9
SENSORS
MEMORY
ISP
HARDWIRED UNIT
Application-specific logic
Timers
A/D and D/A Converters
ACTUATORS
Embedded systems
EMBEDDED
SYSTEM
ENVIRONMENT
10
Array-based design
PrePre-Diffused Array or Mask Programmable
Gate Array (MPGA)
PrePre-Wired Array or Field Programmable
Gate Array (FPGA)
SoftSoft-Programmable (Memory based)
HardHard-Programmable (Anti(Anti-fuse based)
11
Integration level
Single chip systems (SOC approach):
ASICs with embedded cores and memories
Cores (microprocessor, microcontroller, DSP, ...)
Multiple chip systems:
ASICs,
ASICs, FPGAs,
FPGAs, …
Memories
Programmable components such as processors,
DSPs or controllers
OffOff-thethe-shelf or proprietary components
Distributed systems
12
Comparison
IP
A SIP
A SIC
Perfo rm ance
+
++
+++
Pow er
+++
++
+
R eu se
+++
++
++
H W d esign effo rt
SW d esign effort
+
+++
++
13
Embedded system requirements
Reactive systems:
The system never stops
The system responds to signals produced by the
environment
RealReal-time systems:
Timing constraints on task evolution
Hard and soft constraints
14
Specific steps in embedded
control design
Architecture selection:
Standard microcontroller or microprocessor
ASIC
ASIC with embedded core or coco-processor
Technology selection for HW resources
Design dedicated HW, SW and interfaces
15
Co-design flow of embedded
systems
Modeling, validation and synthesis
SystemSystem-level simulation
Homogeneous modeling
HW/SW partitioning
HW/SW or SW/HW migration
Heterogeneous modeling
Direct implementation and rere-targeting
CoCo-synthesis
HW and interface synthesis
SW compilation and code generation
CoCo-simulation
16
Embedded systems design
process
support
(CAD, test, ...)
requirements definition
specification
customer/
marketing
system
architect
system architecture development
SW development
• application SW
• compilers etc.
• operating syst.
SW
developer
interface design
• SW driver dev.
• HW interface
synthesis
HW
designer
HW design
• HW architecture design
• HW synthesis
• physical design
integration and test
reused
components
17
Observations on the design
process
Increasingly concurrent design of hardware and
software with partially incomplete or variable
specification
tight and permanent cooperation of hardware and software
designers, system architects and customer/marketing required
Narrow timetime-toto-market windows require a safe
“first“first-timetime-right” design process
early detection of systematic design flaws is crucial
reliable design times and precisely predictable product data are
more important than design time minimization
prerequisite: reliable estimations - today: designer experience
18
Observations on the design
process
Increased productivity through reuse of
components and functions
function and component libraries required
problem: function migration between different technologies,
between hardware and software
19
State of the practice
CoCo-simulation as a support of design
(process) integration
extension of simulation techniques to combined simulation of
hardware and software components
allows permanent control of hardware and software component
consistency
supports early validation of reused component integration
Integration validation more costly with
increasing level of detail
current focus on coco-simulation for lower levels of a
design
simulation with models of specific processors, memories, busses, ...
reduction of accuracy mainly to improve simulation performance
examples: Mentor Seamless CVS, Viewlogic Eagle
State of the practice
“Executable” coco-specification used as a
basis for system validation
Virtual prototyping
simulation based validation
many commercial examples for different
applications
Statemate (i-Logix),
Logix), MatrixX (ISI), MATLAB
(MathWorks)
MathWorks)
RASSP program (DARPA)
Rapid prototyping with “hardware“hardware-ininthethe-loop”
hardware supported system emulation
environment
often custom design
real
State of the practice
Executable coco-specification problems
combination of domain specific languages and
semantics
integration of reused functions and components
in abstract model
inclusion of nonnon-functional constraints
22
Specification languages
Different communities
VLSI system design VHDL, VERILOG, Specchart…
Specchart…
DSP
COSSAP, SPW, …
Continuous design
MATLAB, MATRIXX, ….
Synchronous system design Esterel,
Esterel, Lustre,
Lustre, Statechart
Classical programming C, C++, Java, ….
Functional and algebraic
VDM, Z, B, Funmath,
Funmath, ….
Structured design methods
SART, OMT, ….
23
Concepts for system level
specification
CONCURRENCY
different levels (bit, operation, statement, process,
system)
two types: datadata-driven, controlcontrol-driven
HIERARCHY
needed for structured design methodologies
Two types: behavior, structure
COMMUNICATION
data exchange between concurrent subsystems
two types: message passing, shared memory
SYNCHRONIZATION
Two models: synchronous, asynchronous
24
Example of Specification Language
SDL
wellwell-suited for controlcontrol-intensive, realreal-time
systems
flow chart FSM, both graphics and text
abstract data types
dynamic process creation
synchronization via blocking, RPC
can monitor performance constraints
25
Example of Specification Language
StateCharts,
StateCharts, SpecCharts
graphical FSM of states and transitions
addition of hierarchical states for modeling
complex reactive behaviors
SpecCharts adds
behavioral completion
exceptions
may attach VHDL code to states and
transitions arcs
extended with arithmetics
Easy to use for controlcontrol-dominated systems
26
Petri Nets (1966)
Powerful uninterpreted modeling tool
Describes explicitly and graphically the
main paradigms of concurrent computation:
sequencing/causality
conflict/ nonnon-deterministic choice
concurrency
Asynchronous model (partial ordering)
Main drawback: no hierarchy
27
Structure and firing rule
Bipartite graph
places: represent distributed state by holding
tokens
marking: token count for each place
initial marking = initial state
transitions: represent actions/events
enabled transition: enough tokens in predecessors
firing transition: modifies marking
28
Petri Nets properties
Liveness:
from any marking and
Liveness:
transition can become fireable
Boundeness:
Boundeness: the number of tokens in any
place cannot grow indefinitely
(1(1-bounded also called safe)
safe)
decidable problem
Basic analysis tool for bounded nets:
reachability graph
29
Petri nets extensions
Add interpretation to tokens and transitions
predicate/transition nets
colored nets
Add time
time/timed Petri nets
stochastic Petri nets
Add hierarchy
Petri boxes
Place Chart nets
30
Simulation and debugging
requirements
Embedded controllers:
ASICs plus SW running on a processor
VHDL or Verilog plus C programs
Weakly heterogeneous systems
Embedded data processing and
communication systems
ASICs plus SW running on a processor or ASIP
Environmental modeling (e.g. telephone lines)
Strongly heterogeneous systems
31
Co-simulation
Simulate at the same time both hardware
and software
Two conflicting requirements:
execute the software as fast as possible
keep hardware and software simulations
synchronized so they interact as they will in the
target system.
32
Co-simulation
Desired features:
Level of timing accuracy
Speed of simulation runs
Visibility of internal states
Potential problems:
Meaningful results are obtained with large SW
programs
Model availability
Strong heterogeneity requires specialized
environment
33
Co-simulation paradigms
Homogeneous modeling:
HW models in HDL
Processor model in HDL
SW in assembly code
Usage of HDL simulator for the whole
system including the processor model
Simple method but quite inefficient
34
Co-simulation paradigms
Weakly heterogeneous systems
a) HDL simulators with processor model
b) Compiled SW
c) HW emulation
Strongly heterogeneous systems
Require specialized simulation environments
(e.g. Ptolemy)
Communication mechanisms among domains
and their corresponding schedulers
35
HDL processor modeling
Precise timing model
Accurate timing and complete functionality
EventEvent-driven simulation
ZeroZero-Delay Model (ZDM) for timing
Correct transitions at clock edges
CycleCycle-based simulation
InstructionInstruction-set simulator
Model emulates processor while insuring
correct register and memory values
36
Compiled SW
Basic assumption:
HW/SW communication protocol such that
communication delay has no effect on
functionality
SW is compiled and linked to simulator
HW/SW communication is replaced by
handshake
Simulation speed is limited by HW
simulation speed
37
HW emulation
HW mapped onto programmable HW
One order of magnitude loss in speed
Programmable HW boards connected to
workstations
Limited visibility of internal states
38
Co-synthesis design flow-Principle
OS,
component &
communication
libraries
intermediate
code generation
system function
compilation&
system analysis
HW/SW partitioning
& scheduling
code generation
constraints
and user
directives
HDL generation
HL synthesis
co-simulation,
analysis
object code
HW model
Co-design using co-synthesis and
design space exploration
hardware
designer
customer
•
•
specification parameter
change
high level transformations
OS,
component &
communication
libraries
estimations
software
developer
system
architect
intermediate code
generation
system function
HW/SW partitioning&
scheduling
code generation
object code
constraints and
user directives
compilation&
system analysis
HDL generation
HL synthesis
co-simulation
analysis
cost,
performance, ...
HW model
Modeling Current Solution
Some C++ dialects have been proposed
General idea:
new classes are defined to model hardware
characteristics
no standardization for new classes
SystemC 1.0 (end of 1999)
proposal of standardization
continuous extensions (2.0 ... 3.0)
41
Standard C-based Design Flow
System Level
Model C, C++
Manual converision
VHDL/Verilog
Refine
Analysis
Simulation
Synthesis
Results
FSMD description
42
SystemC-based Design Flow
SystemC Model
System Level
Authomatic translation
VHDL/Verilog
Simulation
Synthesis
Refinement
SystemC Model
RT Level
FSMD Logic
description
43
Contents
Hw/Sw
Hw/Sw Synthesis
Hw Performance Evaluation
Sw Performance Evaluation
The role of O.S.
44
Simple target architecture
ASIC
ASIC
PROC
RAM
A set of dedicated HW units
A programmable core or coco-processor
Memory
Including SW program storage
Interfaces and interconnections
45
Hardware and software synthesis
Implementation of hardware and software
components after partitioning
Constraints and optimization criteria similar to
those for partitioning
Area and code size tradedtraded-off against
performance (dominant for realreal-time systems)
Cost considerations offtheoff the-shelf processor
separation of software and hardware synthesis,
relying on a prepre-designed customizable interface
Exception: synthesis of ASIP and microcode
46
System-level co-synthesis flow
Consistent systemsystem-level modeling
Partitioning into dedicated and programmable
units
HW synthesis of dedicated units
Based on research or commercial standard synthesis
tools
SW synthesis for programmable units
(processors)
Based on specialized compiling techniques
Interface synthesis
Definition of HW/SW interface and synchronization
Drivers of peripheral devices
47
SW synthesis problems
Target architecture is an ASIP
Develop a specific compiler
NonNon-executable systemsystem-level specification
of computercomputer-aided partitioning
Synthesize highhigh-level or assembly code
Interface to HW with given protocol
Synthesize interfacing routines
48
Re-targetable compilers
Compiler technology suitable for different
architectural backback-ends
ASIPs have specific instruction sets, memory
and interconnection resources
Code quality (i.e. execution speed) is
important whereas compilation time is less
critical
Assembly code programming is still
common practice
49
Re-targetable compilers
Portable compilers
Compiler needs significant rere-write for porting
Compiler compilers
Generates compiler from architectural
templates
MachineMachine-independent compilers
Applicable to different architectures
50
Re-targetable compilers
Compile code into intermediate form and
optimize
Standard optimizing compiler algorithms
Instruction selection
Pattern matching techniques
Instruction scheduling
Satisfaction of realreal-time constraints
Register allocation
MicroMicro-code compaction
51
Software synthesis
Constrained problem for embedded software:
no virtual memory, reduced dynamic memory allocation
and dynamic task creation
SW functions identified by program threads
A single processor requires thread serialization
or interleaving of originally concurrent tasks
Scheduling of threads and instructions
Satisfying performance constraints
SystemSystem-level runrun-time scheduler to synchronize
SW and HW functions
52
Sw synthesis from SystemC
Sw processes are isolated from the global
system description
Hw/Sw
Hw/Sw interfaces are generated
SystemC keywords remapped on C++
Software performance measurement
Hw constraints
53
Sw performance measurement
Use of profiling tools
C library linked to executable code (e.g.
GNU gprof)
gprof)
Program execution (problems?)
Program profile
54
Measurement example
% Time
33.34
16.67
16.67
16.67
16.67
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
cumulative
seconds
0.02
0.03
0.04
0.05
0.06
0.06
0.06
0.06
0.06
0.06
0.06
0.06
0.06
0.06
self
seconds
0.02
0.01
0.01
0.01
0.01
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
calls
self
ms/call
total
ms/call
7208
244
8
7
0.00
0.04
1.25
1.43
0.00
0.12
1.25
1.43
236
192
47
45
1
1
1
1
1
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
50.00
0.00
10.11
0.00
50.00
name
open
offtime
memccpy
write
mcount
tzset
tolower
strlen
strchr
main
memcpy
print
profil
report 55
Measurement legenda (1)
% time
This is the percentage of the total execution time your
program spent in this function. These should all add up to
100%.
cumulative seconds
This is the cumulative total number of seconds the computer
spent executing this functions, plus the time spent in all the
functions above this one in this table.
self seconds
This is the number of seconds accounted for by this function
alone.
56
Measurement legenda (2)
calls
This is the total number of times the function was called.
self ms/call
This represents the average number of milliseconds spent in
this function per call, if this function is profiled.
total ms/call
This represents the average number of milliseconds spent in
this function and its descendants per call.
57
Measurement correctness
Sampling period:
period:
time interval between two measurements (e.g.,
0.01 sec. 100hz)
Total execution time:
time:
time window used to make the measurement
(e.g., 0.06 sec.)
number of samples
sampling error
E.g. Write function
58
Definition of testbench
Does testbench affect the measurement?
Yes, definitely!
How to select testbenches:
testbenches:
algorithm information
coverage metrics
branch coverage
statement coverage
condition coverage
path coverage ...
statistical analysis
59
Role of RTOS
Sw works under the RTOS supervision
Hw/Sw
Hw/Sw interchange through RTOS
Main problems:
uniform time definition concept
tasks scheduling
realreal-time performance issues
60
Summary
HW/SW coco-design is a wide and rapid
evolving area
Several application domains, architectures
and implementation styles
Need to define design methodologies with
the goal of developing CAD tool support
The impact of CAD on systemsystem-level design
will be more profound than the impact of
CAD on VLSI design
61