design methodologies for the nanotechnology era alberto sangiovanni vincentelli n.
Download
Skip this Video
Download Presentation
Design Methodologies for the Nanotechnology Era Alberto Sangiovanni-Vincentelli

Loading in 2 Seconds...

play fullscreen
1 / 69

Design Methodologies for the Nanotechnology Era Alberto Sangiovanni-Vincentelli - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

Design Methodologies for the Nanotechnology Era Alberto Sangiovanni-Vincentelli. Outline. Motivation Design Challenges Platform-based Design Communication-Based Design Implementation Platforms: Constructive Fabrics Analog Platforms. EDA. Platform Based Design. Fabrics. Interfaces.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Design Methodologies for the Nanotechnology Era Alberto Sangiovanni-Vincentelli' - gwidon


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
outline
Outline
  • Motivation
  • Design Challenges
  • Platform-based Design
  • Communication-Based Design
  • Implementation Platforms: Constructive Fabrics
  • Analog Platforms
disaggregation electronic systems design chain

EDA

Platform

Based

Design

Fabrics

Interfaces

Disaggregation:Electronic Systems Design Chain

System Design

Implementation

IP

Manufacturing

asic design trend
ASIC Design Trend

-27%

Design Starts

Source: IBS

electronic design a vision
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
outline1
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

Application

Programming Model:

Models/Estimators

Kernels/Benchmarks

Architecture(s)

Microarchitecture(s)

G

V

V

S

S

S

Cycle-speed, power, area

Functional Blocks,

Interconnect

Circuit Fabric(s)

Manfacturing Interface

Delay, variation,

SPICE models

Basic device & interconnect

structures

Silicon Implementation

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

Architectural Platform

V

S

G

S

V

S

Silicon Implementation Platform

S

V

S

G

V

S

asv platforms 2001

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

Upper layer of abstraction

Constraints

Performance Annotation

{

Platform

Platform stack

Mapping Tools

Lower layer of abstraction

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.

ASV Platforms (2001)

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

design methodology orthogonalize concerns

f1

f2

f3

System Behavior

System Platform

ECU-1

ECU-2

ECU-3

Mapping

Evaluation of

Architectural and Partitioning

Alternatives

Performance

Simulation

Bus

Refinement

Design Methodology: Orthogonalize Concerns

Software ComponentsVirtual Architectural Components

IPs

C-Code

Buses

CPUs

Buses

Buses

Matlab

ASCET

Operating

Systems

Analysis

Specification

Development Process

Implementation

Calibration

After Sales Service

consequences
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.
outline2
Outline
  • Motivation
  • Design Challenges
  • Platform-based Design
  • Communication-Based Design
  • Analog Platforms
picoradio sensor networks bwrc

Control Environmental parameters (temperature, humidity…)

  • Minimize Power consumption
  • Cheap (<0.5$) and small ( < 1 cm3)
  • Large numbers of nodes — between 0.05 and1 nodes/m2
  • Limited operation range of network — maximum 50-100 m
  • Low data rates per node — 1-10 bits/sec average
  • Low mobility (at least 90% of the nodes stationary)

actuator

sensor

controller

Picoradio Sensor Networks (BWRC)
  • 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
network design using platforms

Embedded System Platform

On-Chip Networks

Network Design Using Platforms

Application components Requirements

Components Adaptation

Communication Refinement (Protocol Stack + Gateways)

network platforms
Network Platforms

node

link

  • 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)

port

I/O port

er11, er12

es11, es12, es13

es21, es22

er21, er22, er23

event trace:

communication refinement

NP

P

P

NP’

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

NP

G

NP2

NP1

design of a platform layer ulysses
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

U1

P1

P2

U2

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

read

write

network design using platforms1

Embedded System Platform

On-Chip Networks

Network Design Using Platforms

Application components Requirements

Components Adaptation

Communication Refinement (Protocol Stack + Gateways)

adaptation of component behavior the essence of ip reuse gsrc
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
Interface Compatibility

Protocol 1

Protocol 2

Are the two protocols compatible?

Interface Theories [de Alfaro and Henzinger]

interface adaptability
Interface Adaptability

Protocol 1

Adapter

Protocol 2

Can the two protocols be made compatible?

Interface Synthesis [Passerone, Rowson, ASV]

interface synthesis
Interface Synthesis

Protocol 1

Adapter

Protocol 2

Specification

What does compatible really mean?

[Passerone, de Alfaro, Henzinger, ASV]

communication synthesis platform
Communication Synthesis Platform

P2P Specification

Communication

Implementation

slide24

Communication Synthesis Platform Stack

(bw1,d1)

(bw3,d3)

Communication

Specs

(bw4,d4)

(bw2,d2)

(bw5,d5)

(x3,y3)

(x4,y4)

Links

(x1,y1)

(x2,y2)

bw3+bw4

bw1+bw2

Comm. nodes

Relay Stations

Processes +

Shells

l=1

l=1

Wires

Buffers

CkSkew

constraints

Abstract Model

  • 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”
Constraints
library

b1

Cs(b)

cost

b2

Cs(b)

Length

Cr(b)

Relay

Station

Switches

clk

Library

This is the basic library of Communication Components

synthesis of communication architecture
Synthesis of Communication Architecture

Point-to-Point

Channel

Communication

Constraints

Synthesis

Communication

Architecture

Implementation

Library of

Pre-designed

Communication

Components

metropolis framework

Application-specific methodologies

Multi-media, wireless communication, mechanical controls, processors

Meta-model Library

  • Models of computation

Meta-model Library

  • Architecture platforms

Tools

Simulator

STARS

PIG

SPIN

QSS

Metropolis Framework

Infrastructure

  • Metropolis meta-model

- language

- modeling mechanisms

  • Meta-model compiler
metropolis meta model

Concurrent specification with a formal execution semantics:

Key difference with respect to

Ptolemy, UML, SystemC, …!!!

Metropolis meta-model

Concurrent specification with a formal execution semantics:

  • 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

meta model function netlist

MyFncNetlist

P1

Y

X

M

P2

Y

X

Env2

Env1

F

A

M

I

R

Meta-model : function netlist

process P{

port reader X;

port writer Y;

thread(){

while(true){

...

z = f(X.read());

Y.write(z);

}}}

interface reader extends Port{

update int read();

eval int n();

}

interface writer extends Port{

update void write(int i);

eval int space();

}

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(){ ... }

}

meta model execution semantics
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 components

interface BusArbiterService extends Port {

update void request(event e);

update void resolve();

}

interface BusMasterService extends Port {

update void busRead(String dest, int size);

update void busWrite(String dest, int size);

}

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)));

]]

}

F

A

scheduler BusArbiter extends Quantity

implements BusArbiterService {

update void request(event e){ … }

update void resolve() { //schedule }

}

M

I

R

Bus

BusArbiter

Meta-model: architecture components

An architecture component specifies services, i.e.

  • what it can do
  • how much it costs

: interfaces

: quantities, annotation, logic of constraints

meta model architecture netlist

MyArchNetlist

F

A

M

Bus

Arbiter

I

Bus

R

CPU + OS

Arbiter

Mem

Mem

Cpu

OsSched

Master

Slave

Meta-model: architecture netlist

Architecture netlist specifies configurations of architecture components.

Each constructor

- instantiates arch. components,

- connects them,

- takes as input mapping processes.

meta model platforms

medium AbsM implements MyService{

int myService(int d) { … }

}

refine(AbsM, MyMapNetlist2)

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

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

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

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

refine(AbsM, MyMapNetlist);

refine(AbsM, MyMapNetlist1)

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

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

MyMapNetlist2

MyMapNetlist1

F

F

A

A

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);

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);

M

M

I

I

P1

P2

P1

P2

MyFncNetlist

MyArchNetlist

MyFncNetlist

MyArchNetlist

M

M

R

R

MyMapNetlist1

M

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);

P1

P2

MyFncNetlist

MyArchNetlist

M

Meta-model: platforms

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

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

meta model recursive platforms

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);

N'

N

S

RTOSNetlist

B(P2, M.read) <=> B(P2, mP2.readCpu);

E(P2, P2.f) <=> E(mP2, mP2.mapf);

P1

P2

MyFncNetlist

MyArchNetlist

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);

M

M

P1

P2

MyFncNetlist

MyArchNetlist

M

Meta-model: recursive platforms

RTOS

outline3
Outline
  • Motivation
  • Design Challenges
  • Platform-based Design
  • Communication-Based Design
  • Analog Platforms
motivation
Motivation

Exploration?

Optimality?

focus
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
Analog Design Flow
  • System Specs

SystemLevelExploration

  • Behavioral models
    • Matlab, Excel, …
    • Define Block requirements
  • Circuit design
    • Size, Simulate and iterate

Circuit Sizing &Synthesis

  • Layout design
    • Verify and iterate
analog design flow1
Analog Design Flow
  • System Specs

SystemLevelExploration

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

Analog Platform

  • Circuit design
    • Size, Simulate and iterate

Circuit Sizing &Synthesis

  • Layout design
    • Verify and iterate
analog platforms
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 platforms1
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

Sw.Cap

Cont.T.

Mapping Tools

OpAmp

Performance Estimation

Diff.

S.Ended

OpAmp Lib1

OA Lib2

Analog Platform Stacks
  • APs allow efficient top-down flows for analog systems
  • 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

Filter

  • Platform stacks allow the selection of optimal architectures and topologies for analog components
analog platforms2
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
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

vin

vout

gain

Ideal Model

Behavioral Model

behavioral models hierarchy
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
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
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
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
Constraint Relations (II)

L

  • 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

G

NF

generating f
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
  • Example:
    • Original, 77
    • Shown, projection in 3
proposed methodology
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 flow2

Ext. IP’s

Int. APs

PLL

Performance Models

Behavioral Models

Mapping

Performance Eval/System Optimization

BehaviorRefinement

Architecture Refinement

Analog Design Flow

New APs

constraints interpolation
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
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
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
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
Projection on SVMs
  • Need an efficient way to compute 
    • maximizewith 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
composition
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
composition1
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

Block AA(x)

Block BB(y)

merge
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

LF

VCO

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

PLL

top down with aps
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

Comm. Adapter

FSO: 200 mV

R: 1000-2300 

R/T: 1800ppm

Input range: 0.5-1.5V

Bandwidth: 500 Hz

10 bit

1 kSamples/s

Bridge Linearization

Amplification

DC Offset

Temperature

Compensation

Nyquist Filter

Sensor Interface Example

Signal Conditioning

MEMS Pressure Sensor

ADC Converter

  • Off-the-Shelf Components
  • Field Programmable Analog Arrays
  • Custom Solutions

Synthesize and Map on Proper Platform

performance representation
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
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
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!