1 copyright vsi alliance: overview of the vsi alliance - larry rosenberg - china october 2003 vsia...

Copyright VSI Alliance: Overview Of The VSI Alliance - Larry Rosenberg - China October 20031

VSIA Presentations in China - October 2003

Virtual Socket Interface Alliance

An Overview Of The

VSI Alliance

Larry Rosenberg

Vice President, Engineering

VSI Alliance


Talk Roadmap

• VSIA Motivation– The Design Productivity Challenge to be Addressed

• History of VSIA– Address the Productivity Challenge (and more)

• VSIA Document Organization and List of Documents• Structure of VSIA Organization• Strategic Achievements, Major Accomplishments & Roadmap• VSIA’s DWGs

– Which Exist?– What have they Accomplished?– What are their Plans?

• The New VSIA• Regional “Special Interest Groups”

– Chinese SIG?

• Summary and Conclusion


VSI Alliance Background

Motivation for Creation:The Design Productivity

Challenge

to be Addressed


Motivation for VSIA (1996 Slide)

• Million Gate Silicon now– 10 million gates by 2000

• The design gap is growing– 10 X productivity gain– 1000 X silicon gain

• Solution is Design Reuse– Requires standard

interfaces– Requires new methods– Requires Verifiable VCs

• VSIA founded to help

PkgChipCostpergate

Gates/Chip

.35u.25u

.18u

10**5 10**6 10**7

Gates/Hour

1990 1995 2000

PossibleGates/Chip

Design Gap


Deep Submicron Paradigm Shift

40M Transistors2,000M Metal600 MHzWire RC 6 ns/cm

2M Transistors100M Metal100 MHzWire RC 1 ns/cm

20011991 1996

Cell Based Design - Minimize Area - Maximize Performance - Optimize Gate Level

Virtual Component Base Design - Minimize Design Time - Maximize IP Reuse - Optimize System Level

90%New

Design 90%ReusedDesign

We Came Together to Solve This Problem


VSIA’s Motivation

ASIC /ICDesign

System-ChipIntegration

IP/BlockAuthoring

Yesterday

Today

System-BoardIntegration

Predictable,

Pre-verified‘Virtual

Components’

Virtual Components

Physical Components

Mix and Match of IP (design reuse) is an essential part of the solution!


Scope of VSI Alliance Verifica-tion Flow

VSI VC Integrator

Bus Functional Verification

RTL Functional Verification

Gate Functional Verification

Performance Verification

Final Verification

System Design

RTL Design

Floorplanning Synthesis Placement

Routing

VerificationFlow

Creation Flow

VC Provider

Data Sheet ISA Model

Bus Functional Models

RTL SW Drivers

Functional Test Test Bench

Synthesis Script Timing Models Floorplan Shell

Gate Netlist

Timing Shell Clock Power Shell

Test Vectors Fault Coverage Polygon Data

System Modeling / Analysis

System Requirement Generation

System Integration

System Characterizat.

Behavioral Models Emulation Model Eval. Test Bench

Interconnect Models P&R Shell

• Technical requirements for the use of 3rd party IP in large IC design

• VSI standardized Data interfaces and formats between VC Provider and VC Integrator.

• Vision is to improve Design productivity through IP reuse

Performance Verification

Final Verification

Bus Functional Verification

System Design

RTL Design

RTL Functional Verification

Floorplanning Synthesis Placement

Routing

Gate Functional Verification

Soft VC

Hard VC


Incr

easi

ng D

esig

n R

e-U

se

Time (Evolution of VSI Standards)

DevelopmentWorking Groups (DWGs)resolve Design re-use challenges

IP ProtectionMixed SignalManufacturing Related TestSystem Level DesignOn -Chip Buses

Implementation / Verification

Libraries

RF

?

Solitary DesignAd Hoc methods& processes

Intra / Inter-Company VC re-useIncreasing

Re-use

IncreasingRe-use

Embedded SWC

urre

nt D

WG

s

Future DWGsImproving re-useEvolving methods & processes

VSI Roadmap

Future EnhancementsVSI 1.0 Architecture Document


Organization Structure

• Development Working Groups (DWG) draft proposed standards for review by Members

• Members review and comment on proposals

• Board of Directors (BoD) launches DWGs and grants final approval before public release

• Technical & Marketing Committees interface with DWGs, Administration and the BoD

VSIA Members

Board of Directors

DevWorkGroup

#1

DevWorkGroup

#2

DevWorkGroup

#N

TC MC


VSI Alliance

Document

Organization


Document Organization

VSI Alliance OVERVIEW

Document

VSI Alliance DELIVERABLES

Document

VSILegalDocsReferenced Docs.

ArchitectureDocument

1.0

Standards DWGSpec.

Use DeliverablesSummary as basisfor Compliance

OtherDocs


Deliverables Document

• For Compliance– Comments are added below the Deliverables Tables– Yes / No or Not Applicable only in the Comply? Column– Refer to the Specification’s deliverable details as necessary

Table 2: Implementation/Verification (I/V 1 2.1) Specification Data Deliverables

Section Deliverable

VSIA Endorsed Formats

VSIA Specified Format(s) Soft Firm Hard Comply? Comments

2.3.6 Signature VC LEF - - M Yes see A : : : : : : : : :2.4.8 .. Constraints DC-WG M M M Yes See B

Table 3: On-Chip Bus (OCB 1 1.1) Data Deliverables

Section Deliverable

Currently Used Formats

Candidate VSIA Format OCBD VCD SOCI Comply? Comments

2.1. User Guide 2.1.1 Version Number Document Document M M M Yes See C : : : : : : : : :

2.3.6 Debug Tools R R - NoNo formats exist for these tools

A: Use LEF equivalent to VC LEFB: Available upon request (not as part of the deliverables)C: Available in Bus Documentation Package product # 12345 provided by XYZ Company


Available VSIA Documents

• Analog/Mixed-Signal Extension Version 2 (AMS 1 2.x)• Analog/Mixed-Signal Signal Integrity Extension Version 1(AMS 2

1.x)• On-Chip Bus Attributes Version 1 (OCB 1 2.x)• Soft & Hard VC Modeling Version 2 (I/V 1 2.x)• Test Data Interchange Version 1 (TST 1 1.x)• Virtual Component Transfer Version 2 (VCT 1 2.x)• VSIA Architecture Document• System-Level Design Model Taxonomy (SLD 2 2.x)• Taxonomy of Functional Verification (VER 1 1.x)• IP Protection White Papers (IPP 1 1.x), (IPP 2 1.x), (IPP 2 1.x)• System-Level Interface Documentation Standard Version 1 (SLD 1

1.x)• Test Access Architecture Standard Version 1(TST 2 1.x)• Virtual Component Attributes (VCA) Version 2 (VCT 2 2.x)• VC Identification Physical Tagging Standard (VCID) Version 1 (IPP 1

1.x)• Virtual Component Interface Standard (VCI) Version 2 (OCB 2 2.x)

SpecificationsDocumentsStandards

Naming: [DWG] [doc#] [version].[Revision]


Strategic Achievements,

Highlight of Major

Accomplishments and

Roadmap

Quick Overview of VSIA


Strategic Achievements• Pioneering Vision for SoC

– Design Reuse of (H/W) Virtual Components• Generated High industry awareness • 0 to >150 members• Ten+ DWGs staffed by volunteers• 21 documents (specs, standards,

Taxonomies)• High content - requirements & guidelines • Ensured non-discriminatory, reasonable-cost

format licenses for THE de facto standards– Free Licenses

• Competitors agreed on required data formats!


Highlight of Major Accomplishments

• We have Completed ALL originally committed “1G” specs – Except for I/V’s Firm VC Spec; and Functional Verification

• In addition, we’ve expanded to 2G: – Systems Level, Communications and Interfaces, including:

• VSIA Model Taxonomy addresses Major SoC Terminology Problems• Verification Taxonomy defines key concepts and terminology in Verification• VCI has resolved the “Can’t Pick One” Bus Dilemma• SLIF Seminal Contribution in SLD Space

• Separation of Behavior & Interface

• VCID “tags” hard VC blocks with IP Protection Information => Tracking• VCT has created ONE VC Catalog Attributes Standard

• Used by VCX, SI2’s QuickData, IPH, D&R

• SLD’s Data Types: Strong Collaboration between SystemC & VSIA• Released VC Test Access Architecture Standard• IP Protection White Papers: Intellectual Assets & Network Security

And now 3G: eSoC Initiative SoCs contain not just H/W Components, but also S/W


The VSIA Roadmap


VSIA’s DWGs:

Their

Accomplishments

and Plans


VSIA DWGs: Active and Transitioning• VC Quality DWG Co-Chairman: Scott Batzer, Intel Co-Chairman: Kathy

Werner, Mentor Graphics Consulting

• Hardware-dependent Software DWG Co-Chairman: Frank Pospiech, Alcatel Stephen Olsen, Mentor Graphics

• Platform Based Design DWG Chairman: Bob Altizer, Basys Consulting

• Virtual Component Transfer DWG Co-Chairman: Carolyn Hayden, Individual Member Co-Chairman: David Gardner, Mentor Graphics

• Functional Verification DWG Chairman: Tom Anderson, 0-In Automation Inc.

• IP Protection DWG Chairman: Ian Mackintosh, Sonics

Transitioning DWGs

• Implementation DWG Chairman: Raminderpal Singh, IBM– Merger of Implementation/Verification & Analog-Mixed Signal/Signal Integrity DWGs

• On-Chip Bus DWG -> OCP-IP

• Mfg. Related Test DWG Inactive Chair: R. Chandramouli, Synopsys

• System Level Design DWG - Dissolved, Brian Bailey, Mentor


VSIA’s Focus had been:

Hardware Implementation

SW Design HW Design

GateLevel

VerificationDesignFunctional

Performance

RTL

Behavioral

System Design

SW implementation

HW Implementation

Existing VSIA: OCB I/V TST AMS VCT IPP QLT

FV

SLD


VSIA Expanded To:

Cover the whole SoC Design Space!!

SW Design HW Design

FV

GateLevel


Performance

RTL

SLD

Behavioral

System Design

SW implementation

HW Implementation


PBD

HdS


VC Quality

Quality has been called SoC’s most Challenging Problem

VSIA Is addressing it with the QIP Quality IP Metric

And soon, a QIP Adoption Group


Quality DWG

• The Quality DWG was chartered by the VSIA in to define and measure IP quality.

• Its formation was proceeded by a Quality Study Group

Key Deliverables:– Define Quality in the context of the IP industry– Develop a tool capable of measuring IP quality which

adds value for both the IP provider and the IP consumer. – Comprehend/integrate applicable sections of OpenMORE

as part of the QSS– Provide a forum for the development of “Best Practices”

which result in IP of higher quality


The Quality Vision, Goals and Key Events

• QDWG Vision (5 yrs)– "To implement a widely accepted and utilized metric

(standard) which is both quantifiable and automated to enable and grow a thriving commercial IP business."

• QDWG Goals (1 year)– Refine study group spreadsheet to serve as THE VC quality

measurement tool with quantifiable measurement criteria– Finalize Rev 1 of the Soft IP module of the QSS by DAC 2003

• Key Events– Quality Study Group formed

• 4 Quality Axis Defined by Quality Study Group– (A1) Authoring Process

– (A2) VC Verification

– (A3) VC Maturity

– (A4) Vendor Capability • ST Donated their Spreadsheet Metric -> QSS• Agere Donated their ChartReuse extension of OpenMORE • DWG has completed V. 1.0 of combined Metric for Soft IP:

QIP• VSI Member Review release now planned for Summer 03


Quality• Quality Spreadsheet Created by Quality Study Group

– 4 Quality Axis Defined• (A1) Authoring Process

• (A2) VC Verification

• (A3) VC Maturity

• (A4) Vendor Capability

– ST “Progressive Imperatives” Proposed• ST Seed Proposal Refined

• Post Study Group – OpenMORE donated by Mentor/Synopsys

– DWG went into limbo for 6 months

• Regenerated at last year’s DAC


Quality DWG: History

• ST donated their Quality Metric -> QSS– 4-axis Quality Attributes Spreadsheet

• Synopsys and Mentor donated OpenMORE

• Agere and Cadence Donated their ChartReuse extension of OpenMORE– And have become quite active in Quality DWG

meetings

• Sub-DWG teams merged the QSS and ChartReuse into new QIP VSIA Quality Metric V. 1.0– And created a new simplified “Traffic Light”

scoring system


Quality DWG: Current MR and Beta Status• QIP went into VSIA Member Review August 25, 2003

– Beta formally started with the QIP V. 1.06

• Much Interest expressed, but so far only have– Toshiba/Mentor– Agere/Cast

• DWG Solicited– Alcatel may team with Mentor– Sci-worx may be stand alone– Cadence interested for internal IP review– Intel probably in November

• Board Solicited– ST Micro, Infineon, IBM investigating whom

• Peter Hirt expressed strong interest in ST Micro getting involved

• Need DWG Meeting soon to focus Beta– And continue QIP development

• Need Strong Board Support of Beta


Quality DWG PR

• QIP Member Review and Beta have received excellent PR and is getting great Visibility– EET, EDTN Newsletter and EDA Cafe– Kathy Werner to present at

• 2003 FSA Semiconductor IP Workshop, October 10• TechOnline Webinar, Dec 9

– Submitted Draft Proposals for• IP BASED SOC DESIGN'2003 • DATE 2004

– Will submit to DesignCon 2004 in few days


Quality Next Steps

• VSIA Member Release Goal Q403– Digital Soft IP and IP Maturity-&-Vendor Assessment only

• Complete other IP metrics that are in “Alpha” by November 03 for MR and Beta as V 1.2– Verification IP

– Software IP

– Analog IP

• Extend QIP to Hard IP in cooperation with FSA– FSA has agreed in principal to forming a strategic alliance with VSIA

to extend QIP to Hard IP• They will fund Vin Ratford to Chair the Hard IP sub-group of the Quality

DWG

• They will provide ~ 6 contributors to sub-group

– Goal: Complete Hard IP extension by June 2004 as V. 2

• Joint Marketing with FSA for Industry “Rollout” of QIP


Quality

• Outside Interest in QSS growing• FSA interested in results of QSS

– They prefer to focus on business/legal/education issues• Aligning QSS line items with other DWGs• Team has created sub-groups to accelerate effort:

– Soft IP - Martin Radetzki – Quantification - (aligned soft) Kathy Werner – Scoring - Scott Batzer– Hard IP - Vin Ratford

• Participation– Strong interest in tracking Quality work– Strong interest in results– Need more consuming company participation


Functional Verification DWG Status

• VER 2 1.0 Specification– Four DWG subgroups had completed their work defining

deliverables for:• Stand-alone verification (Mark Peryer of Mentor chaired)• Verification environment (Mike Bartley of Elixent chaired)• Coverage metrics (Andy Piziali of Verisity chaired)• Formal verification (Richard Stolzman of Verplex chaired)

• Merged Document went to VSIA technical editor in October ‘02 and copy edits completed

• Deliverables added in response to Staff request• Approved by Sept 4 TC for Member Review, subject

to:– Adding a column to Deliverables table for Rules requiring

documentation– Acknowledging Motorola SRS contribution in added boiler plate

section– Merging two deliverables chapters into single Chapter 2, if

“quick”• Agreement that more substantive Motorola

comments/suggestions be given as part of Member Review


VCT (VC Transfer) Overview

• VCT 1 2.0 “ VC {meta} Information Set”– aka “VC Documentation”

• VCT 2 2.0 “VC (Profiling) Attributes”

– Detailed Attributes and Formats for Information Set• Appropriate for VC Catalogs

– VCA Released March 20, 2001– Early Adoption by VCX, Si2, IPH, D&R

• Now by many others– Speed in releasing specs/standards key for industry

convergence


VCT Current Development

• VCT 3 “VC Packaging and Transfer”– A packaging scheme for VCs

– A transfer method for VCs

– Intended use

• Primarily in VC transfers between companies

• Recommended within companies (not required)

• VCT DWG went Inactive for almost one year for interesting reasons


VC Transfer

• VCT DWG restarted under David Gardner and Carolyn Hayden

• DWG agreed to focus on VC Packaging Initially• DWG has instituted two reforms to speed up

process– Creation of a Tiger Team of real technical contributors

• Each responded to a call for technology– Two-thirds vote to drive decisions– Tiger Team treated as an independent entity

• i.e. not formally a VSIA activity– This is good model for future accelerated

development

• Spec completion targeted for late ‘03


VC Transfer Packaging Spec

• VCT Tiger Team (VSIG) has been meeting and created a draft proposal – They will present their Packaging Primer to VCT DWG

on Sept 11– This is not a spec, but a proposal to solicit input

• After DWG input is comprehended, the spec will be created by the DWG, reviewed and voted on– Expect this cycle to complete by EOY– But depends on DWG process

• A Transport Specification to facilitate the seamless-and-secure transfer of VC data between Providers and Integrators is planned for next– Perhaps go to MR 3Q04


Major SoC

Challenges


What are the major SoC Challenges?

• This is a list that was reviewed at a VSIA Member Meeting at DesignCon in January 2003 (in rough order of “pain”):

• Virtual Component (IP) Quality

• Functional Verification

• Design Productivity– Single VC Silicon Productivity not enough

• Need more overall SoC Productivity gain (on-going)

– Both H/W and S/W Design Productivity

• Signal Integrity Issues– 90 nM and below

• IP Protection

• & SoC Standards need to be Supported and Productized


Design Productivity - Software

• SoCs are NOT just hardware– Increasingly they include software– Already over 50% of the design effort, and growing

• Productivity improvement requires Design Reuse• But how make Software dependent on Hardware reusable?

– i.e. Portable to other hardware platforms?

• Also, how get better communications between the HW and SW communities?

• This is Charter of the HdS DWG

0.35µ 0.25µ 0.18µ 0.15µ 0.12µ 0.09µ

Gates/cm2

Moore’s Law(59% CAGR)

Widening GapsWill Trigger

Paradigm Shift!Design Productivity(20-25% CAGR)

Software Productivity(8-10% CAGR)


Design Productivity - Hardware

• AND “Productivity Gap” continues to grow for Hardware– Have to move beyond single Virtual Component reuse

• To clusters of VCs,

• Plus

– Silicon NRE’s continue to Escalate• Have to reuse Silicon (design and mask sets)

• Therefore strong interest in Integration Platforms • But what really is a Platform?

– Seem to be many different definitions and approaches

• What’s needed for to define a successful Platform?

• What Deliverables should transfer from Platform creators to Platform Integrators?

• This is the Charter of the PBD DWG


GateLevel

Verification

Functional

Performance

RTL FV

2) VSIA DWG Relationship

VSIA Covers the whole SoC Design Space

SW Design HW Design

Design

SLD System Design

SW implementation

HW Implementation

PBDHDSBehavioral

I/V, AMS, TestOriginal VSIA “Foundation”

VCT, IPP, ->OCBCommunicate, Transfer and Protect


Hardware-dependent Software

DWG Overview


What is Hardware dependent Software (HdS)? And Why?

• Hardware Dependent Software:– All software that is directly dependent on the underlying

HW:• HW drivers• Boot strategy, load• Built-in tests (basic level, offline tests)• HW dependent parts of communication Stacks• Algorithms implemented in SW on DSP

• Purpose of HdS layer– Shields hardware details for upper layer application

software– Retain portability across various simulation and target

environments for rest of eSW

– Goal: eSW only Communicates with HW via stable API


HdS-DWG - History and Mission

• Created 09/2001 as result of VSIA’s investigation on SoC industry’s needs to open for Embedded SW

• Working with currently 23 members from 12 companies (Silicon, EDA, System houses), and 4 indiviudal members

• Co-Chaired by – Stephen Olsen (Mentor Graphics)

– Frank Pospiech (Alcatel)

• Subject:– Hardware dependent Software (HdS): All software that is directly dependent

on the underlying HW, and that shields hardware for upper layer application software.

• DWG’s Mission:– Improve company internal and inter-company component re-use by defining

or fixing an "HdS API".

– Come to industry specifications on HdS Virtual components

– Concentrate on single- and multiprocessor SoCs


HdS-DWG Charter.

VSIA's Hardware dependent Software (HdS) DWG deals with the software layer that interacts directly with the interface offered by the SoC's HW platform. It is defined to hide HW specifics from upper layer SW. HdS can be viewed from a SW platform, HW platform, or SoC design life cycle perspective.

The aim of the DWG is to improve company internal and inter-company component re-use by defining or fixing a "HdS API". The HdS API exposes the SoC's functionality to the upper layer SW. The interface it offers is dependent on the application domain (i.e. multimedia, automotive, telecommunications), therefore the APIs may be different for different application domains. The API can be applied in all relevant development phases (design, verification, debug, production).

A taxonomy is provided, that clarifies the subject, as well as its different aspects and its structure (HW layer, communication layer, application layer,... of the HdS API).

The DWG addresses SoC-IP providers, system integrators, EDA providers, and OS providers.


Major Challenges to Address

• Need to address two issues– Communications gap between HW and SW developers

• Need tutorial on basic concepts and Common Terminology

=> HdS Taxonomy:• Define HdS specific terms (HdS, HdS-API, kernel space, user space,

driver, access shielding,…)

• Define SoC concepts

– Facilitate eSW portability to new platforms• Isolate most of the eSW from Hardware Changes

=> HdS API• Define the characteristics of a common API, that defines the way how to

provide SoC IP’s functionality to upper layer Software.

• Define HdS-APIs for different application domains (telecommunications, automotive, multimedia,…)

• Enable automatic generation of SW/HW interfaces from common register specifications, across various HW and simulation platforms


Other Standards & the HdS API

Applications

Middleware

Device DriversOS

FirmwareHardware

Debug Port

New Standard RequiredHardware-Dependent Software

(HdS)

UserSpace

KernelSpace

Industry Standard Algorithms

RTOS and Language Standards


What is HdS/What not - HdS-API

Application SW

Middleware

Test support library

Offline Test segments OS

Hardware Abstraction layer (HAL)

Hardware

HW-init

Boot & Load

BSP BSP

HdSHdS

EmbeddedSW

EmbeddedSW

POSIXPOSIX

HdS-APIHdS-API

Online Test segments

Use

r S

pace

Us e

r S

pace

HW

Spa

ceH

W S

pace

Ke r

nel S

pac e

Ke r

nel S

pac e

Device Drivers


HdS Taxonomy• Provide a commonly agreed HdS taxonomy, related to other domains

like – Platform based design– Functional verification– System-level Design

• Provide a Top-down view on the HdS domain, train HW and SW experts in understanding HdS (tutorial like character)

• Create a terminology for the HdS domain, serve as industry reference

• Structure:– HdS Terms and Abbreviations – Software Layering, Relation to HW and SW layers – HdS Taxonomy Axes

• Life Cycle Axis • HW Architecture axis• Run-time / Real time axis

• Hardware-dependent Software Taxonomy Version 1 (HdS 1 1.0) MR ended May 30, 2003.


HdS-API• Working on API description methods

– UML notation based– Definition of

• HdS Framework: HAL architecture• API mechanism: How to specify an HdS API• Elementary Services: Which are the basic services either to

be offered directly to the SW, or of which services are composed of

• Mapping of the current proposals to the members’ actual situation (telecommunications, multimedia, automation,…)

• Stepwise refinement• Focus

– 1. On Single processor architectures, – 2. Multiprocessors

• Basis for HdS-VC Re-use guidelines (to come later)• Status: Definition framework (HdS_2_0.2 under work)

– Recently, QNX, an RTOS company has joined the effort


HdS-DWG Status

• HdS Definitions and Taxonomy Document HDS_1_1.0 went to Member Review in March 03

• Completed 60-day Member Review May 30– Over 300 Downloads– But NO comments

• Desirable to log downloaders and request comments after MR complete

• DWG approved Release to Members

• Sept 4 TC passed Recommendation to the Board to Release to Members

– Board approved release by email vote

• To be Released to Members within 2-3 weeks


HdS-DWG Plans for FY ‘04

• Create HdS API Specification– Define HdS Framework: HAL architecture– Define API mechanism: How to specify an HdS API– Define Elementary Services: Which basic services available

to application SW

• HdS_2_1.0 ~6/04API description methods, API architecture, and first

service specifications.

• HdS_2_2.x ~12/04API service specification completion.

• Challenge: Recruit RTOS companies (QNX working with us)


Platform-Based

Design DWG


Platform-Based Key Definitions

• Platform: A platform comprises a common, integrated, and managed set of features, upon which a set of products or product family can be built. In the SoC context, it is a library of virtual components and an architectural framework, consisting of a set of integrated and pre-qualified software and hardware Virtual Components (VCs), models, EDA and software tools, libraries and methodology, to support rapid product development through architectural exploration, integration and verification.

• Platform Based Design: An integration-oriented design approach emphasizing systematic reuse, for developing complex products based upon platforms and compatible hardware and software VCs, intended to reduce development risks, costs, and time to market.


Platform-Based Design Premises

• The embedded systems industry can reduce risk, reduce cost, enhance time-to-market and improve economic return, by applying principles of platform-based design for families of products.

• At present there is no methodology to defining, scoping, specifying, or reusing a platform, or defining interconnections between hardware and software IP blocks that can be used at different levels of abstraction and product integration.

• Today’s platform is tomorrow’s component!

System-on-a-ChipSystem-on-a-ChipProduct FamilyProduct Family

Modules & PeripheralsModules & PeripheralsStandard Modules

CoreEmbeddedSoftware

Test Interfaces

System Interfaces

Memory Interfaces

Memories

Standard ModulesStandard Modules

CoreCorePlatformPlatform

CoreCoreEmbeddedEmbeddedSoftwareSoftware

Test InterfacesTest InterfacesSystem InterfacesSystem Interfaces

Memory InterfacesMemory InterfacesMemoriesMemories

Modules & PeripheralsModules & Peripherals

Computing Computing ComplexComplex


System-on-a-ChipSystem-on-a-ChipProduct FamilyProduct Family



Test Interfaces

System Interfaces

Memory Interfaces

Memories









System-on-a-ChipSystem-on-a-ChipProduct Family MemberProduct Family Member



Test Interfaces

System Interfaces

Memory Interfaces

Memories










Platform-Based Design DWG Charter

• The PBD Study Group and DWG will lead standardization of platform engineering for SoC-based embedded systems, based on our definitions of platforms and platform-based design, by identifying design flows and methodologies, levels of abstraction and integration, interchange standards, and other relevant topics, and specifying standards that promote effective platform-based design and interchange of platform-related IP.

• While platform-based design is applicable at many levels of integration within a finished product, our scope will be limited to platform-based products at the SoC level and below. SoCs, which themselves may be built on lower level platforms, will serve as platforms for higher level products.


PBD DWG Deliverables

• PBD White Paper– What is a platform?– What different types are there?

• Advantages and disadvantages

– Why are platforms critical to SoC Success?

• Requirements for Platform Creation– Focusing on three generic platform types:

• Application-driven (top-down)• Architecture-driven (middle-out)• Technology-driven (bottom-up)


FunctionApplication

Component

System

StructureLibrary Framework Application

Market

Statistical

Segment

Specific

PBD Basic Taxonomy Axes


Structure

Mar

ket

Fun

ctio

n

Block-based(below Platforms)

Technology-Driven(bottom-up)

Architectural-Driven(middle-out)

Applications-Driven(top-down)

PBD Styles and Taxonomy Axes


PBD DWG Taxonomy Document

• PBD Definitions and Taxonomy Document– Focus on three platform types:

• Application-driven (top-down)• Architecture-driven (middle-out)• Technology-driven (bottom-up)

• Preliminary Version of document went out for a “Special Member Review” completed June 10– Lots of good comments and suggestions– DWG made major revisions and enhancements

• Finalized Definitions and Taxonomy Approved by Sept 4 TC for normal, 30-day, MR


PBD DWG Plan

• Real need in the SoC industry is to Specify the Platform Deliverables for the “Derivative Interface” i.e. the Deliverables from the platform creator to the derivative developer– DWG just started on this

• Best Guess Specification: 3Q04

• Internal to VSIA, we need to define relationships and division of responsibility between PBD and other DWGs– PBD needs to grow upward into SLD space– Do High level Verification???

• Platform Verification makes more sense (to me)– Will discuss collaboration with HdS soon


IP Protection BackgroundIP Protection is one of the most daunting challenges for

SoCs. There are both technical and business challenges

associated with IP ProtectionThe most valuable asset for most companies is their IP

They must protect it or loose competitive advantage

The IP Protection DWG has created an IP Protection While Paper to provide a tutorial on these complex issues for Engineers and Engineering ManagersIt is the second most downloaded VSIA Document

This has been followed by other key Documents


IP Protection DWG

• IP Protection White Paper

– Overview of technical, legal and business issues in IP

Protection

• VC Identification “Tagging” Standard (VCID)

– VCID released to public with strong support from UMC &

TSMC

• IP Protection Survey (Feb.’01)

– Strong Interest in IP Protection in general and 2 areas

specifically


IP Protection DWG• Two major Documents requested by Member Survey (1H01)

– More information about IP Protection: Legal/Biz Practices and Network issues

• Goal: provide Best Practices, Guidance & Tools!

• White Papers on both requested areas completed:

• “Value and Management of Intellectual Assets”• Four outside experts brought into DWG on IP Management and Legal

• Board Approved Release to Members 13June02

• “Technical Measures and Best Practices for Securing Proprietary Information” (aka “Network Security”)

• Three respected industry experts on Network /information security

• Frame problem and advise Best Practices

• Board Approved Release to Members 17Sept02

• Second most downloaded VSIA document last few months


IP Protection Status

• Enhancing “Tagging Standard” (VCID 2.0)– Enhancements requested by TSMC are now under

review• But we have an Artisan Tag insertion software licensing issue

– Therefore no dates projected until situation clarified

• Tagging scheme for soft IP– Interest from IBM and Synopsys but no technical

proposal yet• Expect proposal at Sept 12 DWG Meeting

• Encryption Standard Recommendation for VCT Transport Spec– On hold pending definition from VCT DWG.


VSIA Standards Adoption• Among the companies using VSIA Standards/Specifications,

Architecture and Deliverables Document are:* ARM - VSIA Adoption in ARM* Cadence - Methodology Services are VSIA Compliant* Canadian Microelectronics Corp. - CMC Supports VSIA for Canadian University

Research* Design & Reuse uses VCT 2 2.2 VCA Standard* Fujitsu Uses VCT 1, VCT 2 and Promotes VSIA Quality Metrics* Hitachi Uses VSIA Architecture and Deliverables Document* Infineon Technologies Supports VSIA Specifications* inSilicon - OCB 2 - VCI* Mitsubishi Uses VSIA I/V 1, VCT 1 and VCT 2* NEC Uses VSIA Deliverables, VCI and VCT 2* Oki Uses VSIA Architecture and VCT 1* Panasonic Uses Deliverables Document and Specifications* STARC Trial on VCT Pilot Project* STMicroelectronics - Tagging Standard* SystemC and VSIA SLD Datatypes* Toshiba Uses VCI , VCT 2 and Quality Metrics* VCX Uses VCT 2 2.2

• Adoption Slides with details at http://www.vsi.org/library/adoption.htm


VSIA DWGs, And VSIA,

in Transition


VSIA in Transition• As SoC Evolves, some technical areas have matured, others have

transitioned in importance and some have morphed into new ones• This has been mirrored in the activity levels of various DWGs• VSIA has evolved from a monolithic vision of the Architecture

Document into a somewhat disjoint set of independent DWGs– There would be value in uniting and consolidating ones who have

matured• Hence VSIA has decided to re-look at all the DWGs and begin re-

integrating some -- and dissolving others

• In addition, some VSIA Standards have been slow in adoption– Has demonstrated the need for “realization” or “productization”

• Also, VSIA specs are somewhat “academic” – Is there a need to support with real (high level) flows? – With Application Notes?– With Education and Training?– With VSIA Certification?

• This has led to the notion of VSIA Adoption Groups


VSIA DWGs Activity Snapshot (Early 2003)

• VC Quality• AMS/SI• Functional Verification• PBD• HdS• IP Protection• <= VC Transfer*

• SLD• AMS/SI• I/V

• Test• OCB

Active Not Active

* VCT has been fully reactivated

N.B. it is the Original

DWGs that are the least active, plus

OCB


I/V DWG Status (2000)

• I/V 1 2.0 Added Soft VCs to 1 1.0 Hard– Specified Synthesizable RTL (Verilog, VHDL) ...– Endorsed OLA & DC-WG (OVI)

• Firm VC White Paper • Need to Update 2.0 to Version 3.0

– Review status of specified standards • Surveyed the current I/V DWG spec usage (Soft and

Hard) – Incorporate Spec Audit changes– Review industry infrastructure status of endorsed

standards• OLA and DC-WG

– SDC Looks Promising– Synthesizable Verilog still not through IEEE

• Determine whether to specify OLA and/or DC– Add Firm VC requirements


Signal Integrity

• SI was added to AMS/Mixed Signal DWG in 2001 to create extensions to the AMS specs

• SI Version 1.0 – Baseline of SI issues facing VC Authors and Integrators

• Baseline is at 0.18um

– Contents• Power Grid

• Interconnect Crosstalk

• Substrate Coupling

• Example Design

– Specifications to provide for modeling of SI issues in VC transfer

• Completed Member Review: Feb 2002

• Released to Members April, 2002


Signal Integrity

• Version 2.0 – New Interconnect Modeling sub-DWG started– Specifications V. 2.0 development work started late

2002• Basically extend V.1 work from 0.18um to 0.07um

– Challenging as tools (or choice of) not yet in place– Same basic document structure, as in V. 1.0– Signal EM will be pulled out as a separate section– Tighter alignment with I-V and AMS Specifications

• Timeline – New sub-DWG Chair: Juan-Antonio Carballo, IBM

Research

– Investigate relation between SI, I/V and AMS specs• Analyze equivalent or strongly related deliverables

– Complete 2.0 Draft, Summer 2002– V. 2.0 Member Review: October 2003


Merging DWGs

• I/V and AMS have been inactive for two years now

• PROPOSAL: Merge physical implementation activities together under one DWG (i.e. I/V, AMS, and SI)

– Near term deliverables: SI 2.0, I/V formats update or plan on what to do about them

– Long term deliverable: Merged I/V, AMS, SI specification (“the one specification for IP blocks”)

• Home for the activities around DRML between VSIA and STARC

– Near term deliverable: White paper describing the need and possible solutions for a common design rule exchange format.


Implementation DWG Charter and Roadmap• The Charter of the VSI Implementation Development

Working Group (DWG) is to develop standards and specifications to facilitate the Implementation of SoCs. – The activities to date include developing standards and

specifications for the integration of • digital soft, firm, and hard IP • and hard analog/mixed-signal IP into SoCs. • This also includes developing standards and specifications for

addressing signal integrity issues in SoCs.

• Roadmap SI V. 2.0 Spec to TC for Member Review: Oct ‘03

• Juan-Antonio Carballo, IBM Research, new SI Sub-DWG Chair Updates in I-V formats Q3’03 (or a plan) Investigation of requirements for merging Specs: Q4’03

• Single document, AMS/IV/SI, or two documents, AMS-SI and IV-SI?

• Determination of updates required in AMS and IV Specifications

• Schedule planning for development

Development of merged document(s) through Q2’04


I/V, AMS, SI MERGED DOCUMENT

1. SI Version 2.0 Specification work– Member Review in Sept/Oct 03

2. Updates in I-V formats Q3’03

3. Investigation of requirements for merge Q4’03– Single document, AMS/IV/SI, or two documents, AMS-SI and IV-

SI?

– Determination of updates required in AMS and IV Specifications

– Schedule planning for development

4. Development of merged document(s) through Q2’04


New Implementation DWG: Mission Scope

• Merge physical implementation activities together under one DWG (i.e. I/V, AMS, and SI)

– Near term deliverables: SI 2.0, I/V formats update or plan Longer term deliverables:

• Merged I/V, AMS, SI specification (“the one specification for IP blocks”)

• Updating of documents as technical needs change – e.g., consistency with ITRS

• Home for the activities around DRML between VSIA and STARC


Implementation Status

• Analog/Mixed-Signal Signal Integrity Extension Version 1 (AMS 2 2.x) to TC for Member Review: Oct ‘03

˜ SI subgroup Chaired by Juan-Antonio Carballo, IBM Research

• Implementation consolidation Proposed plan:– Update I/V formats in (I/V 1 2.x) mid-2004 **

– Merge I/V, AMS and SI specs into one or two docs Q4’04 **• Updating of documents as technical needs change – e.g., consistency with ITRS

• DRML

– DRML “fluid"; V. 1 not appropriate; V. 2 still being defined; also need to identify new

owner **

• ** Delayed due to Andres unable to get LSI management priority


Inactive DWG Policy

• TC determines if DWG inactive for at least 6 months– If so, and no likely prospects, it recommends Board

change status from “Active” to “Inactive”

• Maximum period of Inactivity is 6 months– Must make recommendation to the Board on status or

disposition, within 6 month period, with justification

• Board may accept the recommendation to continue the DWG, request changes to recommendation details, or dissolve it, at its discretion


System Level Design has lost is significance

• Function/Architecture design & partitioning no longer seen as the holy grail– Too small amount of time spent in this phase.– Optimization is not a goal, re-usable architectures are.– Commercial tools have failed.– Trivializes the software component.

• Designs do not start from blank sheet of paper– Almost all designs are incremental in nature.– Derivative designs based on platform re-use.

• Platform based design has gained in significance

• Current notions of SLD are not likely to be revived– Will be based on different notions and will want to create

distance between earlier failed efforts.

The SLD DWG has been declared as “Inactive”

Perhaps SLD has been replaced by PBD and HdS: <= LMR

Slide from Brian Bailey, SLD Chair


Key Successes for the SLD DWG

Generation of (SL) Model Taxonomy Document Version 2.0 Released in July 2001 Document is commonly referred to in the academic literature This remains THE most downloaded VSIA Document

Data-Types Gained strong alignment in the industry: moving industry to a

single standard!

Have firm alignment with SystemC, and principle of adoption into development of Accelerate

SLIF Standard 1.0 Highly regarded in academic and SL Language circles: Defines

Interface-based Design These principles outlined influenced SL tool development,

however doesn’t seem to be industry’s direction


Manufacturing Test DWG

• Developed VC Test Access Architecture Standard– Basically, this is a embedded-core test-access

structure Standard– Agreement with IEEE P1500 Committee to make 1500 a

superset of VSIA Test Access Architecture Standard– Test 2 1.0 Completed Member Review February 2001

• All Member and P1500 Comments Resolved

• Test Access Architecture Standard Released to Public August 2001

• BUT adoption has been slower than expected– Test DWG on verge of becoming Inactive– Companies must be solicited to adopt Test Access

Architecture– Corrective action being put into effect


Test DWG Issues

• Major issue is adopting companies want supporting automation tools first– EDA companies want requests with commitments to buy

• Weren’t able to break chicken&egg dilemma

• Other issue is many waiting for P1500 to complete– P1500 features now no longer upward compatible with Test Access

Standard– P1500 charter may or may not terminate soon

• Current charter ends in December

– New P1500 draft doc mid June

• Also still able to design and manufacture core-based designs “flat”


OCB DWG

• Advanced VCI and Transaction Language added to the standard [OCB 2 2.0]. – Released to Public in April 2001

• OCB Attributes Specification [OCB 1 2.0] has been updated. – Needed to specify VCI compliance.

• VCI is a VSIA Standard, not a specification.

– VCI compliance has been extended to include any bus interface which can be made equivalent to the VCI by means of a thin wrapper (“veneer”)• and for whom the veneer is made available and

demonstrated


VSIA DWGs in Transition Summary

• A new Implementation DWG Created by Board

– I/V and AMS had been Inactive for over two years

– They and the very active SI sub-DWG have been merged

• VCT has been revived from Inactive Status

– Work in progress on VCT-3 since January

• SLD has been declared Inactive

– Probably will be terminated in September

• Manufacturing Test struggling to get adoption for their Embedded Core Test Access Standard

• The future of OCB to be announced after DAC

• Creation of Adoption Groups to be considered by VSIA Board


The New VSIA

• The new Design Productivity Challenge– The eSoC Initiative

• The Quality Challenge– The QIP Initiative

• Virtual Management of VSIA– The new Web Site– New streamlined proceedures

• Adoption Groups• Regional SIGs

– JSIG, KSIG?, CSIG?


DWG History

• Initial DWGs formed in Spring ’97– Based on sections of Architectural

Document• System Level Design• Implementation / Verification• Analog mixed Signal• Test

– And Member additions • On Chip Bus• IP Protection

• Added additional DWGs• VC Transfer• VC Quality• Functional Verification

SLDOCBI/V

AMSTSTIPP

’97 ’98 ’99 ’00

VCTQTYFV


Design Productivity Gap

Growing gap between what’s designable and what’s manufacturable

SoCs are system solutions - Combinations of HW and SW

0.35µ 0.25µ 0.18µ 0.15µ 0.12µ 0.09µ

Log

Sca

leGates/cm2

Moore’s Law(59% CAGR)

Widening GapsWill Trigger

Paradigm Shift!Design Productivity(20-25% CAGR)

Software Productivity(8-10% CAGR)


The eSoC InitiativeHardware Components

ArchitectureTemplates

Hardware / Software System

Requires Plug & Play Solutions

Based on existing requirements/Architectures/Libraries

Full SoCIntegration

Software

Software Components

Software

VSIA’s vision is to dramatically improve the productivity of SoC development by specifying open standards and specifications that facilitate the integration of Software and Hardware VCs from multiple sources.

.


DWGs Today

• eSoC Initiative Added– Hardware dependent

Software (HdS)– And later Platform based

Design (PBD)SLDOCBI/V

AMSTSTIPP

Past ’01 ’02 ’03 Future

VCTQTY

HdSPBD

FV

• Changes in the works– SLD went inactive

[replaced by PBD]

– I/V & AMS merged into [Implementation (IMP)]

IMP

New Adoption Groups are being formed now.


VSIA Expanded To:

Cover the whole SoC Design Space!!

SW Design HW Design

GateLevel


Performance

RTL

SLD

FV

Behavioral

System Design

SW implementation

HW Implementation


PBD

HDS


VSIA- Historical Organization & Focus

Membership(Technical)

MarketingAdminEventsPRImage

LegalFinancialDocumentsVSIACoordination

VSIA BoDMembership(Executive)

Engineering

DWGs


VSIA - New Organization & Focus

AdoptionGroups

MarketingAdminEngineering

DWGsEventsPRImage

LegalFinancialDocumentsVSIACoordination

Business

Committees

TAB

Membership(Technical)

VSIA BoD

Membership(Non Technical)

IndustryExperts

Membership(Executive)

IndustryOrganizations


The Web: www.vsi.org

• The Public site contains:– Related news and web

sites– VSIA news releases &

articles– Membership forms

• Members Only site contains:– Corporate logon ids – Specifications, Standards

and documents– DWG minutes and

presentations

• The Public site contains:– A new look and feel– Related news, articles &

sites– On line Membership– On line document sales

• Members Only site contains: – Individually tailored pages– Specifications, Standards

and documents– DWG minutes and

presentations– On-line membership

renewal– On-line DWG collaboration

Was Is now in transition To


Membership

• Membership by signing agreement and annual dues of:– $1K for individuals (can be waived for DWG service)– $1K for corporations under $1 million in revenue– $5K for corporations under $10 million in revenue– $10K for corporations under $100 million in revenue– $15K for corporation under $1 billion in revenue– $20K for corporations over $1 billion in revenue– $25K for SWG corporations

• Special Membership is free (limited time or scope of use)• DWG membership is free (unlimited but 1 vote/ member)• SWG membership is by election (5 seconds to nominate)• Membership in Adoption Groups may require signing additional

agreements and additional annual dues.


Membership Benefits

• Documents– Early Access / Member Review– And they are Free

• Association– Vendor / Customer contacts – Worldwide collaboration– DWGs Target your interests

• Discounts– Events (Seminars)– Advertising (Catalog &

Magazine)– Adoption Groups

• Standard Creation– DWG participation– Adoption Groups (Roll your

own)

Giving you and Your company an Unfair Advantage in Design Reuse.


Regional “Special Interest Groups”


Summary and Conclusion