You are on page 1of 66

VSI AllianceTM Deliverables Document Version 2.6.

0
(DD 2.6.0)

April 2002

Copyright 2000-2002 by VSI Alliance, Inc. 401 Edgewater Place, Suite 600 Wakefield, MA 01880, USA Phone: (781) 876-8822, Fax: (781) 224-1230 http://www.vsi.org, info@vsi.org This document may be downloaded for personal use from the VSI Alliance website at www.vsi.org. All other rights are reserved by VSI Alliance, Inc. VSI Alliance is a trademark of the VSI Alliance, Inc. All other trademarks are the property of their respective owners.

VSI Alliance Deliverables Document Version 2.6.0

Notice
THE DOCUMENT IS PROVIDED BY VSIA ON AN AS-IS BASIS, AND VSIA HAS NO OBLIGATION TO PROVIDE ANY LEGAL OR TECHNICAL ASSISTANCE IN RESPECT THERETO, TO IMPROVE, ENHANCE, MAINTAIN OR MODIFY THE DOCUMENT, OR TO CORRECT ANY ERRORS THEREIN. VSIA SHALL HAVE NO OBLIGATION FOR LOSS OF DATA OR FOR ANY OTHER DAMAGES, INCLUDING SPECIAL OR CONSEQUENTIAL DAMAGES, IN CONNECTION WITH THE USE OF THE DOCUMENT BY SUBSCRIBER. VSIA MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY WARRANTY AS TO INFRINGEMENT, OR THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. SUBSCRIBER SHOULD BE AWARE THAT IMPLEMENTATION OF THE DOCUMENT MAY REQUIRE USE OF SUBJECT MATTER COVERED BY PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS OF THIRD PARTIES. NO LICENSE, IMMUNITY, OR OTHER RIGHT IS GRANTED BY VSIA IN ANY SUCH THIRD-PARTY RIGHTS. NEITHER VSIA NOR ITS MEMBERS TAKE ANY POSITION WITH RESPECT TO THE EXISTENCE OR VALIDITY OF ANY SUCH RIGHTS.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

ii

VSI Alliance Deliverables Document Version 2.6.0

Revision History
Revision Number 0.9.0 1.9.0 1.9.1 1.9.3 1.9.3 2.0 2.0 2.0 2.1 2.3 2.4.0 2.4.1 Date 14Mar98 18Jul98 18Jul98 16Jun99 23Jun99 1Jul99 2Aug99 31Aug99 19Oct99 17Oct00 14Dec00 26Feb01 Changes made by Larry Saunders Larry Cooke Larry Cooke Larry Cooke Wilsa Schroers Editing Staff Editing Staff Editing Staff Editing Staff Larry Cooke, Stan Baker, Editing Staff Editing Staff Editing Staff Description of Changes Created initial document from existing VSIA Architecture Document and other information. Updated to include OCB and I/V Specifications and other edits. Updated according to the SSC meeting. Edited per Policy Committee decisions. Copy edited. Formatted and edited. Formatted for web. Edited formats. Updated VCT section. Formatted to match current VSIA styles. Updated tables according to recent Audits of Specifications. Edited formats. Updated table formats. Corrected error in Table 1, Analog/Mixed-Signal section. Moved Comment in row Section 2.6.6 to Comment cell in row Section 2.6.7. Updated OCB 1 2.0 pages of Table 3, page 2, glossary, deleted Appendix E Include information from AMS 2 1.0 Update Summary and Definition of Terms

2.5.0 2.6.0 2.6.0

06Jan01 02Apr02 02May02

Editing Staff Editing Staff Editing Staff

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

iii

VSI Alliance Deliverables Document Version 2.6.0

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

iv

VSI Alliance Deliverables Document Version 2.6.0

Table of Contents 1. Specification Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 2. Deliverables Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 3. Scope and Referenced IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
3.1 DWG Specification Referenced IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.1 System Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.2 Manufacturing Related Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.3 IP Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.4 On Chip Busses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.5 Analog/Mixed-Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.6 Implementation/Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.7 VC Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 DWG Specification Scopes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.1 System Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.2 Manufacturing Related Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.3 IP Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.4 On Chip Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.5 Analog/Mixed-Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.6 Implementation/Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.7 VC Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.8 VC Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.9 Hardware-dependent Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Design Constraints Endorsement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Performance Modeling Endorsement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2

4. Endorsements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
4.1 4.2

A. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
A.1 Open Standards References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A.2 VSIA Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39


B.1 B.2 B.3 B.4 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Rationale and Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Attribution Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Definition of Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

C. Glossary of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 D. Compliance Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

vi

VSI Alliance Deliverables Document Version 2.6.0

1. Specification Philosophy
The Virtual Socket Interface Alliance (VSIA) specifications identify information required to enable Virtual Components (VCs) integration onto a System on a Chip (SoC). While some of this information comes in the form of documentation, much of it comes as executable models or machine-readable design descriptions. The goal of the VSIA is to specify a complete interface that:Provides a practical, reliable link between the VC provider and the VC integrator. Evolves consistently with tool, process, and technological advances. Specifies the use of an industry standard open format whenever applicable for executable or machinereadable models. The VSIA advocates convergence among competing formats to reduce the number of recommended alternatives where no standard exists, or where the standard has not yet been widely integrated, the VSIA will encourage standards to be developed by the appropriate associations such as OVI, IEEE, and so forth. The VSIA will endorse standards that meet their requirements. The VSIA will recommend a proprietary format in a specification only if the owner of the format agrees to make the format available for use within the field of use as defined in the VSIA specification as an open format or for a non-discriminatory and non-burdensome fee.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

2. Deliverables Summary
The following summarizes the VSIA Requirements for data formats. The discussion in this section is also applicable to tables in Section 2 of each of the DWG Specification documents. The following list describes the columns in the tables and the keywords used in the columns. DWG Spec Specifies the DWG Specification document that contains the deliverable, the format is: [DWG_name] [Spec #] [Major_ver #] . [Minor_ver #] where DWG_name is one of the following: VCT SLD TST IPP OCB AMS I/V VER QTY VC Transfer System Level Design Manufacturing Related Test IP Protection On Chip Busses Analog/Mixed-Signal Implementation/Verification Functional Verification VC Quality

Spec # is a digit from 0 to 9 Major_ver # is a digit from 0 to 9 Minor_ver # is a digit from 0 to 9 Note: Any reference to Arch 1.0 denotes that the deliverables are specified in the corresponding section of the Architecture Document 1.0. Section Deliverable VSIA Endorsed Formats Document ASCII VSIA Specified Formats TBD Soft, Firm, Hard, AMS Hard, SI Hard OCBD, VCD, SOCI M References the document section that discusses the deliverable. Describes the deliverable. Lists the formats being developed as standards, which meet the VSIA DWGs requirements. Information exchanged on paper or electronically in a widely used format. Information must be exchanged in a machine- and human-readable format. Lists currently available open formats that have been approved by the respective VSIA DWG. Denotes that no candidate has been selected. The VSIA will either: - Actively pursue a candidate within a DWG- Will not pursue a candidate at this time Describes the applicability of the deliverable to a VC of this hardness. Describes the applicability of the deliverable to an On-Chip Bus provider, VC Developer, and a System on Chip integrator. Denotes Mandatory. Mandatory is a deliverable that is required to make most chip designs workable that use the particular hardness of VC denoted by the column it resides in. Denotes Conditionally Mandatory (requirement is based on application).

CM

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Denotes Recommended. Recommended is a deliverable that will improve the design time, quality, or accuracy for most chip designs that use the particular hardness of VC denoted by the column it resides in. Denotes Conditionally Recommended (requirement is based on application). Conditional comments should identify a class of designs, VCs, or chips containing VCs, where this deliverable is applicable if the defined condition is met. Conditions are sufficiently described to delineate the class of designs. This deliverable is not applicable for this category This column is used only by VC providers to indicate compliance with sections of specifications. (See Appendix D) Adds clarifying information. The specific conditions necessary to meet a CM or a CR are described within the comments section for each deliverable. Also used by VC providers for comments or references to comments in the comment section of a compliance report. (See Appendix D)

CR

Comply? Comments

Note: With respect to compliance, all lists of formats for a given category and deliverable, may be viewed as OR of the individual formats. That is, any of the listed formats may be used to satisfy the deliverable.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Table 1: VSI Alliance Specification (AMS 1 2.2) Data Deliverables Section Deliverable VSIA Endorsed Formats VSIA Specified Format(s) A/MS Hard Comply ? Comments

2.1 2.1.1 2.1.1.1 2.1.1.2 2.1.1.3

User Guide Specification System Description Block Diagram Register Description document document document M M CM If there are registers present, this deliverable is M. If there is digital I/ O, this deliverable is M. If there is analog I/O, this deliverable is R. If there is a clock, this deliverable is M.

2.1.1.4

Timing Diagram

document

M, R

2.1.1.5

Clock Distribution Bus Interfaces & I/O Configs Test Description Summary Integration Requirements Schematic Block Diagrams Operating Modes Bias Supply Management Operating ranges Power Supplies Electrical Specifications Bonding Pad Requirements

document

CM

2.1.1.6 2.1.1.7 2.1.1.8 2.1.1.9 2.1.1.10 2.1.1.11

document document document document document document

M M R R M CM If there is a bias supply, this deliverable is M.

2.1.1.12 2.1.1.13 2.1.1.14 2.1.1.15

document document document document

M M M CM If special pads are required, this deliverable is M.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Table 1: VSI Alliance Specification (AMS 1 2.2) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Format(s) document document document document document A/MS Hard Comply ? Comments

2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2 2.2.1 2.2.2 2.2.3 2.2.4

Claims and Assumptions Verification of Claims Version History Known Bugs Application Notes Process Definition Process Requirements Process Tolerances Process Sensitivities Process Design Rule Exceptions

M M M M R

document document document document

M M R CM If the design rules are intentionally violated, this deliverable is M.

2.2.5

VC Processing History/ Portability System Architecture and Design Algorithmic Level Model

document

2.3

2.3.1

TBD- electronic R format pertaining to the tool TBD- electronic R format pertaining to the tool Packaged Integrated Circuit, document R

VSIA may define a more specific format or set of formats at a later time. VSIA may define a more specific format or set of formats at a later time.

2.3.2

System Evaluation Model / Behavioral Model Bonded Out VC/ Prototype

2.3.3

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Table 1: VSI Alliance Specification (AMS 1 2.2) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Format(s) A/MS Hard Comply ? Comments

2.4

Functional and Performance Modeling Digital Placeholder (Dummy) Model Functional/ Timing Digital Simulation Model Digital Timing Model for Static Timing Bus Functional Model (for digital interfaces) Peripheral Interconnect Model (for digital interfaces) OLA Verilog, VHDL R

2.4.1

2.4.2

Verilog, VHDL

2.4.3

2.4.4

TBD

Format to be determined by the VSIA SLD Interface subgroup. If there is a measurable level of interconnect between the I/O ports and the internal gates of the VC, this deliverable is M.

2.4.5

SPEF

CM

2.4.6 2.4.6.1

Electrical Port Models Digital Electrical Port Model (device level interface netlist) Analog Electrical Port Model Block level HDL VerilogSimulation AMS, Model VHDLAMS VC Hspice R

2.4.6.2 2.4.7

VC Hspice

R R

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Table 1: VSI Alliance Specification (AMS 1 2.2) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Format(s) any suitable format A/MS Hard Comply ? Comments

2.4.8

Detailed Transistor/Gate Level Schematics

CR

If the VC provider agrees to release this deliverable, it is R. There may be IP Protection issues requiring discussion between the VC provider and the VC integrator. If the VC provider agrees to release this deliverable, it is R. There may be IP Protection issues requiring discussion between the VC provider and the VC integrator.

2.4.9

Circuit Level Simulation Netlist

VC Hspice

CR

2.5 2.5.1 2.5.2 2.6 2.6.1

Test Support Signal Requirements Test Requirements Physical Block Implementation Detailed Physical Block Description Layer Mapping Table Pin List/Pin Placement Routing Obstructions Footprint Power and Ground Layer Mapping Table GDSII-Stream M document document M M

2.6.1.1 2.6.2 2.6.3 2.6.4 2.6.5 2.6.6

document VC LEF VC LEF VC LEF VC LEF document

M M M M M M

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Table 1: VSI Alliance Specification (AMS 1 2.2) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Format(s) VC Hspice A/MS Hard Comply ? Comments

2.6.7

Physical Netlist

CM

If layout versus schematic is required by the VC integrator, this deliverable is M.

2.6.8 2.6.8.1 2.6.9 2.6.9.1 2.6.9.2 2.6.10 2.6.10.1 2.6.10.2

General Physical Rules Physical Isolation Specification Placement Specifications Placement Constraints Proximity Effects Interconnect Specifications Special Hookup Guidelines Routing Constraints document document M M document document M M document M

Table 2: Summary of Deliverables Table (AMS 2 1.0) Section 2.1 Deliverable Interconnect Crosstalk (Voltage Noise and Delay Variance) and Signal Electromigration Overview Electrical Data Maximum Permissible Noise Propagating into Input Ports VC Hspice CM If available, otherwise document in Section 2.4 If available, otherwise document in Section 2.4 Currently Used Formats VSIA Specified Format SI Hard Comply ? Comments

2.1.1 2.1.2 2.1.2.1

2.1.2.2

Maximum Permissible Noise Injected into Failure-critical Nets (If Any) Inside VC

VC Hspice

CM

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

VSI Alliance Deliverables Document Version 2.6.0

Table 2: Summary of Deliverables Table (AMS 2 1.0) (Continued) Section 2.1.2.3 Deliverable Maximum Permissible External (to VC) Switching Crosscoupling for Delay-critical Sensitive Nets (If Any) Inside VC Maximum Noise Possible at Output Ports (Due to Propagation and Coupling Inside VC) Electrical Characteristics for Strong Potential Aggressors (for OTH Signals) Lying Inside VC I/O Driver Models Interconnect Models Electrical Characteristics for Failure- or Delay-critical Sensitive Nets Lying Inside VC I/O Driver Models Interconnect Models Best- and Worst-case Slew Permissible at Input Ports Minimum and Maximum Slew Limits Input Environment Models Best- and Worst-case Slew Available at Output Ports (and Its Variation with Load) Minimum and Maximum Slew Limits Driver Models Maximum Permissible Load and Distributed RC that Can Be Driven by Output Ports Physical Data Location of Failure- or Delaycritical Sensitive Interconnect Polygons Inside VC Location of Strong Potential Aggressors (for OTH Signals) Lying Inside VC PDEF R Document M VC Hspice SPEF M M VC Hspice SPEF VC Hspice, SPEF VC Hspice SPEF Hspice, Document Document M VC Hspice M R R R Currently Used Formats VSIA Specified Format SPEF SI Hard CM Comply ? Comments If available, otherwise document in Section 2.4 If available, otherwise document in Section 2.4

2.1.2.4

VC Hspice

CM

2.1.2.5

2.1.2.5.1 2.1.2.5.2 2.1.2.6

2.1.2.6.1 2.1.2.6.2 2.1.2.7 2.1.2.7.1 2.1.2.7.2 2.1.2.8

R R

2.1.2.8.1 2.1.2.8.2 2.1.2.9

2.1.3 2.1.3.1

2.1.3.2

PDEF

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

10

VSI Alliance Deliverables Document Version 2.6.0

Table 2: Summary of Deliverables Table (AMS 2 1.0) (Continued) Section 2.1.3.3 Deliverable Location of Top-layer and Peripheral Supply and Ground Wires Inside VC No-fly Zone or External Shielding Requirements Safe Regions for OTH Signals (Possibly Classified by Slew) Timing Data Variation of Timing Arcs within VC with External Crosstalk SDF CM If available, otherwise document in Section 2.4 Currently Used Formats VSIA Specified Format PDEF SI Hard M Comply ? Comments

2.1.3.4 2.1.3.5 2.1.4 2.1.4.1

PDEF PDEF

R R

2.1.4.2 2.1.4.3 2.1.4.4

Transition Windows Available at Output Ports Transition Windows Assumed at Input Ports Transition Windows for Strong Potential Aggressors (for OTH Signals) or Failure- or Delaycritical Sensitive Nets Lying Inside VC Logical Data Mutex (One-hot) Relationships Pathmill Assumed Between Input Signals CFG files Mutex (One-hot) Relationships Available Between Output Signals Signal Electromigration Electrical Data Current Density Limits on Metal and Via Layers Maximum Load for Electromigration Limits on Outputs Maximum Slew Rate for Electromigration Limits on Inputs Maximum Switching Factor Drive Strength Input Load Physical Data Supply and Ground Grid Noise and Electromigration Pathmill CFG files

SDF SDF SDF

M M M

2.1.5 2.1.5.1 2.1.5.2

Document M Document M

2.1.6 2.1.6.1 2.1.6.1.1 2.1.6.1.2

Document M VC Hspice SDF M

2.1.6.1.3

2.1.6.1.4 2.1.6.1.5 2.1.6.1.6 2.1.6.2 2.2

VC Hspice

Document M Document M GDSII M

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

11

VSI Alliance Deliverables Document Version 2.6.0

Table 2: Summary of Deliverables Table (AMS 2 1.0) (Continued) Section 2.2.1 2.2.2 2.2.2.1 2.2.2.2 2.2.3 2.2.3.1 Overview Electrical Data Specification Specification Requirements for Static Power Model Specification Requirements for Dynamic Power Model Physical Data External Geometrical Data of the Supply and Ground Nets (Supply and Ground Ports) Internal Geometrical Data of the Supply and Ground Nets Timing Data Synopsys Variation in Timing on Output Pins (Delay and Edge Rates) Due .lib file to IR Drop in Power Grid Variation in Timing on Input Synopsys Pins (Setup and Hold Time) Due .lib file to IR Drop in Power Grid Multiple Power Supplies for Analog Blocks, Multi-Vt Circuits, and Pads Supply and Ground Electromigration Verification Substrate Noise and Coupling Overview Electrical Data Block-level Impedance Model Noise Sources for Aggressor Access Ports Maximum Allowed Noise for Each Victim Access Port Physical Data Regions Substrate Access Ports SI Requirements Document Annotated GDSII Document M Document M Document M VC Hspice VC Hspice VC Hspice M M M Document M VC LEF M Document M Document R Deliverable Currently Used Formats VSIA Specified Format SI Hard Comply ? Comments

2.2.3.2 2.2.4 2.2.4.1

Document M

2.2.4.2

Document R

2.2.5

Document M

2.2.6 2.3 2.3.1 2.3.2 2.3.2.1 2.3.2.2 2.3.2.3 2.3.3 2.3.3.1 2.3.3.2 2.4

Document M

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

12

VSI Alliance Deliverables Document Version 2.6.0

Table 3: VSI Alliance Specification (I/V 1 2.1) Data Deliverables VSIA Endorsed Formats VSIA Specified Formats Comply ?

Section 2.1

Deliverable Implementation Level Behavioral and Structural Models RTL Source

Soft

Firm

Hard

Comments

2.1.1

Verilog/ VHDL Synthesis Subset

CM

CR

2.1.2

Cell Level and Circuit Level Netlist

Verilog, -EDIF-netlist, VC Hspice, VHDL

CM

CM

Mandatory (M) for Firm VCs if required for synthesis. Required (R) for Hard VCs if formal verification or functional simulation is met. Mandatory (M) for Firm VCs if they are described at the gate level. Mandatory (M) for Hard VCs if layout versus schematic checking is required for these VCs.

2.2

2.2.1 2.2.2 2.2.3 2.2.3.1

2.2.3.2

2.2.3.3

Implementation Level Performance Models Basic Delay OLA Model Timing Analy- OLA sis Model Power Model Black/Gray OLA Box Power Model Requirements RTL Source Power Model Requirements Cell Level Power Model Requirements

R R

M M

M M

Verilog/ M VHDL Synthesis Subset Verilog, EDIF-netlist, -VHDL, SPEF

--

--

CR

CR

Recommended (R) if a more accurate power model is required.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

13

VSI Alliance Deliverables Document Version 2.6.0

Table 3: VSI Alliance Specification (I/V 1 2.1) Data Deliverables (Continued) VSIA Endorsed Formats VSIA Specified Formats VC Hspice --CR Comply ?

Section 2.2.3.4

Deliverable Circuit Level Power Model Requirements

Soft

Firm

Hard

Comments Recommended (R) if a more accurate power model is required. Recommended (R) for Firm VCs and Mandatory (M) For Hard VCs if the peripheral interconnect needs to be included in the delay calculation. Mandatory (M) if the IO or interfaces need to be modeled at the circuit level.

2.2.4

Peripheral Interconnect Model

SPEF

--

CR

CM

2.2.5

Circuit Level Interface Model Requirements

VC Hspice

--

CM

CM

2.3 2.3.1

Physical Modeling Detailed Physical Block Description Pin List/Pin Placement

GDSII

--

CM

2.3.2

VC LEF

--

CM

2.3.3

Routing Obstructions

VC LEF

--

CM

2.3.4

Footprint

VC LEF

--

CM

2.3.5

Power and Ground

VC LEF

--

CR

Mandatory (M) if Firm VCs contain physical data. Mandatory (M) if Firm VCs contain physical data. Mandatory (M) if Firm VCs contain physical data. Mandatory (M) if Firm VCs contain physical data. Recommended (R) if Firm VCs contain physical data.

2.3.6 2.4 2.4.1

Signature Design Constraints Timing Constraint

VC LEF

--

--

DC-WG

--

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

14

VSI Alliance Deliverables Document Version 2.6.0

Table 3: VSI Alliance Specification (I/V 1 2.1) Data Deliverables (Continued) VSIA Endorsed Formats DC-WG VSIA Specified Formats M M CM Comply ?

Section 2.4.2

Deliverable Clock Constraints

Soft

Firm

Hard

Comments Mandatory (M) if the clock signal requirements need to be provided to the Hard VC.

2.4.3

2.4.4

Logic Architecture Constraints Area Constraints

DC-WG

--

--

DC-WG

CM

--

Mandatory (M) if Synthesis or Floorplanning is required. Mandatory (M) if Floorplanning is required. Mandatory (M) if Synthesis or Floorplanning is required.

2.4.5

Physical Implementation Constraints Power Constraints

DC-WG

CM

CM

--

2.4.6

DC-WG

CM

CM

--

2.4.7 2.4.8

Test ConDC-WG straints Environmental DC-WG / Operating Constraints

M M

M M

M M

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

15

VSI Alliance Deliverables Document Version 2.6.0

Table 4: VSI Alliance Specification (OCB 1 2.0) Data Deliverables Section 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 Deliverable User Guide Version Number Document Conventions Introduction Bus Operation Configuration Space Document Document Document Document Document Document Document Document Document Document Document Document M M M M M M CM M M M M M M CM M M M M M M CM If the deliverables exist, this deliverable is M. If the VC developer is producing a hard VC, this deliverable is M. Revision History Document Currently Used Formats Candidate VSIA Format OCBD VCD SOCI Comply ? Comments

Signal Definition Document

2.1.8

Core Isolation

Document

Document

CM

2.1.9 2.2 2.3 2.3.1 2.3.2 2.3.3

Glossary Implementation Specification Physical Attributes Bus Development Tools Timing Analysis

Document Document

Document Document

R R

R R

R R

VHDL, Verilog Document

VHDL, Ver- R ilog ASCII R VHDL, Ver- R ilog

R R CM

R R M If the VC developer is producing a hard VC, this deliverable is M.

Simulation Mod- VHDL, els Verilog

2.3.4

Bus Implementa- Verilog, tion Tools VHDL, C,C++ Bus Protocol Monitor Verilog, VHDL, C, C++

Verilog, VH- R DL, C,C++ Verilog, VH- CR DL, C, C++

2.3.4.1

If this deliverable is not available from another source, it is recommended for the On-Chip Bus Provider.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

16

VSI Alliance Deliverables Document Version 2.6.0

Table 4: VSI Alliance Specification (OCB 1 2.0) Data Deliverables (Continued) Section 2.3.4.2 Deliverable Currently Used Formats Candidate VSIA Format OCBD VCD CR SOCI R Comply ? Comments If this deliverable is not available from another source, it is Recommended for the On-Chip Bus Provider.

Bus Performance Verilog, Monitor VHDL, C, C++

Verilog, VH- CR DL, C, C++

2.3.5

Compliance Test Verilog, Bench VHDL, C,C++ Debug Tools

Verilog, VH- R DL, C,C++ R

--

2.3.6

--

No formats exist for these tools.

2.4 2.4.1 2.4.2

Technical Attributes General Bus Attributes Un-Cached Transaction Attributes Document Document Document Document M M M M M M

2.4.3 2.4.4 2.4.5 2.5 2.5.1 2.5.2 2.5.3 2.5.4

Cached Transac- Document tion Attributes Interrupts Document Additional Trans- Document action Attributes VC Interface User Guide Implementation Guide VC Interface Wrapper Document Document VHDL, Verilog

Document Document Document

M M M

M M M

M M M

Document Document

M M

CM CM CM CM

If VCI is present If VCI is present If VCI is present If VCI is present

VHDL, Ver- M ilog Document M

Compliance Ver- Document ification

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

17

VSI Alliance Deliverables Document Version 2.6.0

Table 5: VSI Alliance Specification Test Specification (TST 1 1.1) Data Deliverables Section Deliverable VSIA Endorsed Formats VSIA Specified Formats Soft Firm Hard Comply ?

Comments

2.1. 2.1.1. 2.1.2. 2.1.3

Test Strategy Description Test Completeness Design-ForTest (DFT) Techniques SCAN Document Document Table M M M M M M -

2.1.3.1

CM

CM

CM

Conditional based upon VC providers approach to achieve test coverage. Conditional based upon VC providers approach to achieve test coverage. Conditional based upon the requirements of the application being tested.

2.1.3.2

Logic Built-In Self Test (BIST)

Document

CM

CM

CM

2.1.3.3

Idd Quiescent Current (IDDQ Test)

Document

CM

CM

CM

2.1.3.4 2.1.3.5

VC Isolation Isolation Protocol

Document Document

M CM

M CM

M CM Conditional based upon the isolation technique chosen by the VC provider. Conditional based upon the isolation technique chosen by the VC provider. Assignments not applicable.

2.1.3.6

Test Collar

Document

CM

CM

CM

2.1.4

Test Strategy Rationale

Document

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

18

VSI Alliance Deliverables Document Version 2.6.0

Table 5: VSI Alliance Specification Test Specification (TST 1 1.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Formats Document Soft Firm Hard Comply ?

Comments Assignments not applicable.

2.1.5

Test Completeness Rationale Test Modules Target Use Test Modes Utilized

2.2. 2.2.1 2.2.2

Document Document

M CM

M CM

M CM Conditional based upon VC providers decision to make available.

2.2.3 2.2.4

Implementation Fault Coverage

Document, Table Document

M CM

M CM

M CM Not applicable to Test Modules yielding no results.

2.2.5 2.2.6

Constraints Diagnostic or Characterizatio n Information [Optional] Test Modules Rationale Test Modes

Document Document

M CR

M CR

M CR Optional additional information on makeup of Test Module. Assignments not applicable. Test Modes created for design validation and not for test purposes are excluded.

2.2.7

Document

2.3.

2.3.1

Target Use

Document

CM

CM

CM

Availability based upon VC providers willingness to disclose what may be proprietary information

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

19

VSI Alliance Deliverables Document Version 2.6.0

Table 5: VSI Alliance Specification Test Specification (TST 1 1.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Formats Document Soft Firm Hard Comply ?

Comments See 2.3.1 Comments above. See 2.3.1 Comments above. Optional additional information dependent upon Test Mode yielding a test result. Assignments not applicable. Applicable to all digital VCs except for memory oriented VCs, where algorithmic patterns are preferred.

2.3.2

Utilization

CM

CM

CM

2.3.3

Constraints

Document

CM

CM

CM

2.3.4

Diagnostic or Characterizatio n information [optional]

Document

CR

CR

CR

2.3.5

Test Mode Rationale Test vectors & Test Protocol

Document

2.4.

2.4.1.

Test Vectors & IEEE STIL Test Protocol Format Waveforms

VCD, WGL CM

CM

CM

Conditional based upon VC providers choice. Conditional based upon VC providers approach to achieve test coverage. Conditional based upon VC providers approach to achieve test coverage.

2.4.2.

Timing Diagram

CM

CM

CM

2.4.3.

Timing Specification

Parameter Table

CM

CM

CM

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

20

VSI Alliance Deliverables Document Version 2.6.0

Table 5: VSI Alliance Specification Test Specification (TST 1 1.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats VSIA Specified Formats Document Soft Firm Hard Comply ?

Comments Assignments not applicable. Assignments not applicable.

2.4.4

Test vectors & Test Protocols Rationale Waveforms and Timing Specifications Rationale

2.4.5

Document

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

21

VSI Alliance Deliverables Document Version 2.6.0

Table 6: VSI Alliance Specification (VCT 1 2.1) Data Deliverables Section Deliverable VSIA Endorsed Formats Soft Firm Hard Comply ? Comments

2.1

VC Provider Claims Functional Overview Target Applications Performance ASCII, PDF, HTML ASCII, PDF, HTML ASCII, PDF, HTML M M M

2.1.1

2.1.2

2.1.3

CM

CM

Provide for Soft & Firm if proven data from one or more implementation runs exists

2.1.4

Form Information

ASCII, PDF, HTML

2.1.5

Test Coverage ASCII, PDF, HTML

CM

CM

Provide for Soft & Firm if proven data from one or more implementation runs exists

2.1.6

List of Deliverables Features and Standards Compliance System Logic Description Functional Description Structural Diagrams Interfaces

ASCII, PDF, HTML ASCII, PDF, HTML

2.1.7

2.2

2.2.1

ASCII, PDF, HTML ASCII, PDF, HTML

2.2.2

2.2.3 2.2.3.1

System- Level ASCII, PDF, Interface HTML Logical (mapped) interfaces ASCII, PDF, HTML

2.2.3.2

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

22

VSI Alliance Deliverables Document Version 2.6.0

Table 6: VSI Alliance Specification (VCT 1 2.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats ASCII, PDF, HTML ASCII, PDF, HTML ASCII, PDF, HTML M Soft Firm Hard Comply ? Comments

2.2.4

Integration Requirements Abstract Models System/Logic Test Suite Physical Description Interfaces Timing Specifications

2.2.5

2.2.6

2.3

2.3.1 2.3.1.1

-ASCII, PDF, HTML CR

-CM M Supply for Soft and Firm if either have been repeatably implemented and consistent measurements are available (same as above)

2.3.1.2

Electrical ASCII, PDF, Characteristics HTML Integration Requirements Clock Distribution Design Constraints ASCII, PDF, HTML ASCII, PDF, HTML

CR

CM

2.3.2

2.3.2.1

N/A

Does not apply to Soft VC Only Global signal constraints apply to Soft For Soft and Firm, mandatory only for Schematic symbol library and design database format Supply for soft if data known from previous implementation; supply for Firm if hard aspects of Firm are known

2.3.2.2

CM

2.3.2.3

Design Compatibility

ASCII, PDF, HTML

CM

CM

2.3.2.4

Process Compatibility

ASCII, PDF, HTML

CR

CM

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

23

VSI Alliance Deliverables Document Version 2.6.0

Table 6: VSI Alliance Specification (VCT 1 2.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats ASCII, PDF, HTML Soft Firm Hard Comply ? Comments

2.3.2.5

Process Requirements

CR

CM

Supply for soft if data known from previous implementation; supply for Firm if hard aspects of Firm are known Supply for soft if data known from previous implementation; supply for Firm if hard aspects of Firm are known

2.3.2.6

Design Process ASCII, PDF, Sensitivities HTML

CR

CM

2.3.3

Implementation ASCII, PDF, Test Suite HTML Reference Environment Verification of ASCII, PDF, Claims HTML Tools, Flows & ASCII, PDF, Methodology HTML

2.4

2.4.1

2.4.2

CM

CM

If a Tool, Flow, and/or Methodology applies to Firm and Hard, it must be supplied If ASIC Library has been used for any type (Soft, Firm or Hard) detail must be supplied If Soft and Firm have been implemented, information must be supplied

2.4.3

ASIC Libraries ASCII, PDF, HTML

CM

CM

CM

2.4.4

Process Technology

ASCII, PDF, HTML

CM

CM

2.4.5

Naming Convention

ASCII, PDF, HTML

2.4.6

Deliverables ASCII, PDF, Documentation HTML Application Information Version History ASCII, PDF, HTML

2.5

2.5.1

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

24

VSI Alliance Deliverables Document Version 2.6.0

Table 6: VSI Alliance Specification (VCT 1 2.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats ASCII, PDF, HTML M Soft Firm Hard Comply ? Comments

2.5.2

Known Bugs

2.5.3

Application Notes Frequently Asked Questions ASCII, PDF, HTML

--

--

2.5.3.1

2.5.3.2

Design for ASCII, PDF, Different Goals HTML Related/Family ASCII, PDF, VC HTML Customization ASCII, PDF, Options HTML Example Systems Test Information Test Strategy ASCII, PDF, HTML ASCII, PDF, HTML

2.5.3.3

2.5.3.4

2.5.3.5

2.6

2.6.1

CM

CM

For Soft and Firm strategy is applicable and should be supplied if equivalent to a prior existing implementation (same as Test Strategy)

2.6.2

Test Modules

ASCII, PDF, HTML ASCII, PDF, HTML

CM

CM

2.6.3

Test Modes

2.6.4

Mixed Signal ASCII, PDF, Test Integration HTML Signal Requirements for Analog Blocks ASCII, PDF, HTML

--

--

--

2.6.4.1

N/A

N/A

CM

Not applicable to Soft or Firm and only applicable to Hard analog mixed signal VCs

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

25

VSI Alliance Deliverables Document Version 2.6.0

Table 6: VSI Alliance Specification (VCT 1 2.1) Data Deliverables (Continued) Section Deliverable VSIA Endorsed Formats ASCII, PDF, HTML Soft Firm Hard Comply ? Comments

2.6.4.2

Analog Test Requirements

N/A

N/A

CM

Not applicable to Soft or Firm and only applicable to Hard analog mixed signal VCs

2.7

Suppler Information VC Provider Contact Information Transfer Package Information ASCII, PDF, HTML M M M

2.7.1

2.7.2

ASCII, PDF, HTML

2.7.3

Standard Terms ASCII, PDF, and Conditions HTML Third Party Reference Supporting VC ASCII, PDF, Partner HTML ISV (Independent Software Vendor) ASCII, PDF, HTML

2.7.4

--

--

--

2.7.4.1

2.7.4.2

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

26

VSI Alliance Deliverables Document Version 2.6.0

Table 7: VSI Alliance Specification Interface-Layer (IPP 1 1.0) Data Deliverables Interface Abstraction Layer IP Block Design Status Soft Layer 1.0 Layer 0.x Layer 0.0 M R(1) M(2) M R(1) M (2) Firm M R(1) M Hard Document, C, C++, SDL Document, C, C++, SDL Verilog, VHDL, Document Document Document Document Commonly Used Formats VSIA Format(s)

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

27

VSI Alliance Deliverables Document Version 2.6.0

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

28

VSI Alliance Deliverables Document Version 2.6.0

3. Scope and Referenced IP


The intention of the VSIA is that all interface formats referenced in VSIA specifications must be open and available within the field of use defined by the specifications. To become an open standard format, the VSIA must determine that the interface is appropriate and the owner of the standard format must agree to open, nondiscriminatory, and preferably royalty free terms. This section addresses the deliverables that VC creators provide to VC integrators. At this time, the document does not address any issues regarding the generation (manual or automatic) of VCs. However, the deliverables created by a generator must meet the requirements of the VSIA Specification. Table 8 lists the proprietary formats referenced in the Data Deliverables Tables and the owners of the formats. Table 8: Proprietary Formats Format DC Shell DEF SPEF GDSII ITL LEF MMF NLDM TLF VCD VCI Standard WGL Description Design Compiler Scripting Language Design Exchange Format Standard Parasitic Extended Format Polygon Level Layout format Interpolated Table Lookup cell-level timing model Layout Exchange Format Motive Modeling Format Non-Linear Delay Model cell-level timing model Table Lookup Format cell-level timing model Verilog Change Dump VSI Alliance Virtual Component Interface Standard Waveform Graphical Language Owner Synopsys Cadence Cadence Cadence Mentor Graphics Cadence Viewlogic Synopsys Cadence Cadence VSI Alliance TSSI

3.1

DWG Specification Referenced IP

This section contains a copy of the Referenced IP sections of all the released specifications. The referenced IPs are listed by the Specification and Development Working Group.

3.1.1 System Level Design


To be released.

3.1.2 Manufacturing Related Test


This specification considers the following Intellectual Property: Standard Test Interface Language (STIL): 1450 Owner: IEEE/CS Status: Accredited standard

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

29

VSI Alliance Deliverables Document Version 2.6.0

VCD (Verilog Change Dump): 1364-1995 Owner: IEEE Status: Accredited standard Embedded VC Test: P1500 Owner: IEEE/CS Status: Standardization effort in progress. Anticipated in mid 2000.

3.1.3 IP Protection
To be released.

3.1.4 On Chip Busses


OCB 1 2.0 The only referenced IP in this specification are the open standard formats: Verilog: IEEE 1364-1995 VHDL: IEEE 1076-198 C, and C++ VCI Standard: VSI Alliance Virtual Component Interface Standard

3.1.5 Analog/Mixed-Signal
AMS 1 2.1 This specification references a number of data formats, including: VC Hspice: VC Hspice 1.0a Owner: Avant! Corporation Status: Licensed through Technology Contribution Agreement http://www.vsi.org VC LEF: VC LEF 5.1 Owner: Cadence Design Systems, Inc. Status: Licensed through Technology Contribution Agreement http://www.vsi.org GDSII: GDSII Stream Format 6.0.0 Owner: Cadence Design Systems, Inc. Status: Licensed through Technology Contribution Agreement http://www.vsi.org Verilog: IEEE 1364-1995 Owner: IEEE Status: Accredited standard http://standards.ieee.org/faqs/order.html VHDL: IEEE 1076-1987 Owner: IEEE Status: Accredited standard http://standards.ieee.org/faqs/order.html Verilog-AMS: Verilog-AMS Version 2.01 Owner: OVI Status: Under development (Version 1.3 is an approved standard) http://www.ovi.org/ VHDL-AMS: IEEE 1076.1-1999 Owner: IEEE Status: Accredited standard Http://standards.ieee.org/faqs/order.html

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

30

VSI Alliance Deliverables Document Version 2.6.0

Open Library API (OLA) Owner: OLA task force Status: Under Development http://www.Si2.org/ola SPEF: IEEE P1481, 1998 Owner: IEEE Status: IEEE Ballot Standard http://vhdl.org/vi/dpc/dpc-pandc/

AMS 2 1.0 Spice: VC Hspice 1.0a (Spice) Owner: Avant! Corporation Status: Licensed through VSIA Technology Contribution Agreement http://www.vsi.org GDSII: GDSII Stream Format 6.0.0 Owner: Cadence Design Systems, Inc. Status: Licensed through VSIA Technology Contribution Agreement http://www.vsi.org SPEF: IEEE P1481, 1998 Owner: IEEE Status: IEEE Ballot Standard http://www.eda.org/dpc SDF: IEEE P1497 Owner: IEEE Status: IEEE Ballot Standard http://www.eda.org/sdf VC LEF: VC LEF 5.1 Owner: Cadence Design Systems, Inc. Status: Licensed through VSIA Technology Contribution Agreement http://www.vsi.org PDEF: IEEE P1481, 1998 Owner: IEEE Status: IEEE Ballot Standard http://www.eda.org/dpc

3.1.6 Implementation/Verification
I/V 1 2.1 This specification references several data formats, including: Open Library API (OLA) Owner: OLA task force Status: under development http://www.si2.org/ola Design Constraints Working Group (DC-WG) Owner: OVI Status: under development http://www.vhdl.org/dcwg Verilog Synthesis Subset: IEEE 1364.1 Draft Standard Register Transfer Level Subset based on Verilog Hardware Description Language (the IEEE 1364.1 Draft specification is based on the OVI Verilog HDL Synthesis Subset specification) Owner: IEEE Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

31

VSI Alliance Deliverables Document Version 2.6.0

Status: IEEE Draft Standard http://www.eda.org/vlog-synth

VHDL Synthesis Subset: IEEE 1076.6 Draft Standard for VHDL Register Transfer Synthesis Owner: IEEE Status: IEEE Draft standard http://standards.ieee.org/faqs/order.html Verilog: IEEE 1364-1995 Owner: IEEE Status: Accredited standard http://standards.ieee.org/faqs/order.html VHDL: IEEE 1076-1987 Owner: IEEE Status: Accredited standard, older version http://standards.ieee.org/faqs/order.html EDIF: EDIF 2 0 0 Owner: EIA Status: Accredited standard, older version http://www.edif.org/index.html Spice: VC Hspice 1.0a Owner: Avant! Corporation Status: Licensed through VSIA Technology Contribution Agreement http://www.vsi.org SPEF: IEEE P1481, 1998 Owner: IEEE Status: IEEE Ballot Standard http://www.eda.org/dpc

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

32

VSI Alliance Deliverables Document Version 2.6.0

VC LEF: VC LEF 5.1 Owner: Cadence Design Systems, Inc. Status: Licensed through VSIA Technology Contribution Agreement http://www.vsi.org GDSII: GDSII Stream Format 6.0.0 Owner: Cadence Design Systems, Inc. Status: Licensed through VSIA Technology Contribution Agreement http://www.vsi.org

3.1.7 VC Transfer
VCT 1 2.1 This document contains no specifically referenced IP.

3.2

DWG Specification Scopes

The following sections are the Scope sections of the individual specifications. The Scope section defines the area of applicability of that specification, it may still require interpretation for each individual VC, depending on its individual characteristics. Refer to the scope sections below, or the Specification Data Sheets to determine its applicability to your particular VC.

3.2.1 System Level Design


To be released.

3.2.2 Manufacturing Related Test


TST 1 1.1 This specification covers Test Data Interchange formats and Design-For-Test (DFT) Guidelines for VC providers. Its purpose is to define the nature and format of the information transferred between the VC Provider and the VC integrator. Guidelines for VC providers are also presented, to insure successful incorporation of Virtual Components (VCs) into a system chip design using the VSIA (Virtual Socket Interface Alliance) methodology. All test related information from the VSIA Architecture Document (including section 1.5) and test guidelines from Section 3 are covered. Subsequent revisions of this document will cover the transfer of similar information between the VC integrator and the manufacturing Test Engineering function. The field of use for VSIA standard formats is defined as creating, defining, exchanging and integrating descriptions of virtual components of integrated circuits.

3.2.3 IP Protection
To be released.

3.2.4 On Chip Bus


OCB 1 2.0 This specification applies to on-chip buses and their supporting material, which could be classified as system buses or peripheral buses in accordance with the definitions in this document.

3.2.5 Analog/Mixed-Signal
AMS 1 2.1 The scope of this document is to specify deliverables, their associated design guidelines, and data formats to facilitate the test, exchange, and integration of process specific (hard) mixed-signal virtual components. These components target largely digital system chip applications. This document also provides a detailed deliverables list of models to assist the exchange, integration, and verification of process specific (hard) mixed-signal virtual components. Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

33

VSI Alliance Deliverables Document Version 2.6.0

The field of use for VSIA standard data formats is defined as creating, defining, exchanging, and integrating descriptions of virtual components (VCs) of integrated circuits. AMS 2 1.0 The scope of this document is to specify and explain deliverables, data formats, associated design guidelines, and example designs for the signal-integrity (SI) issues of both digital and analog mixed-signal virtual components (VC) in SoC design. This specification is focused on SI issues in the communication between the VC authors and integrators for the integration of Digital and Analog Mixed-Signal blocks (VC) in SoC designs, including design of the interface. It is assumed that the virtual components are provided for integration as hard blocks.

3.2.6 Implementation/Verification
I/V 1 2.1 This specification defines the VC data representation standards to support the hardware design flow from RTL design planning through final verification. This specification includes the RTL source and performance model formats needed for both hard and soft VCs, summary of the design constraints requirements, endorsement of the OVI Design Constraints Working Group (DC-WG) for the development of the design constraints standard, append API to Open Library to give Open Library API, and the endorsement of the Open Library (OLA) standard for the performance modeling standard. The specification includes the data formats that should be used for the structural netlist and a number of physical data types associated with hard VCs. The specification also includes a set of guidelines for reducing the likelihood of name-space collisions between different VCs, and between VCs and other system logic, as well as guidelines for handling any name-space collisions that do occur. The field of use for VSIA standard data formats is defined as creating, defining, exchanging, and integrating descriptions of virtual components of integrated circuits.

3.2.7 VC Transfer
VCT 2 2.0 The VCT Functional Classification scheme facilitates the search process by providing a framework for the consistent definition of values for the functional class attribute (ClassClassification). The specific choices for each name used in this classification scheme were arrived at after a careful examination of functional taxonomies from Cadence, Design & Reuse, IP Highway, RAPID, and Toshiba. There is no limitation mandate as to the use of the VCT Functional Classification. A VC can be attached to more than one functional class if necessary for complete coverage of its possible functions. The top and second levels contain an Others class for use in cases where the specific VC does not readily fit into any existing named category. As industry usage warrants, and it becomes appropriate to expand the classification scheme, new functional classes will be added to accommodate popular new functions.

3.2.8 VC Quality
To be released.

3.2.9 Hardware-dependent Software


To be released.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

34

VSI Alliance Deliverables Document Version 2.6.0

4. Endorsements
The VSIA DWGs will work with other standards organizations for the development of new or emerging standards required for implementation and verification of VCs and system chip integration. The VSIA DWG may endorse the development of select standards provided the DWG requirements are included in the development of the standard. The standard will be specified by the DWG when the standard is completed, approved by the standard organization and meets the DWG requirements. The purpose of the endorsements are to allow VC providers, system integrators and EDA developers to prepare development plans needed to support the future adoption of these emerging standards. The following outlines the DWG specification and endorsement process: Define the VSIA requirements for the integration/verification of VCs. Identify potential defacto, accredited, or emerging standards. Work with standards organization to endorse the emerging standard if defacto or accredited standards are not available or sufficient. o Encourage participation from VSIA members and industry. o Provide VSIA inputs and requirements necessary for the development of the standard. o Endorse the standard development, if the VSIA requirements are included. o Participate in the reviews of the draft standard. o Specify the standard for the VSIA specification when the standard is completed and approved, provided it meets the VSIA requirements. o Promote the use of the standard.

4.1

Design Constraints Endorsement

The I/V DWG endorses the OVI Design Constraints Working Group (DC-WG) development of a Design Constraints standard. The I/V DWG is working with the OVI DC-WG to define the group charter, scope, and requirements. The design constraint requirements are specified in Section 2.4 of the I/V 1 2.0 Specification (Soft and Hard VC Structural, Performance and Physical Modeling Specification).

4.2

Performance Modeling Endorsement

The performance modeling and library attribute data requires advanced features and capabilities to support the emerging very deep sub-micron process and design technologies. The I/V DWG endorses the development of the Open Library API (OLA) standard to provide the advanced capabilities needed to support the emerging technologies. We strongly encourage the development of the OLA standard, OLA based EDA tools, and ASIC libraries to provide the infrastructure needed for the production deployment of OLA for VC deliverables, and system chip design, and verification. Table 3 lists the criteria to define the requirements and dependencies necessary for the production deployment of OLA. They are based on when VC providers and system chip designers can effectively use OLA for VC exchange and system chip design. The criteria define the specific VSIA trigger points and target time frame for the adoption of OLA as a VSIA standard. The criteria will be monitored and the target time frame will be updated accordingly.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

35

VSI Alliance Deliverables Document Version 2.6.0

Table 9: OLA Requirements and Dependencies Criteria Technical Suitability Requirements The OLA standard must support the requirements for the Performance Models. Trigger: Standard needs to meet the VSIA requirements. The advanced process technologies will be one of the primary drivers for the adoption of OLA. Trigger: Production availability of the advanced .25 and .15 um process technologies. ASIC libraries supporting OLA is a key OLA infrastructure requirement for the VC and system chip integration. Trigger: Availability of a significant number of OLA ASIC libraries for a specific generation of process technology. Mainstream EDA tool support of OLA is also a key OLA infrastructure requirement for VC and system chip integration. Trigger: EDA tools that support a significant number of design flows. The specification of the OLA standard is required. Trigger: Completed specification that includes the VSIA requirements. A DWG sponsored pilot will be required to validate that OLA can be utilized for VC and system chip integration. Trigger: Completion of DWG sponsored pilot. Summary The OLA is an API based standard and is a combination of DCL for delay calculation and ALF for function and attribute specification. The modeling requirements for the advanced .25 and .15 um technologies will drive the need and use of OLA. It is expected the .5 and .35 um technologies will continue to use the existing formats. The initial set of production ASIC OLA libraries will be available by Q1 1999.

Process Technology

ASIC Library availability

EDA tool support

The initial set of EDA tools supporting OLA is expected to be released by the end of 1998.

Standard availability

The initial OLA draft standard is expected to be available by the end of 1998. The initial version of the standard may not include all the necessary requirements. The pilot needs to address applicability of OLA to complex IP functions, VC functions from multiple sources, integration of interconnect delay algorithm, and complex delivery and support mechanism.

DWG Sponsored Pilot

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

36

VSI Alliance Deliverables Document Version 2.6.0

A. References
A.1 Open Standards References
The following list the open standard references: IEEE Std 1076-1987, IEEE Standard VHDL Language Reference Manual. IEEE Std 1076-1987 is no longer in print and is NOT available from the IEEE. ANSI/IEEE Std 1076-1993 (Revision of IEEE Std 1076-1987), IEEE Standard VHDL Language Reference Manual. IEEE Std 1076-1993 has superseded IEEE Std 1076-1987. IEEE Std 1164-1993, IEEE Standard Multivalue Logic System for VHDL Model Interoperability (Std_logic_1164).1 IEEE Std 1164-1993 provides a portable, industry standard simulation environment for VHDL coders. IEEE Std 1364, Verilog Hardware Description Language Reference Manual. OVI Standard Delay Format (SDF) Specification, Version 2.1-3.0. OVI-CFI Standard Delay Calculation System Specification, Version 1.0. ISO/IEC 9899-1990, The Programming Language C. All IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA. ANSI publications are available from the Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA. All OVI publications are available from Open Verilog International (OVI), 15466 Los Gatos Blvd., Suite 109071, Los Gatos, CA 95032. All CFI publications are available from CFI, 4030 West Braker Lane, Suite 550, Austin, TX 78759, USA

A.2

VSIA Reference Documents

The following are VSIA reference documents: VSIA Architecture Document 1.0 System-Level Design Model Taxonomy (SLD 2 2.x) Taxonomy of Functional Verificatoin for Virtual Component Development and Integration (VER 1 1.x) All VSIA publications are available from the VSI Alliance Web site at www.vsi.org.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

37

VSI Alliance Deliverables Document Version 2.6.0

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

38

VSI Alliance Deliverables Document Version 2.6.0

B. Glossary of Terms
B.1 Acknowledgments
The VSIA acknowledges the contribution by Lockheed Martin Advanced Technology Laboratories for the basis of the underlying document RASSP VHDL Modeling Terminology and Taxonomy, Revision 2.3, June 23, 1997, which has been the source of several definitions in this glossary. The RASSP document was developed jointly under the DARPA/Tri-Services Rapid Prototyping of Application Specific Signal Processors (RASSP) program by Lockheed Martin Advanced Technology Laboratories, DARPA/Tri-Services, South Carolina Research Authority, Lockheed Sanders, Honeywell Technology Center and Georgia Institute School of Electrical & Computer Engineering.

B.2

Rationale and Purpose

Differing terminology has the potential of creating confusion within the system-chip industry. Some groups use common terms with divergent meanings, while others use different words for the same thing. Clear communication in common semantics is important to achieving the goals of the Virtual Socket Interface Alliance (VSIA). This glossary is a compilation of relevant and specific terms for VSIA members. The intent is to focus on those terms, required for the efficient authoring and integration of VCs. Many of the terms have been defined by the VSIA and are represented in the Architecture Document. Others have been borrowed from industry sources (with permission when needed). Overlap and conflict may be noted in some terms, which is appropriate at this emerging point in the VC industry and is one of the reasons for publishing this information. Contributions to the terminology family should be shared and discussed. Agreement on appropriate descriptive words and their definitions is desired. The purpose of this glossary is threefold: To make, the terminology relevant to the work of the VSIA publicly available. To provide a mechanism for refinement of relevant terminology. To enable the standardization of relevant terminology, informally and formally. Input from the Development Working Groups, for terms of unique semantic import, will continue to be added. Comments on DWG-specific terminology should be directed to the DWG chairperson.

B.3

Attribution Reference

Definitions that can be attributed to a source contain a reference of the form: [Source, Scope] where: Source is the name of the individual or organization that provided the definition. Member, when used in the Attribution, denotes a member of VSIA. Scope is one of the following: General (an industry wide term) VSIA (a VSIA specific term) DWG name (SLD, TST, IPP, OCB, AMS, I/V, VCT, Ver) and document revision (x x.x)

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

39

VSI Alliance Deliverables Document Version 2.6.0

B.4

Definition of Terms
Table 10: Definition of Terms

A/D Address Spaces Advanced Packet Model Agent Application Layer Arbitration Hiding Arbitration Latency Architecture

Analog-to-Digital (converter) A reference to the separate physical address regions such as: memory, I/O, and configuration. A packet model where request and response may have different number of cells. An entity that operates on a computer bus. This layer deals with the software components in a bus transfer, the driver, OS interface, and specific user application. Mechanism to give advance information to the arbitration logic to prevent arbitration cycles adding latency to VCI operation. The time that the master waits after having asserted request until it receives grant and the bus returns to the idle state after the previous masters transaction. In general, the structure of anything. In the context of Software Architecture, it is the configuration of all software routines and services for meeting a system objective. In the context of Hardware Architecture, it is the configuration of all physical elements for meeting a system objective. In the context of System Architecture, is the collection and relationship of the system's constituent hardware and software components. For example, a multiprocessor system architecture would include the hardware network architecture and the software architecture in the form of distributed and local operating systems, application routines, and control routines. [RASSP, SLD DWG]

Artisan Artiscan(tm) Atomic

A provider of foundation IP Software implementation of the VSIA tagging standard and reporting mechanism; available to Artisan's semiconductor partners. Defines a property on an interface action. An atomic action either completes fully or not at all. An atomic action that completes fully does so without the possibility of interruption or interference. If an atomic action does not complete fully (that is, it is abandoned) then the state of the system must be as if the action had never started. These are some classifications by which the behaviors of objects can be more specifically defined. For example, a basic transaction may be a read and an attribute on that read could be blocking. A process by which a block is designed to conform to a set of specifications. The output should be in the standard format with a pre-defined set of characteristics, which will simplify integration and verification. Also termed block creation. [VSI Alliance, VSIA] Defines timing specification of the VC. The behavioral entities that correspond to components stripped of their interface protocols are referred to as "behavioral Blocks."

Attributes

Authoring

Basic Delay Model Behavioral Blocks

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

40

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Behavioral Model A description of the function and timing of a component without describing a specific implementation. A behavioral model can exist at any level of abstraction. Abstraction depends on the precision of implementation details. For example, a behavior model can be a model that describes the bulk time and functionality of a processor that executes an abstract algorithm, or it can be a model of the processor at the less abstract instructions-set level. The precision of internal and external data values depends on the model's abstraction level. [RASSP, SLD DWG] An optional Built-in Self Test register in the header region used for control and status of built-in self-tests. An implementation of a hard, firm, or soft VC (see below) that is hidden from the designer. It is only observable as a bus functional model at the I/O ports. [Dataquest, General] A pre-implemented, reusable module of intellectual property that can be quickly inserted and verified to create a single-chip system. Also called megacells or cores. [Member, VSIA] The logic that connects one computer bus to another, allowing an agent on one bus to access an agent on the other. The basic bus transfer mechanism. A burst is comprised of an address phase and one or more data phases. Signals used to indicate to a target the type of transaction the master is requesting. The structure and interconnection of busses within a System IC. Typically the order of the busses is from the processor out. The processor bus is connected to the System or Local bus, which is connected, via a bridge to the Peripheral bus. [Member, OCB DWG] This deals with the protocols used to transfer words between two components across a bus, within the time frame of a few clock cycles. A virtual component interface between the bus interface logic and a virtual component that is independent of the specific bus protocol. [Member, OCB DWG] A grouping of one or more bytes. It contains a number of bytes that is characteristic to the natural width of the VCI implementation. It is the basic unit of information transferred across the VCI in one cycle. A structural interconnection of design objects ranging from simple logic gates to complex functions. Bus support functions supplied by the host system. The connectivity mechanism between any two components. Each channel has associated attributes along with its behavior. A channel may be specified at multiple levels of abstraction. A structural interconnection of semiconductor devices such as transistors, resistors, and capacitors. A snoop that does not result in a cache providing modified data.

BIST Register Black Box

Block

Bridge Burst Transfer Bus Commands Bus Hierarchy

Bus Transfer Level Bus Wrapper Cell

Cell Level Netlist Central Resources Channel

Circuit Level Netlist Clean Snoop

Configuration Address A set of registers used for configuration, initialization, and catastrophic

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

41

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Configuration Cycle Cores Bus cycles used for system initialization and configuration via the configuration address space. A complex, pre-designed function that is to be integrated onto a larger chip. Examples are PCI, MPEG, and DSP functions as well as 8-, 16-, and 32-bit microprocessors and microcontrollers. [Member, General] Any deviation from the ideal signal waveform propagating in an interconnect wire caused by signal transitions in other wires in the neighborhood. A datum is a primitive object which is one of the data types documented in the SLI behavioral Document Standard. Data may be transmitted through interface ports by transport objects like Messages and be acted upon by behavior objects like Protocol blocks. Specific flaws, physical, or chemical imperfections on a manufactured device. Most defects can be detected and measured by a FA group. Specific devices that do not perform as expected contain defect(s) or have design flaws. [Member, TST 1 1.0] The process of a target latching a request and completing it after the master was terminated with retry. Process of determining whether multiple levels or formats of a design match in terms of functionality. A measure that defines the percentage of success a test set has in finding simulated stuck at 0" or stuck at 1" faults for a list of nodes in a given design. It may be extended to other fault model types. A general definition of fault coverage is the percentage of all faults checked on a particular fault model. The coverage measure should be given for each model type tested. As the user defines the nodes to be evaluated (in some cases this is done by defining lists of nodes not to be used in the task), the raw number has little meaning without a full analysis of the set up. [VSI Alliance, General] Refers to classes or concepts of defect types. The most common of these is the stuck at type fault class. In the EDA and academic worlds, a fault is a software model of a defect. [VSI Alliance, VSIA] VCs that have been structurally and topologically otpimized for performance and area through floorplanning or placement using a generic technology library. The level of detail ranges from region placement of RTL sub-blocks, to relatively placed datapaths, to parameterized generators, to a fully placed netlist. Often a combination of these approaches is used to meet the design goals. Firm VCs offer a compromise between Soft VCs and Hard VCs. They are more flexible and portable than Hard VCs, yet more predictive of performance and area than Soft VCs. Firm VCs include a combination of synthesizable RTL, reference technology library, detailed floorplan, and a full or partial netlist. When a full netlist is present, it is expected that the test logic has been inserted and that the test lists will accompany the design. Firm VCs do not include routing. Protection risk is equivalent to Soft. [VSI Alliance, VSIA]

Crosstalk Datum

Defects

Delayed Transaction Equivalence Verification Fault Coverage

Faults

Firm VC

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

42

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Functional Model A model that describes the function of a system or component without describing a specific implementation. A functional model can exist at any level of abstraction. Abstraction depends on the precision of implementation details. For example, a functional model can be a model that abstractly describes the function of a signal processing algorithm, or it can be a less abstract model that describes the function of an ALU for accomplishing the algorithm. The precision of internal and external data values depends on the model's abstraction level. [RASSP, SLD DWG] Includes additional details of the internal structure so tools using the model can more accurately analyze the effect of the environment around the VC. A GDSII-Stream representation of a virtual component VCs that have been optimized for power, size, or performance and mapped to a specific technology. Examples include netlists fully placed, routed, and optimized for a specific technology library, a custom physical layout, or a combination of the two. Hard VCs are process/vendor specific and generally expressed in GDSII format. They have the advantage of being much more predictable, but consequently are less flexible and portable due to process dependencies. Hard VCs require, at a minimum, a high-level behavioral model, a test list, full physical and timing models along with the GDSII data. The ability to legally protect Hard VCs is much better because there is no requirement for RTL. [VSI Alliance, VSIA] A region of fields that uniquely identify a device and allow the device to be generically controlled. Arbitration that occurs during a previous access so that no bus cycles are consumed by arbitration, except when the bus is idle. A low latency path through which the processor may directly access devices mapped anywhere in the memory, I/O, or configuration address spaces. A design methodology supporting the concurrent development of hardware and software to achieve system functionality and performance goals. In particular, codesign often refers to design activities prior to the partitioning into Hardware and Software and the activity of design partitioning itself. [Member, SLD DWG] A process by which the software is verified against a simulated representation of the hardware prior to lab or system integration. [Mancini et al, DAC 95, p. 522, SLD DWG Refers to all verification activities for mixed hardware-software systems that occur after the explicit partitioning into hardware and software components, and which involve an explicit representation of both hardware and software elements. Coverification involves both formal verification and simulation-based techniques and methodologies. It also encompasses the verification activities that use integrated lab system prototypes. [Member, SLD DWG] Any clock period that the bus is idle. A VC that sends request packets and receives response packets. It is the agent that initiates transactions, for example, DMA. Process of verifying the functionality of a system-on-chip (SoC) design that contains one or more virtual components.

Gray Box Hard Blocks Hard VC

Header Region Hidden Arbitration Host Bus Bridge HW/SW Co-Design

HW/SW CoSimulation HW/SW CoVerification

Idle state Initiator Integration Verification

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

43

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Intellectual Property Intent Verification Interface A term encompassing all products, technology, software, and so forth that have been Process of determining whether a design fulfills a specification of its behavior. An interface to a component is the sum of all communication-both implicit and explicit-between that component and everything else. It may include not only the static types and sizes of ports, but also the definition of the entire protocol necessary to communicate with a specific instantiation of the component. The interface may define a protocol at many levels of abstraction. These levels must be consistent with each other so that the capabilities of the communication protocol observed at one level of abstraction hold at all levels of abstraction below that. An interface to a virtual component consists of a set of channels and the protocols defined on these channels. The point at which a channel connects to a component is known as a port. These are the differing levels of protocol specification that may accompany an interface description. Depending upon the type of interface, certain properties suitable for the description of each layer may be specified. Levels of abstraction on interfaces may be used for: data (for example from enumeration to bit mask) communication (for example from point-to-point to bus communication or from transaction level to messages to cells) resource (for example infinite buffer and non blocking to fixed register and blocking) time (for example data flow to serial processes to clocked) A component model that describes the operation of a component with respect to its surrounding environment. The external port-structure, functional, and timing details of the interface are provided to show how the component exchanges information with its environment. An interface model contains no details about the internal structure, function, data values, or timing other than that necessary to accurately model the external interface behavior. External data values are usually not modeled unless they represent control information. An interface model may describe interface details of a component at any level of abstraction. The term, bus functional and interface behavioral have also been used to refer to an interface model and are considered synonyms. The more general interface model name is preferred to the anachronistic term bus functional. [RASSP, SLD DWG] Refers to the test logic included with the VC or can be included within the VC by the user to facilitate test generation of vectors for the VC. [VSI Alliance, VSIA] Model interoperability designates the degree to which one model may be connected to other models, and have them function properly, with a modicum of effort. Model interoperability requires agreement in interface structure, data format, timing, protocol, and the information content/semantics of exchanged signals. Another name for pull-up resistors that are only used to sustain a signal state. See arbitration latency, master data latency, target initial latency, target subsequent latency. A mechanism for ensuring that a bus master does not extend the access latency of other masters beyond a specified value. A vertical segmentation of the process of transferring information across buses. There are four relevant levels: application layer, transaction layer, bus transfer layer, and physical layer.

Interface Abstraction Layers / Levels

Interface Model

Internal Test Logic Interoperability

Keepers Latency Latency Timer Layer

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

44

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Livelock Local Bus Manufacturing Test A condition in which two or more operations require completion of another operation before they can complete. A bus that connects between the processor and high-speed peripheral functions such as a memory controller, an off chip bus, etc. (See System Bus) [Member, OCB DWG] A term used by the Manufacturing-Related Test DWG to convey completeness. It encompasses all ATE test-related activities by VC providers, VC integrators, and semiconductor, fab/assembly/test providers. Manufacturing Test is the physical process of validating and debugging the performance and functional operation of semiconductor products. Physical testing over the manufacturing lifetime of a device includes (but is not limited to) validation, characterization, production test, and failure analysis. [VSI Alliance, General] An agent that initiates a bus transaction. The number of clocks until ready is asserted. A termination mechanism that allows a master to terminate a transaction when no target responds. A message is an atomic transport object that transfers zero or more cells or data in the same direction to or from a port.

Master Master Data Latency Master-Abort Messages

Miller Coupling Factor In the context of interconnects, the multiplier used for the capacitive coupling from neighboring wires to account for the impact on the delay because of their simultaneous switching. Model (PIN) Model (RTL) Specifies the interconnection RCs for the peripheral interconnect between the physical I/O ports and the internal gates of the VC. An RTL model describes a system in terms of registers, combinational circuitry, lowlevel buses, and control circuits, usually implemented as finite state machines. Some internal structural implementation formation is implied by the register transformations, but this information is not explicitly described. The primary purpose of RTL models is for developing and testing the internal architecture and control logic within an IC component so the design satisfies the required functionality and timing constraints of the IC. The RTL model is also used for specifying the design in a process neutral format that is retargetable to specific technologies or process lines through automatic synthesis. It is often used for the generating detailed test vectors, gathering timing measurements to increase the accuracy of more abstract models, investigating interactions with closely connected components, and it unambiguously documents the design solution. A circuit board containing the basic functions (e.g., CPU, memory, I/O, and expansion connectors) of a computer. A logical guarantee of the mutual exclusivity of the transitions of two signals. A set of signals such that exactly one of them is active at any instant. A specialized transport object consisting of a pair of packets, which are usually transferred in different directions, for example, a request packet and a response packet. A logical sequence of transactions, for example, Lock. A transport object consisting of a group of cells transferred across the VC Interface.

Motherboard Mutex One hot Operation

Packet

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

45

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Packet Chain A non-atomic specialized transport object consisting of a set of logically connected packets transferred in the same direction across a VC Interface. The chain of packets is connected because no intervening packets are allowed on the same channel. A collection of the measures of quality of a design that relates to the timely response of the system in reacting to stimuli. Measures associated with performance include response time, throughput, and utilization. A performance model may be written at any level of abstraction. In general, a performance model may describe the time required to perform simple tasks such as, memory access of a single CPU. However, in the context of VSIA, the typical abstraction level for performance models is most often at the multiprocessor network level. [RASSP, SLD DWG] A slower speed, simpler bus that is used for serial and slow speed devices. It is generally connected to the System or Local bus through a bus bridge. [Member, OCB DWG] Specifies the interconnection RCs for the peripheral interconnect between the physical I/O ports and the internal gates of the VC. One or more clocks in which a single unit of information is transferred, consisting of: An address phase (a single address transfer in one clock for a single address cycle and two clocks for a dual address cycle). A data phase (one transfer state plus zero or more wait states). A model of the physical implementation of the VC and the system chip. A physical model of a product, component, or system. The traditional prototype is a physical prototype, in comparison to a virtual prototype. See prototype, virtual prototype. [RASSP, SLD DWG] Physical verification is the process of checking the geometric design database to ensure that the physical implementation is a correct representation of the original logic design. Physical verification consists of three distinct checks: Electrical Rules Checks (ERC), Design Rules Checks (DRC) and Layout Versus Schematic Checks (LVS). The underlying enabling technology on which the object of reference is rendered functional. This can extend to the capabilities of engineering, support, and sales teams. [VCT 1 2.0] Refers to a set of signals that reside on the boundary of a VC. A port is a connectable point on the VC through which information may travel. A port may have specified attributes and constraints that can range from the direction and size of the port to the definition of the behavioral principle of the port (such as blocking-read) to the specification of the protocol in which the port performs a role[VCT 1 2.0] A method of address decoding in which a device responds to accesses only within an assigned address range. (See also subtractive decoding) Defines the power specification of the VC.

Performance Model

Peripheral Bus

Peripheral Interconnect Model (PIM) Phase 1 Phase 2 Phase 3 Physical Blocks Physical Prototype

Physical Verification

Platform

Port

Positive Decoding Power Model

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

46

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Processor Bus A bus that connects the internal components of the processor together. Typically these are the cache, instruction, and the execution units. It also has an external connection to the System or Local bus. It is proprietary and tightly coupled with the processor architecture. [Member, OCB DWG] The specification of the communications etiquette. A protocol may include the specification of the control lines and their behavior and relationship to data, the specification of the data types and their values (if necessary), communication timing, state (if implied by the communication semantics), and so on. The specification of how a set of transport objects and their data combine and cooperate to perform a higher-level task. They can be thought of as "pattern mappings" from one layer of abstraction to another. A means for checking behavior of an interface and determining if violations of defined, acceptable behavior have occurred. A preliminary working example or model of a product, component, or system. It is often abstract or lacking in some details from the final version. Two classes of prototypes are used in the design process: physical prototypes and virtual prototypes. The purpose of a prototype is for testing, exploration, demonstration, validation, and as a design aid. It is used for testing design concepts and exploring design alternatives. Prototypes are also used to demonstrate design solutions or validate design features. [RASSP, SLD DWG] A simulation in which randomly chosen address, data and control values are driven onto a bus or other circuit elements. A system in which virtual components (VCs) of a system-on-chip (SoC) design are created in off-the-shelf components, bonded-out silicon, FPGAs or in-circuit emulator systems. A programming language representation of a design in which some, but not all of the design structure is explicitly represented. Both the Verilog and VHDL languages are used for RTL modeling.

Protocol

Protocol Blocks

Protocol Checkers Prototype

Random Pattern Simulation Reconfigurable Prototyping System Register Transfer Language (RTL) Register Transfer Level Regression Testing

Techniques for running large numbers of simulations in batch mode, with minimal human intervention. Also, results are analyzed in batch mode, and fails are reported in an automatic way. A form of abort from the initiating side of the transaction. A transaction that was stopped, and is then reinitiated anew. A design object. This refers to the type of component for which a physical implementation exists that can be re-used. For example, ALU chips or macrocells that can be embedded in larger chips, etc. These designs are largely implemented in specific technologies. Limited parameterization may be possible. These design objects typically exist in technology libraries from one or more suppliers. [EDA Industry Standards Roadmap 1996 - http://www.cfi.org/roadmap/BOOK.html, General]

Retract Retry Reusable Component

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

47

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Reusable Design Object Reusable Function A design object that refers to the concept of a simulatable design specification for the design object that can be reused. The examples here might start with ALU chips or entire microprocessor designs for which a VHDL or Verilog simulation model is available. This type of reusable design object is used to enable simulation of a candidate object in a new design context or to develop a new physical technology implementation of a previously designed function. [EDA Industry Standards Roadmap 1996 - http://www.cfi.org/roadmap/BOOK.html, General] Defines the VC source description and is the primary input for the implementation and verification of the VC within a system chip design. A means for translating a test suite that operated on the RTL level to one that operates on the netlist level of a design. Techniques which use simulation results as the starting point for formal techniques. These techniques typically explore only a portion of a state space and are therefore less exhaustive than model checking.

RTL Source RTL to Netlist Test Suite Migration Semi-Formal Verification

Sequential Equivalence Formal equivalency checking techniques that do not rely on mapping of memory Checking elements in one design to another, but rather prove that designs with different numbers of, or different arrangements of, memory elements produce the same output streams given the same input streams. Normally, a set of initial states for each of the designs must be specified. Shadow Logic User defined logic (UDL) accessible only from the input/output ports of VCs. Such a VC is thought of as casting a shadow, which potentially reduces the testability of the logic in that shadow. The addition of test access to the VC ports is said to cast light on or remove the shadow. If the UDL contains internal test access points (such as scan elements, which can act as both test control and test observation points), then the shadow logic includes only the logic between the VC output ports. And the first level of test (control) access points in the UDL and the logic between the last level of test (observation) access points in the UDL and the VC input ports. Shadow logic that is partially accessible from other non-shadowed UDL through chip primary ports or test access points in the UDL is sometimes said to be partially shadowed since the ease of detecting faults on some logic nodes in the shadow logic may be unaffected because of this partial accessibility. Simple logic (such as buffers and inverters) in the interconnect between VCs is said to be trivial shadow logic and may be considered only during interconnect testing. [Member, TST 1 1.0] Synonymous to electrical wire or net. Shows how well state signals or ROM addresses have been exercised. A System Level Integration (SLI) device, also known as system-on-silicon, is a device with greater than 100k gates with at least one programmable core and on-chip memory. [Dataquest, General] The slope of a digital signal propagating in an interconnect (in voltage change per unit time). Similar to snooping, a module is said to snarf a transaction if it takes a copy of data passing by on the bus even though it did not request it.

Signal Signal Coverage System-Level Integration Slew Snarf

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

48

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Socket Test Interface Soft Core Soft VC Describes the way the VC can be individually accessed from the chip I/O for testing. [VSI Alliance, TST 1 1.0] A non-physical (i.e., not GDSII-Stream) view of a virtual component VCs that are delivered in the form of synthesizable HDL code. The advantage is the flexibility of the source code so it can be retargeted to multiple manufacturing processes. The disadvantage is the difficulty in performance prediction (such as timing, area, and power). Soft VCs typically have higher intellectual property protection risks because RTL source code is required by the integrator. [VSI Alliance, VSIA] A completely open VC. [Dataquest, General] error handling. A message broadcast mechanism used for communicating processor status and/or (optionally) logical sideband signaling between agents. A specification comprised of many datasheets or design object specificationrelated information about a reusable object. This information base is the initial access point for the library of reusable design objects. It is used to help designers determine the existence of a reusable design object that can be reused in a new design situation. Typically, a Design Object Specification would exist if, and only if, one of the reusable function or component design objects also exists. [EDA Industry Standards Roadmap 1996 - http://www.cfi.org/roadmap/BOOK.html, General] A transaction that is ended incomplete, usually to complete some other transaction, and then re-established to complete. Data in a cache-based system that is no longer valid and, therefore, must be discarded. Coverage method for showing how many times a statement in the RTL was executed. Static functional verification exploits formal mathematical techniques to verify a design without the use of verification test suites. There is no industry consensus on the verification approaches included under this term. The ability of an agent to spread assertion of qualified signals over several clocks. A representation of a component or system in terms of the interconnections of its constituent components. A structural model follows the physical hierarchy of the system. The hierarchy reflects the physical organization of a specific implementation. A structural model describes the physical structure of a specific implementation by specifying the components and their topological interconnections. These components can be described structurally, functionally, or behaviorally. Simulation of a structural model requires all models in the lowest (leaf) branches of the hierarchy to be behavioral or functional models. Therefore, the effective temporal, data value, and functional precisions depend on the leaf models. A structural model can exist at any level of abstraction. Structural precision depends on the granularity of the structural blocks. [RASSP, SLD DWG] A method of address decoding in which a device accepts all accesses not positively decoded by another agent. (See also positive decoding)

Source Code Space Special Cycle Specification

Split Transaction Stale Data Statement Coverage Static Functional Verification Stepping Structural Model

Subtractive Decoding

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

49

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Symbolic Simulation System Simulation in which some or all inputs are symbolic variables, and functions of these variables are propagated through a design. Any thing consisting of multiple parts that performs a function or set of functions. The boundaries of a system usually follow the structural implementation, but may also cross physical boundaries. For instance, The memory system xyz shares boards p,q,r,s with other systems. Systems are typically hierarchical in that a system is often composed of multiple sub-systems. To avoid ambiguity on the term system, it is recommended that the appropriate qualifier be stated before its use, such as CPU memory system, radar system, DSP system, etc. Most systems are a component of a larger system. The terms system and component can therefore be used to refer to the same item, but from different viewpoints: the former when speaking of the item and its constituent parts, and the latter when speaking of the item as a constituent of a larger system. [RASSP, SLD DWG] System Bus System Chip A bus that connects the processor and the high-speed peripheral functions such as a memory controller, an off chip bus, etc. (See Local Bus). [Member, OCB DWG] A term used to describe highly integrated devices. It is also known as system-onsilicon, system-on-a-chip, system-LSI, system-ASIC, and as a System-Level Integration (SLI) device. [Member, General] A single piece of silicon containing multiple virtual components (VCs) to perform a certain defined function. A VC that receives request packets and sends response packets. It is the agent that responds (with a positive acknowledgment by asserting) to a bus transaction initiated by a initiator, for example, memory. The number of clocks that the target takes to assert ready for the first data transfer. The number of clocks that the target takes to assert ready from the end of the previous data phase of a burst. A termination mechanism that allows a target to terminate a transaction in which a fatal error has occurred, or to which the target will never be able to respond. A transaction termination that brings bus transactions to an orderly and systematic conclusion. A model or collection of models and data files that applies stimuli to a module under test (MUT), compares the response of the MUT with an expected response, and reports any differences observed during simulation. [RASSP, General] Test coverage is needed because it has the ability to convey completeness. If a device is defined as bad for any reason (form, fit, or function), the test coverage is by definition less than complete or 100%. (Form and fit will be covered at a later time). Function has two parts. Both are defined as compliance with specifications and behavioral descriptions. Quality refers to how it complies now, and reliability refers to whether it will continue to comply over time. [VSI Alliance, TST 1 1.0] The overall system for applying stimulus to a design and monitoring the design for correct responses.

System-on-Chip (SoC) Target

Target Initial Latency Target Subsequent Latency Target-Abort Termination Test Bench

Test Coverage

Testbench

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

50

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Theorem Proving A formal verification technique in which a specification is expressed in a formal logic and proof strategies are utilized to construct a proof that a design obeys the specification.

Timing Analysis Model Defines the static timing characteristics of the VC. Timing arc Toggle Coverage Transaction Transaction Layer The input pin to output pin delay between the pins of a VC or cell. Shows which bits of the signals in the design have toggled. An address phase plus one or more data phases. Refers to point-to-point transfers between blocks or virtual components. It does not define signal names or clock-cycle protocols. Note: Also refers to Layer concept. [Member, OCB DWG] The temporal interval containing every instant within a clock cycle at which a specified signal transition may occur. A transaction is a non-atomic transport object which consists of a set of messages or packet chains across ports and along channels. Any bus clock, during a data phase, in which data is transferred. Shows whether each process has been uniquely triggered by each of the signals in its sensitivity list. A bus cycle used to prevent contention when one agent stops driving a signal and another agent begins driving it. A turnaround cycle must last one clock and is required on all signals that may be driven by more than one agent. A post-silicon process which proves (with evidence) that a design is valid physical characterization. For test purposes, the validation process is the use of special purpose test hardware to prove that the product meets the design intent (as opposed to other use of the same equipment as a manufacturing screen). [VSI Alliance, TST 1 1.0] A process by which a designer combines or reuses multiple VCs to create a large IC. Also termed Block Integration. [VSI Alliance, VSIA] The pad or point of interconnection between the VC and the system chip. Refers to a person or an entity that originates and sources the VC in the VC transfer process (also known as VC creator). [VCT 1 2.0] Entity (also known as VC Integrator) that receives a VC in the Transfer process, as the counter-part to the VC provider. [VCT 1 2.0] Process of verifying the functionality of a virtual component, i.e., unit test of that component. Logic between an existing VC and the VCI. A transport object consisting of a pair of packets that are transferred in different directions, for example, a single request-response packet pair.

Transition window Transactions Transfer State Triggering Coverage Turnaround Cycle

Validation

VC Integration VC Port VC Provider VC User VC Verification VC wrapper VCI operation

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

51

VSI Alliance Deliverables Document Version 2.6.0

Table 10: Definition of Terms (Continued) Verification A pre-silicon process normally used during the design phase for gaining confidence that the design will produce the expected (pre-defined) result. An output of verification may be translated into ATE vectors. [VSI Alliance, TST 1 1.0] Techniques for measuring the effectiveness of verification procedures on a design. Broadly divided into hardware code coverage and functional coverage metrics. A means for translating a test suite that operated on one design level (for example, gate netlist) to another level such as RTL. A block that meets the VSIA specification and is used as a component in the virtual socket design environment. Virtual Components can be of the forms: soft, firm, or hard. A pre-implemented, reusable module of intellectual property that can be quickly inserted and verified to create a single-chip system. VCs are also called megacells or cores. The VCI is the interface of a Virtual Component. It encompasses all the interface abstraction layers from the most abstract layer down to the lowest specified level. Note that the VSI OCB DWG uses this term internally in their document [11] to refer to their specific interface definitions. The general definition given here encompasses the OCB definition-that is, the OCB VCI is an instance of a VCI. A computer simulation model of a final product, component, or system. Unlike the other modeling terms that distinguish models based on their characteristics, the term virtual-prototype does not refer to any particular model characteristic. Rather, it refers to the role of the model within a design process; specifically for exploring design alternatives, demonstrating design concepts, and testing for requirement satisfaction/correctness. See prototype, physical-prototype. [RASSP, SLD DWG] The activity of configuring (constructing) and using (simulating) a computer software-based model of a product, system, or component to explore, test, demonstrate, and/or validate the design, its concept, and/or design features, alternatives, or choices. Specifically, it is the act of using the virtual-prototype model as if it were an example of the final (physical) product. See prototype, virtual prototype. [RASSP, SLD DWG] A set of proposed specifications needed to enable system-level integration on a chip using VCs resulting in rapid development of product. This enables IC design using a component-based paradigm. [VSI Alliance, VSIA] Shows how many states of a Finite State Machine were entered during simulation. A bus clock in which no transfer occurs.

Verification Metrics Verification Test Suite Migration Virtual Component (VC)

Virtual Component Interface (VCI)

Virtual Prototype

Virtual Prototyping

Virtual Socket Interface Visited State Coverage Wait

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

52

VSI Alliance Deliverables Document Version 2.6.0

C. Glossary of Acronyms
A/D; ADC AC ADC AGF ALF AMS API ASIC ATPG AVCI BAP BFM BiCMOS BIST BNF bps BVCI CAD CAN CMOS CP CSP D/A; DAC DC DEF Analog to Digital Converter Alternating current Analog-to-digital converter Annotated GDSII format OVI Advanced Library Format, http://www.eda.org/alf/ Analog Mixed Signal Application program interface Application-specific integrated circuit Automatic Test Pattern Generation Advanced Virtual Component Interface (VCI) Bias Access Point Bus Functional Model Bi-Polar Complementary Metal Oxide Silicon Built-in Self Test An acronym for Backus Normal Form (sometimes called, Backus-Naur Form) used to describe syntax in computer languages. bits per second Basic Virtual Component Interface (VCI) Computer Aided Design Controller Area Network Complementary Metal Oxide Silicon Charge Pump Control signal processor Digital to Analog Converter Direct current Design Exchange Format. This is a format from Cadence Design Systems. It is used for a description of physical design information. This includes the netlist and circuit layout. Design for Manufacturing (DFM) - refers to specific activities during the design process, which ensure the design is optimized for the fabrication process that will create the product. This is described in the Design Rules, checked by DRCs, and verified by product yield. [Member, TST 1 1.0]

DFM

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

53

VSI Alliance Deliverables Document Version 2.6.0

DFT

Design for Test (DFT) - refers to specific activities during the design process, which provide the ability to control and observe on silicon needed by test to determine the quality of the product. These activities should be described by guidelines, checked by simulation, and verified by the cost of test. [Member, TST 1 1.0] Direct Memory Access Differential Non-linearity Design Rule Check Deep Submicron Digital Signal Processor Digital Versatile Disk Development Working Group Emitter Coupled Logic Electro Magnetic Epitaxial substrate layer Extended Standard Parasitic Format first-in, first-out Finite State Machine Gigabits per second General Constraint Format Graphical Design System Giga-Hertz Geometric Image Format Global system for mobile communications Hardware Design Language Hardware-dependent Software Input/Output In-Circuit Emulator IDD Quiescent Current - This is a measurement of power supply current with the device in a static state. IDDq tests are used to increase fault coverage, improve reliability, and to screen devices for battery- or low-power applications. Institute of Electrical and Electronic Engineers Integral Non-linearity Intellectual Property Intellectual Property (Protection) Instruction Set Architecture Independent Software Vendor Interpolated Table Lookup-format

DMA DNL DRC DSM DSP DVD DWG ECL EM EPI ESPF FIFO FSM Gbps GCF GDSII GHz GIF GSM HDL HDS I/O ICE IDDQ; IDDq

IEEE INL IP IP(P) ISA ISV ITL

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

54

VSI Alliance Deliverables Document Version 2.6.0

ITRS ITU LBIST LEF LNA LPE LSB

International Technology Roadmap for Semiconductors, International Telecommunication Union Logic Built In Self-Test Layout Exchange Format Low-noise amplifier Layout Parasitic Extraction Least Significant Bit. This is used for binary representation of integers on the digital side of ADC and DAC. One LSB is the resolution, and is equal to the analog range divided by 2 to the power of N (number of bits in the digital range). Layout Versus Schematic Analog Hardware Description Language, owned by Analogy. This is not an acronym. Megabytes per second Miller Coupling Factor Million instructions per second multi-processor system-on-chip Most Significant Bit. This is used for binary representation of integers on the digital side of ADC and DAC. The MSB switches at the midpoint of the analog range. Mean-time-to-failure Non-Linear Delay Model Non-maskable interrupt. On-chip Bus Open Library API, http://www.si2.org/OLA/olaoverview.htm Open Model Forum Operational Transconductance Amplifier Over-the-hierarchy Open Verilog International, now called Accellera, Peripheral Component Interconnect, the industry-standard PCI bus. Physical Design Exchange Format Peripheral interconnect model Procedural Language Interface Phase Locked Loop Power-on self-test. A series of diagnostic routines performed when a system is powered up. Peripheral Virtual Component Interface (VCI) Piece-wise linear VP quality

LVS MAST Mbps MCF MIPS MPSOC MSB

MTF NLDM NMI OCB OLA OMF OTA OTH OVI PCI PDEF PIN PLI PLL POST PVCI PWL QTY

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

55

VSI Alliance Deliverables Document Version 2.6.0

RAM RF RMS RTL RTOS SAP SDF SI SLI SLM SoC SPICE Sps SR STIL TAP Theta J-A TLF TTM UART UDSM uP URL VC VCD VCI VC-LEF VCO VERILOG VHDL VHSIC VSI VSIA Vt WGL

Random Access Memory Radio Frequency Root mean square Register Transfer Logic Real-Time Operating System Substrate access port Standard Delay Format Signal integrity System Level Integration System Level Macro System-on-Chip Simulation Program with Integrated Circuit Emphasis Samples per second Shift Register Standard Test Interface Language Test Access Port Package Heat dissipation characteristic Timing Library Format Time-To-Market Universal Asynchronous Receiver Transmitter Ultra-deep sub-micron Micro Processor Uniform Resource Locator Virtual Component Verilog Change Dump Virtual Component Interface, an OCB-standard for communicating between a bus and a virtual component, which is independent of any specific bus or VC protocol. Virtual component library exchange format Voltage Controlled Oscillator Verilog Hardware Description Language VHSIC Hardware Description Language Very High Speed Integrated Circuits Virtual Socket Interface VSI Alliance Voltage Threshold Waveform Generation Language

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

56

VSI Alliance Deliverables Document Version 2.6.0

D. Compliance Policy
Many companies wish to establish and publicize that their products are VSIA compliant. The following policy and procedure describes how to determine VSIA compliance and provides an easy-to-use format for publicizing compliance. It can be complex to determine and show VSIA compliance, since there are many recommended formats and documents in the VSIA specifications and a wide range of requirements to cover. However, not all compliance requirements apply to all products, and users of a product will differ in their concern for each compliance issue. Furthermore, as VSIA specifications are revised and new ones are added, the list of deliverables required for full and current compliance must change. The following policy takes these complexities into consideration, and resolves them Those using VSIA compliance information need to study the VSIA specifications to understand the full meaning of the data. Notice of Copyrights and Trademarks Use of the following procedure requires reproduction and use of Table 1 of this document (herein referred to as table), the VSIA Deliverables Summary, which is copyrighted by the VSIA, and reproduction and use of the VSIA Compliance Trademark. These items may be reproduced and used only for claiming and showing specific compliance of products with VSIA specifications, and if the user abides by the following terms specified for VSIA compliance. Any company (VSIA member or non-member) that abides by these terms may use the Trademark and table free of charge. Compliance Claim A claim of VSIA compliance must be made in reference to a specific version of the table, which is maintained by the VSIA. The table includes two columns entitled Comply? and Comments. The company completes the table by including check marks as applicable in the Comply? column and short comments or references to subsequent notes, in the Comments column. A compliance claim is made by the use of the specified version of the Trademark. The Trademark includes the version designation within it, which must be the same version as that of the table used. VSIA Revisions When a VSIA specification is revised or a new one is released, the VSIA revises the Deliverables Document. The table and Trademark are revised at the same time to include the same version designation as the new Deliverables Document. Form of VSI Alliance Trademark The form of the Trademark is: VSIA [Ver] Compliant tm [Ver] is the version designation and is in the form of a single-decimal number (such as 1.0, 2.0, etc.). If the version of the Deliverables Document is 2.0, the Trademark will appear as: VSIA 2.0 Compliant tm The style of the font must be Arial (or equivalent), bold, with underline. Use of the Trademark and Table and Determining Compliance A company may claim VSIA compliance for a specific product by using the Trademark, provided that the company completes a compliance report (by hand or via the web-based VSIA Compliance System at www.vsi.org) that meets the following six terms: 1. Compliance Report a) A Compliance Report must promptly be provided to any requestor. The company should download and complete the Web resident table (www.vsi.org) in its entirety and include it in its Compliance Reports.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

57

VSI Alliance Deliverables Document Version 2.6.0

b) The Compliance Report is a document created by the company that must include a completed table. A Comments Section immediately after the table for notes concerning the marked items in the table is optional. c) ALL of the relevant mandatory items must be accurately marked with a yes, no or NA (NA meaning not applicable) in the Comply? column of the table. d) Those items that do not apply to the product should be marked NA in the Comply? column of the table. e) Relevant but non-mandatory items may also be check marked at the company's option in the Comply? column of the table. f) The company, at its option, may fill in the Comments section of the Compliance Report, describing how each required deliverable was verified to be compliant. The Comments column explanation may be expanded by reference to the subsequent Comments section. g) A company using the Trademark and table may, at its option upgrade to new versions when the VSIA revises the Deliverables Document. It is recommended that a new product claim of compliance comply with the latest version of the deliverables table. 2. Compliance pertains to individual products, not to companies. A company must supply a separate Compliance Report for each product (tool or VC) for which it claims VSIA compliance. Any report must be published or furnished promptly on request. 3. The entire table must be provided in the Compliance Report, not excerpts. The table is copyrighted and permission to reproduce it is subject to the condition that it may be reproduced only in whole. The VSIA copyright notice should also be included with the table. Product information that includes only partial compliance information or a compliance summary should include directions for obtaining the full table. 4. A company may provide more than one compliance report for a particular product. This enables the company to provide more optional information to some requestors than to others. However, each report must satisfy the VSIA requirements. 5. If an item or section is marked NA (not applicable), it means that the item does not apply to this particulartype of VC (e.g., the Analog Mixed Signal items would not apply to a digital VC, or the On Chip Bus items would not apply to an Analog Mixed Signal VC). NA may NOT be used when the item is applicable to the product, but the company cannot or does not want to supply it. 6. If an item is checked in the Comply? column, it also means that the company will provide this item in the Virtual Component data transfer package. Any company that meets all of the six requirements listed above may use the Trademark in its product literature for the product that meets the above requirements. Verification Compliance may be self-verified, by the use of tools, test cases, or services. This procedure allows universities or independent test companies to play a role in VSIA compliance, responding to industry demands.

Copyright 2000-2002 by the VSI Alliance, Inc. All Rights Reserved.

58