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

IP-based Design PowerPoint PPT Presentation

  • 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

12 October 2001

Sungjoo Yoo

ISRC, Seoul Nat’l Univ.


  • 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

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

IP-based Design

  • Basic strategy

    • SoC design by assembling IP cores.

IP-based Design

  • Virtual Component (VC) = IP

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 Design

  • VC integration with on-chip bus (OCB)

IP-based Design

  • Bus wrapper

IP-based Design

  • Example of VCI transactions

IP-based Design

  • VCI Options

IP-based Design w/ behavioral IP

  • System Level Interface (SLIF)

IP-based Design

  • VC example

IP-based Design

  • VC internal behavior

IP-based Design

  • Layering of VC refinement

IP-based Design

IP-based Design

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

  • Separation between behavior and communication

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







Incremental Communication Refinement

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

  • 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

  • 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

  • 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

Derivative Design Example 1 MSM3000 -> 3100

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

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

  • Architectural viewpoint

    • Fixed platform at layout or RTL

    • Parameterized platform

    • A family of parameterized platforms

      • Function/architecture codesign

Fixed Platform

[p. 113, Surviving the SoC Revolution]

Fixed Platform at Layout

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

Parameterized Platform

  • UCI, digital camera platform

D$, I$ parameters

size, line, assoc

Bus parameters

width, BI coding

DCT parameters


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


Arch.-indep opt.

Arch. dev.



Local optimization

Com. network design



HW/SW implementation


Three Commercial Approaches

  • Cadence VCC

  • Coware N2C

  • Synopsys CoCentric

Function-Architecture Co-design: Cadence Approach



Function to Architecture Mapping

Mapping to HW and SW

Mapping Function to SW

Mapping Function to HW

Function-Architecture Co-design: Cadence Approach

Architecture Exploration w/ Different Architectures

Function-Architecture Co-design: Cadence Approach

Incremental Refinement of Function/Architecture

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

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

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

  • 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

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

Refine HW/SW mArchitecture

Function-Architecture Co-design: Cadence Approach

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




Std. C lib. API


Std. C lib. Service

CPU mem. API

Value(), Enabled()

CPU Memory Service


Master Adapter API


Bus Slave API

FCFS Bus Adapter

Bus Slave Adatper

Reuse of Architectural Services


If the designer uses a different bus,

the remaining architectural services

are reused.



Std. C lib. API


Std. C lib. Service

CPU mem. API

Value(), Enabled()

CPU Memory Service


Master Adapter API


Bus Slave API

FCFS Bus Adapter

Bus Slave Adatper

Communication Patterns

Refine HW/SW mArchitecture

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

  • 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

CoCentric: Dataflow Model (static I/O pattern)

CoCentric: Dataflow Model (dynamic I/O pattern)

CoCentric: Control Flow Model

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 Study

CoCentric: Case Study

  • Training Sequence Model

CoCentric: Case Study

  • OR model of Mux-TrainingSequence


  • 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


  • Import of HDL models

    • Cosimulation with external HDL simulators

  • Import of SystemC models

    • Cosimulation with SystemC simulator

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

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
















Exe. time

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 Characterization

  • UCI, digital camera platform

Parameter Dependency

Parameter Clustering


search in a cluster

Cluster Merging

Design space =


Pareto-Optimal Points of (0.25, 0.08mm)

Average pruning ratio = 99.999997%

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

  • Quality, verification, characterization vs. parameterization





1 single


No. of parameters,


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 Design

  • Testbench reuse

    • Most errors come from the integration step.


SoC Validation in IP/Platform-based Design

  • Mixed-abstraction-level simulation

    • Incremental integration of new functionality















HW wr.


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

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

  • Test access mechanism (TAM) and test wrapper

Core Test Requirements

  • Wrapper and TAM

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

  • 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

  • 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

  • Fujitsu/LogicVision, ‘98

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 Design

  • MPEG-2

    Chip Core

Case Study of Core-based Test Design: Testability Results


  • 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