introduction to hw/sw co-design of embedded...

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


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


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



• 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...


Embedded Systems

Main reason for buying is not information processing

Embedded systems (ES) = information processing systems embedded into a larger product

Examples:

4


Application Areas (1)

• Automotive electronics

• Aircraft electronics

• Trains

• Telecommunication

• Automotive electronics

• Aircraft electronics

• Trains

• Telecommunication



• Authentication• Authentication

• Military applications• Military applications

• Medical systems• Medical systems

5



• Consumer electronics• Consumer electronics

• Smart buildings• Smart buildings

• Fabrication equipment• Fabrication equipment



• Robotics• Robotics

Robot „Johnnie“ (Courtesy and ©: H.Ulbrich, F. Pfeiffer, TU München)

6


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


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


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


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



• 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)



• 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



• 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.



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


IC Technology towards the System-On-Chip Approach


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


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.


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


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


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


[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


• 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


Cost of Software in Embedded Systems


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


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)


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


Design Methodologies


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


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.


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


A simplified design flow

Architecture Definition

System-Level Requirements

System-Level Specification

HW Design SW Design

System Integrationand Validation


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


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.


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


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!


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


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.


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


HW/SW Co-design Flow


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


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.


HW/SW Co-design Flow

24


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


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



• 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).



• 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


interface and synchronization

• Co-simulation and co-verification:To validate the design descriptions with respect to system-level requirements.

26


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


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


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


Co-synthesis after partitioning

• To automatically derive a system implementation– Hardware synthesis of dedicated units– Software synthesis for processors


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


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


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


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


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


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


HW/SW Co-Design

C/C++

a.out

C/C++

Architectural Design Functional Design

HW/SW Integration

+


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


Optimizing Design Metrics


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


• 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



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…


33


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


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


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 ($)


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


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



$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



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.


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


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


Design Technologies

38


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


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:


Control logic and

State register

Datamemory

39


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


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:


Control logic and

State register

Datamemory

40


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

+


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:


Control logic and

State register

Datamemory

41


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.


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


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)


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


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


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


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)


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


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.


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


STMicroelectronics Roadmap


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


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.


Design Productivity Gap

48


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.


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


(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


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


(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


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


Managing the design productivity crisis

• IP (Intellectual Property) Reuse

• System-Level Design

• Software Design

• IP (Intellectual Property) Reuse

• System-Level Design

• Software Design


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


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


Software Design

Great importance of softwareGreat importance of software

52


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


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

introduction to hw/sw co-design of embedded...

Documents