Ip based design
Download
1 / 107

IP-based Design - PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on

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.

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 'IP-based Design' - pisces


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



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



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



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.





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 architecture co design cadence approach50 l.jpg
Function-Architecture Co-design: Cadence Approach



Function architecture co design cadence approach52 l.jpg
Function-Architecture Co-design: Cadence Approach



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



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.



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



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




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


ad