A General Synthesis Approach for Embedded Systems Design with Applications to Multi-media and Automotive Designs

A General Synthesis Approach for Embedded Systems Design with Applications to Multi-media and Automotive Designs

Alberto Sangiovanni Vincentelli

(Qi Zhu and Abhijit Davare)

2/34

OutlineOutline

Design Trends and Challenges

Semantic-Driven Synthesis FlowCommon Modeling DomainAutomatic Synthesis

Validating the Design FlowAutomotive Stability ControlImage Processing

Future Work

3/34

Toyota Autonomous Vehicle Technology RoadmapToyota Autonomous Vehicle Technology Roadmap

Source: Toyota Web site

4/34

ABS: Antilock Brake SystemACC: Adaptive Cruise ControlBCM: Body Control ModuleDoD: Displacement On DemandECS: Electronics, Controls, and Software

EGR: Exhaust Gas Recirculation.GDI: Gas Direct InjectionOBD: Onboard DiagnosticsTCC: Torque Converter ClutchPT: Powertrain

Valu

e fr

om E

lect

roni

cs &

Sof

twar

e

-More functions & features-Less hardware-Faster

Forefront of Innovation

Vehicle Integration

System Connection

Subsystem Controls & Features

Potential inflection point. Now! Hybrid PT Hybrid PT

Electric IgnitionElectric Ignition

ACCACC

Rear Vision Rear Vision

Passive Entry Passive Entry

Side AirbagsSide Airbags

Fuel CellFuel Cell

Wheel Motor Wheel Motor

……

OnStarOnStar

OBD IIOBD II

HI Spd DataHI Spd Data

Rear aud/vidRear aud/vid

CDsCDs

BCMBCM

ABSABS

TCCTCC

EGREGR

Electric FanElectric Fan

Head AirbagsHead Airbags......

Electric BrakeElectric Brake

DoDDoD

GDIGDI

……

……

……

…………

……

1970s 1980s 1990s 2000s 2010s 2020s

Electronics, Controls & Software Shifting the Basis of Competition in VehiclesElectronics, Controls & Software Shifting the Basis of Competition in Vehicles

$118

2 (+

196%

)$1

182

$1

182

(+19

6%)

(+19

6%)

50 E

CU

s(+

150%

)50

EC

Us

(+15

0%)

100M

Lin

es o

f Cod

e (+

9900

%)

100M

Lin

es o

f Cod

e (+

9900

%)

$400

$400

20 E

CU

s20

EC

Us

1M L

ines

1M L

ines

1M L

ines

Software $Other $ Electronics $ Software $Other $

2%13%

76%

9%

Mechanical $

13%

24%

55%

8%

Mechanical $

Electronics $

AVG. AVG.

Source: Matt Tsien, GM

5/34

A Typical Car Architecture (BMW)A Typical Car Architecture (BMW)

6/34

Design TrendsDesign Trends

Complexity of embedded systems

• Time to market• Reliability• Flexibility

Design reuseCorrect-by-construction

Separation of concerns

Functionality

MP3, MPEG-4, Wi-Fi, BT, GPS …

Architecture

Cell, MXP series, IXP series, Nexperia …Mapping?

7/34

Platform-based DesignPlatform-based Design

Platform: library of resources defining an abstraction layerResources do contain virtual components i.e., place holders thatwill be customized in the implementation phase to meet constraintsVery important resources are interconnections and communication protocols

PlatformDesign-Space

ExportPlatformMapping

Architectural SpaceApplication Space

Application InstancePlatform Instance

8/34

Fractal Nature of DesignFractal Nature of Design

9/34

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

abstr

act

Transistor ModelCapacity Load

1970’s

cluster

abstr

actGate Level Model

Capacity Load

1980’s

RTL

cluster

abstr

act

SDFWire Load

1990’s

IP Blocks

cluster

abstr

act

IP Block PerformanceInter IP Communication Performance Models

RTLClusters

SWModels

Year 2000 +

10/34

• Different semantics (e.g., synchronous vs. asynchronous)

• Different abstraction level(e.g. instruction vs. block level)

ChallengeChallengeFunctionality and Architecture are modeled separately

FunctionModel

ArchitectureModel

Mismatch

Mapping is ad-hoc, manual, error-prone

Find a common languageand decide the abstraction level

Mapping could be automatic, correct-by-construction

11/34

OutlineOutline

Design Trends and Challenges

Semantic-Driven Synthesis FlowCommon Modeling DomainAutomatic Synthesis

Validating the Design FlowAutomotive Stability ControlImage Processing

Future Work

12/34

Technology MappingTechnology Mapping

d+e b+h

t4’

at2 +ct1t3 + fgh

FFunction Architecture

Common language: Boolean logicPrimitives: NAND2 gate and inverter

b’ h’

a

d’ e’g

f

c

FFunction Architectureinv(1) nand2(2)

nor(2)

aoi21 (3)

xor (5)

nand3 (3)

oai22 (4)

nor3 (3)

Mapping

Covering

F

f

g

d

e

h

b

a

c

nand3(3)nand3(3)

oai21(3)oai21(3)

oai21 (3)oai21 (3)

and2(3)

inv(1)

nand2(2)

Mapped Design

13/34

Synthesis FlowSynthesis Flow

CMD

Covering

FunctionModel

ArchitectureModel

Function Model in CMD

ArchitectureModel in CMD

FurtherSynthesis

Stage 1

Stage 2

Stage 3

• Common language • Primitives

14/34

Q: semantic domain - language (trace-based agent algebra [R. Passerone, PhD thesis])Q.D: domain of agents – “building blocks”Q.A: master alphabet – “all signals between blocks”Q.α : Q.D -> 2Q.A, each agent has an alphabet which is a subset of Q.A – “each block has a set of signals”Operators: renaming, projection and parallel composition –“rules to initialize and compose agents”

Modeling Domain – Semantic DomainModeling Domain – Semantic DomainModeling domain is based on semantic domain and primitives

io12s1 s2i1 o2i1

s3

i1 o1 o2o2i2io12 io12

))((||))((( 21 srrenamesrrename )}),({ 213 oiprojs =

PN semantics

15/34

New agents can be constructed by applying a finite number of operators in sequence on existing agents.

Agent Closure CQ(S) contains all the agents that can be constructed from a set of agents S by applying operators in semantic domain Q.

Primitives P – abstraction levelPrimitives are agents, .No agent in can be constructed from other agents in , i.e., , there exists no s.t. .{s1, s2} is a set of primitives in PN semantics, {s1, s2, s3} is not.

Modeling Domain – PrimitivesModeling Domain – Primitives

io12

s1 s2i1 o2

s3

)'(PCp Q∈}{\' pPP ⊆Pp∈∀

DQP .⊆PP

16/34

Modeling DomainModeling Domain

Modeling domain M = CQ(P) is the agent closure of a set of primitives P in semantic domain Q.

Contains all the agents that can be constructed from P.E.g., CPN({s1, s2}) contains all the agents that can be constructed from {s1, s2} by applying operators in PNsemantics.Semantic domain Q provides a language for modeling.Primitive P defines a sub-space of the entire modeling space of Q. Abstraction level can be explored by choosing different primitives.

• What is the relation between different modeling domains?• What is common modeling domain?

17/34

BehaviorsΓ: 2Q.A -> 2T, each alphabet is associated with a set of traces over trace domain T.Each agent s has a set of traces Γ(Q.α(s)), which are called behaviors, denoted as B(s).

Ancestor-Child relation between modeling domainsФ(M) = {B(s) | s CQ(P) }.M1 = CQ1

(P1) is the ancestor of M2 = CQ2(P2)

if Ф(M2) Ф(M1), denoted as M2 ≤ M1.Example: CPN({s3}) ≤ CPN({s1, s2})Ancestor – more expressive, higher modeling complexityChild – more specific, lower modeling complexity

∈

⊆

Relation between Modeling DomainsRelation between Modeling Domains

s1i1 o1)()())(.()( 1111

∞∞ →×→=Γ= VoVisQsB α

18/34

Common Modeling DomainCommon Modeling Domain

A model is an agent in the modeling domain.

A modeling domain M is called common modeling domainbetween function model f and architecture model a if there exists f’ M and a’ M such that B(f’) B(f) and B(a’) B(a).

Function Model f inOriginal Modeling Domain

Architecture Model a inOriginal Modeling Domain

Function Model f’ in CMD Architecture Model a’ in CMD

∈ ∈ ⊆ ⊆

OC

C O⊆

19/34

CMD SelectionCMD Selection

F A

D

C

Original FunctionModeling Domain

Original ArchitectureModeling Domain

Common Ancestor Modeling Domain of F and A

Model TransformationModel Transformation

Search for CMDs onModeling Domain Relation Graph

CMD

Simplermodel

Largermapping space

20/34

CMD SelectionCMD Selection

Two design aspects when selecting CMD C = CQ(P)Semantics – decided by semantic domain Q

Expressiveness vs. Analyzability.e.g. Dataflow vs. Static dataflowFirst choose semantic domain for common ancestor domain D, then refine it in C.

Abstraction level – decided by primitives PExplore different abstraction level by choosing different primitives.Carried out when select C as child domain of D.Utilize ancestor-child relation to explore candidate child domains formally.

Trade-off: complexity and size of mapping space

21/34

OutlineOutline

Design Trends and Challenges

Semantic-Driven Synthesis FlowCommon Modeling DomainAutomatic Synthesis

Validating the Design FlowAutomotive Stability ControlImage Processing

Future Work

22/34

Symbols:Function primitive instances : Architecture primitive instances :Mapping decision variables : Quantities (power, area, bandwidth…): Costs (special quantities):

Constraints:Decision constraints:

Each function primitive instance needs to be covered by one and only one architecture primitive instance.

Quantity constraints:Constraints from architecture platform or design constraints, such as power constraints, bandwidth constraints, etc.

Objective function:Cost function:

),...,,( 21 nfffF

Covering Problem FormulationCovering Problem Formulation

=),...,,( 21 maaaA =

ijdlijkQlijkC

lt

lijkij

lt QCQdH ≤),(

∑∈

=iSj

ijd 1

),( lijkijl CdG

nii ≤≤∀ 1,

23/34

Solve Covering ProblemSolve Covering Problem

Covering Problem

Other design concernsSchedulingBuffer sizingComm. bandwidth……

General purpose solvers• MILP: CPLEX, MOSEK,

GLPK, …• GP: GGPLAB, YALMIP, …

Customizable Branch-based framework

Domain-specific Algorithms

∑∈

=iSj

ijd 1

lt

lijkij

lt QCQdH ≤),(

),( lijkijl CdG

24/34

OutlineOutline

Design Trends and Challenges

Semantic-Driven Synthesis FlowCommon Modeling DomainAutomatic Synthesis

Validating the Design FlowAutomotive Stability ControlImage Processing

Future Work

25/34

Automotive Stability Control Automotive Stability Control Find common language between functionality and architectureby choosing semantic domain Q in CMD CQ(P).

Functionality• synchronous Simulink model• no message loss or duplication

Architecture• clock drift between distributed ECUs, asynchronous comm.• data loss and duplication

mismatch

26/34

CMD Selection (Stage 1)CMD Selection (Stage 1)

Find CMD from modeling domain relation graph

D = CPN(PD)

F = CSR(PF) A = CLTTA(PA)

C1 = CLTTA(P1)C2 =CSR(P2)P2=PF U PA’

P1=PF’ U PA

Original Function modeling domain:Synchronous/Reactive semantics

Original Architecture modeling domain:Semantics of LTTA (loosely time-triggered architecture)

Common ancestor domain:Process Networks semantics

[1] H. Zeng, A. Davare, A. L. Sangiovanni-Vincentelli, et. al, “Design Space Exploration of Automotive Platforms in Metropolis,” SAE 2006

a’ = aB(f’) B(f)⊆f’ = f B(a’) B(a)⊆

27/34

Transformation of architecture modelTransformation of architecture model

CMD uses synchronous/reactive semanticsFunction model does not need to be changedArchitecture primitives PA should be transformed to PA’ in CMD to support synchronous/reactive semantics

Protocol to avoid data loss [1]– Constraints on process periods– Requires clock drift to be within a certain range

Clock synchronization to restrict the clock drift [2]Alternating bit to avoid data duplicationB(a’) B(a), but correct behaviors can be assured when function model f’ is mapped to architecture model a’

⊆

[1] A. Benveniste, P. Caspi, P. Le Guernic, H. Marchand, J.P. Talpin and Stavros Tripakis, “A Protocol for Loosely Time-Triggered Architectures”, EMSOFT '02

[2] M. Gergeleit and H. Streich, “Implementing a Distributed High-Resolution Real-TimeClock using the CAN-Bus”, 1st International CAN-Conference

28/34

Automatic Synthesis (Stage 2&3)Automatic Synthesis (Stage 2&3)

Covering problemFunction primitives instance fi : tasks and messagesArchitecture primitives instance aj : ECUs and busesQuantity constraints : maximum workload on ECUObjective function: minimize inter-ECU communication and balance computation load across ECUsUtilize the Scotch [1] package

Function model graph and architecture graphPartition-based algorithm solves the covering problem

Further synthesisTask priorities – based on pre-assigned message prioritiesTask periods

Adjusted to satisfy end-to-end latency requirementsTask periods need to satisfy the protocol to ensure the correctness of semantics

[1] Scotch, http://www.labri.fr/perso/pelegrin/scotch

29/34

Experimental ResultsExperimental Results

14 tasks, 48 messages

6 ECUs, 1 bus

Automatic synthesized design vs. 6 manual designs

Simulated in Metropolis framework

Design Total delay (ms)

Bus utilization

Max ECU utilization

Manual 1 787.10 57% 60%

Manual 2 761.84 50% 72%

Automatic 559.51 34% 48%

30/34

Image ProcessingImage ProcessingExplore abstraction level of the design by choosing primitives P in CMD CQ(P).

Functionality Architecture

• Data-driven application• Can be used in MPEG-2, Motion-JPEG, MPEG-4, etc. • Highly parallel heterogeneous

platform• Designed for image application• 8 image signal processors (ISPs)• 5 processing elements (PEs) in each ISP

31/34

Dataflow semantics

Choose proper abstraction level (granularity)Too coarse – inefficient usage of highly parallel platformToo fine – scheduling difficulties and model complexity

Explored four CMDsBlock levelCoarse sub-block levelFine sub-block levelInstruction level

CMD Selection (Stage 1)CMD Selection (Stage 1)

F A

Instruction

fine sub-block

coarse sub-block

block

32/34

DCT Quantization Huffman

1D-DCT Trans-pose 1D-DCT Trans-

pose

ZigZag Multi

RLE Lookup

Add4

Sub4

Mult1

Mult2

Add2

Sub2

CSC Shift

Block level CMD

Coarse sub-block level CMD

Fine sub-block level CMD

Function Model at Different CMDsFunction Model at Different CMDs

ancestor

child

33/34

Architecture ModelArchitecture Model

Architecture model has the same abstraction level in all CMDs for this case study.

PEs, global registers, memories are architecture primitives in all CMDs.Abstraction levels of mapped designs in this case study are dictated by the functional abstraction levels.

No single PE can support DCT block so block level CMD is not suitable.

Complexity is too high so instruction level CMD is not suitable.

Important to find a CMD at proper abstraction level

34/34

Automatic Synthesis (Stage 2&3)Automatic Synthesis (Stage 2&3)

Mapping at coarse and fine sub-block level CMDs.Function primitive instances fi : function blocks and channelsArchitecture primitive instances aj : PEs, GRs and memoryQuantity constraints : maximum # of registersObjective function: throughput

Compare # of cycles to perform DCT for a 8x8 block (simulated in Metropolis, accuracy within 1% [1])

[1] A. Davare, Q. Zhu, J. Moondanos and A. L. Sangiovanni-Vincentelli, “JPEG Encoding on the MXP5800: A Platform-based Design Case Study,” EstiMedia 2005.

0

200

400

600

800

1000

1200

1400

F-automatic F-manual-1 F-manual-2 C-automatic

Mappings

Cyc

les

Fine sub-block level

Coarse sub-block level

Choosing a CMD at proper abstraction level can greatly affect the performance of the mapping.

35/34

OutlineOutline

Design Trends and Challenges

Semantic-Driven Synthesis FlowCommon Modeling DomainAutomatic Synthesis

Validating the Design FlowAutomotive Stability ControlImage Processing

Future Work

36/34

Ongoing projects:Task allocation and priority assignment for automotive systems – stage 2Period synthesis for automotive systems – stage 3

Future work:Complete synthesis flow for automotive domainMultimedia domain case study – H.264Synthesis from synchronous models to general multi-processor platform

Future WorkFuture Work

Months01/07 3 6 9 12 1815

AutomotiveMultimedia

Sync. synthesis

37/34

ContributionsContributions

A synthesis flow in which semantics and abstraction level are formally determined, and automatic algorithms can be applied.

The method was validated by industrial case studies with different focus.

Automotive stability control: choose semanticsImage processing: explore abstraction levelRegardless of the focus, applications from different domains can be solved in the same way by our flow.