CADENCE CONFIDENTIALCADENCE CONFIDENTIAL

Design Methodologies for the Nanotechnology EraAlberto Sangiovanni-Vincentelli

Outline

• Motivation

• Design Challenges

• Platform-based Design

• Communication-Based Design

• Implementation Platforms: Constructive Fabrics

• Analog Platforms

Disaggregation:Electronic Systems Design Chain

EDA

Manufacturing

Implementation

System Design

PlatformBasedDesign

IP

InterfacesFabrics

6,000

6,500

7,000

7,500

8,000

8,500

9,000

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007

ASIC Design Trend

Source: IBS

-27%

Design Starts

Electronic Design: A Vision

• Embedded Software will be increasingly critical in the Electronic Industry

• Embedded Software Design must not be seen as a problem in isolation, it is an, albeit essential, aspect of EMBEDDED SYSTEM DESIGN

• Our vision is to change radically the way in which ESW is developed today by linking it:

– Upwards in the abstraction layers to system functionality

– Downwards in the programmable platforms that support it thus providing the means to verify whether the constraints posed on Embedded Systems are met.

• Programmable Platforms must be developed efficiently leveraging IP-reuse and Application Space knowledge

• The future of the industry is pinned on the success of this plan

Outline

• Motivation

• Design Challenges

• Platform-based Design

• Communication-Based Design

• Implementation Platforms: Constructive Fabrics

• Analog Platforms

A Discipline of Platform-Based Design (ASV, GSRC 2000)

Silicon Implementation PlatformSilicon Implementation Platform

Architectural PlatformArchitectural Platform

Manfacturing InterfaceManfacturing Interface

Silicon ImplementationSilicon Implementation

Basic device & interconnectstructures

Delay, variation,SPICE models

Microarchitecture(s)Microarchitecture(s)

Circuit Fabric(s)Circuit Fabric(s)

Functional Blocks,InterconnectCycle-speed, power, area

S SV V SG

SG

SSV

V

SS SSVV VV SSGG

ApplicationApplication

Architecture(s)Architecture(s)

Kernels/BenchmarksProgramming Model:Models/Estimators

The design process is meet-in-the-middle:•Top-down: map an instance of the top platform into an instance of the lower platform and propagate constraints•Bottom-up: build a platform by defining the “library” that characterizes it and a performance abstraction (e.g., number of literals for tech. Independent optimization, area and propagation delay for a cell in a standard cell library)

The library has elements and interconnects

ASV Platforms (2001)

For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.

For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.

Upper layer of abstraction

Lower layer of abstraction

Constraints Performance Annotation

In general, a platform is an abstraction layer that covers a number of possible refinements into a lower level.

Platform

Mapping Tools

Platform

Platform stack{

Specification

Analysis

After Sales Service

Calibration

Implementation

Dev

elo

pm

ent

Pro

cess

BusesBusesMatlab

CPUs Buses OperatingSystems

Software Components Virtual Architectural Components

C-Code IPs

ASCET

ECU-1ECU-1 ECU-2ECU-2

ECU-3ECU-3BusBus

f1f1 f2f2

f3f3

System Behavior System Platform

Mapping

Performance Simulation

Refinement

Evaluation ofArchitectural and Partitioning Alternatives

Design Methodology: Orthogonalize Concerns

Consequences

• There is no difference between HW and SW. Decision comes later.

• HW/SW implementation depend on choice of component at the architecture platform level.

• Function/Architecture co-design happens at all levels of abstractions

– Each platform is an “architecture” since it is a library of usable components and interconnects. It can be designed independently of a particular behavior.

– Usable components can be considered as “containers”, i.e., they can support a set of behaviors.

Outline

• Motivation

• Design Challenges

• Platform-based Design

• Communication-Based Design

• Analog Platforms

Picoradio Sensor Networks (BWRC)

Control Environmental parameters (temperature, humidity…)Control Environmental parameters (temperature, humidity…) Minimize Power consumptionMinimize Power consumption Cheap (<0.5$) and small ( < 1 cmCheap (<0.5$) and small ( < 1 cm33))

Large numbers of nodes Large numbers of nodes — — between 0.05 andbetween 0.05 and 1 nodes/m1 nodes/m22

Limited operation range of network Limited operation range of network —— maximum 50-100 m maximum 50-100 m Low data rates per node Low data rates per node —— 1-10 bits/sec average 1-10 bits/sec average Low mobility (at least 90% of the nodes stationary)Low mobility (at least 90% of the nodes stationary)

sensoractuator

controller

• Key challenges

– Satisfy tight performance and cost constraints (especially power consumption)

– Identify Layers of Abstraction (Protocol Stack)

– Develop distributed algorithms (e.g. locationing, routing) for ubiquitous computing applications

– Design Embedded System Platform to implement Protocol Stack efficiently

Embedded System Platform

Network Design Using Platforms

Application components Requirements

Components Adaptation

Communication Refinement (Protocol Stack + Gateways)

On-Chip Networks

Network Platforms

event trace:

es11, es12, es13 er11, er12

er21, er22, er23es21, es22

node

linkportI/O port

• Network Platform (NP): Library of communication resources (protocols, channels…)

• Network Platform Instance (NPI): selection of NP resources

– Structure: set of resources and topology

– Behavior: set of event traces (events model send or receive actions)

Communication Refinement

• Replace components in abstract NPI with set of resources or NPIs

• Select resources from NP library and compose them to create NP with new Communication Services

• NP resources

– Channels (C ): transfer messages

– Protocols (P): adapt Communication Services

– Gateways (G): interface NPs

• Check refined NPI satisfies constraints

NPP P

NP’

NP GNP2NP1

Design of a Platform Layer: Ulysses

• Protocol Synthesis from Scenario-based (UML) Specifications

– Avoid early partitioning into components

– Problems: optimality, scenario interactions

– Specify scenarios independently

– Compose scenarios

Ulysses

• Pattern-based Design

– Library of Protocol Patterns: framing, retransmissions

• Multiple levels of abstraction (and Models)

– UML Message Sequence Charts (MSCs)

– Petri Nets (PNs)

• PNs Synthesis from MSCs

• Protocol synthesis and optimization driven by PN algorithms

P1 P2U1 U2

read write

Embedded System Platform

Network Design Using Platforms

Application components Requirements

Components Adaptation

Communication Refinement (Protocol Stack + Gateways)

On-Chip Networks

Adaptation of Component Behavior: The essence of IP-reuse (GSRC)

• The components in the NP library must come with specified abstract interfaces

• The composition of components can either be direct, when the interfaces are compatible, or through an adaptor, if they can be made compatible

• We provide a formulation of the problem that can be used to both verify compatibility and to synthesize the adapter

Interface Compatibility

Protocol 1 Protocol 2

Are the two protocols compatible?Interface Theories [de Alfaro and Henzinger]

Interface Adaptability

Protocol 1 Protocol 2

Can the two protocols be made compatible?Interface Synthesis [Passerone, Rowson, ASV]

Adapter

Interface Synthesis

Protocol 1 Protocol 2

What does compatible really mean?[Passerone, de Alfaro, Henzinger, ASV]

Adapter

Specification

Communication Synthesis Platform

M 1

M 2

M 3

M 4

M 5

M 1

M 2

M 3

M 4

M 5

P2P Specification

Communication Implementation

CkSkewWiresBuffers

Processes +Shells l=1

l=1

Relay Stations

(x1,y1)(x2,y2)

(x3,y3) (x4,y4)

bw1+bw2bw3+bw4

Links

Comm. nodes

(bw1,d1)

(bw2,d2)

(bw3,d3)

(bw4,d4) (bw5,d5)

CommunicationSpecs

Communication Synthesis Platform StackCommunication Synthesis Platform Stack

Constraints

– System modules communicate by means of point-to-point unidirectional channels

– Each channel is characterized by a set of communication constraints (distance, minimum bandwidth)

– The specific functionality of each module is “abstracted away”

• Abstract Model

Library

cost

Length

b1

b2

clk

Relay Station Switches

Cr(b)

Cs(b)

Cs(b)

This is the basic library of Communication Components

Synthesis of Communication Architecture

Library of Pre-designedCommunicationComponents

Point-to-PointChannel Communication Constraints

CommunicationArchitecture Implementation

Synthesis

Communication Implementation

Lib

n r

l1

l2

Metropolis Framework

Infrastructure

• Metropolis meta-model

- language

- modeling mechanisms• Meta-model compiler

Meta-model Library

• Models of computation

Meta-model Library

• Architecture platforms

Tools

Simulator QSS PIG STARS SPIN …

Application-specific methodologies

Multi-media, wireless communication, mechanical controls, processors

Metropolis meta-model

• Computation : f : X Z

• Communication : state evaluation and manipulation

• Coordination : constraints over concurrent actions

- process : generates a sequence of events

- medium : defines states and methods

- quantity : annotation of each event (time, energy, memory, …)

- logic : relates events and quantities, defines axioms on quantities

- quantity-manager : algorithm to realize annotation subject to relational constraints

Concurrent specification with a formal execution semantics:

Key difference with respect to Ptolemy, UML, SystemC, …!!!

Concurrent specification with a formal execution semantics:

Meta-model : function netlist

process P{

port reader X;

port writer Y;

thread(){

while(true){

...

z = f(X.read());

Y.write(z);

}}}

medium M implements reader, writer{

int storage;

int n, space;

void write(int z){

await(space>0; writer ; writer)

n=1; space=0; storage=z;

}

word read(){ ... }

}

interface reader extends Port{

update int read();

eval int n();

}

interface writer extends Port{

update void write(int i);

eval int space();

}

MP1X Y P2X Y

Env1 Env2

MyFncNetlist

R

I

F A

M

Meta-model: execution semantics• Processes take actions.

– statements and some expressions, e.g.

y = z+port.f(), port.f(), i < 10, …

• An execution of a given netlist is a sequence of vectors of events.

– event : the beginning of an action, e.g. B(port.f()),

the end of an action, e.g. E(port.f()),

null (no-op) N

– the i-th component of a vector is an event of the i-th process

– synchronous trace-based semantics

– time and other quantities elapse and actions are executed in states

– no assumption on atomicity whatsoever (unless explicitly modeled)

• An execution is feasible if

– it satisfies all coordination constraints, and

– it is accepted by all action automata defining meta-model semantics

Meta-model: architecture componentsAn architecture component specifies services, i.e.

• what it can do

• how much it costs

: interfaces

: quantities, annotation, logic of constraints

medium Bus implements BusMasterService …{

port BusArbiterService Arb;

port MemService Mem; …

update void busRead(String dest, int size) {

if(dest== … ) Mem.memRead(size);

[[Arb.request(B(busRead));

GTime.request(B(memRead),

BUSCLKCYCLE +

GTime.annotation(B(busRead)));

]]

}

…

scheduler BusArbiter extends Quantity

implements BusArbiterService {

update void request(event e){ … }

update void resolve() { //schedule }

}

interface BusMasterService extends Port {

update void busRead(String dest, int size);

update void busWrite(String dest, int size);

}

interface BusArbiterService extends Port {

update void request(event e);

update void resolve();

}

BusArbiterBus

R

I

F A

M

Meta-model: architecture netlist

Bus

ArbiterBus

Mem

Cpu OsSched

MyArchNetlist

…

…

…

Master

CPU + OS

Slave

Mem

Arbiter

Architecture netlist specifies configurations of architecture components.

Each constructor

- instantiates arch. components,

- connects them,

- takes as input mapping processes.

R

I

F A

M

Meta-model: platforms

interface MyService extends Port { int myService(int d); }

medium AbsM implements MyService{ int myService(int d) { … }}

B(thisthread, AbsM.myService) <=> B(P1, M.read);

E(thisthread, AbsM.myService) <=> E(P2, M.write);refine(AbsM, MyMapNetlist);

MyArchNetlistMyFncNetlist MP1 P2

B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);

MyMapNetlist1

MyArchNetlistMyFncNetlist MP1 P2

B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);

MyMapNetlist1

B(…) <=> B(…);

E(…) <=> E(…);refine(AbsM, MyMapNetlist1)

MyArchNetlistMyFncNetlist

MP1 P2

B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);

MyMapNetlist2

M

B(…) <=> B(…);

E(…) <=> E(…);

refine(AbsM, MyMapNetlist2)

A set of mapping netlists, together with constraints on event mappings, constitutes a platform (constrained set of possible implementations) with a given interface.

R

I

F A

M

R

I

F A

M

Meta-model: recursive platforms

S

N N'

B(Q2, S.cdx) <=> B(Q2, mQ2.excCpu); E(Q2, M.cdx) <=> E(mQ2, mQ2.excCpu);

B(Q2, Q2.f) <=> B(mQ2, mQ2.mapf); E(Q2, P2.f) <=> E(mQ2, mQ2.mapf);

MyArchNetlistMyFncNetlist MP1 P2

B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, )B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);

RTOSNetlist

MyArchNetlist

MyFncNetlist

MP1 P2B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf);

M

RTOS

Outline

• Motivation

• Design Challenges

• Platform-based Design

• Communication-Based Design

• Analog Platforms

Motivation

Optimality?Exploration?

Focus

• Focus on System Level Design

– Enable effective design exploration

– Evaluate tradeoffs while proceeding top-down

– Allow integration of third-party components

– Move design optimization as high as possible

– Co-design with the digital part (BB+Protocol)

• Not HW/SW co-design, but HW/SW/Analog!

Analog Design Flow

System Specs

Behavioral models–Matlab, Excel, …–Define Block requirements

Circuit design–Size, Simulate and iterate

Layout design–Verify and iterate

Syst

em

Level

Exp

lora

tion

Cir

cuit

S

izin

g &

Syn

thesi

s

Analog Design Flow

System Specs Behavioral models

–Matlab, Excel, …–Define Block requirements

Circuit design–Size, Simulate and iterate

Layout design–Verify and iterate

Syst

em

Level

Exp

lora

tion

Cir

cuit

S

izin

g &

Syn

thesi

s

Analog Platform

Analog Platforms

• An Analog Platform is a library of analog components and interconnects that implements a set of functionalities

• An Analog Platform consists of:

– Behavioral models – provide an efficient way to simulate mapping effects at the current platform level

– Performance models – constrain the possible behaviors to the considered platforms

Analog Platforms

• Classic top-down approaches suffer for limited predictability of performances Introduce a new level of abstraction

• Platforms abstract underlying components providing:

– Estimation mechanisms (i.e. models) for platform level optimization

– Mapping mechanisms to propagate constraints to next level

• Platforms provide accurate exploration mechanisms by limiting the search space

• Platforms may encapsulate synthesis paths

Analog Platform Stacks

Filter

Diff. S.Ended

OpAmp Lib1 OA Lib2

Sw.Cap Cont.T.

Perf

orm

ance

Est

imat

ion

Map

ping

Too

ls

• APs allow efficient top-down flows for analog systems

Platform stacks allow the selection of optimal architectures and topologies for analog components

At each level of abstraction in the platform stack, performance models allow transforming requirements into satisfiable next-level constraints

Any platform instance is implementable by definition

OpAmp

Analog Platforms

• The Analog Platform (AP) concept applies at different levels of abstractions

– Custom circuits – APs can be derived by automatic characterizationof the circuit

– IPs – APs can be used to encapsulate and characterize Intellectual Properties (possibly customizable Synthesizable Cores)

– Programmable cores – Field Programmable Analog Arrays (FPAA) provide the first example of generic analog platform

Behavioral Models

• A behavioral model is a mathematical parameterized representation of a circuit/component

– still a functional model, no notion of architecture

• How to select rin, i2noise, g1, g2, g3, f-3dB, rout?

– Feasible (compatible) values depend on the real implementation of the platform optimization

2noisei 2

2 invg3

3 invginvg1 outrinr dBf 3

voutvingain

Behavioral ModelIdeal Model

Behavioral Models Hierarchy

• Behavioral models should be organized in form of trees, one for each functional block

– the root node represent the universal model for the functionality

– deeper nodes represent refined models, which already have some architectural assumption

– leaf nodes represent the most detailed behavioral models specific for implementation architectures

Model Representation

• Right now, continuous time prototypes in Matlab/Simulink

– easy to use and powerful prototyping environment

– integration with external code

– de facto standard among analog system designers

• However, HDL-A languages may represent a viable alternative

– more industrial environment

– tool integration

– Co-simulation/co-verification?

Performance Models

• Top-down flows need to estimate performances

– Constrain behavioral models parameters

– set of compatible {gain, noise, dist.,…} n-tuples

• Architectural constraints can be represented through mathematical relations

(Power, Gain, NF, IIP3, P-1dB, DR, …) = 1 {Power, Gain, NF,…} are feasible with the current Platform

• No need for considering actual design variables that achieve specific performances

– Abstract away unnecessary implementation details

Constraint Relations (I)

• Approximate off-line through sampling

• Build estimation methods bottom-up

• Let’s define:

is the set of n-tuples ( n) {W1, W2, …, L1, L2, …, IB1, …, VB1, ..}

is the set of m-tuples ( m){Power, Gain, NF, IIP3, P-1dB, DR,…}

• AP Evaluation defines a function f: n m

• f() can be evaluated in different ways

– analytical expressions

– simplified models/simulations

– Spice accurate simulations

Constraint Relations (II)

• Operatively

– define and (define architectural space)

– get = f()

– build a relation (x)=1 x

needs to sample the image of is a n-dimensional space

– Limit n by proper definition of

– Keep granularity as low as possible

– Trade-offs with composition modeling

– Design of Experiments

– Capture designer experience to prune

– Build a constraints graph for the circuit

W

L

G

NF

Generating f()

• Given the definitions of and , and a constraint graph, f () is randomly sampled

• Operatively, Ocean scripts templates are available to automate the process

• Sampling is computationally expensive but requires no man-power

– On the order of 1000 samples may be necessary depending on the accuracy and on the “size” of

Example

• Example:

– Original, 7 7

– Shown, projection in 3

Proposed Methodology

• Separate the design of single blocks from the system optimization

– Third party’s platforms

– Largest performance improvements come from new topologies

– Do not limit designer’s creativity

• Generate functional models

• Generate performance models

• Perform system optimization at the behavioral level

– use hierarchical models and refinement to select topology

Analog Design Flow

Mapping

Performance Eval/System Optimization

PLL

Behavioral Models

Int. APsExt. IP’s

Performance ModelsNew APs

BehaviorRefinement

Architecture Refinement

Constraints Interpolation

• Given a set of samples, build an approximation for

– because of the generality of the evaluation scheme, few properties can be leveraged

• Assume the evaluation to define a continuous function

– reasonable while exploring “working” circuits

• Assume to be a connected set

• Then, is a connected set in m

– given x1 and its nearest neighbor x1N, if they are “close enough” then all the points in the segment x1-x1N satisfy

• Therefore, approximate with the smallest connected set containing the sample points

Support Vector Machines

• Statistical learning machinery to infer from data

• SVM’s belong to the class of large margin classifiers

– pioneered by Vapnik and Chervonenkis in the Sixties

• Simple conceptual model: hyperplane classifiers

– Separate data into classes using hyperplanes

– Can manage complex models

– Still mathematically analyzable

– Good control on (over)fitting

Operations on Platforms

• Analog Platforms stacks require three operations to be defined:

• Abstraction – Given a detailed platform, generate constraints for an abstracted AP

• Composition – Given constraints for two connected APs, derive constraints for the composition

• Merge – Given different platforms for the same functionality, generate constraints considering the union of s

Abstraction

• Top-down flows and model hierarchies require to derive multiple abstraction for one block

• Use relations where some of the parameters are free

{Power, Gain, NF} = {Power, Gain, NF, , , }

{Power, Gain, NF} =1 IIP3*, P-1dB

*, DR*,… s.t. {Power, Gain, NF, IIP3*, P-1dB

*, DR*,…}=1

are obtained from by projection onto a smaller

• This happens when the model is more general than the implementation

Projection on SVMs

• Need an efficient way to compute

– maximize

with respect to x (x=[x x] m)

– global optimization of a nonlinear function

– simulated annealing

– ad hoc technique

– optimum in the neighborhood of some SV

– complexity o(nl)

– 2 orders of magnitude faster than SA

,1

2

nSV

i

xxii beybxf ixw

Composition

• Composability is a key requirements for building complex (hierarchical) models

• Behavioral models don’t have any intrinsic notion of loading effects

• Need to include interface characterization parameters in the relation

– include ancillary parameters in

– check compatibility of interfaces

– Dynamic Range, Bias point…

– automatic insertion of converters?

• Similar to Communication Based Design for the digital world

Composition

• Define:

– x = [x ], y=[y, ], z=[x y]

AB([x y]) = 1 s.t. A ([x ]) = B([y ]) = 1

• In terms of SVM’s

0

0 ..

1max

1

122

22

nSV

iB

Bi

nSV

iA

Ai

BiB

BiB

AiA

AiA

ee

eets

λλyy

λλxx

λ

Block A A(x)

Block B B(y)

Merge

• Merge is defined in terms of performance relations building a new relation:

= 1+ 2+… k

i are constraints for different Analog Platforms (e.g. for a single ended LNA, a differential LNA, cascoded and so on)

– ‘+’ is the logical OR function

• Architecture selection is achieved selecting platform instances in . The mapping process will then select i

Closure

• Closure is a composition that involves a transformation in the abstraction space

• Closure defines a new platform that is non-trivially related to the composing ones

– E.g., in a PLL, jitter of single components, non linearities and transfer functions get transformed into locking range, acquisition time, phase noise, …

• Closure is implemented through the same process used for AP generation on the first instance

LF

VCO

PLL

Top-down with APs

• Complex optimization strategies can be used at system level

– #params at top level is moderate to low

– behavioral models reasonably fast

• Optimize the system and refine the architectural blocks

• At the end, a set of specs is provided for each Platform Platform Instance

– Constraints achievable by construction

• Generate the actual circuits

– Designers, IP providers, Automatic tools …

• Proceed with appropriate bottom-up verification

Sensor Interface Example

MEMS Pressure Sensor

ADC Converter

Signal Conditioning

10 bit1 kSamples/s

Input range: 0.5-1.5VBandwidth: 500 Hz

FSO: 200 mVR: 1000-2300 R/T: 1800ppm

Bridge Linearization

TemperatureCompensation

Amplification DC Offset

Nyquist Filter

Comm. Adapter

Synthesize and Map on Proper Platform• Off-the-Shelf Components• Field Programmable Analog Arrays• Custom Solutions

Performance Representation

• Platform performance spaces are derived bottom-up by sampling platform instances

Performances can be represented using Support Vector Machines (SVMs)

Fundamental Question and the Role of Platform-Based Design

• Question:

– Will design and manufacturing become intertwined as in the past?

• Analysis:

– Productivity higher if clean separation among layers of abstraction

– Can we afford inefficiency in silicon?

– If yes, what is the price to pay?

• Platform-based design is a disciplined methodology based on clean separation of layers of abstraction but favoring communication among different groups to mitigate negative impacts

Concluding Remarks

• Change in technology and market conditions will force a major design style shift towards IP re-use and programmable solutions

• Platforms will dominate many applications

• ASIC’s design starts will decrease further due to mask and NREs costs

• Embedded software will be a major emphasis in design

• Communication on chip and off chip will be the dominant part of design

• Analog will continue to be a major worry!