Upload
phungdat
View
222
Download
0
Embed Size (px)
Citation preview
1
- 1 -Prof. C. SILVANO, Politecnico di Milano, 2004
Introduction to HW/SW Co-Design of Embedded Systems
Prof. Cristina SILVANOPolitecnico di Milano
Dipartimento di Elettronica e Informazione P.za L. Da Vinci 32, I-20133 Milano (Italy)
Ph.: +39-02-2399-3692 e-mail: [email protected]
Web site: http://www.elet.polimi.it/~silvano
- 2 -Prof. C. SILVANO, Politecnico di Milano, 2004
Outline
• Embedded Systems Overview
• Design Methodologies
• Hardware-Software Co-Design Flow
• Optimizing Design Metrics
• Design Technologies
• Design Productivity Gap
• Embedded Systems Overview
• Design Methodologies
• Hardware-Software Co-Design Flow
• Optimizing Design Metrics
• Design Technologies
• Design Productivity Gap
2
- 3 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Systems Overview
- 4 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Systems Overview
• Computing systems are everywhere• Most of us think of “desktop” computers
– PC’s– Laptops– Mainframes– Servers
• But there’s another type of computing system– Far more common...
• Computing systems are everywhere• Most of us think of “desktop” computers
– PC’s– Laptops– Mainframes– Servers
• But there’s another type of computing system– Far more common...
3
- 5 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Systems Overview
• Embedded computing systems– Computing systems embedded
within electronic devices– Hard to define. Nearly any
computing system other than a desktop computer
– Billions of units produced yearly, versus millions of desktop units
– Perhaps 50 per household and per automobile
• Embedded computing systems– Computing systems embedded
within electronic devices– Hard to define. Nearly any
computing system other than a desktop computer
– Billions of units produced yearly, versus millions of desktop units
– Perhaps 50 per household and per automobile
Embedded systems are in here...
and here...
and even here...
- 6 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Systems
Main reason for buying is not information processing
Embedded systems (ES) = information processing systems embedded into a larger product
Examples:
4
- 7 -Prof. C. SILVANO, Politecnico di Milano, 2004
Application Areas (1)
• Automotive electronics
• Aircraft electronics
• Trains
• Telecommunication
• Automotive electronics
• Aircraft electronics
• Trains
• Telecommunication
- 8 -Prof. C. SILVANO, Politecnico di Milano, 2004
Application Areas (2)
• Authentication• Authentication
• Military applications• Military applications
• Medical systems• Medical systems
5
- 9 -Prof. C. SILVANO, Politecnico di Milano, 2004
Application Areas (3)
• Consumer electronics• Consumer electronics
• Smart buildings• Smart buildings
• Fabrication equipment• Fabrication equipment
- 10 -Prof. C. SILVANO, Politecnico di Milano, 2004
Application Areas (4)
• Robotics• Robotics
Robot „Johnnie“ (Courtesy and ©: H.Ulbrich, F. Pfeiffer, TU München)
6
- 11 -Prof. C. SILVANO, Politecnico di Milano, 2004
A “short list” of embedded systems
Anti-lock brakesAuto-focus camerasAutomatic teller machinesAutomatic toll systemsAutomatic transmissionAvionic systemsBattery chargersCamcordersCell phonesCell-phone base stationsCordless phonesCruise controlCurbside check-in systemsDigital camerasDisk drivesElectronic card readersElectronic instrumentsElectronic toys/gamesFactory controlFax machinesFingerprint identifiersHome security systemsLife-support systemsMedical testing systems
ModemsMPEG decodersNetwork cardsNetwork switches/routersOn-board navigationPagersPhotocopiersPoint-of-sale systemsPortable video gamesPrintersSatellite phonesScannersSmart ovens/dishwashersSpeech recognizersStereo systemsTeleconferencing systemsTelevisionsTemperature controllersTheft tracking systemsTV set-top boxesVCR’s, DVD playersVideo game consolesVideo phonesWashers and dryers
- 12 -Prof. C. SILVANO, Politecnico di Milano, 2004
An embedded system example:Digital camera
• Single-functioned: Always a digital camera• Tightly-constrained: Low cost, low power,
small, fast• Reactive and real-time: Only to a small
extent
Microcontroller
CCD preprocessor Pixel coprocessorA2D
D2A
JPEG codec
DMA controller
Memory controller ISA bus interface UART LCD ctrl
Display ctrl
Multiplier/Accum
Digital camera chip
lens
CCD
7
- 13 -Prof. C. SILVANO, Politecnico di Milano, 2004
Some common characteristics of embedded systems
• Single-functioned– Executes a single program, repeatedly
• Tightly-constrained– Low cost, low power, small, fast, etc.
• Reactive and real-time– Continually reacts to changes in the
system’s environment– Must compute certain results in real-time
without delay
• Single-functioned– Executes a single program, repeatedly
• Tightly-constrained– Low cost, low power, small, fast, etc.
• Reactive and real-time– Continually reacts to changes in the
system’s environment– Must compute certain results in real-time
without delay
- 14 -Prof. C. SILVANO, Politecnico di Milano, 2004
Characteristics of Embedded Systems (1)
• Must be dependable,• Reliability R(t) = probability of system working
correctly provided that is was working at t=0• Maintainability M(d) = probability of system working
correctly d time units after error occurred.• Availability: probability of system working at time t• Safety: no harm to be caused• Security: confidential and authentic communication• Even perfectly designed systems can fail if the
assumptions about the workload and possible errors turn out to be wrong.
• Making the system dependable must not be an after-thought, it must be considered from the very beginning
• Must be dependable,• Reliability R(t) = probability of system working
correctly provided that is was working at t=0• Maintainability M(d) = probability of system working
correctly d time units after error occurred.• Availability: probability of system working at time t• Safety: no harm to be caused• Security: confidential and authentic communication• Even perfectly designed systems can fail if the
assumptions about the workload and possible errors turn out to be wrong.
• Making the system dependable must not be an after-thought, it must be considered from the very beginning
8
- 15 -Prof. C. SILVANO, Politecnico di Milano, 2004
Characteristics of Embedded Systems (2)
• Must be efficient– Energy efficient– Code-size efficient (especially for systems on a chip)– Run-time efficient– Weight efficient– Cost efficient
• Dedicated towards a certain application
• Dedicated user interface(no mouse, keyboard and screen)
• Must be efficient– Energy efficient– Code-size efficient (especially for systems on a chip)– Run-time efficient– Weight efficient– Cost efficient
• Dedicated towards a certain application
• Dedicated user interface(no mouse, keyboard and screen)
- 16 -Prof. C. SILVANO, Politecnico di Milano, 2004
Characteristics of Embedded Systems (3)
• Many ES must meet real-time constraints– A real-time system must react to stimuli from
the controlled object (or the operator) within the time interval dictated by the environment.
– For real-time systems, right answers arriving too late are wrong.
– „A real-time constraint is called hard, if not meeting that constraint could result in a catastrophe“ [Kopetz, 1997].
– All other time-constraints are called soft.
• Many ES must meet real-time constraints– A real-time system must react to stimuli from
the controlled object (or the operator) within the time interval dictated by the environment.
– For real-time systems, right answers arriving too late are wrong.
– „A real-time constraint is called hard, if not meeting that constraint could result in a catastrophe“ [Kopetz, 1997].
– All other time-constraints are called soft.
9
- 17 -Prof. C. SILVANO, Politecnico di Milano, 2004
Characteristics of Embedded Systems (4)
• Frequently connected to physical environment through sensors and actuators,
• Hybrid systems(analog + digital parts).
• Typically, ES are reactive systems:„A reactive system is one which is in continual interaction with is environment and executes at a pace determined by that environment“ [Bergé, 1995]
Behavior depends on input and current state.Automata model appropriate,model of computable functions inappropriate.
• Frequently connected to physical environment through sensors and actuators,
• Hybrid systems(analog + digital parts).
• Typically, ES are reactive systems:„A reactive system is one which is in continual interaction with is environment and executes at a pace determined by that environment“ [Bergé, 1995]
Behavior depends on input and current state.Automata model appropriate,model of computable functions inappropriate.
- 18 -Prof. C. SILVANO, Politecnico di Milano, 2004
Characteristics of Embedded Systems (5)
Not every ES has all of the above characteristics.
Def.: Information processing systems having most of the above characteristics are called embedded systems.
Methodologies for embedded systems design makes sense because of the number of common characteristics.
Not every ES has all of the above characteristics.
Def.: Information processing systems having most of the above characteristics are called embedded systems.
Methodologies for embedded systems design makes sense because of the number of common characteristics.
10
- 19 -Prof. C. SILVANO, Politecnico di Milano, 2004
IC Technology towards the System-On-Chip Approach
- 20 -Prof. C. SILVANO, Politecnico di Milano, 2004
IC Technology towards the System-On-Chip Approach
Satellite (DVB) VideoBroadcasting
Multimedia GameSystem
Wireless GSM Pocket Communicator
•Evolution of microelectronic technology, design methodology and EDA tool enables the System-On-Chip (SOC) approach.
11
- 21 -Prof. C. SILVANO, Politecnico di Milano, 2004
System-On-Chip Approach
• The evolution of SOC approach opens new perspectives to HW/SW codesign.
• Specification languages and system-levelmodelling assume fundamental importance to support mixed HW/SW descriptions.
• Based on integration of off-the-shelf blocks as core processors and reuse of IP (Intellectual Property) blocks and cells.
• The evolution of SOC approach opens new perspectives to HW/SW codesign.
• Specification languages and system-levelmodelling assume fundamental importance to support mixed HW/SW descriptions.
• Based on integration of off-the-shelf blocks as core processors and reuse of IP (Intellectual Property) blocks and cells.
- 22 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded systemsand ubiquitous computing
Ubiquitous (or pervasive) computing: Information available anytime, anywhere.
Embedded systems provide fundamental technology.
Ubiquitous (or pervasive) computing: Information available anytime, anywhere.
Embedded systems provide fundamental technology.
Ist.gif
UMTS,
12
- 23 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Systems Market
• Growing economical importance of embedded systems– .. but embedded chips form the backbone of the
electronics driven world in which we live ... they are part of almost everything that runs on electricity[Mary Ryan, EEDesign, 1995]
– 79% of all high-end processors are used in embedded systems
– THE growing area, according to all forecasts
• Growing economical importance of embedded systems– .. but embedded chips form the backbone of the
electronics driven world in which we live ... they are part of almost everything that runs on electricity[Mary Ryan, EEDesign, 1995]
– 79% of all high-end processors are used in embedded systems
– THE growing area, according to all forecasts
- 24 -Prof. C. SILVANO, Politecnico di Milano, 2004
Importance of Embedded Softwareand Embedded Processors
“... the New York Times has estimated that the average American comes into contact with about 60 micro-processors every day....” [Camposano, 1996]
Latest top-level BMWs contain over 100 micro-processors
Most of the functionality of embedded systemswill be implemented in software!
... it is now common knowledge that more than 70% of the development cost for complex systems such as automotive electronics and communication systems are due to software development[A. Sangiovanni-Vincentelli, 1999]
13
- 25 -Prof. C. SILVANO, Politecnico di Milano, 2004
[Fritz Vaandrager in: Rozenberg, Vaandrager (eds.):Lectures on Embedded Systems, LNCS, Vol. 1494, 1998]
... dramatic growth of the number of embedded applications and the size and the complexity of the software used in these applications.
For many products in the area of consumer electronics the amount of code is doubling every two years.
... dramatic growth of the number of embedded applications and the size and the complexity of the software used in these applications.
For many products in the area of consumer electronics the amount of code is doubling every two years.
Importance of Embedded Softwareand Embedded Processors
- 26 -Prof. C. SILVANO, Politecnico di Milano, 2004
• It is estimated that each year embedded software is written five times as much as 'regular' software
• The vast majority of CPU-chips produced world-wide today are used in the embedded market ... ; only a small portion of CPU's is applied in PC's
• ... the number of software-constructors of Embedded Systems will rise from 2 million in 1994 to 10 million in 2010;... the number of constructors employed by software-producers 'merely' rises from 0.6 million to 1.1 million.
• It is estimated that each year embedded software is written five times as much as 'regular' software
• The vast majority of CPU-chips produced world-wide today are used in the embedded market ... ; only a small portion of CPU's is applied in PC's
• ... the number of software-constructors of Embedded Systems will rise from 2 million in 1994 to 10 million in 2010;... the number of constructors employed by software-producers 'merely' rises from 0.6 million to 1.1 million.
[Department of Trade and Industry/ IDC Benelux BV: Embedded software research in the Netherlands. Analysis and results, 1997(according to: www.scintilla.utwente.nl/shintabi/engels/thema_text.html)]
Views on embedded software
14
- 27 -Prof. C. SILVANO, Politecnico di Milano, 2004
Cost of Software in Embedded Systems
- 28 -Prof. C. SILVANO, Politecnico di Milano, 2004
What‘s the problem?
If embedded systems will be implemented mostly in software, then why don‘t we just use what software engineers have come up with?
15
- 29 -Prof. C. SILVANO, Politecnico di Milano, 2004
Some open problems
• How can we capture the required behavior of complexsystems ?
• How do we validate specifications?• How do we translate specifications efficiently intoimplementation?
• Do software engineers ever consider power dissipation?• How can we check that we meet real-time constraints?• Which programming language provides real-time features?• How do we validate embedded real-time software?(large volumes of data, testing may be safety-critical)
• How can we capture the required behavior of complexsystems ?
• How do we validate specifications?• How do we translate specifications efficiently intoimplementation?
• Do software engineers ever consider power dissipation?• How can we check that we meet real-time constraints?• Which programming language provides real-time features?• How do we validate embedded real-time software?(large volumes of data, testing may be safety-critical)
- 30 -Prof. C. SILVANO, Politecnico di Milano, 2004
The co-design ladder
• In the past:– Hardware and software
design technologies were very different
– Recent maturation of synthesis enables a unified view of hardware and software
• Now:– Hardware/software
“codesign”
• In the past:– Hardware and software
design technologies were very different
– Recent maturation of synthesis enables a unified view of hardware and software
• Now:– Hardware/software
“codesign”
Implementation
Assembly instructions
Machine instructions
Register transfers
Compilers(1960's,1970's)
Assemblers, linkers(1950's, 1960's)
Behavioral synthesis(1990's)
RT synthesis(1980's, 1990's)
Logic synthesis(1970's, 1980's)
Microprocessor plus program bits: “software”
VLSI, ASIC, or PLD implementation: “hardware”
Logic gates
Logic equations / FSM's
Sequential program code (e.g., C, VHDL)
The choice of hardware versus software for a particular function is simply a tradeoff among various design metrics, like performance, power, size, NRE cost, and especially flexibility;
there is no fundamental difference between what hardware or software can implement.
16
- 31 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design Methodologies
- 32 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design Methodologies
• A procedure for designing a system• Many systems are complex and pose many
design challenges: Large specifications, short time-to-market, high performance, multiple designers, interface to manufacturing.
• Proper design methodology helps to manage the design process and improves quality, performance and design costs
• A procedure for designing a system• Many systems are complex and pose many
design challenges: Large specifications, short time-to-market, high performance, multiple designers, interface to manufacturing.
• Proper design methodology helps to manage the design process and improves quality, performance and design costs
17
- 33 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design Flow
• A sequence of design steps in a design methodology
• The design flow can be partially or fully automated
• A set or tools can be used to automate the methodology steps: – Software engineering tools, – Compilers, – Computer-Aided Design tools, – etc.
• A sequence of design steps in a design methodology
• The design flow can be partially or fully automated
• A set or tools can be used to automate the methodology steps: – Software engineering tools, – Compilers, – Computer-Aided Design tools, – etc.
- 34 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design goals
• To provide the target functionality and user interface meeting the system level requirements in terms of:– Performance (latency and throughput)– Power consumption– Design and manufacturing costs– Other requirements (physical size, weight,
etc.)
• To provide the target functionality and user interface meeting the system level requirements in terms of:– Performance (latency and throughput)– Power consumption– Design and manufacturing costs– Other requirements (physical size, weight,
etc.)
18
- 35 -Prof. C. SILVANO, Politecnico di Milano, 2004
A simplified design flow
Architecture Definition
System-Level Requirements
System-Level Specification
HW Design SW Design
System Integrationand Validation
- 36 -Prof. C. SILVANO, Politecnico di Milano, 2004
System-Level Requirements
• Plain language description of what the user wants and expects to gets
• May be developed in several ways: talking directly to customers, talking to marketing representative, etc.
• Functional requirements:– To describe outputs as a function of inputs
• Non-functional requirements:– Performance (latency and throughput),
power consumption, reliability, sizes, weight, reliability, etc.
• Plain language description of what the user wants and expects to gets
• May be developed in several ways: talking directly to customers, talking to marketing representative, etc.
• Functional requirements:– To describe outputs as a function of inputs
• Non-functional requirements:– Performance (latency and throughput),
power consumption, reliability, sizes, weight, reliability, etc.
19
- 37 -Prof. C. SILVANO, Politecnico di Milano, 2004
System-Level Specification
• A more precise description of the system behavior– Should not yet imply a target architecture– Provides inputs to the architecture design
process• May include functional and non-functional
requirements• May be executable for simulation or may be
in mathematical form for formal verification.
• A more precise description of the system behavior– Should not yet imply a target architecture– Provides inputs to the architecture design
process• May include functional and non-functional
requirements• May be executable for simulation or may be
in mathematical form for formal verification.
- 38 -Prof. C. SILVANO, Politecnico di Milano, 2004
Architecture Design
• How HW and SW components can satisfy the specification?
• HW Components:– Processor, Memory, Peripherals, etc.
• SW Components:– Programs and their operations
• Some components are already available (design reuse), some can be modified from existing designs, some others must be designed from scratch
• How HW and SW components can satisfy the specification?
• HW Components:– Processor, Memory, Peripherals, etc.
• SW Components:– Programs and their operations
• Some components are already available (design reuse), some can be modified from existing designs, some others must be designed from scratch
20
- 39 -Prof. C. SILVANO, Politecnico di Milano, 2004
System Integration
• Put together the HW and SW components of the system
• The components can be:– Executable models– Physical prototypes
• The system integration phase is crucial to validate the interaction among the different system components.
• Many system-level bugs can be discovered only at this stage
• It would be convenient to validate system integration as early as possible!
• Put together the HW and SW components of the system
• The components can be:– Executable models– Physical prototypes
• The system integration phase is crucial to validate the interaction among the different system components.
• Many system-level bugs can be discovered only at this stage
• It would be convenient to validate system integration as early as possible!
- 40 -Prof. C. SILVANO, Politecnico di Milano, 2004
Levels of Abstraction
•Define the levels of detail in the description of the component and system models:–System Level–Behavioral Level–Architectural or RT (Register Transfer) Level
–Logic Level–Layout Level
21
- 41 -Prof. C. SILVANO, Politecnico di Milano, 2004
Top-down Design Approach
• Top-down design approach:– Start from the most abstract description
down to the most detailed low-level description
– Stepwise refinement process:• At each level of abstraction, we must
analyze the design to determine the characteristics of the current state of the design
• To refine the design descriptions by adding details.
• Top-down design approach:– Start from the most abstract description
down to the most detailed low-level description
– Stepwise refinement process:• At each level of abstraction, we must
analyze the design to determine the characteristics of the current state of the design
• To refine the design descriptions by adding details.
- 42 -Prof. C. SILVANO, Politecnico di Milano, 2004
Bottom-up Design Approach
• Bottom-up design approach:– Start from small component design to
system integration– Based on the Reuse of Intellectual
Property (IP) components
• Bottom-up design approach:– Start from small component design to
system integration– Based on the Reuse of Intellectual
Property (IP) components
22
- 43 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Co-design Flow
- 44 -Prof. C. SILVANO, Politecnico di Milano, 2004
What is HW/SW Co-design?
• HW/SW Co-design is the field that emphasizes a unified view of HW and SW and develops synthesis tools and simulators that enable the co-development of systems by using both hardware and software.
• Main goal: To meet the design goals at the system-level exploiting the synergy of HW and SW parts through their concurrent design.
• HW/SW Co-design is the field that emphasizes a unified view of HW and SW and develops synthesis tools and simulators that enable the co-development of systems by using both hardware and software.
• Main goal: To meet the design goals at the system-level exploiting the synergy of HW and SW parts through their concurrent design.
23
- 45 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Co-design: Main Advantages
• To explore different design alternatives.• To evaluate cost-performance trade-offs• To reduce system design time ⇒ Reduction
of product time-to-market and cost• To improve product quality through design
process optimization• To support system-level specifications
⇒ To facilitate the reuse of hardware and software parts.
• To provide an integrated framework for the synthesis and validation of hardware and software components.
• To explore different design alternatives.• To evaluate cost-performance trade-offs• To reduce system design time ⇒ Reduction
of product time-to-market and cost• To improve product quality through design
process optimization• To support system-level specifications
⇒ To facilitate the reuse of hardware and software parts.
• To provide an integrated framework for the synthesis and validation of hardware and software components.
- 46 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Co-design Flow
24
- 47 -Prof. C. SILVANO, Politecnico di Milano, 2004
Main phases of HW/SW co-design process
• Requirements Analysis• Functional Specification (System Modelling)• Task Concurrency Management• High-level Transformations• Design Space Exploration• HW/SW Partitioning• Compilation and Scheduling• Co-synthesis• Co-simulation and co-verification
• Requirements Analysis• Functional Specification (System Modelling)• Task Concurrency Management• High-level Transformations• Design Space Exploration• HW/SW Partitioning• Compilation and Scheduling• Co-synthesis• Co-simulation and co-verification
- 48 -Prof. C. SILVANO, Politecnico di Milano, 2004
Overview of co-design phases
• Functional Specification (System-Level Modelling): to capture the system functionality in a formal language.
• Task Concurrency Management: To identify and to manage tasks in the system; To define tasks granularity (size of tasks)
• High-level Transformations: To apply some optimizing high-level transformations (that are outside the scope of traditional compilers). For example: Loops can be interchanged so that accesses to arrays in memory can exploit more locality.
• Functional Specification (System-Level Modelling): to capture the system functionality in a formal language.
• Task Concurrency Management: To identify and to manage tasks in the system; To define tasks granularity (size of tasks)
• High-level Transformations: To apply some optimizing high-level transformations (that are outside the scope of traditional compilers). For example: Loops can be interchanged so that accesses to arrays in memory can exploit more locality.
25
- 49 -Prof. C. SILVANO, Politecnico di Milano, 2004
Overview of co-design phases
• Design Space Exploration: To evaluate different design alternatives in terms of power-performance trade-offs
• HW/SW Partitioning: To map system functionalities to either hardware or software.
• Compilation and Scheduling: Hardware-aware compilation (for example energy-aware compilation) and scheduling (mapping of operations to control steps).
• Design Space Exploration: To evaluate different design alternatives in terms of power-performance trade-offs
• HW/SW Partitioning: To map system functionalities to either hardware or software.
• Compilation and Scheduling: Hardware-aware compilation (for example energy-aware compilation) and scheduling (mapping of operations to control steps).
- 50 -Prof. C. SILVANO, Politecnico di Milano, 2004
Overview of co-design phases
• Co-synthesis: To automatically derive a system implementation– Hardware synthesis of dedicated units– Software synthesis for processors
(Specialized compiling techniques)– Interface synthesis to support HW/SW
interface and synchronization
• Co-simulation and co-verification:To validate the design descriptions with respect to system-level requirements.
• Co-synthesis: To automatically derive a system implementation– Hardware synthesis of dedicated units– Software synthesis for processors
(Specialized compiling techniques)– Interface synthesis to support HW/SW
interface and synchronization
• Co-simulation and co-verification:To validate the design descriptions with respect to system-level requirements.
26
- 51 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Partitioning
To map system functionalities to either dedicated HW components or SW (processors).
• One extreme: Fully HW solution– High performance due to parallelism– High cost and long design time
• Other extreme: Fully SW solution– High-performance low-cost processors– Operations serialization– Lack of support for specific tasks
• Best solution: Mix of HW and SW components based on cost-performance trade-offs
To map system functionalities to either dedicated HW components or SW (processors).
• One extreme: Fully HW solution– High performance due to parallelism– High cost and long design time
• Other extreme: Fully SW solution– High-performance low-cost processors– Operations serialization– Lack of support for specific tasks
• Best solution: Mix of HW and SW components based on cost-performance trade-offs
- 52 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Partitioning Goals
• To speed-up software execution– By migrating critical SW functions to
dedicated HW• To reduce the cost of hardware
implementation– By migrating non-critical hardware
functions to software running on processor core
• To achieve system prototypes– By migrating functions to the prototype
medium
• To speed-up software execution– By migrating critical SW functions to
dedicated HW• To reduce the cost of hardware
implementation– By migrating non-critical hardware
functions to software running on processor core
• To achieve system prototypes– By migrating functions to the prototype
medium
27
- 53 -Prof. C. SILVANO, Politecnico di Milano, 2004
Open issues in HW/SW partitioning
• Object granularity in partitioning• Estimation of performance and cost metrics
from graph model of the system• Integrate the designer’s experience in
biasing a partition
• Object granularity in partitioning• Estimation of performance and cost metrics
from graph model of the system• Integrate the designer’s experience in
biasing a partition
- 54 -Prof. C. SILVANO, Politecnico di Milano, 2004
Co-synthesis after partitioning
• To automatically derive a system implementation– Hardware synthesis of dedicated units– Software synthesis for processors
(Specialized compiling techniques)– Interface synthesis to support HW/SW
interface and synchronization of SW functions identified by program threads
• A single processor requires threads serialization or interleaving
• Scheduling of threads and instructions– Satisfying performance constraints
• System-level run-time scheduler to synchronize SW and HW functions
• To automatically derive a system implementation– Hardware synthesis of dedicated units– Software synthesis for processors
(Specialized compiling techniques)– Interface synthesis to support HW/SW
interface and synchronization of SW functions identified by program threads
• A single processor requires threads serialization or interleaving
• Scheduling of threads and instructions– Satisfying performance constraints
• System-level run-time scheduler to synchronize SW and HW functions
28
- 55 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW Synthesis
• After partitioning, HW behavior is still described at high-level of abstraction (behavioral level)
• High-level synthesis alternatives:– Manual translation to RTL (Register
Transfer Level) description– Use behavioral synthesis tools
• After partitioning, HW behavior is still described at high-level of abstraction (behavioral level)
• High-level synthesis alternatives:– Manual translation to RTL (Register
Transfer Level) description– Use behavioral synthesis tools
- 56 -Prof. C. SILVANO, Politecnico di Milano, 2004
SW Synthesis
• SW synthesis for processors is based on specialized compiling techniques
• SW synthesis may be preceded by automatic SW generation steps
• Compilation characteristics in embedded systems– Code is compiled once ⇒ Compilation time
is not important, maximum optimization is desired
– Performance constraints ⇒ Code must be tight and fast ⇒ Assembly code
– Energy-aware compilation for low-power portable embedded systems
• SW synthesis for processors is based on specialized compiling techniques
• SW synthesis may be preceded by automatic SW generation steps
• Compilation characteristics in embedded systems– Code is compiled once ⇒ Compilation time
is not important, maximum optimization is desired
– Performance constraints ⇒ Code must be tight and fast ⇒ Assembly code
– Energy-aware compilation for low-power portable embedded systems
29
- 57 -Prof. C. SILVANO, Politecnico di Milano, 2004
Interface Synthesis
• Interfacing processors to ASICs and peripheral devices
• Device drivers may be in SW or in HW• Define models for communication
mechanisms• Scheduling the processor communication
• Interfacing processors to ASICs and peripheral devices
• Device drivers may be in SW or in HW• Define models for communication
mechanisms• Scheduling the processor communication
- 58 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Co-design at System-Level
Syst
emR
TL
Phys
ical
HWImplementation
Verification &Analysis
Soft IP
SWImplementation
SystemLevel IP
Hard IP
RTL to GDS IISynthesis Flow
C CompilerAssembler
Link Editor(IDE)
System Level Design
30
- 59 -Prof. C. SILVANO, Politecnico di Milano, 2004
HW/SW Co-Design
C/C++
a.out
C/C++
Architectural Design Functional Design
HW/SW Integration
+
- 60 -Prof. C. SILVANO, Politecnico di Milano, 2004
System-Level Design Flow Based on a Common HW/SW Language
Algorithm Architecture Application
ApplicationRTOS, ProtocolsDevice Drivers
Executable Specification
HardwareSynthesis
SoftwareSynthesis
C/C++ C/C++
31
- 61 -Prof. C. SILVANO, Politecnico di Milano, 2004
Optimizing Design Metrics
- 62 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design goals: Optimizing design metrics
• Obvious design goal:– Design an implementation with desired
functionality• Key design challenge:
– Simultaneously optimize several design metrics
• Design metric– A measurable feature of a system’s
implementation– Optimizing design metrics is a key
challenge
• Obvious design goal:– Design an implementation with desired
functionality• Key design challenge:
– Simultaneously optimize several design metrics
• Design metric– A measurable feature of a system’s
implementation– Optimizing design metrics is a key
challenge
32
- 63 -Prof. C. SILVANO, Politecnico di Milano, 2004
• Common metrics
–Unit cost: Monetary cost of manufacturing each copy of the system, excluding NRE cost
–NRE cost (Non-Recurring Engineering cost): One-time monetary cost of designing the system
–Size: Physical space required by the system
–Performance: Execution time or throughput of the system
–Power: Amount of power consumed by the system
–Flexibility: Ability to change the functionality of the system without incurring heavy NRE cost
• Common metrics
–Unit cost: Monetary cost of manufacturing each copy of the system, excluding NRE cost
–NRE cost (Non-Recurring Engineering cost): One-time monetary cost of designing the system
–Size: Physical space required by the system
–Performance: Execution time or throughput of the system
–Power: Amount of power consumed by the system
–Flexibility: Ability to change the functionality of the system without incurring heavy NRE cost
Design goals: Optimizing design metrics
- 64 -Prof. C. SILVANO, Politecnico di Milano, 2004
Common metrics (continued)– Time-to-prototype: Time needed to build a working
version of the system
– Time-to-market: Time required to develop a system to the point that it can be released and sold to customers
– Maintainability: Ability to modify the system after its initial release
– Correctness: Confidence to have implemented the system’s functionality correctly
– Safety: Probability that the system will no cause harm
– Many more…
Common metrics (continued)– Time-to-prototype: Time needed to build a working
version of the system
– Time-to-market: Time required to develop a system to the point that it can be released and sold to customers
– Maintainability: Ability to modify the system after its initial release
– Correctness: Confidence to have implemented the system’s functionality correctly
– Safety: Probability that the system will no cause harm
– Many more…
Design goals: Optimizing design metrics
33
- 65 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design metric competition: Improving one may worsen others
Expertise with both software and hardware is needed to optimize design metrics
–Not just a hardware or software expert, as is common–The designer must be able to migrate from one technology to another in order to find the best implementation for a given application and constraints
Expertise with both software and hardware is needed to optimize design metrics
–Not just a hardware or software expert, as is common–The designer must be able to migrate from one technology to another in order to find the best implementation for a given application and constraints
SizePerformance
Power
NRE cost
- 66 -Prof. C. SILVANO, Politecnico di Milano, 2004
Time-to-market: A demanding design metric
•Time required to develop a product to the point it can be sold to customers•Market window
–Period during which the product would have highest sales
•Average time-to-market constraint is about 8 months•Delays can be costly
•Time required to develop a product to the point it can be sold to customers•Market window
–Period during which the product would have highest sales
•Average time-to-market constraint is about 8 months•Delays can be costly
Rev
enue
s ($)
Time (months)
34
- 67 -Prof. C. SILVANO, Politecnico di Milano, 2004
Losses due to delayed market entry
•Simplified revenue model–Product life = 2W, peak at W–Time of market entry defines a triangle, representing market penetration–Triangle area equals revenue
•Loss –The difference between the on-time and delayed triangle areas
•Simplified revenue model–Product life = 2W, peak at W–Time of market entry defines a triangle, representing market penetration–Triangle area equals revenue
•Loss –The difference between the on-time and delayed triangle areas
On-time Delayedentry entry
Peak revenue
Peak revenue from delayed entry
Market rise Market fall
W 2W
Time
D
On-time
Delayed
Rev
enue
s ($)
- 68 -Prof. C. SILVANO, Politecnico di Milano, 2004
Losses due to delayed market entry (cont.)
•Area = 1/2 * base * height–On-time = 1/2 * 2W * W = W2
–Delayed = 1/2 * (W-D+W)*(W-D)
•Percentage revenue loss = (D(3W-D)/2W2)*100%•Try some examples
•Area = 1/2 * base * height–On-time = 1/2 * 2W * W = W2
–Delayed = 1/2 * (W-D+W)*(W-D)
•Percentage revenue loss = (D(3W-D)/2W2)*100%•Try some examples
On-time Delayedentry entry
Peak revenue
Peak revenue from delayed entry
Market rise Market fall
W 2W
Time
D
On-time
Delayed
Rev
enue
s ($)
– Lifetime 2W=52 wks, delay D=4 wks– (4*(3*26 –4)/2*26^2) = 22%– Lifetime 2W=52 wks, delay D=10 wks– (10*(3*26 –10)/2*26^2) = 50%– Delays are costly!
35
- 69 -Prof. C. SILVANO, Politecnico di Milano, 2004
NRE and unit cost metrics
Costs:Unit cost: the monetary cost of manufacturing each
copy of the system, excluding NRE costNRE cost (Non-Recurring Engineering cost): The one-
time monetary cost of designing the systemtotal cost = NRE cost + unit cost * # of unitsper-product cost = total cost / # of units
= (NRE cost / # of units) + unit cost
Costs:Unit cost: the monetary cost of manufacturing each
copy of the system, excluding NRE costNRE cost (Non-Recurring Engineering cost): The one-
time monetary cost of designing the systemtotal cost = NRE cost + unit cost * # of unitsper-product cost = total cost / # of units
= (NRE cost / # of units) + unit cost
• Example– NRE Cost = $2000, Unit Cost = $100– For 10 units
– total cost = $2000 + 10*$100 = $3000– per-product cost = $2000/10 + $100 = $300
Amortizing NRE cost over the units results in an additional $200 per unit
- 70 -Prof. C. SILVANO, Politecnico di Milano, 2004
NRE and unit cost metrics
$0
$40,000
$80,000
$120,000
$160,000
$200,000
0 800 1600 2400
A
BC
$0
$40
$80
$120
$160
$200
0 800 1600 2400
Num b e r o f units (vo lu m e )
AB
C
Num b e r o f units (vo lu m e )
tota
l cos
t (x1
000)
per
pro
duc
t cos
t
Compare technologies by costs -- best depends on quantity
Technology A: NRE=$2,000, unit=$100Technology B: NRE=$30,000, unit=$30Technology C: NRE=$100,000, unit=$2
Compare technologies by costs -- best depends on quantity
Technology A: NRE=$2,000, unit=$100Technology B: NRE=$30,000, unit=$30Technology C: NRE=$100,000, unit=$2
• But, must also consider time-to-market
36
- 71 -Prof. C. SILVANO, Politecnico di Milano, 2004
NRE and unit cost metrics
The best technology choice will depend on the number of units we plan to produce.
• Larger volumes allow us to amortize NRE costs such that lower per-product costs result
• Larger volumes ⇒ Lower per-product cost since NRE cost can be distributed over more products.
The best technology choice will depend on the number of units we plan to produce.
• Larger volumes allow us to amortize NRE costs such that lower per-product costs result
• Larger volumes ⇒ Lower per-product cost since NRE cost can be distributed over more products.
- 72 -Prof. C. SILVANO, Politecnico di Milano, 2004
The performance design metric
• Widely-used measure of system, widely-abused– Clock frequency, instructions per second – not
good measures– Digital camera example – a user cares about how
fast it processes images, not clock speed or instructions per second
• Latency (response time)– Time between task start and end– e.g., Camera’s A and B process images in 0.25
seconds
• Widely-used measure of system, widely-abused– Clock frequency, instructions per second – not
good measures– Digital camera example – a user cares about how
fast it processes images, not clock speed or instructions per second
• Latency (response time)– Time between task start and end– e.g., Camera’s A and B process images in 0.25
seconds
37
- 73 -Prof. C. SILVANO, Politecnico di Milano, 2004
The performance design metric
• Throughput (Number of tasks that can be processed per unit time)– Tasks per second, e.g. Camera A processes 4
images per second– Throughput can be more than latency seems to
imply due to concurrency, e.g. Camera B may process 8 images per second (by capturing a new image while previous image is being stored).
• To compare the performance of 2 systems:Speedup of B over A = B’s performance / A’s performance– Throughput speedup = 8/4 = 2
• Throughput (Number of tasks that can be processed per unit time)– Tasks per second, e.g. Camera A processes 4
images per second– Throughput can be more than latency seems to
imply due to concurrency, e.g. Camera B may process 8 images per second (by capturing a new image while previous image is being stored).
• To compare the performance of 2 systems:Speedup of B over A = B’s performance / A’s performance– Throughput speedup = 8/4 = 2
- 74 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design Technologies
38
- 75 -Prof. C. SILVANO, Politecnico di Milano, 2004
Three key technologies
TechnologyA manner of accomplishing a task,
especially using technical processes, methods, or knowledge
Three key technologies for embedded systems1. Processor technology2. IC technology3. Design technology
TechnologyA manner of accomplishing a task,
especially using technical processes, methods, or knowledge
Three key technologies for embedded systems1. Processor technology2. IC technology3. Design technology
- 76 -Prof. C. SILVANO, Politecnico di Milano, 2004
1) Processor technology
• The architecture of the computation engine used to implement a system’s desired functionality
• “Processor” not necessarily equal to general-purpose processor
• The architecture of the computation engine used to implement a system’s desired functionality
• “Processor” not necessarily equal to general-purpose processor
General-purpose(“software”)
Application-specific
Registers
CustomALU
DatapathController
Program memory
Assembly code for:
total = 0for i =1 to …
Control logic and State register
Datamemory
IR PC
Single-purpose(“hardware”)
DatapathController
Controllogic
State register
Datamemory
index
total
+
IR PC
Registerfile
GeneralALU
DatapathController
Program memory
Assembly code for:
total = 0for i =1 to …
Control logic and
State register
Datamemory
39
- 77 -Prof. C. SILVANO, Politecnico di Milano, 2004
Processor technology
Processors vary in their customization for the problem at handProcessors vary in their customization for the problem at hand
total = 0for i = 1 to N loop
total += M[i]end loop
General-purpose processor
(SW)
Single-purpose processor
(HW)
Application-specific processor(HW/SW)
Desired functionality
It represents the exact fit of the desired functionality
- 78 -Prof. C. SILVANO, Politecnico di Milano, 2004
General-purpose processors (SW)
• Programmable device used in a variety of applications– Also known as “microprocessor”
• Features– Program memory– General data-path with large
register file and general ALU• User benefits
– Low time-to-market and NRE costs
– High flexibility• “Pentium” the most well-known,
but there are hundreds of others
• Programmable device used in a variety of applications– Also known as “microprocessor”
• Features– Program memory– General data-path with large
register file and general ALU• User benefits
– Low time-to-market and NRE costs
– High flexibility• “Pentium” the most well-known,
but there are hundreds of others
IR PC
Registerfile
GeneralALU
DatapathController
Program memory
Assembly code for:
total = 0for i =1 to …
Control logic and
State register
Datamemory
40
- 79 -Prof. C. SILVANO, Politecnico di Milano, 2004
Single-purpose processors (HW)
• Digital circuit designed to execute exactly one program– a.k.a. coprocessor, accelerator or
peripheral• Features
– Contains only the components needed to execute a single application program
– No program memory• Benefits
– Fast– Low power– Small size
• Digital circuit designed to execute exactly one program– a.k.a. coprocessor, accelerator or
peripheral• Features
– Contains only the components needed to execute a single application program
– No program memory• Benefits
– Fast– Low power– Small size
DatapathController
Control logic
State register
Datamemory
index
total
+
- 80 -Prof. C. SILVANO, Politecnico di Milano, 2004
Application-specific processors (HW/SW)
• Programmable processor optimized for a particular class of applications having common characteristics– Compromise between general-
purpose and single-purpose processors
• Features– Program memory– Optimized data-path– Special functional units
• Benefits– Some flexibility, good
performance, size and power
• Programmable processor optimized for a particular class of applications having common characteristics– Compromise between general-
purpose and single-purpose processors
• Features– Program memory– Optimized data-path– Special functional units
• Benefits– Some flexibility, good
performance, size and power
IR PC
Registers
CustomALU
DatapathController
Program memory
Assembly code for:
total = 0for i =1 to …
Control logic and
State register
Datamemory
41
- 81 -Prof. C. SILVANO, Politecnico di Milano, 2004
Application-specific processors
ASIPS can require large NRE costs to build the processor and the compiler
⇒ Current research focuses on automatically generating ASIPs and their associated compile and debug environment.
ASIPS can require large NRE costs to build the processor and the compiler
⇒ Current research focuses on automatically generating ASIPs and their associated compile and debug environment.
- 82 -Prof. C. SILVANO, Politecnico di Milano, 2004
2) IC technology
• The manner in which a digital (gate-level) implementation is mapped onto an IC– IC: Integrated circuit, or “chip”– IC technologies differ in their customization to a
design– IC’s consist of numerous layers (perhaps 10 or
more)• IC technologies differ with respect to who builds
each layer and when
• The manner in which a digital (gate-level) implementation is mapped onto an IC– IC: Integrated circuit, or “chip”– IC technologies differ in their customization to a
design– IC’s consist of numerous layers (perhaps 10 or
more)• IC technologies differ with respect to who builds
each layer and when
source drainchanneloxidegate
Silicon substrate
IC package IC
42
- 83 -Prof. C. SILVANO, Politecnico di Milano, 2004
IC technology
Three types of IC technologiesa) Full-custom/VLSIb) Semi-custom ASIC (gate array and
standard cell)c) PLD (Programmable Logic Device)
Three types of IC technologiesa) Full-custom/VLSIb) Semi-custom ASIC (gate array and
standard cell)c) PLD (Programmable Logic Device)
- 84 -Prof. C. SILVANO, Politecnico di Milano, 2004
a) Full-custom/VLSI
• All layers are optimized for an embedded system’s particular digital implementation– Placing transistors– Sizing transistors– Routing wires
• Benefits– Excellent performance, small size, low
power• Drawbacks
– High NRE cost (e.g., $300k), long time-to-market
• All layers are optimized for an embedded system’s particular digital implementation– Placing transistors– Sizing transistors– Routing wires
• Benefits– Excellent performance, small size, low
power• Drawbacks
– High NRE cost (e.g., $300k), long time-to-market
43
- 85 -Prof. C. SILVANO, Politecnico di Milano, 2004
b) Semi-custom
• Lower layers are fully or partially built– Designers are left with routing of wires
and maybe placing some blocks• Benefits
– Good performance, good size, less NRE cost than a full-custom implementation (perhaps $10k to $100k)
• Drawbacks– Still require weeks to months to develop
• Lower layers are fully or partially built– Designers are left with routing of wires
and maybe placing some blocks• Benefits
– Good performance, good size, less NRE cost than a full-custom implementation (perhaps $10k to $100k)
• Drawbacks– Still require weeks to months to develop
- 86 -Prof. C. SILVANO, Politecnico di Milano, 2004
c) PLD (Programmable Logic Device)
• All layers already exist– Designers can purchase an IC– Connections on the IC are either created or
destroyed to implement desired functionality– Field-Programmable Gate Array (FPGA) very
popular• Benefits
– Low NRE costs, almost instant IC availability• Drawbacks
– Bigger, expensive (perhaps $30 per unit), power hungry, slower
• All layers already exist– Designers can purchase an IC– Connections on the IC are either created or
destroyed to implement desired functionality– Field-Programmable Gate Array (FPGA) very
popular• Benefits
– Low NRE costs, almost instant IC availability• Drawbacks
– Bigger, expensive (perhaps $30 per unit), power hungry, slower
44
- 87 -Prof. C. SILVANO, Politecnico di Milano, 2004
Independence of processor and IC technologies
• Basic tradeoff– General vs. custom– With respect to processor technology or IC technology– The two technologies are independent
• Basic tradeoff– General vs. custom– With respect to processor technology or IC technology– The two technologies are independent
General-purpose
processorASIP
Single-purpose
processor
Semi-customPLD Full-custom
General,providing improved:
Customized, providing improved:
Power efficiencyPerformance
SizeCost (high volume)
FlexibilityMaintainability
NRE costTime- to-prototype
Time-to-marketCost (low volume)
- 88 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Hardware: Moore’s law
• The most important trend in embedded systems [Predicted in 1965 by Intel co-founder Gordon Moore]
“IC transistor capacity has doubled roughly every 18 months for the past several decades”
• The most important trend in embedded systems [Predicted in 1965 by Intel co-founder Gordon Moore]
“IC transistor capacity has doubled roughly every 18 months for the past several decades”
10,000
1,000
100
10
1
0.1
0.01
0.001
Logic transistors per chip
(in millions)
1981
1 98 3
1 98 5
1 98 7
1 98 9
1 99 1
1 99 3
1 99 5
1 99 7
1 99 9
2 00 1
2 00 3
2 00 5
2 00 7
2 00 9
Note: logarithmic scale
45
- 89 -Prof. C. SILVANO, Politecnico di Milano, 2004
Embedded Hardware: Moore’s law
• This trend is mainly caused by improvements in IC manufacturing
• Minimum feature size for CMOS IC technology in 2002 is approximately 130 nm.
• This trend is mainly caused by improvements in IC manufacturing
• Minimum feature size for CMOS IC technology in 2002 is approximately 130 nm.
- 90 -Prof. C. SILVANO, Politecnico di Milano, 2004
Graphical illustration of Moore’s law
1981 1984 1987 1990 1993 1996 1999 2002
Leading edgechip in 1981
10,000transistors
Leading edgechip in 2002
150,000,000transistors
• Something that doubles frequently grows more quickly than most people realize!– A 2002 chip can hold about 15,000
1981-chips inside itself
46
- 91 -Prof. C. SILVANO, Politecnico di Milano, 2004
STMicroelectronics Roadmap
- 92 -Prof. C. SILVANO, Politecnico di Milano, 2004
3) Design Technology
The manner in which we convert our concept of desired system functionality into an implementation
The manner in which we convert our concept of desired system functionality into an implementation
Libraries/IP: Incorporates pre-designed implementation from lower abstraction level into higher level.
Systemspecification
Behavioralspecification
RTspecification
Logicspecification
To final implementation
Compilation/Synthesis: Automates exploration and insertion of implementation details for lower level.
Test/Verification: Ensures correct functionality at each level, thus reducing costly iterations between levels.
Compilation/Synthesis
Libraries/IP
Test/Verification
Systemsynthesis
Behaviorsynthesis
RTsynthesis
Logicsynthesis
Hw/Sw/OS
Cores
RTcomponents
Gates/Cells
Model simulat./checkers
Hw-Swcosimulators
HDL simulators
Gatesimulators
47
- 93 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design Technology
The designer must be able to produce larger number of transistors per year to keep pace with IC technology.
The designer must be able to produce larger number of transistors per year to keep pace with IC technology.
- 94 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design Productivity Gap
48
- 95 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design productivity exponential increase
Exponential increase over the past few decades
Exponential increase over the past few decades
100,000
10,000
1,000
100
10
1
0.1
0.01
1983
1 98 1
1987
1989
1991
1993
1985
1995
1997
1999
2001
2003
2005
2007
2009
Prod
uctiv
ity(K
) Tra
ns./S
taff
–M
o.
- 96 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design productivity gap
• While designer productivity has grown at an impressive rate over the past decades, the rate of improvement has not kept pace with chip capacity
• While designer productivity has grown at an impressive rate over the past decades, the rate of improvement has not kept pace with chip capacity
10,000
1,000
100
10
1
0.1
0.01
0.001
Logic transistors per chip
(in millions)
100,000
10,000
1000
100
10
1
0.1
0.01
Productivity(K) Trans./Staff-Mo.
1981
198 3
1 98 5
1 98 7
1 98 9
1 99 1
1 99 3
1 99 5
1 99 7
1 99 9
2 00 1
2 00 3
2 00 5
2 00 7
2 00 9
IC capacity
productivity
Gap
49
- 97 -Prof. C. SILVANO, Politecnico di Milano, 2004
Design productivity gap
• 1981 leading edge chip required 100 designer months– 10,000 transistors / 100 transistors/month
• 2002 leading edge chip requires 30,000 designer months– 150,000,000 / 5000 transistors/month
• Designer cost increases from $1M to $300M
• 1981 leading edge chip required 100 designer months– 10,000 transistors / 100 transistors/month
• 2002 leading edge chip requires 30,000 designer months– 150,000,000 / 5000 transistors/month
• Designer cost increases from $1M to $300M
10,0001,000
100101
0.1
0.010.001
Logic transistors per chip
(in millions)
100,00010,0001000100101
0.10.01
Productivity(K) Trans./Staff-Mo.
1981
198 3
1 98 5
1 98 7
1 98 9
1 99 1
1 99 3
1 99 5
1 99 7
1 99 9
2 00 1
2 00 3
2 00 5
2 00 7
2 00 9
IC capacity
productivity
Gap
- 98 -Prof. C. SILVANO, Politecnico di Milano, 2004
The mythical man-month
• The situation is even worse than the productivity gap indicates• In theory, adding designers to team reduces project completion time• In reality, productivity per designer decreases due to complexities of
team management and communication • In the software community, known as “the mythical man-month”
(Brooks 1975)• At some point, can actually lengthen project completion time! (“Too
many cooks”)
• The situation is even worse than the productivity gap indicates• In theory, adding designers to team reduces project completion time• In reality, productivity per designer decreases due to complexities of
team management and communication • In the software community, known as “the mythical man-month”
(Brooks 1975)• At some point, can actually lengthen project completion time! (“Too
many cooks”)
10 20 30 400
100002000030000400005000060000
43
24
1916 15 16
18
23
Team
Individual
Months until completion
Number of designers
1M transistors, 1 designer=5000 trans/month
Each additional designer reduces for 100 trans/month
So 2 designers produce 4900 trans/month each
50
- 99 -Prof. C. SILVANO, Politecnico di Milano, 2004
Managing the design productivity crisis
• IP (Intellectual Property) Reuse
• System-Level Design
• Software Design
• IP (Intellectual Property) Reuse
• System-Level Design
• Software Design
- 100 -Prof. C. SILVANO, Politecnico di Milano, 2004
IP-reuse
• Assembly of predesigned Intellectual Property components, often from external vendors
• Soft and Hard IPs
• Assembly of predesigned Intellectual Property components, often from external vendors
• Soft and Hard IPs
51
- 101 -Prof. C. SILVANO, Politecnico di Milano, 2004
System-Level Design
• Design and verification at the system-level– Rather than at the RTL or gate-level– Focus on Interface and Communication
• Design and verification at the system-level– Rather than at the RTL or gate-level– Focus on Interface and Communication
- 102 -Prof. C. SILVANO, Politecnico di Milano, 2004
Software Design
Great importance of softwareGreat importance of software
52
- 103 -Prof. C. SILVANO, Politecnico di Milano, 2004
Summary
• Embedded systems are everywhere• Key challenge: optimization of design metrics
– Design metrics compete with one another• A unified view of hardware and software is
necessary to improve productivity• Three key technologies
– Processor: general-purpose, application-specific, single-purpose
– IC: Full-custom, semi-custom, PLD– Design: Compilation/synthesis,
libraries/IP, test/verification
• Embedded systems are everywhere• Key challenge: optimization of design metrics
– Design metrics compete with one another• A unified view of hardware and software is
necessary to improve productivity• Three key technologies
– Processor: general-purpose, application-specific, single-purpose
– IC: Full-custom, semi-custom, PLD– Design: Compilation/synthesis,
libraries/IP, test/verification
- 104 -Prof. C. SILVANO, Politecnico di Milano, 2004
Note
• Part of the material presented was derived from the books: – “Embedded System Design” by Peter Marwedel, Kluwer
Academic Publishers, ISBN: 1-4020-7690-8, October 2003
– “Embedded System Design: A Unified Hardware/ Software Introduction” by Frank Vahid, Tony Givargis, John Wiley & Sons Inc., ISBN:0-471-38678-2, 2002.
– “Computers as Components: Principles of Embedded Computer Systems Design (With CD-ROM)” by Wayne Wolf, Morgan Kaufmann Publishers, ISBN: 1-55860-541-X, 2001
• Part of the material presented was derived from the books: – “Embedded System Design” by Peter Marwedel, Kluwer
Academic Publishers, ISBN: 1-4020-7690-8, October 2003
– “Embedded System Design: A Unified Hardware/ Software Introduction” by Frank Vahid, Tony Givargis, John Wiley & Sons Inc., ISBN:0-471-38678-2, 2002.
– “Computers as Components: Principles of Embedded Computer Systems Design (With CD-ROM)” by Wayne Wolf, Morgan Kaufmann Publishers, ISBN: 1-55860-541-X, 2001