Sie sind auf Seite 1von 41

VSI Alliance TM Test Access Architecture Standard

Version 1.0

(Test 2 1.0)

Manufacturing-Related Test Development Working Group

September 2001

Access Architecture Standard Version 1.0 (Test 2 1.0) Manufacturing-Related Test Development Working Group September 2001

Copyright 2000-2001 by VSI Alliance, Inc. 401 Edgewater Place, Suite 600 Wakefield, Masschusetts 01880, USA Phone: (781) 876-8822, Fax: (781)-224-1239 http://www.vsi.org, info@vsi.org

All rights reserved. This document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without the prior written authorization of VSI Alliance.

VSI Alliance is a trademark of the VSI Alliance, Inc. All other trademarks are the property of their respective owners.

VSI Alliance (TST 2 1.0)

HOW TO OBTAIN LICENSE RIGHTS FOR THE VSI ALLIANCE DOCUMENT:

Test Access Architecture Standard Version 1.0 (TST 2 1.0)

VSI ALLIANCE (VSIA) COPYRIGHT LICENSE

The VSI Alliance is the copyright owner of the document identified above.

The VSI Alliance will make royalty-free copyright licenses for this document available to VSI Alliance Members. Non-members must pay a fee for the copyright license.

Use of the document by members and non-members of the VSI Alli- ance is subject to the terms of the license. You are not entitled to use the document unless you agree to the terms of the license (and, if ap- plicable, pay the fee). The license terms are set forth on the Web site of the VSI Alliance at http://www.vsi.org.

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 THIS LICENSE 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 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

i

VSI Alliance (TST 2 1.0)

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

ii

VSI Alliance (TST 2 1.0)

Manufacturing-Related Test Development Working Group

Company Members of the Development Working Group:

Advantest Cadence Design Systems Fujitsu Limited Hitachi Semiconductor America LSI Logic National Semiconductor Palmchip Schlumberger Technologies STMicroelectronics Synopsys

ARM ECSI Agilent Technologies LogicVision Mentor Graphics Oki Electric Industry Co. Philips Semiconductor Sonics Toshiba

Individual Member of the Development Working Group:

Prab Varma

Chairman:

Ramamurti Chandramouli

Technical Editors:

Samy Makar

Herbert Leeds

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

iii

VSI Alliance (TST 2 1.0)

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

iv

VSI Alliance (TST 2 1.0)

Revision History

06May99

Version 0.01

Samy Makar

Wrote initial version

27May99

Version0 .02

Samy Makar

Fixed TAM figures to reflect separate clock instead of clk/ 4, added Figure 8, added numbers to sections, minor edits

02Jun99

Version 0.03

Samy Makar

Renamed Section 2 to VC Requirements, changed Section 3 to VC Implementation, moved Section 3.1 to Section 3, edited based on last meeting discussion, deleted Section 3.2 and beyond to reflect only issues discussed

03Nov99

Version 0.04

Samy Makar

Restarting using P2_12

17Nov99

Version 0.05

Samy Makar

Added all sections from P2_12

18Nov99

Version 0.06

Samy Makar

Made table format changes and fixed figures

10Dec99

Version 0.07

Pat

Made most of the changes based on phone meeting of 08Dec99, and added an introduction

21Dec99

Version 0.08

Samy

Added global tristate, made changes to figures, corrected minor errors.

27Jan00

Version 0.09

Samy

Made corrections from feedback of task force e-mail

08Mar00

Version 0.10

Samy

Made changes based on discussion from 29Mar00 meeting

11May00

Version 0.11

Samy Makar

Made changes based on DWG feedback meeting of

 

26Apr00

04Oct00

Version 0.12

Samy Makar

Made changes based on P1500 feedback

29Mar01

Version 0.13

Samy Makar

Made changes based on participating company reviews with task force discussion

11Apr01

Version 0.14

Samy Makar

Made changes based on feedback from DWG feedback on Version 0.13 (pages 7, 8, 15, 21)

22Apr01

Version 1.0

Editorial Staff

Converted to FrameMaker, edited

26Apr01

Version 1.0

Editorial Staff

Applied editor’s written input

30Apr01

Version 1.0

Editorial Staff

Applied editor’s written input

04May01

Version 1.0

Editorial Staff

Applied clarifications from review by Chandramouli

11July01

Version 1.0

Editorial Staff

Edit/update graphics

12July01

Version 1.0

Editorial Staff

Made formatting edits

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

v

VSI Alliance (TST 2 1.0)

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

vi

VSI Alliance (TST 2 1.0)

Contents

1. VSI Alliance Test Access

.1

1.1

Abstract .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

2. Introduction

VC

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.3

2.1 Structure of This Document

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

2.2 VSIA Test Standards and IEEE P1500

 

4

3. Requirements for VC Testing

 

.5

3.1 Rule .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

3.2 Discussion

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

4. Architecture

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.7

4.1 Rules

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

4.2 Recommendations

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

4.3 Permissions

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

4.4 Register.

Wrapper

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

 

4.4.1

Rules .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

4.4.2

Wrapper Cells With Protection

 

15

4.4.3

Permissions .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

16

4.5 Bypass Register

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

4.6 Test Control Block

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

 

4.6.1

Rules .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.6.2

Note.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.6.3 Permissions .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.6.4 Recommendations.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

5. Instructions

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.23

5.1

Normal Operation Instruction

 

23

5.2

Safe

State

(Isolation) .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

5.3

External Test

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

5.4

Internal Tests

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

5.4.1 Scan.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

Iddq .

5.4.2 .

.

.

.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

5.4.3

Functional

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

5.4.4

BIST

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

 

Appendix

 

A.1

Extest Example

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

A.1.1

Example Verilog model

 

25

A.1.2

Waveforms

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

vii

VSI Alliance (TST 2 1.0)

List of Tables

Table 1: VSIA VC Ports for VCs with TCB

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

Table 2: VSIA VC Ports for VCs with Normal VC Ports

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 9

Table 3: VSIA VC Ports for VCs With No TCB

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

Table 4: Normal VC Ports

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

Table 5: Example of Internal Control Signals

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

Table 6: Input Wrapper Cell Definition

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

Table 7: Output Wrapper Cell Definition

Table 8: Input Wrapper Cell With 0-Output During Shift

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

15

Table 9: Input Wrapper Cell Definition With 0-Protection

.

.

.

.

.

.

.

.

.

.

.

.

15

Table 10: Input Wrapper Cell Definition With 1-Protection

.

.

.

.

.

.

.

.

.

.

.

.

16

Table 11: Input Wrapper Cell Definition With External Source

 

17

. Table 13: TCB Cell Definition With Capture

Table 12: TCB Cell Definition

. Table 14: Example of TCB Cell Assignments for Instructions

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

20

23

List of Figures

Figure 1: Wrapper Register

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

7

Figure 2: An Architecture for Test Access Between VCs

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 8

Figure 3: Example of Input Wrapper Cell

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

Figure 4: Example of Output Wrapper Cell

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

. Figure 6: Examples of Input Wrapper Cell With Protection

Figure 5: Wrapper Cells in Action

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

16

Figure 7: Example of Wrapper With External Source

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

. Figure 9: Example Bypass Register with Anti-Skew Latch

. Figure 11: TCB Cell Implementation

Figure 10: TCB Register Sample

.

Figure 8: Global Control of VC Tristate Outputs

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

18

19

19

. Figure 12: TCB Cell With Capture Option

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

Figure 13: TCB Register With Capture Option

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

Figure 14: Waveforms

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

viii

VSI Alliance (TST 2 1.0)

1. VSI Alliance Test Access Architecture

1.1

Abstract

This document describes a specification for manufacturing test access to individual virtual components (VCs), embedded in a System-on-a-Chip (SoC). Test access refers to the ability to apply test stimuli to an individual VC, and to monitor the response of the individual VC as a result of the applied test stimuli. Without a specification for test access, SoC designers and users may have difficulty accessing the individual VCs that are integrated among other application circuitry on an SoC. This makes it difficult to test not just the VCs, but the interconnect and user- defined logic between the VCs. This specification was conceived to support the use and reuse of previously generated test vectors for individual VCs. The necessary logical structures needed to support the reuse of previously generated test vectors for individual VCs are introduced and defined in this document.

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

1

VSI Alliance (TST 2 1.0)

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

2

VSI Alliance (TST 2 1.0)

2. Introduction VC

Increasing complexity as well as time-to-market pressures are forcing shorter ASIC design cycles. Million -gate ASIC designs are not feasible in such time frames using traditional gate-based designs. More and more larger designs are shifting to the use of pre-designed virtual components (VC). VCs are developed to be either soft VCs or hard VCs. Soft VCs are usually HDL (Hardware Description Language) models of complex functions that are reconfigurable and that can be targeted towards any technology. Hard VCs are models that are technology -specific implementations of various complex functions and cannot be modified.

VC-based design methodology is well suited for higher levels of integration, as well as a “system-on-silicon” concept.The designer can build the system-on-a-chip using various VCs (similar to the lower-level cells in a library) , that are connected using glue logic. The resulting densely packed SoC presents a formidable test challenge.

Test is one of the significant barriers faced in the SoC design environment. The test strategy should address the access and test of the VC after it is embedded in the chip, and the integration of such VCs with user logic and embedded memories at the chip level. The main issues include testing individual VCs, interaction between VCs, isolation of the VCs, and the glue logic.

As designers move into the high-level, structured design environment, the VCs are delivered as RTL (Register Transfer Level) models. These models, also called soft VCs, enable end users to optimize the VCs for targeted applications or as hard VCs with built-in testability. Many of the soft VCs are delivered to the end user without any testability, since most of the current design-for-test (DFT) techniques (such as scan) are not suitable for implementation at the RT level. In case of the hard VCs, the preferred DFT (design-for-test) approach is some form of scan testing that has proven effective for manufacturing test.

For soft VCs, the VC vendors provide only functional vectors that verify VC functionality. In general, these vectors are not targeted toward manufacturing test. Typically, the functional vectors do not satisfy the very high fault coverage (>95%) requirement for manufacturing test. The system integrator then creates the manufacturing test for the VC. These vectors, which are valid only at the VC I/O level, must be mapped to the chip I/O to ensure manufacturability of the system chip. This is true for hard VCs too, where scan DFT is implemented. It becomes difficult to access (control and observe) the VC I/O when it is embedded within a larger design, especially when the VC I/Os are not directly accessible from the chip I/O. The lack of common VC test interface is another issue in accessing embedded VCs from chip I/O, especially when the designer has to use VCs with scan DFT from multiple sources that may not conform to a common scan-test standard. Hence, a standard VC test access approach becomes important both for reuse and for VC interoperability. At present, there are no standards that define the interface for VC test access. Existing approaches are ad hoc and vary from design to design.

As the VC-based design environment grows, the lack of VC test access standards will definitely create a bottleneck for manufacturing h igh-quality products. Recognizing this need, the VSIA Test DWG has created this standard that can be easily adopted by both VC developers and VC integrators.

2.1 Structure of This Document

This standard defines the architecture and a set of rules and recommendations for accessing the test structures of embedded VCs.

Section 3 introduces a set of rules that specify various test modes required for testing embedded VCs. Section 4 describes the basic architecture for VC test access and the associated set of interface signals for test access. Sections 4.1, 4.2, and 4.3 specify the architecture requirement in terms of rules, recommendations and permissions. Every VC must be wrapped using a wrapper register, which is needed to access the VC I/O from an external source. Section 4.4 describes various types of input and output wrapper registers and the associated rules, recommendations, and permissions. Section 4.5 describes the bypass register required to bypass the surrounding VCs when accessing a single VC. Section 4.6 describes a Test Control Block (TCB), which manages all the test control signals that interface with the wrapped VC. This section also specifies all the rules, recommendations, and permissions associated with the TCB and the interface signals.

Section 5 summarizes the control signals associated with various test modes that are described in Section 3. Appendix A explains the implementation details for Extest operation.

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

3

VSI Alliance (TST 2 1.0)

This standard does not specify any DFT solution for use by the VC internal structure.

2.2 VSIA Test Standards and IEEE P1500

With increasing demand for multiple functionalities in next generation SoC products, including wireless telecom and consumer electronic products, designers are rapidly adopting VC-based design methodology. However, the lack of industry-wide standards for many aspects of Virtual Component/VC-based design, especially in test, poses a challenge to designers who integrate Virtual Components from multiple sources without a standard interface. The need for a set of standards becomes critical especially when these emerging design methodologies are driven by Virtual Component reuse.

Both VSIA and the IEEE P1500 Working group realized the need for test interoperability standard for embedded Virtual Components to ensure test reuse and to enable plug-and-play at the chip level. There was general agreement between the IEEE P1500 working group and the VSIA Manufacturing Test DWG on having a single standard for test interoperability. Industry demand for a timely standard has prompted VSIA to provide a simple standard that fills the need until the complete IEEE standard (wrapper and information model) is available. The VSIA test DWG worked closely with the IEEE P1500 working group to ensure that the VSIA Test Access Standard is compatible with IEEE P1500. It is the intent of the VSIA that the users of the VSIA Test Access Standard are compliant with the IEEE P1500 wrappers when this becomes a standard. VSIA will specify the 1500 standard at that point.

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

4

VSI Alliance (TST 2 1.0)

3. Requirements for VC Testing

3.1 Rule

A VC must have a minimum of four modes of operation: Normal Mode, Safe State (Isolation), External Test, and

Internal Test.

3.2 Discussion

In order to completely test an SoC, each VC requires four modes of operation. The active mode of operation of a

VC depends on the state of the control signals to the VC. In the case where an SoC contains multiple VCs, there must be a sufficient number of control signals to control the mode of operation of each VC in the SoC. The four modes of operation of a VC are as follows:

• Normal Mode – In this mode, the VC operates in its intended functional or operational mode. The Design For Testability (DFT) structures in the VC are not activated.

because it is isolated from the

surrounding logic or other VCs. Techniques for isolation are described in the isolation section of this Specification

• External Test Mode – In this mode, the VC is set up to allow testing of the interconnect wiring between it and other VCs or the User-Defined Logic (UDL) in the SoC. This implies access to the outputs of the VC (for driving the interconnects), as well as access of the inputs to the VC (to observe what travels on the interconnects to the inputs of the VC).

• Safe State (Isolation) Mode – In this mode, the VC is in a safe state

• Internal Test Mode – In this mode, the VC itself is being tested. Of course, there could be multiple tests that need to be applied to the VC, and therefore multiple modes that need to be assigned to internal test.

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

5

VSI Alliance (TST 2 1.0)

Copyright 2000 - 2001 by the VSI Alliance, Inc.

All Rights Reserved.

VSIA CONFIDENTIAL LICENSED DOCUMENT

6