Vsia Test Access

VSI AllianceTM Test 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 Alliance 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 applicable, 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
VSI Alliance (TST 2 1.0)
ii
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
iii
iv
Revision History
06May99 27May99 02Jun99 Version 0.01 Version0 .02 Version 0.03 Samy Makar Samy Makar Samy Makar Wrote initial version Fixed TAM figures to reflect separate clock instead of clk/ 4, added Figure 8, added numbers to sections, minor edits 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 Restarting using P2_12 Added all sections from P2_12 Made table format changes and fixed figures Made most of the changes based on phone meeting of 08Dec99, and added an introduction Added global tristate, made changes to figures, corrected minor errors. Made corrections from feedback of task force e-mail Made changes based on discussion from 29Mar00 meeting Made changes based on DWG feedback meeting of 26Apr00 Made changes based on P1500 feedback Made changes based on participating company reviews with task force discussion Made changes based on feedback from DWG feedback on Version 0.13 (pages 7, 8, 15, 21) Converted to FrameMaker, edited Applied editors written input Applied editors written input Applied clarifications from review by Chandramouli Edit/update graphics Made formatting edits
03Nov99 17Nov99 18Nov99 10Dec99 21Dec99 27Jan00 08Mar00 11May00 04Oct00 29Mar01 11Apr01 22Apr01 26Apr01 30Apr01 04May01 11July01 12July01
Version 0.04 Version 0.05 Version 0.06 Version 0.07 Version 0.08 Version 0.09 Version 0.10 Version 0.11 Version 0.12 Version 0.13 Version 0.14 Version 1.0 Version 1.0 Version 1.0 Version 1.0 Version 1.0 Version 1.0
Samy Makar Samy Makar Samy Makar Pat Samy Samy Samy Samy Makar Samy Makar Samy Makar Samy Makar Editorial Staff Editorial Staff Editorial Staff Editorial Staff Editorial Staff Editorial Staff
vi
Contents 1. VSI Alliance Test Access Architecture. . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 2.1 2.2 3.1 3.2 4.1 4.2 4.3 4.4 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Structure of This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 VSIA Test Standards and IEEE P1500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wrapper Register. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Wrapper Cells With Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bypass Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Note. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Normal Operation Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Safe State (Isolation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . External Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Scan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Iddq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 Functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.4 BIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 11 12 14 15 16 18 18 21 21 21 21 23 23 23 24 24 24 24 24
2. Introduction VC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
3. Requirements for VC Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
4.5 4.6
5. Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
5.1 5.2 5.3 5.4
Appendix
A.1 Extest Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.1.1 Example Verilog model soc.v. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.1.2 Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
vii
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Table 8: Input Wrapper Cell With 0-Output During Shift . . . . . . . . . . . . . . . . 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 12: TCB Cell Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 13: TCB Cell Definition With Capture . . . . . . . . . . . . . . . . . . . . . . . . . 20 Table 14: Example of TCB Cell Assignments for Instructions . . . . . . . . . . . . 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 5: Wrapper Cells in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Figure 6: Examples of Input Wrapper Cell With Protection . . . . . . . . . . . . . . 16 Figure 7: Example of Wrapper With External Source . . . . . . . . . . . . . . . . . . . 17 Figure 8: Global Control of VC Tristate Outputs . . . . . . . . . . . . . . . . . . . . . . 17 Figure 9: Example Bypass Register with Anti-Skew Latch . . . . . . . . . . . . . . . 18 Figure 10: TCB Register Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Figure 11: TCB Cell Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Figure 12: TCB Cell With Capture Option . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 13: TCB Register With Capture Option . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 14: Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
viii
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 userdefined 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.
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 high-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

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.
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. Safe State (Isolation) Mode In this mode, the VC is in a safe state because it is isolated f rom 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). 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.
4. Architecture
Achieving the VC requirements described in Section 3 implies a need to break the normal functional paths on the SoC during testing time. This can be achieved by using the test wrapper register shown in Figure 1. As shown in this figure, the wrapper register is made of wrapper cells. Each of the wrapper cells is connected to one of the ports of the VC, allowing a wrapper cell to drive an input of the VC or to capture the signal on an output of the VC. In addition to the wrapper register, we also need a Test Control Block (TCB) for controlling the wrapper based on the type of test being applied. A bypass register is also included to speed up the transfer of the vectors going through the VCs. The full architecture is shown in Figure 2. Here, for simplicity, only two VCs are shown to illustrate the communication between them. Table 1 gives list of all of the ports that are required, or are optional for the wrapper. The first group of signals is required for all wrappers. The remaining signals may be required, depending on the type of test methods that are built into the VC itself. For example, VC_SI and VC_SO are required only if scan is used as a test method for the VC.
Wrapper Cell VC
SI
SO
Figure 1: Wrapper Register
Wrapped VC Wrapped VC
VC_SI_BYPASS VC_TDI_BYPASS VC_SI_BYPASS VC_TDI_BYPASS
WP_PI Func_out Func_in Wrapper Reg

MAS
WP_PI
Wrapper Reg WP_SO WP_SI
Bypass
Bypass
UDL
WP_SI
MAS
WP_SO
VC
Scan Chain VC_SO
MAS
VC
VC_SI Clocks Asyncs Scan Chain Scan Chain BIST Control
MAS
VC _S I
Scan Chain BIST Control
VC_SO
Clocks
Asyncs
Test Control Block TC_SO TC_SI Test Control Block TC_SO TCLK TC_RESET TC_SHIFT TC_UPDATE VC_SHIFT
TC_CAPTURE
Figure 2: An Architecture for Test Access Between VCs
TC_SI
Table 1: VSIA VC Ports for VCs with TCB Signal Name WP_SI WP_SO TC_SI TC_SO TCLK TC_RESET TC_SHIFT TC_UPDATE VC_SHIFT WP_CLK WP_PI VC_SI VC_SO TC_CAPTURE Functional Scan Scan Optional Required Yes Yes Yes Yes Yes Yes Yes Yes Yes Description Serial data input to wrapper register (n bits wide) Serial data output from wrapper re gister (n bits wide) Input to TCB Output from TCB Clock controlling all memory elements in TCB Resets the TCB Sets the TCB in shift mode Updates the TCB Used to shift wrapper registers or scan chains Clock-controlling memory elements of wrapper register (may be TCLK or system clock) Parallel load values for functional test Scan inputs Scan outputs Only needed if capturing status in TCB
Yes required for all VCs Scan required for VCs with scan Optional Use of signal determined by VC provider
Table 2: VSIA VC Ports for VCs with Normal VC Ports Signal Name Clocks Asyncs Func_in Clocks used to operate the VC Asynchronous signals such as resets Functional inputs to VC that are not async Description
Yes required for all VCs Scan required for VCs with scan Optional Use of signal determined by VC provider The wrapper register can be split into multiple parallel registers. Each register has one of the WP_SI bits as an input, and one of the WP_SO bits as an output. (Figure 5 shows an example with three parallel registers.) The number of parallel registers is left as a choice for the VC provider (or whoever is actually building the wrapper). Regardless of the number of parallel registers, there should also be a mode that combines all the parallel wrapper chains into a single chain. Some VCs may require direct functional tests. Such VCs will have WP_PI port that will have inputs coming directly from primary inputs of the chip. The response can still be captured in the wrapper registers.

As mentioned earlier, VC_SI and VC_SO are the inputs and outputs of the scan chains if they are used. TCLK, TC_RESET, TC_SHIFT, TC_UPDATE, and TC_CAPTURE all control the Test Control Block. Details about the Test Control Block are given later. VC_SHIFT is a special input that is used to enable shift the scan chains or the wrappers (or both) depending on the test mode. Table 2 also lists ports that are used for normal VC operation. Most of the normal pins fall into the Func_in or Func_out categories. These are normal functional inputs and outputs of the VC that will be accessed through the wrapper cells. There are also some special inputs, clocks and asyncs which will not be accessed through the wrapper because of their nature of operation. Clocks are signals that drive control inputs of memory elements. Asyncs drive asynchronous sets and resets of memory elements, or any other special controls that require accurate timing. The provider may, of course, synchronize such signals, and thus make it possible to add them to the wrapper. Control of the clocks and asyncs will be the responsibility of the integrator, and thus should be well documented by the provider. Under certain conditions (described later), a wrapper may not require a TCB. In such cases, the ports in Table 3 are needed. Table 3: VSIA VC Ports for VCs With No TCB Signal Name WP_SI WP_SO WP_SHIFTMODE WP_HOLD_IN WP_HOLD_OUT WP_BP WP_SINGLEWPMODE VC_SI VC_SO VC_BP Required Yes Yes Yes Yes Yes Yes Yes Scan Scan Scan optional Description Serial data input to wrapper register (n bits wide) Serial data output from wrapper register (n bits wide) Sets the wrapper cells into shift mode Sets the input wrapper cells in hold mode Sets the output wrapper cells in hold mode Bypasses the wrapper chains (required for a s ingle chain; can be used if bypassing all wrapper chains) Indicates that wrapper is hooked into a single chain Scans inputs Scans outputs Bypasses the scan chains
Table 4: Normal VC Ports Signal Name Clocks Asyncs Func_in Func_out Yes required for all VCs Scan required for VCs with scan Description Clocks used to operate the VC Asynchronous signals such as resets Functional inputs to the VC that are not asynchronous Functional outputs of the VC
10
4.1

Rules
WP_SI and WP_SO of the same VC shall be the same width. VC_SI and VC_SO of the same VC shall be the same width. A special mode shall be provided to make all wrappers appear as a single chain. WP_SI[0] will be the input of such a chain, and WP_SO[0] will be the output. The special single chain wrapper shall be bypassed. Scan chain inputs and outputs need not be wrapped. The Test Control Block (TCB) shall not be bypassed. VC_SHIFT shall be used to shift scan chains and wrapper registers. TCLK shall control all memory elements of TCB. The VC provider shall specify which clock will be used for the wrapper cells. If more than one clock is used, the VC provider shall specify the sequence of the clocks. (TCLK is preferred.) If the VC has async signals, sufficient information shall be provided on how and when to control them. This shall be done for all required test modes, and not just for the VC internal test modes.
4.2

Recommendations
Scan chains and wrapper chains should end with anti-skew memory elements (output on the negative edge). The anti-skew memory element should be before the output pin of the wrapper (after the mux). This is shown in Figure 9 as MAS. TCLK should be separate from the system clock. TCLK should be used for the wrapper register cells and bypass registers. VCs should have no async signals (or at least keep them to a minimum) in the functional design. All wrapper chains should be bypassed. Only the single chain mode has to be bypassed. The regular wrapper chains should be bypassed as well.
Scan chains should be of reasonable lengths. If scan chains are used, chains should be less than 500 scan elements, to avoid having very long chains that could become difficult or impossible for the integrator to have reasonably sized chains at the top level. The number of scan chains should not be more than 32, as a very large number of scan chains out of a VC complicates matters for the integrator and introduces unnecessary anti-skew elements. If there are more than 16K scan elements, the 32-chain limit should be maintained, and longer (but balanced) chains should be maintained. Note that this recommendation is intended for current designs, and although the multi-chain philosophy is expected to hold for future designs, the numbers used here may not scale.
4.3

Permissions
WP_SI (and thus WP_SO) of different VCs do not have to be the same width. VC_SI (and thus VC_SO) of different VCs do not have to be the same width. Although wrapper cells are not required for scan chains, they may be added to the design. However, proper operation should be maintained. The integrator may mix wrapper registers and scan chains to optimize overall test times. (See the dotted lines in Figure 9.) Scan chains may have different lengths. The VC provider may share functional memory elements for wrapper cells.
11
Table 5: Example of Internal Control Signals Signal Name WP_SHIFTMODE WP_HOLD_IN Signal Name WP_HOLD_OUT WP_BP WP_SAFE WP_PI_ACTIVE VC_ BP VC_SCANMODE VC_BISTMODE Required Yes Yes Required Yes Yes SafeWp Func Scan Scan BIST Description Sets the wrapper cells into shift mode Sets the input wrapper cells in hold mode Description Sets the output wrapper cells in hold mode Bypasses the wrapper chains Activates safety in wrapper cells Hooks up external sources to VC wrapper cells Bypasses scan chains; required for scan designs only Scan_mode signal, used to fix any scan violations in the VC. Optional Sets the VC into BIST mode and fixes any BIST violation problems
Yes required for all VCs Scan required for VCs with scan BIST required for VCs with BIST SafeWP required if any safety wrapper cells are used There are several control signals that are used to control the wrapper register and bypass register. These signals shall be generated by the TCB. Since these signals are internal to the wrapped VC, names and structures for generating them will not be mandated. An example of these signals are summarized in Table 5. Two important signals that will be derived from these signals are : SCAN_SHIFT = VC_SCANMODE & VC_SHIFT WP_SHIFT = WP_SHIFTMODE & VC_SHIFT
4.4
Wrapper Register
As explained earlier, the wrapper register is used to gain access to the boundaries of the VC. Even though Figur e 1 illustrates the wrapper as a single chain, this would generally not be practical because of the large bandwidth of data that is required to apply the tests to all the VCs. The bandwidth problem is addressed in Figure 2 by using an input bus called WP_SI and an output bus called WP_SO. The actual number of bits is left as a choice to the designer of the wrapper. The wrapper register consists of wrapper cells. There are two types of wrapper cells: input wrapper cells and output wrapper cells. The definition of the input wrapper cell is given in Table 6. An example implementation is shown in Figure 3. Note that while the example shows an edge-triggered memory element, using LSSD or any other clocking scheme is permitted.
12
Table 6: Input Wrapper Cell Definition Control Inputs WP_SHIFT 1 0 0 Outputs WP_HOLD_IN d 1 0 Comment SO SI SOFunc_In Control Inputs VCI SO Func_In Shifts wrappers Applies wrapper values Normal Op / Capture input to VC Outputs
SI Func_in
WP_SHIFT
WP_HOLD_IN
VC Input 1 1
WP CLK
SO
Figure 3: Example of Input Wrapper Cell Table 6 defines three basic operations: Shifting: During this operation the wrapper cell is loaded with values to be applied in a VC internal test. This operation is also used for shifting out results captured from an interconnect test. Applying: A fter values have been shifted in to the wrapper, they need to be applied to test the VC. During the application, the shift operation is stopped, so the SO remains unchanged regardless of the number of clock pulses applied. This allows holding values for multiple cycles when applying an internal test, circumventing any multiple clocking problems within VCs. Capturing: In this mode, the input wrapper cell captures values at the input of the VC (such as the interconnect). This mode is also used for normal mode. The definition of the output wrapper cell is very similar to that of the input wrapper cell. The two kinds of cells are identical except for the naming of the inputs and outputs . An example implementation is shown in Figure 4. Note that while the example shows an edge-triggered memory element, using LSSD or any other clocking scheme is permitted. Table 7: Output Wrapper Cell Definition Control Inputs WP_SHIFT 1 0 0 *VCO = VC Output Outputs WP_HOLD_OUT d 1 0 Comment SO SI SOVCO Control Inputs Func_Out SO VCO Shifts wrappers Applies wrapper values Normal Op / Capture VCO Outputs
13
SI VC Output
WP_SHIFT
WP_HOLD_OUT
Func_out 1 1
WP_CLK
SO
Figure 4: Example of Output Wrapper Cell Table 7 defines three basic operations: Shifting: During this operation the wrapper cell is loaded with values to be applied in an interconnect test. This operation is also used for shifting out results captured from a VC internal test. Applying: After values have been shifted in to the wrapper, they need to be applied to test the interconnect. During the application, the shift operation is stopped, so that S remains unchanged O regardless of the number of clock pulses applied. This allows holding values for multiple cycles when applying an interconnect test, circumventing any skew problems between VCs. Func_out has the value of the wrapper cells. Capturing: In this mode, the output wrapper cell captures values at the output of the VC. This mode is also used for normal operation.
4.4.1 Rules
The input wrapper cell shall be defined as in Table 6. The output wrapper cell shall be defined as in Table 7.
Figure 5 shows wrapper cells connected. In this figure, the wrapper cells on the left of the VC are input wrapper cells and those on the right of the VC are output wrapper cells. While the figure shows the input wrappers preceding the output wrappers, this is not an actual requirement. It is shown only for illustration.
SO SI
VC Output (VCO)
SI SO
SO
SI
SO WP_SI TCLK WP_SHIFT WP_HOLD_IN WP_HOLD_OUT WP_SO
Figure 5: Wrapper Cells in Action
Func_out
Func_in
VC Input (VCI)
14
VSI Alliance (TST 2 1.0) 4.4.2 Wrapper Cells With Protection

As the wrapper registers shift, random values are applied to VCI and Func_out. This could be a problem if the VC does not expect certain combinations of inputs, and such combinations could cause damage to the VC and the chip overall. Another problem can occur while capturing interconnect tests in the input wrapper cells. If the VC is not prepared to handle arbitrary inputs, an interconnect test can cause damage to the VC and chip. The first problem can be alleviated by filling in fixed values to the dont care outputs of the tables. The value chosen will depend on the value that is safe for the VC. For example, the table below shows a wrapper cell whose output is 0 when the wrapper register is shifting. The second problem can be fixed with protection cells. Protection cells have a mode that prevents the output from changing values. Table 8 and Table 9 show input wrapper cells with 0-protection and 1-protection respectively. During an interconnect test, for example, WP_SAFE would be set to 1, so capturing the values in input wrapper cells can cause no damage to the VC. Figure 6 shows example implementations. Note that, although the example shows an edge-triggered memory element, using LSSD or any other clocking scheme is permitted Table 8: Input Wrapper Cell With 0-Output During Shift Control Inputs WP_SHIFT 1 0 0 Outputs WP_HOLD_IN d 1 0 Comment SO SI SOFunc_In Control Inputs VCI 0 SO Func_In Shifts wrappers Applies wrapper values Normal Op / Capture input to VC Outputs
Table 9: Input Wrapper Cell Definition With 0-Protection Control Inputs WP_SAFE 1 1 1 0 0 0 Outputs WP_SHIFT 1 0 0 1 0 0 Comment WP_HOLD_IN d 1 0 d 1 0 Control Inputs SO SI SOVCO SI SOFunc_In Outputs VCI 0 0 0 SO Func_In Captures input to VC Shifts wrappers Applies wrapper values Normal Op Shifts wrappers Comment
15
Table 10: Input Wrapper Cell Definition With 1-Protection Control Inputs WP_SAFE 1 1 1 0 0 0 Outputs WP_SHIFT 1 0 0 1 0 0 Comment WP_HOLD_IN d 1 0 d 1 0 Control Inputs SO SI SOFunc_In SI SOFunc_In Outputs VCI 1 1 1 SO Func_In Captures input to VC Shifts wrappers Applies wrapper values Normal Op Shifts wrappers Comment
WP_HOLD_IN SI WP_SHIFT WP_SAFE SI WP_SHIFT
WP_HOLD_IN WP_SAFE
Func_in
VC Input
Func_in
& 1 1
+ 1 1
WP CLK
SO
WP CLK
SO
0-safe Cell
1-safe Cell
Figure 6: Examples of Input Wrapper Cell With Protection
4.4.3 Permissions
To avoid undesired inputs to the VC, the wrapper may contain protection cells as defined in Tables 9 and 10. Some VC s may not have any DFT structures and can only be tested using functional tests. Even VCs with DFT structures may also require functional tests if the DFT structures do not provide adequate coverage. For such VCs, a special wrapper may be used to allow direct access to the inputs of the wrappers. In essence, these cells have an additional data input, which can be connected to the primary input of the chip (or whatever source is used to drive the functional vectors). This input is referred to as a parallel input, because no shifting in the wrapper registers will be performed during the application of such a test. Table 11 shows the definition of such a wrapper cell. An example of a circuit is shown in Figure 7.
VC Input
16

Table 11: Input Wrapper Cell Definition With External Source Inputs WP_PI_ACTIVE 1 0 0 0 Outputs WP_SHIFT d 1 0 0 Comment WP_HOLD_I N d d 1 0 Inputs SO (TCLK^) SI SOVCO
WP_HOLD_IN SI WP_SHIFT WP_PI_ACTIVE
Outputs VCI WP_PI SO VCO
Comment
Applying external input Shifts wrapper Applies wrapper values Normal Op
Func_in
1 1
WP CLK
SO
1-safe Cell
Figure 7: Example of Wrapper With External Source If a wrapper cell has external source as well as protection, the external source operation will have precedence over protection. For protection to be active, a VC user must turn off external source operation (WP_PI_ACTIVE = 0). If a VC has bidirectional ports or tristated ports, a signal called GLOBAL_TRI_OFF will be made available by the VC provider. When this signal is active, all tristate drivers out of the VC will be turned off. (See Figure 8.) The integrator will make sure that this signal is activated at the appropriate times. It is recommended not to use any tristates or bidirectionals at the outputs of a VC.
GLOBAL_TRI_OFF
VC
Out Wrapper
&
Out Wrapper
In Wrapper
Figure 8: Global Control of VC Tristate Outputs
VC Input
17
4.5
Bypass Register
The bypass register is used to improve test time by reducing the number of clock cycles needed to get test vectors through the wrapper registers and scan chains. Data is captured on the rising edge of TCLK, and made available on the negative edge of TCLK of the next cycle to avoid clock-skew problems. This requirement can be achieved using the circuit Figure 9. Since the scan chains and wrapper registers also require anti-skew elements, they can share the anti-skew element with the bypass registers. This is shown in Figure 9. Scan Chains Wrapper Regs VC_SI WP_SI WP_CLK WP_SI_BYPASS FF WP_TDI_BYPASS WP_SO VC_SO
Figure 9: Example Bypass Register with Anti-Skew Latch
4.6
Test Control Block
The test control block manages all the control signals used by the wrapper register cells and the bypass register. It also manages control signals used for internal DFT structures such as scan or BIST. The TCB can be viewed as an instruction register, as the values shifted into the TCB determine the test performed. Under certain conditions (discussed later in this section) the TCB may be not be needed. Even though we are not mandating a particular implementation, an example implementation will be used in the following discussion, to help describe the functionality of the TCB. All rules, recommendations, and permissions apply to all implementations and not just to the one discussed here. In our example implementation, the TCB consists of a number of TCB cells. Each cell corresponds to one of the control signals of the VC. Since the contents of the TCB are control signals, the TCB needs to have a shadow register to prevent random perturbations on control signals. The number of cells in the TCB depend on the test needs for the individual VC. The definition of the TCB cell is shown in Table 12. The table shows two control signals, TC_SHIFT and TC_UPDATE. When TC_SHIFT is 1, the TCB shifts, and when TC_UPDATE is 1, TCB updates the values that were shifted in, applying them to the internals of the VC. If both TC_UPDATE and TC_SHIFT are 0, then the TCB goes in to a pause mode (as in the JTAG pause states). TC_SHIFT and TC_UPDATE should not both be 1 at the same time. Table 12: TCB Cell Definition Control Inputs TC_RESET 1 0 0 0 Outputs TC_SHIFT 1 0 0 1 Comments TC_UPDATE 0 1 0 1 Control Inputs SO (TCLK^) 0 SI SOSOOutputs DO (TCLKv) 0 DOSODOResets to functional mode TCB shifts new instructions TCB updates instructions TCB pauses Not allowed Comments
18

An implementation example of the TCB cell is shown in Figure 10. Here, two flip-flops are used to implement the TCB cell definition. The upper flip-flip is used to shift in the values, and the lower one is used for the update. The TCB cells are combined together as in Figure 11 to form the TCB. The general structure of the TCB is similar to that of any shift register with an update signal. To load instructions (such as control signals), TC_SHIFT is set to 1, and TC_UPDATE is set to 0. TCLK is pulsed as many times as needed to shift in the instruction. Once that is completed, TC_SHIFT is set to 0, and TC_UPDATE is set to 1. A single cycle of TCLK is applied. The VC is now in the appropriate test mode. The AND gates in Figure 12 are included to control shift operations of the wrapper register or the scan chains. As pointed out in the beginning of the document, VC_SHIFT is a dynamic input signal. The TCB cell corresponding the AND gate will determine if that dynamic signal is activated or not. In other words, the TCB controls the dynamic signals operation. Waveforms for extest instruction are shown in Appendix A.
&
VC_SHIFT TC_SHIFT TC_SHIFT TC_SI SI DO SO TC_SHIFT SI DO SO TC_SHIFT SI
&
DO SO
TC_SHIFT SI
DO SO
TC_SO
TC_UPDATE TCLK TC_UPDATE TC_CLK TC_RESET
TC_UPDATE TCLK
TC_UPDATE TCLK
TC_UPDATE TCLK
Figure 10: TCB Register Sample
TC_SHIFT
FF SI 1
SO
FF 1
DO
TC_UPDATE TCLK
TC_RESET
Figure 11: TCB Cell Implementation The circuit in Figure 11 shows the minimum requirements for the TCB. The TCB may also be used to capture status values to be shifted out. If this feature is used, the status bits should be clearly defined. Also, the status bit should not be expected until the test is completed. An example of where capture may be used is in BIST. A bit may be captured to indicate the status of the BIST test. The result of the test is not needed until it is completed. The definition of the TCB cell with capture is shown in Table 13, the example circuit in Figure 12. The complete circuit is shown in Figure 13. In addition to the operations described for the circuit in Figure 11, the circuit in Figure 13 has the capture feature. To capture status values, set TC_CAPTURE to 1 for one TCLK cycle, then set TC_CAPTURE to 0, and TC_SHIFT to 1. Apply as many TCLK cycles as needed.
19
Table 13: TCB Cell Definition With Capture Inputs Outputs Comment Inputs Outputs SO (TCLK^) 0 SI SODI SOComment DO (TCLKv) 0 DOSODODOResets to functional mode TCB shifts new instruction TCB updates instruction TCB captures status signals TCB pauses Inputs
TC_RESET TC_SHIFT TC_UPDATE TC_CAPTURE 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0
Note : For TC_SHIFT, TC_UPDATE, and TC_CAPTURE , only one of these can be set to 1 at any one time.
TC_SHIFT
TC_CAPTURE
SI DI
1 1
FF
SO
FF 1
DO
TC_UPDATE TCLK
TC_RESET
Figure 12: TCB Cell With Capture Option
TC_CAPTURE TC_SHIFT S TC_SI SI UPDATE UPDATE TC_CLK TC_RESET C DO SO TCLK SI UPDATE S C DO SO TCLK SI UPDATE S C DO SO TCLK SI UPDATE S C DO SO TCLK TC_SO
Figure 13: TCB Register With Capture Option
20
VSI Alliance (TST 2 1.0) 4.6.1 Rules

TC_SHIFT and TC_UPDATE shall be treated as separate signals to allow for pausing. An anti-skew memory element is required at the end of the TCB. The anti-skew memory element should not be counted as part of the size of the TCB. Reset should put the VC in normal operation (all TCB cells = 0). Not more than one of TC_SHIFT, TC_UPDATE, and TC_CAPTURE should be active in the same cycle. TCLK will be used to operate the TCB. A TCB is required if more than the minimum number of control bits are needed for the VC. If a TCB is not used, the names given in Table 12 will be used. If a TCB is used, control signals in Table 13 are internal to the VC, and thus names are not mandated (although it is recommended to use the same names). If a TCB is not used, the timing information of each of the control signals needs to be completely specified. It will be left to the integrator to connect these control signals.
4.6.2 Note
The integrator for the TCB is optional in the very simple cases. However, if any complex structure is included (such as BIST and protection wrappers), then a TCB is required. Scan is an interesting special case. Even though VC_SCANMODE will not be available for a TCB-free VC, scan can still operate using VC_SHIFT signal (required in any case, to control wrapper cells). The only catch is that the scan chains and wrapper cells will always shift together.
4.6.3 Permissions
The VC integrator may hook up TC_UPDATE to the inverse of TC_SHIFT if it is determined that no pausing is necessary. The capture of status bits in the TCB above is an optional feature. Additional instructions and control bits may be added to implement additional test functions not described in this document.
4.6.4 Recommendations
A VC should have a TCB. Avoid the use of TCB-free VCs. The TCB cells should implement individual control bits. Decoding of control bits is allowed as long as the result is deglitched. TCLK should be separate from the system clock. Avoid async signals (or keep them to a minimum) in the functional design.
21
22
5. Instructions
Section 4 describes the architecture for test access. Table 5 shows a summary of the control signals. There are many ways to generate these control signals. The recommended approach is to assign each control bit to one of the TCB cells. Even though this may result in more than a minimum number of TCB cells, it allows for maximum flexibility in control of the VC. In such an architecture, the values shifted into the TCB define an instruction that sets the VC into the appropriate test mode. Several instructions are required, which correspond directly to the VC requirements described in Section 3. Table 14 shows the TCB cell settings required for the different instructions. The rest of this section describes the different instructions in some detail. Table 14: Example of TCB Cell Assignments for Instructions WP_ WP_ WP_ WP_BP WP_ WP_ SHIFT HOLD_ HOLD_ * SINGLE SAFE MODE* IN* OUT* WP MODE* Normal 0 0 0 0 1 0 1 0 0 1 1 0 0 1 X 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1 1 1 X 1 1 WP_PI_ VC _BP VC_ ACTIVE BIST_ MODE 0 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 0 0 1 0 VC_ SCAN_ MODE 0 0 0 1 0 1 0
VC_EXT 1 EXT 1 Singlewp SCAN Func BIST Safe 1 X 1 0
*indicates required signals
5.1
Normal Operation Instruction
In normal operation, the VC operates in its functional mode. The instruction for normal operation is an all-0 instruction. This instruction can be activated by either shifting in all 0s into the TCB, or by setting TC_RESET to 1. During normal operation, it is recommended that the wrappers and bypass registers hold their values, and that TCLK is turned off.
5.2
Safe State (Isolation)
When this instruction is loaded, the VC should be in a safe state as it is not being tested. All flip-flops should have known states, and all busses should be conflict-free and not floating. Requirements for VC Testing (Section 3) describes safe state in more detail. When in safe state, all bypass registers should be activated (WP_BP = 1 and VC_SO_BP = 1). This saves test time for data that is flowing through the VC wrappers and chains. If protection wrapper cells are used, they should be in protection mode (WP_SAFE = 1).
5.3
External Test
External test is used to test the interconnect between VCs. This could be simple wires or UDL. We are really testing Func_in and Func_out in this test. For this test the following is required: VC internals should be in a safe state. VC_SO should be bypassed.
23

WP_SO should not be bypassed. VC s not involved in external test should be in safe state, and should be loaded with safe state instruction.
5.4
Internal Tests
Internal tests are tests for the VC itself. Multiple tests are permitted. During any internal test, all bypasses should be disabled. Input wrapper cells are configured to drive the VC input. WP_SHIFTMODE should be set to 1. VC_SHIFT determines whether the wrapper is shifting or holding.
5.4.1 Scan
For scan, VC_SCAN_MODE is set to 1, so that VC_SHIFT can be used to control the scan chains.
5.4.2 Iddq
VC s not under test should be in a low-power state. The pattern application depends on the type of patterns used for Iddq testing. Thus, there is no specific instruction for Iddq in the specification.
5.4.3 Functional
Functional test is very important for legacy VCs that have no DFT structures. In functional test m ode, WP_PI_ACTIVE is set to 1 to allow direct access to all the VC inputs.
5.4.4 BIST
For BIST operation, VC_BIST_MODE should be set to 1. If multiple BIST modes are designed in the VC, multiple bits may be used.
24
A. Appendix
A.1 Extest Example
In this appendix, a small example of application of extest operation is shown. The circuit contains two VCs, VC1 and VC2. (Refer to Section A.1, Example Verilog Model soc.v, below.) The VCs have two inputs and two outputs, so they have four wrapper cells each. The wrapper registers are hooked up as a single register between both VCs. This is not necessarily the best way of doing it. The most effective application depends on the actual design. The TCBs are hooked up in series to each other. The TCB consists of four bits in the order shown in Table 15. According to Table 14, the values in Table 15 are needed for extest. Table 15: Index in TCB 1 2 3 4 Name WP_SHIFTMODE WP_HOLDOUT WP_HOLDIN WP_BP Value 1 1 0 0
The TCBs of both wrappers are also connected serially, so 0011 is shifted in serially (twice in a scan chain, the last bit is shifted in first). In the waveform, this happens between times 25s and 175s. During that time, TC_SHIFT is set high and VC_SHIFT is set low, making the TCB shift while the wrappers hold their values. After the TCB shifting is complete, TC_UPDATE updates the TCB, and the scanning of the data begins. Here we only shift for four cycles, to load up the first VC. VC_SHIFT is then turned off for one cycle, causing the second VC to capture the functional input coming from the wrapper outputs of the first VC. The output is then shifted out. All the verilog code is shown on the following pages, and the waveform is shown after that.
A.1.1 Example Verilog model soc.v

module soc (TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK,TC_SO, a,b,x,y,z, WP_SI, WP_SO); input TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK; // inputs to TCB output TC_SO; // outputs from TCB // wrapper stuff input WP_SI; output WP_SO; // SOC functional inputs input a,b; // SOC functional outputs output x,y,z;
wrapped_vc VC1 (.TC_RESET(TC_RESET),.VC_SHIFT(VC_SHIFT),.TC_SHIFT(TC_SHIFT), .TC_SI(TC_SI),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK),.TC_SO(tc_so1), .Func_in({a,b}), .Func_out({p,q}), .WP_SI(WP_SI), .WP_SO(wp_so1));
25

wrapped_vc VC2 (.TC_RESET(TC_RESET),.VC_SHIFT(VC_SHIFT),.TC_SHIFT(TC_SHIFT), .TC_SI(tc_so1),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK),.TC_SO(TC_SO), .Func_in({p,q}), .Func_out({y,z}), .WP_SI(wp_so1), .WP_SO(WP_SO)); endmodule
module antiskew (SI, clk, SO); input SI, clk; output SO; reg SO; always @(negedge clk) begin SO = SI; end endmodule module bypass_reg (WP_SI,WP_CLK, VC_WP_BYPASS); input WP_SI,WP_CLK; output VC_WP_BYPASS; reg VC_WP_BYPASS; always @(posedge WP_CLK) begin VC_WP_BYPASS = WP_SI; end endmodule
module mas (WP_BP, VC_WP_BYPASS, WP_SO, WP_SO_beforeskew, WP_CLK); input WP_BP, VC_WP_BYPASS, WP_SO_beforeskew, WP_CLK; output WP_SO; wire choice; reg WP_SO; assign choice = (WP_BP) ? VC_WP_BYPASS : WP_SO_beforeskew ; always @(negedge WP_CLK) begin WP_SO = choice; end endmodule module oscillator (CLK); output CLK; reg CLK; initial begin $monitor ("%f %d\n",$time, CLK); Copyright 2000 - 2001 by the VSI Alliance, Inc. All Rights Reserved. VSIA CONFIDENTIAL LICENSED DOCUMENT 26

CLK = 0; end always begin #10 CLK = ~CLK; end endmodule module tcb(TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK,TC_SO, WP_BP, WP_HOLD_IN, WP_HOLD_OUT, WP_SHIFT); input TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK; output TC_SO, WP_BP, WP_HOLD_IN, WP_HOLD_OUT, WP_SHIFT; tcb_cell wp_shiftmode (.TC_RESET(TC_RESET),.TC_SHIFT(TC_SHIFT),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK), .SI(TC_SI), .SO(so1), .DO(WP_SHIFTMODE)); tcb_cell wp_hold_out (.TC_RESET(TC_RESET),.TC_SHIFT(TC_SHIFT),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK), .SI(so1), .SO(so2), .DO(WP_HOLD_OUT)); tcb_cell wp_hold_in (.TC_RESET(TC_RESET),.TC_SHIFT(TC_SHIFT),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK), .SI(so2), .SO(so3), .DO(WP_HOLD_IN)); tcb_cell wp_bp (.TC_RESET(TC_RESET),.TC_SHIFT(TC_SHIFT),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK), .SI(so3), .SO(so4), .DO(WP_BP)); and wp_shift(WP_SHIFT, WP_SHIFTMODE, VC_SHIFT); antiskew tc_so (.SI(so4), .clk(TCLK), .SO(TC_SO)); endmodule module wrapped_vc (TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK,TC_SO, Func_in, Func_out, WP_SI, WP_SO); input TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK; // inputs to TCB output TC_SO; // outputs from TCB // wrapper stuff input WP_SI; output WP_SO; // input wrappers input [1:0] Func_in; // output wrappers output [1:0] Func_out; wire [1:0] VCI; wire [1:0] VCO;
wrapper WRAPPER (.TC_RESET(TC_RESET),.VC_SHIFT(VC_SHIFT),.TC_SHIFT(TC_SHIFT), .TC_SI(TC_SI),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK),.TC_SO(TC_SO), Copyright 2000 - 2001 by the VSI Alliance, Inc. All Rights Reserved. VSIA CONFIDENTIAL LICENSED DOCUMENT 27

.Func_in(Func_in), .Func_out(Func_out), .WP_SI(WP_SI), .WP_SO(WP_SO), .VCI(VCI), .VCO(VCO)); // Instantiation of VC should go here endmodule module wrapper (TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK,TC_SO, Func_in, Func_out,VCI, VCO, WP_SI, WP_SO); input TC_RESET,VC_SHIFT,TC_SHIFT,TC_SI,TC_UPDATE,TCLK; // inputs to TCB output TC_SO; // outputs from TCB // wrapper stuff input WP_SI; output WP_SO; // input wrappers input [1:0] Func_in; output [1:0] VCI; // output wrappers input [1:0] VCO; output [1:0] Func_out;
tcb TCB (.TC_RESET(TC_RESET),.VC_SHIFT(VC_SHIFT),.TC_SHIFT(TC_SHIFT), .TC_SI(TC_SI),.TC_UPDATE(TC_UPDATE),.TCLK(TCLK),.TC_SO(TC_SO), .WP_BP(WP_BP), .WP_HOLD_IN(WP_HOLD_IN), .WP_HOLD_OUT(WP_HOLD_OUT), .WP_SHIFT(WP_SHIFT));
wrapper_reg WRAPPER_REG (.WP_CLK(TCLK),.WP_SHIFT(WP_SHIFT),.WP_HOLD_IN(WP_HOLD_IN),.WP_HOLD_OUT(WP_ HOLD_OUT), .Func_in(Func_in), .Func_out(Func_out), .VCI(VCI), .VCO(VCO), .WP_SI(WP_SI), .WP_SO_beforeskew(WP_SO_beforeskew)); bypass_reg bypass (.WP_SI(WP_SI), .WP_CLK(TCLK), .VC_WP_BYPASS(VC_WP_BYPASS)); mas MAS (.WP_BP(WP_BP), .VC_WP_BYPASS(VC_WP_BYPASS), .WP_SO(WP_SO), .WP_SO_beforeskew(WP_SO_beforeskew),.WP_CLK(TCLK)); endmodule module wrapper_reg (WP_CLK,WP_SHIFT,WP_HOLD_IN,WP_HOLD_OUT, Func_in, Func_out, VCI, VCO, WP_SI, WP_SO_beforeskew); input WP_CLK,WP_SHIFT,WP_HOLD_IN,WP_HOLD_OUT, WP_SI; output WP_SO_beforeskew; // input wrappers input [1:0] Func_in; output [1:0] VCI; // output wrappers Copyright 2000 - 2001 by the VSI Alliance, Inc. All Rights Reserved. VSIA CONFIDENTIAL LICENSED DOCUMENT 28

input [1:0] VCO; output [1:0] Func_out; wp_cell_in i1 (.Func_in(Func_in[0]), .WP_SHIFT(WP_SHIFT), .WP_CLK(WP_CLK), .WP_HOLD_IN(WP_HOLD_IN), .VCI(VCI[0]), .SI(WP_SI), .SO(so1)); wp_cell_in i2 (.Func_in(Func_in[1]), .WP_SHIFT(WP_SHIFT), .WP_CLK(WP_CLK), .WP_HOLD_IN(WP_HOLD_IN), .VCI(VCI[1]), .SI(so1), .SO(so2)); wp_cell_out o1 (.Func_out(Func_out[0]), .WP_SHIFT(WP_SHIFT), .WP_CLK(WP_CLK), .WP_HOLD_OUT(WP_HOLD_OUT), .VCO(VCO[0]), .SI(so2), .SO(so3)); wp_cell_out o2 (.Func_out(Func_out[1]), .WP_SHIFT(WP_SHIFT), .WP_CLK(WP_CLK), .WP_HOLD_OUT(WP_HOLD_OUT), .VCO(VCO[1]), .SI(so3), .SO(WP_SO_beforeskew)); endmodule
module tcb_cell(TC_RESET, TC_SHIFT, TC_UPDATE, TCLK, SI, SO, DO); input TC_RESET, TC_SHIFT, TC_UPDATE, TCLK, SI; output SO, DO; reg SO; reg DO; always @(TCLK) begin if (TC_RESET) SO = 0; else begin if (TCLK === 1'b1) begin if (TC_SHIFT) SO = SI; else SO = SO; end else begin if (TC_UPDATE) DO = SO; else DO = DO; end end end endmodule module wp_cell_in (Func_in,WP_SHIFT,SI, WP_HOLD_IN, WP_CLK, SO,VCI); input Func_in,WP_SHIFT,SI, WP_HOLD_IN, WP_CLK; output SO,VCI; reg SO; assign VCI = (WP_HOLD_IN) ? SO : Func_in ;
29

always @(posedge WP_CLK) begin if(WP_SHIFT) SO = SI; else if (WP_HOLD_IN == 1'b1) SO = SO; else SO = Func_in; end endmodule module wp_cell_out (Func_out,WP_SHIFT,SI, WP_HOLD_OUT, WP_CLK, SO,VCO); input VCO,WP_SHIFT,SI, WP_HOLD_OUT, WP_CLK; output SO,Func_out; reg SO; assign Func_out = (WP_HOLD_OUT) ? SO : VCO; always @(posedge WP_CLK) begin if(WP_SHIFT) SO = SI; else if (WP_HOLD_OUT == 1'b1) SO = SO; else SO = VCO; end endmodule
30
VSI Alliance (TST 2 1.0) A.1.2 Waveforms
Figure 14: Waveforms
31

Vsia Test Access

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vsia Test Access

Uploaded by

Copyright:

Available Formats

VSI AllianceTM Test Access Architecture Standard Version 1.

Manufacturing-Related Test Development Working Group

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

Manufacturing-Related Test Development Working Group

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

Contents 1. VSI Alliance Test Access Architecture. . . . . . . . . . . . . . . . . . . . . . . . . .1

3. Requirements for VC Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

1. VSI Alliance Test Access Architecture

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

Structure of This Document

VSI Alliance (TST 2 1.0)

VSIA Test Standards and IEEE P1500

VSI Alliance (TST 2 1.0)

3. Requirements for VC Testing

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

WP_PI Func_out Func_in Wrapper Reg

Wrapper Reg WP_SO WP_SI

VSI Alliance (TST 2 1.0)

Figure 2: An Architecture for Test Access Between VCs

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

SO WP_SI TCLK WP_SHIFT WP_HOLD_IN WP_HOLD_OUT WP_SO

Figure 5: Wrapper Cells in Action

VSI Alliance (TST 2 1.0) 4.4.2 Wrapper Cells With Protection

VSI Alliance (TST 2 1.0)

WP_HOLD_IN SI WP_SHIFT WP_SAFE SI WP_SHIFT

Figure 6: Examples of Input Wrapper Cell With Protection

VSI Alliance (TST 2 1.0)

Outputs VCI WP_PI SO VCO

Applying external input Shifts wrapper Applies wrapper values Normal Op

Figure 8: Global Control of VC Tristate Outputs

VSI Alliance (TST 2 1.0)

Figure 9: Example Bypass Register with Anti-Skew Latch

Test Control Block

VSI Alliance (TST 2 1.0)

TC_UPDATE TCLK TC_UPDATE TC_CLK TC_RESET

Figure 10: TCB Register Sample

VSI Alliance (TST 2 1.0)

TC_RESET TC_SHIFT TC_UPDATE TC_CAPTURE 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0

Figure 12: TCB Cell With Capture Option

Figure 13: TCB Register With Capture Option

VSI Alliance (TST 2 1.0) 4.6.1 Rules

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

VC_EXT 1 EXT 1 Singlewp SCAN Func BIST Safe 1 X 1 0

*indicates required signals

Normal Operation Instruction

Safe State (Isolation)

VSI Alliance (TST 2 1.0)

VSI Alliance (TST 2 1.0)

A.1.1 Example Verilog model soc.v