EE249 1

n Formal Specificationsn Top Down Design

u System Level Design and Rapid Prototypingu Hardware/Software Co-Designu Component Design

n Bottom Up Design: IP Use and IP Delivery

A New Approach to Design

EE249 2

System Specifications

EE249 3

Driver Vehicle

force, speed, acceleration, jerk, rpm, fuel consumption,...

emissions, external noise, temperature, ...

Key, Brake, Gas, Transm.

Engine &

Driveline

Controller

spark advance, injection time,throttle angle

Closed loop vehicle model

EE249 4

Fast N e gative

Force Trans ien t min f(D, M fuel)

τ < τmax

Force Track ing

Fast Posi tive

Force Trans ien t

S pe e d Track in g

n=n(.) n=n(.)

Idle & Trasm On

.G>0 | t >τ

. .G < GB

| B=1

.G<0 | t >τ

. .G > GA

G > 0

G = 0

T > 0

T=0 T=0

(G>0)&(T>0)

T=0

fI(n) = 0 & G=0

fI(n,G) > 0

.G=0 & C=1

.

G > 0| B = 1

T > 0

T=0

O UTPUT:

n - Eng i ne Speedn - Eng i ne SpeedFFG G - Generated Fo rceVV GG - Veh i cl e Speed - Veh i cl e Speed

n=n(G)

FG=0

Rpm Tracking

n=argmin(M fu el)

Id le

FG=0

VG= VG(.)

S top

n=0

FG=0

S tartu p

FG=0

n= .

G > 0G = 0

(n < nmin)| (K=Off) n > nst art up

K = St art

(n < nmin)| (K = O ff)

FG=FG(G ,T,n)FG=FG(G ,T,n)

max Dτ < τ max

min τ

FG=FG(G ,T,n)

M fuel < M ma x; D>D min

T>0 &G=0

INP UTS:

G - G as PedalG - G as PedalT - Clu tch Pedal & Gear S ti ckT - Clu tch Pedal & Gear S ti ckB - Brake PedalB - Brake PedalC - Cru i se Co ntro lC - Cru i se Co ntro l

K - Key

D - Co mfort

fI(n) = 0 & G=0

EE249 5

CombustionEngine

MixMngmt

&Injection

Ignition(Spark)Timing

Engine Model

TorqueGeneration

Exhaust GasTreatment

FuelMngmt

AirMngmt

EE249 6

Abstraction

n The Plant consists of Engine+Drive-Linen Torque Generation Model abstracted from very

complex chemical-mechanical-thermo-dynamicalprocess = FSM!

n Drive Line Dynamics represented as 3rd order lineardynamical system

n Control variables: spark + fuel injectionn Abstraction validated by theoretical devices (formal

verification) + measurements on actual cars

EE249 7

Hybrid Systems in Automotive

n Driver (Reference) Model n Engine + Drive-line (Plant)Model

DEFSM

CT

START

DECEL.

ACCEL.

CONST.

IDLESTOP

EE249 8

Cut-off Control: the Problemn When accelerator pedal is released, no torque is

requested.n Intuitive solution: reduce injection to zero immediately!

u minimizes consumption and emissions

u but, sharp torque variations can cause unpleasant power-trainoscillations!

n Control Problem: Power-train oscillation reduction viainjection signal control

n Present solution: open loop air/fuel modulationu engine speed transient during gear changes

u power-train state not taken into account

EE249 9

Short History

n Specifications obtained November 1996n Hybrid Modeling November-December 1996n Control Problem partially solved January 1997n Complete Simulations May 1997n Implementation and Field Test October 1997n Planned for production 1998

EE249 10

Summary of Results

n Hybrid engine+power-train modeln Cut-off control as hybrid control

n Convergence and Optimality Propertiesn Experimental results very encouraging:

u better performanceu for a commercial car, 50% of memory occupation

for data and 75% of memory occupation for code, 1%CPU utilization (Motorola 68020)

u Approach can be extended to most regions ofoperations

EE249 11

Target HW/SW Architecture

Mem

uP/uC

Co-P

Mem

Mem

DSP

Bridge

Bridge

DPMEM

Periph

CustHW

IPBLOCK

I/O

I/O

I/F

I/F

DriverThread

Thread

Thread

Driver

MapMap

EE249 12

Choosing the Architecture

Core Processors(ARM, x86, MIPS)

DSP Processors(TI320x, Pine, Trimedia)

Configurable Hardware(Clay, Xilinx, Atmel)

Dedicated Hardware(Fixed, Synthesized)

Programmability

Coverage

Cost

Performance

Power

Metrics

EE249 13

Mapping

n Associates functional units with architecturalunits

n Performs HW/SW partitioning

n Associates functional communication withresources (buffers, busses, serial links, etc.)

n Provides estimates of performance of a givenfunction on a given architectural unit

EE249 14

Behavior-Architecture Binding

Up-link Radio

Down-link Radio

Graphics

Video

Voice

Pen

DSP RAM

ExternalI/O

System RAM

DSPProcessor

Pro

cess

or B

us

ControlProcessor

ASSP

Dedicated

AudioDecode

Meaningful decision makingrequires fast and educated information on impact of design choices

EE249 15

Behavioral Function

Combines Behavioral Parameters and Architectural Models

HWlibrary

Network ofModules

Map

ping

Hardware Path

ModelLibrary

SWlibrary

ProcessorModel

Cod

eG

ener

atio

n

Software Path

ARM8

ModelLibrary

Estimation and Modeling

EE249

Example of System Behavior

FrontEnd 1

TransportDecode 2

RateBuffer

12

RateBuffer

9

RateBuffer

5

Sensor

SynchControl

4

VideoDecode 6

AudioDecode/

Output 10

Mem11

User/SysControl

3

Mem13

FrameBuffer

7

VideoOutput 8

Satellite Dish

Cable

remote

monitor

speakers

EE249

IP-Based Design of the SystemBehavior

FrontEnd 1

TransportDecode 2

RateBuffer

12

RateBuffer

9

RateBuffer

5

Sensor

SynchControl

4

VideoDecode 6

AudioDecode/

Output 10

Mem11

User/SysControl

3

Mem13

FrameBuffer

7

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

EE249

IP-Based Design of the Implementation

DSP RAM

ExternalI/O

System RAM

DSPProcessor

Pro

cess

or B

us

ControlProcessor

MPEG

Peripheral

AudioDecode

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 MPEG2Processor?

Which One?

EE249

Architecture EvaluationProblem

Behavior

Architecture

HDLHighCost

Out ofSpec

SystemBehavior

Refine

Refine

SystemArchitecture

SystemBehavior

Refine

Refine

SystemArchitecture

Time and Money

EE249

Architecture Evaluation

SystemBehavior

Refine

Time and Money

SystemArchitecture

SystemArchitecture

SystemArchitecture

In SpecLow Cost

Behavior

Architecture

HDL

EE249

Separate Behavior fromArchitecture

FrontEnd 1

TransportDecode 2

RateBuffer

12

RateBuffer

9

RateBuffer

5

Sensor

SynchControl

4

VideoDecode 6

AudioDecode/

Output 10

Mem11

User/SysControl

3

Mem13

FrameBuffer

7

VideoOutput 8

n System Behavioru Functional Specification of

System.

n Implementation Architectureu Hardware and Software

DSP RAM

ExternalI/O

System RAM

DSPProcessor

Pro

cess

or B

us

ControlProcessor

MPEG

Peripheral

AudioDecode

EE249

Map Between Behavior fromArchitecture

FrontEnd 1

TransportDecode 2

RateBuffer

12

RateBuffer

9

RateBuffer

5

Sensor

SynchControl

4

VideoDecode 6

AudioDecode/

Output 10

Mem11

User/SysControl

3

Mem13

FrameBuffer

7

VideoOutput 8

Audio Decode BehaviorImplemented on

Dedicated Hardware

Transport Decode Implemented as Software Task Running

on Microcontroller

DSP RAM

ExternalI/O

System RAM

DSPProcessor

Pro

cess

or B

us

ControlProcessor

MPEG

Peripheral

AudioDecode

CommunicationOver Bus

EE249

Architecture DeterminesPerformance

TransportDecode

AudioDecode/Output

Processor B

usControl

ProcessorAudio

Decoder

EE249

Communication Refinement

n Separate Function of blocks from inter-blockcommunication

n Substitute lower-level detail for communicationsbehavior

IP Block IP Block

Pro

toco

l Dow

n C

onve

rter

Pro

toco

l Up

C

on

vert

er

IP Block WithGeneric Data

Transfer

IP Block WithGeneric Data

Transfer

EE249

Insert Communication Design

TransportDecode

AudioDecode/Output

EE249 26

Engine Control Unit SW Arch.

SW Structure Layer

Sensors Actuators

Hardware

S ANet Net

BIOS

Hardware

Software

network

RT

OS

P. Sensors DeviceDriver

P. Actuators Devicedriver

VariableImages

Actuated Variable

Transformation

controls

Com

mun

icat

ion

EE249 27

Mapping and Performance Estimation

n Mapping the system behavior to each ECUarchitecture

n Performance estimation based on CPU and peripheralmodels:u automatic estimation for untimed behavior running on CPUsu manual estimation for timers and TPUs

EE249

Software IP authoring

n Key in providing flexibilityn Software is consuming more and more time and

resources:u Telecom: 70+% of engineeringu Automotive: from 40% to more than 60%u Most of malfunctioning comes from software

n Life Threatening Errorsn Cost of bug fixing

EE249

Software Issuesn Error free requirementsn Architecture of embedded software:

u typical of 8-bit architecturesu assembly codeu mostly obsoleteu layeredu little, if any, documentation

n Almost no re-usen Cost of developing software often not

recognized by clients

EE249

Opportunities for EmbeddedSoftware Design

n A structured approach geared towards re-use andverification is not impossible, but requires investingin new human resources and tools!

n Embedded software has peculiarities that alloweffective automatic synthesis and optimization

n Operating systems are RT and micro-kerneln Could be synthesized as well….to take advantage of

the characteristics of the problemn Validation can be carried out formally if a rigorous

approach to modeling is used

EE249 31

SW Architecture Guideline

n Strong separation between “basic” software andapplication software.u Basic software must encapsulate hardware details and

sensor/actuator implementation detailsu Application software should reflect the control algorithm

hierarchy with no explicit dependency on hardwarearchitecture.

A.Ferrari, M.Antoniotti, and A.S.V.

EE249 32

System Design

Synthesis Verification

Architecture Function

Mapping

HW SW

EE249

Proposed Design Methodology

Behavioral Libraries

CaptureBehavior

ArchitectureLibraries

CaptureArchitecture

VerifyBehavior

VerifyArchitecture

Functional Level

Map Behavior toArchitecture

VerifyPerformance

Mapping Level

Refine HW/SWArchitecture

PerformanceBack-Annotation Link to

uArchitectureVerification

Link toHW/SW

ImplementationArchitectural Level

EE249

Ptolemy

n E. Lee Project at UC Berkeleyn Multiple models of computationn DSP beginnings: Static Dataflown Many other models: FSM,

Discrete Eventn Mixed model verification

EE249 35

n The target architecture:

A 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

68HC11

ROM

Intfc.

� 1988:

� The problem:

EE249 36

Aptix Board Consistof

– micro of choice– FPGA’s– FPIC’s

POLIS Methodology

Graphical EFSM ESTEREL ................

CFSMs

Partitioning

Sw Synthesis

Sw Code + RTOS

Logic Netlist

Hw Synthesis

Sw Estimation Hw Estimation

Physical Prototyping

Hw/Sw Co-SimulationPerformance/trade-off Evaluation

Fomal Verification

Compilers

EE249

Design System

HW/SW Coverification

System BehaviorSpecification

System Architecture Evaluation

Design Verification

BehaviorLibraries

SPW,CossapBONeSPtolemy

ArchitectureLibrariesDatabooks

IP

SW Compile HW Synthesis

F ront

End 1

Transpo rtDecode 2

Rat eBuff er

12

Rat eBuff er

9

Rat eBuff er

5

Sensor

Synch

Cont rol4

VideoDecode 6

AudioDecode /

Out put 10

User/SysCont rol

3

Mem13

F rameBuff er

7

VideoOut put 8

SimulationEstimationPartitioning

Front End

mController

Memory

TransportDecode

VideoDecode

VideoOutput

AudioDecode/Output

Bus

ToolsetPoindexterC

SoftwareDevelopmentTools

EE249

Product Design KitReference ImplementationArchitectureLibrary

PeripheralCatalog

SampleDesignLibrary

VideoDecodeVideo

DecodeVideoDecodeVideo

Decode

Transpo rt

Decode 2

Rat eBuff er

12

Rat eBuff er

9

Rat eBuff er

5

Sensor

SynchCont rol

4

VideoDecode 6

AudioDecode /

Out put 10

User/SysCont rol

3

Mem13

F rameBuff er

7

VideoOut put 8

Transpo rt

Decode 2

Rat eBuff er

12

Rat eBuff er

9

Rat eBuff er

5

Sensor

SynchCont rol

4

VideoDecode 6

AudioDecode /

Out put 10

User/SysCont rol

3

Mem13

F rameBuff er

7

VideoOut put 8

Transpo rt

Decode 2

Rat eBuff er

12

Rat eBuff er

9

Rat eBuff er

5

Sensor

SynchCont rol

4

VideoDecode 6

AudioDecode /

Out put 10

User/SysCont rol

3

Mem13

F rameBuff er

7

VideoOut put 8

Inte

rfac

e

DSP RAM

ExternalI/O

System RAM

DSPProcessor

Pro

cess

or B

us

ControlProcessor

Per

iphe

ral B

usPeripheral

Peripheral

Peripheral

F ront

End 1

Transpo rtDecode 2

Rat eBuff er

12

Rat e

Buff er9

Rat e

Buff er5

Sensor

Synch

Cont rol4

VideoDecode 6

Audio

Decode /Out put 10

User/SysCont rol

3

Mem13

F rame

Buff er7

VideoOut put 8

SimulationEstimationPartitioning

Toolset

Inte

rfac

e

DSP RA M

Externa lI/O

System RAM

DSPProcessor P

roce

ssor

Bu

s Contro lProcessor

Per

iph

eral

Bu

s

Peripheral

Peripheral

Peripheral

Product DevelopmentPeripheral Selection

Application SWMapping

EE249

Conclusion

n Separate the Behavior from Architecture.n Map between the Behavior and Architecture.

n Mapping paradigm extends to communication andrefinement.

EE249

Classic A/D, HW/SW tradeoff

n RF Front Endn Can trade custom analog for hardware, even for software

u Power, area critical criteria, or easy functional modification

LO

De-correlate(spread spectrum)

Analog vs. Digital tradeoff

De-modulate

A/DCustom

DSP

Suppose digital limit is pushed

DS 1-bitModulator

Dec.Filter

GenDSP

1-bitModulator

GenDSP

1-bitModulator

System Chip DSP

Digital expanding

e.g.

EE249

Example: Voice Mail Pager

n Design considerations cross design layersn Trade-offs require systematic methodology and constraint-

based hierarchical approach for clear justification

Modulation Scheme Choice (e.g. BPSK)

Q

IPf

De-correlate(spread spectrum)

Analog vs. Digital tradeoff

De-modulate

e.g.GenDSP

?

?

EE249 42

Where All is Going

HW/SW Co-Design Paradigm (Felix)

Rowson, ASV

Convergence of Paradigms

VSI Design Paradigm

Analog Top-DownDesign Methodology

Chang et al.

uCreate paradigm shift- not just link methodslNew levels of abstraction to fluidly tradeoff HW/SW, A/D, HF/IF,interfaces, etc- to exploit heterogeneous nature of components

lLinks already being forged

EE249 43

Concluding Remarksn The Industry Structure is undergoing a revolutionary

changen The Design Problems are changing radically their

main characteristics

n System Design is becoming more and more the key tosuccess

n System implies Major Emphasis on Softwaren Analog, Sensors, Actuators, RF must be part of designn Deep Submicron makes most of the tools obsolete