1challenges shift to u reuse strategy u higher level of abstractions u software !!!

37
1 Challenges Challenges Shift to Shift to Reuse Reuse Strategy Strategy Higher Level Higher Level of of Abstractions Abstractions Software !!! Software !!!

Post on 20-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

1

ChallengesChallenges

Shift toShift to

Reuse StrategyReuse Strategy

Higher Level of Higher Level of

AbstractionsAbstractions

Software !!!Software !!!

2

PERCENT OF TRANSISTORS WITHIN EMBEDDED PERCENT OF TRANSISTORS WITHIN EMBEDDED IP (EXCLUDES MEMORY) IP (EXCLUDES MEMORY)

100

5

Random LogicTransistors

Transistors WithinEmbedded IP

0.35 0.25 0.18 0.15 0.13 0.11 0.10 0.08 0.07FeatureDimension (µm):

20051997 1998 1999 2000 2001 2002 2003 2004Year:

Tra

nsi

sto

rs (

%)

3

TRENDS IN EMBEDDED IPTRENDS IN EMBEDDED IP

DESIGNS WITH EMBEDDED IP WILL DOMINATE THE SYSTEM IC BUSINESS IN THE FUTURE

IC Market

System ICMarket

DesignsWith

EmbeddedIP

0

50

100

150

200

250

300

350

400

1998 1999 2000 2001 2002 2003 2004 2005 2006

Year

Val

ue (

$B)

1998 1999 2000 2001 2002 2003 2004 2005 2006

Total IC Value ($M) 112,005 133,426 174,723 164,592 173,506 197,118 227,752 269,078 313,214

Growth rate (%) NA 19.1 31.0 (5.8) 5.4 13.6 15.5 18.1 16.4

System IC Value ($M) 43,506 50,493 64,366 67,581 76,034 92,804 115,123 145,700 175,767

Growth rate (%) NA 16.1 27.5 5.0 12.5 22.1 24.0 26.6 20.6

Percent total (%) 38.8 37.8 36.8 41.1 43.8 47.1 50.5 54.1 56.1

IP-based design Value ($M) 15,706 19,894 30,123 39,129 51,247 68,582 90,602 122,679 153,093

Growth rate (%) NA 26.7 51.4 29.9 31.0 33.8 32.1 35.4 24.8

Percent system IC (%) 36.1 39.4 46.8 57.9 67.4 73.9 78.7 84.2 87.1

12/09/1999 4

Intra- and Inter-Company World Wide IP NetworksIntra- and Inter-Company World Wide IP Networks

IndependentIP Provider

System HouseCorporate Headquarters

OverseasAffiliate withProprietary IP

Semiconductor& IP Provider

Rapid IPIdentification,Business Transaction, & Design-in

5

Computing for Embedded SystemsComputing for Embedded Systems

Imag

e “

borr

ow

ed

” fr

om

an

Iom

eg

a a

dvert

isem

en

t fo

r Y2

K

soft

ware

an

d d

isk

dri

ves,

Sci

en

tifi

c A

meri

can

, S

ep

tem

ber

19

99

.

6

Complexity, Quality, Time-to-Market: TODAY Complexity, Quality, Time-to-Market: TODAY

MEMORYMEMORY 256 KB256 KB 128 KB128 KB 184 KB184 KB 8 MB8 MB

LINES OF CODELINES OF CODE 50.00050.000 30.00030.000 45.00045.000 300.000300.000

CHANGING RATECHANGING RATE 3 YEARS3 YEARS 2 YEARS2 YEARS 1 YEAR1 YEAR < 1 YEAR< 1 YEAR

DEV. EFFORTDEV. EFFORT 40 MAN-YEAR40 MAN-YEAR 12 MAN-YEAR12 MAN-YEAR 30 MAN-YEAR30 MAN-YEAR 200 MAN-YEAR200 MAN-YEAR

VALIDATION TIMEVALIDATION TIME 5 MONTHS5 MONTHS 1 MONTH1 MONTH 2 MONTHS2 MONTHS 2 MONTHS2 MONTHS

TIME TO MARKETTIME TO MARKET 24 MONTHS24 MONTHS 18 MONTHS18 MONTHS 12 MONTHS12 MONTHS < 12 MONTHS< 12 MONTHS

PWT UNITPWT UNIT BODY GATEWAYBODY GATEWAY TELEMATICTELEMATICUNITUNIT

INSTRUMENTINSTRUMENT

CLUSTERCLUSTER

PRODUCTIVITYPRODUCTIVITY 6 LINES/DAY6 LINES/DAY 10 LINES/DAY10 LINES/DAY 6 LINES/DAY6 LINES/DAY 10 LINES/DAY*10 LINES/DAY*

RESIDUAL DEFECTRESIDUAL DEFECTRATE @ END OF DEVRATE @ END OF DEV 3000 PPM3000 PPM 2500 PPM2500 PPM 2000PPM2000PPM 1000 PPM1000 PPM

* C++ CODE Source: EMBEDDED SYSTEMS: THE REAL STORYFABIO ROMEO, Magnetti-Marelli

Design Automation Conference, Las Vegas, June 20th, 2001

7

The Software Development ProblemThe Software Development Problem

Product Quality is POORProduct Quality is POOR

Development Productivity is LOWDevelopment Productivity is LOW

Development Cycle-time is TOO LONGDevelopment Cycle-time is TOO LONG

Source of Industry Data: Capers Jones(2000) Software Assessments, Benchmarks, and Best Practices, Addison-Wesley.

Industry Average

4.13Ind. Best-in-Class

8.76Customer Expectation

>40

PRODUCTIVITY

Function Point per Staff Month

Industry Average

0.44Ind. Best-in-Class

0.08Customer Expectation

<0.00044

QUALITY

Delivered Defects per Function Point

Industry Average

36Ind. Best-in-Class

25Customer Expectation

<3-6

CYCLETIME

Schedule in Months

System Software (of size 10,000 Function Points)

Source: Roger G. Fordham Motorola, Global Source: Roger G. Fordham Motorola, Global

Software GroupSoftware Group

DAC 2001, June 6,DAC 2001, June 6, 20012001

8

SW Complexity

0

100

200

300

400

500

600

700

800

1995 1997 2000 2003 2005

K-Linesof code

SW defects at End-of-Design

1

10

100

1000

10000

1995 1997 2000 2003 2005

ppmKEY DRIVERSKEY DRIVERS• QUALITYQUALITY• TIME-TO-MARKETTIME-TO-MARKET• COMPLEXITY MGMTCOMPLEXITY MGMT

WINNING SOLUTIONSWINNING SOLUTIONS•PLATFORM & APPLICATIONSPLATFORM & APPLICATIONS•DESIGN METHODOLOGIESDESIGN METHODOLOGIES•TESTINGTESTING

COMPLEXITY, QUALITY, TIME-TO-MARKET: FUTURE TRENDS COMPLEXITY, QUALITY, TIME-TO-MARKET: FUTURE TRENDS

Time-to-Market

0

5

10

15

20

25

30

35

40

1995 1997 2000 2003 2005

Months

TelematicsTelematics Power TrainPower Train

Body and NetworkBody and Network

9

What are the Remedies?What are the Remedies?

Significant commitment to CONTINUOUS IMPROVEMENTSignificant commitment to CONTINUOUS IMPROVEMENT

Effective use of DESIGN METHODOLOGIESEffective use of DESIGN METHODOLOGIES

Effective use of development/management AUTOMATIONEffective use of development/management AUTOMATION

P / PCBalance

90 : 10 %

SDL

UML

FML

10

Software Architecture TodaySoftware Architecture Today

Poor common infrastructure. Weak specialization of functions. Poor resource management. Poor planning.

11

Software Architecture Tomorrow?Software Architecture Tomorrow?

12

The “C” or “Java” ParadigmThe “C” or “Java” Paradigm

Not abstract enough to capture functionality onlyNot abstract enough to capture functionality only

Not detailed enough to capture important parameters such as performance, Not detailed enough to capture important parameters such as performance,

energy consumption, “size”energy consumption, “size”

What about real time?What about real time?

“Make it faster!”

13

Problems with Past Design MethodProblems with Past Design Method

Lack of unified hardware-software representationLack of unified hardware-software representation

Partitions are defined Partitions are defined a prioria prioriCan't verify the entire systemCan't verify the entire system

Hard to find incompatibilities across HW-SW boundaryHard to find incompatibilities across HW-SW boundary(often found only when prototype is built)(often found only when prototype is built)

Lack of well-defined design flowLack of well-defined design flowTime-to-market problemsTime-to-market problems

Specification revision becomes difficultSpecification revision becomes difficult

14

Today

Design Effort vs. System Design ValueDesign Effort vs. System Design Value

Effort/Value

Leve

l of A

bstr

actio

n

Function

HW/SW

Architecture

RTL - SW

Mask - ASM

Tomorrow

RTL/Gate “platform”RTL/Gate “platform”

Design Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry LevelDesign Entry Level

ConceptualConceptualGapGap

Design Entry LevelDesign Entry Level

15

Today

Design Effort vs. System Design ValueDesign Effort vs. System Design Value

Effort/Value

Leve

l of A

bstr

actio

n

Function

HW/SW

Architecture

RTL - SW

Mask - ASM

Tomorrow

Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”Hand-off “platform”

Design Entry LevelDesign Entry Level

16

New Levels of Design Chain InteractionNew Levels of Design Chain Interaction

Today

Effort/Value

Leve

l of A

bstr

actio

n

Function

HW/SW

Architecture

RTL - SW

Mask - ASM

Tomorrow

Architectural Space

System Platform

Application Space

18

High-Leverage ParadigmsHigh-Leverage Paradigms

If we face a problem that has become too complex to If we face a problem that has become too complex to

solve, eliminate the problem!solve, eliminate the problem!DecomposeDecompose

ApproximateApproximate

Solve by constructionSolve by construction

19

Separate Behavior from Micro-architectureSeparate Behavior from Micro-architecture

FrontFrontEnd End 11

TransportTransportDecode Decode 22

RateRateBufferBuffer1212

RateRateBufferBuffer

99

RateRateBufferBuffer

55

SensorSensor

SynchSynchControlControl

44

VideoVideoDecode Decode 66

AudioAudioDecode/Decode/

Output Output 1010

MemMem1111

User/SysUser/SysControlControl

33

MemMem1313

FrameFrameBufferBuffer

77

VideoVideoOutput Output 88

System BehaviorSystem BehaviorFunctional Specification of Functional Specification of

System.System.

No notion of hardware or No notion of hardware or software!software!

Implementation ArchitectureImplementation ArchitectureHardware and SoftwareHardware and Software

Optimized ComputerOptimized Computer

DSP RAMDSP RAM

ExternalExternalI/OI/O

System System RAMRAM

DSPDSPProcessorProcessor

Pro

cessor

Bu

sP

rocessor

Bu

s

ControlControlProcessorProcessor

MPEGMPEG

PeripheralPeripheral

AudioAudioDecodeDecode

20

Models of Computation: And There are More...Models of Computation: And There are More... Continuous time (ODEs)Continuous time (ODEs)

Spatial/temporal (PDEs)Spatial/temporal (PDEs)

Discrete timeDiscrete time

RendezvousRendezvous

Synchronous/ReactiveSynchronous/Reactive

DataflowDataflow

......

Tower of Babel, Bruegel, 1563

Each of these provides a formal framework for reasoning about certain aspects of embedded systems.

We are searching for an abstraction that provides the Source for all MoCs that can be obtained by refinementWe are searching for an abstraction that provides the Source for all MoCs that can be obtained by refinement

21

FormalizationFormalization

Model of a design with precise unambiguous semantics:Model of a design with precise unambiguous semantics:

Implicit or explicit relations: inputs, outputs and (possibly) Implicit or explicit relations: inputs, outputs and (possibly)

state variablesstate variables

Properties Properties

““Cost” functions Cost” functions

ConstraintsConstraints

Formalization of Design + Environment =

closed system of equations and inequalities over some algebra.

22

Validating DesignsValidating Designs By construction

property is inherent.

By verification property is provable.

By simulation check behavior for all inputs.

By intuition property is true. I just know it is.

By assertion property is true. Wanna make something of it?

By intimidation Don’t even try to doubt whether it is true

It is generally better to be higher in this list

23

Notion of TimeNotion of Time

25

IP B

lock

Aut

horin

g

Synthesis / Place & Route etc.

Two Basic Questions …Two Basic Questions …Question I - IP AuthoringQuestion I - IP Authoring

How to design a system block?How to design a system block?Starting from the system levelStarting from the system level

With a consistent test-benchWith a consistent test-bench

Getting from the abstract, un-timed Getting from the abstract, un-timed system model to the clocked HW or system model to the clocked HW or SW implementation modelSW implementation model

ExampleExample

Rake ReceiverRake ReceiverWhich are the optimal algorithms?Which are the optimal algorithms?

How does it work fixed point?How does it work fixed point?

How is it best implemented?How is it best implemented?

Does the implementation work as Does the implementation work as specified in the system levelspecified in the system level

Implementation Level Verification

Block Implementation

Iterative Refinement

Executable System LevelBlock Level Specification

IP Block Definition

Embedded System Requirements

26Synthesis / Place & Route etc.

Two Basic Questions …Two Basic Questions …Question II – IP IntegrationQuestion II – IP Integration

How to integrate system blocks?How to integrate system blocks?Starting from the system levelStarting from the system levelWith a consistent test-benchWith a consistent test-benchGetting from the abstract, un-timed Getting from the abstract, un-timed

system model to the clocked HW or system model to the clocked HW or SW implementation modelSW implementation model

Communication between blocksCommunication between blocksAddressing Platform Based designAddressing Platform Based design

ExampleExample

3G Cell phone3G Cell phoneWhich are the optimal algorithms?Which are the optimal algorithms?Do they work together functionally?Do they work together functionally? Is the architecture sufficient?Is the architecture sufficient?Does the implementation integration Does the implementation integration

work?work?Implementation Level Verification

SoftwareAssembly

HardwareAssembly

Communication Refinement Communication Integration

Performance Analysis and Platform Configuration

System Integration

Platform Function

Platform Architecture

IP B

lock

Sys

tem

Inte

grat

ion

Embedded System Requirements

27

The new approachThe new approach

Not the typical stepwise top-down refinement: we rest on Not the typical stepwise top-down refinement: we rest on

platforms!platforms!

Explicit mapping of applications onto architecture Explicit mapping of applications onto architecture

componentscomponents

The higher the level of abstraction, the faster is the design The higher the level of abstraction, the faster is the design

timetime

12/09/1999 28

PtolemyPtolemy

E. Lee Project at UC BerkeleyE. Lee Project at UC Berkeley

Multiple models of computationMultiple models of computation

DSP beginnings: Static DataflowDSP beginnings: Static Dataflow

Many other models: FSM, Discrete Many other models: FSM, Discrete

EventEvent

Mixed model verificationMixed model verification

29

The target architecture:The target architecture:

A bit of history: the POLIS projectA bit of history: the POLIS project

Climate Control

Exhaust Control

Active Suspensions Transmission

InfoSystem

EngineControl

ABS

computeair flow compute

injectiontime

driveactuators

airflow

injectiontime

air temperature

engine temperature

engine speed

throttle position

look-up table

PWM signalsair pressure

68HC1168HC11

ROMROM

Intfc.Intfc.

1988:1988:

The problem:The problem:

12/09/1999 31

Example of System BehaviorExample of System Behavior

FrontFrontEnd End 11

TransportTransportDecode Decode 22

RateRateBufferBuffer

1212

RateRateBufferBuffer

99

RateRateBufferBuffer

55

SensorSensor

SynchSynchControlControl

44

VideoVideoDecode Decode 66

AudioAudioDecode/Decode/

Output Output 1010

MemMem1111

User/SysUser/SysControlControl

33

MemMem1313

FrameFrameBufferBuffer

77

VideoVideoOutput Output 88

Satellite DishSatellite Dish

CableCable

remoteremote

monitormonitor

speakersspeakers

12/09/1999 32

IP-Based Design of the System BehaviorIP-Based Design of the System Behavior

FrontEnd 1

TransportDecode 2

RateBuffer12

RateBuffer9

RateBuffer5

Sensor

SynchControl4

VideoDecode 6

AudioDecode/

Output 10

Mem11

User/SysControl3

Mem13

FrameBuffer7

VideoOutput 8

Satellite Dish

Cable

remote

monitor

speakers

TestbenchDesigned in BONeS

Baseband ProcessingDesigned in SPW

Decoding AlgorithmsDesigned in SPW

Transport DecodeWritten in C

User InterfaceWritten in C

System IntegrationCommunication Protocol

Designed in Felix

33

The next level of Abstraction …The next level of Abstraction …

abst

ract

Transistor ModelCapacity Load

1970’s

cluster

abst

ract

Gate Level ModelCapacity Load

1980’s

RTL

cluster

abst

ract

SDFWire Load

1990’s

IP Blocks

cluster

abst

ract

IP Block PerformanceInter IP Communication Performance Models

RTLClusters

SWModels

Year 2000 +

12/09/1999 34

IP-Based Design of the ImplementationIP-Based Design of the Implementation

DSP RAMDSP RAM

ExternalExternalI/OI/O

System System RAMRAM

DSPDSPProcessorProcessor

Pro

cess

or B

usPr

oces

sor B

us

ControlControlProcessorProcessor

MPEGMPEG

PeripheralPeripheral

AudioAudioDecodeDecode

Which DSPProcessor? C50?

Can DSP be done onMicrocontroller?

Which Bus? PI?AMBA?

Dedicated Bus forDSP?

WhichMicrocontroller?

ARM? HC11?

Do I need a dedicated Audio Decoder?Can decode be done on Microcontroller?

How fast will myUser Interface

Software run? HowMuch can I fit on my

Microcontroller?

Can I Buyan MPEG2

Processor?Which One?

35

Architectural ChoicesArchitectural Choices

P

Prog Mem

MACUnit

AddrGenP

Prog Mem

P

Prog Mem

Satellite

ProcessorDedicated

Logic

Satellite

Processor

Satellite

Processor

GeneralPurpose

P

Software

DirectMapped

Hardware

HardwareReconfigurable

Processor

ProgrammableDSP

Fle

xib

ility

Fle

xib

ility

1/Efficiency (power, speed)1/Efficiency (power, speed)

12/09/1999 36

Map Between Behavior from ArchitectureMap Between Behavior from Architecture

FrontFrontEnd End 11

TransportTransportDecode Decode 22

RateRateBufferBuffer1212

RateRateBufferBuffer

99

RateRateBufferBuffer

55

SensorSensor

SynchSynchControlControl

44

VideoVideoDecode Decode 66

AudioAudioDecode/Decode/

Output Output 1010

MemMem1111

User/SysUser/SysControlControl

33

MemMem1313

FrameFrameBufferBuffer

77

VideoVideoOutput Output 88

Audio Decode BehaviorImplemented on

Dedicated Hardware

Transport Decode Implemented as Software Task Running

on Microcontroller

DSP RAMDSP RAM

ExternalExternalI/OI/O

System System RAMRAM

DSPDSPProcessorProcessor

Pro

cessor

Bu

sP

rocessor

Bu

s

ControlControlProcessorProcessor

MPEGMPEG

PeripheralPeripheral

AudioAudioDecodeDecode

CommunicationOver Bus

12/09/1999 37

Classic A/D, HW/SW tradeoffClassic A/D, HW/SW tradeoff

RF Front EndRF Front End

Can trade custom analog for hardware, even for softwareCan trade custom analog for hardware, even for softwarePower, area critical criteria, or easy functional modificationPower, area critical criteria, or easy functional modification

LOLO

De-correlateDe-correlate(spread spectrum)(spread spectrum)

Analog vs. Digital tradeoff Analog vs. Digital tradeoff

De-modulateDe-modulate

A/DA/D CustomCustomDSPDSP

Suppose digital limit is pushedSuppose digital limit is pushed

DS 1-bitDS 1-bitModulatorModulator

Dec.Dec.FilterFilter

GenGenDSPDSP

1-bit1-bitModulatorModulator

GenGenDSPDSP

1-bit1-bitModulatorModulator

System Chip DSPSystem Chip DSP

Digital expandingDigital expanding

e.g.e.g.

12/09/1999 38

Example: Voice Mail PagerExample: Voice Mail Pager

Design considerations cross design layersDesign considerations cross design layers

Trade-offs require systematic methodology and constraint-based hierarchical approach for clear Trade-offs require systematic methodology and constraint-based hierarchical approach for clear

justificationjustification

Modulation Scheme Choice (e.g. BPSK)Modulation Scheme Choice (e.g. BPSK)

QQ

IIPPff

De-correlateDe-correlate(spread spectrum)(spread spectrum)

Analog vs. Digital tradeoff Analog vs. Digital tradeoff

De-modulateDe-modulate

e.g.e.g.GenGenDSPDSP

??

??

39

Where All is GoingWhere All is Going

Function/Arch. Co-Design

Convergence of Paradigms

Communication-basedDesign

Analog PlatformDesign

Create paradigm shift- not just link methodsNew levels of abstraction to fluidly tradeoff HW/SW, A/D, HF/IF, interfaces, etc- to exploit heterogeneous nature of componentsLinks already being forged

40

Concluding RemarksConcluding Remarks

The Industry Structure is undergoing a revolutionary changeThe Industry Structure is undergoing a revolutionary change

The Design Problems are changing radically their main characteristicsThe Design Problems are changing radically their main characteristics

System Design is becoming more and more the key to successSystem Design is becoming more and more the key to success

System implies Major Emphasis on SoftwareSystem implies Major Emphasis on Software

Analog, Sensors, Actuators, RF must be part of designAnalog, Sensors, Actuators, RF must be part of design

Deep Submicron makes most of the tools obsoleteDeep Submicron makes most of the tools obsolete