Design methodologies for the nanotechnology era alberto sangiovanni vincentelli
Download
1 / 69

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


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


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
Design methodologies for the nanotechnology era alberto sangiovanni vincentelli

Design Methodologies for the Nanotechnology EraAlberto Sangiovanni-Vincentelli


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


    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

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


    ad