Ip based design l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 107

IP-based Design PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on
  • Presentation posted in: General

IP-based Design. 12 October 2001 Sungjoo Yoo ISRC, Seoul Nat’l Univ. Outline. Design productivity gap and design reuse IP-based design Interface-based design Platform-based design Function-architecture co-design Practical issues in IP/Platform-based design Summary.

Download Presentation

IP-based Design

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


Ip based design l.jpg

IP-based Design

12 October 2001

Sungjoo Yoo

ISRC, Seoul Nat’l Univ.


Outline l.jpg

Outline

  • Design productivity gap and design reuse

  • IP-based design

    • Interface-based design

  • Platform-based design

    • Function-architecture co-design

  • Practical issues in IP/Platform-based design

  • Summary


Design productivity gap l.jpg

Design Productivity Gap


How to increase design productivity l.jpg

How to Increase Design Productivity?

  • Reuse

    • What to reuse?  How to reuse?

    • IPs (Intellectual Properties)  IP-based design

    • Previous system design (or architecture), platform  platform-based design


How to increase design productivity5 l.jpg

How to Increase Design Productivity?

(2) Design at higher levels of abstraction

  • E.g. 200 lines/man-day

    • code size: C > assembly

  • Abstraction levels higher than C code level.

    • SPW, COSSAP, etc.

    • SDL, CORBA, etc.

      (3) Combine reuse and high-level design

  • Currently, function-architecture co-design


Design methodology evolution l.jpg

Design Methodology Evolution


Ip based design7 l.jpg

IP-based Design

  • Basic strategy

    • SoC design by assembling IP cores.


Ip based design8 l.jpg

IP-based Design

  • Virtual Component (VC) = IP


Ip based design9 l.jpg

IP-based Design

  • VC Interface

    • VC Interface at RT level (VCI).

      • To reuse RTL IP’s

    • System-level interface (SLIF)

      • To reuse behavioral IP’s


Ip based design10 l.jpg

IP-based Design

  • VC integration with on-chip bus (OCB)


Ip based design11 l.jpg

IP-based Design

  • Bus wrapper


Ip based design12 l.jpg

IP-based Design

  • Example of VCI transactions


Ip based design13 l.jpg

IP-based Design

  • VCI Options


Ip based design w behavioral ip l.jpg

IP-based Design w/ behavioral IP

  • System Level Interface (SLIF)


Ip based design15 l.jpg

IP-based Design

  • VC example


Ip based design16 l.jpg

IP-based Design

  • VC internal behavior


Ip based design17 l.jpg

IP-based Design

  • Layering of VC refinement


Ip based design18 l.jpg

IP-based Design


Ip based design19 l.jpg

IP-based Design


Ip based design20 l.jpg

IP-based Design

  • Integration of VC’s with OCB.

    • IP w/ VCI

    • VC w/ VCI + bus wrapper  OCB

  • Incremental refinement of VC interface

    • Behavioral IP

    • SLIF  OCB protocol w/ the behavior unchanged.

  • IP-based design

    • Formally, interface-based design


Interface based design l.jpg

Interface-based Design

  • Separation between behavior and communication


Interface based design22 l.jpg

Interface-based Design

  • Separation between behavior and communication

    • It enables IP reuse.

    • Each one can be refined separately.

      • Behavior refinement

      • Communication refinement

  • Design Automation Conf.’97 paper

    • James A. Rowson (Cadence) and Alberto Sangiovanni-Vincentelli (Berkeley).


Communication in interface based design l.jpg

Communication in Interface-based Design

sender

receiver

substitution

master

slave

repartition


Incremental communication refinement l.jpg

Incremental Communication Refinement


Checkpoint ip based design l.jpg

Checkpoint:IP-based Design

  • Separation between behavior and communication

  • It works in incremental communication refinement.

  • It includes SW IP’s as well as HW ones.

    • To be explained later in function-architecture co-design.

  • Bottom-up approach

    • SoC design by assembling IP cores.


Evolution to platform based design l.jpg

Evolution to Platform-based Design

  • A Problem of Bottom-Up IP Integration

    • How can the designer find the optimal system architecture?

  • Can we re-use our design experience at a higher level than IP level?

    • Reuse of previous designs in a similar application domain.

    • Platform-based design.


Platform based design l.jpg

Platform-based Design

  • Platform

    • Common hardware/software denominator that could be shared across multiple applications in a given application domain.

    • E.g. Derivative design of Qualcomm CDMA mobile station modems (MSM’s)

      • MSM3000  MSM3100

      • MSM3100  MSM5100


Derivative design of qualcomm cdma chips l.jpg

Derivative Design of Qualcomm CDMA Chips

  • MSM3000, 3100, 5100, …

    • Added functionality and interfaces

    • Base functionality and interfaces

      • Platform of MSM3000 series

    • Note

      • Platform consists of software parts as well as hardware ones.


Msm3000 l.jpg

MSM3000


Msm3100 l.jpg

MSM3100


Derivative design example l.jpg

Derivative Design Example


Derivative design example 1 msm3000 3100 l.jpg

Derivative Design Example 1 MSM3000 -> 3100


Derivative msm design l.jpg

Derivative MSM Design

  • Functional viewpoint

    • MSM3000  3100

      • + PLL, USB, PM (ADC, Vtg reg.)

      • D RF i/f, Vocoder (QCELP  EVRC), Codec (chip in)


Derivative design example 2 msm3100 5100 l.jpg

Derivative Design Example 2 MSM3100 -> 5100


Summary of case study derivative msm design l.jpg

Summary of Case Study: Derivative MSM Design

  • Functional viewpoint

    • MSM3000  3100

      • + PLL, USB, PM (ADC, Vtg reg.)

      • D RF i/f, Vocoder (QCELP  EVRC), Codec (chip in)

    • MSM3100  5100

      • + gpsOne processor, Bluetooth baseband processor, MMC, R-UIM controllers, MP3, MIDI

      • D Vocoder DSP (QDSP2000)

  • Platform-based design in functional viewpoint

    • Common functionality + added/modified functionality

  • Architectural viewpoint?


Levels of platform based design l.jpg

Levels of Platform-based Design

  • Architectural viewpoint

    • Fixed platform at layout or RTL

    • Parameterized platform

    • A family of parameterized platforms

      • Function/architecture codesign


Fixed platform l.jpg

Fixed Platform

[p. 113, Surviving the SoC Revolution]


Fixed platform at layout l.jpg

Fixed Platform at Layout

  • HW Kernel [p. 148, 156 Surviving the SoC …]


Parameterized platform l.jpg

Parameterized Platform

  • UCI, digital camera platform

D$, I$ parameters

size, line, assoc

Bus parameters

width, BI coding

DCT parameters

precisions


Function architecture co design l.jpg

Function-Architecture Co-design

  • SoC platforms

    • A family of parameterized platforms

  • High abstraction level design

    • SW-centric SoC design

    • Top-down flow in platform-based design

  • A key design step

    • Mapping functions to SoC platform

    • W/ different HW/SW, communication mapping

  • Thus, it is named Function-Architecture Co-design


Function architecture co design flow l.jpg

Function-Architecture Co-design Flow

Algorithm

Arch.-indep opt.

Arch. dev.

Function

Architecture

Local optimization

Com. network design

Mapping

Evaluation

HW/SW implementation

Cosimulation/emulation


Three commercial approaches l.jpg

Three Commercial Approaches

  • Cadence VCC

  • Coware N2C

  • Synopsys CoCentric


Function architecture co design cadence approach l.jpg

Function-Architecture Co-design: Cadence Approach


Function l.jpg

Function


Architecture l.jpg

Architecture


Function to architecture mapping l.jpg

Function to Architecture Mapping


Mapping to hw and sw l.jpg

Mapping to HW and SW


Mapping function to sw l.jpg

Mapping Function to SW


Mapping function to hw l.jpg

Mapping Function to HW


Function architecture co design cadence approach50 l.jpg

Function-Architecture Co-design: Cadence Approach


Architecture exploration w different architectures l.jpg

Architecture Exploration w/ Different Architectures


Function architecture co design cadence approach52 l.jpg

Function-Architecture Co-design: Cadence Approach


Incremental refinement of function architecture l.jpg

Incremental Refinement of Function/Architecture


Three ways to performance estimation l.jpg

Three Ways to Performance Estimation

  • Limit the estimation to the runtime

    • Applicable to other design metrics, e.g. power

  • Depending on where the function is mapped

    • Processor and micro-controller

      • Addition of assembly instruction delays

      • Usage of virtual instruction set

    • DSP

      • Estimation of kernel function delays

    • ASIC

      • With measurement or simulation models


Using virtual instruction set in sw performance estimation l.jpg

Using Virtual Instruction Set in SW Performance Estimation


Usage of virtual instruction set vis l.jpg

Usage of Virtual Instruction Set (VIS)

  • Constructing the delay table

    • From the datasheet

    • Run benchmark programs on actual processor and measure

    • Run benchmark programs on cycle-accurate instruction set simulators

      • Solve a set of linear equations

  • Compile the function code (e.g. in C) to the VIS.

  • Delay calculation by adding the delays of virtual instructions.


White box model l.jpg

White Box Model


Characterization of sw execution time for dsps l.jpg

Characterization of SW Execution Time for DSPs

  • Two reasons of not using the VIS

    • Many legacy/high-performance codes are assembly code.

    • Performance is highly dependent on memory locations of instructions and data.

      • VIS ignores accesses to different memory locations.

  • DSP SW codes are usually dataflow functions with small amounts of control.

    • Dataflow functions dominate the total cycle count.

  • Measure or estimate a set of standard DSP kernels or atomic functions on a processor.

  • Derive a parameterized delay equation for each kernel function on each processor.

  • Model an application as a scheduled sequence of kernel functions.


Abstraction levels of dsp kernel functions l.jpg

Abstraction Levels of DSP Kernel Functions

  • Basic arithmetic

    • Integer barrel shift, integer add

    • Integer & long multiply

  • Generic signal processing and complex mathematical functions

    • Auto-correlation, FIR filter

    • Convolution, discrete time FFT

  • Application specific: e.g. for CDMA:

    • Viterbi decoder

    • Convolutional Encoder

    • Block Interleaver

    • 64-ary Orthogonal Modulator


Non programmable hw components and custom hw l.jpg

Non-programmable HW Components and Custom HW

  • Examples

    • MPEG decoder, CDMA modem, IP peripheral IO block, etc.

  • Modeling method

    • Generate delay equations for the VC block

      • Output pin delay equations

      • Considering the internal resource contention

    • To derive the delay equations, measure real HW or use the simulation model

  • Then, derive high level delay equations

    • In terms of frame, packet, token processing


Function architecture co design cadence approach61 l.jpg

Function-Architecture Co-design: Cadence Approach


Refine hw sw m architecture l.jpg

Refine HW/SW mArchitecture


Function architecture co design cadence approach63 l.jpg

Function-Architecture Co-design: Cadence Approach


Architectural service concept l.jpg

Architectural Service Concept

  • Each architectural component provides a set of services.

    • E.g. processor gives

      • Instruction fetching, interrupt handling, bus adapters

    • E.g. OS gives

      • Scheduling, standard C library, software timers, etc.

    • E.g. Bus gives

      • Arbitration, single read/write, burst read/write.


Communication based on architectural services l.jpg

Communication based on Architectural Services

SW

Post()

RegisterMappedSWSender

Std. C lib. API

HW

Std. C lib. Service

CPU mem. API

Value(), Enabled()

CPU Memory Service

RegisterMappedReceiver

Master Adapter API

ASIC mem. API

Bus Slave API

FCFS Bus Adapter

Bus Slave Adatper


Reuse of architectural services l.jpg

Reuse of Architectural Services

SW

If the designer uses a different bus,

the remaining architectural services

are reused.

Post()

RegisterMappedSWSender

Std. C lib. API

HW

Std. C lib. Service

CPU mem. API

Value(), Enabled()

CPU Memory Service

RegisterMappedReceiver

Master Adapter API

ASIC mem. API

Bus Slave API

FCFS Bus Adapter

Bus Slave Adatper


Communication patterns l.jpg

Communication Patterns


Refine hw sw m architecture68 l.jpg

Refine HW/SW mArchitecture


Coware n2c l.jpg

Coware N2C

  • Also supports function-architecture co-design

  • Gradual refinement of communication/behavior

    • Untimed functional  timed func  RTL C  HDL

    • RPC  BCASH  real i/f

  • HW/SW Interface Synthesis

    • Comparable to communication patterns in VCC

  • InterState Synthesis

    • HW synthesis from C description

    • Abstract port  physical port implementation

      • E.g. scheduling port accesses

  • On-chip bus modeling


Synopsys approach cocentric l.jpg

Synopsys Approach: CoCentric

  • Compared to N2C and VCC, CoCentric first focuses on control/dataflow mixed functional specification

    • Control flow  FSM

    • Data flow  data flow models used in COSSAP

  • As a design entry, SystemC can be used.

  • Control/dataflow spec. is compiled to synthesizable/compilable HW and SW codes.

    • Especially, HW synthesis from SystemC by SystemC Compiler

  • Existing Synopsys tool chains are used.

    • COSSAP stream driven simulation (SDS)


Cocentric control dataflow specification l.jpg

CoCentric: Control/Dataflow Specification


Cocentric dataflow model static i o pattern l.jpg

CoCentric: Dataflow Model (static I/O pattern)


Cocentric dataflow model dynamic i o pattern l.jpg

CoCentric: Dataflow Model (dynamic I/O pattern)


Cocentric control flow model l.jpg

CoCentric: Control Flow Model


Cocentric case study l.jpg

CoCentric: Case Study

  • OR model embedded in a hierarchical DFG

    • Bit-serial signals of mixed text and image are multiplexed into a TDMA signal, modulated and transmitted.

    • Receiver

      • Equalization based on LMS and demodulation


Cocentric case study76 l.jpg

CoCentric: Case Study


Cocentric case study77 l.jpg

CoCentric: Case Study

  • Training Sequence Model


Cocentric case study78 l.jpg

CoCentric: Case Study

  • OR model of Mux-TrainingSequence


Cocentric l.jpg

CoCentric

  • Code scheduling and generation

    • Control model

      • FSM  sequential code

      • Like Esterel  C code

    • Dataflow model

      • Use COSSAP

        • Fixed I/O pattern  sequential code

        • Dynamic I/O pattern  scheduler


Cocentric80 l.jpg

CoCentric

  • Import of HDL models

    • Cosimulation with external HDL simulators

  • Import of SystemC models

    • Cosimulation with SystemC simulator


Ip platform based design l.jpg

IP/Platform-based Design

  • IP/Platform Characterization

  • IP/Platform Authoring

  • SoC design validation in IP/Platform-based design

    • Testbench reuse

    • Mixed-abstraction-level simulation

  • SoC Testing

    • IEEE P1500


Ip and platform characterization l.jpg

IP and Platform Characterization

  • Problem: exhaustive characterization

    • Due to the large number of parameters, full characterization does not seem to be possible.

      • E.g. IP or platform w/ 100 binary parameters --> 2100 configurations

      • For each configuration

        • HW area, runtime, power estimation

        • By simulation/estimation

      • In an exhaustive way, it is impossible to characterize the IP/platform!

    • How to do practical characterization?


Ip and platform characterization83 l.jpg

IP and Platform Characterization

  • What the designer wants is pareto-optimal points in design space.

  • Solution

    • Search space pruning by decomposing the parameter space into orthogonal sub-spaces.

Power

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Exe. time


Ip and platform characterization84 l.jpg

IP and Platform Characterization

  • Search space pruning

    • Dependency between parameters

      • E.g. I$ line size and I$ associativity are dependent with each other.

      • E.g. I$ line size and D$ associativity are independent.

    • Key idea

      • If parameter sub-spacess P1 and P2 are independent

      • Parato-optimal points (P1xP2)

        = POP(P1) x POP(P2)


Ip and platform characterization85 l.jpg

IP and Platform Characterization

  • UCI, digital camera platform


Parameter dependency l.jpg

Parameter Dependency


Parameter clustering l.jpg

Parameter Clustering

Exhaustive

search in a cluster


Cluster merging l.jpg

Cluster Merging

Design space =

DS(AHI)xD(LMPQ)


Pareto optimal points of 0 25 0 08 m m l.jpg

Pareto-Optimal Points of (0.25, 0.08mm)

Average pruning ratio = 99.999997%


Ip and platform authoring l.jpg

IP and Platform Authoring

  • Problem: unexpected IP/Platform usage

    • Negative test is required.

    • Usage-scenario-based testing

      • for expected IP usage

  • Solution: precisely define illegal inputs

    • for each IP configuration

    • activate corner cases

      • e.g. by random test vector generators

    • check illegal inputs by assertion check


Ip platform trade off l.jpg

IP/Platform Trade-off

  • Quality, verification, characterization vs. parameterization

Quality,

Verifiability,

Testability,

Characterizability

1 single

instance

No. of parameters,

Generality


Soc validation in ip platform based design l.jpg

SoC Validation in IP/Platform-based Design

  • SoC validation takes up to 2/3 of design cycle.

    • Why?

      • E.g. if the integration of 1 core has 0.1% prob. of bug, then that of 200 core SoC has 20% prob. of bug!

    • How to reduce the validation efforts?

      • Testbench reuse

      • Mixed-abstraction-level simulation


Soc validation in ip platform based design93 l.jpg

SoC Validation in IP/Platform-based Design

  • Testbench reuse

    • Most errors come from the integration step.


Soc validation in ip platform based design94 l.jpg

M4

SoC Validation in IP/Platform-based Design

  • Mixed-abstraction-level simulation

    • Incremental integration of new functionality

M1

High-level

Specification

M2

M3

M4

mP

IP

M1

M1

M3

OS

Intermediate

Implementation

HW wr.

AMBA


Soc validation in ip platform based design95 l.jpg

SoC Validation in IP/Platform-based Design

  • Mixed-abstraction-level simulation

    • A conventional method: bus functional model (BFM)

      • Functional memory access

        • E.g. write to variable x located 0x100

      • Cycle-accurate (C/A) memory access

        • addr_bus = 0x100; nrw=0;

        • 1 cycle delay;

        • return data_bus;

    • SystemC and Coware

      • BCASH: bus cycle accurate shell

        • RPC (remote procedural call) access to C/A accesses

    • TIMA

      • Wrapper concept


Soc testing l.jpg

SoC Testing

  • Why SoC testing?

    • To detect manufacturing defects.

    • Deep sub-micron technology  various types of fault

  • Why core-based testing?

    • Reuse of core test

    • SoC test is constructed based on core test.

  • Core-based SoC testing

    • Core provider

      • DFT (design for testability) hardware and test patterns

    • SoC Integrator

      • SoC-level DFT, .e.g TAM (test access mechanism)

      • SoC test patterns using core test patterns


Soc testing97 l.jpg

SoC Testing

  • SoC Test Challenges

    • Cores have different test methods.

      • E.g. BIST, scan, mixed, memory test, etc.

    • Test access to cores

      • Cores can be deeply embedded.

      • Test access should be routed to the cores.

    • Test optimization

      • Many cores  very long test time  TTM loss

      • Area overhead of SoC test

      • Power overhead of SoC test

        • E.g. BIST consumes more power than usual operations.


Core test requirements l.jpg

Core Test Requirements

  • Test access mechanism (TAM) and test wrapper


Core test requirements99 l.jpg

Core Test Requirements

  • Wrapper and TAM


Core based test standard l.jpg

Core-based Test Standard

  • IEEE P1500 SECT (Standard for Embedded Core Test)

    • Core Test Language (CTL)

      • Core test knowledge transfer

      • Test patterns are written to be reused.

    • Core Test Wrapper Architecture

      • Test access to embedded cores


Ieee p1500 l.jpg

IEEE P1500

  • Core test wrapper

  • Elements

  • Wrapper Inst. Reg

  • Wrapper Bypass Reg.

  • Wrapper Boundary Reg.

  • Modes

  • Transparent mode

  • Serial InTest mode

  • Serial ExTest mode

  • Parallel InTest mode

  • Parallel ExTest mode


Automation of soc test design l.jpg

Automation of SoC Test Design

  • Test wrapper generation and insertion

  • Compliancy checking

  • Interconnect test generation

  • Test access planning and synthesis

    • E.g. # of TAM’s, mapping cores to TAM’s, TAM width

  • Test expansion

    • Core test patterns  SoC test patterns

  • Test scheduling

    • Schedule core tests to minimize test resources (time, area, power, etc.).

      • Power

      • Test application time and storage capacity


Case study of core based test design l.jpg

Case Study of Core-based Test Design

  • Fujitsu/LogicVision, ‘98


Case study of core based test design104 l.jpg

Case Study of Core-based Test Design

  • Core 1 (VD) DfT

Memory BIST insertion

Scan chain insertion

Logic BIST insertion


Case study of core based test design105 l.jpg

Case Study of Core-based Test Design

  • MPEG-2

    Chip Core


Case study of core based test design testability results l.jpg

Case Study of Core-based Test Design: Testability Results


Summary l.jpg

Summary

  • Design productivity gain

    • By reuse

      • IP reuse  IP-based design

      • Platform reuse  platform-based design

      • Test bench reuse

      • Test reuse

    • By high-level SoC design

      • Concurrent programming of SoC

    • Reuse and high-level SoC design

      • Function-architecture co-design

    • Practical issues


  • Login