SSYA002C BCT8244 LVTH18502 LVTH18504 ABTH18504 LVTH18245 RS-232C JEP106 - Datasheet Archive

 

(JTAG) Testability Primer 1997 Printed in U.S.A. 1096­AL SSYA002C Semiconductor Group IEEE Std 1149.1 (JTAG) Testability 1997

 

IEEE Std 1149.1 (JTAG) Testability Primer 1997 Printed in U.S.A. 1096­AL SSYA002C SSYA002C Semiconductor Group IEEE Std 1149.1 (JTAG) Testability 1997 Printed in U.S.A. 1096­AL SSYA002C SSYA002C Semiconductor Group Primer IEEE Std 1149.1 (JTAG) Testability Primer i IMPORTANT NOTICE Texas Instruments (TI) reserves the right to make changes to its products or to discontinue any semiconductor product or service without notice, and advises its customers to obtain the latest version of relevant information to verify, before placing orders, that the information being relied on is current. TI warrants performance of its semiconductor products and related software to the specifications applicable at the time of sale in accordance with TI's standard warranty. Testing and other quality control techniques are utilized to the extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements. Certain applications using semiconductor products may involve potential risks of death, personal injury, or severe property or environmental damage ("Critical Applications"). TI SEMICONDUCTOR PRODUCTS ARE NOT DESIGNED, INTENDED, AUTHORIZED, OR WARRANTED TO BE SUITABLE FOR USE IN LIFE-SUPPORT APPLICATIONS, DEVICES OR SYSTEMS OR OTHER CRITICAL APPLICATIONS. Inclusion of TI products in such applications is understood to be fully at the risk of the customer. Use of TI products in such applications requires the written approval of an appropriate TI officer. Questions concerning potential risk applications should be directed to TI through a local SC sales office. In order to minimize risks associated with the customer's applications, adequate design and operating safeguards should be provided by the customer to minimize inherent or procedural hazards. TI assumes no liability for applications assistance, customer product design, software performance, or infringement of patents or services described herein. Nor does TI warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of TI covering or relating to any combination, machine, or process in which such semiconductor products or services might be or are used. Copyright © 1996, Texas Instruments Incorporated ii Contents 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 Machines Corporation. Microsoft is a registered trademark of Microsoft Corporation. Scan Engine, ThunderCELL, ThunderLAN, TI, UBT, and Widebus are trademarks of Texas Instruments Incorporated. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. SUPPORT Device Boundary-Scan Description Language (BSDL) files and other information regarding Texas Instruments IEEE Std 1149.1/JTAG/boundary-scan products are maintained on the World-Wide Web at URL http://www.ti.com/sc/docs/jtag/ jtaghome.htm; or, on the main Texas Instruments home page at URL http://www.ti.com. Search for keywords JTAG and testability. iii iv Contents Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overall Rationale for Design for Test . . . . . . . . . . . . . . . . . Reduced Cost and Higher Quality . . . . . . . . . . . . . . . . . . . Benefits Over Standard Test Methods . . . . . . . . . . . . . . . . Standard Test Solutions Versus Proprietary Solutions . . . An Industry Standard - IEEE Std 1149.1-1990 (JTAG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 1-2 1-3 1-3 1-5 Benefits of Testability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traditional Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Efficient Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lower Cost for Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Production Time Savings . . . . . . . . . . . . . . . . . . . . . . . . . . . Easier Board-Level Isolation . . . . . . . . . . . . . . . . . . . . . . . . Simple Access to Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2-1 2-1 2-1 2-2 2-2 2-2 1-5 Boundary-Scan Architecture and 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 BYPASS Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 SAMPLE/PRELOAD Instruction . . . . . . . . . . . . . . . . 3-12 EXTEST Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 IEEE Std 1149.1 Optional Instructions . . . . . . . . . . . . . . . 3-13 INTEST Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 RUNBIST Instruction . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 CLAMP Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 HIGHZ Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 IDCODE Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 USERCODE Instruction . . . . . . . . . . . . . . . . . . . . . . . 3-14 Obtaining IEEE Std 1149.1-1990 . . . . . . . . . . . . . . . . . . . 3-15 v Using DFT in ASICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Design-for-Test Considerations . . . . . . . . . . . . . . . . . . . . . . The Need for Testability . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test-Time Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time to Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Coverage and Cost of Ownership . . . . . . . . . . . . . . . Developing Testability Strategies . . . . . . . . . . . . . . . . . . . . 4-1 4-1 4-2 4-3 4-3 4-5 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 . . . . . . . . . . . . . . . . . . . Test Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Built-In Self-Test (BIST) Methodology . . . . . . . . . . . . . . . . Internal Scan Test Methodology . . . . . . . . . . . . . . . . . . . . . Design Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IC Design Implementation . . . . . . . . . . . . . . . . . . . . . . IC Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using SVF for IC Design Validation . . . . . . . . . . . . . . Data Passed to Board Designer . . . . . . . . . . . . . . . . . Board Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partitioned Scan Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi 6-1 6-2 6-3 6-3 6-4 6-4 6-6 6-6 6-7 6-8 6-8 6-8 Contents 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 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16 Backplane Multidrop Environment . . . . . . . . . . . . . . . . . . 7-17 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21 Embedded Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23 Boundary-Scan Test Flow . . . . . . . . . . . . . . . . . . . . . . . . . 7-24 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24 Detailed Description . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28 vii Product Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IEEE Std 1149.1-Compatible Components . . . . . . . . . . . . Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IEEE Std 1149.1 (JTAG) Boundary-Scan Logic . . . . . . . . Bus Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Universal Bus Transceiver (UBTTM) . . . . . . . . . . . . . . Scan Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1 8-1 8-1 8-2 8-3 8-4 8-5 Other Support and Learning Products . . . . . . . . . . . . . Scan Educator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supporting Documentation Included . . . . . . . . . . . . . CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testability Video Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix A - Abbreviations/Acronyms . . . . . . . . . . . Appendix B - Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix C - References . . . . . . . . . . . . . . . . . . . . . . . . Appendix D - Internet Starting Points . . . . . . . . . . . . . 9-1 9-1 9-1 9-2 9-3 9-3 9-3 9-4 A-1 B-1 C-1 D-1 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1 viii Contents Illustrations 1-1 2-1 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 4-1 4-2 4-3 4-4 4-5 4-6 4-7 5-1 6-1 6-2 6-3 7-1 7-2 7-3 7-4 7-5 7-6 7-7 7-8 7-9 7-10 7-11 Chip Through System-Level Test . . . . . . . . . . . . . . 1-1 Boundary-Scan Testing Using the IEEE Std 1149.1 Bus . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Boundary-Scan Example . . . . . . . . . . . . . . . . . . . . . 3-2 Boundary-Scan Architecture . . . . . . . . . . . . . . . . . . 3-4 TAP Controller State Diagram . . . . . . . . . . . . . . . . . 3-5 TAP Control Output Interconnect Diagram . . . . . . 3-7 General Instruction Register Architecture . . . . . . . 3-8 Test Data Register Architecture . . . . . . . . . . . . . . . 3-10 Conceptual View of a Control-and-Observe BSC . . . . . . . . . . . . . . . . . . . 3-11 Device Identification Register Structure . . . . . . . . 3-11 Fault Grade Versus Development Time . . . . . . . . . 4-3 Economic Trade-Off for a Testable Design . . . . . . 4-4 Defect Level Versus Fault Coverage . . . . . . . . . . . 4-5 Motorola and Delco Study Results . . . . . . . . . . . . . 4-6 ASIC ppm Versus PCB ppm Rate . . . . . . . . . . . . . . 4-7 Cost of Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 Testability Development Flow . . . . . . . . . . . . . . . . 4-11 Scan Path of Six ICs . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Initial DFT Concerns . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Designing Testability for ASICs and Boards . . . . . 6-4 Debug and Verification of a Boundary-Scan Design . . . . . . . . . . . . . . . . . . . . . . . 6-7 Etch/Interconnect Testing . . . . . . . . . . . . . . . . . . . . . 7-2 Open-Etch Condition . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Open-Solder-Joint Condition . . . . . . . . . . . . . . . . . . 7-3 Short-to-Ground Condition . . . . . . . . . . . . . . . . . . . . 7-3 Bond-Wire Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Cluster Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Backplane Open-Circuit Fault . . . . . . . . . . . . . . . . . 7-8 PWB Connector Fault . . . . . . . . . . . . . . . . . . . . . . . . 7-8 Backplane Short-to-Ground Fault . . . . . . . . . . . . . . 7-9 Block Diagram of Simplified Boundary-Scannable RAM Interface . . . . . . . . . . 7-13 Testing Embedded RAM . . . . . . . . . . . . . . . . . . . . . 7-15 ix 7-12 7-13 7-14 7-15 7-16 7-17 7-18 7-19 8-1 x Testing Embedded ROM . . . . . . . . . . . . . . . . . . . . 7-16 Backplane Ring Configuration . . . . . . . . . . . . . . . . 7-18 Backplane Star Configuration . . . . . . . . . . . . . . . . 7-19 Backplane With ASP-Equipped Boards . . . . . . . . 7-20 General Boundary-Scan Test . . . . . . . . . . . . . . . . . 7-25 Assembly Verification Flow . . . . . . . . . . . . . . . . . . 7-26 Automated Functional Verification and Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27 Interactive Verification and Fault Isolation . . . . . . 7-28 TI's Family of IEEE Std 1149.1 (JTAG) Boundary-Scan Logic . . . . . . . . . . . . . . . . . . . . . . . . 8-2 Contents Tables 1-1 1-2 5-1 5-2 7-1 High-Technology Product Scenarios . . . . . . . . . . . . . 1-3 Time to Develop Test Programs (in Man-Months) . . 1-4 SVF TAP State Names . . . . . . . . . . . . . . . . . . . . . . . 5-13 Stable-State Path Examples . . . . . . . . . . . . . . . . . . 5-14 Access Rates of IEEE Std 1149.1 Devices With and Without BIST . . . . . . . . . . . . . . . . . . . . . . . 7-14 8-1 IEEE Std 1149.1 UBTs Replace 50+ Bus Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5 xi xii Contents Chapter 1 Introduction Design for test (DFT), also known as design for testability, is a process that incorporates rules and techniques in the design of a product to make testing easier. Structured design for test is a system methodology rather than a collection of discrete techniques. This methodology impacts all phases of a product's life, from device circuit design through field service. Design for test is used to manage complexity, minimize development time, and reduce manufacturing costs. Testing has two major aspects: control and observation. To test any system it is necessary to put the system into a known state, supply known input data (test data), and observe the system to see if it performs as designed and manufactured. If control or observation cannot be carried out, there is no way to know empirically if the system performs as it should. During the normal product development flow, testing (it may be known by different names) takes place at many points during the process. If testing is considered at the chip design level, its benefits can be used at all levels of electronic assembly, from chip through system level. See Figure 1-1. IC Test Board Test Box Test System Test Figure 1-1. Chip Through System-Level Test 1-1 Designers usually test various functions to validate their design. Manufacturing and customer groups subject the design to an assortment of unique criteria to see if the concept works in practice. Is it manufacturable? Will it stand up to real-world operating conditions? Will repair be cost efficient? In addition to direct testability considerations, production managers want features designed into the product to help them minimize scrap and manufacturing costs. Good system-testability methodology provides an integrative function throughout the product development cycle and allows materials created during an early phase of development to be reused in later phases. Various chip designers have used this integration feature as a tool to help manage the development of complex products. Testability provides companies with a firmer grasp on the economic and market-window constraints due to product development. One major workstation manufacturer claimed: Test program development would have been nearly impossible without scan techniques. Chip-level test development time fell from 1 man-year to about 20 hours. Board-level test development time fell from multiple man-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 a unique set of problems. Although modern circuit density, high device speed, surface-mount packaging, and complex board-interconnect technology have a positive influence on state-of-the-art electronic systems, these factors can adversely affect ability to verify correct design and operation. Increased complexity and lack of physical access to circuitry makes for costly and time-consuming testing using traditional test techniques. 1-2 Introduction 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 an expeditious alternative to the expense of full testing gamble their technical credibility in the marketplace and expose themselves to the high cost of product returns. In today's global electronics marketplace, a manufacturer who delivers poorly tested products does not remain competitive. The cost for detecting and identifying faults using traditional test methods increases by an order of magnitude as a circuit's level of complexity increases. These increased costs and development time reduce profit margins, delay product introduction, and reduce time-to-market windows. An increasing number of companies have simultaneously improved their product quality and profit margins by adopting system-level (integrative) design methods. Design for test is one such system-level approach. Benefits Over Standard Test Methods Time to market is more important than ever in the high technology marketplace. Companies that can produce quality products with a short product development cycle-time have a competitive advantage. Designing testability into a system can play an important role in introducing a new high-technology product with an expected five-year life cycle to market on time. Table 1-1 shows various product development time/budget scenarios and the resulting project profitability. Table 1-1. High-Technology Product Scenarios { Product A To Market: Budget: Available Profit Over 5 Years: Product B Product C on time on time 6 mos. late on 50% over on 100% 96% 66% {Source:McKinsey & Company 1-3 Adding testability to a product increases design time and costs, while reducing costs of design validation, manufacturing test, and system maintenance. The system design phase of product development represents only 15 percent of a product's total life-cycle cost. However, the system design phase has a 70-percent impact on a product's operation and support costs over the product's total life (source: Mitre Corporation, 1987 Government Microcircuit Applications Conference). The majority of faults found on boards, such as solder joints (shorts and opens), components (wrong device, missing device, wrong orientation, wire-bond failure, and stuck pins), etch integrity, and connector faults, make up over 95 percent of failures found. A structured technique such as boundary-scan testing allows for pins-out testing to easily detect these failures (source: Teradyne). The additional cost of designing testability into a system during the system design phase can be more than offset over the product's total life. Design cycle times have shortened significantly over the years while test program development time has increased, necessitating that companies adopt structured or repeatable methodologies. Table 1-2 documents the increase in test program development time as test requirements increase. Table 1-2. Time to Develop Test Programs (in Man-Months) 1987­1980 3­6 months 1981­1983 6­12 months 1984­1986 9­18 months 1987­1990 12­24 months Source: Texas Instruments 1-4 Introduction Standard Test Solutions Versus Proprietary Solutions Embedded test, emulation, and maintenance circuitry are well defined and understood within the test community. Previously, the lack of standards caused these structures to be implemented in an ad hoc and proprietary manner. Since proprietary solutions are usually more expensive and labor intensive, the added costs further limited the use of these test circuits. Boundary-scan testing combined with a common test bus interface and test protocol has these benefits: Provides a standard and cost-effective solution to traditional test problems Opens new applications The ability to reuse previously developed test data and to use less costly test equipment means that this approach yields products that are less expensive to manufacture. An Industry Standard - IEEE Std 1149.1-1990 (JTAG) In 1985, an ad hoc group composed of key electronic manufacturers joined to form the Joint Test Action Group (JTAG). JTAG had over 200 members around the world, including major electronics and semiconductor manufacturers. This group met to establish a solution to the problems of board test and to promote a solution as an industry standard. The solution, which became IEEE Std 1149.1-1990, IEEE Standard Test Access Port and Boundary-Scan Architecture, is the basis for Texas Instruments (TITM) testability products. IEEE Std 1149.1 allows test instructions and data to be serially loaded into a device and enables the subsequent test results to be serially read out. Every IEEE Std 1149.1-compatible device has four additional pins - two for control and one each for input and output serial test data. To be compatible, a component must have certain basic test features, but IEEE Std 1149.1 allows designers to add test features to meet their own unique requirements. The specification was adopted as an IEEE standard in February 1990. 1-5 1-6 Introduction Chapter 2 Benefits of Testability This chapter explains how designing testability into devices eliminates problems associated with traditional testing and improves quality and efficiency. Traditional Testing Traditional board-level and device-level testing consumes a great deal of time and requires special hardware and complex automatic test equipment (ATE) for each type of board or device. This results in increased costs and development time. In addition, extensive testing is necessary for the evermore stringent reliability standards and performance standards in the defense, aerospace, automotive, computer, and communications industries. These extensive tests can delay the market introduction of products, disrupt just-in-time (JIT) manufacturing flows, and limit the productivity of standard ATE operations. This creates numerous problems because time to market is more important than ever in the high-technology marketplace. Companies that produce quality products with a short product-development cycle time have a competitive advantage. Efficient Testing An innovative approach to the problems inherent with traditional 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 nodes while the component or circuit is embedded within the system. During the same scan, the previous condition of each node is scanned out. This saves test time and reduces the number of test vectors needed. Lower Cost for Testing The additional cost of designing testability into a system during the design phase is more than offset over the product's total life. This is accomplished by reducing the test program development time, minimizing fixture complexity, and allowing for the use of lower-cost ATE solutions. Another cost benefit is the economy of scale gained by having a standard test approach that spans design, test, manufacture, field repairs, and maintenance. 2-1 Production Time Savings Board-level boundary-scan testing is easily implemented using TI's line of IEEE Std 1149.1 testability devices, such as: WidebusTM and octal bus interfaces Scan-support devices ASIC and DSP These IEEE Std 1149.1-compliant devices are included in board 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 serial IEEE Std 1149.1 test bus under the control of boundary-scan test software. Easier Board-Level Isolation Fault isolation on a printed circuit board can be greatly improved by electronically isolating suspect areas using boundary-scannable devices. The IEEE Std 1149.1 test bus controls boundary-scannable devices to place them in EXTEST for pins-out testing. This effectively partitions or isolates circuitry for separate testing. Partitioning a system using IEEE Std 1149.1-compliant devices reduces the number of patterns required for testing each circuit area. See Figure 2-1 for an example of a design than can be partitioned. Simple Access to Circuits Highly integrated, modern, multilayer systems or lCs with fine-pitch pins are virtually impossible to access using manual probes or ATE. Some boards require extensive fixturing or redesign before they can be tested effectively. TI's testability devices with boundary-scan architecture eliminate physical access problems. These parts provide the designer with testability for the most complex and hard-to-access circuits, and add controllability of test circuits. In addition, a designer can easily observe and control internal device functions. 2-2 Benefits of Testability TDI TDO UBT (buffer) Buffer 'BCT8244 BCT8244 UBT Data (xcvr) Control 'LVTH18502 LVTH18502 TDO Address Memory Array Logic Buffer 'BCT8244 BCT8244 Microprocessor 'LVTH18504 LVTH18504 'ABTH18504 ABTH18504 UBT (latch) Data TDI 'LVTH18245 LVTH18245 TDO TDI IEEE Std 1149.1 Bus TDI TDO TCK Parallel Data In/Out TMS Edge Connector Figure 2-1. Boundary-Scan Testing Using the IEEE Std 1149.1 Bus 2-3 2-4 Benefits of Testability Chapter 3 Boundary-Scan Architecture and IEEE Std 1149.1 Boundary scan is a special type of scan path with a register added at every I/O pin on a device. Although this requires the addition of a special test latch on some pins, the technique offers several important benefits. The most obvious benefit offered by the boundary-scan technique is allowing fault isolation at the component level. Such an isolation requirement is common in telecomunications switching environments where prompt field repair is critical. A major problem driving the development of IEEE Std 1149.1 boundary scan is the adverse effect of surface-mount technology. The inclusion of a boundary-scan path in surface-mount components, in many cases, affords the only way to perform continuity tests between devices. By placing a known value on an output buffer of one device and observing the input buffer of another interconnected device, it is easy to see if the printed wiring board (PWB) net is electrically connected. Failure of this simple test indicates broken circuit traces, cold solder joints, solder bridges, or electrostatic-discharge (ESD) induced failures in an IC buffer - all common problems on PWBs. A less-obvious advantage of the boundary-scan methodology is the ability to apply predeveloped functional pattern sets to the I/O pins of the IC by way of the scan path. IC manufacturers and ASIC developers create functional pattern sets for DC test purposes. Subsets of these patterns can be reused for in-circuit functional IC testing. Reusing existing patterns in the development of system diagnostics can save large amounts of development resources, especially if many of the ICs in a system have embedded boundary-scan paths. IEEE Std 1149.1 is a common protocol and boundary-scan architecture developed into an industrial standard after thousands of man hours of cooperative development by approximately 200 major international electronics firms. Early contributors in the development of IEEE Std 1149.1 were AT&T, DECTM, Ericsson, IBMTM, Nixdorf, Philips, Siemens, and TI. These companies recognized that only a nonproprietary architecture would encourage companies to 3-1 offer the compatible integrated circuits, test equipment, and CAD software needed to bring product development, manufacturing, and test costs under control in today's competitive electronics marketplace. Many people believe that boundary-scan architecture will do for development, manufacturing, and test what the RS-232C RS-232C standard did for computer peripherals. Boundary-Scan Overview Boundary scan is the application of a scan path at the boundary (I/O) of ICs to provide controllability and observability access via scan operations. Figure 3-1 shows an IC with an application-logic section and related input and output, and a boundary-scan path consisting of a series of boundary-scan cells (BSCs), in this case one BSC per IC function pin. NDI BSC Application Logic NDO BSC TDI TDO Figure 3-1. Boundary-Scan Example The BSCs are interconnected to form a scan path between the host IC's test data input (TDI) pin and test data output (TDO) pin. During normal IC operation, input and output signals pass freely through each BSC, from the normal data input (NDI), to the normal data output (NDO). However, when the boundary-test mode is entered, the IC's boundary is controlled in such a way that test stimulus can be shifted in and applied from each BSC output (NDO), and test response can be captured at each BSC input (NDI) and shifted out for inspection. External testing of wiring interconnects and neighboring ICs on a board assembly is accomplished by applying test stimulus from the output BSCs and capturing test response at the input BSCs. As an option, internal testing of the application logic can be accomplished by 3-2 Boundary-Scan Architecture and IEEE Std 1149.1 applying test stimulus from the input BSCs and capturing test response at the output BSCs. The implementation of a scan path at the boundary of IC designs provides an embedded testing capability that can overcome the physical access problems in current and future board designs. Test Interface and Boundary-Scan Architecture Figure 3-2 shows the IEEE Std 1149.1 architecture. The architecture consists of an instruction register, a bypass register, a boundary-scan register (highlighted), optional user data 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 series of boundary-scan cells (BSCs), is shown at the input and output boundary of the IC. The instruction register and data registers are separate scan paths arranged between the primary test data input (TDI) pin and primary test data output (TDO) pin. This architecture allows the TAP to select and shift data through one of the two types of scan paths, instruction or data, without accessing the other scan path. 3-3 BSC BSC Core Logic BSC Output Pins BSC BSC BSC Input Pins BSC BSC OE BSC Boundary-Scan Register User Data Register Bypass Resister TDI Instruction Register TMS TCK TAP TDO Note: The boundary-scan register is shifted TDI to TDO. Figure 3-2. Boundary-Scan Architecture 3-4 Boundary-Scan Architecture and IEEE Std 1149.1 Test Access Port and Operation The TAP is controlled by the test clock (TCK) and test mode select (TMS) inputs. These two inputs determine whether an instruction register scan or data register scan is performed. The TAP consists of a small controller design, driven by the TCK input, which responds to the TMS input as shown in the state diagram in Figure 3-3. The IEEE Std 1149.1 test bus uses both clock edges of TCK. TMS and TDI are sampled on the rising edge of TCK, while TDO changes on the falling edge of TCK. Test-Logic-Reset 1 0 1 1 1 Run-Test/Idle Select-DR-Scan 0 Select-IR-Scan 0 0 Capture-DR 1 1 Capture-IR 0 0 Shift-IR Shift-DR 0 1 1 0 1 1 Exit1-DR Exit1-IR 0 0 Pause-IR Pause-DR 0 1 1 Exit2-DR 0 0 1 1 Update-DR 1 0 Exit2-IR 0 Update-IR 1 0 Note: The value shown adjacent to each state transition in this figure represents the signal present at TMS at the rising edge of TCK. Figure 3-3. TAP Controller State Diagram 3-5 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 is that only one steady state exists for the condition when TMS is set high: the Test-Logic-Reset state. This means that a reset of the test logic can be achieved within five TCKs or less by setting the TMS input high. At power up, or during normal operation of the host IC, the TAP is forced into the Test-Logic-Reset state by driving TMS high and applying five or more TCKs. In this state, the TAP issues a reset signal that places all test logic in a condition that does not impede normal operation of the host IC. When test access is required, a protocol is applied via the TMS and TCK inputs, causing the TAP to exit the Test-Logic-Reset state and move through the appropriate states. From the Run-Test/Idle state, an instruction register scan or a data register scan can be issued to transition the TAP through the appropriate states shown in Figure 3-3. The states of the data register scan and instruction register scan blocks are mirror images of each other, adding symmetry to the protocol sequences. The first action that occurs when either block is entered is a capture operation. For the data registers, the Capture-DR state is used to capture (or parallel load) the data into the selected serial data path. If the BSR is the selected data register, the normal data inputs (NDIs) are captured during this state. In the instruction register, the Capture-IR state is used to capture status information into the instruction register. From the Capture state, the TAP transitions to either the Shift or Exit1 state. Normally, the Shift state follows the Capture state so that test data or status information can be shifted out for inspection and new data shifted in. Following the Shift state, the TAP either returns to the Run-Test/Idle state via the Exit1 and Update states or enters the Pause state via Exit1. The reason for entering the Pause state is to temporarily suspend the shifting of data through either the selected data register or instruction register while a required operation, such as refilling a tester memory buffer, is performed. From the Pause state, shifting can resume by re-entering the Shift state via the Exit2 state or be terminated by entering the Run-Test/Idle state via the Exit2 and Update states. 3-6 Boundary-Scan Architecture and IEEE Std 1149.1 Upon entering the data register scan or instruction register scan blocks, shadow latches in the selected scan path are forced to hold their present state during the capture and shift operations. The data being shifted into the selected scan path is not output through the shadow latch until the TAP enters the Update-DR or Update-IR state. The Update state causes the shadow latches to update (or parallel load) with the new data that has been shifted into the selected scan path. Figure 3-4 shows the TAP control output signals, along with the instruction register and data register interconnects. MSB TDI LSB Instruction Register 1 TDO 0 CLOCKIR UPDATEIR SHIFTIR TMS RESET* TAP TCK SELECT ENABLE SHIFTDR UPDATEDR CLOCKDR Data Register MSB LSB Figure 3-4. TAP Control Output Interconnect Diagram 3-7 IEEE Std 1149.1 Registers This section contains descriptions of the required and optional registers specified in IEEE Std 1149.1-1990. Instruction Register (Required) The instruction register is responsible for providing the address and control signals required to access a particular data register in the scan path. The instruction register is accessed when the TAP receives an instruction register scan protocol. During an instruction register scan operation the SELECT output from the TAP (Figure 3-4) selects the output of the instruction register to drive the TDO pin. A general instruction register architecture is shown in Figure 3-5. STATUS 0 STATUS 1 STATUS 6 STATUS 7 7 TDI CLOCKIR UPDATEIR 1 0 TDO Instruction Shift Register SHIFTIR RESET* 6 7 6 1 0 Instruction Shadow Latch 7 6 1 0 Instruction Register Outputs Figure 3-5. General Instruction Register Architecture The instruction register consists of an instruction shift register and an instruction shadow latch. The instruction shift register (Figure 3-5) consists of a series of shift register bits arranged to form a single scan path between the TDI and TDO pins of the host IC. During instruction register scan operations, the TAP exerts control via the instruction register shift enable (SHIFTIR) and instruction register clock 3-8 Boundary-Scan Architecture and IEEE Std 1149.1 (CLOCKIR) signals to cause the instruction shift register to preload status information and shift data from TDI to TDO. Both the preload and shift operations occur on the rising edge of TCK; however, the data shifted out from the host IC from TDO occurs on the falling edge of TCK. The status inputs are user-defined observability inputs, except for the two least-significant bits, which are always 01 for scan-path testing purposes. (The instruction register has a minimum length of two bits.) The instruction shadow register (Figure 3-5) consists of a series of latches, one latch for each instruction shift register bit. During an instruction register scan operation, the latches remain in their present state. At the end of the instruction register scan operation, the instruction register update (UPDATEIR) input updates the latches with the new instruction installed in the instruction shift register. When activated, the RESET* input sets the instruction shadow register to the value of the BYPASS instruction (or IDCODE instruction, if it is supported). This forces the device into its normal functional mode and selects the bypass register (or device identification register, if one is present). Data Registers IEEE Std 1149.1 requires two data registers; boundary-scan register and bypass register, with a third, optional, device identification register. Additional user-defined data registers can be included. The data registers are arranged in parallel from the primary TDI input to the primary TDO output. The instruction register supplies the address that allows one of the data registers to be accessed during a data register scan operation. During a data register scan operation, the addressed scan register receives TAP control via the data register shift enable (SHIFTDR) and data register clock (CLOCKDR) inputs to preload test response and shift data from TDI to TDO. During a data register scan operation, the SELECT output from the TAP (Figure 3-4) selects the output of the data register to drive the TDO pin. When one scan path in the data register is being accessed, all other scan paths remain in their present state. 3-9 Boundary-Scan Register Device Identification Register G Optional Design-Specific Test Data Register From TDI Optional MUX To TDO MUX Design-Specific Test Data Register Optional Design-Specific Test Data Register Optional Bypass Register Clock and Control Signals From Instruction Register, TAP Controller, etc. 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 the boundary of the host IC. The BSCs provide the controllability and observability features required to perform boundary-scan testing as described in the Boundary-Scan Overview section of this chapter. Shadow latches in the BSCs, driving the NDO outputs remain 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 updates the shadow latches with the new boundary test pattern to be applied from the NDO outputs of the BSCs. Figure 3-7 shows a conceptual view of a control-and-observe BSC. 3-10 Boundary-Scan Architecture and IEEE Std 1149.1 IR Decode Mode Serial Output ShiftDR G NDI 1 G 1 1 Serial Input 1 1D C1 NDO 1D C1 ClockDR UpdateDR Figure 3-7. Conceptual View of a Control-and-Observe BSC Bypass Register (Required) - The bypass register consists of a single scan register bit. When selected, the bypass register provides a single-bit scan path between TDI and TDO. Thus, the bypass register allows abbreviating the scan path through devices that are not involved in the test. The bypass register is selected when the instruction register is loaded with a pattern of all ones to satisfy the IEEE Std 1149.1 BYPASS instruction requirement. Device Identification Register (Optional) - The device identification register is an optional register, defined by IEEE Std 1149.1, to identify the device's manufacturer, part number, revision, and other device-specific information. Figure 3-8 shows the bit assignments defined for the device identification register. These bits can be scanned out of the device identification register after its selection. MSB LSB 1 Version (bits 31­28) Part Number (bits 27­12) Fixed (bit 0) Manufacturer Identity (bits 11­1) Figure 3-8. Device Identification Register Structure Although the device identification register is optional, IEEE Std 1149.1 has dedicated an instruction to select 3-11 this register. The device identification register is selected when the instruction register is loaded with the IDCODE instruction, the bit code of which is defined by the vendor. Manufacturer's identity codes (bit1 through bit11) are assigned, maintained, and updated by the EIA/JEDEC office. Any company can be added to the JEDEC Standard Manufacturer's Identification Code (Publication JEP106 JEP106) by request to the JEDEC office at 202-457-4973. IEEE Std 1149.1 Required Instructions IEEE Std 1149.1 defines nine test instructions. Of the nine instructions, three are required and six are optional. The following subsections contain brief descriptions of each required test instruction. BYPASS Instruction The required BYPASS instruction allows the IC to remain in a functional mode and selects the bypass register to be connected between TDI and TDO. The BYPASS instruction allows serial data to be transferred through the IC from TDI to TDO without affecting the operation of the IC. The bit code of this instruction is defined as all ones by IEEE Std 1149.1. SAMPLE/PRELOAD Instruction The required SAMPLE/PRELOAD instruction allows the IC to remain in its functional mode and selects the boundary-scan register to be connected between TDI and TDO. During this instruction, the boundary-scan register can be accessed via a data scan operation, to take a sample of the functional data entering and leaving the IC. This instruction is also used to preload test data into the boundary-scan register before loading an EXTEST instruction. The bit code for this instruction is defined by the vendor. 3-12 Boundary-Scan Architecture and IEEE Std 1149.1 EXTEST Instruction The required EXTEST instruction places the IC into an external boundary-test mode and selects the boundary-scan register to be connected between TDI and TDO. During this instruction, the boundary-scan register is accessed to drive test data off-chip via the boundary outputs and receive test data off-chip via the boundary inputs. The bit code of this instruction is defined as all zeroes by IEEE Std 1149.1. IEEE Std 1149.1 Optional Instructions The following subsections contain brief descriptions of the optional IEEE Std 1149.1 instructions. INTEST Instruction The optional INTEST instruction places the IC in an internal boundary-test mode and selects the boundary-scan register to be connected between TDI and TDO. During this instruction, the boundary-scan register is accessed to drive test data on-chip via the boundary inputs and receive test data on-chip via the boundary outputs. The bit code of this instruction is defined by the vendor. RUNBIST Instruction The optional RUNBIST instruction places the IC in a self-test mode, enables a comprehensive self-test of the IC's core logic, and selects a user-specified data register to be connected between TDI and TDO. During this instruction, the boundary outputs are controlled so that they cannot interfere with neighboring ICs during the RUNBIST operation. Also, the boundary inputs are controlled so that external signals cannot interfere with the RUNBIST operation. The bit code of this instruction is defined by the vendor. CLAMP Instruction The optional CLAMP instruction sets the outputs of an IC to logic levels determined by the contents of the boundary-scan register and selects the bypass register to be connected between TDI and TDO. Before loading this instruction, the contents of the boundary-scan register can be preset with the SAMPLE/PRELOAD instruction. During this instruction, data can be shifted through the bypass register from TDI to 3-13 TDO without affecting the condition of the outputs. The bit code of this instruction is defined by the vendor. HIGHZ Instruction The optional HIGHZ instruction sets all outputs (including two-state as well as three-state types) of an IC to a disabled (high-impedance) state and selects the bypass register to be connected between TDI and TDO. During this instruction, data can be shifted through the bypass register from TDI to TDO without affecting the condition of the IC outputs. The bit code of this instruction is defined by the vendor. IDCODE Instruction The optional IDCODE instruction allows the IC to remain in its functional mode and selects the optional device identification register to be connected between TDI and TDO. The device identification register (see Figure 3-8) is a 32-bit shift register containing information regarding the IC manufacturer, device type, and version code. Accessing the device identification register does not interfere with the operation of the IC. Also, access to the device identification register should be immediately available, via a TAP data-scan operation, after power-up of the IC or after the TAP has been reset using the optional TRST* pin or by otherwise moving to the Test-Logic-Reset state. The bit code of this instruction is defined by the vendor. USERCODE Instruction The optional USERCODE instruction allows the IC to remain in its functional mode and selects the device identification register to be connected between TDI and TDO. During the USERCODE instuction, the optional 32-bit device identification register captures user-defined information about the IC. Accessing the device identification register does not interfere with the operation of the IC. The bit code of this instruction is defined by the vendor. 3-14 Boundary-Scan Architecture and IEEE Std 1149.1 Obtaining IEEE Std 1149.1-1990 To learn more about IEEE Std 1149.1, please refer to the publications, IEEE Standard Test Access Port and Boundary-Scan Architecture, IEEE Std 1149.1-1990 (includes IEEE Std 1149.1a-1993) and Supplement to IEEE Std 1149.1-1990, IEEE Standard Test Access Port and Boundary-Scan Architecture, IEEE Std 1149.1b-1994. These documents are available through IEEE (1-800-678-IEEE 1-800-678-IEEE). IEEE Std 1149.1-1990/IEEE 1-1990/IEEE Std 1149.1a-1993 is also available from Texas Instruments on CD-ROM (see Chapter 9, Other Support and Learning Products). 3-15 3-16 Boundary-Scan Architecture and IEEE Std 1149.1 Chapter 4 Using DFT in ASICs The concern most often voiced by application-specific integrated circuit (ASIC) users is that of testability. This chapter is intended to provide an understanding of ASIC testability that can be used for developing test strategies when designs are being initiated. Design-for-Test Considerations Designing testability into any circuit affects the hardware to some degree. Additional logic will probably have to be added. This additional logic increases the amount of silicon required to implement the design. The savings from enhanced testability do not usually show up until the cycle time and testing cost of the circuit and its end system are analyzed. Fault simulation is an important part of designing for testability. This technique enables you to evaluate your test patterns to determine whether these patterns detect faults. Faults may occur during either the design-tooling stage or the circuit-fabrication stage. A fault simulator uses fault models, such as a node shorted to power (stuck-at-one) or a node shorted to ground (stuck-at-zero), and compares the response of a fault-free circuit with the response of a faulty circuit. If the response of the fault-free circuit is different than the response of the faulty circuit, then the test patterns have detected the fault. By faulting all the nodes in the circuit, the fault simulator produces the test-pattern fault grade or fault coverage. The fault coverage is the percentage of faults detected among the total faults. The higher the fault coverage, the better the test pattern set separates a faulty circuit from a fault-free circuit. After determining which faults have not been detected by the current set of test patterns, additional test patterns can be generated to detect those faults. Adoption of design-for-test principles early in the design process ensures the maximum testability for the minimum effort. These guidelines emphasize that test is a part of the design flow, not a process that is done at the end of the design cycle. 4-1 Three basic elements must come together to make a successful ASIC circuit: Logic design, including schematic capture, library selection, synthesis, and simulation Logic testability, including fault-detection and test-application criteria within predefined cost and time-scale budgets Vendor's manufacturing capability, including processing and packaging The Need for Testability Most engineers involved in the design of ASIC devices are familiar with the trade-offs between gate arrays, standard cells, and full custom devices. They are also familiar with the vendor selection process. The aspect of test capability and testability is often overlooked. Testability could be ignored when typical designs were only a few thousand gates. These designs were implemented first and then turned over to a test engineer or to a vendor to create a test program for production. As design complexities increased, this approach to testing became futile. Successful high-density ASIC design and manufacturing demand that circuits be built with testability incorporated into the design process. Although testability imposes additional constraints in the design phase, design verification and test can be unmanageable, if ignored until the design is completed and testability is handled as a postdesign insertion. In fact, the design constraints are overwhelmingly balanced by improved testability, which adds value to the device throughout manufacturing and system life. 4-2 Using DFT in ASICs Test-Time Cost Test cost, as it relates to time, is a simple calculation. Most commercial testers cost between $2 million and $3 million. Under normal circumstances, the tester depreciation, plant, operator, and support personnel costs are between 10 and 20 cents per test second. Brute-force test approaches often generate a large number of test patterns. Since test patterns are run at multiple power-supply values and possibly at multiple temperatures, inefficient pattern sets can severely impact the test costs of a complex ASIC device. Time to Market Surveys indicate that 40 percent of the development cycle time for an ASIC device is required for test insertion and test-pattern generation. This figure is expected to increase as device complexity increases. The intent of a design-for-test strategy is to achieve high fault-detection test programs in reduced time (Figure 4-1). The obvious cycle-time reductions result from designed-in testability (elimination of iterative redesigns resulting from poor design practices), and from automatic test-pattern generation (ATPG). 100 With DFT Strategies Fault Grade % 80 60 Without DFT Strategies 40 20 0 Hours Days Weeks Months Time to Develop Test Patterns Figure 4-1. Fault Grade Versus Development Time 4-3 Figure 4-2 shows the economic relationship between time to market and system manufacturing and field maintenance costs. Point 1 represents the case where market-entry timing forces a constraint on the development time. Since 40 percent of this time is expended in inserting testability, the temptation is to rush to market with devices that are not completely testable or tested. The result is a higher-than-desirable manufacturing and field-maintenance cost. Point 2 represents the case where DFT and ATPG techniques are employed to develop devices that are completely tested. This situation allows an economic optimum that is more favorable to long-term manufacturing and maintenance costs. Cost $ g Economic Optimum 1 Without DFT Strategy Economic Optimum 2 g With DFT Strategy Manufacturing and Field Cost Fault Coverage % Development and Time-to-Market Cost Total Cost Figure 4-2. Economic Trade-Off for a Testable Design A less obvious result of a DFT strategy is the reduction of debug time. The designer must make certain assumptions about system requirements. Often, a new device does not work in the system environment and requires debugging. If the device is designed for controllability and observability access, the debugging process is enhanced. Conversely, if these two features are overlooked, debugging and manufacturing can be significantly harder to accomplish, if not impossible. Oscilloscopes and logic analyzers are not very effective in debugging systems utilizing complex ASIC devices in a surface-mount environment. 4-4 Using DFT in ASICs Fault Coverage and Cost of Ownership Figure 4-3 shows the trade-off between time to market and manufacturing and field-maintenance costs. The horizontal factor on this figure is fault coverage. The relationship between fault coverage and device defect level is well documented. 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 50% Defect Level % 6 5 60% 4 70% 3 80% 2 90% 1 0 90 91 92 93 94 95 96 97 98 99 100 50% Process Yield - 6.70 6.04 5.39 4.74 4.07 3.41 2.73 2.08 1.38 0.89 .00 60% Process Yield - 4.98 4.48 4.00 3.51 3.02 2.52 2.02 1.52 1.01 0.51 .00 70% Process Yield - 3.50 3.16 2.81 2.47 2.12 1.77 1.42 1.06 0.71 0.36 .00 80% Process Yield - 2.21 1.99 1.77 1.55 1.33 1.11 0.89 0.67 0.45 0.22 .00 90% Process Yield - 1.05 0.94 0.84 0.73 0.63 0.53 0.42 0.32 0.21 0.11 .00 Fault Coverage % Figure 4-3. Defect Level Versus Fault Coverage To briefly explore the Williams model, assume that the ASIC vendor has a silicon and assembly process yield that is 4-5 70 percent. If the fault grade of the test program is also 70 percent, the defect level is projected to be 10.1 percent, or 101,000 ppm (this is outside the limits of the chart and was calculated). At a fault grade of 90 percent, the defect level is projected to be 3.5 percent or 35,000 ppm. A study of the model shows that the process yield becomes an insignificant term when the fault coverage of the test program is very close to 100 percent. Motorola and Delco performed a study in 1980 that supports the Williams model. Their experimental results are shown in Figure 4-4. A fault coverage of 99.9 percent was required to obtain defect levels in the range of 100 ppm. Defect Level ppm 100 000 10 000 1000 100 Harrison, Holzwarth, Motz, Delco; Daniels, Thomas, Weimann, Motorola, 9/80 10 90 99 99.9 Fault Coverage % Figure 4-4. Motorola and Delco Study Results Figure 4-5 shows the maximum allowable ASIC defect rate to achieve a goal PCB defect rate as a function of the number of ASIC devices per board assembly. Note that for multiple-device PCB designs, a goal of 500 ppm requires ASIC defect levels in the range of 100 to 200 ppm. 4-6 Using DFT in ASICs 600 Number of ASICs Per Board 500 1 ASIC ppm Rate 400 300 2 200 3 4 5 10 20 100 0 0 100 200 300 400 500 600 Goal PCB ppm Rate Figure 4-5. ASIC ppm Versus PCB ppm Rate Theoretical and experimental studies conclude that a high-fault-grade test-pattern set is required for low-defect-level ASIC devices. This type of pattern set is nearly impossible to obtain through brute force. The requirements 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 performance and 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 hard to quantify. Reduced cost of ownership is another major benefit and is easy to quantify. Figure 4-6 shows what is commonly referred to as the "cost-of-ownership, order-of-magnitude relationship". It shows that each company has a cost associated with finding a defect in a packaged device before it has entered the assembly process. This cost can be calculated easily. The cost of finding a defective device after assembly onto a PCB is an order-of-magnitude more than before assembly. This continues until the cost to discover a defective device in a system at a customer's site is three orders-of-magnitude higher than that of discovery before assembly on to a PCB. 4-7 The lowest cost of ownership is achieved by finding defective units before they are shipped from the vendor. Discovery Site Customer Site System PCB Package Device 0 1X 10X 100X 1000X 1000X Cost-of-Defect-Discovery Multiplier Figure 4-6. Cost of Ownership The previous discussions lead to the conclusion that the lowest cost of ownership can be obtained by providing the ASIC vendor with an efficient, high-fault-detection set of test vectors. These DFT methodologies provide lower cost of ownership with the added benefit of reduced time to market. Developing Testability Strategies The following strategies outline the process of design for test. 1. Select a technology. When selecting a technology or vendor, make sure there is enough performance and gate-count margin to allow the insertion 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 design begins. Add a testability commitment to the design requirements 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 by the manufacturing or quality organization. Establish this requirement before the first design review. Add the fault-grade requirement to the design requirements 4-8 Using DFT in ASICs document. This requirement drives many of the decisions that follow in the development of the test strategy. Many companies consider the fault-grade requirement to be an index of device cost of ownership. Failure to achieve it impacts profits throughout the lifetime of the device. 4. Decide if IEEE Std 1149.1 is a system requirement. When implemented in an ASIC device, IEEE Std 1149.1 allows test of the interconnect between devices on a PCB through 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-scan through the test access port (TAP) and instruction register. 5. Select an ASIC testability approach based on gate density. Designs with fewer than 10K gates Designs with fewer than 10K gates are not generally complex enough to require structured test approaches. The overhead impact is usually too high to justify them. Nonstructured, good design practices are usually sufficient. Designs with more than 10K gates, but fewer than 20K gates Structured techniques should be considered for designs in this density. Nonstructured, good design practices are probably sufficient for highly combinatorial circuits without memory. Structured approaches should be considered as complexity is increased by the addition of sequential circuits, feedback, and memory. Consider boundary-scan testing for reduced cycle times and high fault grades. Designs with more than 20K gates The complexity of circuits this dense usually requires structured approaches to achieve high fault grades. At this density, it is often hard to control or observe deeply embedded circuits. The overhead associated with structured testability approaches is acceptable at this density. 4-9 6. Choose structured tools. Scan testing is typically the preferred structured approach for 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 expedite debug. This is an important step in decreasing the time to market for an ASIC device. The purpose of this pattern set is to isolate circuitry for analysis. 8. Generate high fault-grade test patterns. The fault grade of a test pattern set determines the best possible 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 and performance of the device. Test-pattern simulation produces the information needed to verify the test patterns in a tester environment. Figure 4-7 contains a flow chart that steps through the design-for-test process. 4-10 Using DFT in ASICs Pick a technology/vendor Commit to good testability design practices Establish a fault-grade requirement Yes Implement IEEE Standard 1149.1 No Yes IEEE Standard 1149.1 required for PCB? Density = Gates < 10K ? No Yes Consider scan Recommend scan 10K < Gates < 20K ? No Choose structured approach Scan/BIST Develop diagnostic pattern sets and locate critical paths Develop high fault-grade pattern sets Generate test description language Simulate test patterns and timing Have a system to ensure test patterns are compatible with logic revisions Minimum Time to Market Figure 4-7. Testability Development Flow 4-11 4-12 Using DFT in ASICs Chapter 5 Data Formats Several data formats have emerged to make IEEE Std 1149.1 successful and well supported by tools. This chapter discusses the most widely accepted data formats that support 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 aware of and used the standard, the need for a standard method for describing IEEE Std 1149.1-compatible devices was recognized. The IEEE Std 1149.1 working group established a subcommittee to develop a device description language to address this need. The subcommittee has since developed an industry standard language called Boundary-Scan Description Language (BSDL). BSDL is a subset and standard practice of VHDL (VHSIC Hardware Description Language) that describes how IEEE Std 1149.1 is implemented in a device and how it operates. BSDL captures the essential features of any IEEE Std 1149.1 implementation. BSDL has been formally adopted as part of IEEE Std 1149.1b-1994. IEEE Std 1149.1 is a structured design-for-test approach well suited for tools and automation. Tools developed to support the standard can control the test access port (TAP). If they know how the boundary-scan architecture was implemented in the device, such tools can also control the I/O of the device. BSDL provides a standard machine- and human-readable data format for describing how IEEE Std 1149.1 boundary-scan architecture is implemented in a device. How BSDL Is Used Many IEEE Std 1149.1 tools already on the market support BSDL as a data input format. These tools offer different capabilities to customers implementing IEEE Std 1149.1 into their designs, including board interconnect automatic test-pattern generation (ATPG) and automatic test equipment (ATE). 5-1 When tools that support BSDL are used, such BSDL is often received from the semiconductor vendor. This can result in significant time and cost savings. Teradyne estimates that to create in-circuit test patterns for a leading microprocessor normally can take as long as seven weeks: 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 the BSDL is supplied by the vendor, the time to develop in-circuit test patterns is less than two hours (less than $100) using today's tools. Elements of BSDL A BSDL description for a device consists of the following elements: 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 SN74BCT8245A). An entity description begins with an entity statement and terminates with an end statement. entity XYZ is {statements to describe the entity go here} end XYZ; 5-2 Data Formats Generic Parameter - A generic parameter is a parameter that can come from outside the entity, or it can be defaulted, such as a package type (e.g., "DW"). generic (PHYSICAL_PIN_MAP : string := "DW"); Logical Port Description - The port description gives logical names to the I/O pins (system and TAP pins), and denotes 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 external definitions found in packages and package bodies. use STD_1149_1_1994.all; Component Conformance Statement - The component conformance statement indicates the latest issue of IEEE 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 of logical signals onto the physical pins of a particular device package. attribute PIN_MAP of XYZ : entity is PHYSICAL_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 identification statements define the device's 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 (50.0e6, BOTH); Instruction Register Description - The instruction register description identifies the device-dependent characteristics of the instruction register. attribute INSTRUCTION_LENGTH of XYZ : entity is 2; attribute INSTRUCTION_OPCODE of XYZ : entity is "BYPASS (11),"& "EXTEST (00),"& "SAMPLE (10),"& "IDCODE (01)" attribute INSTRUCTION_CAPTURE of XYZ : entity is "01"; 5-3 Optonal Register Description - The optional register description identifies the values captured in the device identification register for the optional IDCODE and USERCODE instructions, if supported. attribute IDCODE_REGISTER of XYZ : entity is "01010100000011111100000000101111"; Register Access Description - The register access description defines which register is placed between TDI and TDO for each instruction. attribute REGISTER_ACCESS of XYZ : entity is "BOUNDARY (EXTEST, SAMPLE),"& "BYPASS (BYPASS)"; Boundary Register Description - The boundary register description contains a list of boundary-scan cells, along with information regarding the cell type and associated control. attribute BOUNDARY_LENGTH of XYZ : entity is 7; attribute BOUNDARY_REGISTER of XYZ : entity is "0 (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 semantically correct is only the beginning. A syntactically and semantically correct BSDL file can still contain descriptive errors and result in time-consuming debugging of board-level tests and diagnostics. A BSDL file must be validated (compared) against the silicon. 5-4 Data Formats Potential BSDL Errors As with any hand-entered data, typographical errors potentially exist. BSDL contains many commas and semicolons that contribute error possibilities. Fortunately, syntax and semantics errors can easily be identified and corrected using syntax and semantics checking tools during the 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 can result in implementation errors. How to Receive the BSDL Specification Contact the IEEE (1-800-678-IEEE 1-800-678-IEEE) and refer to Supplement to IEEE Std 1149.1-1990, IEEE Standard Test Access Port and Boundary-Scan Architecture, IEEE Std 1149.1b-1994 to receive a copy of the Boundary-Scan Description Language (BSDL) specification. Obtaining BSDL for TI Devices Texas Instruments makes catalog-device BSDL files available to customers through the World-Wide Web. As of this writing, these files can be located on the Texas Instruments IEEE Std 1149.1/JTAG/Boundary-Scan Silicon Products page located at URL http://www.ti.com/sc/docs/ jtag/silicon.htm; or, on the main Texas Instruments home page at URL http://www.ti.com. Search for keyword BSDL. 5-5 Hierarchical Scan Description Language (HSDL) Texas Instruments developed the hierarchical scan description language (HSDL) to complement BSDL, using the same subset of VHDL statements as BSDL. HSDL picks up where BSDL stops to describe additional attributes of IEEE Std 1149.1 devices and how IEEE Std 1149.1 devices are 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 as devices. A module is any level of architecture above the device level, including boards, multichip modules, backplanes, subsystems, and systems. In addition, HSDL provides two new packages used to indicate that an entity is an HSDL device or module. BSDL is ideal for describing how IEEE Std 1149.1 is implemented in a device, but stops there. HSDL provides a method for describing how IEEE Std 1149.1 devices are connected at the board, module, and system levels. HSDL serves two needs not addressed by BSDL: Describes the test-bus interconnections of IEEE Std 1149.1 at the board or module level Improves ease of use and reduces risk during interactive design debug and verification Allows descriptions of boards with dynamic and reconfigurable architectures Elements of HSDL HSDL module statements use much of the same syntax as BSDL. New statements have been added to describe the members and scan paths of the module and to simplify interactive use. Entity description Generic parameter Logical port description Use statement(s) [Optional module description(s)] [Optional port description(s)] Pin mapping(s) 5-6 Data Formats 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 entity description begins with an entity statement and terminates with an end statement. entity BOARD is {statements to describe the entity go here} end BOARD; Generic Parameter - A generic parameter may come from outside the entity or it may be defaulted, such as a package type (e.g., "UNDEFINED"). generic (PHYSICAL_PIN_MAP : string := "UNDEFINED"); Logical Port Description - The port description gives logical names to the I/O pins (system and TAP pins), and denotes 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 external definitions 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 of logical signals onto the physical pins of a particular entity. attribute PIN_MAP of BOARD : entity is PHYSICAL_PIN_MAP; constant PINOUT1 : PIN_MAP_STRING := "TDI:1, TDO:2, TMS:3, TCK:4, GND:5"; 5-7 Scan Port Identification - The scan port identification statements define the entity's TAP. attribute attribute attribute attribute TAP_SCAN_IN of TDI : signal is TRUE; TAP_SCAN_OUT of TDO : signal is TRUE; TAP_SCAN_MODE of TMS : signal is TRUE; TAP_SCAN_CLOCK of TCK : signal is (5.0e6, LOW); Members Description (Optional) - Members represent devices or other modules that are on the module. Usually members represent components, but some boards may contain scannable daughtercards, card slots, etc. that require member modules to describe them. attribute MEMBERS of BOARD : entity is "U1 (XYZ1, DW),"& "U2 (XYZ2, DW)"; Bus Composition (Optional) - Buses in an HSDL module can be built of module buses, member module buses, member device buses, and member device test registers. attribute BUS_COMPOSITION of BOARD : entity is "bus1[4] (U1.Boundary[3,0]),"& "bus2[4] (U2.Boundary[3,0])"; Path Description - Module paths are intended to describe the 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 in support of its ASSET business, HSDL is now supported by ASSET InterTech, which acquired ASSETTM in 1995. 5-8 Data Formats Serial Vector Format (SVF) Serial Vector Format, commonly referred to as SVF, was jointly developed by Texas Instruments and Teradyne in 1991. SVF is a standard ASCII format for expressing test patterns that represent the stimulus, expected response, and mask data for IEEE Std 1149.1-based tests. The need for SVF arose from the desire to have vendor-independent IEEE Std 1149.1 test patterns that are transportable across a wide selection of simulation software and test equipment - from design verification through field diagnostics. Boundary-scan test execution is controlled by the sequencing of TAP signals on the pins of the devices. Each device's behavior is determined solely by the states of its TAP pins. Boundary-scan tools must maintain knowledge of the sequences required to exert certain behaviors within a device and where that device is located in the serial scan path. SVF controls the IEEE Std 1149.1 test bus using commands that transition the TAP from one steady state to another. Rather than describe the explicit state of the IEEE Std 1149.1 bus on every TCK cycle, SVF describes it in terms of transactions conducted between stable states. For instance, the process of scanning in an instruction is described merely in terms of the data involved and the desired stable state to enter after the scan has been completed. The Capture, Update, Pause, etc. states are inferred rather than explicitly represented. The data to be scanned in, expected data out, and compare mask are all grouped in an easily understandable manner. A command is provided to support deterministic navigation of TAP states where required. In addition to supporting higher level depictions of scan operations, SVF also supports combined serial and parallel operations. This allows SVF to accommodate ATE environments where some stimulus/response is handled via parallel I/O, and serial signals are accessed via an IEEE Std 1149.1-control environment. SVF also supports the concept of scan offsets. Offsets allow a test to be applied to a component or cluster of logic embedded in the middle of a scan path. In Figure 5-1, a device exists in multiple instances on a board. Serially applied tests were generated by the designer that are available in SVF format. To reuse this test, it is necessary to 5-9 put all other devices on the scan path into the BYPASS mode. The IEEE Std 1149.1 test controller must therefore comprehend 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 devices introduce three data register bits before and two data register bits after the target device. SVF allows a header and trailer to be defined once, which maintains the instruction register and data registers of the nontargeted devices in the desired BYPASS state. No modifications are required to the SVF for the device. In Figure 5-1, if the same test were targeted toward another device downstream, this would be accommodated merely by changing the headers and trailers. Trailer TDI U1 U2 Header U3 U4 U5 U6 TDO Target Figure 5-1. Scan Path of Six ICs The offset approach is capable of installing any instruction register and data register stimulus, provided these values are constant for the entire process of applying the SVF device sequence. SVF Structure The SVF file is defined as an ASCII file that consists of a set of SVF statements. Statements are terminated by a semicolon (;) and may continue for more than one line. The maximum number of ASCII characters per line is 256. SVF is not case sensitive, and comments can be inserted into an SVF file after an exclamation point (!) or a pair of slashes (//). Each statement consists of a command and parameters associated with that specific command. Commands can be grouped into three types: state commands, offset commands, and parallel commands. 5-10 Data Formats State Commands State commands are used to specify how the test sequences will traverse the IEEE Std 1149.1 TAP state machine. The following state commands are supported: SDR SIR ENDDR ENDIR RUNTEST STATE TRST Scan data register Scan instruction register Define end state of DR scan Define end state of IR scan Enter Run-Test/Idle state Go to specified stable state Drive the TRST line to the designated level SDR performs an IEEE Std 1149.1 data register scan. SIR performs an IEEE Std 1149.1 instruction register scan. ENDDR and ENDIR establish a default state for the bus following any data register scan or instruction register scan, respectively. RUNTEST goes to Run-Test/Idle state for a specific number of TCKs. For each of the above commands, a default path through the state machine is used. Each of these commands also terminates in a stable, nonscannable state. STATE places the bus in a designated IEEE Std 1149.1 stable state. TRST activates or deactivates the optional test-reset signal of the IEEE Std 1149.1 bus. Offset Commands Offset commands allow a series of SVF commands to be targeted toward a contiguous series of points in the scan path. Examples would be a sequence for executing self-test on a device, or a cluster test where all devices involved in the cluster test are grouped together. The following offset commands are supported: HDR HIR TDR TIR Header data for data bits Header data for instruction bits Trailer data for data bits Trailer data for instruction bits 5-11 HDR specifies a particular pattern of data bits to be padded onto the front of every data scan. HIR specifies the same for the front of every instruction register scan. TDR and TIR specify data to be injected on the back of each scan. These patterns need only be specified once and are included on each scan unless changed by a subsequent HDR, HIR, TDR, or TIR command. Parallel Commands Parallel commands are used to map and apply the following commands: PIO - Specifies a parallel test pattern PIOMAP - Designates the mapping of bits in the PIO command to logical pin names Parallel commands allow SVF to combine serial and parallel sequences. PIOMAP commands are used by parallel I/O controllers to map data bits in the command into parallel I/O channels using the ASCII logical pin name as a reference. The PIO command specifies the execution of a parallel pattern application/sample. SVF does not specify any other properties of parallel I/O such as drive, levels, or skew. Default State Transitions SVF uses names for the TAP states that are similar to the IEEE Std 1149.1 TAP state names. Table 5-1 lists the SVF equivalent names for the TAP states. 5-12 Data Formats Table 5-1. SVF TAP State Names IEEE Std 1149.1 TAP State Name SVF TAP State Name Test-Logic-Reset RESET Run-Test/Idle IDLE Select-DR-Scan DRSELECT Capture-DR DRCAPTURE Shift-DR DRSHIFT Pause-DR DRPAUSE Exit1-DR DREXIT1 Exit2-DR DREXIT2 Update-DR DRUPDATE Select-IR-Scan IRSELECT Capture-IR IRCAPTURE Shift-IR IRSHIFT Pause-IR IRPAUSE Exit1-IR IREXIT1 Exit2-IR IREXIT2 Update-IR IRUPDATE 5-13 Table 5-2 identifies sample default paths taken when transitioning from one state to a specified new state. For example, if the current state is RESET and DRPAUSE is selected as the end state, the TAP moves from RESET through IDLE, DRSELECT, DRCAPTURE, DREXIT1 to DRPAUSE. One must only specify the current and end states and not each intermediate step. See the TAP controller state diagram on page 3-5 of Chapter 3, Boundary-Scan Architecture and IEEE Std 1149.1 to determine state transition paths not shown in Table 5-2. Table 5-2. Stable-State Path Examples Current State End State State Path RESET RESET RESET RESET IDLE RESET RESET DRPAUSE IDLE RESET IDLE DRSELECT DRCAPTURE DREXIT1 DRPAUSE RESET IRPAUSE RESET IDLE DRSELECT IRSELECT IRCAPTURE IREXIT1 IRPAUSE 5-14 Data Formats SVF Example The following is an example SVF file: ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Begin Test Program Disable Test Reset line TRST OFF; Initialize UUT STATE RESET; End IR scans in DRPAUSE ENDIR DRPAUSE; End DR scans in DRPAUSE ENDDR DRPAUSE; 24 bit IR header HIR 24 TDI (FFFFFF); 3 bit DR header HDR 3 TDI (7); 16 bit IR trailer TIR 16 TDI (FFFF); 2 bit DR trailer TDR 2 TDI (3); 8 bit IR scan, load BIST opcode SIR 8 TDI (41) TDO (81) MASK (FF); 16 bit DR scan, load BIST seed SDR 16 TDI (ABCD); RUNBIST for 95 TCK Clocks RUNTEST 95 TCK ENDSTATE IRPAUSE; 16 bit DR scan, check BIST status SDR 16 TDI (0000) TDO(1234) MASK(FFFF); Enter Test-Logic-Reset STATE RESET; End Test Program The test begins by deasserting TRST. The DRPAUSE state is established as the default end state for instruction register scans and data register scans. Twenty-four bits of header and 16 bits of trailer data are specified for instruction register scans. No status bits are checked. Three bits of header data and two bits of trailer data are specified for data register scans. In the example above, a single device in the middle of the scan is targeted. Notice from the 24-bit IR header (3 x 8-bit IR) and the 3-bit DR header (3 x 1-bit DR) that the targeted device has three devices before it in the scan path. From the 16-bit IR trailer (2 x 8-bit IR) and the 2-bit DR trailer (2 x 2-bit DR), the targeted device has two devices following it in the scan path. After the header and trailer offsets are established, all subsequent scans are the concatenation of the header, scan data, and trailer bits. The targeted device supports BIST, which is initialized by scanning hex 41 into the instruction register, followed by hex ABCD into the 5-15 selected data register. The BIST in the targeted device is then executed by entering the Run-Test/Idle state for 95 clock cycles. Next, the BIST result is scanned out and the status bits compared against a deterministic value to determine pass/fail. How to Receive the SVF Specification Orignally developed by Texas Instruments (with Teradyne) primarly in support of its ASSET business, SVF is now supported by ASSET InterTech, which acquired ASSETTM in 1995. 5-16 Data Formats Chapter 6 Suggested Design-for-Test Flow The designer of any new product must plan for testing at any time in the life cycle of the product. This process is called design for test (DFT). The test methodology, defined by IEEE Std 1149.1, is used to ease problems associated with both product development and all levels of testing. Once boundary-scan architecture is built into a device, tests developed for that device can be reused after it is in a product. Figure 6-1 summarizes the concerns applicable to any new product design. System Requirements Engineering Requirements Manufacturing Requirements Total Requirements Architecture To Figure 6-2 Field Service Requirements Marketing Requirements Figure 6-1. Initial DFT Concerns 6-1 Test Requirements Before implementing a boundary-scan test scheme, the designer must define test requirements for the following phases of the product life cycle: Design verification Manufacturing test Field test (also can be used for incoming inspection) These studies must ensure that the necessary controls are designed into the hardware to support the following requirements: During design verification, an engineer requires controllability of the circuitry, both internal to the IC and at board and system levels. Design engineers need controllability and observability of every logic node in the system. If this proves to be unrealistic, reasonable coverage is achievable with partial scan in a boundary-scan design. Manufacturing test may include interconnect testing and functional logic validation. Field or embedded testing typically may only include the ability to report faults and to isolate a fault to a field-repairable unit (board or subsystem). For both manufacturing test and field test, IEEE Std 1149.1 logic and test vectors can be used to test clusters or blocks of logic. Internal IC testing at the board or system level requires a subset of the complete IC logic-verification patterns to validate basic IC logic functions. Each level of hierarchical testing has a different set of fault characteristics. IEEE Std 1149.1 logic can be used throughout the testing life cycle of the product. 6-2 Suggested Design-for-Test Flow Built-In Self-Test (BIST) Methodology BIST usually consists of special circuitry built as part of an IC's internal design. BIST tests typically perform these functions: Pseudorandom pattern generation (PRPG) Parallel signature analysis (PSA) Serial signature analysis (SSA) State machine-based generation/comparison IEEE Std 1149.1 commands can initiate BIST tests and return the test results. Internal Scan Test Methodology Many high-density microprocessors and ASICs now include internal IEEE Std 1149.1-compliant scan circuitry. High-pin-count and fine-pitch packages limit physical access to package pins and devices with high gate count limit observation of the internal logic states. Internal scan, either partial or full, can do the following: Provide access to internal registers Partition the design Reduce the design to combinatorial networks surrounded by scannable registers Provide fast, efficient testing of internal logic Internal scan also allows on-chip emulation control and circuit observability within a device to provide design verification. The emulation capability also can aid in software development to control highly complex functions designed into a device. 6-3 Design Effort Figure 6-2 summarizes the various steps involved in ASIC and board design. Catalog Device Selection From Figure 6-1 Architecture Third-Party Simulation Models Board Design Prototype Assembly ASIC Design D Entry D Simulation D Layout D Fabrication D Entry D Simulation D Synthesis D Vector Generation D 1149.1 Insertion D Vector Generation D Simulation D Fabrication Board Netlist To Figure 6-3 HSDL Files BSDL Files Simulation Vectors Figure 6-2. Designing Testability for ASICs and Boards IC Design Implementation Synthesis of ASICs has become a popular approach to ASIC design. ASIC designers faced with DFT for the first time are concerned about lack of knowledge and the additional design time involved. Today, there are several vendors supporting synthesis and/or insertion tools that can automatically 6-4 Suggested Design-for-Test Flow generate the following elements of an IEEE Std 1149.1 architecture: Test access port (TAP) controller Instruction register Instruction decode logic Bypass register Boundary-scan register Such tools also can automatically generate test vectors for IEEE Std 1149.1-compliant designs. This means that a designer can quickly and correctly implement basic IEEE Std 1149.1 test circuitry in an ASIC. If synthesis is not available, most ASIC vendors offer a library of macros that the designer can use to implement IEEE Std 1149.1 into their designs. Using vendor macros requires considerably more effort and knowledge to implement IEEE Std 1149.1 into an ASIC, compared to using synthesis. However, in the absence of synthesis or boundary-scan insertion tools, using vendor macros is significantly easier than implementing boundary-scan architecture using a library that has no such macros. Texas Instruments offers a family of IEEE Std 1149.1-compliant ASIC macros for gate array and standard cell designs. The ASIC designer is required to provide a Boundary-Scan Description Language (BSDL) file that describes the finished ASIC. This information becomes the basis for tools that automatically create board interconnect test vectors. These vectors can be used by the board designer for debug and validation and by manufacturing test departments for quality assurance. Several DFT tool vendors plan to implement automatic BSDL creation that is available once the ASIC design has been completed. The creation of a BSDL file by the ASIC designer is straightforward if the design tool used does not automatically create it. 6-5 IC Simulation During IC simulation, the designer can use IEEE Std 1149.1 logic to simplify the simulation patterns required to validate the design. First, patterns must be developed to verify that the IEEE Std 1149.1 interface is operating properly. Simple IR and DR scan patterns can be developed to perform this check. If internal scan is implemented, then simulation pattern sets can be written to test internal logic clusters using the internal scan registers. This partitioned approach simplifies design validation. Using SVF for IC Design Validation Many IEEE Std 1149.1-compliant tools use Serial Vector Format (SVF) as the primary test pattern data format and interfaces between simulators and ATE testers also support SVF. A collection of manually-generated SVF patterns, simulation patterns translated into SVF and ATPG-generated SVF patterns can be used to validate the IEEE Std 1149.1 logic. Initial tests must first verify that serial data can be scanned into and out of the IC. Proper use of internal scan registers to partition the internal functional logic can simplify fault detection and isolation. IC testing usually is broken into three parts; static functional tests at 1 MHz, at-speed functional tests, and parametric tests. Because IEEE Std 1149.1 architecture relies on serially scanning control and test data, only static functional testing and DC parametric testing can be performed via the IEEE Std 1149.1 architecture. However, the IEEE Std 1149.1 TAP can be used to access user-defined test instructions (such as RUNBIST), which can be operated at speed. INTEST patterns generated by a simulator can be used to validate the internal logic of the IC. By comparing these patterns with simulation results and by observing internal scan register contents, the designer can isolate faulty internal logic. Figure 6-3 summarizes the design validation flow for all products, from IC through system-level products. 6-6 Suggested Design-for-Test Flow Prototype Assembly Board Netlist From Figure 6-2 Debug and Validation Integration and Test Manufacturing and Test Ship Boundary-Scan Test Tool HSDL Files Field Service Simulation Vectors BSDL Files Interconnect Patterns (SVF) Fault Dictionary Figure 6-3. Debug and Verification of a Boundary-Scan Design Data Passed to Board Designer The board designer needs test data to use during the design debug and validation phase. This data includes: BSDL for the ASICs as developed by the ASIC designer BSDL for catalog devices from the device vendor The BSDL that the designer creates for the ASIC must be validated to ensure that it is correct since it will be used by tools that develop more tests for board debug and validation. The new tests are then applicable for manufacturing test and field service test vector