Software (System) Synthesis: Raising the Level of Abstraction

Alberto Sangiovanni VincentelliDepartment of EECS

University of California at BerkeleyQi Zhu

Intel Researcn, Oregon

Outline

• Lesson learned from logic synthesis

• ‘Software’ Synthesis Flow and Algorithms

• Case Studies

MBD: Code generation

High level input models(Simulink, Modelica, …)

Target code……

Direct code generation - No significant restructuring- Low level optimization- Manual partition

e.g. Mathworks RTW, dSpace TargetLink

Specification

Analysis

Dev

elo

pm

en

t P

roce

ss

BusesBuses

MatlabCPUs Buses Operating

Systems

Behavior Components Virtual Architectural Components

C-Code

IPs

Dymola

ECU-1 ECU-2

ECU-3Bus

f1 f2

f3

Behavior Platform

Mapping

PerformanceAnalysis

Refinement

Evaluation ofArchitectural

and Partitioning Alternatives

Implementation

Separation of Concerns (ca. 1990)

PlatformDesign-Space

Export

PlatformMapping

Architectural SpaceApplication Space

Application Instance Platform Instance

Platform-Based Design

Platform: library of resources defining an abstraction layer with interfaces that allow legal connections

• Resources do contain virtual components i.e., placeholders that will be customized in the implementation phase to meet constraints

• Very important resources are interconnections and communication protocols

© Alberto Sangiovanni-Vincentelli. All rights reserved.

5

Learning from logic synthesis

d+e b+h

t4’

at2+c

t1t3+fgh

b’ h’

a

d’ e’g

f

c

inv(1) nand2(2)

nor(2)

aoi21 (3)

xor (5)

nand3 (3)

oai22 (4)

nor3 (3)F

f

gd

e

h

ba

c

nand3(3)

oai21(3)

oai21 (3)

and2(3)

inv(1)nand2(2)

High level function model Gate library (platform)

Function model in netlist

Gate library in netlist

Technology Mapping (covering )

Mapped design

- Separation of func and arch- Common language for func and arch netlists (Boolean logic, NAND2 gate)- Automatic mapping

restructuring restructuring

Outline

• Lesson learned from logic synthesis

• ‘Software’ Synthesis Flow and Algorithms

• Case Studies

Our software synthesis flowFunction Model Architecture Platform

restructuring restructuring

Stage 1: Common modeling domain (CMD) selectionCommon semantics for func and archPrimitives to decide abstraction level

Function Modelin CMD

T2T1

T5

T3

T6T4 Architecture

Model in CMDStage 2: Automatic mapping

E1 E2 E3

……B1

E1 E2 E3

……B1

T1 T2

T3T4

Mapped Design in CMD

Stage 3: Code generation

Challenges in the flow

• Stage 1: Common modeling domain selection Various models of computation exist in system level.

Trade-off between expressiveness and ease of manipulation when selecting the common semantics.

Trade-off between granularity and optimality when selecting the primitives.

• Stage 2: Automatic mapping Various constraints and objectives.

Domain-specific algorithms may be used albeit not necessary.

• Stage 3: Code generation Communication interface synthesis maybe needed to guarantee

correct semantics.

Modeling domain

• Semantic domain Q - the language Formally defined as trace-based agent algebra [1]. Q.D: domain of agents - “building blocks”. Q.A: master alphabet – “set of all signals between blocks”. Q.α : Q.D -> 2Q.A, each agent has an alphabet – “each block has a

set of signals” Operators: renaming, projection and parallel composition –

“rules to initialize and compose blocks”

• Primitives P – abstraction level Primitives are a set of agents in a semantic domain, P Q.D . No agent in P can be constructed from other agents in P.

• Modeling domain CQ(P): all agents constructed from primitives P by applying operators in semantic domain Q.

[1] R. Passerone, Semantic Foundations for Heterogeneous Systems. PhD thesis, University of California, Berkeley, 2004.

Common modeling domain (CMD)

• A model is an agent in the modeling domain.• Function model f F, architecture model a A.• B(s) denotes the behavior of model s.• Modeling domain M is a common modeling domain between f and

a if there exists f’ M and a’ M s.t. B(f’) B(f) and B(a’) B(a).

Behavior of original function model f in F

Behavior of original architecture model a in A

Behavior of function model f’ in CMD

Behavior of architecture model a’ in CMD

O

Λ

• f and a may have different semantics or abstraction level – hard to explore o.• f’ and a’ in CMD – mapping space Λcan be formally explored.• Λ o – mapped behavior is legal.

Illustration of mapping space in CMD

CMD selection• Ancestor-child relation between modeling domains.

Define Ф(M) = {B(s) | s CQ(P) } – set of all agent behavior.

M1 = CQ1(P1) is the ancestor of M2 = CQ2

(P2) iff Ф(M2) Ф(M1).

• Search CMDs on modeling domain relation graph (directed edges representing ancestor-child relation).

FA

D

C

Original FunctionModeling Domain Original Architecture

Modeling Domain

Common Ancestor Modeling Domain of F and A

CMD Selection

expressive but too complex to explore

may lose behavior but tractable mapping

CMD selection contd.

• Two design aspects when selecting CMD C = CQ(P)

Semantics – decided by semantic domain Q

o Expressiveness vs. analyzability, e.g. dataflow vs. static dataflow.

o May first choose semantic domain for common ancestor domain D, then refine it in C.

Abstraction level – depends on primitives P

o Explore different abstraction level by choosing different primitives.

o Carried out when selecting C as child domain of D.

For both, it is a trade-off between the size of mapping space and complexity.

Covering problem after CMD selection

• Symbols: Function primitive instances :

Architecture primitive instances :

Mapping decision variables :

Architecture selection variables:

Quantities (power, area, bandwidth…):

General covering formulation

),...,,( 21 nfffF

),...,,( 21 maaaA

jas

tataf jjiQQ ,,,

ji afd ,

Function covering constraints

Architecture selection constraints

Quantity constraints

Objective functions

Domain specific.Determines complexity!

Outline

• Lesson learned from logic synthesis

• ‘Software’ Synthesis Flow and Algorithms

• Case Studies

Case study: active safety vehicle

• Functional correctness and cost-efficiency are both important for active safety applications.

• Function and architecture mismatch.

Function model• synchronous model.• no message loss or duplication.

Architecture platform• clock drift between distributed ECUs, asynchronous communication.• data loss and duplication exist.

SwTask

1_1

MW 1Bus

Sender

1

Bus

SwTask

1_m1

MW i

SwTask

i_1

SwTask

i_mi…... …...

Bus

Receiver

1

Bus

Receiver

i

Bus

Sender

i

send

receive

send

receive

………

mismatch

Stage 1: CMD selection – common semantics

D = C PN (PD)

F = C SR (PF)

A = C LTTA (PA)

C1 = C LTTA (P1=PF’ U PA)

C2 =C SR (P2=PF U PA’)

Original FunctionModeling Domain

Original ArchitectureModeling Domain

CMD Selection

1. Process Networks (PN): expressive but high modeling complexity. Need transformation of both func and arch models.

2. Loosely time triggered architecture (LTTA): transformation of func model to support asynchronous communication.

3. Synchronous reactive (SR): transformation of the arch to support synchronous communication, by applying following protocols.

• Clock synchronization.• Constraints on task periods.

Chosen in this case study

Stage 2: covering problem

Functional Model Architectural Model

Covering variables- Task to ECU- Signal to message- Message selection- Priority- Period

Quantity constraints and objective functions - End-to-end latency- Utilization- Extensibility - ……

Variety of algorithms- mathematical programming- heuristics- meta-heuristics- machine learning- ……

ECU1 ECU2

ECU3 ECU4

BUS1

BUS2

IRSensor

WheelSensor

FusionTask

ObjectID Task

Brake Act.

Nav.Task

150 ms

Primitives: tasks, signals Primitives: ECUs, messages on buses

Stage 2: covering problem contd.

• Worst case analysis for CAN systems with periodic tasks and messages.• A complete formulation with all design variables does not scale for

industrial size problems.• We start with tackling following sub-problems.

Problems PeriodSynthesis [1]

Allocation & PrioritySynthesis [2]

ExtensibilityOptimization [3, 4]

Variables Period AllocationPriority

AllocationPriority

Objective Latency Latency Extensibility

Approach Geometricprogramming (GP)

Mixed integer linear programming (MILP)

Multi-step Heuristic

*1+ “Period Optimization for Hard Real-time Distributed Automotive Systems”, 44th DAC, 2007. *2+ “Definition of Task Allocation and Priority Assignment in Hard Real-Time Distributed Systems”, 28th RTSS,

2007.*3+ “Optimizing Extensibility in Hard Real-time Distributed Systems”, 15th RTAS, 2009.*4+ “Optimizing the Software Architecture for Extensibility in Hard Real-Time Distributed Systems”, TII, 2010.

Allocation & priority synthesis (MILP based)

Step1:Synthesize task allocation(using MILP)

Step2:Synthesize signal packing, task and message priorities(using MILP)

Constraints:End-to-end latency on given pathsUtilization bound on ECUs and busesObjective:Sum of latencies on given paths

Design inputs:Task worst case execution timesTask and signal periodsArchitecture topology, bus speeds

Heuristic:Task and signal priorities

After mapping- Meet all requirements- Total latency from 36486ms in manual design to 12900ms

Allocation & priority synthesis results

End to end latencies

Sensing & Object

Detection

Target

Object

Selection

Object

FusionObject

Tracking

ArbitrationFeatures

Map

GPS

Map2ADAS

Mid-Range

Forward

Object

Detection

and Fusion

Long-Range

Forward

Object

Detection

RF-MRR

Object Data

LF-MRR

Object Data

Forward-

Looking

Camera

Object

Detection

Lane

Sense

Mid-Range

Rear

Object

Detection

and Fusion

Right Side

Object

Detection

Front-LRR

Object Data

Front

Camera

Object Data

Front

Camera

Lane Data

Map

Data

GPS

Data

LR-MRR

Object Data

RR-MRR

Object Data

Wheel

Speed

Sensors

Rear

Fusion?

Forward

Object

Fusion

SAS, PAS, RWA,

Yaw Rate, Lat

Accel, VehSpd,

Actual Gear,

Actual Direction of

Travel

Vehicle

Path

Calc

Camera

Forward

Object List

Long-Range

Forward

Object List

Mid-Range

Forward

Object List

Lane

Path

History

Forward

Lane Path

Estimation

Map

Lane Data

Optical

Lane Data

Rear

Lane

Path

FSRACC

ACP

TOS_LCA

TOS_VB

TOS_ACP

TOS_FCA

TOS_FSRACC

SBZA

LCA

SAPA

LK

LDW

VB

FCA

Optical

Lane Data

Actuators

MSB_L

MSB_R

Haptic

Seat

Suspension

Steering

HW

Troque

Brake

Park

Brake

HUD

OSRVM_R

OSRVM_L

DIC

Cluster

.

Raw Wheel

Speeds

Forward

Lane

Path

Forward

Lane

Path

Map

Lane Data

(Road Class)

.

.

Forward

ACP

Target

Data

Forward

Nearest

In-Path

Target

Data

.

.

.

.

.

HMI

Supervisor

.

.

.

Commanded

Damping

Hold

Vehicle

Commanded

Vehicle

Accel

Commanded

RWA

.

Commanded

Engine

Torque

.ACP

Criticality

Vector

ACP

Criticality

Vector

FSRACC

Brake &

Engine

Commands

ACP

Suspension,

Brake, &

Engine

Commands

.

VB

Brake &

Engine

Commands

.Mid-Range

Rear

Object List

ForwardObject

List

Vehicle

Path

Optical

Lane Data

Map

Lane Data

Go

Notifier

.

Left Side

Object

Detection

.

.

.

.

TOS_SBZA

Left Side

Short-Range

(U/S ?)

Right Side

Short-Range

(U/S ?)

Left Side

Mid/Long

Range

(Radar ?)

Right Side

Mid/Long

Range

(Radar ?)

Left Side

Object

List

Right Side

Object

List

NAPA

LF-

MRR

RF-

MRR

Front-

LRR

Accel Pedal,

Brake Pedal,

Steering Whl,

Gear Lever Driver’s

Control

Commands

Front-

Camera

LR-

MRR

RR-

MRR

Mid-Range

Rear

Object List

Vehicle Motion DataVehicle Motion Data

Driver’s

Control

Commands

Map

Data

(Overpass)

Vehicle

Path

Lane

Function

On/Off

Switch

Switch

Status .

ACC

Engaged

LDW

LED in

Switch ?LED

Command

Chime.

.

.

.

CSV DFD 1.6 -

060119

Driver’s

Enable/Disable

Inputs

Switch

Switch

Turn

Signal

Switches

Switch

Switch

AFS

Throttle

Long-Range

Forward

Object List?

Must fix all feature

descriptions in your

files

since the HMI

Supervisor

has been removed.

Switch

Status

Vehicle

Motion

Control

Supervisor

Feature Control

Output Arbitrator

Other

Control Output

Arbitration

Commanded

Vehicle

Accel

ACP

Criticality

Vector BCMBody

Function

Actuators

Switch

Status

Vehicle

Position

in the Lane

...ECU1 ECU2

...ECU20 ECU21

...

...ECU61 ECU62

Function Model- 41 Tasks- 83 Signals- 171 paths

Architecture platform- 9 ECUs- single bus

Mapping

Extensibility optimization (MILP and heuristic)

Initial Task Allocation(MILP)

Signal Packing and Message Allocation(Greedy Heuristic)

Task and Message Priority Assignment(Iterative Heuristic)

Task Re-allocation(Heuristic for incremental changes)

Reach Stop Condition?

Yes

End

No

Initial Task and Signal Priority (Heuristic)

Extensibility optimization results• Same active safety vehicle as in allocation and priority synthesis.• Single-bus and dual-bus options.• Parameter K to trade off between extensibility and latency. • Compared with a simulated annealing algorithm: maximum

extensibility within 0.3%, runtime 0.5 hour vs. 12 hours.

0

5000

10000

15000

20000

25000

30000

16 17 18 19 20 21 22 23 24 25

Tota

l Lat

ency

(m

s)

Task Extensibility

2 buses case 1 bus case

K=0K=0

K=0.1

K=0.1

K=0.2K=0.5

K=0.2K=0.5

1 bus case manual

Case studies in other domains

• Building automation domain [1] Similar semantics as in automotive – synchronous function model and

LTTA architecture platform.

Also choose SR as the common semantics, however additional timing constraints are added to the architecture for preserving synchronism, as we consider the physical interaction with environment.

Mapping leverages COSI for communication network synthesis.

• Multimedia domain [2] JPEG encoder application. Intel MXP architecture platform.

Semantics for both function and architecture are dataflow.

Challenge is to choose the proper abstraction level. Different levels are explored and compared through choices of primitives.

*1+ “A Design Flow for Building Automation and Control Systems”, 31st RTSS, 2010. *2+ “JPEG Encoding on the Intel MXP5800: A Platform-Based Design Case Study”, ESTIMedia’05, 2005.

Concluding remarks

• Software (and hardware) synthesis based on a formal mapping procedure Formally determines the semantics and abstraction level of the design

by choosing a common modeling domain.

Automatic and optimal mapping algorithms.

Generality – applied to various domains with different models of computation as well as different implementation platforms. Domain-specific mapping algorithms may be leveraged in the framework.

Optimality – trade-off between complexity and mapping space through the selection of CMD.

Reusability – common semantic selection requires designers’ expertise. However proper selection is typically general for particular domains.