TExasJTAG Primer

8/13/2019 TExasJTAG Primer

1/144

Semiconductor Group1997

Printed in U.S.A.1096AL

SSYA002D

Primer


2/144

Semiconductor Group1997

Printed in U.S.A.1096AL

SSYA002D


3/144

Primer


4/144


5/144

i

IEEE Std 1149.1(JTAG) Testability

Primer


6/144

ii Contents

IMPORTANT NOTICE

Texas Instruments (TI) reserves the right to make changes to itsproducts or to discontinue any semiconductor product or servicewithout notice, and advises its customers to obtain the latest versionof relevant information to verify, before placing orders, that theinformation being relied on is current.

TI warrants performance of its semiconductor products and relatedsoftware to the specifications applicable at the time of sale inaccordance with TIs standard warranty. Testing and other qualitycontrol techniques are utilized to the extent TI deems necessary tosupport this warranty. Specific testing of all parameters of each

device is not necessarily performed, except those mandated bygovernment requirements.

Certain applications using semiconductor products may involvepotential risks of death, personal injury, or severe property orenvironmental damage (Critical Applications).

TI SEMICONDUCTOR PRODUCTS ARE NOT DESIGNED,INTENDED, AUTHORIZED, OR WARRANTED TO BE SUITABLEFOR USE IN LIFE-SUPPORT APPLICATIONS, DEVICES ORSYSTEMS OR OTHER CRITICAL APPLICATIONS.

Inclusion of TI products in such applications is understood to be fullyat the risk of the customer. Use of TI products in such applicationsrequires the written approval of an appropriate TI officer. Questionsconcerning potential risk applications should be directed to TIthrough a local SC sales office.

In order to minimize risks associated with the customers

applications, adequate design and operating safeguards should beprovided by the customer to minimize inherent or proceduralhazards.

TI assumes no liability for applications assistance, customerproduct design, software performance, or infringement of patentsor services described herein. Nor does TI warrant or represent thatany license, either express or implied, is granted under any patentright, copyright, mask work right, or other intellectual property rightof TI covering or relating to any combination, machine, or processin which such semiconductor products or services might be or areused.

Copyright 1996, Texas Instruments Incorporated


7/144

iii

TRADEMARKS

ASSET is a trademark of ASSET InterTech Incorporated.

DEC is trademark of Digital Equipment Corporation.

Ethernet is a trademark of Xerox Corporation.

IBM is a trademark of International Business MachinesCorporation.

Microsoft is a registered trademark of Microsoft Corporation.

Scan Engine, ThunderCELL, ThunderLAN, TI, UBT, andWidebus are trademarks of Texas Instruments Incorporated.

UNIX is a registered trademark in the United States and othercountries, licensed exclusively through X/Open CompanyLimited.

SUPPORT

Device Boundary-Scan Description Language (BSDL) filesand other information regarding Texas Instruments IEEE Std1149.1/JTAG/boundary-scan products are maintained on theWorld-Wide Web at URL http://www.ti.com/sc/docs/jtag/

jtaghome.htm; or, on the main Texas Instruments home pageat URL http://www.ti.com. Search for keywords JTAGand testability.


8/144

iv Contents


9/144

v

Contents

Introduction 1-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overall Rationale for Design for Test 1-2. . . . . . . . . . . . . . . . .

Reduced Cost and Higher Quality 1-3. . . . . . . . . . . . . . . . . . .

Benefits Over Standard Test Methods 1-3. . . . . . . . . . . . . . . .

Standard Test Solutions Versus Proprietary Solutions 1-5. . .

An Industry Standard IEEE Std 1149.1-1990(JTAG) 1-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Benefits of Testability 2-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . .Traditional Testing 2-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Efficient Testing 2-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lower Cost for Testing 2-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Production Time Savings 2-2. . . . . . . . . . . . . . . . . . . . . . . . . . .

Easier Board-Level Isolation 2-2. . . . . . . . . . . . . . . . . . . . . . . .

Simple Access to Circuits 2-2. . . . . . . . . . . . . . . . . . . . . . . . . . .

Boundary-Scan Architectureand IEEE Std 1149.1 3-1. . . . . . . . . . . . . . . . . . . . . . . . . .

Boundary-Scan Overview 3-2. . . . . . . . . . . . . . . . . . . . . . . . . . .

Test Interface and Boundary-Scan Architecture 3-3. . . . . . . .

Test Access Port and Operation 3-5. . . . . . . . . . . . . . . . . . . . .

IEEE Std 1149.1 Registers 3-8. . . . . . . . . . . . . . . . . . . . . . . . . .

Instruction Register (Required) 3-8. . . . . . . . . . . . . . . . . .

Data Registers 3-9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .IEEE Std 1149.1 Required Instructions 3-12. . . . . . . . . . . . . .

BYPASSInstruction 3-12. . . . . . . . . . . . . . . . . . . . . . . . . .

SAMPLE/PRELOADInstruction 3-12. . . . . . . . . . . . . . . .

EXTESTInstruction 3-13. . . . . . . . . . . . . . . . . . . . . . . . . .

IEEE Std 1149.1 Optional Instructions 3-13. . . . . . . . . . . . . . .

INTESTInstruction 3-13. . . . . . . . . . . . . . . . . . . . . . . . . . .

RUNBISTInstruction 3-13. . . . . . . . . . . . . . . . . . . . . . . . .

CLAMPInstruction 3-13. . . . . . . . . . . . . . . . . . . . . . . . . . .

HIGHZInstruction 3-14. . . . . . . . . . . . . . . . . . . . . . . . . . . .

IDCODEInstruction 3-14. . . . . . . . . . . . . . . . . . . . . . . . . .

USERCODEInstruction 3-14. . . . . . . . . . . . . . . . . . . . . . .

Obtaining IEEE Std 1149.1-1990 3-15. . . . . . . . . . . . . . . . . . .


10/144

vi Contents

Using DFT in ASICs 4-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Design-for-Test Considerations 4-1. . . . . . . . . . . . . . . . . . . . . .

The Need for Testability 4-2. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Test-Time Cost 4-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Time to Market 4-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fault Coverage and Cost of Ownership 4-5. . . . . . . . . . . . . . .

Developing Testability Strategies 4-8. . . . . . . . . . . . . . . . . . . .

Data Formats 5-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Boundary-Scan Description Language (BSDL) 5-1. . . . . . . .

How BSDL Is Used 5-1. . . . . . . . . . . . . . . . . . . . . . . . . . . .Elements of BSDL 5-2. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Verifying BSDL Accuracy 5-4. . . . . . . . . . . . . . . . . . . . . . .

Potential BSDL Errors 5-5. . . . . . . . . . . . . . . . . . . . . . . . .

How to Receive the BSDL Specification 5-5. . . . . . . . . .

Obtaining BSDL for TI Devices 5-5. . . . . . . . . . . . . . . . . .

Hierarchical Scan Description Language (HSDL) 5-6. . . . . .

Elements of HSDL 5-6. . . . . . . . . . . . . . . . . . . . . . . . . . . .

How to Receive the HSDL Specification 5-8. . . . . . . . . .

Serial Vector Format (SVF) 5-9. . . . . . . . . . . . . . . . . . . . . . . . .

SVF Structure 5-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Default State Transitions 5-12. . . . . . . . . . . . . . . . . . . . . .

SVF Example 5-15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

How to Receive the SVF Specification 5-16. . . . . . . . . .

Suggested Design-for-Test Flow 6-1. . . . . . . . . . . . . . . . . . .Test Requirements 6-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Built-In Self-Test (BIST) Methodology 6-3. . . . . . . . . . . . . . . .

Internal Scan Test Methodology 6-3. . . . . . . . . . . . . . . . . . . . .

Design Effort 6-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IC Design Implementation 6-4. . . . . . . . . . . . . . . . . . . . . .

IC Simulation 6-6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using SVF for IC Design Validation 6-6. . . . . . . . . . . . . .

Data Passed to Board Designer 6-7. . . . . . . . . . . . . . . . .

Board Design 6-8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Constraints 6-8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Partitioned Scan Path 6-8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


11/144

vii

Board Validation/Manufacturing Test 6-9. . . . . . . . . . . . . . . . .

Summary 6-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Applications 7-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Board-Etch and Solder-Joint Testing 7-1. . . . . . . . . . . . . . . . .

Solution 7-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Detailed Description 7-2. . . . . . . . . . . . . . . . . . . . . . . . . . .

Summary 7-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Cluster Testing 7-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Solution 7-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Detailed Description 7-5. . . . . . . . . . . . . . . . . . . . . . . . . . .Summary 7-6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Board-Edge Connector Testing 7-7. . . . . . . . . . . . . . . . . . . . . .

Solution 7-7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Detailed Description 7-7. . . . . . . . . . . . . . . . . . . . . . . . . . .

Summary 7-9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ASIC Verification 7-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Solution 7-10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Detailed Description 7-10. . . . . . . . . . . . . . . . . . . . . . . . . .

Summary 7-11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Memory-Testing Techniques 7-12. . . . . . . . . . . . . . . . . . . . . . .

Solution 7-12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Summary 7-16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Backplane Multidrop Environment 7-17. . . . . . . . . . . . . . . . . .Solution 7-19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Summary 7-21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Embedded Applications 7-21. . . . . . . . . . . . . . . . . . . . . . . . . . .

Solution 7-21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Summary 7-23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Boundary-Scan Test Flow 7-24. . . . . . . . . . . . . . . . . . . . . . . . .

Solution 7-24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Summary 7-28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


12/144

viii Contents

Product Summary 8-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IEEE Std 1149.1-Compatible Components 8-1. . . . . . . . . . . .

Highlights 8-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IEEE Std 1149.1 (JTAG) Boundary-Scan Logic 8-2. . . . . . . .

Bus Interface 8-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Universal Bus Transceiver (UBT) 8-4. . . . . . . . . . . . . .

Scan Support 8-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Other Support and Learning Products 9-1. . . . . . . . . . . . .

Scan Educator 9-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Scan Board 9-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Flexibility 9-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Compatibility 9-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Supporting Documentation Included 9-3. . . . . . . . . . . . .

CD-ROM 9-3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Testability Video Tape 9-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix A Abbreviations/Acronyms A-1. . . . . . . . . . .

Appendix B Glossary B-1. . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix C References C-1. . . . . . . . . . . . . . . . . . . . . . . .

Appendix D Internet Starting Points D-1. . . . . . . . . . . . .

Index Index-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


13/144

ix

Illustrations

1-1 Chip Through System-Level Test 1-1. . . . . . . . . . . . . .

2-1 Boundary-Scan Testing Using theIEEE Std 1149.1 Bus 2-3. . . . . . . . . . . . . . . . . . . . . . . . .

3-1 Boundary-Scan Example 3-2. . . . . . . . . . . . . . . . . . . . .

3-2 Boundary-Scan Architecture 3-4. . . . . . . . . . . . . . . . . .

3-3 TAP Controller State Diagram 3-5. . . . . . . . . . . . . . . . .

3-4 TAP Control Output Interconnect Diagram 3-7. . . . . .

3-5 General Instruction Register Architecture 3-8. . . . . . .

3-6 Test Data Register Architecture 3-10. . . . . . . . . . . . . . .3-7 Conceptual View of a

Control-and-Observe BSC 3-11. . . . . . . . . . . . . . . . . . .

3-8 Device Identification Register Structure 3-11. . . . . . . .

4-1 Fault Grade Versus Development Time 4-3. . . . . . . . .

4-2 Economic Trade-Off for a Testable Design 4-4. . . . . .

4-3 Defect Level Versus Fault Coverage 4-5. . . . . . . . . . .

4-4 Motorola and Delco Study Results 4-6. . . . . . . . . . . . .

4-5 ASIC ppm Versus PCB ppm Rate 4-7. . . . . . . . . . . . . .

4-6 Cost of Ownership 4-8. . . . . . . . . . . . . . . . . . . . . . . . . . .

4-7 Testability Development Flow 4-11. . . . . . . . . . . . . . . .

5-1 Scan Path of Six ICs 5-10. . . . . . . . . . . . . . . . . . . . . . . .

6-1 Initial DFT Concerns 6-1. . . . . . . . . . . . . . . . . . . . . . . . .

6-2 Designing Testability for ASICs and Boards 6-4. . . . .

6-3 Debug and Verification of aBoundary-Scan Design 6-7. . . . . . . . . . . . . . . . . . . . . . .

7-1 Etch/Interconnect Testing 7-2. . . . . . . . . . . . . . . . . . . . .

7-2 Open-Etch Condition 7-3. . . . . . . . . . . . . . . . . . . . . . . . .

7-3 Open-Solder-Joint Condition 7-3. . . . . . . . . . . . . . . . . .

7-4 Short-to-Ground Condition 7-3. . . . . . . . . . . . . . . . . . . .

7-5 Bond-Wire Testing 7-4. . . . . . . . . . . . . . . . . . . . . . . . . . .

7-6 Cluster Testing 7-5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-7 Backplane Open-Circuit Fault 7-8. . . . . . . . . . . . . . . . .

7-8 PWB Connector Fault 7-8. . . . . . . . . . . . . . . . . . . . . . . .

7-9 Backplane Short-to-Ground Fault 7-9. . . . . . . . . . . . . .

7-10 Block Diagram of SimplifiedBoundary-Scannable RAM Interface 7-13. . . . . . . . . .

7-11 Testing Embedded RAM 7-15. . . . . . . . . . . . . . . . . . . . .


14/144

x Contents

7-12 Testing Embedded ROM 7-16. . . . . . . . . . . . . . . . . . . .

7-13 Backplane Ring Configuration 7-18. . . . . . . . . . . . . . . .

7-14 Backplane Star Configuration 7-19. . . . . . . . . . . . . . . .

7-15 Backplane With ASP-Equipped Boards 7-20. . . . . . . .

7-16 General Boundary-Scan Test 7-25. . . . . . . . . . . . . . . . .

7-17 Assembly Verification Flow 7-26. . . . . . . . . . . . . . . . . .

7-18 Automated Functional Verification andFault Detection 7-27. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-19 Interactive Verification and Fault Isolation 7-28. . . . . .

8-1 TIs Family of IEEE Std 1149.1 (JTAG)

Boundary-Scan Logic 8-2. . . . . . . . . . . . . . . . . . . . . . . .


15/144

xi

Tables

1-1 High-Technology Product Scenarios 1-3. . . . . . . . . . . . .

1-2 Time to Develop Test Programs (in Man-Months) 1-4. .

5-1 SVF TAP State Names 5-13. . . . . . . . . . . . . . . . . . . . . . .

5-2 Stable-State Path Examples 5-14. . . . . . . . . . . . . . . . . .

7-1 Access Rates of IEEE Std 1149.1 DevicesWith and Without BIST 7-14. . . . . . . . . . . . . . . . . . . . . . .

8-1 IEEE Std 1149.1 UBTs Replace50+ Bus Functions 8-5. . . . . . . . . . . . . . . . . . . . . . . . . . . .


16/144

xii Contents


17/144

1-1

Chapter 1

Introduction

Design for test(DFT), also known as design for testability, isa process that incorporates rules and techniques in thedesign of a product to make testing easier.

Structured design for test is a system methodology ratherthan a collection of discrete techniques. This methodologyimpacts all phases of a products life, from device circuitdesign through field service. Design for test is used tomanage complexity, minimize development time, and reduce

manufacturing costs.

Testing has two major aspects: control and observation. Totest any system it is necessary to put the system into aknown state, supply known input data (test data), andobserve the system to see if it performs as designed andmanufactured. If control or observation cannot be carried out,there is no way to know empirically if the system performs asit should.

During the normal product development flow, testing (it maybe known by different names) takes place at many pointsduring the process. If testing is considered at the chip designlevel, its benefits can be used at all levels of electronicassembly, from chip through system level. See Figure 1-1.

IC

Test

BoardTest

BoxTest

SystemTest

Figure 1-1. Chip Through System-Level Test


18/144

1-2 Introduction

Designers usually test various functions to validate theirdesign. Manufacturing and customer groups subject thedesign to an assortment of unique criteria to see if theconcept works in practice. Is it manufacturable? Will it standup to real-world operating conditions? Will repair be costefficient? In addition to direct testability considerations,production managers want features designed into theproduct to help them minimize scrap and manufacturingcosts. Good system-testability methodology provides anintegrative function throughout the product developmentcycle and allows materials created during an early phase ofdevelopment to be reused in later phases. Various chip

designers have used this integration feature as a tool to helpmanage the development of complex products.

Testability provides companies with a firmer grasp on theeconomic and market-window constraints due to productdevelopment. One major workstation manufacturer claimed:

Test program development would have been nearlyimpossible without scan techniques.

Chip-level test development time fell from 1 man-year toabout 20 hours.

Board-level test development time fell from multipleman-years to about a week.

Three months were cut off development time.

Overall Rationale for Design for Test

Manufacturers of state-of-the-art electronic products face aunique set of problems. Although modern circuit density, highdevice speed, surface-mount packaging, and complexboard-interconnect technology have a positive influence onstate-of-the-art electronic systems, these factors canadversely affect ability to verify correct design and operation.Increased complexity and lack of physical access to circuitrymakes for costly and time-consuming testing using traditionaltest techniques.


19/144

1-3

Reduced Cost and Higher Quality

Reacting to this complexity, with an eye on the bottom line,manufacturers may opt to perform less rigorous testing.Manufacturers who choose the less rigorous testing as anexpeditious alternative to the expense of full testing gambletheir technical credibility in the marketplace and exposethemselves to the high cost of product returns. In todaysglobal electronics marketplace, a manufacturer who deliverspoorly tested products does not remain competitive. The costfor detecting and identifying faults using traditional testmethods increases by an order of magnitude as a circuits

level of complexity increases. These increased costs anddevelopment time reduce profit margins, delay productintroduction, and reduce time-to-market windows. Anincreasing number of companies have simultaneouslyimproved their product quality and profit margins by adoptingsystem-level (integrative) design methods. Design for test isone such system-level approach.

Benefits Over Standard Test Methods

Time to market is more important than ever in the hightechnology marketplace. Companies that can produce qualityproducts with a short product development cycle-time have acompetitive advantage. Designing testability into a systemcan play an important role in introducing a newhigh-technology product with an expected five-year life cycleto market on time. Table 1-1 shows various productdevelopment time/budget scenarios and the resulting projectprofitability.

Table 1-1. High-Technology Product Scenarios

ProductA

ProductB

ProductC

To Market: on time on time 6 mos. late

Budget: on 50% over on

Available ProfitOver 5 Years:

100% 96% 66%

Source:McKinsey & Company


20/144

1-4 Introduction

Adding testability to a product increases design time andcosts, while reducing costs of design validation,manufacturing test, and system maintenance.

The system design phase of product developmentrepresents only 15 percent of a products total life-cycle cost.However, the system design phase has a 70-percent impacton a products operation and support costs over the productstotal life (source: Mitre Corporation, 1987 GovernmentMicrocircuit Applications Conference).

The majority of faults found on boards, such as solder joints(shorts and opens), components (wrong device, missingdevice, wrong orientation, wire-bond failure, and stuck pins),etch integrity, and connector faults, make up over 95 percentof failures found. A structured technique such asboundary-scan testing allows for pins-out testing to easilydetect these failures (source: Teradyne).

The additional cost of designing testability into a systemduring the system design phase can be more than offsetover the products total life.

Design cycle times have shortened significantly over theyears while test program development time has increased,necessitating that companies adopt structured or repeatablemethodologies. Table 1-2 documents the increase in testprogram development time as test requirements increase.

Table 1-2. Time to Develop Test Programs (inMan-Months)

19871980 36 months

19811983 612 months

19841986 918 months

19871990 1224 months

Source: Texas Instruments


21/144

1-5

Standard Test Solutions Versus ProprietarySolutions

Embedded test, emulation, and maintenance circuitry arewell defined and understood within the test community.Previously, the lack of standards caused these structures tobe implemented in an ad hocand proprietary manner. Sinceproprietary solutions are usually more expensive and laborintensive, the added costs further limited the use of thesetest circuits. Boundary-scan testing combined with acommon test bus interface and test protocol has thesebenefits:

Provides a standard and cost-effective solution totraditional test problems

Opens new applications

The ability to reuse previously developed test data and touse less costly test equipment means that this approachyields products that are less expensive to manufacture.

An Industry Standard IEEE Std 1149.1-1990(JTAG)

In 1985, an ad hocgroup composed of key electronicmanufacturers joined to form the Joint Test Action Group(JTAG). JTAG had over 200 members around the world,including major electronics and semiconductormanufacturers. This group met to establish a solution to theproblems of board test and to promote a solution as an

industry standard. The solution, which becameIEEE Std1149.1-1990, IEEE Standard Test Access Port andBoundary-Scan Architecture, is the basis for TexasInstruments (TI) testability products. IEEE Std 1149.1allows test instructions and data to be serially loaded into adevice and enables the subsequent test results to be seriallyread out.

Every IEEE Std 1149.1-compatible device has four additionalpins two for control and one each for input and outputserial test data. To be compatible, a component must havecertain basic test features, but IEEE Std 1149.1 allowsdesigners to add test features to meet their own uniquerequirements. The specification was adopted as an IEEEstandard in February 1990.


22/144

1-6 Introduction


23/144

2-1

Chapter 2

Benefits of Testability

This chapter explains how designing testability into deviceseliminates problems associated with traditional testing andimproves quality and efficiency.

Traditional TestingTraditional board-level and device-level testing consumes agreat deal of time and requires special hardware andcomplex automatic test equipment (ATE) for each type of

board or device. This results in increased costs anddevelopment time. In addition, extensive testing is necessaryfor the evermore stringent reliability standards andperformance standards in the defense, aerospace,automotive, computer, and communications industries.These extensive tests can delay the market introduction ofproducts, disrupt just-in-time (JIT) manufacturing flows, andlimit the productivity of standard ATE operations. Thiscreates numerous problems because time to market is moreimportant than ever in the high-technology marketplace.Companies that produce quality products with a shortproduct-development cycle time have a competitiveadvantage.

Efficient TestingAn innovative approach to the problems inherent withtraditional testing is to incorporate design-for-test techniques

that allow embedded testing to be performed. For example,data can be scanned in to stimulate internal system nodeswhile the component or circuit is embedded within thesystem. During the same scan, the previous condition ofeach node is scanned out. This saves test time and reducesthe number of test vectors needed.

Lower Cost for TestingThe additional cost of designing testability into a systemduring the design phase is more than offset over theproducts total life. This is accomplished by reducing the testprogram development time, minimizing fixture complexity,and allowing for the use of lower-cost ATE solutions. Anothercost benefit is the economy of scale gained by having astandard test approach that spans design, test, manufacture,field repairs, and maintenance.


24/144

2-2 Benefits of Testability

Production Time SavingsBoard-level boundary-scan testing is easily implementedusing TIs line of IEEE Std 1149.1 testability devices, suchas:

Widebusand octal bus interfaces

Scan-support devices

ASIC and DSP

These IEEE Std 1149.1-compliant devices are included inboard design with little modification to existing circuitry.Embedded testability greatly reduces the need for other test

points on the board, and offers these advantages:Greatly simplified test fixtures

Reduced fixture construction time

Sophisticated built-in test and debug operations

Many ICs or boards can be tested together using the serialIEEE Std 1149.1 test bus under the control of boundary-scantest software.

Easier Board-Level IsolationFault isolation on a printed circuit board can be greatlyimproved by electronically isolating suspect areas usingboundary-scannable devices. The IEEE Std 1149.1 test buscontrols boundary-scannable devices to place them inEXTESTfor pins-out testing. This effectively partitions orisolates circuitry for separate testing. Partitioning a systemusing IEEE Std 1149.1-compliant devices reduces the

number of patterns required for testing each circuit area. SeeFigure 2-1 for an example of a design than can bepartitioned.

Simple Access to CircuitsHighly integrated, modern, multilayer systems or lCs withfine-pitch pins are virtually impossible to access usingmanual probes or ATE. Some boards require extensivefixturing or redesign before they can be tested effectively.TIs testability devices with boundary-scan architectureeliminate physical access problems. These parts provide thedesigner with testability for the most complex andhard-to-access circuits, and add controllability of test circuits.In addition, a designer can easily observe and controlinternal device functions.


25/144

2-3

BCT8244

BCT8244

LVTH18245

LVTH18504

LVTH18502

ABTH18504

TDI

TDI

TDO

TDO

TDI

TDO

Buffer

DataData

Buffer

Microprocessor

Memory

Array

EdgeConnector

Parallel Data In/Out

UBT

UBT

Address

Control

UBT

TCK

TMS

TDO

TDI

Logic

IEEE Std 1149.1Bus

(latch)(buffer)

(xcvr)

Figure 2-1. Boundary-Scan Testing Using the IEEE Std1149.1 Bus


26/144

2-4 Benefits of Testability


27/144

3-1

Chapter 3

Boundary-Scan Architecture

and IEEE Std 1149.1

Boundary scan is a special type of scan path with a registeradded at every I/O pin on a device. Although this requiresthe addition of a special test latch on some pins, thetechnique offers several important benefits. The mostobvious benefit offered by the boundary-scan technique isallowing fault isolation at the component level. Such an

isolation requirement is common in telecomunicationsswitching environments where prompt field repair is critical.

A major problem driving the development of IEEE Std 1149.1boundary scan is the adverse effect of surface-mounttechnology. The inclusion of a boundary-scan path insurface-mount components, in many cases, affords the onlyway to perform continuity tests between devices. By placinga known value on an output buffer of one device andobserving the input buffer of another interconnected device, itis easy to see if the printed wiring board (PWB) net iselectrically connected. Failure of this simple test indicatesbroken circuit traces, cold solder joints, solder bridges, orelectrostatic-discharge (ESD) induced failures in an ICbuffer all common problems on PWBs.

A less-obvious advantage of the boundary-scanmethodology is the ability to apply predeveloped functionalpattern sets to the I/O pins of the IC by way of the scan path.IC manufacturers and ASIC developers create functionalpattern sets for DC test purposes. Subsets of these patternscan be reused for in-circuit functional IC testing. Reusingexisting patterns in the development of system diagnosticscan save large amounts of development resources,especially if many of the ICs in a system have embeddedboundary-scan paths.

IEEE Std 1149.1 is a common protocol and boundary-scanarchitecture developed into an industrial standard afterthousands of man hours of cooperative development byapproximately 200 major international electronics firms. Earlycontributors in the development of IEEE Std 1149.1 wereAT&T, DEC, Ericsson, IBM, Nixdorf, Philips, Siemens,and TI. These companies recognized that only anonproprietary architecture would encourage companies to


28/144

3-2 Boundary-Scan Architecture and IEEE Std 1149.1

offer the compatible integrated circuits, test equipment, andCAD software needed to bring product development,manufacturing, and test costs under control in todayscompetitive electronics marketplace. Many people believethat boundary-scan architecture will do for development,manufacturing, and test what the RS-232C standard did forcomputer peripherals.

Boundary-Scan Overview

Boundary scan is the application of a scan path at theboundary (I/O) of ICs to provide controllability and

observability access via scan operations. Figure 3-1 showsan IC with an application-logic section and related input andoutput, and a boundary-scan path consisting of a series ofboundary-scan cells (BSCs), in this case one BSC per ICfunction pin.

ApplicationLogic

BSC

TDI TDO

NDINDO

BSC

Figure 3-1. Boundary-Scan ExampleThe BSCs are interconnected to form a scan path betweenthe host ICs test data input (TDI) pin and test data output(TDO) pin. During normal IC operation, input and outputsignals pass freely through each BSC, from the normal datainput (NDI), to the normal data output (NDO). However, whenthe boundary-test mode is entered, the ICs boundary iscontrolled in such a way that test stimulus can be shifted inand applied from each BSC output (NDO), and test responsecan be captured at each BSC input (NDI) and shifted out forinspection. External testing of wiring interconnects andneighboring ICs on a board assembly is accomplished byapplying test stimulus from the output BSCs and capturingtest response at the input BSCs. As an option, internaltesting of the application logic can be accomplished by


29/144

3-3

applying test stimulus from the input BSCs and capturing testresponse at the output BSCs. The implementation of a scanpath at the boundary of IC designs provides an embeddedtesting capability that can overcome the physical accessproblems in current and future board designs.

Test Interface and Boundary-Scan Architecture

Figure 3-2 shows the IEEE Std 1149.1 architecture. Thearchitecture consists of an instruction register, a bypassregister, a boundary-scan register (highlighted), optional userdata register(s), and a test interface referred to as the test

access port (TAP). In Figure 3-2, the boundary-scan register(BSR), a serially accessed data register made up of a seriesof boundary-scan cells (BSCs), is shown at the input andoutput boundary of the IC.

The instruction register and data registers are separate scanpaths arranged between the primary test data input (TDI) pinand primary test data output (TDO) pin. This architectureallows the TAP to select and shift data through one of the twotypes of scan paths, instruction or data, without accessingthe other scan path.


30/144


InputPins

OutputPins

TDI

TMS

TCK

TDO

TAP

User DataRegister

BypassResister

InstructionRegister

Note: The boundary-scan register is shifted TDI to TDO.

BSC

BSC

BSC

BSC

B

SC

B

SC

BSC

BSC

BSC

OE

Core Logic

Boundary-Scan Register

Figure 3-2. Boundary-Scan Architecture


31/144

3-5

Test Access Port and Operation

The TAP is controlled by the test clock (TCK) and test modeselect (TMS) inputs. These two inputs determine whether aninstruction register scan or data register scan is performed.The TAP consists of a small controller design, driven by theTCK input, which responds to the TMS input as shown in thestate diagram in Figure 3-3. The IEEE Std 1149.1 test bususes both clock edges of TCK. TMS and TDI are sampled onthe rising edge of TCK, while TDO changes on the fallingedge of TCK.

Shift-DR

1 0

1

0

1 1

0

0

1

0

0

1

1

0 0

0

0

1

0

0

1

1

1 1

0

0

0

0

1 1

11

Note: The value shown adjacent to each state transition in this figurerepresents the signal present at TMS at the rising edge of TCK.

Pause-DR

Update-DR

Test-Logic-Reset

Capture-DR Capture-IR

Shift-IR

Exit1-DR Exit1-IR

Pause-IR

Exit2-DR Exit2-IR

Update-IR

Select-DR-Scan Select-IR-ScanRun-Test/Idle

Figure 3-3. TAP Controller State Diagram


32/144


The main state diagram consists of six steady states:Test-Logic-Reset, Run-Test/Idle, Shift-DR, Pause-DR,Shift-IR, and Pause-IR. A unique feature of this protocol isthat only one steady state exists for the condition when TMSis set high: the Test-Logic-Reset state. This means that areset of the test logic can be achieved within five TCKs orless by setting the TMS input high.

At power up, or during normal operation of the host IC, theTAP is forced into the Test-Logic-Reset state by driving TMShigh and applying five or more TCKs. In this state, the TAPissues a reset signal that places all test logic in a condition

that does not impede normal operation of the host IC. Whentest access is required, a protocol is applied via the TMS andTCK inputs, causing the TAP to exit the Test-Logic-Resetstate and move through the appropriate states. From theRun-Test/Idle state, an instruction register scan or a dataregister scan can be issued to transition the TAP through theappropriate states shown in Figure 3-3.

The states of the data register scan and instruction registerscan blocks are mirror images of each other, addingsymmetry to the protocol sequences. The first action thatoccurs when either block is entered is a capture operation.For the data registers, the Capture-DR state is used tocapture (or parallel load) the data into the selected serialdata path. If the BSR is the selected data register, the normaldata inputs (NDIs) are captured during this state. In theinstruction register, the Capture-IR state is used to capturestatus information into the instruction register.

From the Capture state, the TAP transitions to either the Shiftor Exit1 state. Normally, the Shift state follows the Capturestate so that test data or status information can be shifted outfor inspection and new data shifted in. Following the Shiftstate, the TAP either returns to the Run-Test/Idle state via theExit1 and Update states or enters the Pause state via Exit1.The reason for entering the Pause state is to temporarilysuspend the shifting of data through either the selected dataregister or instruction register while a required operation,such as refilling a tester memory buffer, is performed. Fromthe Pause state, shifting can resume by re-entering the Shiftstate via the Exit2 state or be terminated by entering theRun-Test/Idle state via the Exit2 and Update states.


33/144

3-7

Upon entering the data register scan or instruction registerscan blocks, shadow latches in the selected scan path areforced to hold their present state during the capture and shiftoperations. The data being shifted into the selected scanpath is not output through the shadow latch until the TAPenters the Update-DR or Update-IR state. The Update statecauses the shadow latches to update (or parallel load) withthe new data that has been shifted into the selected scanpath.

Figure 3-4 shows the TAP control output signals, along withthe instruction register and data register interconnects.

Instruction Register

Data Register

TAP

TDI

TMS

TCK

MSB LSB

MSB LSB

TDO

CLOCKIR

UPDATEIR

SHIFTIR

RESET*

SELECT

ENABLE

SHIFTDR

UPDATEDR

CLOCKDR

1

0

Figure 3-4. TAP Control Output Interconnect Diagram


34/144


IEEE Std 1149.1 Registers

This section contains descriptions of the required andoptional registers specified in IEEE Std 1149.1-1990.

Instruction Register (Required)

The instruction register is responsible for providing theaddress and control signals required to access a particulardata register in the scan path. The instruction register isaccessed when the TAP receives an instruction register scanprotocol. During an instruction register scan operation the

SELECT output from the TAP (Figure 3-4) selects the outputof the instruction register to drive the TDO pin. A generalinstruction register architecture is shown in Figure 3-5.

TDOInstructionShift Register

InstructionShadow Latch

STATUS 1

STATUS 6

STATUS 7

TDI

CLOCKIR

SHIFTIR

RESET*

UPDATEIR

7 6 1 0

Instruction Register Outputs

7 6 1 0

7 6 1 0

STATUS 0

Figure 3-5. General Instruction Register Architecture

The instruction register consists of an instruction shiftregister and an instruction shadow latch. The instruction shiftregister (Figure 3-5) consists of a series of shift register bitsarranged to form a single scan path between the TDI andTDO pins of the host IC. During instruction register scanoperations, the TAP exerts control via the instruction registershift enable (SHIFTIR) and instruction register clock


35/144

3-9

(CLOCKIR) signals to cause the instruction shift register topreload status information and shift data from TDI to TDO.Both the preload and shift operations occur on the risingedge of TCK; however, the data shifted out from the host ICfrom TDO occurs on the falling edge of TCK. The statusinputs are user-defined observability inputs, except for thetwo least-significant bits, which are always 01 for scan-pathtesting purposes. (The instruction register has a minimumlength of two bits.)

The instruction shadow register (Figure 3-5) consists of aseries of latches, one latch for each instruction shift register

bit. During an instruction register scan operation, the latchesremain in their present state. At the end of the instructionregister scan operation, the instruction register update(UPDATEIR) input updates the latches with the newinstruction installed in the instruction shift register. Whenactivated, the RESET* input sets the instruction shadowregister to the value of the BYPASSinstruction (or IDCODEinstruction, if it is supported). This forces the device into itsnormal functional mode and selects the bypass register (ordevice identification register, if one is present).

Data Registers

IEEE Std 1149.1 requires two data registers; boundary-scanregister and bypass register, with a third, optional, deviceidentification register. Additional user-defined data registerscan be included. The data registers are arranged in parallelfrom the primary TDI input to the primary TDO output. The

instruction register supplies the address that allows one ofthe data registers to be accessed during a data register scanoperation. During a data register scan operation, theaddressed scan register receives TAP control via the dataregister shift enable (SHIFTDR) and data register clock(CLOCKDR) inputs to preload test response and shift datafrom TDI to TDO. During a data register scan operation, theSELECT output from the TAP (Figure 3-4) selects the outputof the data register to drive the TDO pin. When one scanpath in the data register is being accessed, all other scanpaths remain in their present state.


36/144


Boundary-Scan Register

Bypass Register

TDO

Device Identification Register

Design-Specific Test Data Register



FromTDI

To

Clock and Control Signals From InstructionRegister, TAP Controller, etc.

Optional

Optional

Optional

Optional

MUX

G

MUX

Figure 3-6. Test Data Register Architecture

Boundary-Scan Register The boundary-scan register(BSR) consists of a series of boundary-scan cells(BSCs) arranged to form a scan path around theboundary of the host IC. The BSCs provide thecontrollability and observability features required toperform boundary-scan testing as described in theBoundary-Scan Overview section of this chapter.Shadow latches in the BSCs, driving the NDO outputsremain in their present state during a data register scan

operation. At the end of a data register scan operation,the data register update (UPDATEDR) input updatesthe shadow latches with the new boundary test patternto be applied from the NDO outputs of the BSCs.Figure 3-7 shows a conceptual view of acontrol-and-observe BSC.


37/144

3-11

1D

C1

NDO

ShiftDR

NDI

Serial Input

Serial IR Decode

ClockDR UpdateDR

Output Mode

G

G

1

1

1D

C1

1

1

Figure 3-7. Conceptual View of a Control-and-Observe BSC

Bypass Register (Required) The bypass register consistsof a single scan register bit. When selected, the bypassregister provides a single-bit scan path between TDIand TDO. Thus, the bypass register allows abbreviatingthe scan path through devices that are not involved inthe test. The bypass register is selected when theinstruction register is loaded with a pattern of all ones tosatisfy the IEEE Std 1149.1 BYPASSinstructionrequirement.

Device Identification Register (Optional) The deviceidentification register is an optional register, defined by

IEEE Std 1149.1, to identify the devices manufacturer,part number, revision, and other device-specificinformation. Figure 3-8 shows the bit assignmentsdefined for the device identification register. These bitscan be scanned out of the device identification registerafter its selection.

MSB LSB

Version(bits 3128)

Part Number(bits 2712)

Manufacturer Identity(bits 111)

1

Fixed(bit 0)

Figure 3-8. Device Identification Register Structure

Although the device identification register is optional,IEEE Std 1149.1 has dedicated an instruction to select


38/144


this register. The device identification register isselected when the instruction register is loaded with theIDCODEinstruction, the bit code of which is defined bythe vendor.

Manufacturers identity codes (bit1 through bit11) areassigned, maintained, and updated by the EIA/JEDECoffice. Any company can be added to the JEDECStandard Manufacturers Identification Code(Publication JEP106) by request to the JEDEC office at202-457-4973.

IEEE Std 1149.1 Required InstructionsIEEE Std 1149.1 defines nine test instructions. Of the nineinstructions, three are required and six are optional. Thefollowing subsections contain brief descriptions of eachrequired test instruction.

BYPASS Instruction

The required BYPASSinstruction allows the IC to remain in afunctional mode and selects the bypass register to beconnected between TDI and TDO. The BYPASSinstructionallows serial data to be transferred through the IC from TDIto TDO without affecting the operation of the IC. The bit codeof this instruction is defined as allones by IEEE Std 1149.1.

SAMPLE/PRELOAD Instruction

The required SAMPLE/PRELOADinstruction allows the IC toremain in its functional mode and selects the boundary-scanregister to be connected between TDI and TDO. During thisinstruction, the boundary-scan register can be accessed viaa data scan operation, to take a sample of the functional dataentering and leaving the IC. This instruction is also used topreload test data into the boundary-scan register beforeloading an EXTESTinstruction. The bit code for thisinstruction is defined by the vendor.


39/144

3-13

EXTEST Instruction

The required EXTESTinstruction places the IC into anexternal boundary-test mode and selects the boundary-scanregister to be connected between TDI and TDO. During thisinstruction, the boundary-scan register is accessed to drivetest data off-chip via the boundary outputs and receive testdata off-chip via the boundary inputs. The bit code of thisinstruction is defined as all zeroes by IEEE Std 1149.1 .

IEEE Std 1149.1 Optional Instructions

The following subsections contain brief descriptions of theoptional IEEE Std 1149.1 instructions.

INTEST Instruction

The optional INTESTinstruction places the IC in an internalboundary-test mode and selects the boundary-scan registerto be connected between TDI and TDO. During thisinstruction, the boundary-scan register is accessed to drivetest data on-chip via the boundary inputs and receive testdata on-chip via the boundary outputs. The bit code of thisinstruction is defined by the vendor.

RUNBIST Instruction

The optional RUNBISTinstruction places the IC in a self-testmode, enables a comprehensive self-test of the ICs corelogic, and selects a user-specified data register to be

connected between TDI and TDO. During this instruction, theboundary outputs are controlled so that they cannot interferewith neighboring ICs during the RUNBISToperation. Also,the boundary inputs are controlled so that external signalscannot interfere with the RUNBISToperation. The bit code ofthis instruction is defined by the vendor.

CLAMP Instruction

The optional CLAMPinstruction sets the outputs of an IC tologic levels determined by the contents of the boundary-scanregister and selects the bypass register to be connectedbetween TDI and TDO. Before loading this instruction, thecontents of the boundary-scan register can be preset withthe SAMPLE/PRELOADinstruction. During this instruction,data can be shifted through the bypass register from TDI to


40/144


TDO without affecting the condition of the outputs. The bitcode of this instruction is defined by the vendor.

HIGHZ Instruction

The optional HIGHZinstruction sets all outputs (includingtwo-state as well as three-state types) of an IC to a disabled(high-impedance) state and selects the bypass register to beconnected between TDI and TDO. During this instruction,data can be shifted through the bypass register from TDI toTDO without affecting the condition of the IC outputs. The bitcode of this instruction is defined by the vendor.

IDCODE Instruction

The optional IDCODEinstruction allows the IC to remain inits functional mode and selects the optional deviceidentification register to be connected between TDI andTDO. The device identification register (see Figure 3-8) is a32-bit shift register containing information regarding the ICmanufacturer, device type, and version code. Accessing thedevice identification register does not interfere with theoperation of the IC. Also, access to the device identificationregister should be immediately available, via a TAPdata-scan operation, after power-up of the IC or after theTAP has been reset using the optional TRST* pin or byotherwise moving to the Test-Logic-Reset state. The bit codeof this instruction is defined by the vendor.

USERCODE InstructionThe optional USERCODEinstruction allows the IC to remainin its functional mode and selects the device identificationregister to be connected between TDI and TDO. During theUSERCODEinstuction, the optional 32-bit deviceidentification register captures user-defined informationabout the IC. Accessing the device identification registerdoes not interfere with the operation of the IC. The bit codeof this instruction is defined by the vendor.


41/144

3-15

Obtaining IEEE Std 1149.1-1990

To learn more about IEEE Std 1149.1, please refer to thepublications,IEEE Standard Test Access Port andBoundary-Scan Architecture, IEEE Std 1149.1-1990(includes IEEE Std 1149.1a-1993) and Supplement to IEEEStd 1149.1-1990, IEEE Standard Test Access Port andBoundary-Scan Architecture, IEEE Std 1149.1b-1994. Thesedocuments are available through IEEE (1-800-678-IEEE).IEEE Std 1149.1-1990/IEEE Std 1149.1a-1993 is alsoavailable from Texas Instruments on CD-ROM (seeChapter 9, Other Support and Learning Products).


42/144


43/144

4-1

Chapter 4

Using DFT in ASICs

The concern most often voiced by application-specificintegrated circuit (ASIC) users is that of testability. Thischapter is intended to provide an understanding of ASICtestability that can be used for developing test strategieswhen designs are being initiated.

Design-for-Test Considerations

Designing testability into any circuit affects the hardware tosome degree. Additional logic will probably have to beadded. This additional logic increases the amount of siliconrequired to implement the design. The savings fromenhanced testability do not usually show up until the cycletime and testing cost of the circuit and its end system areanalyzed.

Fault simulation is an important part of designing fortestability. This technique enables you to evaluate your testpatterns to determine whether these patterns detect faults.Faults may occur during either the design-tooling stage orthe circuit-fabrication stage. A fault simulator uses faultmodels, such as a node shorted to power (stuck-at-one) or anode shorted to ground (stuck-at-zero), and compares theresponse of a fault-free circuit with the response of a faultycircuit. If the response of the fault-free circuit is different thanthe response of the faulty circuit, then the test patterns have

detected the fault.

By faulting all the nodes in the circuit, the fault simulatorproduces the test-pattern fault grade or fault coverage. Thefault coverage is the percentage of faults detected amongthe total faults. The higher the fault coverage, the better thetest pattern set separates a faulty circuit from a fault-freecircuit. After determining which faults have not been detectedby the current set of test patterns, additional test patternscan be generated to detect those faults.

Adoption of design-for-test principles early in the designprocess ensures the maximum testability for the minimumeffort. These guidelines emphasize that test is a part of thedesign flow, not a process that is done at the end of thedesign cycle.


44/144

4-2 Using DFT in ASICs

Three basic elements must come together to make asuccessful ASIC circuit:

Logic design, including schematic capture, libraryselection, synthesis, and simulation

Logic testability, including fault-detection andtest-application criteria within predefined cost andtime-scale budgets

Vendors manufacturing capability, including processingand packaging

The Need for Testability

Most engineers involved in the design of ASIC devices arefamiliar with the trade-offs between gate arrays, standardcells, and full custom devices. They are also familiar with thevendor selection process. The aspect of test capability andtestability is often overlooked.

Testability could be ignored when typical designs were only afew thousand gates. These designs were implemented firstand then turned over to a test engineer or to a vendor tocreate a test program for production. As design complexitiesincreased, this approach to testing became futile. Successfulhigh-density ASIC design and manufacturing demand thatcircuits be built with testability incorporated into the designprocess.

Although testability imposes additional constraints in thedesign phase, design verification and test can beunmanageable, if ignored until the design is completed andtestability is handled as a postdesign insertion. In fact, thedesign constraints are overwhelmingly balanced by improvedtestability, which adds value to the device throughoutmanufacturing and system life.


45/144

4-3

Test-Time Cost

Test cost, as it relates to time, is a simple calculation. Mostcommercial testers cost between $2 million and $3 million.Under normal circumstances, the tester depreciation, plant,operator, and support personnel costs are between 10 and20 cents per test second.

Brute-force test approaches often generate a large numberof test patterns. Since test patterns are run at multiplepower-supply values and possibly at multiple temperatures,inefficient pattern sets can severely impact the test costs of acomplex ASIC device.

Time to Market

Surveys indicate that 40 percent of the development cycletime for an ASIC device is required for test insertion andtest-pattern generation. This figure is expected to increaseas device complexity increases. The intent of adesign-for-test strategy is to achieve high fault-detection testprograms in reduced time (Figure 4-1). The obviouscycle-time reductions result from designed-in testability(elimination of iterative redesigns resulting from poor designpractices), and from automatic test-pattern generation(ATPG).

Hours Days Weeks Months

Time to Develop Test Patterns

Fau

ltGra

de

%

With DFT Strategies

Without DFT Strategies

100

80

60

40

20

0

Figure 4-1. Fault Grade Versus Development Time


46/144


Figure 4-2 shows the economic relationship between time tomarket and system manufacturing and field maintenancecosts. Point 1 represents the case where market-entry timingforces a constraint on the development time. Since 40percent of this time is expended in inserting testability, thetemptation is to rush to market with devices that are notcompletely testable or tested. The result is ahigher-than-desirable manufacturing and field-maintenancecost. Point 2 represents the case where DFT and ATPGtechniques are employed to develop devices that arecompletely tested. This situation allows an economicoptimum that is more favorable to long-term manufacturing

and maintenance costs.

EconomicOptimum

EconomicOptimum

Without DFT Strategy

With DFT Strategy

Manufacturingand Field Cost

Development andTime-to-Market Cost Total Cost

Fault Coverage %

Cos

t$

1

2

Figure 4-2. Economic Trade-Off for a Testable Design

A less obvious result of a DFT strategy is the reduction ofdebug time. The designer must make certain assumptionsabout system requirements. Often, a new device does notwork in the system environment and requires debugging. Ifthe device is designed for controllability and observabilityaccess, the debugging process is enhanced. Conversely, ifthese two features are overlooked, debugging andmanufacturing can be significantly harder to accomplish, ifnot impossible. Oscilloscopes and logic analyzers are notvery effective in debugging systems utilizing complex ASICdevices in a surface-mount environment.


47/144

4-5

Fault Coverage and Cost of Ownership

Figure 4-3 shows the trade-off between time to market andmanufacturing and field-maintenance costs. The horizontalfactor on this figure is fault coverage. The relationshipbetween fault coverage and device defect level is welldocumented.

Figure 4-3 is a plot of the relationship modeled by T. W.Williams for fault coverages of 90 percent, or greater.

The Williams model is:

D

[1 Y(1 T)

] x100

Where:

D = Defect level in percent

Y = Theoretical functional process yield

T = Fault coverage of the test program used

7

6

5

4

3

2

1

0

50%

60%

70%

80%

90%

De

fec

tLeve

l%

Fault Coverage %

90

6.70

4.98

3.50

2.21

1.05

91

6.04

4.48

3.16

1.99

0.94

92

5.39

4.00

2.81

1.77

0.84

93

4.74

3.51

2.47

1.55

0.73

94

4.07

3.02

2.12

1.33

0.63

95

3.41

2.52

1.77

1.11

0.53

96

2.73

2.02

1.42

0.89

0.42

97

2.08

1.52

1.06

0.67

0.32

98

1.38

1.01

0.71

0.45

0.21

99

0.89

0.51

0.36

0.22

0.11

100

.00

.00

.00

.00

.00

50% Process Yield

60% Process Yield

70% Process Yield

80% Process Yield

90% Process Yield

Figure 4-3. Defect Level Versus Fault Coverage

To briefly explore the Williams model, assume that theASIC vendor has a silicon and assembly process yield that is


48/144


70 percent. If the fault grade of the test program is also 70percent, the defect level is projected to be 10.1 percent, or101,000 ppm (this is outside the limits of the chart and wascalculated). At a fault grade of 90 percent, the defect level isprojected to be 3.5 percent or 35,000 ppm.

A study of the model shows that the process yield becomesan insignificant term when the fault coverage of the testprogram is very close to 100 percent.

Motorola and Delco performed a study in 1980 that supportsthe Williams model. Their experimental results are shown inFigure 4-4. A fault coverage of 99.9 percent was required to

obtain defect levels in the range of 100 ppm.

Fault Coverage %

De

fec

tLeve

lppm

90 99 99.9

10000

1000

100

10

Harrison, Holzwarth, Motz, Delco;Daniels, Thomas, Weimann, Motorola, 9/80

100000

Figure 4-4. Motorola and Delco Study ResultsFigure 4-5 shows the maximum allowable ASIC defect rateto achieve a goal PCB defect rate as a function of thenumber of ASIC devices per board assembly. Note that formultiple-device PCB designs, a goal of 500 ppm requiresASIC defect levels in the range of 100 to 200 ppm.


49/144

4-7

Goal PCB ppm Rate

ASICppm

Ra

te

0

300

200

100

0

400

500

100 200 300 400 500 600

1

2

34

20

600Number of ASICs Per Board

510

Figure 4-5. ASIC ppm Versus PCB ppm Rate

Theoretical and experimental studies conclude that ahigh-fault-grade test-pattern set is required forlow-defect-level ASIC devices. This type of pattern set isnearly impossible to obtain through brute force. Therequirements for a high-fault-grade pattern set are:

ATPG tool

Fault grader

A testable design meeting the constraints of the ATPG tool

As stated earlier, a design-for-test strategy has performanceand area costs. Now, the cost of new tools has been added.Benefits such as lower test costs and reduced time to market

have been mentioned. These benefits are real, but often hardto quantify. Reduced cost of ownership is another majorbenefit and is easy to quantify.

Figure 4-6 shows what is commonly referred to as thecost-of-ownership, order-of-magnitude relationship. Itshows that each company has a cost associated with findinga defect in a packaged device before it has entered theassembly process. This cost can be calculated easily. Thecost of finding a defective device after assembly onto a PCBis an order-of-magnitude more than before assembly. Thiscontinues until the cost to discover a defective device in asystem at a customers site is three orders-of-magnitudehigher than that of discovery before assembly on to a PCB.


50/144


The lowest cost of ownership is achieved by finding defectiveunits before they are shipped from the vendor.

0

Cost-of-Defect-Discovery Multiplier

Discovery

Site

1X 10X 100X 1000X

Customer Site

System

PCB

PackageDevice

Figure 4-6. Cost of Ownership

The previous discussions lead to the conclusion that thelowest cost of ownership can be obtained by providing theASIC vendor with an efficient, high-fault-detection set of testvectors. These DFT methodologies provide lower cost ofownership with the added benefit of reduced time to market.

Developing Testability Strategies

The following strategies outline the process of design fortest.

1. Select a technology.

When selecting a technology or vendor, make sure thereis enough performance and gate-count margin to allow theinsertion of testability.

2. Commit to testability design practices.

Testability design practices work. Commit to use them,and review them with the design team before the designbegins. Add a testability commitment to the designrequirements document developed for the design project.Make testability audits part of the design review process.

3. Establish a fault-grade requirement.

The fault-grade requirement usually can be provided bythe manufacturing or quality organization. Establish thisrequirement before the first design review. Add thefault-grade requirement to the design requirements


51/144

4-9

document. This requirement drives many of the decisionsthat follow in the development of the test strategy.

Many companies consider the fault-grade requirement tobe an index of device cost of ownership. Failure toachieve it impacts profits throughout the lifetime of thedevice.

4. Decide if IEEE Std 1149.1 is a system requirement.

When implemented in an ASIC device, IEEE Std 1149.1allows test of the interconnect between devices on a PCBthrough a four-pin test bus. If IEEE Std 1149.1 is selected,the four dedicated test pins also can be used to control

core-logic test techniques such as built-in self-test (BIST),internal scan, on-chip emulation, and boundary-scanthrough the test access port (TAP) and instruction register.

5. Select an ASIC testability approach based on gatedensity.

Designs with fewer than 10K gates

Designs with fewer than 10K gates are not generallycomplex enough to require structured test approaches.The overhead impact is usually too high to justify them.Nonstructured, good design practices are usuallysufficient.

Designs with more than 10K gates, but fewer than 20Kgates

Structured techniques should be considered for designsin this density. Nonstructured, good design practices areprobably sufficient for highly combinatorial circuitswithout memory. Structured approaches should beconsidered as complexity is increased by the addition ofsequential circuits, feedback, and memory. Considerboundary-scan testing for reduced cycle times and highfault grades.

Designs with more than 20K gates

The complexity of circuits this dense usually requiresstructured approaches to achieve high fault grades. Atthis density, it is often hard to control or observe deeplyembedded circuits. The overhead associated withstructured testability approaches is acceptable at thisdensity.


52/144


6. Choose structured tools.

Scan testing is typically the preferred structured approachfor sequential logic. The available scan choices are:

Clocked scan

Multiplexed flip-flop scan

Level-sensitive scan-design (LSSD)

Parallel scan chains

Partial scan

7. Establish a diagnostic functional-pattern set to expeditedebug.

This is an important step in decreasing the time to marketfor an ASIC device. The purpose of this pattern set is toisolate circuitry for analysis.

8. Generate high fault-grade test patterns.

The fault grade of a test pattern set determines the bestpossible quality level attainable with that set of patterns.

9. Simulate test patterns and timing.

Two types of simulation are required during development.Logic simulation verifies both functionality andperformance of the device. Test-pattern simulationproduces the information needed to verify the testpatterns in a tester environment.

Figure 4-7 contains a flow chart that steps through thedesign-for-test process.


53/144

4-11

Yes

Yes

Yes

No

No

No

ImplementIEEE Standard 1149.1

Considerscan

Recommendscan

Minimum Time to Market

Pick a technology/vendor

Commit to good testabilitydesign practices

Establish a fault-graderequirement

IEEE Standard 1149.1required for PCB?

Density = Gates < 10K ?

10K < Gates < 20K ?

Choose structured approachScan/BIST

Develop diagnostic patternsets and locate critical paths

Develop high fault-gradepattern sets

Simulate test patterns andtiming

Generate test descriptionlanguage

Have a system to ensuretest patterns are compatiblewith logic revisions

Figure 4-7. Testability Development Flow


54/144



55/144

5-1

Chapter 5

Data Formats

Several data formats have emerged to make IEEE Std1149.1 successful and well supported by tools. This chapterdiscusses the most widely accepted data formats thatsupport IEEE Std 1149.1 BSDL, HSDL, and SVF.

Boundary-Scan Description Language (BSDL)

In 1990, IEEE Std 1149.1 was approved and implementation

of the standard accelerated. As more people became awareof and used the standard, the need for a standard method fordescribing IEEE Std 1149.1-compatible devices wasrecognized. The IEEE Std 1149.1 working group establisheda subcommittee to develop a device description language toaddress this need.

The subcommittee has since developed an industry standardlanguage called Boundary-Scan Description Language(BSDL). BSDL is a subset and standard practice of VHDL(VHSIC Hardware Description Language) that describes howIEEE Std 1149.1 is implemented in a device and how itoperates. BSDL captures the essential features of any IEEEStd 1149.1 implementation. BSDL has been formally adoptedas part of IEEE Std 1149.1b-1994.

IEEE Std 1149.1 is a structured design-for-test approach wellsuited for tools and automation. Tools developed to support

the standard can control the test access port (TAP). If theyknow how the boundary-scan architecture was implementedin the device, such tools can also control the I/O of thedevice. BSDL provides a standard machine- andhuman-readable data format for describing how IEEE Std1149.1 boundary-scan architecture is implemented in adevice.

How BSDL Is Used

Many IEEE Std 1149.1 tools already on the market supportBSDL as a data input format. These tools offer differentcapabilities to customers implementing IEEE Std 1149.1 intotheir designs, including board interconnect automatictest-pattern generation (ATPG) and automatic test equipment(ATE).


56/144

5-2 Data Formats

When tools that support BSDL are used, such BSDL is oftenreceived from the semiconductor vendor. This can result insignificant time and cost savings.

Teradyne estimates that to create in-circuit test patterns for aleading microprocessor normally can take as long as sevenweeks:

One week to study the device

Four weeks to develop in-circuit test patterns

Two weeks to verify the patterns on ATE

The development cost estimate for this approach is $14,000.If the microprocessor supports IEEE Std 1149.1, and theBSDL is supplied by the vendor, the time to develop in-circuittest patterns is less than two hours (less than $100) usingtodays tools.

Elements of BSDL

A BSDL description for a device consists of the followingelements:

Entity descriptions

Generic parameter

Logical port description

Use statement(s)

Component conformance statement

Pin mapping(s)Scan port identification

Instruction register description

Optional register decription

Register access description

Boundary register description

Entity Descriptions The entity statement names the entity,such as the device name (e.g., SN74BCT8245A). Anentity description begins with an entity statement andterminates with an end statement.entity XYZ is{statements to describe the entity go here}

end XYZ;


57/144

5-3

Generic Parameter A generic parameter is a parameterthat can come from outside the entity, or it can bedefaulted, such as a package type (e.g., DW).generic (PHYSICAL_PIN_MAP : string := DW);

Logical Port Description The port description gives logicalnames to the I/O pins (system and TAP pins), anddenotes their nature, such as input, output, bidirectional,linkage (analog or power supply/return) and so on.port (OE:in bit;Y:out bit_vector(1 to 3);

A:in bit_vector(1 to 3);GND, VCC, NC:linkage bit;TDO:out bit;TMS, TDI, TCK:in bit);

Use Statement(s) The use statement refers to externaldefinitions found in packages and package bodies.use STD_1149_1_1994.all;

Component Conformance Statement The componentconformance statement indicates the latest issue ofIEEE Std 1149.1 to which the device conforms.attribute COMPONENT_CONFORMANCE of XYZ : entity is

STD_1149_1_1993;

Pin Mapping(s) The pin mapping provides a mapping oflogical signals onto the physical pins of a particulardevice package.attribute PIN_MAP of XYZ : entity isPHYSICAL_PIN_MAP;constant DW:PIN_MAP_STRING:=OE:1, Y:(2,3,4), A:(5,6,7), GND:8, VCC:9, &

TDO:10, TDI:11, TMS:12, TCK:13, NC:14;

Scan Port Identification The scan port identificationstatements define the devices TAP.attribute TAP_SCAN_IN of TDI : signal is TRUE;attribute TAP_SCAN_OUT of TDO : signal is TRUE;attribute TAP_SCAN_MODE of TMS : signal is TRUE;attribute TAP_SCAN_CLOCKof TCK : signal is (50.0e6,

BOTH);

Instruction Register Description The instruction registerdescription identifies the device-dependentcharacteristics of the instruction register.attribute INSTRUCTION_LENGTH of XYZ : entity is 2;attribute INSTRUCTION_OPCODE of XYZ : entity isBYPASS (11),&EXTEST (00),&SAMPLE (10),&IDCODE (01)

attribute INSTRUCTION_CAPTURE of XYZ : entity is01;


58/144

5-4 Data Formats

Optonal Register Description The optional registerdescription identifies the values captured in the deviceidentification register for the optional IDCODEandUSERCODEinstructions, if supported.attribute IDCODE_REGISTER of XYZ : entity is01010100000011111100000000101111;

Register Access Description The register accessdescription defines which register is placed betweenTDI and TDO for each instruction.attribute REGISTER_ACCESS of XYZ : entity isBOUNDARY (EXTEST, SAMPLE),&BYPASS (BYPASS);

Boundary Register Description The boundary registerdescription contains a list of boundary-scan cells, alongwith information regarding the cell type and associatedcontrol.attribute BOUNDARY_LENGTH of XYZ : entity is 7;attribute BOUNDARY_REGISTER of XYZ : entity is0 (BC_1, Y(1), output3, X, 6, 0, Z),&1 (BC_1, Y(2), output3, X, 6, 0, Z),&2 (BC_1, Y(3), output3, X, 6, 0, Z),&3 (BC_1, A(1), input , X),&4 (BC_1, A(2), input , X),&5 (BC_1, A(3), input , X),&6 (BC_1, OE , input , X),&6 (BC_1, * , control, 0);

Verifying BSDL Accuracy

Creating a BSDL file that is syntactically and semanticallycorrect is only the beginning. A syntactically and semanticallycorrect BSDL file can still contain descriptive errors and

result in time-consuming debugging of board-level tests anddiagnostics. A BSDL file must be validated (compared)against the silicon.


59/144

5-5

Potential BSDL Errors

As with any hand-entered data, typographical errorspotentially exist. BSDL contains many commas andsemicolons that contribute error possibilities. Fortunately,syntax and semantics errors can easily be identified andcorrected using syntax and semantics checking tools duringthe authoring process.

Other common errors are:

Wrong pinout

Wrong cell types

Wrong boundary-scan register order

Wrong boundary-scan register length

Wrong instruction register opcodes

Wrong control cell locations

Wrong control cell disable value

Wrong I/O pin control cell

Wrong identification code value

Wrong capture-IR value

Typographical errors or device documentation errors canresult in implementation errors.

How to Receive the BSDL Specification

Contact the IEEE (1-800-678-IEEE) and refer to Supplement

to IEEE Std 1149.1-1990, IEEE Standard Test Access Portand Boundary-Scan Architecture, IEEE Std 1149.1b-1994 toreceive a copy of the Boundary-Scan Description Language(BSDL) specification.

Obtaining BSDL for TI Devices

Texas Instruments makes catalog-device BSDL filesavailable to customers through the World-Wide Web. As ofthis writing, these files can be located on the TexasInstruments IEEE Std 1149.1/JTAG/Boundary-Scan SiliconProducts page located at URL http://www.ti.com/sc/docs/

jtag/silicon.htm; or, on the main Texas Instruments homepage at URL http://www.ti.com. Search for keyword BSDL.


60/144

5-6 Data Formats

Hierarchical Scan Description Language (HSDL)

Texas Instruments developed the hierarchical scandescription language (HSDL) to complement BSDL, usingthe same subset of VHDL statements as BSDL. HSDL picksup where BSDL stops to describe additional attributes ofIEEE Std 1149.1 devices and how IEEE Std 1149.1 devicesare connected at the board and system levels.

HSDL uses the BSDL entity and package in new ways.Entities in HSDL are used to describe modules as well asdevices. A module is any level of architecture above thedevice level, including boards, multichip modules,backplanes, subsystems, and systems. In addition, HSDLprovides two new packages used to indicate that an entity isan HSDL device or module.

BSDL is ideal for describing how IEEE Std 1149.1 isimplemented in a device, but stops there. HSDL provides amethod for describing how IEEE Std 1149.1 devices areconnected at the board, module, and system levels. HSDLserves two needs not addressed by BSDL:

Describes the test-bus interconnections of IEEE Std1149.1 at the board or module level

Improves ease of use and reduces risk during interactivedesign debug and verification

Allows descriptions of boards with dynamic andreconfigurable architectures

Elements of HSDL

HSDL module statements use much of the same syntax asBSDL. New statements have been added to describe themembers and scan paths of the module and to simplifyinteractive use.

Entity description

Generic parameter

Logical port description

Use statement(s)

[Optional module description(s)]

[Optional port description(s)]

Pin mapping(s)


61/144

5-7

Scan port identification

[Optional members description(s)]

[Optional bus composition(s)]

Path description

[Optional member connections]

[Optional constraint description(s)]

[Optional design warning]

Entity Description The entity statement names the entity,

such as the module name (e.g., BOARD). An entitydescription begins with an entity statement andterminates with an end statement.entity BOARD is{statements to describe the entity go here}

end BOARD;

Generic Parameter A generic parameter may come fromoutside the entity or it may be defaulted, such as apackage type (e.g., UNDEFINED).generic (PHYSICAL_PIN_MAP : string := UNDEFINED);

Logical Port Description The port description gives logicalnames to the I/O pins (system and TAP pins), anddenotes their nature such as input, output, bidirectional,linkage (analog or power supply/return) and so on.port (TDI:in bit;TDO:out bit;TMS:in bit;TCK:in bit;GND:linkage bit);

Use Statement(s) The use statement refers to externaldefinitions found in packages and package bodies.use STD_1149_1_1994.all;use HSDL_module.all;

Pin Mapping(s) The pin mapping provides a mapping oflogical signals onto the physical pins of a particularentity.attribute PIN_MAP of BOARD : entity isPHYSICAL_PIN_MAP;constant PINOUT1 : PIN_MAP_STRING :=TDI:1, TDO:2, TMS:3, TCK:4, GND:5;


62/144

5-8 Data Formats

Scan Port Identification The scan port identificationstatements define the entitys TAP.attribute TAP_SCAN_IN of TDI : signal is TRUE;attribute TAP_SCAN_OUT of TDO : signal is TRUE;attribute TAP_SCAN_MODE of TMS : signal is TRUE;attribute TAP_SCAN_CLOCK of TCK : signal is (5.0e6, LOW);

Members Description (Optional) Members representdevices or other modules that are on the module.Usually members represent components, but someboards may contain scannable daughtercards, cardslots, etc. that require member modules to describethem.attribute MEMBERS of BOARD : entity isU1 (XYZ1, DW),&U2 (XYZ2, DW);

Bus Composition (Optional) Buses in an HSDL modulecan be built of module buses, member module buses,member device buses, and member device testregisters.attribute BUS_COMPOSITION of BOARD : entity isbus1[4] (U1.Boundary[3,0]),&bus2[4] (U2.Boundary[3,0]);

Path Description Module paths are intended to describethe netlist of TAP signals (scan paths) on the board.constant boardpath1 : STATIC_PATH :=U1, U2;

end BOARD;

How to Receive the HSDL Specification

Originally developed by Texas Instruments primarily insupport of its ASSET business, HSDL is now supported byASSET InterTech, which acquired ASSETin 1995.


63/144

5-9

Serial Vector Format (SVF)

Serial Vector Format, commonly referred to as SVF, wasjointly developed by Texas Instruments and Teradyne in1991. SVF is a standard ASCII format for expressing testpatterns that represent the stimulus, expected response, andmask data for IEEE Std 1149.1-based tests. The need forSVF arose from the desire to have vendor-independent IEEEStd 1149.1 test patterns that are transportable across a wideselection of simulation software and test equipment fromdesign verification through field diagnostics.

Boundary-scan test execution is controlled by thesequencing of TAP signals on the pins of the devices. Eachdevices behavior is determined solely by the states of itsTAP pins. Boundary-scan tools must maintain knowledge ofthe sequences required to exert certain behaviors within adevice and where that device is located in the serial scanpath.

SVF controls the IEEE Std 1149.1 test bus using commandsthat transition the TAP from one steady state to another.Rather than describe the explicit state of the IEEE Std1149.1 bus on every TCK cycle, SVF describes it in terms oftransactions conducted between stable states. For instance,the process of scanning in an instruction is described merelyin terms of the data involved and the desired stable state toenter after the scan has been completed. The Capture,Update, Pause, etc. states are inferred rather than explicitlyrepresented. The data to be scanned in, expected data out,

and compare mask are all grouped in an easilyunderstandable manner. A command is provided to supportdeterministic navigation of TAP states where required.

In addition to supporting higher level depictions of scanoperations, SVF also supports combined serial and paralleloperations. This allows SVF to accommodate ATEenvironments where some stimulus/response is handled viaparallel I/O, and serial signals are accessed via an IEEE Std1149.1-control environment.

SVF also supports the concept of scan offsets. Offsets allowa test to be applied to a component or cluster of logicembedded in the middle of a scan path. In Figure 5-1, adevice exists in multiple instances on a board. Seriallyapplied tests were generated by the designer that areavailable in SVF format. To reuse this test, it is necessary to


64/144

5-10 Data Formats

put all other devices on the scan path into the BYPASSmode. The IEEE Std 1149.1 test controller must thereforecomprehend 24 instruction register bits (8-bit IR x 3 devices)before and 16 instruction register bits (8-bit IR x 2 devices)after the target device. Once in BYPASS, the devicesintroduce three data register bits before and two data registerbits after the target device.

SVF allows a header and trailer to be defined once, whichmaintains the instruction register and data registers of thenontargeted devices in the desired BYPASSstate. Nomodifications are required to the SVF for the device. In

Figure 5-1, if the same test were targeted toward anotherdevice downstream, this would be accommodated merely bychanging the headers and trailers.

U1 U2 U3 U4 U5 U6TDI TDO

Trailer Header

Target

Figure 5-1. Scan Path of Six ICs

The offset approach is capable of installing any instructionregister and data register stimulus, provided these values areconstant for the entire process of applying the SVF devicesequence.

SVF StructureThe SVF file is defined as an ASCII file that consists of a setof SVF statements. Statements are terminated by asemicolon (;) and may continue for more than one line. Themaximum number of ASCII characters per line is 256. SVF isnot case sensitive, and comments can be inserted into anSVF file after an exclamation point (!) or a pair of slashes (//).

Each statement consists of a command and parametersassociated with that specific command. Commands can begrouped into three types: state commands, offsetcommands, and parallel commands.


65/144

5-11

State Commands

State commands are used to specify how the test sequenceswill traverse the IEEE Std 1149.1 TAP state machine. Thefollowing state commands are supported:

SDR Scan data

Date post:	04-Jun-2018
Category:	Documents
Upload:	krish-gokul
View:	212 times
Download:	0 times

TExasJTAG Primer

Documents