Synopsys_dft_ug

ASIC Design Manual

Synopsys-DFT User Guide

2003

Synopsys-DFT User Guide Published in April, 2003 Document ID: BDE0048A (C) Copyright 2003 TOSHIBA Corporation All Rights Reserved The information contained herein is subject to change without notice. TOSHIBA is continually working to improve the quality and reliability of its products. Nevertheless, semiconductor devices in general can malfunction or fail due to their inherent electrical sensitivity and vulnerability to physical stress. It is the responsibility of the buyer, when utilizing TOSHIBA products, to comply with the standards of safety in making a safe design for the entire system, and to avoid situations in which a malfunction or failure of such TOSHIBA products could cause loss of human life, bodily injury or damage to property. In developing your designs, please ensure that TOSHIBA products are used within specified operating ranges as set forth in the most recent TOSHIBA products specifications. Also, please keep in mind the precautions and conditions set forth in the "Handling Guide for Semiconductor Devices," or "TOSHIBA Semiconductor Reliability Handbook" etc. The Toshiba products listed in this document are intended for usage in general electronics applications (computer, personal equipment, office equipment, measuring equipment, industrial robotics, domestic appliances, etc.). These Toshiba products are neither intended nor warranted for usage in equipment that requires extraordinarily high quality and/or reliability or a malfunction or failure of which may cause loss of human life or bodily injury ("Unintended Usage"). Unintended Usage include atomic energy control instruments, airplane or spaceship instruments, transportation instruments, traffic signal instruments, combustion control instruments, medical instruments, all types of safety devices, etc. Unintended Usage of Toshiba products listed in this document shall be made at the customer’s own risk. Toshiba does not take any responsibility for incidental damage (including loss of business profit, business interruption, loss of business information, and other pecuniary damage) arising out of the use or disability to use the product. The information contained herein is presented only as a guide for the applications of our products. No responsibility is assumed by TOSHIBA for any infringements of patents or other rights of the third parties which may result from its use. No license is granted by implication or otherwise under any patents or patent rights of TOSHIBA or others. The products described in this document may include products subject to the foreign exchange and foreign trade laws. Synopsys, TetraMAX, Design Compiler, VCS, DFT Compiler, PrimeTime, VCS, BSD Compiler and DesignWare are trademarks of Synopsys, Inc. Verilog, Verilog-XL, and NC-Verilog are trademarks of Cadence Design Systems, Inc. Gemini and Voyager are trademarks of IKOS Systems, Inc. ModelSim is a trademark of Model Technology, Inc. Sun-4, SunOS and Solaris are trademarks of Sun Microsystems, Inc. HP-UX is a trademark of Hewlett-Packard Company. UNIX is a trademark in the United States and other countries, licensed exclusively by X/Open Company, Ltc. Red Hat is a trademark of Red Hat, Inc. Linux is a trademark of Linux Torvalds. All other products or services mentioned in this document are identified by the trademarks or service marks of their respective companies or organizations.

Synopsys-DFT User Guide

Preface

Preface Design-for-testability (DFT) is essential to enhance the efficiency and effectiveness of IC testing. However, understanding and implementing DFT techniques manually can be a daunting task for new adopters. Automatic DFT tools help to complete robust designs more quickly. DFT Compiler and TetraMAX from Synopsys, Inc are popular DFT tools. Toshiba supports these DFT tools for development of its ASICs by providing cell libraries and design kit software programs. The Synopsys-DFT User Guide is for design and test engineers involved in a chip design for the Toshiba ASIC, using Synopsys’ DFT Compiler, BSD Compiler and TetraMAX. This manual provides necessary background material on DFT techniques and describes how to use the above tools to get the best results. For a complete description of their commands and usages, consult the documents provided by Synopsys. All information in this manual is based on the latest product information available at the time of printing. Toshiba reviewed the accuracy of this manual, but should you find, in this manual, any ambiguities or be in doubt as to any meanings, please direct all queries to your nearest Toshiba ASIC Design Center. In case of any inconsistencies existing between this and Synopsys’ manuals, please refer to the Synopsys manuals.

Supported Synopsys Tool Versions This manual is for the DFT Compiler, BSD Compiler and TetraMAX versions listed below: ♦ DFT Compiler 2000.11 and above ♦ BSD Compiler 2000.11 and above ♦ TetraMAX 2000.11 and above Please keep in mind that users of other versions might encounter minor inconsistencies existing in this manual.

i

Preface

Synopsys-DFT User Guide

Manual Organization This manual is organized as follows: Part 1: DFT Fundamentals Part 1 provides basic information for design-for-testability (DFT). Designers who have no experience with Toshiba’s DFT methodologies should read Part 1. ♦ Chapter 1, "Understanding DFT Concepts," discusses motivation for DFT and testability measures, and introduces common DFT techniques. ♦ Chapter 2, "Using the Internal-Scan Methodology," describes things you should know before performing scan insertion and automatic test pattern generation (ATPG). ♦ Chapter 3, "Using JTAG Boundary-Scan Methodology," describes things you should know before inserting JTAG boundary-scan logic to your design. ♦ Chapter 4, "DFT Considerations," describes the considerations for DFT methodologies supported by Toshiba and overall DFT flows. Part 2: Using the Synopsys DFT Tools Part 2 provides step-by-step instructions for common tasks using Synopsys’ DFT Compiler, BSD Compiler and TetraMAX in the Toshiba DFT design flow. ♦ Chapter 5, "Setting Up the Design Environment," describes how to set up the design environment for scan design using the Synopsys DFT tools. ♦ Chapter 6, "Scan Synthesis Methodology Using DFT Compiler," describes the scan synthesis methodology using DFT Compiler. ♦ Chapter 7, "STIL Procedure File (SPF)," provides guidelines for creating and edting STIL procedure files. ♦ Chapter 8, "Using TetraMAX ATPG," describes how to perform ATPG using Synopsys’ TetraMAX in conjunction with Toshiba’s TetraMAX design kit. ♦ Chapter 9, "Validating the Scan Structure and ATPG Test Vectors," describes how to evaluate the quality of your scan implementation and generated scan-test patterns. ♦ Chapter 10, "Toshiba TetraMAX Design Kit," mainly describes the SPFGen, TFSA, LSF2DEF and SCRTST programs contained in Toshiba’s TetraMAX design kit.

ii

Synopsys-DFT User Guide

Preface

♦ Chapter 11, "JTAG Boundary-Scan Insertion Using BSD Compiler," describes boundary-scan insertion using Synopsys’ BSD Compiler in conunction with Toshiba’s BSD Compiler design kit. Part 3: Advanced Topics Part 3 introduces more advanced design techniques related to DFT. ♦ Chapter 12, "Scan-Chain Reordering (SCR)," provides an outline of scanchain reordering, a feature of the layout tool to change the order in which scan flip-flops are connected, based on cell placement. ♦ Chapter 13, "Timing Analysis Using PrimeTime," discusses case analysis useful for analyzing normal- and test-mode operations of your design. Part 4: Appendixes ♦ Appendix A, "Quick Tour," walks you through the entire DFT process, from synthesizing scan circuitry using DFT Compiler to performing parallel-load simulation using VSO. ♦ Appendix B, "TSTL2 Scan Test Data Description," describes serialized scan-test vectors and how they are applied for scan testing. The Toshiba sign-off system supports STIL and TSTL2 test vectors. This appendix describes the TSTL2 test vectors.

Related Documents The following documents provide additional information. Contact your Toshiba design center engineer to obtain Toshiba’s documents. Toshiba’s Documents ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

CMOS ASIC Design Manual TDL, TSTL2, ROM Data Sign-Off System Command Reference VSO/VITALSO x.x.x User Guide PrimeTime Sign-Off System User Guide Design Compiler User Guide High-Speed Simulation (HSS) System User Guide MemoryBIST Design System Design-for-Test Handbook

iii

Preface

Synopsys-DFT User Guide

♦ VSO/DFT and VITALSO/DFT ♦ Toshiba STIL Language Guide Synopsys’ Documents ♦ ♦ ♦ ♦ ♦ ♦

iv

Boundary Scan Reference Manual BSD Compiler User Guide Scan Synthesis Reference Manual Scan Synthesis User Guide Test Automation Tutorial TetraMAX ATPG User Guide

Synopsys-DFT User Guide

Contents

Contents Part 1 DFT Fundamentals Chapter 1 Understanding DFT Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Internal-Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3 JTAG Boundary-Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Chapter 2 Using the Internal-Scan Methodology . . . . . . . . . . . . . . . . . . . . . . . 23 2.1 2.2 2.3 2.4 2.5 2.6

Scan Implementation Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I/O Pin Requirements for Scan Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Design Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Chain Number and Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixing Testability Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Timing Parameters for Scan Test Patterns . . . . . . . . . . . . . . . . . . . . . .

24 27 31 41 43 48

Chapter 3 Using JTAG Boundary-Scan Methodology . . . . . . . . . . . . . . . . . . . 55 3.1 Implementing Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.2 JTAG Boundary-Scan Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.3 I/O Pin and Buffer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Chapter 4 DFT Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.1 Selecting DFT Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.2 Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3 Design-for-Test Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Part 2 Using the Synopsys DFT Tools Chapter 5 Setting Up the Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1 Synopsys DFT Tools and Toshiba Design Kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.2 Installing and Setting Up Toshiba’s Design Kits and Libraries . . . . . . . . . . . . . . . . . 86 Chapter 6 Scan Synthesis Methodology Using DFT Compiler . . . . . . . . . . . . 89 6.1 6.2 6.3 6.4 6.5

Overview of Test-Ready Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Naming Rules for Ports, Cells and Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Sample DC Script for Scan Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Step-by-Step Scan Synthesis Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Considerations for Scan Synthesis Using DFT Compiler . . . . . . . . . . . . . . . . . . . . 110

v

Contents

Synopsys-DFT User Guide

Chapter 7 STIL Procedure File (SPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9

Creating an SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPF Organization for Single-Clocked Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPF Organization for Dual-Clocked Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPF Description for Scan-Out Ports with Bidirectional Buffers . . . . . . . . . . . . . . . Pin-Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing an SPF Generated by DFT Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing an SPF Generated by TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPF for a Design with JTAG Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

120 122 127 134 135 136 141 142 153

Chapter 8 Using TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.1 8.2 8.3 8.4 8.5 8.6 8.7

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Various Test Coverage Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATPG Test Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running TFSA and LSF2DEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

160 166 181 184 188 191 198

Chapter 9 Validating the Scan Structure and ATPG Test Vectors . . . . . . . . . 201 9.1 Key Decision Criteria for Quality of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.2 Scan Design Rule Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.3 Verifying the ATPG Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Chapter 10 Toshiba TetraMAX Design Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 10.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 SPFGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 TFSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 LSF2DEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 SCRTST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

228 229 240 249 253

Chapter 11 JTAG Boundary-Scan Insertion Using BSD Compiler . . . . . . . . . 255 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 BSD Compiler Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 JTAG Design and Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure . . . . . . . . . . . . . . . . . . . . . . 11.5 Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6 JTAG Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.7 BSD Compiler Design Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8 Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

256 257 259 268 283 287 290 295

Synopsys-DFT User Guide

Contents

Part 3 Advanced Topics Chapter 12 Scan-Chain Reordering (SCR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 12.1 What is Scan-Chain Reordering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 12.2 Scan-Chain Reordering (SCR) Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304 Chapter 13 Timing Analysis Using PrimeTime . . . . . . . . . . . . . . . . . . . . . . . . . 309 13.1 STA Considerations for a Design with DFT Logic . . . . . . . . . . . . . . . . . . . . . . . . . 310 13.2 Validating the Normal-Mode Operation of a Scanned Design . . . . . . . . . . . . . . . . . 311 13.3 Validating the Test-Mode Operation of a Scanned Design . . . . . . . . . . . . . . . . . . . 313

Part 4 Appendixes Appendix A Quick Tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 A.1 A.2 A.3 A.4

General Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-Pass Scan Synthesis Using DFT Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying the Scan Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

324 325 328 330

Appendix B TSTL2 Scan Test Data Description . . . . . . . . . . . . . . . . . . . . . . . 333 B.1 B.2 B.3 B.4 B.5

TSTL2 Scan Vector File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DECLARE Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Definition Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Pattern Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Test Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

334 336 341 344 346

vii

Contents

viii

Synopsys-DFT User Guide

Synopsys-DFT User Guide

Style Conventions

Style Conventions The following syntax and notation conventions are used throughout this manual: Courier Bold

Indicates any reference to a command. In many cases, it indicates keywords or command line options that you must enter literally (or exactly as shown).

Courier Oblique Indicates variable information, or user-defined arguments for

which you must substitute a name or a value. Courier Plain

In examples, shows text from files and reports printed by the system.

...

Elements preceding ellipses may be repeated any number of times.

[A]

Indicates an optional argument.

[A|B|C]

Indicates a list of choices from which you can choose one.

{A|B|C}

Indicates a list of choices from which you must choose one.

underscore|B|C

Indicates a default option or argument when there is more than one choice.

You must type all other punctuation symbols such as the comma, colon, slash, backslash, and quotation mark, as shown.

ix

Style Conventions

x

Synopsys-DFT User Guide

CMOS ASIC Design Manual

Part 1 DFT Fundamentals

1

Synopsys-DFT User Guide

2

Chapter 1

Understanding DFT Concepts

.....

.....................................

T

his chapter provides design engineers with the basics of design-for-testability (DFT) methodologies. It discusses motivation for DFT and testability measures, and introduces common DFT techniques. The material is organized into the following sections:

☞ Introduction ☞ Internal-Scan ☞ JTAG Boundary-Scan

3

1

1.1

Understanding DFT Concepts 1.1 Introduction

Introduction

Motivation for DFT

.................................................. An integrated circuit is tested to determine that it works as you designed it to do. Testing, in general, falls into two categories: functional testing and manufacturing testing. Functional testing is to ascertain that the circuit is functionally correct whereas manufacturing testing screens devices for physical defects introduced in the manufacturing process. An ideal material and manufacturing environment should produce no defective device, but in reality, a number of factors affect product quality. Thus, testing is required to detect defective devices. A point of interest to IC users is the probability that defective chips are shipped. This is referred to as defect level (DL). It would be best if we could somehow get an accurate prediction for a chip’s defect level, or the number of test escapes. However, it is extremely difficult to get an accurate estimate of the defect level due to a prohibitive amount of data (including statistics about every conceivable kind of defect characteristics and manufacturing yields) and the huge computational resources required. As an alternative to the defect level, fault coverage is generally used to provide a useful measure of manufacturing test quality. Fault coverage is the extent to which a test can detect faults, or physical defects, in a design, and expressed as a ratio of the number of detected faults to the number of faults tested. A mathematical equation is known that theoretically represents the relationship among fault coverage, manufacturing yield and defect level. Figure 1–1 gives some indication of fault coverage and defect level relationship for different yields. It clearly shows the importance of achieving the highest possible test fault coverage.

4

Figure 1–1 Defect Level as a Function of Yield and Fault Coverage 100

Yield

90

10

Defect Level (%)

80

20

70

30

60

40

50

50

40

60 70

30

80

20

90

10 0 0

10

20

30

40

50

60

70

80

90

100

Fault Coverage (%)

One outcome of higher integration in ASICs is that the circuit complexity has increased much faster than the number of I/O pins. This gate-to-pin ratio has increased dramatically over the past several years, creating a test problem for designers. The impaired accessibility of the internal logic from I/O pins is a bottleneck in developing high-quality test patterns. Proper testing is no longer possible without enhancing the "inherent" testability of a circuit design. Design-for-testability (DFT) is a deliberate design effort to assure that a chip may be thoroughly tested with minimum effort and cost and that high confidence may be granted to the test results. The most widely used approach to DFT is by using EDA systems to automate the entire DFT process. EDA applications generally consist of a tightly integrated set of a test synthesis tool and an automatic test pattern generation (ATPG) tool. EDA tools help to shorten the test development time and increase the test fault coverage.

Fault Models

.................................................. There are many kinds of faults that can occur in digital components. But, for what kinds of faults should we test? When a chip has manufacturing defects, physical defects have, by and large, logical effects on the circuit behavior. Thus, we can focus on the consequences of those faults rather than on their causes. In estimating the test fault coverage, the most commonly occurring faults are modeled to conform to some premise or conjecture about real physical defects.

5

.....

Understanding DFT Concepts 1.1 Introduction

1

Understanding DFT Concepts 1.1 Introduction

The fault model which is most widely used for the purpose of automatic test pattern generation is the single stuck-at fault model. In stuck-at fault models, the inputs and outputs of a logic gate are assumed fixed to a value, either logic 0 or logic 1, irrespective of what value is applied to or should be coming out of the network. The stuck-at-1 fault represents a circuit node that is permanently fixed at a logic 1 value. The stuck-at-0 fault represents a circuit node that is permanently fixed at a logic 0. The single stuck-at fault model assumes that only one node in the circuit is faulty at a time. Basically, the DFT methodology described in this manual uses the single stuck-at fault assumption.

Testability Measures

.................................................. The amount of fault coverage you achieve depends on the inherent testability of your logic design. Testability problems of a logic design can be classified into controllability and observability. If a node is controllable to a particular logic value, then you can drive it to that value by setting primary input pins to certain values. Controllability consists of 0-controllability and 1-controllability. If a particular logic value on a node is observable, then that value can be propagated to primary output pins where you can measure it for evaluation. Figure 1–2 Testability Factors

0-Controllability

Observability S-A-1

To detect a stuck-at fault on a node, both controllability and observability are required for that node. For example, to detect a stuck-at-1 (S-A-1) fault on a node, you must control the value of that node to the opposite of the stuck-at value first, by applying a test pattern at the primary inputs. Then the effect of that fault must be propagated to a primary output where you can observe it. SCOAP is one of the most popular algorithms to measure the controllability and observability of particular nodes within a design.

6

Design-for-Test Methods

.................................................. DFT techniques are broadly divided into two categories: ad hoc methods and structured methods. Ad hoc DFT techniques are directed toward correcting specific testability problems which make it difficult or impossible to create effective tests. Structured DFT techniques put an emphasis on transforming a design into a form that lends itself to automating test pattern generation and test process.

Ad Hoc DFT Techniques Ad hoc DFT techniques are used when the situation makes it necessary or desirable to enhance the testability of particular circuit nodes rather than being arranged in advance or as part of a general DFT scheme. Ad hoc techniques are useful to supplement internal-scan for increased controllability and observability. For example, test point insertion is an ad hoc technique to add non-scan circuitry to better control selected points and to better observe selected points. Another example is to bypass internally generated clocks during testing because they are hard to control efficiently.

Structured DFT Techniques Structured DFT techniques are applied to the overall design and included as part of the general design flow. The following are principal structured DFT techniques: ■

Internal-scan: This is a DFT technique that makes stored-state elements such as flip-flops both controllable and observable by replacing them with logically equivalent cells with a serial shift function and stitching them together to form one or more large shift register paths called scan chains. The next section briefly introduces the internal-scan design concept. Chapter 2 describes the scan style alternatives supported by Toshiba and the design considerations for scan insertion.

■

Build-in self-test (BIST): BIST involves adding test circuitry for generating test patterns on-chip and verifying response on-chip. Toshiba supports BIST for SRAMs, mask ROMs and DRAMs. BIST is outside the scope of this manual. For details on BIST, refer to the MemoryBIST User Guide from Toshiba.

■

Core Test: For standalone testing of an IP core or a megacell, a direct-access and wrapper-scan approaches are used to isolate the IP core or megacell from the rest of the design by providing a mux or wrapper scan register collar at its input and output pins. The benefit of a core test approach is that the designer can use the IP core’s or megacell’s standalone test developed by Toshiba for manufacturing test.

7

.....

Understanding DFT Concepts 1.1 Introduction

1

■

8

Understanding DFT Concepts 1.1 Introduction

JTAG boundary-scan: This is a board-level test vehicle that provides control over the input and output pads of digital ICs through test structures integrated on-chip. Chapter 3 describes the JTAG boundary-scan methodology and the design considerations for its implementation.

1.2

Internal-Scan

Basic Structure of Internal-Scan Design

.................................................. Internal-scan design is the most popular DFT technique that provides high controllability and observability to sequential logic. This technique modifies a design into a form that enables the computer software to automatically generate manufacturing test patterns. In this manual, the term "scan design" refers to internal-scan design, as opposed to the JTAG boundary-scan design. In the scan design technique, flip-flops in your design are replaced by logically equivalent elements that also perform a serial shift function called scan flip-flops. Figure 1–3 shows a non-scan flip-flop and an equivalent single-clocked scan flip-flop. Figure 1–3 Standard and Scannable Flip-Flops

D

Q

Scan Replacement

CP QN

Standard D Flip-Flop

D D

D

Q CP QN TI TE

=

Q

TI CP QN TE

Scan Flip-Flop

This implementation has a multiplexer in front of the data input of the flip-flop. When the TE input is 0, system data from the D input is selected. When the TE input is 1, scan-input data from the TI input is selected. One of the data outputs of the flip-flop (Q or QN) is also used as the scan-output signal. The scan-output signal of a flip-flop is connected to the scan-input signal of another flip-flop to form a shift register, as shown in Figure 1–4. This shift register path is called a scan chain or a scan path. Flip-flops in a scan chain are scan-controllable and scan-observable; that is, scan flip-flops can be controlled to a known state by serially shifting in specific logic values and can be observed by serially shifting out data. This scan shift capability makes internal nodes more accessible for testing. The process of replacing non-scan cells with the scan equivalents is called scan replacement. The process of implementing scan-chain connections and scan-control signal routing is called scan assembly. The process of performing scan replacement and scan assembly in a single step is called scan insertion or scan synthesis.

9

.....

Understanding DFT Concepts 1.2 Internal-Scan

Understanding DFT Concepts 1.2 Internal-Scan

1

Figure 1–4 Scan Chain Through a Scanned Design Scan-in

Scan-out

F/F Primary Inputs

Comb Logic Island F/F

F/F Comb Logic Island

F/F

Comb Logic Island

Primary Outputs

F/F

Clock Scan Shift Enable Scan Chain

Scan Test Sequence

.................................................. A design with internal-scan logic operates in one of two modes: scan shift mode and scan capture mode: ■

Scan shift mode (Shift mode) In scan shift mode, the entire scan chain operates as a long shift register. In this mode, test vector values are shifted in from the external scan-in input, and the contents of the scan flip-flops are shifted out on the external scan-out output.

■

Scan capture mode (Capture mode) In capture mode, all flip-flops in a scan chain operate as a standard flip-flop. Flip-flops are preloaded in scan shift mode to control the inputs to combinational logic islands. Once the capture mode is selected, a functional test vector is applied to the primary inputs, and the steady-state output response from the combinational logic is captured into the flip-flops by pulsing the system clock.

A scan test sequence is repeated by alternating these two modes. Figure 1–5 illustrates the scan test sequence step by step.

10

Figure 1–5 Scan Test Sequence 1. Test vector values are shifted in. Scan Shift Mode

1. Test vector values are serially shifted into scan flip-flops through the scan chain. (Scan-in)

Scan Capture 2. A functional test vector is applied to the primary inputs. Mode

F/F 2. The test pattern is applied to the primary inputs.

Comb Logic Island

F/F

F/F Comb Logic Island

F/F

F/F

F/F

F/F

F/F

Comb Logic Island

This completes test stimulus input to the combinational logic.

3. The output response is checked at the primary outputs and compared to the expected response.

4. The clock is exercised to capture the response from the combinational logic into scan flip-flops.

Comb Logic Island 4. The response from the comb logic is clocked into scan flip-flops.

F/F

Comb Logic Island

F/F

F/F

Comb Logic Island

3. The response is checked at the primary outputs.

F/F

5. The contents of scan flip-flops are shifted out. Scan Shift Mode

5. The contents of the scan flip-flops are serially shifted out from the scan chain and compared to the expected response. (Scan-out)

F/F Comb Logic Island

F/F F/F

F/F Comb Logic Island

F/F

Comb Logic Island

F/F

Steps 1 to 5 shown in Figure 1–5 are repeated for each test pattern. Note that, except for the last test pattern, a new test pattern is shifted into the scan chain while, simultaneously, the test result is shifted out, thus shortening the test time. You can use ATPG to automatically generate test patterns.

ATPG

.................................................. In effect, ATPG can treat scan flip-flop outputs as primary inputs and scan flip-flop inputs as primary outputs. In addition to the scan chain giving access to the internal states of a circuit, the scan chain may also be considered as a means of partitioning a circuit into less complex combinational logic blocks. Thus, a scan design technique enormously simplifies automatic test pattern generation.

11

.....

Understanding DFT Concepts 1.2 Internal-Scan

1

Understanding DFT Concepts 1.2 Internal-Scan

Generally, ATPG has two phases: 1. Random generation of patterns to cover easy-to-detect faults efficiently ATPG fault-simulates each random pattern to determine which fault it detects and calculates the overall fault coverage achieved with each new pattern. 2. Deterministic generation of patterns to cover specific stuck-at faults that are otherwise hard to detect In the second phase, ATPG analyzes the remaining undetected faults, one at a time, and tries to derive patterns to detect each of those faults. D-algorithm is one of the most popular test generation algorithms. Although random generation of patterns is efficient to cover easy-to-detect faults, it often results in inclusion of patterns that do not contribute to improving overall fault coverage. If the same fault can be detected by test patterns A and B and if pattern A can not detect any other fault, then pattern A is unnecessary. Thus ATPG can compact the set of test patterns. This means fewer patterns are needed to achieve the same fault coverage and that the test time is reduced.

Penalties of Internal-Scan Design

.................................................. The benefit of internal-scan is the potential it has for enhancing the design’s inherent testability so that the computer software can automatically generate high-fault-coverage test patterns. However, despite all the benefits, the freedom available to designers are bounded by four considerations:

12

■

Area overhead — Replacing non-scan flip-flops with more complex scan flip-flops increases sequential logic area. Additional interconnections required for scanning also increases area overhead. It is critical to keep area overhead within a certain limit not to have to go to the next die size.

■

Additional package pins — You must have extra I/O pins that may be allocated for test purposes. You can minimize the number of additional I/O pins by sharing I/O pins between functional and test signals.

■

Loss in chip performance — Scan design may slightly reduce circuit performance since higher gate loads or increased logic delays may be involved.

■

Design constraints — Scan design imposes a very specific set of design constraints on the designer so that APTG can quickly and correctly generate high-quality test patterns that run with no logic or timing violation in the scan circuitry.

1.3

JTAG Boundary-Scan

The JTAG boundary-scan addresses board-level testability. Its architecture employs a shift-register-based structure called boundary-scan chain that is inserted between the I/O pads and the core logic of an IC. The purpose of this register is to control and observe the signals at IC boundaries without interfering with on-chip system logic. This register is formally referred to as the boundary-scan register (BSR). Since the first proposal for a boundary-scan standard came from the Joint Test Action Group (JTAG), often it is simply called JTAG. The JTAG proposal is standardized as IEEE Std 1149.1. The main objective of boundary-scan is to automate the following tests: ■

To check interconnections between ICs on the pc board for shorts, opens and solder bridges

■

To check for misloaded or missing components

■

To check for dead components

Boundary-Scan Architecture

.................................................. To implement boundary-scan, there are two things that must be done: 1) add specialized test logic to all (or part) of the ICs on a board; 2) connect JTAG test signals of individual ICs on the board. Figure 1–6 and Figure 1–7 illustrate the architecture of boundary-scan logic and a simple boundary-scannable board design.

13

.....

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

1

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

Figure 1–6 JTAG Boundary-Scan Architecture Boundary-Scan Register (BSR) Cell

Serial Data Input (TDI)

Serial Data Output (TDO)

Boundary-Scan Path

System Interconnect

Boundary-Scan Register Boundary-Scan Path

BSR Cell

BSR Cell

BSR Cell

BSR Cell

BSR Cell

BSR Cell

From previous BSR cell

Core Logic BSR Cell

BSR Cell

BSR Cell

BSR Cell

BSR Cell

BSR Cell

From core logic

IC pad

To next BSR From JTAG From JTAG cell controller controller

JTAG Controller

14

Figure 1–7 Organization of the JTAG Controller Test Data Registers System Inputs

System Outputs

Boundary-Scan Register System Logic

G Device Identification Register MUX User-Specific Test Data Registers

Bypass Register TDI GI ID Instruction Register

MUX

CI

TDO EN

TMS TAP Controller

TCK TRST*

The following subsections briefly describe the components of the IEEE Std 1149.1 boundary-scan design.

Test Access Port (TAP) The TAP is the JTAG interface between the chip and the external environment. It provides access to test support functions built into the chip for the board testing. The internal test functions may also be accessed through the TAP. The TAP consists of the following three input and one output signal. An optional fourth input connection called TRST* may be included. ■

TCK (Test Clock Input) The TCK signal is the clock for the TAP controller. The actions of the JTAG test logic are synchronized by the TCK signal.

15

.....

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

1

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

TMS (Test Mode Select Input)

■

The TMS signal controls the transitions of the TAP controller in conjunction with the rising edge of the Test Clock (TCK). IEEE Std 1149.1 stipulates that TMS be high in case of an undriven input (due to open faults in the board-level boundary-scan path). Thus the TMS input uses an input buffer with pullup. TDI (Test Data Input)

■

The TDI input provides serial test instructions and data received by the JTAG test logic. The signal presented at TDI is fed into the TAP controller on the rising edge of TCK. IEEE Std 1149.1 stipulates that TDI be high in case of an undriven input (due to open faults in the board-level boundary-scan path). Thus the TDI input uses an input buffer with pullup. TDO (Test Data Output)

■

The TDO signal is the serial output for test instructions and data from the instruction register and test data registers. TRST* (Test Reset Input)

■

The optional TRST* input provides for asynchronous initialization of the JTAG test logic. Initialization occurs when the TRST* input changes to the low logic level. Thus to prevent an erroneous low signal on the TRST* input, an input buffer with pullup is used for the TRST* input. Note: In IEEE Std 1149.1, signals that are asserted or active in the low state have an asterisk suffix.

TAP Controller The TAP controller is a finite state machine with 16 states that controls the operation of the JTAG test logic. The TMS signal controls the transitions of the TAP controller in conjunction with the rising edge of TCK. The TAP controller is initialized to the reset state asynchronously when the low logic level is presented at the TRST* input. A synchronizing sequence for the state machine also exists: it will return to the reset state when TMS is held high for at least five rising edges of TCK.

Instruction Register The instruction register includes at least two shift-register-based cells that hold instruction data shifted in from the TDI input. The instruction is used to select the test to be performed or the data register to be "targeted" between TDI and TDO.

16

Test Data Registers Each instruction selects a unique test data register path to be enabled to shift data between TDI and TDO. There are the following types of test data registers. Boundary-Scan Register The boundary-scan register (BSR) is a shift-register-based structure mandated by IEEE Std 1149.1. It is inserted between the on-chip system logic and package pins as shown in Figure 1–6 and provides a means of both controlling and observing the I/O pads of an IC. the boundary-scan register allows you to check for shorts and opens in the interconnect between ICs. Bypass Register The bypass register is a mandatory 1-bit shift register. This register provides a minimum-length serial path through the IC (between TDI and TDO) when the IC is not required for the current test. The ability to "bypass" segments of the board-level serial test interconnect (boundary-scan path) allows considerable shortening of the overall path for the movement of test data. Device Identification Register The device identification register is an optional, 32-bit-wide shift-register-based structure. This register allows the device identification code to be serially read from the IC that shows the manufacturer’s identify, the part number and the version number for the IC. User-Defined Test Data Registers IEEE Std 1149.1 can be extended by adding optional user-defined test data registers. The user has a freedom to define new instructions to gain access to the test features within the IC such as a self-test function and internal scan chains.

TAP Controller

.................................................. The TMS signal controls the sequence of transitions of the TAP controller in conjunction with the rising edge of TCK. The state diagram of the TAP controller is shown in Figure 1–8. Each arrow between states is labeled with a 1 or 0, indicating the logic value of TMS that must be set up before the rising edge of TCK to cause the transition.

17

.....

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

1

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

Figure 1–8 TAP Controller State Diagram 1

Test-Logic-Reset 0

0

Run-Test/Idle

1

Select-DR-Scan 1

1

0

Select-IR-Scan 1

Capture-DR

0 Capture-IR

0

0 0

Shift-DR 1

1

1

Exit1-IR

0

0

Pause-DR

0

0

Pause-IR

1

1 0

Exit2-DR

Exit2-IR

1

1

Update-DR 1

0

Shift-IR

1

Exit1-DR

0

1

0

Update-IR 1

0

The following paragraphs briefly describe each of the controller states. ■

Test-Logic-Reset This is the controller reset state. The controller must be placed in this state after power-up.

■

Run-Test/Idle In this state, the IC is put in a test mode only when certain instructions are present. Otherwise, the instruction register and all test data registers retain their previous state.

■

Select-DR-Scan — Capture-DR — Shift-DR — Exit1-DR — Pause-DR — Exit2-DR — Update-DR These are the controller states in which test data registers such as the boundary-scan register are controlled. The Capture-DR, Shift-DR and Update-DR states are used to manipulate test data registers. All the other DR states are temporary or halt states. In the Capture-DR state, test results are parallel-loaded into test data registers selected by the current instruction. In the Shift-DR state, the test data register connected between TDI and TDO shifts data one stage forward towards its serial output. In the Update-DR state, a test data register with a latched parallel output drives out data to the logic under test.

18

■

Select-IR-Scan — Capture-IR — Shift-IR — Exit1-IR — Pause-IR — Exit2-IR — Update-IR These are the controller states in which the instruction register is controlled. The Capture-IR, Shift-IR and Update-IR states are used to manipulate the instruction register. All the other IR states are temporary or halt states. In the Capture-IR state, the shift register contained in the instruction register loads a pattern of fixed logic values. In the Shift-IR state, data is shifted through the shift register stage of the instruction register from TDI, and the MSB of the instruction register’s shift register stage is shifted onto TDO. The Update-IR state allows the instruction shifted into the instruction register to be latched onto the parallel output. Once the new instruction is latched, it becomes the current instruction.

General Test Sequence

.................................................. The TAP controller controls the sequence of operation of the JTAG circuitry in conjunction with a JTAG test instruction. 1. Loading an instruction The first step is to load serially into an IC the instruction code for a particular test operation to be performed. When the TAP controller has moved from the Select-IR-Scan state to the Shift-IR state, an instruction code is serially shifted from the TDI input into the shift register portion of the instruction register. After the shift operation is completed, in the Update-IR state the instruction code is latched into the update register portion of the instruction register; once the new instruction is latched, it becomes the current instruction. The instruction code is decoded to select a test data register to be accessed in the DR states such as Shift-DR and Update-DR. 2. Controlling a test data register Next, it may be necessary to load test data into the selected test circuitry before a meaningful response can be made. In the Shift-DR state, test data is shifted bit by bit from the TDI input into the shift register portion of the test data register selected by the current instruction. After the shift operation is completed, in the Update-DR state test data is latched into the update register portion of the test data register, which drives the logic under test. 3. Observing the test data register Following execution of the test instruction, test results are captured into the test data register in the Capture-DR state, and then shifted out onto the TDO output for examination in the Shift-DR state.

19

.....

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

1

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

Below is a description of the general test sequence for the IEEE Std 1149.1 EXTEST instruction to test the interconnections between ICs. 1. TRST* is asserted to initialize the TAP controller (TAPC). The controller is then moved to the Shift-IR state by using TMS and TCK. IC-A

TDI

01100...

IC-B BSR

BSR

Inst. Reg

Inst. Reg

TAPC

TAPC

TDO

TCK TMS TRST

2. In the Shift-IR state, the instruction register of each IC is connected between respective TDI and TDO pins. In this state, the binary code of the EXTEST instruction is shifted into the instruction register through the TDI pin. IC-A

11111... TDI (Instruction Code)

00000...

IC-B BSR

BSR

Inst. Reg

Inst. Reg

TAPC

TAPC

TDO

TCK TMS TRST

3. The controller is moved to the Shift-DR state via the Update-IR state. IC-A

TDI

11100...

20

TCK TMS TRST

IC-B BSR

BSR

Inst. Reg

Inst. Reg

TAPC

TAPC

TDO

4. Test data is shifted into the boundary-scan register from the TDI input. IC-A

01100... (Test Data)

TDI

IC-B BSR

BSR

Inst. Reg

Inst. Reg

TAPC

TAPC

TDO

TCK TMS TRST

5. In the Update-DR state, data is latched onto the parallel output of the BSR and driven onto its external connections. In the Capture-DR state, the state of all signals is received at the input pins of IC-B. If there is no fault in board-level interconnections, IC-B will see signal values with no modification. Data propagates from A to B

IC-A

IC-B 0

BSR

BSR

1 0

Inst. Reg TDI

1100

Inst. Reg

1

TAPC

TAPC

TDO

TCK TMS TRST

6. In the Shift-DR state, the data captured in the BSR of IC-B is shifted out from the TDO output for examination. This way, the propagation of data from IC-A to IC-B can be verified. IC-A

TDI TCK TMS TRST

IC-B BSR

BSR

Inst. Reg

Inst. Reg

TAPC

TAPC

TDO LHLH... (Expected Values)

a

21

.....

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

1

22

Understanding DFT Concepts 1.3 JTAG Boundary-Scan

Chapter 2

Using the Internal-Scan Methodology

.....

.....................................

T

his chapter describes things you should know before performing scan insertion and automatic test pattern generation (ATPG). The material is organized into the following sections:

☞ Scan Implementation Alternatives ☞ I/O Pin Requirements for Scan Methodologies ☞ Scan Design Rules ☞ Scan Chain Number and Balancing ☞ Fixing Testability Problems ☞ Determining Timing Parameters for Scan Test Patterns

23

Using the Internal-Scan Methodology 2.1 Scan Implementation Alternatives

2

2.1

Scan Implementation Alternatives

Selecting a scan style is the first thing you need to do. Toshiba supports two scan styles: singled-clocked and dual-clocked. The following sections describe these scan styles.

Single-Clocked Scan

.................................................. This scan implementation is formally known as the multiplexed flip-flop scan style. Figure 2–1 shows a standard D-type flip-flop and a single-clocked scan equivalent. The system clock input is used as a scan clock for scan shifting. Figure 2–1 Single-Clocked Scan Flip-Flop

D

Q

D

Scan Replacement

D

D

Q CP QN TI TE

CP QN

Standard D Flip-Flop

=

Q

TI CP QN

Q QN

TE

Scan Flip-Flop

CP

When the TE pin is at logic 0, data from the system data input (D) is selected. In scan shift mode, data from the Test Input (TI) pin is selected. In Figure 2–1, when TE=1, data from the TI pin is latched on the rising edge of the clock (CP). The scan-out pin is shared with a system data output. Figure 2–2 shows a single-clocked scan flip-flop that is less likely to cause hold-time violations than the one shown in Figure 2–1. Figure 2–2 Single-Clocked Scan Flip-Flop with the SO Output D D

D

Q CP QN TI SO TE

Scan Flip-Flop

=

Q

TI CP QN

Q QN

TE CP

SO

This scan flip-flop has a dedicated Scan-Out (SO) pin with a predefined delay to prevent hold-time violations. Note: The availability of single-clocked scan flip-flops with the SO output is limited to several technology series.

24

General Characteristics The characteristics of single-clocked scan are: ■

Advantages • Lower area overhead than dual-clocked scan • Requires fewer test pins than dual-clocked scan

■

Disadvantages • Tighter setup constraints than dual-clocked scan flip-flops because of the multiplexer in front of the D input • Requires skew control because hold violations can occur when a scan flip-flop’s scan-out pin (Q or QN) is directly connected to the next scan flip-flop’s scan-in pin (TI) • Requires lock-up latches whenever a scan chain crosses between two clock domains.

Required Test Pins Single-clocked scan flip-flops require or may require the following test pins: ■

Scan test enable input (usually, but not always, required)

■

Scan shift enable input (always required)

■

Scan-in inputs and scan-out outputs (required for each scan chain, but can be shared with system pins)

Section 2.2, "I/O Pin Requirements for Scan Methodologies," provides a description of the test pins.

Dual-Clocked Scan

.................................................. Figure 2–3 shows a standard D-type flip-flop and an equivalent dual-clocked scan version. This scan implementation uses dedicated two-phase clocks (A and B) for scan shifting.

25

.....

Using the Internal-Scan Methodology 2.1 Scan Implementation Alternatives

Using the Internal-Scan Methodology 2.1 Scan Implementation Alternatives

2

Figure 2–3 Dual-Clocked Scan Flip-Flop Latch1 D

Q

Scan Replacement

CP QN

Standard D Flip-Flop

D Q CP SI QN A B SO

Latch2 Q

D =

QN CP SI A

SO

Scan Flip-Flop B Latch3

In normal operation mode, the scan flip-flop functions like the original standard flip-flop. In scan shift mode, two nonoverlapping clocks (A and B) are used to shift data from the Scan-In (SI) pin to the Scan-Out (SO) pin. When A=1, data on the SI input is loaded into Latch 2. When B=1, data in Latch 2 is shifted to Latch 3. General Characteristics The characteristics of dual-clocked scan are: ■

Advantages • Relaxed clock skew constraints for scan clocks • More relaxed setup constraints than single-clocked scan flip-flops

■

Disadvantages • Higher area overhead than single-clocked scan • Require two dedicated scan clocks

Required Test Pins Dual-clocked scan flip-flops require or may require the following test pins: ■

Scan test enable input (usually, but not always, required)

■

Scan shift enable input (usually, but not always, required)

■

Scan-in inputs and scan-out outputs (required for each scan chain, but can be shared with system pins)

■

Two scan clocks (always required for the A and B clocks, but can be shared with system pins)

Section 2.2, "I/O Pin Requirements for Scan Methodologies," provides a description of the test pins.

26

2.2

I/O Pin Requirements for Scan Methodologies

Scan design requires one or more I/O pins for test purposes. The following sections describe the scan test pins.

Scan Test Enable

.................................................. Scan Test Enable (or simply called Test Enable) is an input pin that is active throughout testing. It can be active high or active low. The Scan Test Enable pin is required if there is a need to configure your design for test mode to disable any circuitry that causes test design rules violations. The next section gives some examples that illustrate the use of the Scan Test Enable pin (see Figure 2–9 on page 32, Figure 2–10 on page 32, Figure 2–12 on page 34 and Figure 2–14 on page 36).

Scan Shift Enable

.................................................. Scan Shift Enable is an input pin that is active during scan shift mode, as opposed to the Scan Test Enable input which is active throughout both scan shift and capture modes. The Scan Shift Enable input can be active high or active low. The single-clocked scan style always requires the Scan Shift Enable pin to configure scan flip-flops for scan shift mode. In the single-clocked scan design, this input pin drives the TE pin of all scan flip-flops in the scan chain. The dual-clocked scan style usually, though not always, requires the Scan Shift Enable pin to control the behavior of certain circuitry, such as multiplexing scan-out data and functional data at an output pin or forcing bidirectional pins to input mode during scan shifting (see Figure 2–5 on page 28 and Figure 2–18 on page 40). You can use a system input pin as the Scan Shift Enable pin. However, a shared Scan Shift Enable pin is held at its active value, say, logic 1, during scan shift mode and at its inactive value (logic 0) during capture mode. Because test patterns can not be generated with the Scan Shift Enable pin set to 1, fault coverage is lowered. When a system input pin is used as the Scan Shift Enable pin, a Scan Test Enable pin is required to control the Scan Shift Enable signal. The Scan Shift Enable signal is allowed to go active only during scan testing so that it does not disturb the circuit behavior in normal operation mode.

27

.....

Using the Internal-Scan Methodology 2.2 I/O Pin Requirements for Scan Methodologies

2

Using the Internal-Scan Methodology 2.2 I/O Pin Requirements for Scan Methodologies

Figure 2–4 Using a System Input Pin as the Scan Shift Enable Input ATPG can not generate test patterns with the system input set to 1. This causes a drop in fault coverage. System Input/ Scan Shift Enable (Active-High)

Scan Chain TE

TE

Scan Test Enable (Active-High)

Scan-in and Scan-out

.................................................. The scan-in pin drives the head of a scan chain. The scan-out pin is a point where the value at the end of a scan chain is observed. If your design has multiple scan chains, each scan chain must have its own scan-in and scan-out pins. You can use a system input pin as a scan-in pin. You can use a system output pin as a scan-out pin. When using a system output pin as a scan-out pin, a Scan Shift Enable pin is required to multiplex scan-out data and functional data at that output pin, as shown in Figure 2–5. Figure 2–5 Using a System Output Pin as a Scan-Out Pin MUX System/Scan Input

System/Scan Output SI SO

SI SO

SI SO

Scan Chain Scan Shift Enable

Scan Clocks

.................................................. The dual-clocked scan style uses two-phase clocks: master clock A (capture clock) and slave clock B (update clock). Even if your design has multiple scan chains, all scan chains can share the same scan clocks. You can use system input pins as the scan clock pins; in this case, however, either a Scan Shift Enable or Scan Test Enable pin is required to control the scan clocks so that they do not disturb the circuit behavior in normal operation mode. The shared

28

pin lowers possible fault coverage because it is constrained to the inactive state of the scan clocks during scan capture mode. Thus, you should select, as a Scan Test Enable pin, an input pin that is only connected with small logic. Figure 2–6 shows an example of using system input pins as scan clocks. Figure 2–6 Using System Input Pins as Scan Clock Pins ATPG can not generate test patterns with the system input set to 1. This causes a drop in fault coverage. System Input/ Scan Clock A System Input/ Scan Clock B

Scan Chain 1 A

B

A

B

Scan Chain 2 A

B

A

B

Scan Shift Enable or Scan Test Enable

Inserting Buffer Trees

.................................................. Global test signals drive all scan flip-flops in the scan chain. It is desirable to create buffer trees to drive these signals.

Buffering Single-Clocked Scan Circuitry In this scan implementation, the Scan Shift Enable signal drives all scan flip-flops. The Scan Shift Enable signal requires no skew control, but to prevent drive-limit violations it is necessary to create a buffer tree to drive the Scan Shift Enable signal. A buffer tree can be created in two ways: 1) Use the clock tree synthesis (CTS) feature during physical layout; or 2) re-run compile in DFT Compiler after insert_scan (or insert_dft). However, if you want to generate AC test patterns such as a Path Test or a Transition Test with ATPG, it is recommended to run CTS on the Scan Shift Enable signal for clock skew management. This helps to achieve higher fault coverage with fewer patterns.

29

.....

Using the Internal-Scan Methodology 2.2 I/O Pin Requirements for Scan Methodologies

2

Using the Internal-Scan Methodology 2.2 I/O Pin Requirements for Scan Methodologies

Figure 2–7 Scan Test Signal That Requires Buffering Scan Flip-Flops

TE

Scan Shift Enable TE

Buffering Dual-Clocked Scan Circuitry In this scan implementation, the scan clock signals drive all scan flip-flops. Being two-phase clocks, the scan clock signals require no rigid skew control, but to prevent drive-limit violations it is necessary to create buffer trees to drive the scan clock signals. Buffer trees can be created in two ways: 1) Use the clock tree synthesis (CTS) feature during physical layout; or 2) re-run compile in DFT Compiler after insert_scan (or insert_scan). However, if you want to generate AC test patterns such as a Path Test or a Transition Test with ATPG, it is recommended to run CTS on the scan clock signals for clock skew management. This helps to achieve higher fault coverage with fewer patterns. Figure 2–8 Scan Test Signals That Require Buffering Scan Flip-Flops A B

Scan Clock A Scan Clock B

30

A B

2.3

Scan Design Rules

To perform scan synthesis and scan test correctly, you must create your design in conformance with the test design rules. Although the scan synthesis and ATPG tools do not require you to eliminate all violations, many of them have a severe impact on fault coverage results. You can use the integrated design rule checker of your DFT tool to check that your design conforms to the design rules of your chosen scan style. The rule checker might be able to correct minor violations automatically, but most violations are left unfixed. Therefore, you should watch for and correct testability problems in your design earlier in the design process, preferably at RTL, rather than later when it is difficult and time-consuming to get them right.

Sequential Logic Rules

.................................................. The percent of fault coverage achieved for a scan design is related to the ratio of scanned flip-flops in your design. If your design has latches or flip-flops for which scan equivalents are not available, possible fault coverage may be affected. You may need to use workarounds to improve testability.

Flip-Flops During early design exploration, pay close attention to the inferred flip-flops to determine that they can be converted to scan. Specifically, ■

Add synthesis constraints so that sequential elements will be mapped only to positive-edge-triggered D-type flip-flops. Avoid using JK flip-flops and toggle flip-flops.

■

Make set and reset signals directly controllable from I/O pins for testing.

■

Make clock signals directly controllable from I/O pins for testing.

Clock signals will be discussed in detail in the section "System Clocks" on page 33. Figure 2–9 shows a technique to control the reset input of a flip-flop from a primary input during testing to prevent it from resetting asynchronously.

31

.....

Using the Internal-Scan Methodology 2.3 Scan Design Rules

2

Using the Internal-Scan Methodology 2.3 Scan Design Rules

Figure 2–9 Holding an Asynchronous Register Signal During Testing System Reset Logic Test Reset

Scan Test Enable Flip-Flop

Note: As an alternative to the design shown above, you can use the Scan Test Enable signal to disable the Test Reset signal during scan testing. However, this makes it impossible to test the reset pin of the flip-flop, causing a drop in fault coverage.

Latches Avoid using latches wherever possible because there are no scannable equivalents in the Toshiba cell library. If your design has latches, they must not block the propagation of fault effects so as not to affect fault coverage results. A recommended workaround is to either fix the latch enables at a constant logic 1 or make them easily controllable to logic 1 during testing. This way, all latches can be placed in transparent mode during testing. The ATPG tool can optionally generate test patterns, considering the storage mode of latches; however, this greatly lowers the ATPG efficiency, making it difficult to obtain expected results. Figure 2–10 shows a design in which a latch enable is gated using a Scan Test Enable pin. Figure 2–10 Gating a Latch Enable

Enable Control

Scan Test Enable (Held at 1 During Test) Latch

Remember that treating latches as transparent may cause more design rule violations than leaving them non-transparent. This occurs because if a combinational path exists from the output of a latch to the input of the same latch, placing the latch in transparent mode introduces a combinational feedback loop into the design.

32

Mixed Flip-Flops and Latches Flip-flops and latches can be mixed in the same clock domain provided they use the opposite edges of a clock, as shown in Figure 2–11. Figure 2–11 Mixed Flip-Flops and Latches Using the Opposite Edges of the Clock Flip-Flops To Be Scanned

Combinational Logic

Non-Scan Latches

Combinational Logic

Flip-Flops To Be Scanned

System Clock

System Clocks

..................................................

System Clock Controllability All clock signals for flip-flops must be directly controllable from I/O pins for test purposes, and all flip-flops driven by the same clock must be sensitive to the same edge of that clock. Bypass violating clocks to I/O pins in order to allow control of the clocks. In the case where flip-flops are driven by a clock divider as shown in Figure 2–12(a), it is difficult or impossible to directly control the divided-down clocks for test. This design will have uncontrollable scan flip-flops after scan replacement; thus you will not be able to generate high-fault-coverage test patterns for it. To solve this problem, it is necessary to directly control flip-flops using Scan Test Enable muxes or make all flip-flops operate with the same clock during scan testing, bypassing the clock divider. When the divider is bypassed, clock slew management is required (see the next section).

33

.....

Using the Internal-Scan Methodology 2.3 Scan Design Rules

2

Using the Internal-Scan Methodology 2.3 Scan Design Rules

Figure 2–12 Clock Divider (a) Clock Divider

t o N

Clock

s i Th

Scan Flip-Flops

(b) Test Clock 1 Test Clock 2 Clock Divider MUX

Scan Flip-Flops

MUX Clock Scan Test Enable

For Scan Test Enable muxes, provide separate test clock pins to control each clock domain independently. It is recommended to allocate dedicated pins to the test clocks because pulse waveforms are applied to them.

Skew Control ATPG uses zero-delay models and expects no timing violations to exist in the design. The assumption is that all flip-flops in the same scan chain are clocked simultaneously. Therefore, the presence of timing violations can cause ATPG to generate test patterns that do not perform the scan operation correctly. In order to guarantee that no timing violations occur, you need to provide skew control through clock tree synthesis (CTS) or create your design in a manner that makes it insensitive to skew. Usually, Toshiba is responsible for building a clock tree during physical layout. Before layout, Toshiba predicts the impact of clock tree synthesis on the delay of the design, so you can assign an estimate of the clock tree during timing verification.

34

CTS gives no special consideration to skew between clock domains. A configuration such as the one shown in Figure 2–13 might cause hold violations during testing. Figure 2–13 Mixing Clock Domains (Risky) CTS can not reduce skew between clock domains. CTS1 Clock Divider MUX MUX CTS2

Clock skew can cause hold violations during testing.

Clock Scan Test Enable (Held at 1 During Test)

CTS3

There are two ways to prevent timing problems caused by the capture of data between clock domains: ■

drive each domain from its own clock pin as shown in Figure 2–12(b), or

■

make the interface between clock domains insensitive to clock skew when you want to use the same test clock for multiple clock domains.

If you elect to use the latter method, be sure to perform timing verification to identify any timing violations that might exist during test. Toshiba’s Gated CTS provides a way to control skew between gated clocks; so you do not need to bypass gated clocks to external I/O pins for testing. If the enable input of the clock-gating elements seldom goes active, you can force it to its active state during testing by using a Scan Test Enable pin, as shown in Figure 2–14.

35

.....

Using the Internal-Scan Methodology 2.3 Scan Design Rules

2

Using the Internal-Scan Methodology 2.3 Scan Design Rules

Figure 2–14 Gated Clocks

Enable Logic Test Enable (Held at 1 During Test) Clock

CTS

Multiple Capture Clock Groups A capture clock group is a set of clocks that can be safely clocked in the same cycle. By default, ATPG activates only one system clock in any given cycle. This is to prevent unreliable capture conditions from arising between scan flip-flops in different clock domains. As described in the previous chapter, the internal states of the circuit are captured during scan capture mode by exercising the system clock and then shifted out at a primary output for observation during scan shift mode. That is, scan flip-flops controlled by inactive system clocks retain their previous scanned-in state. Consequently, the default ATPG behavior leads to a lengthy test pattern set for designs with multiple system clocks. In cases where the relative timing of the capture clocks has no effect on the circuit behavior during test, they can be assigned to the same capture clock group in order to minimize the pattern count. Figure 2–15 shows a design with three clocks.

36

Figure 2–15 Multiple System Clock Design Top Level

CLK2

Block A

Block B

CLK1 CLK3

■

By default, ATPG partitions the system clocks into three capture clock groups as follows: • Capture clock group 1: CLK1 • Capture clock group 2: CLK2 • Capture clock group 3: CLK3

■

If the data launched from Block A does not propagate to Block B, their clocks can be assigned to the same capture clock group as follows. • Capture clock group1: CLK1 • Capture clock group2: {CLK2, CLK3}

■

If the data launched from Block A does not propagate to Block B and the interface between the top level and the Blocks A and B is insensitive to skew, all the clocks can be in the same capture clock group as follows: • Capture clock group 1: {CLK1, CLK2, CLK3}

In order to take advantage of the grouping of capture clocks, the ATPG user must have a solid knowledge of the clocking scheme for the entire design. Therefore, use of capture clock groups is discouraged unless your design has many clocks and the generated test pattern set has turned out to be too lengthy. The default ATPG behavior (1 capture clock group = 1 clock) is always the safest strategy.

37

.....

Using the Internal-Scan Methodology 2.3 Scan Design Rules

2

Using the Internal-Scan Methodology 2.3 Scan Design Rules

Internal 3-State Buses

.................................................. If your design has 3-state buses, all 3-state drivers must be directly controlled from external I/O pins or the enable lines for the 3-state drivers must be fully decoded. Figure 2–16(a) shows a design in which flip-flops control the enable pins of 3-state drivers. This design is risky because bus conflict can occur whenever scan shift changes the state of the flip-flops. In order to ensure only one driver is active at any one time, it is safe to drive 3-state enable lines from either combinational decode logic or external input pins. Figure 2–16(b) shows a technique to make your design comply with the 3-state bus rule. Figure 2–16 3-State Bus Rule Flip-flops randomly change state during scan shifting and may cause bus conflict. Flip-Flops

Decoder Combinational Logic

T t o

A B

N

s i h

Flip-Flops Decoder Combinational Logic

38

A B

The design in Figure 2–17 controls the 3-state bus with a decoder that is connected to external test input pins. Figure 2–17 Workaround for the 3-State Bus Problem MUX Enable Logic

Test Input 1 Test Input 2

Decoder A B

Test Enable (Held at 1 During Test)

To ensure the highest possible fault coverage, ATPG must be able to create test patterns that place each one of the drivers in the active state, either via external inputs or scan flip-flops. Even if bus conflict does not occur, any one driver should not be the only active driver during scan testing because drivers that are not enabled block the propagation of fault effects and lower fault coverage. If the bus is not controllable, the propagation of fault effects may be blocked at the bus, thereby lowering fault coverage.

Bidirectional Pins

.................................................. All bidirectional pins must be placed in input mode during scan shift operation so that the output buffer will not be enabled and output a logical value which conflicts with the value from a tester’s driver. Unless bidirectional pins are forced into input mode, bidirectional pin conflict or float can occur because the circuit can be put into a random state during scan shift. Bus conflicts that last only briefly typically does not damage the device, but long periods of bus conflicts can destroy the device. Use the Scan Shift Enable signal to hold bidirectional pins in input mode throughout the scan shift process, as shown in Figure 2–18.

39

.....

Using the Internal-Scan Methodology 2.3 Scan Design Rules

2

Using the Internal-Scan Methodology 2.3 Scan Design Rules

Figure 2–18 Controlling Bidirectional Pins Scan Shift Enable (Held at 1 During Scan Shift)

System Enable Logic

Bidirectional Pin

Combinational Feedback Loops

.................................................. Avoid using combinational feedback loops because they can cause generation of incorrect test patterns or lower possible fault coverage. Remember that, as explained in the section "Sequential Logic Rules" on page 31, if a combinational path exists from the output of a latch to the input of the same latch, placing the latch in transparent mode introduces a combinational feedback loop into the design.

40

2.4

Scan Chain Number and Balancing

General Considerations

.................................................. The following considerations apply to scan chain connections: ■

Consider scan routing from the perspective of the top level of the design.

■

Serialized scan-in and expected scan-out patterns constitute a large majority of ATPG patterns. Therefore, testers are typically equipped with specialized memory for scan test. Because the test time is proportional to the length of the longest scan chain, increasing the number of scan chains reduces the test time for a design. However, the maximum number of scan chains is restricted due to tester limitations. Using the maximum number of scan chains supported minimizes the test time. Ask your Toshiba design center engineer for the maximum number of scan chains supported by your prototype and production testers.

■

The number of bits (i.e., cycles) in the scan test pattern for a scan chain is equal to the number of scan flip-flops in that scan chain. If the scan chains are different lengths, the scan test patterns for the shorter scan chains are automatically padded to make all patterns the same length. Therefore, the time required for the scan shift process is proportional to the length of the longest scan chain. To reduce the time required for scan-shifting, it is recommended that all scan chains be balanced.

■

Each scan chain must have a scan-in and a scan-out pin associated with it. You can use functional input and output pins as scan-in and scan-out pins respectively.

Note that the number of scan chains implemented in the design is important here, not the number of scan chains activated by a given test pattern file. Configuring 16 scan chains may exceed the target tester limit even if at most eight of the 16 scan chains are exercised by a given test pattern file. A workaround for this limit is to use a Scan Path Select pin to share the same scan-in and scan-out pins between scan chains that are not accessed in parallel. For details on the Scan Path Select pin, see the Design-for-Test Handbook.

41

.....

Using the Internal-Scan Methodology 2.4 Scan Chain Number and Balancing

Using the Internal-Scan Methodology 2.4 Scan Chain Number and Balancing

2

Considerations for Single-Clocked Scan

.................................................. Because the single-clocked scan technique uses the system clock pin as the scan clock pin, you must construct a scan chain in a manner to eliminate the likelihood of timing problems due to clock skew. Figure 2–19 shows a mixed-clock scan chain that might not shift properly. The ability to shift data through this scan chain depends on the timing relationship between the two clocks. Figure 2–19 Multiple-Clock Scan Chain Timing violations might occur during scan shifting.

Q TI

Clock1 Clock2

N

T t o

s i h Q

TI

Q TI

Although the design in Figure 2–20 uses only one clock pin, the scan flip-flops have different branches of the clock. This scan chain might not also shift properly due to the effects of clock skew. Figure 2–20 Scan Chain Controlled by Divergent Clocks Timing violations might occur during scan shifting.

Q TI

Clock Divider

T t No

s i h

Q

TI

Clock Test Enable

You can prevent timing problems by the following ways:

42

■

allocate a scan chain for each clock domain

■

insert lock-up latches whenever a clock change occurs, or

■

insert buffers into scan signals to ensure adequate hold time.

Q TI

2.5

Fixing Testability Problems

Internal-scan significantly enhances the testability of your design. However, certain issues may limit its effectiveness. Commonly encountered problems include signals fixed at a constant logic value during testing, deeply buried logic states, and cells treated as black boxes during ATPG such as RAMs. This section explains how you can resolve these testability problems.

Overview of Hard-to-Detect Faults

.................................................. The following describes the circuit nodes whose faults are difficult or impossible to detect using ATPG.

Fixed Logic Values at Nodes ATPG can not generate test patterns to detect faults at nodes that are held at constant logic values for testing, such as certain nodes in the test mode logic added to disable the circuitry that causes design rule violations. Several downstream nodes may also be untestable because fixed logic values block the propagation of their logic values. For example, in the design in Figure 2–21, the circled signals are blocked when the Scan Test Enable input is active. You must add observe test points if you need to restore their observability (see Figure 2–25 to Figure 2–27). Figure 2–21 Undetectable Faults These signals are blocked (i.e., untestable) when the Test Enable input is asserted to logic 1 for testing. MUX

Decoder

Scan Test Enable (Held at 1 During Test)

43

.....

Using the Internal-Scan Methodology 2.5 Fixing Testability Problems

2

Using the Internal-Scan Methodology 2.5 Fixing Testability Problems

Deeply Buried Logic States Nodes buried deep within a design are hard to control and observe. Buried states may defeat the ATPG’s attempt to generate test patterns or lead to an increase in pattern count. You can enhance the testability of deeply buried nodes by inserting control and observe test points. See the section "Inserting Test Points" on page 45.

Black Box Cells ATPG can not propagate fault effects through black box cells such as megacells and forces their outputs to unknown (X) values; so ATPG can not detect faults on black box cells and cells in their neighborhoods. Black box cells have an adverse effect on fault coverage. Figure 2–22 shows logic in the shadow of a black box. Black box cells require additional test logic to resolve the shadow effects and increase overall testability. Figure 2–22 Untestable Logic in the Shadow of a Black Box Module Any signal between scan flip-flops (primary inputs) and the black box that pass only into the black box are unobservable.

Any signal between the black box and scan flip-flops that is affected by the outputs of the black box is uncontrollable.

Black Box Module

Using the Scan Shift Enable Input Versus the Scan Test Enable Input

..................................................

Figure 2–23 shows a technique to make the untestable nodes in the design of Figure 2–21 testable. Use a Scan Shift Enable input so that the signals that were blocked by the Scan Test Enable signal can propagate through the multiplexers.

44

Figure 2–23 Increasing Testability Using Scan Shift Enable The 3-state enable signals can be active (i.e., testable) during capture mode.

GND VDD

MUX MUX

Scan Shift Enable (Held at 1 Only During Scan Shift)

This way, during scan capture mode (i.e., when the Scan Shift Enable input is at logic 0), the TetraMAX ATPG tool can safety generate conflict- and float-free test patterns. During scan shift mode (i.e., when the Scan Shift Enable input is at logic 1), the 3-state bus is safely fixed in a known state, independent of the random state in which the circuit is placed during scan shift.

Inserting Test Points

.................................................. Test point insertion is a technique to add non-scan circuitry to better control selected points and to better observe selected points. Control and observe test points are most useful when you use them to supplement scan to increase ATPG fault coverage. Figure 2–24 shows a multiple-input AND gate that is hard to control to logic 1 and a technique to make it more testable by inserting a test-point OR gate. Figure 2–24 Control Test Point The OR gate makes it easy to control the node to logic 1 during testing.

The output of a multiple-input AND gate has poor controllability.

Test-Point Control Input Test Enable (Held at 1 During Test) Cancels the effect of the OR gate during normal functional operation.

45

.....

Using the Internal-Scan Methodology 2.5 Fixing Testability Problems

2

Using the Internal-Scan Methodology 2.5 Fixing Testability Problems

Megacells such as RAMs pose a problem to the logic in the shadow of the megacell. Figure 2–25 shows a technique to make a RAM input more observable by creating a direct path to a test-point output pin. The test-point output pin can be shared with a functional output pin. Figure 2–25 Creating a Path to an Observe Test-Point Output Pin Fault effects on this logic uniquely flow through the RAM, making them difficult to observe.

Create a direct path to an external output pin.

RAM

RAM Test Observe Output

If you want to insert several observe test points, you can use an EXOR gate to reduce the number of required test-point output pins, as shown in Figure 2–26. Figure 2–26 Multiple Observe Test Points Functional Data

Test Point 1 Test Point 2 Test Point 3

Functional Output / Test Observe Output

Select Control Test Enable (Held at 1 During Test)

Figure 2–27 shows a control-and-observe test point. Figure 2–27 Control-and-Observe Test Point

Test Point 0/1 Control Input Test Enable (Held at 1 During Test)

46

Test Observe Output

All the above examples used external I/O pins to provide controllability and observability. When you are adding scan, you can exploit the scan chain to scan in and scan out the control and observe data, as shown in Figure 2–28. This approach alleviates the need for additional I/O pins. Figure 2–28 Connecting the Control and Observe Test Points to a Scan Flip-Flop

Scan F/F From Previous Scan Flip-Flop

D

Q

SI

SO

To Next Scan Flip-Flop

System Clock Test Enable (Held at 1 During Test)

Bypassing Megacells

.................................................. Megacells modeled as black boxes have a dramatic impact on ATPG fault coverage. To improve testability, add bypass logic from the inputs of a megacell to the output of the same megacell. If the megacell have more input pins than output pins, adding EXOR cells makes the propagation of fault effects easier. Figure 2–29 Megacell Bypass Logic MUX

Megacell Combinational Logic

Combinational Logic

Test Enable (Held at 1 During Test)

Note: Make sure that bypassing a megacell does not create combinational feedback loops.

47

.....

Using the Internal-Scan Methodology 2.5 Fixing Testability Problems

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

2

2.6

Determining Timing Parameters for Scan Test Patterns

Each scan style has unique scan test sequence cycles and timing. You must determine the timing characteristics for testing prior to execution of ATPG. Because zero delay is assumed during ATPG, the length of your tester cycle can be long, provided no hold violations occur. However, long tester cycles lead to long test times; to minimize your test time, it is required that the tester cycle be as short as possible, but it must be long enough for the circuit behavior to be tolerant against timing variations in the real test environment. This section describes how to determine your ATPG timing. Note: ATPG is executed at the chip level. Therefore, you must consider your test timing at the chip level.

Test Timing Parameters for Single-Clocked Scan

..................................................

Figure 2–30 shows the timing parameters you must define for the single-clocked scan design. Figure 2–30 Single-Clocked Scan Timing Waveform Tcycle Functional Data Input Pins Scan-in Input Pins Fixed Input Pins

Tbd

Bidirectional Pins Output Strobe System/Scan Clock Pin

48

Tstb Tdc Twc

■

Tcycle:

Duration of a tester cycle

■

Tbd:

Bidirectional pin timing The time, relative to the beginning of the tester cycle, at which input data is applied to all bidirectional pins

■

Tstb:

Output strobe timing The time, relative to the beginning of the tester cycle, at which all output pins are strobed for expected data comparison. The output strobe must occur before the rising edge of the clock.

■

Tdc / Twc:

System/scan clock timing A pulse waveform must be used for the system/scan clock. The timing can be unique to each system/scan clock. Tdc is the time, relative to the beginning of the tester cycle, at which the rising edge occurs. Twc is the pulse width.

Test Timing Parameters for Dual-Clocked Scan

..................................................

Figure 2–31 shows the timing parameters you must define for the dual-clocked scan design. Figure 2–31 Dual-Clocked Scan Timing Waveform Scan Shift Mode

Scan Capture Mode

Tcycle

Tcycle

Functional Data Input Pins Scan-in Input Pins Fixed Input Pins Tbd Bidirectional Pins Output Strobe

Tstb

Tstb Tdc

System Clock Pin Scan Clock A Pin (Master Clock) Scan Clock B Pin (Slave Clock)

Twc Tdca Tdca Tdcb Twcb Exercised in the master_observe procedure (see "ATPG Test Cycles" on page 184).

■

Tcycle:

Duration of a tester cycle

■

Tbd:

Bidirectional pin timing The time, relative to the beginning of the tester cycle, at which input data is applied to all bidirectional pins

49

.....

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

2

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

■

Tstb:

Output strobe timing The time, relative to the beginning of the tester cycle, at which all output pins are strobed for expected data comparison. The output strobe must occur before the rising edge of every clock.

■

Tdc / Twc:

System clock timing A pulse waveform must be used for the system clock. The timing can be unique to each system clock. Tdc is the time, relative to the beginning of the tester cycle, at which the rising edge occurs. Twc is the pulse width.

■

Tdca / Twca: Scan clock A timing A positive pulse waveform must be used for Scan Clock A. Tdca is the time, relative to the beginning of the tester cycle, at which the rising edge occurs. Twca is the pulse width.

■

Tdcb / Twcb: Scan Clock B timing A positive pulse waveform must be used for Scan Clock B. Tdcb is the time, relative to the beginning of the tester cycle, at which the rising edge occurs. Twcb is the pulse width. The rising edge of Scan Clock B must occur after the falling edge of Scan Clock A.

Determinants for Test Timing

..................................................

Overview Before you can determine the optimal timing parameters to be used for ATPG, you must know the following timing characteristics: ■

Maximum path delays on I/O-to-register, register-to-register, register-to-I/O and I/O-to-I/O paths Calculation of maximum path delays require special test considerations different from system verification. These include: • Test condition: Whether to test the chip using the nominal operating condition alone or in min-max mode. • Output pin loads and input pin slew rates on the tester • Effects of input pins fixed at constant logic values during testing • PLL bypass mode • Elimination of special handling for multi-cycle paths

50

■

Tester restrictions, such as the minimum test cycle, the minimum pulse width, the potential input/output skew on the tester itself, etc.

Ask your Toshiba design center engineer for specific tester guidelines for your design.

Path Delays in Scan Capture Mode Maximum delay values for each of the path groups in scan capture mode are important in determining scan test parameters. There are four types of timing paths: ■

Dif: Maximum delay on paths from external input pins to the data input pins of flip-flips. Exclude external input pins that are fixed at a constant value during testing. For clocks, only system clocks need to be considered.

■

Dff: Maximum delay on paths from the clock input pins of flip-flops to the data input pins of flip-flops. For clocks, only system clocks need to be considered.

■

Dfo: Maximum delay on paths from the clock input pins of flip-flops to external output pins

■

Dio: Maximum delay on paths from external input pins to external output pins. Exclude external input pins that are fixed at a constant value during testing.

Figure 2–32 Types of Timing Paths

Dio IN1

OUT1 Dif

F/F

IN2

Dff

F/F

Dfo OUT2

CLK

Path Delays in Scan Shift Mode The dual-clocked scan technique uses dedicated pins for scan clocks. Timing paths involving scan clocks must be analyzed separately.

51

.....

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

2

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

Path Delays of Bidirectional Enable Lines As described earlier in Section 2.3, "Scan Design Rules," bidirectional pins must be held in input mode so that the output buffer will not be enabled and output a logical value which conflicts with the value from a tester’s driver. During this time, the tester forces all bidirectional pins to a fixed value so that they will not interfere with the scan shift process. However, bidirectional pins go into conflict very briefly due to the circuit delay while the enable signals, activated by the Scan Shift Enable input, are switching. To prevent such conflicts, the application of logic values at bidirectional pins must occur a little after the Scan Shift Enable pin is activated. Figure 2–33 Scan Shift Enable Delay 0 -> 1 Scan Shift Enable L/H -> Z

Dsb: Maximum delay from the time when the Scan Shift Enable input pin is activated to the the time when bidirectional pins are are placed in input mode

Bidirectional Pins

How to Determine the Test Timing

.................................................. You can ensure reliable scan testing by setting all timing parameters but Tbd to large values, but to reduce the required test time, you should minimize the length of a test cycle. Use the following guidelines when defining the test timing. ■

Tcycle Select the maximum of the following: • Minimum test cycle supported by your tester (Ask your Toshiba design center engineer.) • Sum of Dff and potential tester skew • Sum of the maximum value among Dif, Dfo and Dio plus potential tester skew plus 10 ns

52

■

Tbd Set Tbd to the value equal to Dsb.

■

Tsb Sum of Dio and potential tester skew

■

Tic If Dif is larger than Dio, use the sum of Dif plus potential tester skew. If Dio is larger than Dif, use the sum of Dio and potential tester skew.

■

Twc Scan testing does not require the clock duty cycle to be set to 50%. Also, the system clock pulse width can be different between normal operation mode and test mode. Taking the minimum supported tester cycle, input slew rates and the results of clock tree synthesis into consideration, the system clock pulse width can be approximately 10 ns (or 5 ns for >100 MHz testers).

The following example demonstrates how to determine the test timing for a hypothetical design: ■ ■ ■ ■ ■

Target tester: 40 MHz (Tscycle = 25 ns), Potential skew (Tskew) = 5 ns Maximum input pin to flip-flop delay (Dif) = 12 ns Maximum flip-flop to flip-flop delay (Dff) = 20 ns Maximum input pin to output pin delay (Dio) = 20 ns Average Scan Shift Enable to bidirectional enable delay (Dsb) = 5 ns

Test timing parameters are calculated as follows: ■ ■ ■ ■ ■

Tbd = Dsb = 5 ns Tstb = Dfo + Tskew = 25 + 5 = 30 ns Tic = max(Dif, Dio) + Tskew = max(12, 20) + 5 = 25 ns Twc = 10 ns Tcycle = max(Tscycle, (Dff + Tskew), max(Dif, Dfo, Dio) + Twc + Tskew + 10) = max(25, (20 + 5), max (12, 25, 20) + 10 + 5 + 10) = max(25, 25, 50) = 50 ns

53

.....

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

2

54

Using the Internal-Scan Methodology 2.6 Determining Timing Parameters for Scan Test Patterns

Chapter 3

Using JTAG Boundary-Scan Methodology

.....

.....................................

T

his chapter describes a set of recommendations for inserting JTAG logic into your design. This chapter focuses on the topics related to insertion of boundary-scan DesignWare cells by using BSD Compiler. The material is organized into the following sections:

☞ Implementing Instructions ☞ JTAG Boundary-Scan Data ☞ I/O Pin and Buffer Considerations

55

3

3.1

Using JTAG Boundary-Scan Methodology 3.1 Implementing Instructions

Implementing Instructions

Overview of the JTAG Instructions

.................................................. Each JTAG test instruction selects a particular test to be performed and/or the test data register to be accessed. IEEE Std 1149.1 defines three mandatory instructions and six optional instructions. Besides those instructions, IEEE Std 1149.1 allows you to add your own instructions. Table 3–1 Mandatory IEEE Std 1149.1 Instructions Instruction

Function

Code

BYPASS

Selects the 1-bit bypass register to be connected between TDI and TDO to bypass the IC’s boundary-scan chain.

All 1’s (1111....)

SAMPLE/PRELOAD

In Sample mode, samples data traffic flowing through the input and output pads of an IC. In Preload mode, initializes the boundary-scan register with test values.

Arbitrary

EXTEST

Allows circuitry external to an IC to be tested.

All 0’s (0000....)

Table 3–2 Optional IEEE Std 1149.1 Instructions Instruction

Function

INTEST

Tests the IC’s core logic using the boundary-scan register.

RUNBIST

Selects a user-defined BIST register that invokes device self-test functions.

CLAMP

Allows the IC’s pins to be held in a safe state.

IDCODE

Selects the IEEE Std 1149.1-defined device identification register to be connected between TDI and TDO.

USERCODE

Selects a user-defined device identification register to be connected between TDI and TDO.

HIGHZ

Forces all system output pins into the high-impedance state.

† The binary codes for the optional instructions are not defined by IEEE Std 1149.1. They can be arbitrarily defined.

First of all, you must decide what kinds of test functions you will need. When using BSD Compiler, you need to specify JTAG instructions before you can synthesize a boundary-scan design. When you use your own TAP controller, BSD Compiler allows you to implement the mandatory and optional set of IEEE Std 1149.1 instructions as well as user-defined instructions. When you use the DesignWare foundation library TAP controller, only INTEST, IDCODE, RUNBIST, CLAMP and HIGHZ are available as optional instructions.

56

Device Identification Code

.................................................. The device identification code defined in IEEE Std 1149.1 includes a manufacturer identify code. Generally, the ICs fabricated by Toshiba contain the Toshiba’s manufacturer id code. For ASICs, however, the manufacturer id code can be that of the designer, rather than that of Toshiba. Each manufacturer is entrusted to manage generation of device identification codes. If you need an id code, contact your nearest Toshiba design center.

57

.....

Using JTAG Boundary-Scan Methodology 3.1 Implementing Instructions

3

3.2

Using JTAG Boundary-Scan Methodology 3.2 JTAG Boundary-Scan Data

JTAG Boundary-Scan Data

Once you have added JTAG logic to your design, you must generate the following: ■

JTAG test patterns Because JTAG circuitry is a test logic that can operate independently from system logic, system functional patterns can hardly verify the functionality of the JTAG logic. You can use BSD Compiler to generate test patterns for your JTAG logic. (Refer to Chapter 11.)

■

BSDL file Boundary-Scan Description Language (BSDL) allows the description of JTAG boundary-scan logic in an IC in a machine-readable format. BSDL files are required as an interface to a board tester. You can use BSD Compiler to generate a BSDL file.

■

Design documentation Though not mandatory, it is recommended to prepare documentation on the following: • the operations of JTAG and other test logic accessed in response to JTAG instructions • a complete list and description of JTAG and other test control signals IEEE Std 1149.1 includes documentation requirements for any component claiming conformance to the standard.

58

3.3

I/O Pin and Buffer Considerations

This section describes a set of rules and recommendations for I/O pins to be followed when using BSD Compiler to insert JTAG boundary-scan.

Rules for Implementing Optional Instructions

..................................................

Don’t use the PO output of an input buffer for a system input signal when implementing the INTEST instruction.

The INTEST instruction shifts each test pattern through the boundary-scan register (BSR). Since each BSR cell is inserted between the Z output of an input buffer and the core logic, the JTAG test logic has no control over its PO output. When you want to implement the INTEST instruction, you can not use the PO output of an input buffer (or the input portion of a bidirectional buffer) for a system input signal. Use 3-state output buffers for system output pins when implementing the HIGHZ instruction.

When the HIGHZ instruction is selected, all system logic outputs (including 2-state and 3-state output pins and bidirectional pins) of the component must immediately be placed in an inactive-drive state (high-impedance state), as required by IEEE Std 1149.1. Because this rule applies to all system outputs, 3-state output buffers must be used even when system requirements are 2-state outputs.

Rules for the EN and TN Pins of I/O Buffers

..................................................

The 3-state output and bidirectional buffers for Toshiba’s ASICs may have two 3-state control pins called EN and TN. Designs using such I/O buffers require consideration for JTAG insertion.

59

.....

Using JTAG Boundary-Scan Methodology 3.3 I/O Pin and Buffer Considerations

3

Using JTAG Boundary-Scan Methodology 3.3 I/O Pin and Buffer Considerations

IEEE Std 1149.1 specifies that only one control BSR cell can be connected to an I/O pin. Even if both the EN and TN pins of an I/O buffer is used, a BSR cell can only be inserted to either one of them. Therefore, 3-state output and bidirectional buffers should be controlled through either the EN or TN pin. The EN pin is preferred by Toshiba. Also, a signal connected to the EN pin of an I/O buffer must not be connected to the TN pin of another I/O buffer. You may want to use the TN pin only for test purposes such as controlling the direction of bidirectional pins during internal-scan shift or forming a NAND tree. In such cases, the TN pin must be held at logic 1 during JTAG boundary-scan test. The following illustrations show the recommendations for the EN and TN pin connections. Use either the EN or TN pin for system logic. (EN is preferred.) Figure 3–1 Recommendation for the EN and TN Pin Connections (a)

s i h T t EN

No

EN

System Logic

TN

System Logic TN

Don’t connect the same signal to the EN and TN pins of different I/O buffers. (Delete the TN signal connection and route it to the EN pin through an inverter.) Figure 3–2 Recommendation for the EN and TN Pin Connection (b)

EN

t o N TN

EN TN

60

s i Th System Logic

EN TN EN TN

System Logic

If you want to use the TN pin for non-JTAG test purposes such as for a NAND tree test enable or an internal-scan shift enable, the non-JTAG test logic must be disabled during JTAG boundary-scan test. (Use a JTAG-enable pin.) † In this manual, the term "JTAG-enable pin" is used synonymously with "compliance-enable pin" defined in Section 4.8 of the IEEE Std 1149.1 document.

Figure 3–3 Recommendation for the EN and TN Pin Connection (c) JTAG-Enable Input or the EXTC Output from the JTAG Controller NAND Tree Test Enable or Internal-Scan Shift Enable

EN TN

System Logic

If a NAND tree test enable pin or an internal-scan shift enable pin is directly connected to 3-state enable input of a bidirectional buffer, that pin must be held at logic 1 during JTAG boundary-scan test. This means a BSR cell can not be inserted to that pin. Figure 3–3 shows a workaround to this problem where the TN input can be held at logic 1, regardless of the input to the non-JTAG enable pin.

External JTAG Interface

.................................................. The external interface of the JTAG logic consists of the following pins, which are collectively referred to as the test access port (TAP). Table 3–3 External JTAG Interface Pin Name

Type

I/O Buffer Type

Function

TMS

Input

Input buffer with pullup

Test Mode Select

TCK

Input

Input buffer (no pull resistor)

Test Clock

TRST

Input

Input buffer with pullup

Test Reset (active-low)

TDI

Input

Input buffer with pullup

Test Data Input

TDO

Output

3-state output buffer

Test Data Output

61

.....

Using JTAG Boundary-Scan Methodology 3.3 I/O Pin and Buffer Considerations

3

Using JTAG Boundary-Scan Methodology 3.3 I/O Pin and Buffer Considerations

The TAP connections must comply with IEEE Std 1149.1. The subsections that follow describe the considerations for the following: ■

Pin-sharing

■

TRST*

■

Addition of BSR cells

Pin-Sharing Four input pins and one output pin must be allocated for external JTAG interface. IEEE Std 1149.1 states that the TRST* input is optional, but it is required in most cases (see the next section). If you do not have extra pins left for the TAP pins, IEEE Std 1149.1 permits them to be shared with other signals. The rules for pin-sharing are: ■

So that the shared pins can be used as JTAG test pins, one or more dedicated "JTAG-enable input pins" must be allocated. Compliance with IEEE Std 1149.1 must be enabled/disabled by one or more steady-state logic patterns (called "compliance-enable or JTAG-enable patterns") applied at the JTAG-enable pins. (3.8) Note: In this manual, the term "JTAG-enable pin" is used synonymously with "compliance-enable pin" defined in the IEEE Std 1149.1 document.

■

After the application of JTAG-enable patterns, the TRST* input must be asserted (low) to reset the JTAG logic. (5.3)

■

BSR cells must not be provided at JTAG-enable pins. (10.4)

Figure 3–4 Sharing JTAG Test Pins with Other Test Pins JTAG-Enable Input JTAG Logic TMS / Other Test Input

TMS

TDO

TCK / Other Test Input

TCK

TDO-EN

TRST / Other Test Input

TRST

TDI / Other Test Input

TDI

Non-JTAG Test Logic

62

TDO / Other Test Output

Note that JTAG-enable pins require board-level connections to switch on or off compliance with IEEE Std 1149.1.

TRST* Input A reset signal is required to initialize the JTAG logic to the reset state. IEEE Std 1149.1 specifies that the JTAG logic be forced into the reset state at power-up. The initialization must be accomplished by use of a reset signal applied externally or as a result of circuitry built into the test logic. However, the Toshiba ASIC cell library does not allow you to build circuitry that dictates the auto-power-up behavior. Thus, a reset signal needs to be provided from the external world. A general method is to use the TRST* pin at the IC interface and connect it to the on-board power-on-reset. Consequently, although IEEE Std 1149.1 states that the TRST* input is optional, it is required in most cases for Toshiba ASICs. An exception is when your test logic has a power-on-reset, in which case a reset pin may be shared with other signal; however, this does not fully comply with the IEEE Std 1149.1 requirements. IEEE Std 1149.1 requires that an input buffer with a pull-up resistor be used for the TRST* pin, but in actuality, there are ICs using a pull-down resistor at TRST* (violating the rule) so that undriven input causes the JTAG logic to be forced into the reset state. If such ICs are mixed with ICs that comply with the IEEE Std 1149.1 rule, the board’s JTAG logic might not work properly. Therefore, you should consult with your system designer before selecting an input buffer to be used at TRST*.

Addition of BSR Cells You do not have a choice to determine at which pins to add BSR cells and at which pins not to add them. As per IEEE Std 1149.1, you must add a BSR cell to all pins, with the exception of the following pins. ■

JTAG test pins (TAP)

■

JTAG-enable pins

■

Non-digital pins (analog and power/ground pins)

63

.....

Using JTAG Boundary-Scan Methodology 3.3 I/O Pin and Buffer Considerations

3

64

Using JTAG Boundary-Scan Methodology 3.3 I/O Pin and Buffer Considerations

Chapter 4

DFT Considerations

.....

.....................................

T

his chapter describes things you should know during the design specification stage. The material is organized into the following sections. Note: This manual assumes that you use TSTL2 to write test patterns. If you want to use the Standard Tester Interface Language (STIL), contact your Toshiba design center engineer.

☞ Selecting DFT Methodologies ☞ Design Environment ☞ Design-for-Test Flows

65

4

4.1

DFT Considerations 4.1 Selecting DFT Methodologies

Selecting DFT Methodologies

This section describes the considerations for DFT at an early stage.

Principal Criteria for Selecting DFT Methodologies

..................................................

Up-front DFT planning is important to successful DFT and test implementation. During the initial design specification phase, there should be an overall DFT assessment of the design and a DFT strategy should be determined. ■

Internal-Scan The purpose of adding internal-scan to a design is to automatically generate manufacturing test patterns with high fault coverage. To use internal-scan, review the following points: • The ability to adhere to scan design rules • The ability to implement full-scan (Consider possible gate overhead and scan design rules related to flip-flops.) • Scan style: single-clocked or dual-clocked • Allocation of I/O pins for test purposes • Number of scan chains

■

JTAG Boundary-Scan The major purpose of the JTAG boundary-scan is to automate the process of board-level testing. To implement JTAG boundary-scan, you must have extra I/O pins that can be allocated for the TAP and possibly JTAG-enable pins.

■

Memory BIST Memory BIST involves adding test circuitry for generating memory test patterns on-chip and verifying the memory response on-chip. • Toshiba’s MemoryBIST Design System allows you to automatically synthesize and insert BIST logic for SRAMs and mask ROMs. • For DRAMs, Toshiba adds BIST logic for you.

66

Impacts of Inserting DFT Logic

.................................................. While the benefits of DFT are significant, the costs may make some methodologies inappropriate for some designs. During design and DFT planning, these resources required to implement DFT must be accounted for and budgeted: ■

Increase in design size (area impact)

■

Additional package pins

■

Increase in test pattern size and test time

■

Availability of DFT design environment

Area Impact The conversion from a non-scan to a scan design adds a few gates for each scan flip-flop. The JTAG boundary-scan and memory BIST require hundreds to thousands of gates. During the sizing of your design, any area overhead due to DFT logic should be taken into account.

I/O Pin Requirements for Test Purposes Table 4–1 shows the additional I/O pins used by the internal-scan methodology. Table 4–1 I/O Pin Requirements for Internal-Scan Pin Function

Type

Description

Scan Test Enable

Input

–

Enables internal-scan test.

Scan Shift Enable

Input

Shareable

Enables scan chain shifting.

Scan Clock A

Input

Shareable

Scan shift clock for master Required for dual-clocked scan

Scan Clock B

Input

Shareable

Scan shift clock for slave Required for dual-clocked scan

Scan-in

Input

Shareable

Serial data input Required for each scan chain

Output

Shareable

Serial data output Required for each scan chain

Scan-out

67

.....

DFT Considerations 4.1 Selecting DFT Methodologies

4

DFT Considerations 4.1 Selecting DFT Methodologies

Table 4–2 shows the additional I/O pins used by the JTAG boundary-scan methodology. Table 4–2 I/O Pin Requirements for JTAG Boundary-Scan Pin Function

Type

Description

Test Mode Select (TMS)

Input

Controls the transitions of the TAP controller.

Test Clock (TCK)

Input

Test clock input to synchronize the JTAG logic

Test Reset (TRST*)

Input

TAP controller asynchronous reset

Test Data In (TDI)

Input

Test data input pin

Test Data Out (TDO)

Output

JTAG Enable

Test data output pin

Input

Enables JTAG logic functionality. Optional.

Table 4–3 shows the additional I/O pins used by memory BIST. Table 4–3 I/O Pin Requirements for Memory BIST Pin Function

BIST Enable

Type

Input

Description

–

Enables memory BIST.

BIST Clock

Input

Shareable

Test clock input to synchronize the memory BIST logic

BIST Shift Enable

Input

Shareable

Enables shifting of test response for examination (no-scan BIST only)

Output

Shareable

Test response output pin

BIST Data Out

Practically, most designs do not have extra package pins that can be allocated to all of the test signals. Typically, system functional pins are shared with most of the test signals by using one or more Scan Test Enable pins. As a rule of thumb, consider pin-sharing in the following order: 1. Scan-in, Scan-out, BIST Clock, BIST Enable, BIST Data Out 2. Scan Shift Enable, Scan Clock A, Scan Clock B 3. JTAG test pins It is not recommended to use system functional pins as JTAG test pins since they require board-test considerations. An alternative practice is to share common I/O pins between scan and JTAG test pins. In this case, internal-scan circuitry must be permanently disabled once the chip is mounted on a pc board. Thus scan test is only possible during chip test. Figure 4–1 shows a pin-sharing example.

68

Figure 4–1 Pin-Sharing Between Various Test Features Decoder Test Mode 1 Test Mode 2

System Logic Clock Data Out 1 Data In 1

MUX

Scan Chain 1

Data In 2

Scan Chain 2 Data Out 2

Data In 3

MUX Memory BIST Logic

Other Test Structure

Circuit State

Test Mode 1

Test Mode 2

Clock

Data In 1

Data In 2

Data In 3

Data Out 1

Data Out 2

Normal Operation

0

0

System Clock

Functional Data Input

Functional Data Input

Functional Data Input

Functional Data Output

Functional Data Output

Scan Test Mode

1

0

Scan Clock

Scan Shift Enable

Scan-in 1

Scan-in 2

Scan-out 1

Scan-out 2

BIST Mode

0

1

BIST Clock

BIST Enable

BIST Shift Enable

—

BIST Test Out

—

Other Test Mode

1

1

Test Clock

Test Data Input

Test Data Input

Test Data Input

Test Data Output

Test Data Output

Scan Test Pattern Size and Test Time Highly complex designs may require hundreds or thousands of scan test patterns to achieve high fault coverage. During testing, each scan test pattern is serially shifted into the scan chain bit by bit. The bit length of scan test patterns equal the number of flip-flops in the scan chain. Below is a list of techniques to reduce the time required for the scan shift sequence:

69

.....

DFT Considerations 4.1 Selecting DFT Methodologies

4

70

DFT Considerations 4.1 Selecting DFT Methodologies

■

Partition the scan chain into as many scan chains as your tester permits and have them loaded in parallel. Also make the lengths of scan chains balanced. See 2.4, "Scan Chain Number and Balancing," on page 41.

■

Make the length of the test cycle as short as possible. See 2.6, "Determining Timing Parameters for Scan Test Patterns," on page 48.

■

For multiple-system-clock designs, if a set of clocks can be safely clocked in the same cycle, assign them to the same capture clock group during ATPG. See the section "Multiple Capture Clock Groups" on page 36.

4.2

Design Environment

Sign-Off Systems

.................................................. Below is a list of the sign-off tools offered by Toshiba. Sign-off tools contain cell libraries and application programs such as a delay calculator and a simulation results analyzer. ■

VSO VSO is for Verilog-XL and NC-Verilog from Cadence and VCS from Synopsys. VSO supports HDL designs written in Verilog-HDL and is based on gate-level dynamic simulation.

■

VITALSO VITALSO is for Mentor Graphics’ ModelSim and Cadence’s NC-VHDL. VITALSO supports HDL designs written in VHDL and is based on gate-level dynamic simulation.

■

VOYSO VOYSO is for Voyager from IKOS. VOYSO supports HDL designs written in VHDL and is based on gate-level dynamic simulation.

■

GEMINISO GEMINISO is for Gemini from IKOS. GEMINISO supports HDL designs written in Verilog-HDL and is based on gate-level dynamic simulation.

■

PrimeTime Sign-Off (PTSO) System PTSO supports a static timing sign-off flow. The design needs to be mainly synchronous. Designers are responsible for any supplemental functional verification using a dynamic simulator.

Toshiba DFT Design Kits

.................................................. Toshiba provides you with design kits for use with Synopsys’ DFT tools. Design kits are comprised of DFT cell libraries and translation programs to interface to sign-off tools. Below is a list of Toshiba’s Synopsys DFT design kits:

71

.....

DFT Considerations 4.2 Design Environment

4

■

DFT Considerations 4.2 Design Environment

DFT Compiler Library DFT Compiler can be used as an extension of Design Compiler. You can use the standard DC library with DFT Compiler for test synthesis. DC libraries for Toshiba’s ASICs are available from Toshiba.

■

TetraMAX Design Kit The TetraMAX Design Kit contains both cell libraries and interface programs. By using it in conjunction with the Synopsys TetraMAX, you can generate scan test patterns for Toshiba ASIC designs and interface to the sign-off system.

■

BSD Compiler Library BSD Compiler can be used as an extension of Design Compiler. You can use the standard DC library with BSD Compiler for JTAG insertion and verification. DC libraries for Toshiba’s ASICs are available from Toshiba.

■

BSD Compiler Design Kit The BSD Compiler Design Kit contains a utility program used for JTAG insertion. Using it in conjunction with BSD Compiler facilitates JTAG insertion.

Toshiba MemoryBIST Design System

.................................................. Toshiba offers MemoryBIST Design System to allow you to add BIST logic for on-chip SRAMs and mask ROMs. MemoryBIST generates RTL code for the BIST logic. Design Compiler is used to synthesize the BIST logic into gate-level netlists. MemoryBIST then allows you to insert the gate-level BIST logic to your design. You can implement memory BIST together with the internal-scan methodology.

Synopsys DFT Tools

.................................................. Below is a list of the DFT tools from Synopsys supported by Toshiba. ■

DFT Compiler DFT Compiler is an extension to Design Compiler and allows you to implement an internal-scan methodology with a synthesis-based design flow.

72

■

TetraMAX TetraMAX provides an ATPG solution optimized for the full-scan methodology that is integrated with DFT Compiler.

■

BSD Compiler BSD Compiler allows you to perform JTAG insertion and verification within the Design Compiler synthesis environment.

73

.....

DFT Considerations 4.2 Design Environment

4

4.3

DFT Considerations 4.3 Design-for-Test Flows

Design-for-Test Flows

This section shows how scan methodologies fit into the general design flow.

Design Flow for Implementing Internal-Scan Alone

..................................................

Figure 4–2 shows a typical design flow for using DFT Compiler with TetraMAX. Figure 4–2 Typical Design Flow for Internal-Scan Design Using DFT Compiler and TetraMAX Design (RTL/Gate/db)

1. DFT Compiler (Synthesis / Scan Insertion)

2. Scan Design Rule Checking

Gate-Level Netlist

3. TetraMAX (ATPG)

TSTL2 Test Data

4. Sign-off Verification

1. Use DFT Compiler to automate scan insertion as part of your synthesis flow. 2. Perform design rule checking during synthesis or prior to test pattern generation to check adherence to scan design rules. 3. Use TetraMAX to generate manufacturing test patterns and save them in the Toshiba TSTL2 format. 4. Verify the generated netlist and test pattern files for sign-off. If your design can not adhere to the scan design rules or appears to have a lot of shadow elements, it is recommended to perform a trial ATPG run before finalizing your netlist or tuning the timing. Use a sample of faults to quickly assess the likelihood of attaining your fault coverage goal and to check the correctness of any hand-crafted portions of scan logic.

74

Design Flow for Implementing Internal-Scan and JTAG Boundary-Scan

..................................................

Figure 4–3 shows the typical design flow for internal-scan and JTAG boundary-scan insertion using DFT Compiler, BSD Compiler and TetraMAX. Figure 4–3 Typical Design Flow for Internal-Scan and JTAG Boundary-Scan Insertion Subdesigns (Black Boxes/Gate)

Top-Level Design (RTL/Gate/db)

1. BSD Compiler (Synthesis / JTAG Insertion & Verification)

JTAG Test Patterns (TSTL2)

Top-Level Design Netlist w/ JTAG (Gate)

Subdesigns (RTL/Gate/db)

2. DFT Compiler (Synthesis / Scan Insertion)

Netlist with JTAG and Scan (Gate)

4. TetraMAX (ATPG)

3. BSD Compiler (JTAG Verification)

ATPG Test Patterns (TSTL2)

5. Sign-off Verification

1. Use BSD Compiler to insert JTAG boundary-scan logic to the top level of your design hierarchy and check the compliance of your design against IEEE Std 1149.1. Then generate JTAG test pattern and BSDL files. For JTAG insertion, lower modules that comprise system logic can be black boxes with only port declarations. 2. Use DFT Compiler to automate scan insertion as part of your synthesis flow. At this time, you can optionally insert internal-scan logic to the JTAG logic. So that internal-scan can be inserted to the JTAG logic, the following two must be satisfied: • One or more JTAG-enable inputs must be provided to disable internal-scan mode.

75

.....

DFT Considerations 4.3 Design-for-Test Flows

4

DFT Considerations 4.3 Design-for-Test Flows

• An inverted TCK signal must be supplied to the update register portions of the boundary-scan register (BSR) cells. You can use check_bsd to check if your JTAG logic meets the above requirements. 3. Run the BSD Compiler check_bsd command to check the compliance of your design against IEEE Std 1149.1. You must re-run check_bsd if you alter your JTAG logic during internal-scan insertion or any subsequent design phases. 4. Use TetraMAX to generate manufacturing test patterns. 5. Verify the generated netlist and test pattern files for sign-off.

Design Flows for Implementing Internal-Scan and Memory BIST

..................................................

Toshiba offers the MemoryBIST Design System for the synthesis of BIST logic for SRAMs and mask ROMs.

Adding Memory BIST Logic Alone For starters, Figure 4–4 shows a typical design flow for adding memory BIST logic alone using MemoryBIST.

76

Figure 4–4 Typical Design Flow for MemoryBIST BISTGROUP File

Design (RTL/Gate/db)

1. bist_lib_gen (BIST Generation)

DC script

RTL BIST Logic

Design Compiler (Synthesis)

Design Compiler (Synthesis)

Gate-Level BIST Logic

Gate-Level Netlist

2. bist_insert (BIST Insertion / Test Pattern Generation)

Gate-Level BISTed Netlist

TSTL2 Test Data

1. Divide RAMs and ROMs into groups and run bist_lib_gen to generate synthesizable RTL models for the BIST logic. 2. After synthesis, run bist_insert to add the gate-level BIST logic to your design. When your design is scanned, you can also convert the BIST logic to scan to enhance the overall fault coverage. bist_insert replaces RAMs and ROMs with BISTed modules with mux collars, which incurs some delay overhead; you should budget an increase of the delay during synthesis.

Adding Internal-Scan and Memory BIST Logic Figure 4–5 shows a typical design flow for adding BIST and scan logic using MemoryBIST with DFT Compiler and TetraMAX.

77

.....

DFT Considerations 4.3 Design-for-Test Flows

4

DFT Considerations 4.3 Design-for-Test Flows

Figure 4–5 Typical Design Flow Using MemoryBIST with DFT Compiler and TetraMAX Design (RTL/Gate/db)

BISTGROUP File

2. Manual Editing (Add scan commands.)

DC script

1. bist_lib_gen (BIST Generation) 3. DFT Compiler (Synthesis / Scan Insertion)

RTL BIST Logic

3. DFT Compiler (Synthesis / Scan Insertion)

Gate-Level Scanned BIST Logic

Gate-Level Scanned Netlist

4. bist_insert (BIST Insertion / Test Pattern Generation)

Gate-Level BISTed Netlist

TSTL2 BIST Test Data

5. Manual Editing or DFT Compiler (BIST Scan Connection)

Gate-Level Scanned/BISTed Netlist

SPF

6. TetraMAX (Test Pattern Generation)

ATPG Patterns (TSTL2)

7. Sign-off Verification

1. Divide RAMs and ROMs into groups and run bist_lib_gen to generate synthesizable RTL models for the BIST logic. 2. The DC script file from bist_lib_gen contains no dc_shell commands for scan synthesis. Add scan synthesis commands to it.

78

3. Use DFT Compiler to synthesize both BIST and system logic directly to scanned gates. Scan routing can be done either at this stage or later at Step 6. 4. Use bist_insert to insert the gate-level BIST logic to your netlist and generate BIST test patterns. 5. If you performed scan routing at Step 3, either edit the netlist manually or use DFT Compiler to connect the scan chain in the BIST logic to system functional modules. If you did not perform scan routing at Step 3, use DFT Compiler to route scan chains through both the BIST and system functional modules. 6. Use the TetraMAX ATPG to generate scan test patterns. 7. Verify the generated netlist, and BIST and ATPG test pattern files for sign-off.

79

.....

DFT Considerations 4.3 Design-for-Test Flows

4

80

DFT Considerations 4.3 Design-for-Test Flows

CMOS ASIC Design Manual

Part 2 Using the Synopsys DFT Tools

81

Synopsys-DFT User Guide

82

Chapter 5

Setting Up the Design Environment

.....

.....................................

T

his chapter describes how to set up the design environment for scan design using the Synopsys DFT tools. The material is organized into the following sections:

☞ Synopsys DFT Tools and Toshiba Design Kits ☞ Installing and Setting Up Toshiba’s Design Kits and Libraries

83

5

5.1

Setting Up the Design Environment 5.1 Synopsys DFT Tools and Toshiba Design Kits

Synopsys DFT Tools and Toshiba Design Kits

Supported DFT Tools

..................................................

DFT Compiler To use Synopsys’ DFT Compiler in the Toshiba ASIC design environment, you must have the following software installed on your workstation: ■

Synopsys Design Compiler Scan synthesis capability is available with the optional DFT Compiler license. If you have Design Compiler installed on your workstation, no extra software installation is required. You just need to obtain a license for DFT Compiler.

■

Toshiba Design Compiler library

BSD Compiler To use Synopsys’ BSD Compiler in the Toshiba ASIC design environment, you must have the following software installed on your workstation: ■

Synopsys Design Compiler The BSD Compiler license is available as an extension to Design Compiler. If you have Design Compiler installed on your workstation, no extra software installation is required. You just need to obtain a license for BSD Compiler.

■

Toshiba Design Compiler library

■

Toshiba BSD Compiler design kit

TetraMAX To use Synopsys’ TetraMAX in the Toshiba ASIC design environment, you must have the following software installed on your workstation:

84

■

Synopsys TetraMAX

■

Toshiba TetraMAX design kit

■

Toshiba TetraMAX library Note: You must validate test patterns generated by TetraMAX for design sign-off. Therefore, a Toshiba sign-off tool is required.

Installing DFT Compiler, BSD Compiler and TetraMAX

..................................................

Both DFT Compiler, BSD Compiler and TetraMAX are installed in a directory pointed to by the environmental variable $SYNOPSYS. For installation procedures, refer to the release notes that accompany your Synopsys products.

85

.....

Setting Up the Design Environment 5.1 Synopsys DFT Tools and Toshiba Design Kits

5

5.2

Setting Up the Design Environment 5.2 Installing and Setting Up Toshiba’s Design Kits and Libraries

Installing and Setting Up Toshiba’s Design Kits and Libraries

Directory Structure

.................................................. All the Toshiba tools and libraries, including a sign-off system, are installed in a directory pointed to by the environmental variable $TOSH_ROOT. Figure 5–1 exemplifies the directory structure beneath $TOSH_ROOT. Figure 5–1 $TOSH_ROOT Directory Structure $TOSH_ROOT toshiba_common lib tmax verilog dft bin_Solaris bin_Linux32 bin_HP etc message tmax bin_Solaris bin_Linux32 bin_HP demo doc lib rule bsdc bin_Solaris bin_Linux32 bin_HP demo doc rule

86

Installation

.................................................. To install a design kit or a library, decompress the delivered file in the $TOSH_ROOT directory. For a description of the installation procedure, refer to the release notes that accompany your design kit or library release.

Setting UNIX Environment Variables

.................................................. Once you have installed the Toshiba design kit, set the TOSH_ROOT variable to the installation directory set to the paths to Xterm and the binary directory. For the C shell, for example, you can use the following commands: setenv TOSH_ROOT install_dir set path = ( $TOSH_ROOT/dft/bin_ /usr/openwin/bin $path )

To use TetraMAX, set these variables: setenv DISPLAY IP_address:0 setenv LANG C

To use TetraMAX 2005.05 or above, also set this variable: setenv LTRAN_SHELL 1

Setting the Library Environment

..................................................

Design Compiler Library To use the Design Compiler library, set these variables in a DC script file, or set them in the .synopsys_dc.setup file. Replace the technology name in the following commands with an appropriate name. tsb_lib_path = { "install_dir", "install_dir/tc240c" } search_path = search_path + tsb_lib_path link_library = { "*" tc240c.db_WCCOM25 tc240ct_io_macro.db } target_library = { tc240c.db_WCCOM25 } set_min_library tc240c.db_WCCOM25 -min_version tc240c.db_BCCOM25

87

.....

Setting Up the Design Environment 5.2 Installing and Setting Up Toshiba’s Design Kits and Libraries

5

Setting Up the Design Environment 5.2 Installing and Setting Up Toshiba’s Design Kits and Libraries

symbol_library = { tc240c.workview.sdb }

Theinstall_dir indicates the directory pointed to by the variable $TOSH_ROOT.

BSD Compiler BSD Compiler utilizes the DesignWare libraries. Add the following lines to the DC setup file. The version of BSD Compiler must match that of the DesignWare libraries. synthetic_library = { standard.sldb dw01.sldb dw02.sldb dw03.sldb \ dw04.sldb dw06.sldb } link_library = { "*" tc240c.db_WCCOM25 tc240ct_io_macro.db } + \ syntetic_library

TetraMAX Library To read a TetraMAX library, use the read netlist command as shown below. You can use the $TOSH_ROOT variable in specifying the pathname. BUILD> read netlist -library \ $TOSH_ROOT/lib/tmax/TC240CT/TC240CT.tmaxlib

88

Chapter 6

Scan Synthesis Methodology Using DFT Compiler

.....

.....................................

T

his chapter describes the scan synthesis methodology using DFT Compiler. The material is organized into the following sections:

☞ Overview of Test-Ready Compile ☞ Naming Rules for Ports, Cells and Nets ☞ Sample DC Script for Scan Synthesis ☞ Step-by-Step Scan Synthesis Procedure ☞ Considerations for Scan Synthesis Using DFT Compiler

89

6

6.1

Scan Synthesis Methodology Using DFT Compiler 6.1 Overview of Test-Ready Compile

Overview of Test-Ready Compile

Scan Synthesis Strategy

.................................................. Figure 6–1 shows the dc_shell commands used in the scan synthesis process and when they are executed in the overall design synthesis flow. Figure 6–1 Scan Synthesis Commands Typical Design Compiler Design Flow

Scan Synthesis Commands

Read in a design. (read, analyze, link, etc.)

Describe design constraints.

Set a scan style and constraints. (set_scan_configuration, set_scan_signal, set_test_hold)

Synthesize a design. (compile)

Perform scan synthesis. (compile -scan, insert_scan)

Evaluate the design. (check_design, etc.)

Check scan design rules. (check_test, report_test)

Write out the design. (write)

Set ATPG timing attributes. Write a test protocol file. (test_default_cycle, write_test_protocol, etc.)

Scan synthesis has two stages: scan replacement and scan assembly. The compile -scan command performs scan replacement during the initial mapping of a design to gates. After scan replacement, the insert_scan (or insert_dft) command is used to assemble scan chains. Figure 6–2 illustrates the functionality of these commands.

90

Figure 6–2 The compile -scan and insert_scan Commands RTL Design

Set synthesis constraints and scan style.

Test-ready compile maps all sequential cells directly to scan flip-flops. Scan flip-flops are not scan-chained together; a loop is connected from the scan-out pin of a flip-flop to the scan-in pin of the same flip-flop. All scan control pins are tied to ground. FD1SF

compile -scan

SI

Gate-Level Design

FD1SF

SO

SI

SO

Identify scan ports and check design rules. Temporary connections are deleted and replaced by actual scan connections. insert_scan FD1SF Gate-Level Scanned Design

SI

Scan-in

SO

FD1SF

SI

SO

Scan-out

You can perform scan replacement block by block, then execute the insert_scan (or insert_dft) command at the top level of the design. Alternatively, you can run compile without the -scan option, in which case all sequential cells are mapped to non-scan cells. When you run insert_scan (or insert_dft) on the mapped design, both scan replacement and scan assembly occur simultaneously. For a detailed description, see 6.5, "Considerations for Scan Synthesis Using DFT Compiler," on page 110.

Designing Block by Block

.................................................. You may want to build scan chains at the top level of your design, or you may want to build them block by block. The subsections that follow describe each of these design flows.

Building Scan Chains at the Top Level of a Design Using the design flow shown in Figure 6–3, you can run compile -scan on each of the modules, then build scan chains at the top level.

91

.....

Scan Synthesis Methodology Using DFT Compiler 6.1 Overview of Test-Ready Compile

Scan Synthesis Methodology Using DFT Compiler 6.1 Overview of Test-Ready Compile

6

Figure 6–3 Building Scan Chains at the Top Level of a Design Module A (RTL)

Module B (RTL) No scan port

DFT Compiler

No scan port

DFT Compiler

compile -scan

compile -scan

Gate-level

Gate-level No scan port Mapped to scan flip-flops No scan chain

No scan port Mapped to scan flip-flops No scan chain

Top Level

insert_scan

After scan assembly No scan port No flip-flops in the top-level module No scan connections between modules

Equal-length scan chains

The advantages of this design flow are: ■

You don’t need to define scan ports in each submodule before assembling scan chains at the top level of your design.

■

You can implement automatically balanced scan chains.

The disadvantages of this design flow are:

92

■

Your design may be too large to be compiled flat all at one time in Design Compiler.

■

You must complete your entire design and scan replacement before you can build scan chains.

Building Scan Chains in Each Module You may prefer to develop your design on a module-by-module basis. Using the design flow shown in Figure 6–4, you can implement a complete scan architecture in each module as it is developed. When you want to use this flow, you must include scan ports in each prescan module. Figure 6–4 Building Scan Chains in Each Module Module A (RTL)

Module B (RTL) Existing scan ports

DFT Compiler

Existing scan ports

DFT Compiler

compile -scan insert_scan

compile -scan insert_scan

Gate-level

Gate-level A scan chain is stitched and connected to scan ports.

A scan chain is stitched and connected to scan ports.

Top Level

After scan assembly Existing scan ports No flip-flops in the top-level module No scan connections between modules

Unbalanced scan chains

The advantages of this design flow are: ■

You can obtain complete netlists (with scan) module by module.

■

You can handle large designs exceeding the capacity limitations of Design Complier.

93

.....

Scan Synthesis Methodology Using DFT Compiler 6.1 Overview of Test-Ready Compile

6

Scan Synthesis Methodology Using DFT Compiler 6.1 Overview of Test-Ready Compile

The disadvantages of this design flow are: ■

You must stitch scan chains between modules beforehand.

■

An unbalanced scan architecture may be created (with scan chains of unequal length) because scan connections are predetermined in each module.

In the example shown in Figure 6–4, the chip-level scan architecture is completed when you have the two submodules. You don’t need to pre-define scan ports and scan connections in the top level; you can use insert_scan to build the scan chains in the top level.

Scan Design Rule Checking

.................................................. Perform scan design rule checking at the following phases with either the check_test or check_dft command: 1. Before running insert_scan (or insert_dft) Load the RTL code of your design and run compile -scan to synthesize a gate-level design. Then run check_test on the gate-level design to check for scan design rule violations. At this phase, check_test determines whether the flip-flops in your design can be replaced by their scan equivalents, whether your design has no combinational feedback loops, and so on. Fix design rule violations in one of the following ways: • Modify your RTL code. • Use the AutoFix feature of insert_dft to automatically fix design rule violations during scan conversion. 2. After running insert_scan (or insert_dft) Run check_test to check the scan-chain connections and the corrections made by the AutoFix feature of insert_dft. 3. After synthesizing all subdesigns and assembling them together Run check_test at the chip level. You can also check for scan design rule violations in a TetraMAX session.

94

6.2

Naming Rules for Ports, Cells and Nets

When you use Toshiba’s sign-off system, you must observe the naming rules imposed by it, in addition to the conventions of the HDL language (Verilog-HDL or VHDL) being used. For the naming rules of your sign-off system, refer to the VSO/VITALSO x.xx User Guide. When you adopt DFT methodologies, you also need to follow these guidelines: ■

When you use internal-scan design, don’t use the slash character (/) in instance names.

■

When you use JTAG boundary-scan, don’t use the reserved words of VHDL and BSDL.

You can use the change_names command to change the names of ports, cells and nets to conform to the specified rules. Figure 6–5 shows an example of a change_names script you can use for Verilog-HDL designs. Figure 6–5 Sample change_names Script for Verilog-HDL Designs /* ** VSO Naming Rules for Ports, Cells and Nets */ define_name_rules toshiba \ -max_length 50 \ -restricted ".*" \ -first_restricted "|!\"#$%&'()=\\-^~{}`@:[]/?<>," \ -map {{"_TSB","_TB"},{"_Tsb","_Tb"},{"_TSb","_Tb"},{"_tsb","_tb"}, \ {"_tsB","_tB"},{"_tSB","_tB"}} \ -reserved_words {always, and, assign, begin, buf, bufif0, bufif1, case, \ casex, casez, cmos, deassign, default, defparam, disable, \ edge, else, end, endattribute, endcase, endfunction, \ endmodule, endprimitive, endspecify, endtable, endtask, \ event, for, force, forever, fork, function, highz0, highz1, \ if, initial, inout, input, integer, join, large, \ macromodule, medium, module, nand, negedge, nmos, nor, not, \ notif0, notif1, or, output, parameter, pmos, posedge, \ primitive, pull0, pull1, pullup, pulldown, reg, rcmos, reg, \ release, repeat, rnmos, rpmos, rtran, rtranif0, rtranif1, \ scalared, small, specify, specparam, strength, strong0, \ strong1, supply0, supply1, table, task, time, tran, \ tranif0, tranif1, tri, tri0, tri1, trinand, trior, trireg, \ use, vectored, wait, wand, weak0, weak1, while, wire, wor, \ xor, xnor} /* ** VSO Naming Rules for Ports */ define_name_rules toshiba_ports \ -max_length 35 \ -type port \ -allowed "A-Z a-z 0-9 _ [ ] " \ -first_restricted "0-9 _ [ ] " \ -map {{"^VDD","XVDD"},{"^VDd","XVDd"},{"^Vdd","XVdd"},{"^vdd","xvdd"}, \

95

.....

Scan Synthesis Methodology Using DFT Compiler 6.2 Naming Rules for Ports, Cells and Nets

6

Scan Synthesis Methodology Using DFT Compiler 6.2 Naming Rules for Ports, Cells and Nets

{"^vdD","xvdD"},{"^vDD","xvDD"},{"^VSS","XVSS"},{"^VSs","XVSs"}, \ {"^Vss","XVss"},{"^vss","xvss"},{"^vsS","xvsS"},{"^vSS","xvSS"}, \ {"_TSB","_TB"}, {"_Tsb","_Tb"}, {"_TSb","_Tb"}, {"_tsb","_tb"}, \ {"_tsB","_tB"},{"_tSB","_tB"}} \ -reserved_words {always, and, assign, begin, buf, bufif0, bufif1, case, \ casex, casez, cmos, deassign, default, defparam, disable, \ edge, else, end, endattribute, endcase, endfunction, \ endmodule, endprimitive, endspecify, endtable, endtask, \ event, for, force, forever, fork, function, highz0, highz1, \ if, initial, inout, input, integer, join, large, \ macromodule, medium, module, nand, negedge, nmos, nor, not, \ notif0, notif1, or, output, parameter, pmos, posedge, \ primitive, pull0, pull1, pullup, pulldown, reg, rcmos, reg, \ release, repeat, rnmos, rpmos, rtran, rtranif0, rtranif1, \ scalared, small, specify, specparam, strength, strong0, \ strong1, supply0, supply1, table, task, time, tran, \ tranif0, tranif1, tri, tri0, tri1, trinand, trior, trireg, \ use, vectored, wait, wand, weak0, weak1, while, wire, wor, \ xor, xnor, NC, Nc, nC, nc} /* ** Naming rules for Toshiba’s scan methodology */ define_name_rules toshiba_scan -restricted "/" /* ** JTAG Naming Rules: VHDL reserved words can not be used as package pin names. */ define_name_rules jtag_vhdl \ -type port \ -allowed "A-Z a-z 0-9 _ [ ] " \ -reserved_words {abs, access, after, alias, all, and, architecture, array, \ assert, attribute, begin, block, body, buffer, bus, case, \ component, configuration, constant, disconnect, downto, \ else, elsif, end, entity, exit, file, for, function, \ generate, generic, guarded, if, in, inout, is, label, \ library, linkage, loop, map, mod, nand, new, next, nor, \ not, null, of, on, open, or, others, out, package, port, \ procedure, process, range, record, register, rem, report, \ return, select, severity, signal, subtype, then, to, \ transport, type, units, until, use, variable, wait, when, \ while, with, xor} \ -case_insensitive /* ** JTAG Naming Rules: BSDL reserved words can not be used as package pin names. */ define_name_rules jtag_bsdl \ -type port \ -allowed "A-Z a-z 0-9 _ [ ] " \ -reserved_words {at_pins, bc_0, bc_1, bc_2, bc_3, bc_4, bc_5, bc_6, bc_7, bc_8, bc_10, bc_11, bc_12, bc_13, bc_14, bc_15, bc_16, bc_17, bc_18, bc_20, bc_21, bc_22, bc_23, bc_24, bc_25, bc_26, bc_27, bc_28, bc_30, bc_31, bc_32, bc_33, bc_34, bc_35, bc_36, bc_37, bc_38, bc_40, bc_41, bc_42, bc_43, bc_44, bc_45, bc_46, bc_47, bc_48, bc_50, bc_51, bc_52, bc_53, bc_54, bc_55, bc_56, bc_57, bc_58, bc_60, bc_61, bc_62, bc_63, bc_64, bc_65, bc_66, bc_67, bc_68, bc_70, bc_71, bc_72, bc_73, bc_74, bc_75, bc_76, bc_77, bc_78, bc_80, bc_81, bc_82, bc_83, bc_84, bc_85, bc_86, bc_87, bc_88, bc_90, bc_91, bc_92, bc_93, bc_94, bc_95, bc_96, bc_97, bc_98,

96

bc_9, \ bc_19, \ bc_29, \ bc_39, \ bc_49, \ bc_59, \ bc_69, \ bc_79, \ bc_89, \ bc_99, \

bidir, bidir_in, bidir_out, both, boundary, boundary_length, \ boundary_register, bscan_inst, bsdl_extension, bypass, cap, cap_data, \ captures, cell_data, cell_info, cell_type, clamp, clock, clock_info, \ clock_level, compliance_patterns, component_conformance, control, \ controlr, design_warning, device_id, differential_current, \ differential_voltage, expect_data, extest, highz, id_bits, id_string, \ idcode, idcode_register, input, instruction_capture, instruction_length, \ instruction_opcode, instruction_private, internal, intest, intest_execution, \ low, observe_only, observing, one, output2, output3, physical_pin_map, \ pi, pin_map, pin_map_string, po, port_grouping, pull0, pull1, \ register_access, runbist, runbist_execution, sample, std_1149_1_1990, \ std_1149_1_1993, std_1149_1_1994, tap_scan_clock, tap_scan_in, \ tap_scan_mode, tap_scan_out, tap_scan_reset, upd, usercode, \ usercode_register, wait_duration, weak0, weak1, x, z, zero} \ -case_insensitive /* ** Change names in a design with internal-scan. */ current_design TOP change_names -hierarchy -rules toshiba change_names -hierarchy -rules toshiba_scan change_names -rules toshiba_ports /* ** Change names in a design with JTAG boundary-scan. */ change_names -rules jtag_vhdl change_names -rules jtag_bsdl

97

.....

Scan Synthesis Methodology Using DFT Compiler 6.2 Naming Rules for Ports, Cells and Nets

6

6.3

Scan Synthesis Methodology Using DFT Compiler 6.3 Sample DC Script for Scan Synthesis

Sample DC Script for Scan Synthesis

Figure 6–6 shows an example of a DC script that includes commands that are specifically used for scan synthesis. Each command is explained in the next section. Figure 6–6 DC Script for Scan Synthesis /* ** FILE NAME : syn_muxscan.scr ** SCAN TYPE : Mux-scan ** This script compiles the design and performs scan synthesis. */ /* ** Read and link the design. */ read -f verilog {CKTCORE.v CKTTOP.v_prescan} current_design CKTTOP link /* ** Create a clock and set delay constraints on I/O ports. */ create_clock -name CLK -period 20 -waveform {0.0 10.0} CLK set_clock_skew -uncertainty 0.2 CLK set_fix_hold CLK set_input_delay 18.0 -clock CLK {all_inputs() - "CLK"} set_output_delay 18.0 -clock CLK all_outputs() /* ** Select a scan style and set a test mode constraint. */ set_scan_configuration -style multiplexed_flip_flop set_test_hold 1 RESETN /* ** Perform test-ready compile. */ set_max_area 0.0 compile -scan -map_effort high /* ** Identify scan-in, scan-out and scan-enable ports. */ set_scan_signal test_scan_in -port DIA0 -hookup ui0/Z set_scan_signal test_scan_out -port DO0 -hookup uo0/A set_scan_signal test_scan_enable -port SCAN_ENABLE -hookup ui13/Z /* ** Check scan design rules. */ check_test

98

/* ** Build scan chains. */ insert_scan /* ** Set timing parameters for scan test. */ test_default_period = 100 test_default_delay = 0 test_default_bidir_delay = 0 test_default_strobe = 40 create_test_clock "CLK" -waveform { 50 70 } /* ** Recheck scan design rules and generate a scan-related report. */ check_test > scan_design.report report_test -scan -assertions -atpg_conflict >> scan_design.report /* ** Write a STIL procedure file for TetraMAX. */ test_stil_netlist_format = verilog write_test_protocol -format stil -o CKTTOP.spf /* ** Write out a netlist. */ write -format verilog -o CKTTOP.v_postscan -h quit

99

.....

Scan Synthesis Methodology Using DFT Compiler 6.3 Sample DC Script for Scan Synthesis

6

6.4

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

Step-by-Step Scan Synthesis Procedure

Reading in the Design and Preparing for Logic Synthesis

..................................................

The following command sequence prepares a design for logic synthesis, in much the same way as a typical synthesis process: dc_shell> read -f verilog CKT.v.rtl dc_shell> current_design CKT dc_shell> create_clock -name CLK -period 20 \ -waveform { 0.0 10.0 } CLK dc_shell> set_clock_skew -uncertainty 0.2 all_clocks() dc_shell> set_fix_hold CLK dc_shell> set_input_delay 18.0 -clock CLK { all_inputs() - "CLK" } dc_shell> set_output_delay 18.0 -clock CLK all_outputs()

Specifying the Scan Architecture

.................................................. Prior to invoking compile, you must declare the scan test methodology by using the set_scan_configuration command. This command allows you to select a scan style, specify the number of scan chains and so on.

Syntax The syntax of the set_scan_configuration command is: set_scan_configuration [-style multiplexed_flip_flop|lssd] [-chain_count number_of_chains] [-existing_scan true|false] [-dedicated_scan_ports true|false]

Options -style

100

Identifies a scan style. Select multiplexed_flip_flop if you want to implement the single-clocked scan structure, or lssd if you want to implement the dual-clocked scan structure.

-chain_count

Forces insert_scan to build the specified number of scan chains.

-existing_scan If true, causes insert_scan to recognize existing scan chains in the

design. -dedicated_scan_ports

Specifies whether or not insert_scan should build a dedicated scan-out port for the scan chain. By default, insert_scan uses an existing data output port as a scan-out port. Table 6–1 shows the types of selected scan flip-flops, depending on which scan style you choose with the -style option. Table 6–1 Scan Flip-Flop Types Selected by the -style Argument Technology

multiplexed_flip_flop

lssd

FDnSm

FDnSFm

Up to TC220G Gate Arrays and Embedded Arrays Up to TC220C Cell-Based ICs

FDnEm

FDnSFm

GFDnEXm

GFDnSFXm

CFDnEXm, CFDnEAXm

CFDnSFXm

TC280

CFDnEXm, CFDnEQXm, CFDnMEXm, CFDnMEQXm

CFDnSFXm,CFDnSFQXm, CFDnMSFXm, CFDnMSFQXm

TC300

CFDnMSQXm, CFDnMSXm, CFDnSQXm, CFDnQXm

Provided on an individual basis

From TC240E Embedded Arrays TC240C to TC260C Cell-Based ICs

n: 1, 2, 3, 4, 5 or 3L1

m: P, R, RR, 1, 2, 4, 8 or L

TC240C to TC260C cell-based IC families offer two types of scan flip-flops: CFDnEXm and CFDnEAXm. While CFDnEXm is optimized for area, it provides smaller hold slack during scan shift. Hold violations can be a problem if you use it in a design with potentially large clock skew. In contrast, CFDnEAXm is not so susceptible to hold violations, but is a little physically larger than CFDnEXm. In Toshiba’s DC library, CFDnEXm has the dont_use attribute on it, so CFDnEAXm is used by default.

Command Input Example Here is an example usage of set_scan_configuration: dc_shell> set_scan_configuration -style lssd \ -dedicated_scan_ports true dc_shell> test_disable_find_best_scan_out = true

101

.....

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

6

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

Note: LSSD scan flip-flops and all scan flip-flops for the TC300 family have a dedicated Scan-Out pin. So that DFT Compiler will use the Scan-Out pin for scan chain connections, enter: set_scan_configuration -dedicated_scan_ports true test_disable_find_best_scan_out = true Without these settings, DFT Compiler might connect scan flip-flops using the system data output pins (Q and QN) instead of the Scan-Out (SO) pins.

Holding Input Ports at Constant Values During Testing

..................................................

If your design has any input ports that should maintain a constant logic value during testing, use the set_test_hold command to set a hold value.

Syntax The syntax of the set_test_hold command is: set_test_hold {0|1} port_list

Command Input Example Here is an example usage of set_test_hold: dc_shell> set_test_hold 1 RSTN

Synthesizing a Design

.................................................. Use the compile command to synthesize a design. The -scan option instructs compile to implement all sequential functions with scan flip-flops during the initial mapping of a design to gates. The insert_scan command is used later to assemble scan chains.

102

If you wish, you can also run compile without the -scan option, so all sequential cells are mapped to non-scan cells; in this case, you can use insert_scan at the top level of the design to perform scan replacement and assembly at the same time. For this design flow, see 6.5, "Considerations for Scan Synthesis Using DFT Compiler," on page 110.

Syntax The syntax of the compile command is: compile [-scan]

Option -scan

Performs test-ready compile, mapping all sequential cells directly to scan flip-flops.

Command Input Example Here is an example usage of compile: dc_shell> compile -scan

Identifying Scan Test Ports

.................................................. Prior to building scan chains, you must identify scan test ports with the set_scan_signal command.

Syntax The syntax of the set_scan_signal command is: set_scan_signal scan_signal_type -port port_list [-hookup pin [-sense sense]]

103

.....

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

6

Table 6–2 shows the valid scan signal types. Table 6–2 Valid Scan Signal Types Scan Signal Type

Function

test_scan_in

Scan-in

test_scan_out

Scan-out

test_scan_enable

Scan Shift Enable (active-high)

I/O

Input Output Input

test_scan_enable_inverted

Scan Shift Enable (active-low)

Input

test_scan_clock_a

Scan Clock A (master)

Input

test_scan_clock_b

Scan Clock B (slave)

Input

Options -port

Identifies ports that insert_scan can use for the specified scan signal type. The ports must exist in the design. insert_scan will attribute them as specific types.

-hookup

Causes insert_scan to connect scan signals to the specified hookup pins. insert_scan still assigns signal type attributes to the ports identified by the -port option. Unless you give the -hookup option, the behavior of insert_scan depends on the presence or absence of I/O buffers at the ports; if I/O buffers are found, insert_scan connects scan signals to the core side of them; if I/O buffers aren’t found, insert_scan connects scan signals directly to the ports.

In the single-clocked scan design, the Scan Shift Enable input drives all flip-flops in a scan chain. In the dual-clocked scan design, Scan Clock A and Scan Clock B drive all flip-flops in a scan chain. Therefore, it is necessary to buffer these signals to increase their drive strength. You can create buffer trees in two ways, either in DFT Compiler or during clock tree synthesis (CTS) in a layout tool, as explained in the section "Inserting Buffer Trees" on page 29. When you choose to employ CTS to do this, assign the dont_touch_network attribute to the above scan signals in DFT Compiler. For more on the set_scan_signal command, see 6.5, "Considerations for Scan Synthesis Using DFT Compiler," on page 110.

Command Input Examples Here are some example usages of set_scan_signal: dc_shell> dc_shell> dc_shell> dc_shell>

104

set_scan_signal test_scan_enable -port SEN -hookup usen/Z set_dont_touch_network usen/Z set_scan_signal test_scan_in -port DIA[0] -hookup udiA0/Z set_scan_signal test_scan_out -port DOA[0] -hookup \ udoA0/A

Performing Design Rule Checking

.................................................. It is recommended to check the scan design rules at this stage with the check_test command. The purpose of running check_test here is to determine whether all sequential cells in your design can be recognized correctly.

Syntax The syntax of the check_test command is: check_test

Command Input Example Here is the simplest invocation of check_test: dc_shell> check_test

At the end of the check_test output, DFT Compiler provides a summary of the test status of sequential cells in your design, as shown in Figure 6–7. Figure 6–7 Sequential Cell Summary in the check_test Output ************************************************** Sequential Cell Summary 2 out of 5 sequential cells have violations ************************************************** SEQUENTIAL CELLS WITH VIOLATIONS * 2 cells are black boxes * 2 cells are identified causes of other reported violations SEQUENTIAL CELLS WITHOUT VIOLATIONS * 3 cells are valid scan cells

Within the summary, sequential cells are divided into two categories: those with violations and those without. The report shown in Figure 6–7 indicates that two cells are treated as black boxes. Black-box cells will cause a loss of fault coverage during ATPG. In the check_test output, there are diagnostic messages that describe the sources of violations. Modify your design according to the messages. You should confirm that there is no cell that is treated as a black box before proceeding any further.

105

.....

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

6

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

Building Scan Chains

.................................................. Use the insert_scan command to assemble scan chains. If your design contains non-scan sequential cells that are scannable (without a design rule violation or an attribute that prevents scan replacement), insert_scan replaces them with scan equivalents prior to building scan chains.

Syntax The syntax of the insert_scan command is: insert_scan [-ignore_compile_design_rules]

Option -ignore_compile_design_rules

Minimize the fixing of cell-drive violations.

Command Input Example Here is an example usage of insert_scan: dc_shell> insert_scan -ignore_compile_design_rules

Defining a Test Protocol for ATPG

.................................................. When you are finished with the scan synthesis process, you should recheck the scan design rules, in addition to the quality of synthesis of your functional design. Before you re-run check_test, specify timing parameters to be used during ATPG.

106

Syntax Use these commands and variables to specify timing parameters: test_default_period = test_cycle test_default_delay = input_delay test_default_bidir_delay = bidirectional_input_delay test_default_strobe = output_strobe_time create_test_clock "port_list" -waveform {two_value_rise_fall_edge_list}

Command Input Examples ■

Here is an example for the single-clocked scan design: dc_shell> dc_shell> dc_shell> dc_shell> dc_shell>

test_default_period = 100 test_default_delay = 0 test_default_bidir_delay = 5 test_default_strobe = 40 create_test_clock "CLK" -waveform {50 60} 100 ns

Input Ports 5 ns Bidirectional Ports in Input Mode Output Strobe

40 ns 10 ns

System/Scan Clock

■

50 ns

Here is an example for the dual-clocked scan design: dc_shell> dc_shell> dc_shell> dc_shell> dc_shell> dc_shell>

test_default_period = 100 test_default_delay = 0 test_default_bidir_delay = 5 test_default_strobe = 40 create_test_clock "CLK" -waveform {50 60} create_test_clock "SCAN_ACLK" -waveform {50 60}

107

.....

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

6

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

dc_shell> create_test_clock "SCAN_BCLK" -waveform {70 80} Scan Shift Mode

Scan Capture Mode

100 ns

100 ns

Input Ports 5 ns

5 ns

Bidirectional Ports in Input Mode Output Strobe

40 ns

40 ns 10 ns

System Clock

50 ns 10 ns

Scan Clock A (Master)

50 ns 10 ns

Scan Clock B (Slave)

70 ns

Performing Final Design Rule Checking

.................................................. Run check_test to recheck the design rules. Use the report_test command to generate a scan-related report to confirm the results of design rule checking and scan-related attributes assigned to your design. Chapter 9, "Validating the Scan Structure and ATPG Test Vectors," will explain how to interpret a report from report_test.

Syntax The syntax of the check_test and report_test commands are: check_test > scan_chk_log report_test [report_content] > scan_rep_log

Redirect the output to disk files as shown above. For a description of the report_test arguments, see the Synopsys manual.

Command Input Examples Here is an example usage of check_test and report_test:

108

dc_shell> check_test > scan_chk_log dc_shell> report_test -scan -assertions -atpg_conflict > \ scan_rep_log

Writing a Test Protocol File

.................................................. When you use TetraMAX ATPG, write a STIL procedure file. Enter these commands: dc_shell> test_stil_netlist_format = verilog dc_shell> write_test_protocol -format stil -o CKT.spf

Writing a Netlist

.................................................. Before writing out a gate-level netlist, run the change_names command to make port, cell and net names conform to the naming rules. An example command sequence to write out a Verilog-HDL netlist is shown below: dc_shell> dc_shell> dc_shell> dc_shell> dc_shell>

current_design CKT change_names -hierarchy -rules toshiba change_names -hierarchy -rules toshiba_scan change_names -rules toshiba_ports write -format verilog -hierarchy -o CKT.v_scan

This completes the scan synthesis process using DFT Compiler.

109

.....

Scan Synthesis Methodology Using DFT Compiler 6.4 Step-by-Step Scan Synthesis Procedure

6

6.5

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

Considerations for Scan Synthesis Using DFT Compiler

Separating Functional Design Synthesis and Scan Synthesis

..................................................

Test-ready compile by compile -scan provides a means of implementing a scan methodology with a synthesis-based design flow. However, in some cases, you may want to create a mapped design without scan and build the scan architecture at a later time. The subsections that follow describe a general design flow for mapped designs.

Creating a Mapped Netlist without Scan When you create a gate-level netlist, set dc_shell variables as shown in Figure 6–8 so that all sequential cells are mapped to D-type flip-flops. This is because only D-type flip-flops have scan equivalents in Toshiba’s ASIC cell library. Figure 6–8 Creating a Mapped Netlist without Scan RTL Design

Set synthesis constraints and scan style.

There are no scan equivalents for JK, toggle and negative-edge-triggered flip-flops. Before compile, set dont_use on these flip-flops. For example: set_dont_use tc220c/FT* /* Toggle */ set_dont_use tc220c/FJK* /* JK */ set_dont_use tc220c/FDN* /* Negedge */

compile

Gate-Level Design

All sequential cells are mapped to D-type flip-flops such as FD1. FD1

FD1

It is recommended to run check_test at this stage to confirm the mapping of sequential cells.

110

Performing Scan Insertion Use the insert_scan command to perform scan replacement and assembly at the same time. By default, insert_scan corrects compile design rules violations such as max_fanout and performs mapping optimization. If you want to minimize these corrections, give the -ignore_compile_design_rules option. Figure 6–9 Performing Scan Insertion Identify scan ports and check design rules.

insert_scan -ignore_compile_design_rules

All D-type flip-flops are replaced by their scan equivalents, and scan chains are stitched. FD1SF

FD1SF

Scanned Gate-Level Design Scan-in

Scan-out

Details on the set_scan_signal Command

.................................................. The subsections that follow provide useful tips to keep in mind when using the set_scan_signal command.

Specifying Nonexistent Ports as Scan Test Ports The set_scan_signal command issues an error message if you specify ports that don’t exist in your HDL circuit description. You can avoid such an error by creating ports with the create_port command within DFT Compiler. Figure 6–10 shows this flow.

111

.....

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

6

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

Figure 6–10 Specifying Nonexistent Ports as Scan Test Ports with set_scan_signal create_port SIN -direction in create_port SOUT -direction out

An input port named SIN and an output port named SOUT are added. Scan Chain set_scan_signal test_scan_in -port SIN set_scan_signal test_scan_out -port SOUT

SIN

SOUT

insert_scan

A scan chain is connected to the newly added scan ports (SIN and SOUT).

Specifying Existing Ports without I/O Buffers as Scan Test Ports You can use the set_scan_signal command to share an existing functional port (without an I/O buffer) with a scan-in port; insert_scan will connect the scan input signal directly to the specified input port. You can also use the set_scan_signal command to share an existing functional port (without an I/O buffer) with a scan-out port; in this case, a Scan Shift Enable port is used to multiplex scan-out data and functional data at the specified output port. Figure 6–11 illustrates this process. Figure 6–11 Using Existing Ports without I/O Buffers as Scan Test Ports set_scan_signal test_scan_in -port DIN set_scan_signal test_scan_out -port DOUT

DIN

DOUT

insert_scan Scan Chain A scan chain is connected between DIN and DOUT. If DOUT is connected to internal logic, a mux logic is automatically added.

MUX DIN Scan Shift Enable

112

DOUT

Specifying Existing Ports with I/O Buffers as Scan Test Ports You can also specify existing functional ports with I/O buffers as scan ports with the set_scan_signal command. In this case, insert_scan will connect the scan signals to the core side of the I/O buffers. Figure 6–12 illustrates this process. Note: For the TC240 to TC260 series, DFT Compiler can not automatically recognize I/O buffers. For a workaround, see the section "Connecting Scan Signals to I/O Buffers in the TC240 to TC260 Technologies" on page 114. Figure 6–12 Using Existing Ports with I/O Buffers as Scan Test Ports set_scan_signal test_scan_in -port DIN set_scan_signal test_scan_out -port DOUT

DIN

DOUT

insert_scan Scan Chain A scan chain is connected to the core side of the I/O buffers at DIN and DOUT. If DOUT is connected to internal logic, a mux logic is automatically added.

MUX DIN

DOUT

Scan Shift Enable

Sharing Functional Input Ports with Scan Clock Ports By default, insert_scan connects scan signals to the core side of the specified ports. You can use the -hookup option of the set_scan_signal command to override this behavior and instruct insert_scan to connect scan signals to specified pins. Figure 6–13 shows an example usage of the -hookup option. Figure 6–13 Sharing a Functional Input Port with a Scan Clock Using the -hookup Option u0 set_scan_signal test_scan_clock_a \ -port DIN -hookup u0/Z

DIN Scan Shift Enable

insert_scan u0 Scan Clock A is connected to the Z output of cell u0. The scan_clock_a attribute is assigned to the DIN port.

A

Scan Chain

DIN Scan Shift Enable

113

.....

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

6

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

Connecting Scan Signals to I/O Buffers in the TC240 to TC260 Technologies DFT Compiler can not automatically recognize I/O buffers for the TC240 to TC260 series. If you want a scan chain connected to ports that already have I/O buffers, use the -hookup option of the set_scan_signal command. Identify an instance of an input buffer as instance_name/IOMAIN. Give the option -sense inverted for an inverting I/O buffer. See Figure 6–14. Figure 6–14 Connecting to I/O Buffers in the TC240 to TC260 Technologies set_scan_signal test_scan_in -port DIN \ -hookup u1/IOMAIN/Z set_scan_signal test_scan_out -port DOUT \ -hookup u2/A

DIN

u2

u1

DOUT

insert_scan Scan Chain The scan-in signal is connected to pin u1/Z, and the scan-out signal is connected to pin u2/A. If u2/A is connected to internal logic, a mux logic is automatically added.

DIN

u1

MUX u2

DOUT

Scan Shift Enable

Explicitly Assigning Scan Test Ports to Scan Chains Unless specified, insert_scan assigns scan-in and scan-out ports to scan chains in the default order. To allocate scan flip-flops to particular scan chains, use the set_scan_path command. Then, you can use the -chain option of set_scan_signal to explicitly assign scan-in and scan-out ports to particular scan chains, using scan chain names you assigned them with set_scan_path. Figure 6–15 shows how to get the exact scan architecture you require. Figure 6–15 Explicitly Assigning Scan Ports to Scan Chains

set_scan_configuration -chain_count 2 ... set_scan_path IN1 set_scan_path IN2 set_scan_signal test_scan_in -port SIN1 -chain IN1 set_scan_signal test_scan_in -port SIN2 -chain IN2 set_scan_signal test_scan_out -port SOUT1 -chain IN1 set_scan_signal test_scan_out -port SOUT2 -chain IN2

114

Difference between set_scan_signal and set_signal_type The difference between set_scan_signal and set_signal_type is as follows: ■

set_scan_signal

The specified ports are assigned signal type attributes (such as test_scan_enable) by the insert_scan command. insert_scan determines signal types from these attributes when assembling scan chains.

■

set_signal_type

The specified ports are immediately assigned signal type attributes by the set_signal_type command itself.

Use set_scan_signal to identify design ports that you want connected during scan assembly. Use set_signal_type to identify scan ports that are connected to the existing scan structure.

Correcting Design Rule Violations Reported by check_test

..................................................

When you run check_test in DFT Compiler, warning and error messages may sometimes be generated due to software limitations, etc. even when your design has no problem. The following describe common sources of the problem. ■

Using a bidirectional port as a clock DFT Compiler does not allow bidirectional ports to be used as scan or system clock ports. The check_test command issues a warning message if it finds a bidirectional port used as a clock. If you want to use a bidirectional port as a clock, you need to verify the integrity of the scan chain by means of another tool.

■

Using a bidirectional port on a submodule Signals connected to a bidirectional port of a module must be completely tristatable. Otherwise, they are assumed to have an unknown (X) value. See the design in Figure 6–16. When you run check_test on this design, the scan-shift signal is assumed to have an unknown (X) value and reported as a warning condition.

115

.....

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

6

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

Figure 6–16 Functionally Output Port Declared as inout Functionally, this port is an output, but is declared as inout in HDL description.

FD1E

FD1E Q

TI

A warning message is generated because check_test assumes that it is not scan-controllable. Warning: Cell u07(FD1E) is not scan controllable.(TEST-302) Information: Because it clocks in an unknown value from pin TI.(TEST-512) Information: Pin TI of cell u07(FD1E) is unknown due to a preciously reported violation.(test-547) Information: As a result, 1 other cell is not scan controllable.(TEST-501) ... ************************************************ Sequential Cell Summary 4 out of 4 sequential cells have violations ************************************************ SEQUENTIAL CELLS WITH VIOLATIONS * 4 cells have scan shift violations * 2 cells are not scan controllable * 2 cells are not scan observable * 1 cell is an identified cause of other reported violations

■

Unknown cell violations DFT Compiler models cells that can not be found in the library as black-box cells. If not all cell references can be resolved using technology libraries or designs in search_path, the link command generates warning messages as shown below: Warning: Unable to resolve reference ’EAS1A0A00016A’ in ’ram40x4k5.db:ram16x1k5’. (LINK-5) Warning: Unable to resolve reference ’EAS1A0B00032A’ in ’ram40x2k4.db:ram32x2k4’. (LINK-5)

Both inputs and outputs of a black-box cell are assumed to have an unknown (X) value. See the design in Figure 6–17 in which the RAM is treated as a black box. Consequently, the system clock is assumed to have an X value, causing design rules violations.

116

Figure 6–17 Unknown Cell Violation EAS1A0A00016A (Treated as a black box) A black-box cell is directly connected to a clock. This clock is assumed to have an X value, causing clock rule violations.

RAM

FD1

Clock FD1 All flip-flops driven by this clock cause violations.

************************************************ Sequential Cell Summary 4 out of 4 sequential cells have violations ************************************************ SEQUENTIAL CELLS WITH VIOLATIONS * 4 cells are black boxes * 4 cells are identified causes of other reported violations

DFT Compiler assumes that the FD1 cells are not scan-controllable and excludes them from scan replacement. As demonstrated by this example, the effects of unknown cells are often reported as other kinds of violations. Occasionally, it takes a long time to identify the true source of the violation. To prevent such a situation, pay great attention to the messages from link to ensure that no cells will lead to unknown cells during check_test. In cases where your design has unresolved references, you can avoid the problem by creating a dummy module as shown below in Figure 6–18. Figure 6–18 Dummy Module for the RAM

module EAS1A00016A (O0,O1,O2,O3,O4,O5,O6,O7,O8,O9,O10,O11,O12,O13, O14,O15,CLK,WEN,REN,OEN,A0,A1,S2,A3,A4,A5,A6,A7,A8,A9,I0,I1,I2, I3,I4,I5,I6,I7,I8,I9,I10,I11,I12,I13,I14,I15); output O0,O1,O2,O3,O4,O5,O6,O7,O8,O9,O10,O11,O12,O13,O14,O15; input CLK,WEN,REN,OEN,A0,A1,S2,A3,A4,A5,A6,A7,A8,A9,I0,I1,I2,I3,I4, I5,I6,I7,I8,I9,I10,I11,I12,I13,I14,I15; endmodule

117

.....

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

6

Scan Synthesis Methodology Using DFT Compiler 6.5 Considerations for Scan Synthesis Using DFT Compiler

Although the RAM is still a black box, check_test does not assume an X value on it because it is explicitly declared as an input port. Prior to writing out a netlist, be sure to remove this dummy module by using the remove_design command.

118

Chapter 7

STIL Procedure File (SPF)

.....

.....................................

T

his chapter provides guidelines for creating and editing STIL procedure files. The material is organized into the following sections:

☞ Creating an SPF ☞ SPF Organization for Single-Clocked Scan ☞ SPF Organization for Dual-Clocked Scan ☞ Controlling Bidirectional Ports ☞ SPF Description for Scan-Out Ports with Bidirectional Buffers ☞ Pin-Sharing ☞ Editing an SPF Generated by DFT Compiler ☞ Editing an SPF Generated by TetraMAX ☞ SPF for a Design with JTAG Logic

119

7

7.1

STIL Procedure File (SPF) 7.1 Creating an SPF

Creating an SPF

A STIL procedure file (SPF) describes the scan structure inserted in your design and dictates the capture and scan-shift operations of scan chains. An SPF is required by TetraMAX. Basically, an SPF uses a subset of STIL syntax specified by IEEE Std 1450-1999, IEEE Standard Test Interface Language (STIL) for Digital Test Vectors. An SPF also capitalizes on the IEEE P1450.1 extensions to STIL. You can create an SPF in three ways, using DFT Compiler, SPFGen or TetraMAX: ■

Generate an SPF within a DFT Compiler session when you have performed scan synthesis at the chip level and run check_test.

■

Use SPFGen when you have not generated an SPF with DFT Compiler.

■

When you want to customize ATPG procedures, etc, modify an SPF manually generated by DFT Compiler, SPFGen or TetraMAX.

Using DFT Compiler

.................................................. Once scan synthesis is finished, DFT Compiler allows you to write out an SPF, as described in Chapter 6. You can save time and avoid typing errors by using it. In some cases, however, you might have to make some manual edits to an SPF.

Using SPFGen

.................................................. You can use SPFGen to create an SPF file and a command file for TetraMAX automatically. Before running SPFGen, a setup file must be created. To run SPFGen, enter the following command at a UNIX shell prompt. %> spfgen

For a detailed description of SPFGen, see 10.2, "SPFGen," on page 229.

120

Using TetraMAX

.................................................. TetraMAX also allows you to write out a template SPF. To create an SPF, enter the following command within TetraMAX. write drc_file filename

You can run this command in DRC and TEST command modes. An initial SPF generated in DRC mode contains the minimum information needed by TetraMAX ATPG. An SPF is used by test design rules checking. Edit it to define your scan structure, and required STIL procedures and port timing. Figure 7–1 shows the flow for creating an SPF. Figure 7–1 Flow for Creating an SPF in TetraMAX Define clocks. Define primary pin constraints. DRC Mode write drc_file

SPF Template

Edit the SPF.

DRC TEST Mode

Error

OK write drc_file

SPF

121

.....

STIL Procedure File (SPF) 7.1 Creating an SPF

7

7.2

STIL Procedure File (SPF) 7.2 SPF Organization for Single-Clocked Scan

SPF Organization for Single-Clocked Scan

Sample SPF

.................................................. Figure 7–2 shows a sample SPF with minimum information TetraMAX needs for single-clocked scan design. This example assumes that all primary bidirectional ports can be forced to input mode during scan-shifting. If any bidirectional ports are not directly controllable, see the section 7.4, "Controlling Bidirectional Ports," on page 134.

Figure 7–2 Sample SPF for Single-Clocked Scan Design STIL 1.00; ScanStructures { ScanChain "IN0" { ScanIn "SDI0"; ScanOut "SDO0"; } //Scan chains are named IN0, IN1 and IN2. ScanChain "IN1" { ScanIn "SDI1"; ScanOut "SDO1"; } //Scan-in ports are SDI0, SDI1 and SDI2. ScanChain "IN2" { ScanIn "SDI2"; ScanOut "SDO2"; } //Scan-out ports are SDO0, SDO1 and SDO2. } Procedures { load_unload { V { "CLK"=0; //System clock is set to off state. "RST"=1 //Async. reset is set to off state. "SEN"=1; //Scan Shift Enable is driven high to enable scan chains. "BIDI_DISABLE"=1 //Bidirectional 3-state enable is set to off state } //(input mode). Shift V { _si=\r3 #; _so=\r3 #;

"CLK"=P; "RST"=1 "SEN0"=1;

//Specify the number of scan-in and scan-out ports //in the form \r. _si and _so are naming //conventions expected by TetraMAX. Enter a space //between number and #. //Shared system/scan clock port is pulsed (P). //Async. reset is set to off state. //Scan Shift Enable port is set to on state.

} } } } MacroDefs { test_setup { V { "CLK=0; "RST"= 1 "SEN0"=0; "BIDI_DISABLE"=1; } } }

122

//Define an initialization sequence. //System clock port is set to off state. //Async. reset is set to off state. //Scan Shift Enable port is set to off state. //Bidirectional 3-state enable is set to off state //(input mode).

ScanStructures Construct

.................................................. The ScanStructures construct defines the scan chains in your design and their scan-in and scan-out ports. In the example in Figure 7–2, three scan chains are named IN0, IN1 and IN2. The syntax of the ScanStructures construct is: ScanStructures { ScanChain "chain_name" { ScanIn "scan-in_port"; ScanOut "scan-out_port"; } ScanChain "chain_name" { ScanIn "scan-in_port"; ScanOut "scan-out_port"; } ScanChain "chain_name" { ScanIn "scan-in_port"; ScanOut "scan-out_port"; } //Define all scan chains. }

Although the SPF language specification also provides the ScanLength and ScanInversion keywords, TetraMAX ignores them when reading in an SPF. However, TetraMAX correctly supplies ScanLength and ScanInversion in an SPF and an STIL test protocol file it generates.

Procedures Construct

.................................................. The Procedures construct defines the scan-shift and system capture operations for your design. The general structure of the Procedures construct is shown below. Only the load_unload procedure is mandatory; the other procedures are written only when needed.

123

.....

STIL Procedure File (SPF) 7.2 SPF Organization for Single-Clocked Scan

7

STIL Procedure File (SPF) 7.2 SPF Organization for Single-Clocked Scan

Procedures { load_unload { V { ... } Shift { V { ... } }

//Vector for placing scan chains in shift mode //Specify how to shift scan chains. //Define how to shift one bit through scan chains. The //Shift procedure is applied repeatedly to shift as many //bits as are in the longest scan chain. //Vector for placing scan chains in capture mode

V { ... } } shadow_observe { //Required only when your design has shadow registers V { ... } //Set up a path from shadow registers back to scan registers } capture_ { //Define a capture clock procedure. F { ... } //Primary inputs fixed during capture cycles V { ... } //Define a capture operation. } capture_ { //Define an async set/reset procedure. F { ... } //Primary inputs fixed during async set/reset V { ... } //Define a set/reset operation. } capture { //Define an operation to measure test response only at POs. F { ... } //Omit this procedure if you want a capture clock pulsed V { ... } //in every test pattern. } }

The Procedures construct can consist of three procedures: ■

load_unload procedure (always required)

The load_unload procedure defines: 1) how the scan chains in your design can be placed into a shiftable state (scan shift mode), 2) how they can be shifted one bit, and 3) how they are placed back in a capture state (scan capture mode). Usually, you can omit a vector to place the scan chains in a capture state. The Shift procedure is placed within the definition of the load_unload procedure. ■

shadow_observe procedure (optional)

A shadow register is not in the scan chain, but is loaded when its master register in the scan chain is loaded. The shadow_observe procedure is used when a design has shadow registers and the shadow register’s outputs are observable at the scan cells to which they are shadows. The shadow_observe procedure defines how to set up paths from shadow registers back to scan cells. ■

capture procedure (optional)

The capture procedure is used when you want to use non-default capture timing or sequence. You can run ATPG with no capture definition in an SPF. The default capture procedure usually consists of three cycles for applying inputs, observing outputs and pulsing the system clock. You can optionally define the capture procedure if you want

124

to merge the capture cycles into a single cycle. For a detailed description of the capture procedure, see 8.4, "ATPG Test Cycles," on page 184. By default, latches and flip-flops whose set and reset lines are not off when all clocks are at their off state are treated as unstable cells. Because they are unstable, their output values are unknown and they can not be used during test pattern generation. One way to make these cells stable is to make their asynchronous set/reset input signals controllable from external I/O pins and declare them as clocks using a capture block, as shown above.

MacroDefs Construct

.................................................. An optional test_setup macro is written within the MacroDefs construct. The test_setup macro defines an initialization sequence to put the device in test mode. Figure 7–3 shows an example of the MacroDefs construct. Figure 7–3 MacroDefs Construct MacroDefs { test_setup { V { TEST_ENABLE=1; RST=0; } V { TEST_ENABLE=1; RST=1; } } }

Test Sequence of the Single-Clocked Scan Design

..................................................

The test sequence TetraMAX generates for the single-clocked scan design is shown below. Figure 7–4 Test Sequence of the Single-Clocked Scan Design test_setup V

V

...

shadow_ capture_xxx observe load_unload

load_unload Shift V

V

V

.......

V

...

V F

V

... V: Vector F: Fixed

As shown in Figure 7–4, the following vectors comprise a scan test pattern: 1. Initialization (test_setup) 2. Scan-shift operation (load_unload)

125

.....

STIL Procedure File (SPF) 7.2 SPF Organization for Single-Clocked Scan

7

STIL Procedure File (SPF) 7.2 SPF Organization for Single-Clocked Scan

3. Capture operation (capture_) In capture mode, the fault effects are propagated and latched into scan flip-flops. 4. Shadow observe (shadow_observe) 5. Repetitions of 2 to 4 TetraMAX can usually create vectors where the data is "unloaded" through the scan-out port as the data is "loaded" from the scan-in port.

126

7.3

SPF Organization for Dual-Clocked Scan

This section describes how to create an SPF for dual-clocked scan design.

Sample SPF

.................................................. Figure 7–5 shows a sample SPF with minimum information TetraMAX needs for dual-clocked scan design. This example assumes that all primary bidirectional ports can be forced to input mode during scan-shifting. If any bidirectional ports are not directly controllable, see 7.4, "Controlling Bidirectional Ports," on page 134.

Figure 7–5 Sample SPF for Dual-Clocked Scan Design STIL 1.00; ScanStructures { ScanChain "IN0" { ScanIn "SDI0"; ScanOut "SDO0"; } //Define a scan chain IN0. } SignalGroups { //This construct can be output by the //TetraMAX write drc_file command. "_default_In_Timing_" = ’"CLK" + "IN0" + "IN1" + "SDI0" +"ACK0" + "BCK0"’; "_default_Out_Timing_" = ’"SDO0" + "OUT0" + "OUT1"’; "_default_SysClk_Timing_" = ’"CLK"’; "_default_Reset_Timing_" = ’"RST"’; "_default_ScanMasterClk_Timing_" = ’"ACK0"’; "_default_ScanSlaveClk_Timing_" = ’"BCK0"’; } Timing { //This construct can be output by the WaveformTable "_default_WFT_" { //TetraMAX write_drc_file command. Period ’100ns’; //Tester cycle period Waveforms { "_default_In_Timing_" { 0 { ’0ns’ D; } } "_default_In_Timing_" { 1 { ’0ns’ U; } } "_default_In_Timing_" { Z { ’0ns’ Z; } } "_default_Out_Timing_" { X { ’0ns’ X; } } "_default_Out_Timing_" { H { ’0ns’ X; ’40ns’ H; } } //Place strobe before "_default_Out_Timing_" { T { ’0ns’ X; ’40ns’ T; } } active clock edge. "_default_Out_Timing_" { L { ’0ns’ X; ’40ns’ L; } } "_default_SysClk_Timing_" { P { ’0ns’ D; ’50ns’ U; ’80ns’ D; } } "_default_Reset_Timing_" { P { ’0ns’ U; ’50ns’ D; ’80ns’ U; } } "_default_ScanMasterClk_Timing_" { P { ’0ns’ D; ’10ns’ U; ’30ns’ D; } } "_default_ScanSlaveClk_Timing_" { P { ’0ns’ D; ’60ns’ U; ’80ns’ D; } } } } }

127

.....

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

7

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

Procedures { load_unload { W "_default_WFT_"; V { "CLK"=0; "RST"=1; "ACK0"=0; "BCK0"=0; "BIDI_DISABLE"=1;

//System clock is set to off state. //Async reset is set to off state. //Scan Clock A is set to off state. //Scan Clock B is set to off state. //Bidirectional 3-state enable is set to off state //(input mode).

} Shift { V { _si=\r1 #; _so=\r1 #;

"CLK"=0; "RST"=1; "ACK0"=P; "BCK0"=P; } } } master_observe { V { "CLK"=0; "RST=1; "ACLK0"=0; "BCLK0"=P; } } } MacroDefs { test_setup { V { "CLK"=0; "RST"=1; "ACK0"=0; "BCK0"=0; "BIDI_DISABLE"=1;

//Specify the number of scan-in and scan-out ports //in the form \r. _si and _so are naming //conventions expected by TetraMAX. Enter a space //between number and #. //System clock is set to off state. //Async reset is set to off state. //Scan Clock A is pulsed (P). //Scan Clock B is pulsed (P).

//Propagate the captured data from master latches //to slave latches before scan-out.

//Only Scan Clock B is pulsed (P).

//Define an initialization sequence. //System clock is set to off state. //Async reset is set to off state. //Scan Clock A is set to off state. //Scan Clock B is set to off state. //Bidirectional 3-state enable is set to off state //(input mode).

}

} }

An SPF for the dual-clocked scan design has these additional constructs and procedure, as compared to an SPF for the single-clocked scan design:

128

■

SignalGroups construct

■

Timing construct

■

master_observe procedure

ScanStructures Construct

.................................................. The ScanStructures construct defines the scan chains in your design and their scan-in and scan-out ports. In the example in Figure 7–5, the scan chain is named IN0. The syntax of the ScanStructures construct is: ScanStructures { ScanChain "chain_name" { ScanIn "scan-in_port"; ScanOut "scan-out_port"; } ScanChain "chain_name" { ScanIn "scan-in_port"; ScanOut "scan-out_port"; } ScanChain "chain_name" { ScanIn "scan-in_port"; ScanOut "scan-out_port"; } //Define all scan chains. }

Although the SPF language specification also provides the ScanLength and ScanInversion keywords, TetraMAX ignores them when reading in an SPF. However, TetraMAX correctly supplies ScanLength and ScanInversion in an SPF and an STIL test protocol file it generates.

SignalGroups Construct

.................................................. Define signal groups so that timing for all inputs and outputs can be defined in just a few lines. The syntax for the SignalGroups construct is shown below. The write drc_file command can generate this construct automatically; edit it as described in 7.8, "Editing an SPF Generated by TetraMAX," on page 142. signalGroups { "input_port_label" = ’"input_port" + "bidirect_port" + "clock_port" + "scan-in_port" + "ACLK_port" + "BCLK_port"’ ; "output_port_label" = ’"output_port" + "bidirect_port" + "scan-out_port"’ ; "clock_port_label" = ’"clock_port"’ ; "ACLK_port_label" = ’"ACLK_port"’ ; "BCLK_port_label" = ’"BCLK_port"’ ; }

Timing Construct

.................................................. The Timing construct contains a waveform table that defines the timing to be used at all input and output ports. The write drc_file command can generate this construct automatically; edit it as needed. Observe the following guidelines when writing the Timing construct:

129

.....

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

7

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

■

Due to the TetraMAX constraint, place the output strobe before any system clock events in the cycle.

■

Scan Clock A must not overlap with Scan Clock B; the active region of Scan Clock A must precede the active region of Scan Clock B.

Figure 7–6 gives the Timing construct in the SPF shown previously. Figure 7–7 shows a waveform representation of the Timing construct in Figure 7–6. Figure 7–6 Timing Construct Timing { WaveformTable "_default_WFT_" { Period ’100ns’; Waveforms { "_default_In_Timing_" { 0 { ’0ns’ "_default_In_Timing_" { 1 { ’0ns’ "_default_In_Timing_" { Z { ’0ns’ "_default_Out_Timing_" { X { ’0ns’ "_default_Out_Timing_" { H { ’0ns’ "_default_Out_Timing_" { T { ’0ns’ "_default_Out_Timing_" { L { ’0ns’ "_default_SysClk_Timing_" { "_default_Reset_Timing_" { "_default_ScanMasterClk_Timing_" { "_default_ScanSlaveClk_Timing_" { } } }

//Identify the timing definition. //Tester cycle period D; } } U; } } Z; } } X; } } X; ’40ns’ X; ’40ns’ X; ’40ns’ P { ’0ns’ P { ’0ns’ P { ’0ns’ P { ’0ns’

H; T; L; D; U; D; D;

} } //Place strobe before } } active clock edge. } } ’50ns’ U; ’80ns’ D; } } ’50ns’ D; ’80ns’ U; } } ’10ns’ U; ’30ns’ D; } } ’60ns’ U; ’80ns’ D; } }

Figure 7–7 Waveform Representation of the Above Timing Construct 100 ns _default_In_Timing_ _default_SysClk_Timing_ 50

80

_default_Reset_Timing_ _default_ScanMasterClk_Timing_ 10

30

_default_ScanSlaveClk_Timing_ 60 _default_Out_Timing_

130

40

80

Procedures Construct

.................................................. The Procedures construct defines the scan-shift and system capture operations for your design. The general structure of the Procedures construct is shown below. Note the presence of the master_observe procedure. The other procedures are basically identical to those for the single-clocked scan design. Procedures { load_unload { V { ... } Shift { V { ... } } V { ... } } master_observe { V { ... }

//Vector for placing scan chains in shift mode //Specify how to shift scan chains. //Define how to shift one bit through scan chains. The //Shift procedure is applied repeatedly to shift as many //bits as are in the longest scan chain. //Vector for placing scan chains in capture mode //Required only for dual-clocked scan design //Vector for propagating the captured data from master latches //to slave latches //Required only when your design has shadow registers //Set up a path from shadow registers back to scan registers

shadow_observe { V { ... } } capture_ { //Define a capture clock procedure. F { ... } //Primary inputs fixed during capture cycles V { ... } //Define a capture operation. } capture_ { //Define an async set/reset procedure. F { ... } //Primary inputs fixed during async set/reset V { ... } //Define a set/reset operation. } capture { //Define an operation to measure test response only at POs. F { ... } //Omit this procedure if you want a capture clock pulsed V { ... } //in every test pattern. } }

The Procedure construct can consist of four procedures: ■

load_unload procedure (always required)

The load_unload procedure defines: 1) how the scan chains in your design can be placed into a shiftable state (scan shift mode), 2) how they can be shifted one bit, and 3) how they are placed back in a capture state (scan capture mode). The Shift procedure is placed within the definition of the load_unload procedure. Usually, you can omit a vector to place the scan chains in a capture state. ■

master_observe procedure (always required for dual-clocked scan)

The master_observe procedure propagates the captured data from master latches to slave latches prior to shifting scan test response through the scan chain. In the

131

.....

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

7

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

master_observe cycle, only Scan Clock B is pulsed. Without the master_observe

procedure, the data captured into master latches would be overwritten and lost. For a detailed description of the master_observe behavior, see 8.4, "ATPG Test Cycles," on page 184. ■

shadow_observe procedure (optional)

A shadow register is not in the scan chain, but is loaded when its master register in the scan chain is loaded. The shadow_observe procedure is used when a design has shadow registers and the shadow register’s outputs are observable at the scan cells to which they are shadows. The shadow_observe procedure defines how to set up paths from shadow registers back to scan cells. ■

capture procedure (optional)

The capture procedure is used when you want to use non-default capture timing or sequence. You can run ATPG with no capture definition in an SPF. The default capture procedure usually consists of three cycles for applying inputs, observing outputs and pulsing the system clock. You can optionally define the capture procedure if you want to merge the capture cycles into a single cycle. For a detailed description of the capture procedure, see 8.4, "ATPG Test Cycles," on page 184. By default, latches and flip-flops whose set and reset lines are not off when all clocks are at their off state are treated as unstable cells. Because they are unstable, their output values are unknown and they can not be used during test pattern generation. One way to make these cells stable is to make their asynchronous set/reset input signals controllable from external I/O pins and declare them as clocks using a capture block, as shown above.

MacroDefs Construct

.................................................. An optional test_setup macro is written within the MacroDefs construct. The test_setup macro defines an initialization sequence to put the device in test mode. Figure 7–8 shows an example of the MacroDefs construct. Figure 7–8 MacroDefs Construct MacroDefs { test_setup { V { TEST_ENABLE=1; RST=0; } V { TEST_ENABLE=1; RST=1; } } }

132

Test Sequence of the Dual-Clocked Scan Design

..................................................

The test sequence TetraMAX generates for the dual-clocked scan design is shown below. Figure 7–9 Test Sequence of the Dual-Clocked Scan Design test_setup V

V

...

shadow_ master_ capture_xxx observe observe load_unload

load_unload Shift V

V

V

.......

V

...

V F

V

...

V V: Vector F: Fixed

As shown in Figure 7–9, the following vectors comprise a scan test pattern: 1. Initialization (test_setup) 2. Scan-shift operation (load_unload) 3. Capture operation (capture_) In capture mode, the fault effects are propagated and latched into scan flip-flops. 4. Shadow observe (shadow_observe) 5. Master observe (master_observe) Prior to a scan-shift operation (load_unload), the data in the master latch is transferred to the slave latch. 6. Repetitions of 2 to 5 TetraMAX can usually create vectors where the data is "unloaded" through the scan-out port as the data is "loaded" from the scan-in port.

133

.....

STIL Procedure File (SPF) 7.3 SPF Organization for Dual-Clocked Scan

7

7.4

STIL Procedure File (SPF) 7.4 Controlling Bidirectional Ports

Controlling Bidirectional Ports

Bidirectional I/O ports must be forced to input mode during scan shift, regardless of the scan style. Unless your design conforms to this rule, modify the SPF as shown in Figure 7–10. After a TSTL2 pattern file has been generated, you must not add the PATTYPE statement to its DECLARE block; otherwise, bidirectional pin conflicts might occur during scan shift. Figure 7–10 Placing a Z Value on Bidirectional Ports STIL 1.00; ... Omitted ... SignalGroups { "bidi_ports" = ’"D[0]"+"D[1]"+"D[2]"+"D[3]"’; //Create a bidirectional port group. } Procedures { load_unload { V { ... Omitted ... "bidi_ports" = \r4 Z; //Set bidi_ports to a Z state. } Shift { ... Omitted ... } }

} MacroDefs { test_setup { V { ... Omitted ... "bidi_ports" = \r4 Z; } } }

134

//Set bidi_ports to a Z state.

7.5

SPF Description for Scan-Out Ports with Bidirectional Buffers

If a scan-out port uses a bidirectional pin, place a Z value on that bidirectional port prior to scan-chain shifting. Figure 7–11 shows an SPF with a bidirectional scan-out port. An addition has been made to the load_unload procedure. Without this addition, a DRC violation of the S1 class will occur. Figure 7–11 Scan-Out Pin with a Bidirectional I/O Buffer ... Omitted ... Procedure { load_unload { V{ _so = \r8 Z; // "clk"= 0; // "rst"= 1; // "sen"=1; // } shift { V{ _si=\r8 #; _so=\r8 #; "clk" = P; "rst" =1; } } } }

Assign Z states to scan-out pin. Set clock to off state. Set async reset to off state. Set Scan Shift Enable to on state.

// Pulse the clock. // Set async reset to off state.

... Omitted ...

The following shows an example of the messages generated in the presence of an S1 violation: -------------------------------------------------------------------Begin scan chain operation checking... Error: Chain c0 blocked at BUS gate u_SDO0 (3574) after tracing 0 cells. (S1-1) Error: Design rules checking failed: cannot exit DRC command mode. (M100)

135

.....

STIL Procedure File (SPF) 7.5 SPF Description for Scan-Out Ports with Bidirectional Buffers

7

7.6

STIL Procedure File (SPF) 7.6 Pin-Sharing

Pin-Sharing

As explained in 2.2, "I/O Pin Requirements for Scan Methodologies," on page 27, some scan test ports can be shared with functional ports. The subsections that follow contain some tips for working with an SPF when scan test ports are shared with functional ports.

Sharing a Functional Input Port with a Scan-in Port

..................................................

A scan-in port can be shared with a functional input port. Figure 7–12 shows a design in which a functional input port called D0 is also used as a scan-in port. In the SPF in Figure 7–13, the ScanChain statement specifies the name of this port. Figure 7–12 Functional Input Port Shared with a Scan-in Port padi_0 D0

Z

A PI IBUFU

SOUT

Scan Chain

Figure 7–13 ScanChain Statement Identifying the Shared Scan-in Port STIL 1.00; ScanStructures { ScanChain "C0" { ScanIn "D0"; ScanOut "SOUT"; } } ... Omitted ... Procedures { load_unload { Shift { V { _si=#; _so=#; ... Omitted ... } } } } MacroDefs { ... Omitted ... }

136

//Shared scan-in port

//No change needed

Sharing a Functional Output Port with a Scan-out Port

..................................................

A scan-out port can be shared with a functional output port. When using a functional output port as a scan-out port, a Scan Shift Enable port is required to multiplex scan-out data and functional data at that output port, as shown in Figure 7–14. Figure 7–15 highlights the portions in an SPF related to the scan-out and Scan Shift Enable ports. Figure 7–14 Functional Output Port Shared with a Scan-out Port CMX2X1

padi_0 D0

Z

A

pado_9 A Z

A0 A1

PI

OUT99

S Scan Chain

padi_sen SCAN_EN

A

Z

PI

Figure 7–15 The Shared Scan-out Port and the Scan Shift Enable Port STIL 1.00; ScanStructures { ScanChain "IN0" { ScanIn "D0"; ScanOut "OUT99"; } //Shared scan-out port } ... Omitted ... Procedures { load_unload { W "_default_WFT_"; ... Omitted ... Shift { V { _si=\r1 #; _so=\r1 #; "CLK"=0; "ACK0"=P; "BCK0"=P; "SCAN_EN"=1; } } } master_observe { V { "CLK"=0 "ACLK0"=0; "BCLK0"=P; "SCAN_EN"=1; } }

//Scan Shift Enable port is set to on state.

//Scan Shift Enable port is set to on state.

137

.....

STIL Procedure File (SPF) 7.6 Pin-Sharing

7

STIL Procedure File (SPF) 7.6 Pin-Sharing

} MacroDefs { test_setup { V { "CLK"=0; "ACK0"=0; "BCK0"=0; "BIDI_DISABLE"=1; "SCAN_EN"=0; }

//Scan Shift Enable port is set to off state.

} }

Sharing a Functional Input Port with a Scan Shift Enable Port

..................................................

A Scan Shift Enable port can be shared with a functional input port by using a Scan Test Enable signal. In Figure 7–16, D0 is used as a Scan Shift Enable port. Figure 7–17 highlights the portions in an SPF related to the Scan Shift Enable and Scan Test Enable ports. Figure 7–16 Functional Input Port Shared with a Scan Shift Enable Port padi_0 D0

Z

A PI IBUFU

Scan Chain

SIN

SOUT padi_1

TEST_EN

Z

A PI IBUFU

Figure 7–17 Scan Shift Enable and Scan Test Enable Ports STIL 1.00; ... Omitted ... Procedures { load_unload { W "_default_WFT_"; ... Omitted ... Shift { V { _si=#; _so=#; "CLK"=P; "D0"=1; "TEST_EN"=1; }

138

//Scan Shift Enable port is set to on state. //Scan Test Enable port is set to on state.

} } } MacroDefs { ... Omitted ... }

Sharing Functional Input Ports with Scan Clock Ports

..................................................

The dual-clocked scan style allows scan clock ports (A and B) to be shared with functional input ports. To do so, a Scan Shift Enable port is required so that the scan clock ports can be set to their off states to disable scan-shifting during normal operation mode. Figure 7–18 shows a design in which functional input ports D1 and D2 are used as scan clock ports. Figure 7–19 shows an SPF example. Figure 7–18 Scan Clock Ports Shared with Functional Input Ports padi_0 D1

Z

A PI

ack_ctl padi_1 D2

ACK Z

A PI

bck_ctl padi_sen SCAN_EN

A

Z

BCK

PI Scan Chain

Figure 7–19 Scan Clock Ports Shared with Functional Input Ports STIL 1.00; ... Omitted ... Procedures { load_unload { W "_default_WFT_"; ... Omitted ...

139

.....

STIL Procedure File (SPF) 7.6 Pin-Sharing

7

STIL Procedure File (SPF) 7.6 Pin-Sharing

Shift { V { _si=\r3 #; _so=\r3 #; "CLK"=0; "D1"=P; "D2"=P; "SCAN_EN"=1; } } } master_observe { V { "CLK"=0 "D1"=0; "D2"=P; "SCAN_EN"=1; } } capture_clk { F { "SCAN_EN"=0; "D1"=0; "D2"=0; }

//Shared Scan Clock A port //Shared Scan Clock B port //Scan Shift Enable port is set to on state.

//Scan Shift Enable port is set to on state.

//Scan clocks are set to off state //during a system capture procedure. V { "_pi"=\r5 #; "_po"=\r5 #; "CLK"=P; }

} } MacroDefs { test_setup { V { "CLK"=0; "D1"=0; "D2"=0; "BIDI_DISABLE"=1; "SCAN_EN"=0;

//Scan Shift Enable port is set to off state //during normal operation mode.

}

} }

The Scan Shift Enable port is held at logic 1 during the load_unload and master_observe procedures, so the scan clocks become active during scan-shifting. The Scan Shift Enable port and the scan clock ports are held at logic 0 during the capture procedure, so the scan flip-flops function as standard flip-flops. Consequently, fault coverage will suffer in combinational logic connected to the D1 and D2 inputs. Special care must be taken when you determine which ports to use for the Scan Clock signals. Because the clocks are held at a fixed value during the capture operation, design rules checking generates the warning message shown below. Warning: Rule C15 (scan cell port unable to capture) was violated N times.

140

7.7

Editing an SPF Generated by DFT Compiler

You can use an SPF generated by DFT Compiler with TetraMAX, with one minor modification. DFT Compiler assigns lowercase names to scan chains, like c0. However, Toshiba’s TSTL2 requires scan chain names to be all uppercase. Figure 7–20 shows a fragment of an SPF after modification. Figure 7–20 Scan Chain Name in an SPF ScanStructures { Scanchain "C0" { ScanLength 4; ScanIn "DIA0"; ScanOut "DO0"; } }

//Change scan chain name to uppercase.

141

.....

STIL Procedure File (SPF) 7.7 Editing an SPF Generated by DFT Compiler

7

7.8

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

Editing an SPF Generated by TetraMAX

This section describes how to modify an SPF generated by TetraMAX before running ATPG.

SPF for Single-Clocked Scan

.................................................. Following is a sequence of commands to generate an SPF in a TetraMAX session. Figure 7–21 shows a sample SPF generated by TetraMAX; it includes statements for setting up clock and asynchronous reset inputs. BUILD> read netlist -lib TC240CT.tmaxlib BUILD> read netlist demo.v BUILD> run build_model demo DRC> add clocks 0 clk reset DRC> write drc_file demo.spf_pre

Figure 7–21 SPF Before Modification (for Single-Clocked Scan) STIL 1.0 { Extension Design P2000.5; } Header { Title " TetraMAX (TM) 2000.05-i001012_225440 STIL output"; Date "Tue May 8 22:32:46 2001"; History { Ann {* Uncollapsed Stuck Fault Summary Report *} ... Ann {* There are no net connections *} } } Signals { "clk" In; "reset" In; "control[1]" In; "control[0]" In; "bus_ctl" In; "test_si1" In; "test_si2" In; "test_se" In; "data_bus[7]" InOut; "data_bus[6]" InOut; "data_bus[5]" InOut; "data_bus[4]" InOut; "data_bus[3]" InOut; "data_bus[2]" InOut; "data_bus[1]" InOut; "data_bus[0]" InOut; "test_so1" Out; "test_so2" Out; } SignalGroups { "_default_In_Timing_" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "test_si1" + "test_si2" + "test_se"'; //#signals=16 "_pi" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "test_si1" + "test_si2" + "test_se"'; // #signals=16 "_io" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]"

142

+ "data_bus[2]" + "data_bus[1]" + "data_bus[0]"' { WFCMap 0X->0; WFCMap 1X->1; WFCMap ZX->Z; WFCMap NX->N; } // #signals=8 "_default_Out_Timing_" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "test_so1" (1) + "test_so2"'; // #signals=10 "_po" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "test_so1" + "test_so2"'; // #signals=10 "_default_Clk0_Timing_" = '"clk" + "reset"'; // #signals=2 } ScanStructures { // Uncomment and modify the following to suit your design // ScanChain "chain_name" { ScanIn "chain_input_name"; ScanOut "chain_output_name"; } } Timing { WaveformTable "_default_WFT_" { Period '100ns'; Waveforms { "_default_In_Timing_" { 0 { '0ns' D; } } "_default_In_Timing_" { 1 { '0ns' U; } } "_default_In_Timing_" { Z { '0ns' Z; } } "_default_In_Timing_" { N { '0ns' N; } } "_default_Clk0_Timing_" { P { '0ns' D; '50ns' U; '80ns' D; } } "_default_Out_Timing_" { X { '0ns' X; } } "_default_Out_Timing_" { H { '0ns' X; '40ns' H; } } "_default_Out_Timing_" { T { '0ns' X; '40ns' T; } } "_default_Out_Timing_" { L { '0ns' X; '40ns' L; } } } } } PatternBurst "_burst_" { PatList { "_pattern_" { } }} PatternExec { PatternBurst "_burst_"; } Procedures { "capture_clk" { W "_default_WFT_"; "forcePI": V { "_pi"=\r16 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } "pulse": V { "clk"=P; "_po"=\j \r10 X ; } } "capture_reset" { W "_default_WFT_"; "forcePI": V { "_pi"=\r16 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } "pulse": V { "reset"=P; "_po"=\j \r10 X ; } } "capture" { W "_default_WFT_"; "forcePI": V { "_pi"=\r16 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } }

(2)

143

.....

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

7

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

// Uncomment and modify the following to suit your design // load_unload { // V { "clk" = 0; "reset" = 0; } // force clocks off and shift enable pins active // Shift { V { _si=#; _so=#; "clk" = P; "reset" = P; }} // pulse shift clocks // } } MacroDefs { "test_setup" { W "_default_WFT_"; V { "clk"=0; "reset"=0; } } }

(3)

(4)

Figure 7–22 shows a sample SPF after modification. Figure 7–22 SPF After Modification (for Single-Clocked Scan) STIL 1.0 { Extension Design P2000.5; } Header { Title " TetraMAX (TM) 2000.05-i001012_225440 STIL output"; Date "Tue May 8 21:29:47 2001"; History { Ann {* Uncollapsed Stuck Fault Summary Report *} ... Ann {* There are no net connections *} } } Signals { "clk" In; "reset" In; "control[1]" In; "control[0]" In; "bus_ctl" In; "test_si1" In; "test_si2" In; "test_se" In; "data_bus[7]" InOut; "data_bus[6]" InOut; "data_bus[5]" InOut; "data_bus[4]" InOut; "data_bus[3]" InOut; "data_bus[2]" InOut; "data_bus[1]" InOut; "data_bus[0]" InOut; "test_so1" Out; "test_so2" Out; } SignalGroups { "_default_In_Timing_" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "test_si1" + "test_si2" + "test_se"'; //#signals=16 "_pi" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "test_si1" + "test_si2" + "test_se"'; // #signals=16 "_io" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]"' { WFCMap 0X->0; WFCMap 1X->1; WFCMap ZX->Z; WFCMap NX->N; } // #signals=8 "_default_Out_Timing_" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "test_so1" + "test_so2"'; // #signals=10 "_po" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "test_so1" + "test_so2"'; // #signals=10 "_default_Clk0_Timing_" = '"clk" + "reset"'; // #signals=2 }

144

ScanStructures { ScanChain "IN0" { ScanIn "test_si1"; ScanOut "test_so1"; } ScanChain "IN1" { ScanIn "test_si2"; ScanOut "test_so2"; } } Timing { WaveformTable "_default_WFT_" { Period '100ns'; Waveforms { "_default_In_Timing_" { 0 { '0ns' D; } } "_default_In_Timing_" { 1 { '0ns' U; } } "_default_In_Timing_" { Z { '0ns' Z; } } "_default_In_Timing_" { N { '0ns' N; } } "_default_Clk0_Timing_" { P { '0ns' D; '50ns' U; '80ns' D; } } "_default_Out_Timing_" { X { '0ns' X; } } "_default_Out_Timing_" { H { '0ns' X; '40ns' H; } } "_default_Out_Timing_" { T { '0ns' X; '40ns' T; } } "_default_Out_Timing_" { L { '0ns' X; '40ns' L; } } } } } PatternBurst "_burst_" { PatList { "_pattern_" { } }} PatternExec { PatternBurst "_burst_"; } Procedures { "capture_clk" { W "_default_WFT_"; V { "_pi"=\r16 # ; "_po"=\r10 # ; "clk"=P; } } "capture_reset" { W "_default_WFT_"; V { "_pi"=\r16 # ; "_po"=\r10 # ; "reset"=P; } } load_unload { V { "clk" = 0; "bus_ctl" = 1; "test_se" = 1; "reset" = 0; } Shift { V { _si = \r2 #; _so = \r2 #; "clk = P; } } } }

(1)

(2)

(3)

145

.....

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

7

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

MacroDefs { "test_setup" { W "_default_WFT_"; V { "clk"=0; "reset"=0; "bus_ctl"=1; } } }

(4)

1. ScanStructures construct Define all scan chains in your design and their scan-in and scan-out ports. There must be as many ScanChain statements as the number of scan chains. Scan chain names must be in uppercase due to Toshiba’s TSTL2 restriction. 2. capture procedures in the Procedures construct Delete a procedure named capture. Modify capture_ procedures. TetraMAX, by default, generates three-cycle capture procedures (i.e., three V statements): forcePI, measurePO and pulse. Merge these capture cycles into a single cycle. To do that, combine _pi=# of the first vector, _PO=# of the second vector and clk=P of the third vector into a single V statement. 3. load_unload procedure in the Procedures construct Use a V{...} statement immediately below load_unload to define how the scan chains in your design can be placed into a shiftable state. Here, put the clock and the bidirectional 3-state enable signals in their off states. If your design has bidirectional ports that can not be controlled externally, see the section 7.4, "Controlling Bidirectional Ports," on page 134. Modify the Shift procedure to define how the scan chains in your design can be shifted one bit. Look at the Shift procedure in an SPF before modification (Figure 7–21), which pulses an asynchronous reset signal; delete "reset" =P from the event list. _si and _so represent all scan-in and scan-out ports respectively. Enter _si = \r # and _so = \r #, where is equal to the number of the scan chains. 4. test_setup macro in the MacroDefs construct Add a definition to force bidirectional buses into input mode. If your design has any bidirectional ports that can not be controlled externally, see the section 7.4, "Controlling Bidirectional Ports," on page 134.

146

SPF for Dual-Clocked Scan

.................................................. Following is a sequence of commands to generate an SPF in a TetraMAX session. Figure 7–23 shows a sample SPF generated by TetraMAX; it includes statements for setting up clock and asynchronous reset inputs. BUILD> read netlist -lib TC240CT.tmaxlib BUILD> read netlist demo.v BUILD> run build_model demo DRC> add clocks 0 clk reset ACK BCK DRC> write drc_file demo.spf_pre

Figure 7–23 SPF Before Modification (for Dual-Clocked Scan) STIL 1.0 { Extension Design P2000.5; } Header { Title " TetraMAX (TM) 2000.05-i001012_225440 STIL output"; Date "Wed May 9 16:47:02 2001"; History { Ann {* Uncollapsed Stuck Fault Summary Report *} ... Ann {* There are no net connections *} } } Signals { "clk" In; "reset" In; "control[1]" In; "control[0]" In; "bus_ctl" In; "ACK" In; "BCK" In; "SDI0" In; "SDI1" In; "data_bus[7]" InOut; "data_bus[6]" InOut; "data_bus[5]" InOut; "data_bus[4]" InOut; "data_bus[3]" InOut; "data_bus[2]" InOut; "data_bus[1]" InOut; "data_bus[0]" InOut; "SDO0" Out; "SDO1" Out; } SignalGroups { "_default_In_Timing_" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "ACK" + "BCK" + "SDI0" + "SDI1"'; // #signals=17 "_pi" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "ACK" + "BCK" + "SDI0" + "SDI1"'; // #signals=17 "_io" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]"' { WFCMap 0X->0; WFCMap 1X->1; WFCMap ZX->Z; WFCMap NX->N; } // #signals=8 "_default_Out_Timing_" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "SDO0" + "SDO1"'; // #signals=10 "_po" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "SDO0" + "SDO1"'; // #signals=10 "_default_Clk0_Timing_" = '"clk" + "reset" + "ACK" + "BCK"'; // #signals=4

(1)

147

.....

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

7

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

} ScanStructures { // Uncomment and modify the following to suit your design // ScanChain "chain_name" { ScanIn "chain_input_name"; ScanOut "chain_output_name"; } } Timing { WaveformTable "_default_WFT_" { Period '100ns'; Waveforms { "_default_In_Timing_" { 0 { '0ns' D; } } "_default_In_Timing_" { 1 { '0ns' U; } } "_default_In_Timing_" { Z { '0ns' Z; } } "_default_In_Timing_" { N { '0ns' N; } } "_default_Clk0_Timing_" { P { '0ns' D; '50ns' U; '80ns' D; } } "_default_Out_Timing_" { X { '0ns' X; } } "_default_Out_Timing_" { H { '0ns' X; '40ns' H; } } "_default_Out_Timing_" { T { '0ns' X; '40ns' T; } } "_default_Out_Timing_" { L { '0ns' X; '40ns' L; } } } } } PatternBurst "_burst_" { PatList { "_pattern_" { } }} PatternExec { PatternBurst "_burst_"; } Procedures { "capture_clk" { W "_default_WFT_"; "forcePI": V { "_pi"=\r19 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } "pulse": V { "clk"=P; "_po"=\j \r10 X ; } } "capture_ACK" { W "_default_WFT_"; "forcePI": V { "_pi"=\r19 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } "pulse": V { "ACK"=P; "_po"=\j \r10 X ; } } "capture_BCK" { W "_default_WFT_"; "forcePI": V { "_pi"=\r19 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } "pulse": V { "BCK"=P; "_po"=\j \r10 X ; } } "capture_reset" { W "_default_WFT_"; "forcePI": V { "_pi"=\r19 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; } "pulse": V { "reset"=P; "_po"=\j \r10 X ; } } "capture" { W "_default_WFT_"; "forcePI": V { "_pi"=\r19 # ; "_po"=\j \r10 X ; } "measurePO": V { "_po"=\r10 # ; }

148

(2)

(3)

(4)

} // Uncomment and modify the following to suit your design // load_unload { // V { "clk" = 0; "ACK" = 0; "BCK" = 0; "reset" = 0; } // force clocks off and //scan shift enable pins active // Shift { V { _si=#; _so=#; "clk" = P; "ACK" = P; "BCK" = P; "reset" = P; }} // pulse shift clocks // } } MacroDefs { "test_setup" { W "_default_WFT_"; V { "clk"=0; "ACK"=0; "BCK"=0; "reset"=0; } } }

(5)

(7)

Figure 7–24 shows a sample SPF after modification. Figure 7–24 SPF After Modification (for Dual-Clocked Scan) STIL 1.0 { Extension Design P2000.5; } Header { Title " TetraMAX (TM) 2000.05-i001012_225440 STIL output"; Date "Wed May 9 16:47:02 2001"; History { Ann {* Uncollapsed Stuck Fault Summary Report *} ... Ann {* There are no net connections *} } } Signals { "clk" In; "reset" In; "control[1]" In; "control[0]" In; "bus_ctl" In; "ACK" In; "BCK" In; "SDI0" In; "SDI1" In; "data_bus[7]" InOut; "data_bus[6]" InOut; "data_bus[5]" InOut; "data_bus[4]" InOut; "data_bus[3]" InOut; "data_bus[2]" InOut; "data_bus[1]" InOut; "data_bus[0]" InOut; "SDO0" Out; "SDO1" Out; } SignalGroups { "_default_In_Timing_" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "ACK" + "BCK" + "SDI0" + "SDI1"'; // #signals=17 "_pi" = '"clk" + "reset" + "data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "control[1]" + "control[0]" + "bus_ctl" + "ACK" + "BCK" + "SDI0" + "SDI1"'; // #signals=17 "_io" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]"' { WFCMap 0X->0; WFCMap 1X->1; WFCMap ZX->Z; WFCMap NX->N; } // #signals=8 "_default_Out_Timing_" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]"

149

.....

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

7

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

+ "data_bus[0]" + "SDO0" + "SDO1"'; // #signals=10 "_po" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]" + "data_bus[3]" + "data_bus[2]" + "data_bus[1]" + "data_bus[0]" + "SDO0" + "SDO1"'; // #signals=10 "_default_Clk0_Timing_" = '"clk" + "reset"'; // #signals=2 "_default_ACK_Timing_" = '"ACK"'; // #signals=1 "_default_BCK_Timing_" = '"BCK"'; // #signals=1 } ScanStructures { // Uncomment and modify the following to suit your design ScanChain "IN0" { ScanIn "SDI0"; ScanOut "SDO0"; } ScanChain "IN1" { ScanIn "SDI1"; ScanOut "SDO1"; } } Timing { WaveformTable "_default_WFT_" { Period '100ns'; Waveforms { "_default_In_Timing_" { 0 { '0ns' D; } } "_default_In_Timing_" { 1 { '0ns' U; } } "_default_In_Timing_" { Z { '0ns' Z; } } "_default_In_Timing_" { N { '0ns' N; } } "_default_Clk0_Timing_" { P { '0ns' D; '50ns' U; '80ns' D; } } "_default_ACK_Timing_" { P { '0ns' D; '10ns' U; '30ns' D; } } "_default_BCK_Timing_" { P { '0ns' D; '50ns' U; '80ns' D; } } "_default_Out_Timing_" { X { '0ns' X; } } "_default_Out_Timing_" { H { '0ns' X; '40ns' H; } } "_default_Out_Timing_" { T { '0ns' X; '40ns' T; } } "_default_Out_Timing_" { L { '0ns' X; '40ns' L; } } } } } PatternBurst "_burst_" { PatList { "_pattern_" { } }} PatternExec { PatternBurst "_burst_"; } Procedures { "capture_clk" { W "_default_WFT_"; V { "_pi"=\r17 # ; "_po"=\r10 # ; "clk"=P; } } "capture_reset" { W "_default_WFT_"; V { "_pi"=\r17 # ; "_po"=\r10 # ; "reset"=P; } } load_unload { V { "clk" = 0; "ACK" = 0; "BCK" = 0; "reset" = 0; "bus_ctl" = 1; }

150

(1)

(2)

(3)

(4)

(5)

Shift { V { _si = \r2 #; _so = \r2 #; "clk" = 0; "ACK" = P; "BCK" = P; "reset" = 0;

(5)

} } } master_observe { V { "clk" = 0; "ACK" = 0; "BCK" = P; "reset" = 0; "bus_ctl" = 1; } }

(6)

} MacroDefs { "test_setup" { W "_default_WFT_"; V { "clk"=0; "ACK"=0; "BCK"=0; "reset"=0; "bus_ctl"=1; } } }

(7)

1. SignalGroups construct The write drc_file command groups all positive-triggered clocks (and asynchronous sets and resets) into "_default_Clk0_Timing_" and all negative-triggered clocks (and asynchronous sets and resets) into "_default_Clk1_Timing_". In the examples of Figure 7–23 and Figure 7–24, all clocks are positive-edge-triggered; thus there is only a "_default_Clk0_Timing" signal group. Delete scan clocks (ACK and BCK) from "_default_Clk0_Timing" and define two new signal groups, one each for master (A) and slave (B) scan clocks. Remember to surround the entire signal list between single quotes. 2. ScanStructures construct Define all scan chains in your design and their scan-in and scan-out ports. There must be as many ScanChain statements as the number of scan chains. Scan chain names must be in uppercase due to Toshiba’s TSTL2 restriction. 3. Timing construct Define waveforms for the scan clocks. Scan Clock A (ACK) must go active before Scan Clock B (BCK), and Scan Clock A must not overlap with Scan Clock B.

151

.....

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

7

STIL Procedure File (SPF) 7.8 Editing an SPF Generated by TetraMAX

4. capture procedure in the Procedures construct Delete a procedure named capture. Modify capture_ procedures. TetraMAX, by default, generates three-cycle capture procedures (i.e., three V statements): forcePI, measurePO and pulse. Merge these capture cycles into a single cycle. To do that, combine _pi=# of the first vector, _PO=# of the second vector and clk=P of the third vector into a single V statement. 5. load_unload procedure in the Procedures construct Use a V{...} statement immediately below load_unload to define how the scan chains in your design can be placed into a shiftable state. Here, put all clock and the bidirectional 3-state enable signals in their off states. If your design has bidirectional ports that can not be controlled externally, see the section 7.4, "Controlling Bidirectional Ports," on page 134. Modify the Shift procedure to define how the scan chains in your design can be shifted one bit. Enter _si = \r # and _so = \r #, where is equal to the number of the scan chains. Put all system clocks and asynchronous sets and resets in their off states, and generate clock pulse events on the scan clocks (ACK and BCK). 6. master_observe procedure in the Procedures construct In the master_observe procedure, generate clock pulse events only on Scan Block B (BCLK). Put all system clocks, asynchronous sets and resets, and Scan Clock A (ACK) in their off states. Force bidirectional buses into input mode. If your design has any bidirectional ports that can not be controlled externally, see the section 7.4, "Controlling Bidirectional Ports," on page 134. 7. test_setup macro in the MacroDefs construct Add a definition to force bidirectional buses into input mode. If your design has any bidirectional ports that can not be controlled externally, see the section 7.4, "Controlling Bidirectional Ports," on page 134.

152

7.9

SPF for a Design with JTAG Logic

If your design has JTAG logic, you can perform ATPG in one of two ways. One way is to disable the JTAG logic for ATPG. The other way is to use the SCANTEST instruction to control scan chains with JTAG logic during ATPG. SCANTEST is Toshiba’s private instruction implemented in JTAG IP cores. For a detailed description of the JTAG IP cores and how to control scan chains with signals generated by JTAG circuitry, refer to an application note entitled JTAG Design Guide.

Disabling JTAG Logic

.................................................. The JTAG logic has to be transparent before you run ATPG. Reset the JTAG logic in the test initialization sequence so that TCK remains inactive throughout testing. Figure 7–25 shows a sample SPF used to run ATPG with JTAG logic disabled.

Figure 7–25 SPF Used to Run ATPG with JTAG Logic Disabled STIL 1.0; Signals { "CLK" In; "RST" In; "CTR[1]" In; "SDI0" In { ScanIn; } "SDI1" In { ScanIn; } "CTR[0]" In; "DMODE[2]" In; "DMODE[1]" In; "DMODE[0]" In; "TSTMODE[1]" In; "TSTMODE[0]" In; "SCANEN[1]" In; "SCANEN[0]" In; "TCK" In; "TRST" In; "TMS" In; "TDI" In; "SDI2" In { ScanIn; } "DA[11]" InOut; "DA[10]" InOut; "DA[9]" InOut; "DA[8]" InOut; "DA[7]" InOut; "DA[6]" InOut; "DA[5]" InOut; "DA[4]" InOut; "DA[3]" InOut; "DA[2]" InOut; "DA[1]" InOut; "DA[0]" InOut; "DB[11]" InOut; "DB[10]" InOut; "DB[9]" InOut; "DB[8]" InOut; "DB[7]" InOut; "DB[6]" InOut; "DB[5]" InOut; "DB[4]" InOut; "DB[3]" InOut; "DB[2]"InOut; "DB[1]" InOut; "DB[0]" InOut; "DOUT[1]" Out; "SDO0" Out { ScanOut; } "SDO1" Out { ScanOut; } "DOUT[0]" Out; "ADR[3]" Out; "ADR[2]" Out; "ADR[1]" Out; "ADR[0]" Out; "TESTOUT" Out; "TDO" Out; "SDO2" { ScanOut; } } SignalGroups { "_pi" = ’"CLK" + "RST" + "CTR[1]" + "SDI0" + "SDI1" "SDI2" + "CTR[0]" + "DMODE[2]" + "DMODE[1]" + "DMODE[0]" + "TSTMODE[1]" + "TSTMODE[0]" + "SCANEN[1]" + "SCANEN[0]" + "TCK" + "TRST" + "TMS" + "TDI" + "DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]"’ "_io" = ’"DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]" ’; "_si" = ’"SDI0" + "SDI1" + "SDI2"’ { ScanIn; }

153

.....

STIL Procedure File (SPF) 7.9 SPF for a Design with JTAG Logic

7

STIL Procedure File (SPF) 7.9 SPF for a Design with JTAG Logic

"_so" = ’"SDO0" + "SDO1" + "SDO2"’ { ScanOut; } "_po" = ’"DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]" + "ADR[3]" + "ADR[2]" + "ADR[1]" + "ADR[0]" + "TESTOUT" + "TDO" + "SDO0" + "SDO1" + "SDO2"’; "_default_In_Timing_" = ’"CLK" + "RST" + "CTR[1]" + "SDI0" + "SDI1" + "CTR[0]" + "DMODE[2]" + "DMODE[1]" + "DMODE[0]" + "TSTMODE[1]" + "TSTMODE[0]" + "JTAGEN[1]" + "JTAGEN[0]" + "TCK" + "TRST" + "TMS" + "TDI" + "DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]"’ "_default_Out_Timing_" = ’"DA[11]" + "DA[10]" + "DA[9]" + + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]" + + "ADR[1]" + "ADR[0]" + "TESTOUT" + "TDO"’;

"DA[8]" + "DA[7]" "DA[1]" + "DA[0]" + "DB[6]" + "DB[5]" "ADR[3]" + "ADR[2]"

} ScanStructures { ScanChain "IN0" { ScanIn "SDI0"; ScanOut "SDO0"; } ScanChain "IN1" { ScanIn "SDI1"; ScanOut "SDO1"; } ScanChain "IN2" { ScanIn "SDI2"; ScanOut "SDO2"; } } Timing { WaveformTable "_default_WFT_" { Period ’100ns’; Waveforms { "_default_In_Timing_" { 0 { ’0ns’ D; } } "_default_In_Timing_" { 1 { ’0ns’ U; } } "_default_In_Timing_" { Z { ’0ns’ Z; } } "_default_In_Timing_" { N { ’0ns’ N; } } "_default_Out_Timing_" { X { ’0ns’ X; } } "_default_Out_Timing_" { H { ’0ns’ X; ’30ns’ H; } } "_default_Out_Timing_" { L { ’0ns’ X; ’30ns’ L; } } "_default_Out_Timing_" { T { ’0ns’ X; ’30ns’ T; } } "CLK" { P { ’0ns’ D; ’40ns’ U; ’60ns’ D; } } "TCK" { P { ’0ns’ D; ’35ns’ U; ’85ns’ D; } } } } }

154

Procedures { "load_unload" { W "_default_WFT_"; V { "SCANEN[1]"=0; "SCANEN[0]"=1; "RST"=1; "CLK"=0; "TRST"=1; //Hold TRST Shift { W "_default_WFT_"; V { "CLK"=P; "TCK"=0; "_so"=###; "_si"=###; } //Scan-shift } } "capture_CLK" { W "_default_WFT_"; F { "RST"=1; "TCK"=0; "TRST"=1; "TMS"=0;} //Hold TRST "forcePI": V { "_pi"=\r40 # ; "_po"=\r28 X ; } "measurePO": V { "_po"=\r28 # ; } "pulse": V { "_po"=\r28 X ; "CLK"=P; } } "capture" { W "_default_WFT_"; F { "RST"=1; "TCK"=0; "TRST"=1; "TMS"=0; } //Hold TRST V { "_pi"=\r40 # ; "_po"=\r28 # ; } }

"TCK"=0; } at 1 and TCK at 0.

at 1 and TCK at 0.

at 1 and TCK at 0.

MacroDefs { "test_setup" { W "_default_WFT_"; // Initialize JTAG logic to the reset state. // Thereafter, keep it in the reset state throughout testing. V { "JTAGEN[1]"=0; "JTAGEN[0]"=1; "RST"=0; "CLK"=0; "TCK"=0; "TRST"=0; "TMS"=1; "TDI"=0; } V { "TRST"=1; "RST"=1; } } }

Using the JTAG SCANTEST Instruction

.................................................. To make scan chains controlled by signals generated by the JTAG logic, you must make TetraMAX ATPG understand the operation of the JTAG logic. Figure 7–26 shows a sample SPF to control the state transitions of the JTAG logic.

Figure 7–26 SPF for Using the JTAG SCANTEST Instruction for ATPG STIL 1.0; Signals { "CLK" In; "RST" In; "CTR[1]" In; "SDI0" In { ScanIn; } "SDI1" In { ScanIn; } "CTR[0]" In; "DMODE[2]" In; "DMODE[1]" In; "DMODE[0]" In; "TSTMODE[1]" In; "TSTMODE[0]" In; "JTAGEN[1]" In; "JTAGEN[0]" In; "TCK" In; "TRST" In; "TMS" In; "TDI" In { ScanIn; } "DA[11]" InOut; "DA[10]" InOut; "DA[9]" InOut;

155

.....

STIL Procedure File (SPF) 7.9 SPF for a Design with JTAG Logic

7

STIL Procedure File (SPF) 7.9 SPF for a Design with JTAG Logic

"DA[8]" InOut; "DA[7]" InOut; "DA[6]" InOut; "DA[5]" InOut; "DA[4]" InOut; "DA[3]" InOut; "DA[2]" InOut; "DA[1]" InOut; "DA[0]" InOut; "DB[11]" InOut; "DB[10]" InOut; "DB[9]" InOut; "DB[8]" InOut; "DB[7]" InOut; "DB[6]" InOut; "DB[5]" InOut; "DB[4]" InOut; "DB[3]" InOut; "DB[2]"InOut; "DB[1]" InOut; "DB[0]" InOut; "DOUT[1]" Out; "SDO0" Out { ScanOut; } "SDO1" Out { ScanOut; } "DOUT[0]" Out; "ADR[3]" Out; "ADR[2]" Out; "ADR[1]" Out; "ADR[0]" Out; "TESTOUT" Out; "TDO" Out { ScanOut; } } SignalGroups { "_pi" = ’"CLK" + "RST" + "CTR[1]" + "SDI0" + "SDI1" + "CTR[0]" + "DMODE[2]" + "DMODE[1]" + "DMODE[0]" + "TSTMODE[1]" + "TSTMODE[0]" + "JTAGEN[1]" + "JTAGEN[0]" + "TCK" + "TRST" + "TMS" + "TDI" + "DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]"’ "_io" = ’"DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]" ’; "_si" = ’"SDI0" + "SDI1" + "TDI"’ { ScanIn; } "_so" = ’"SDO0" + "SDO1" + "TDO"’ { ScanOut; } "_po" = ’"DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]" + "ADR[3]" + "ADR[2]" + "ADR[1]" + "ADR[0]" + "TESTOUT" + "SDO0" + "SDO1" + "TDO"’; "_default_In_Timing_" = ’"CLK" + "RST" + "CTR[1]" + "SDI0" + "SDI1" + "CTR[0]" + "DMODE[2]" + "DMODE[1]" + "DMODE[0]" + "TSTMODE[1]" + "TSTMODE[0]" + "JTAGEN[1]" + "JTAGEN[0]" + "TCK" + "TRST" + "TMS" + "TDI" + "DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]"’ "_default_Out_Timing_" = ’"DA[11]" + "DA[10]" + "DA[9]" + "DA[8]" + "DA[7]" + "DA[6]" + "DA[5]" + "DA[4]" + "DA[3]" + "DA[2]" + "DA[1]" + "DA[0]" + "DB[11]" + "DB[10]" + "DB[9]" + "DB[8]" + "DB[7]" + "DB[6]" + "DB[5]" + "DB[4]" + "DB[3]" + "DB[2]" + "DB[1]" + "DB[0]" + "ADR[3]" + "ADR[2]" + "ADR[1]" + "ADR[0]" + "TESTOUT" + "TDO"’; } ScanStructures { ScanChain "IN0" { ScanIn "SDI0"; ScanOut "SDO0"; } ScanChain "IN1" { ScanIn "SDI1"; ScanOut "SDO1"; } ScanChain "IN3" { ScanIn "TDI"; ScanOut "TDO"; } }

156

Timing { WaveformTable "_default_WFT_" { Period ’100ns’; Waveforms { "_default_In_Timing_" { 0 { ’0ns’ D; } } "_default_In_Timing_" { 1 { ’0ns’ U; } } "_default_In_Timing_" { Z { ’0ns’ Z; } } "_default_In_Timing_" { N { ’0ns’ N; } } "_default_Out_Timing_" { X { ’0ns’ X; } } "_default_Out_Timing_" { H { ’0ns’ X; ’30ns’ H; } } "_default_Out_Timing_" { L { ’0ns’ X; ’30ns’ L; } } "_default_Out_Timing_" { T { ’0ns’ X; ’30ns’ T; } } "CLK" { P { ’0ns’ D; ’40ns’ U; ’60ns’ D; } } "TCK" { P { ’0ns’ D; ’35ns’ U; ’85ns’ D; } } } } } Procedures { "load_unload" { W "_default_WFT_"; // Move from the Pause-DR state to the Shift-DR state. V { "JTAGEN[1]"=0; "JTAGEN[0]"=1; "RST"=1; "CLK"=0; "TRST"=1; "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=0; } // Shift-DR Shift { W "_default_WFT_"; V { "CLK"=P; "TCK"=0; "_so"=###; "_si"=###; } // Shift scan chains. } // Move from the Shift-DR state back to the Pause-DR state. V { "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=0; } // Pause-DR } "capture_CLK" { W "_default_WFT_"; F { "RST"=1; "TCK"=0; "TRST"=1; "TMS"=0;} "forcePI": V { "_pi"=\r40 # ; "_po"=\r27 X ; } "measurePO": V { "_po"=\r27 # ; } "pulse": V { "_po"=\r27 X ; "CLK1"=P; } } "capture" { W "_default_WFT_"; F { "RST"=1; "TCK"=0; "TRST"=1; "TMS"=0; } V { "_pi"=\r40 # ; "_po"=\r27 # ; } } MacroDefs { "test_setup" { W "_default_WFT_"; // Initialize JTAG logic to the reset state. V { "JTAGEN[1]"=0; "JTAGEN[0]"=1; "RST"=0; "CLK"=0; "TCK"=0; "TRST"=0; "TMS"=1; "TDI"=0; } V { "TRST"=1; "RST"=1; } // Move to the Shift-IR state.

157

.....

STIL Procedure File (SPF) 7.9 SPF for a Design with JTAG Logic

7

STIL Procedure File (SPF) 7.9 SPF for a Design with JTAG Logic

V { "TCK"=P; "TMS"=0; } V { "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=0; } V { "TCK"=P; "TMS"=0; } // Serially shift in the instruction code for SCANTEST. V { "TCK"=P; "TMS"=0; "TDI"=1; } V { "TCK"=P; "TMS"=0; "TDI"=1; } V { "TCK"=P; "TMS"=0; "TDI"=1; } V { "TCK"=P; "TMS"=1; "TDI"=0; } // Move to the Pause-DR state. V { "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=0; } V { "TCK"=P; "TMS"=1; } V { "TCK"=P; "TMS"=0; } V { "TCK"=0; "TMS"=0; } } }

158

Chapter 8

Using TetraMAX ATPG

.....

.....................................

T

his chapter describes how to perform ATPG using Synopsys’ TetraMAX in conjunction with Toshiba’s TetraMAX design kit. The material is organized into the following sections:

☞ Overview ☞ Running TetraMAX ATPG ☞ Various Test Coverage Calculations ☞ ATPG Test Cycles ☞ Running TFSA and LSF2DEF ☞ Advanced Topics ☞ Known Problems

159

Using TetraMAX ATPG 8.1 Overview

8

8.1

Overview

About TetraMAX ATPG

.................................................. TetraMAX is a high-speed ATPG tool for scan designs. TetraMAX can generate high-quality test patterns for designs of all sizes, including megagate ASICs.

ATPG Design Flow

.................................................. Figure 8–1 shows the basic ATPG design flow using TetraMAX. The input files for TetraMAX are: 1) a netlist file, 2) a STIL procedure file (SPF) that describes the structure and operation of scan chains, and 3) a TetraMAX library file contained in the Toshiba design kit. Figure 8–1 General Design Flow Using TetraMAX ATPG

Netlist

Setup File

SPFGen (Toshiba’s TetraMAX Design Kit)

SPF

TMCMD

Library

Synopsys TetraMAX

TSTL2 To Toshiba’s Sign-off System

SCE

SPA

TFSA (Toshiba’s TetraMAX Design Kit)

FSA To Toshiba’s Sign-off System

LSF To place & route and scan-chain reordering (SCR) in conventional layout flow

LSF2DEF (Toshiba’s DFT Design Kit)

SCRDEF To place & route and scan-chain reordering (SCR) in Layout-Verilog interface flow

160

The files used and generated by TetraMAX, SPFGen, TFSA and LSF2DEF are explained below. SPFGen and TFSA are contained in the Toshiba TetraMAX design kit, whereas LSF2DEF is contained in the Toshiba DFT design kit. ■

Netlist file

Gate-level netlist in Verilog-HDL or VHDL format produced by DFT Compiler. See Chapter 6.

■

Setup file

The required setup file differs, depending on the tool used for scan synthesis. Refer to 10.2, "SPFGen," on page 229.

■

TMCMD file

TetraMAX command file

■

SPF

STIL procedure file. See Chapter 7, "STIL Procedure File (SPF)," for a detailed description. This file provides the following information needed by TetraMAX ATPG: • • • • • •

System clock ports and their active states Asynchronous set and reset ports and their active states Scan-in and scan-out ports Scan Test Enable ports and their active states Scan Shift Enable ports and their active states Ports that control bidirectional ports and their active states You can create an SPF in one of the following three ways:

• • •

DFT Compiler write_test_protocol command SPFGen in Toshiba’s TetraMAX design kit TetraMAX write drc_file command (template)

■

Library

TetraMAX library provided by Toshiba

■

TSTL2 file

Test pattern file in Toshiba’s TSTL2 format produced by TetraMAX. The TSTL2 file is used as input to the Toshiba sign-off system.

■

SCE file

Contains reports on scan chains and scan cells generated by the report scan chains and report scan cells commands. This file is used as input to TFSA.

■

SPA file

Contains a very detailed report on gates in scan chains generated by the report scan path command. This file is used as input to TFSA to generate an LSF file, which is required for scan-chain reordering.

■

FSA file

Identifies scan flip-flops and their properties in the order in which they are connected in scan chains. This file is required by the sign-off

161

.....

Using TetraMAX ATPG 8.1 Overview

8

Using TetraMAX ATPG 8.1 Overview

system to convert a TSTL2 file into Verilog or VHDL format suitable for parallel-load simulation (PLS). ■

LSF file

Describes the connections of cells in the scan chain. This file is required to perform scan-chain reordering (SCR) in the conventional layout flow.

■

SCRDEF file

Describes the connections of cells in the scan chain. This file is required to perform scan-chain reordering (SCR) in the new Layout-Verilog Interface flow.

Running SPFGen

.................................................. You can use SPFGen to create an SPF file and a command file for TetraMAX automatically. Before running SPFGen, a setup file must be created. To run SPFGen, enter the following command at a UNIX shell prompt. %> spfgen

For a detailed description of SPFGen, see 10.2, "SPFGen," on page 229.

Invoking TetraMAX

.................................................. You can use TetraMAX in one of the two user interfaces: graphical user interface (GUI) or text-based command interface (Shell mode). The invocation commands are: %> tmax %> tmax -shell

//GUI mode //Shell mode

Use Shell mode when your design environment does not support window-based interface or when you want to run the TetraMAX job in the background. The GUI mode features the Graphical Schematic Viewer (GSV) window, which enables interactive analysis and debugging of design rules violations. In either mode, you can submit a list of commands as a file and have TetraMAX execute those commands in batch mode. Figure 8–2 shows an example of a command file.

162

Figure 8–2 TetraMAX Command File

//comment read netlist -lib $TOSH_ROOT/lib/tmax/TC260CT/TC260CT.tmaxlib read netlist TOP.v run build_model TOP ....

You can specify a command file to be run when starting TetraMAX, as follows: %> tmax command_file %> tmax -shell command_file

//GUI mode //Shell mode

You can also run a command file within a TetraMAX session by using the source command: BUILD> source command_file

TetraMAX Command Modes

.................................................. TetraMAX has three command modes: BUILD, DRC and TEST. You use these command modes in this order, as shown in Figure 8–3.

163

.....

Using TetraMAX ATPG 8.1 Overview

8

Using TetraMAX ATPG 8.1 Overview

Figure 8–3 TetraMAX Command Modes Netlist

Library

SPF

BUILD Command Mode (Read a design and build its ATPG model.)

No

OK? Yes DRC Command Mode (Perform design rules checking.)

No

OK? Yes

TEST Command Mode (Perform ATPG)

TSTL2

SCE

SPA

Running TFSA

.................................................. TFSA takes as input SCE and SPA files, and generates FSA and LSF files. To execute TFSA, enter the following command at a UNIX shell prompt. %> tfsa top_module_name [-verilog|-vhdl] [-lsf] [-chip] [-delimit hierarchy_delimiter]

For a detailed description of TFSA, see Chapter 10, "Toshiba TetraMAX Design Kit," on page 159.

164

Running LSF2DEF

.................................................. LSF2DEF converts an LSF file into an SCRDEF file required for scan-chain reordering in the layout-Verilog interface flow. To execute LSF2DEF, enter the following command at your UNIX shell prompt: %> lsf2def.pl top_module_name

The output SCRDEF file name wii be design.scrdef.

165

.....

Using TetraMAX ATPG 8.1 Overview

8

8.2

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Running TetraMAX ATPG

TetraMAX Design Flow

.................................................. TetraMAX ATPG has the following command modes: ■

BUILD:

Builds the ATPG model for a design.

■

DRC:

Performs test design rules checking.

■

TEST:

Performs ATPG.

The command mode indicator displays either BUILD>, DRC> or TEST>, depending on which mode is currently enabled. You must successfully complete the current command mode before you can enter the next command mode. Figure 8–4 shows a typical command sequence executed in each mode.

166

Figure 8–4 Typical TetraMAX Design Flow

Netlist

SPF

Library

BUILD Mode BUILD> set build -hierarchical_delimiter . BUILD> read netlist -library -master_module $TOSH_ROOT/lib/tmax/ \ /technology/filename BUILD> read netlist filename BUILD> set build -black_box module_name BUILD> run build_model top_module_name

DRC Mode DRC> add clocks off_state port_name DRC> add pi constraints {0|1|X|Z} port_name DRC> set drc -clock -one_hot DRC> run drc SPF_filename

TEST Mode TEST> report scan chains > top_module_name.sce TEST> report scan cells -all >> top_module_name.sce TEST> report scan path scan_chain1 sco sci > top_module_name.spa TEST> report scan path scan_chain2 sco sci >> top_module_name.spa ... TEST> run atpg -auto TEST> report summaries primitives faults patterns TEST> write patterns filename -format tstl2 -internal -replace

TSTL2

SCE

SPA

Figure 8–5 Typical Command Sequence

BUILD> set build -hierarchical_delimiter . BUILD> read netlist -library -master \ $TOSH_ROOT/lib/tmax/TC260CT/TC260CT.tmaxlib BUILD> read netlist TMDEMO.v BUILD> set build -black_box MPU_CORE BUILD> run build TMDEMO DRC> add clocks 0 CLK DRC> add pi constraints 0 SEN DRC> set drc -clock -one_hot DRC> run drc TMDEMO.spf TEST> rep scan chains > TMDEMO.sce TEST> rep scan cells -all >> TMDEMO.sce

167

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

TEST> TEST> TEST> TEST> TEST> TEST> TEST> TEST> TEST> TEST> TEST>

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

rep scan path IN0 sco sci rep scan path IN1 sco sci rep scan path IN2 sco sci set faults -model stuck add faults -all run atpg run pattern_compress report summaries write patterns TMDEMO.bin write patterns TMDEMO.tst quit -force

> TMDEMO.spa >> TMDEMO.spa >> TMDEMO.spa

-format binary -internal -replace -format tstl2 -internal -replace

BUILD Command Mode

.................................................. In BUILD command mode, you read in the library and your netlist, and build the ATPG model for your design.

Setting the Hierarchical Delimiter Use this command to specify the dot character as the hierarchical delimiter. BUILD> set build -hierarchical_delimiter .

Reading the Library Run the following command to read in the library. BUILD> read netlist -library -master_module [-noabort] $TOSH_ROOT/lib/tmax/technology/filename

When you are creating a design for Toshiba’s ASIC, use the library contained in the Toshiba TetraMAX design kit. The filename is technology.tmaxlib.

168

Reading the Netlist Run the following command to read in your netlist. BUILD> read netlist filename

TetraMAX can read designs in Verilog-HDL and VHDL formats. The read netlist command can take one file at a time. If you have multiple netlist files, run read netlist on each file, or use the wildcard character (*) in filename.

Defining Black Boxes Before building the ATPG design model, you can explicitly identify modules which should be black-boxed, such as megacells (e.g., RAMs) and analog cells. Enter the following command: BUILD> set build -black_box module_name

Building the ATPG Model Run the following command to build the ATPG model for your design. BUILD> run build_model top_module_name

DRC Command Mode

.................................................. In DRC command mode, you perform test design rules checking (DRC).

169

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Declaring Clock and Asynchronous Set/Reset Ports When No Capture Clock Grouping Is Used Use the add clocks command to define clocks, and primary inputs that function as asynchronous sets and resets to scan cells. Don’t specify synchronous sets and resets. The off-state is 0 when the port is active-high, and 1 when the port is active-low. DRC> add clocks off_state clock_port_name ... DRC> add clocks off_state async_set_port_name ... DRC> add clocks off_state async_reset_port_name ...

When Capture Clock Grouping Is Used By default, only one system clock is activated in any given cycle to avoid unreliable capture conditions. If necessary, you can optionally define a capture clock group, or a set of clocks that can be safely clocked in the same cycle. This helps to reduce the pattern count when your design has multiple system clocks. For more details on this topic, see the section "Multiple Capture Clock Groups" on page 36. Two examples are given below. The add pi equivalences command declares primary input ports to be equivalent; equivalent ports are always driven with the same value during ATPG. ■

When your design has three system clocks named CLK1, CLK2 and CLK3, and CLK2 and CLK3 can be equivalent, enter: DRC> add clocks off_state CLK1 CLK2 CLK3 DRC> add pi equivalences CLK2 CLK3

■

When your design has three clocks named CLK1, CLK2 and CLK3, and all of them can be equivalent, enter: DRC> add clocks off_state CLK1 CLK2 CLK3 DRC> add pi equivalences CLK1 CLK2 CLK3

170

Declaring Primary Input Constraints Use the following command to define primary input ports to be held constant during ATPG. The value of Z can be set only to bidirectional and 3-state output ports. DRC> add pi constraints {0|1|X|Z} port_name

Setting the Capture Clock Figure 8–6, which follows, illustrates how fault effects propagate through the circuit. Faults are exercised by test vectors applied to primary inputs (PIs) and pseudo-primary inputs (PPIs). Fault effects can reach pseudo-primary outputs (PPOs) or primary outputs (POs). Fault effects that propagates to PPOs are captured into scan flip-flops by pulsing a system clock, then shifted out through the scan chain toward a scan-out port. Scan-out for the current pattern and scan-in for the next pattern occur simultaneously. On the other hand, fault effects that propagate to POs are directly observable without pulsing the system clock; the next scan-shifting is done only to scan in the next pattern. Figure 8–6 Fault Propagation Stuck-at Faults Fault effects propagate to a PO. Primary Inputs (PIs)

Primary Outputs (POs) Fault effects propagate to a PPI.

Scan-in (SDI)

Scan-out (SDO)

Pseudo-Primary Inputs and Outputs (PPIs and PPOs)

If you permit generation of such patterns (with no capture clocks in capture mode cycles), the overall ATPG pattern size could increase. To avoid this situation, it is recommended to set the following parameters so that a clock is always supplied during scan capture mode. DRC> set drc -clock -one_hot

171

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Performing Test Design Rule Checking To perform DRC, enter the following command: DRC> run drc SPF_file

The run drc command checks your design to determine that the following rules are met: ■

Scan chains operate correctly during scan shift mode.

■

Scan chains are stitched correctly from primary scan-in ports to primary scan-out ports.

■

All clocks, and asynchronous set and reset signals for scan flip-flops can be directly controlled from primary input ports.

■

All clocks, and asynchronous set and reset signals are in their off states when the design switches between scan shift and capture modes.

■

No bus conflict occurs on multiple-drive nets.

TEST Command Mode

.................................................. In TEST command mode, you run ATPG.

Generating an SCE File When parallel-load simulation (PLS) or scan-chain reordering (SCR) is to be performed, you must generate an SCE file. Redirect the transcripts of the report scan chains and report scan cells commands to the same disk file as shown below.

TEST> report scan chains > top_module_name.sce TEST> report scan cells -all >> top_module_name.sce

Figure 8–7 shows an example of an SCE file. This file is used as input to Toshiba’s TFSA program to generate FSA and LSF files necessary for PLS and SCR.

172

Figure 8–7 SCE File Example Scan chain names

Number of flip-flops Scan-in port in a scan chain

Scan-out port

chain group length input_pin output_pin report scan chains ---------------- ----- ------ ------------------ -----------------transcript C0 sg0 4 /DIA0 /DO0 chain cell type inv gate# instance_name (type) ------- ---- ------- --- ------ -----------------------------------C0 0 MASTER II 110 /ucore/\store_reg[3] (FD4E) report scan cells C0 1 MASTER NN 112 /ucore/\store_reg[2] (FD2E) transcript C0 2 MASTER II 111 /ucore/\store_reg[1] (FD4E) C0 3 MASTER NN 113 /ucore/\store_reg[0] (FD2EP)

Scan flip-flop types

Inversion status

Instance names

Cell names

Generating an SPA File When scan-chain reordering (SCR) is to be performed, you must also generate an SPA file. Redirect a transcript of the report scan path command on all the scan chains to a single disk file, as shown below. TEST> report scan path chain_name1 sco sci > top_module_name.spa TEST> report scan path chain_name2 sco sci >> top_module_name.spa

This file is used as input to Toshiba’s TFSA program to generate an LSF file necessary for SCR. Note: The SPA file can be very huge for complex designs. Ensure that you have sufficient free disk space. See 10.1, "System Requirements" on page 228.

Figure 8–8 shows a fragment of an SPA file.

173

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Figure 8–8 SPA File Scan path for chain=C0: begin_position=SCO, end_position=SCI /DO0 (117) PO (_PO) Header for each scan chain --I 92-/uo0/Z DO0 O PO usage: scanout(C0) Scan-out port of scan chain C0 /uo0 (92) BUF (B8) A I 87-/U6/Z Z O 117-DO0 /U6 (87) MUX (MX2P) S I 50-/ui13/Z A0 I 84-/ucore/U117/Z A1 I 52-/ucore/\store_reg[3]/QN Z O 92-/uo0/A /ucore/\store_reg[3] (52) INV (FD4E) --I 110QN O 87-/U6/A1 /ucore/\store_reg[3] (110) DFF (FD4E) Information about scan flip-flop !SD I 48-/ui11/Z .ucore.\store_reg[3] --I (/TIE_0) • Input and output pin connections CP I 49-/ui12/Z • Instance name --I 109• Cell name, etc. --O 5251scan_behavior: MASTER(LE/-) chain=C0 cell_id=0 invert_data=II obs=noproc /ucore/\store_reg[3] (109) MUX (FD4E) TE I 50-/ui13/Z D I 107-/ucore/U108/Z TI I 69-/ucore/\store_reg[2]/QN --O 110/ucore/\store_reg[2] (69) INV (FD2E) --I 112QN O 109-/ucore/\store_reg[3]/TI /ucore/\store_reg[2] (112) DFF (FD2E) Information about scan flip-flop --I (/TIE_0) .ucore.\store_reg[2] !CD I 48-/ui11/Z • Input and output pin connections CP I 49-/ui12/Z • Instance name --I 108• Cell name, etc. --O 6869scan_behavior: MASTER(LE/-) chain=C0 cell_id=1 invert_data=NN obs=noproc /ucore/\store_reg[2] (108) MUX (FD2E) TE I 50-/ui13/Z D I 106-/ucore/U69/Z TI I 59-/ucore/\store_reg[1]/QN --O 112/ucore/\store_reg[1] (59) INV (FD4E) --I 111QN O 108-/ucore/\store_reg[2]/TI ....... .......

174

Preparing for ATPG Specifying the Pattern Generation Effort Use the set atpg command to specify the amount of effort to be expended in the ATPG process. The set atpg command allows you to control the following: ■

Maximum number of aborts in searching for a pattern for a specific fault (-abort_limit)

■

Maximum capture cycle depth (-capture_cycles)

■

Maximum CPU time allowed per fault and for the entire ATPG run (-time)

■

Maximum number of patterns (-patterns)

■

Test coverage limit (-coverage)

■

Pattern merging effort level during the ATPG process (-merge)

■

Whether ATPG patterns should be stored (-store|-nostore)

Running ATPG Typical ATPG Run A typical ATPG run consists of these phases: ■

Selecting stuck-at fault models

■

Creating a fault list

■

Generating test patterns

■

Compressing test patterns

The sequence of commands to perform these tasks are shown below: TEST> set faults -model stuck TEST> add faults [instance_name | pin_pathname [-stuck 0|1|01] | -module name | -all] TEST> run atpg TEST> run pattern_compression

175

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Alternatively, you can run them with a single command; give the -auto option to the run atpg command. TEST> set atpg -auto

Obtaining Quick Test Coverage Estimates To obtain a quick estimate of the final test coverage result, use the following command sequence. TEST> set atpg -abort_limit 5 -merge off -resim_basic_scan_patterns off -nostore -decision random TEST> run atpg

No pattern merging or pattern compression is done; consequently, the ATPG run is considerably sped up. Pattern count can not be estimated, however, since -nostore option tells TetraMAX not to keep patterns.

Generating a Fault Summary Report To generate a fault summary report, enter the following command: TEST> report summaries [primitives] [faults] [patterns]

Figure 8–9 shows a fault summary report when all of the above three options are specified. Figure 8–9 Fault Summary Report Gate Summary Report -------------------------------------------------------#primitives 73 #primary_inputs 6 # ... #DFFs 2 #scan 2 -------------------------------------------------------Uncollapsed Fault Summary Report -------------------------------------------------------fault class code #fault -------------------------------------- -----------Detected DT 116

176

Possibly detected PT 0 Undetectable UD 0 ATPG untestable AU 0 Not detected ND 0 --------------- ---------------------------------------total faults 116 test coverage 100% -------------------------------------------------------Pattern Summary Report -------------------------------------------------------#internal patterns 10 #basic_scan patterns 10 --------------------------------------------------------

Writing Out Test Patterns in TSTL2 Format Toshiba supports TSTL2 and STIL as tester interface languages in the sign-off environment. Here, the method for converting ATPG patterns generated by TetraMAX into TSTL2 format will be described. If you want to use STIL, contact your Toshiba design center engineer. Generating a Chain Test TetraMAX allows you to generate a chain test for testing the shift operation of the scan chain. The methods for generating a chain test differs between TetraMAX versions. ■

Using TetraMAX 2000.11-SP1 TetraMAX 2000.11-SP1 generates a chain test separately from scan-test patterns. The chain test pattern is predetermined and can not be changed. You can generate a chain test without running the ATPG process. Enter the following command: TEST> write patterns filename.tst -format tstl2 -internal -replace -exclude patterns

■

Using TetraMAX 2001.08 or above TetraMAX 2001.08 generates a chain test as pattern 0 together with the ATPG patterns. It allows you to select the sequence of a chain test pattern. You must run the ATPG process even when you only need a chain test. Enter the following command: TEST> set atpg -chain_test {0011|0101|1000|0111} TEST> run atpg -auto TEST> write patterns filename.tst -format tstl2 -internal -repalce -first 0 -last 0 aaaaaa

177

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Writing ATPG Patterns in TSTL2 Run the following commands to convert the generated ATPG patterns into the TSTL2 format. ■

Using TetraMAX 2000.11-SP1 TEST> write patterns filename.tst -format tstl2 -internal -replace -exclude chain_test

■

Using TetraMAX 2001.08 or above TEST> write patterns filename.tst -format tstl2 -internal -replace -first 1

TSTL2 Conversion Window TetraMAX invokes a separate program called Ltran when writing test patterns in TSTL2. To run Ltran, an environment setup is necessary. ■

Using TetraMAX 2001.08-SP1 or earlier Before starting TetraMAX, set the environmental to open an Xterm window as shown below since Ltran uses an Xterm window. %> setenv DISPLAY display_name %> set path = ( /usr/openwin/bin $path )

■

Using TetraMAX 2002.05 or above Before invoking TetraMAX, set the following environmental variable to run Ltran in the background. %> setenv LTRAN_SHELL 1

Note on the TSTL2 Test Pattern Files Generated by TetraMAX The TSTL2 file from TetraMAX does not contain the following statements within the DECLARE block. You can use SPFGen to automatically generate a file containing only the DECLARE block.

178

■

SYSCLK

■

SCMCLK

■

SCKSLK

■

SCSEL

■

PATTYPE

Edit the generated TSTL2 file to add these statements. Figure 8–10 shows examples of the DECLARE blocks for the single- and dual-clocked scan designs. For a description of the DECLARE block syntax, see B.2, "DECLARE Block," on page 336. Figure 8–10 DECLARE Block in a TSTL2 File

• Single-clocked scan design DECLARE; SYSCLK(P) CLK(IN0); SCSEL(IN0) SEN1; ENDDEC;

• Dual-clocked scan design DECLARE; SYSCLK(P) CLK(IN0); SCMCLK(P) ACK(IN0); SCSCLK(P) BCK(IN0); ENDDEC;

Splitting the Patterns into Multiple TSTL2 Files ATPG patterns for a large, complex design can be very lengthy. You may have to split patterns into multiple TSTL2 files. ■

Specifying the range of pattern numbers TEST> write patterns filename.tst -format tstl2 -first d -last d -internal -replace

The -first and -last options specify the pattern numbers of the first and last patterns. Run the above command several times.

179

.....

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

8

■

Using TetraMAX ATPG 8.2 Running TetraMAX ATPG

Specifying the number of patterns per output file TEST> write patterns filename.tst -format tstl2 -split d -internal -replace

The -split option allows you to limit the number of patterns per output file. The output TSTL2 files will be namedfilename.tst_00, filename.tst_01 and so on. Saving the Patterns in ATPG Binary Storage Format TetraMAX can not read a TSTL2 test pattern file. Save test patterns in the binary format before writing a TSTL2 file. TetraMAX2001.08-SP1 and earlier occasionally fail to convert ATPG patterns into the TSTL2 format due to the use of the Xterm window. For example, TetraMAX2001.08-SP1 and earlier may also experience failure to launch the Xterm window or even bring up as many Ltran sessions (Xterm windows) as required by -split option, causing the system to become unstable. Should such problems occur, you would lose the generated ATPG patterns. Therefore, be sure to save test patterns in the binary format before writing a TSTL2 file. To save ATPG patterns in TetraMAX ATPG binary format, enter the following command: TEST> write patterns filename.bin -format binary -internal -replace

This way, should TSTL2 conversion fails, you can restore test patterns from a binary file without re-running the ATPG process. Reading in a Binary Pattern File You can read a binary pattern file into TetraMAX and convert it into TSTL2 format. To do so, use the -external option on the write patterns command instead of the -internal option. TEST> set patterns external filename.bin TEST> write patterns filename.tst -format tstl2 -external -replace

180

8.3

Various Test Coverage Calculations

TetraMAX can perform various calculations to measure the quality of your test patterns. This section discusses fault coverage, test coverage and testable fault coverage.

Fault Coverage Fault coverage is defined as the percentage of detected faults out of all faults. Give PT faults a zero credit, so fault coverage is calculated as follows: DT Fault Coverage = ------------------------- × 100 total faults Use the -PT_credit option on the set faults command, as shown below: TEST> set faults -fault_coverage -PT_credit 0 TEST> report faults -summary

Figure 8–11 shows a fault summary report resulting from these commands. Figure 8–11 Fault Summary Report (Fault Coverage)

... --------------------------------------------------fault class code #faults ----------------------------------------Detected DT 181 Possibly detected PT 0 Undetectable UD 3 ATPG untestable AU 4 Not detected ND 0 --------------------------------------------------total faults 188 test coverage 97.84% fault coverage 96.28% ...

If you included any megacells in ATPG, see the section "Test Coverage Calculations When Megacell Models Are Used" on page 195.

181

.....

Using TetraMAX ATPG 8.3 Various Test Coverage Calculations

8

Using TetraMAX ATPG 8.3 Various Test Coverage Calculations

Test Coverage Test coverage is defined as the percentage of detected faults (DT) out of detectable faults. All faults meaningless to test are excluded from calculation. One example is stuck-at-1 faults on power nets. Test coverage is the mostly commonly used measure of test pattern quality. DT Test Coverage = ----------------------------------------- × 100 total faults – UD To get a test coverage result close to fault simulation, set both PT_credit and AU_credit to 0, as follows. TEST> set faults -PT_credit 0 -AU_credit 0 TEST> report faults -summary

Figure 8–12 shows a fault summary report resulting from these commands. Figure 8–12 Fault Summary Report (Test Coverage) ... -------------------------------------------------fault class code #faults ----------------------------------------Detected DT 181 Possibly detected PT 0 Undetectable UD 3 ATPG untestable AU 4 Not detected ND 0 -------------------------------------------------total faults 188 test coverage 97.84% ...

If you included any megacells in ATPG, see the section "Test Coverage Calculations When Megacell Models Are Used" on page 195.

Testable Fault Coverage Testable fault coverage is the percentage of detected faults out of all faults that can be detectable using ATPG methods. You can use it as guiding statistics in the course of ATPG. DT Testable Fault Coverage = -------------------------------------------------------- × 100 total faults – UD – AU To calculate testable fault coverage, set PT_credit to 0 and AU_credit to 100%: TEST> set faults -PT_credit 0 -AU_credit 100 TEST> report faults -summary

182

Figure 8–13 shows a fault summary report resulting from these commands. Figure 8–13 Fault Summary Report (Test Fault Coverage)

... --------------------------------------------------fault class code #faults ----------------------------------------Detected DT 181 Possibly detected PT 0 Undetectable UD 3 ATPG untestable AU 4 Not detected ND 0 -------------------------------------------------total faults 188 test coverage 100.00% ...

If you included any megacells in ATPG, see the section "Test Coverage Calculations When Megacell Models Are Used" on page 195.

183

.....

Using TetraMAX ATPG 8.3 Various Test Coverage Calculations

8

8.4

Using TetraMAX ATPG 8.4 ATPG Test Cycles

ATPG Test Cycles

This section discusses ATPG test cycles that TetraMAX uses to generate a test pattern.

Sequence of ATPG Test Cycles

.................................................. Scan capture mode consists of at most six cycles, as shown below: ■

1st cycle:

Applies a test vector to primary inputs (PIs)

■

2nd cycle:

Observes test response at primary outputs (POs).

■

3rd cycle:

Pulses the system clock (capture operation).

■

4th cycle:

shadow_observe procedure (This cycle exists only when your design has observable shadow registers and you write the shadow_observe procedure in an SPF.)

■

5th cycle:

master_observe procedure (This cycle always exists for dual-clocked

scan design.) ■

6th cycle:

Sets bidirectional 3-state enables to their off state prior to scan-shifting.

The shadow_observe Procedure

.................................................. A shadow register is not in the scan chain, but is loaded when its master register in the scan chain is loaded. The shadow_observe procedure is used when a design has shadow registers and the shadow register’s outputs are observable at the scan cells to which they are shadows. The shadow_observe procedure defines how to set up paths from shadow registers back to scan cells. During design rules checking in DRC command mode, TetraMAX searches for non-scan cells that can be considered to be shadow registers. You can check the presence of shadow registers in a run drc transcript.

184

The master_observe Procedure

.................................................. The master_observe procedure is required only for the dual-clocked scan style. The dual-clocked scan flip-flop is made up of three latches, as shown in Figure 8–14. Of those latches, L2 and L3 function as master and slave latches. Scan Clock A is the master clock; Scan Clock B is the slave clock. Figure 8–14 highlights the data flow through the dual-clocked scan flip-flop. Figure 8–14 Data Flow Through Dual-Clocked Scan Flip-Flops Capture Operation Scan Flip-Flop

Scan Flip-Flop B A

L1

L2

L1

L2

System Clock Scan-in

Scan-out L3

L3

Scan Clock A Scan Clock B

In scan capture mode, functional data is captured into L2 by pulsing the system clock. Next, the flip-flop is put in scan shift mode. Basically, Scan Clock A and Scan Clock B are exercised repeatedly to shift the data through the scan chain. An important thing to be aware of here is that the captured data in L2 must be moved to L3 by pulsing Scan Clock B once before beginning the scan-shift sequence (A-B-A-B- ...). Otherwise the data in L2 will be overwritten and lost. This movement of data from master latches (L2) to slave latches (L3) is performed by the master_observe procedure. Figure 8–15 shows the waveform diagram for the dual-clocked scan design.

185

.....

Using TetraMAX ATPG 8.4 ATPG Test Cycles

8

Using TetraMAX ATPG 8.4 ATPG Test Cycles

Figure 8–15 Timing Diagram for the Dual-Clocked Scan Design shadow_ master_

load_unload

capture observe observe

load_unload

Scan Clock A

Scan Clock B

Scan-in

Scan-out 3. Pulse the system clock (capture).

System Clock 1. Force primary inputs.

Primary Inputs (PIs) 2. Measure primary outputs.

Primary Outputs (POs)

Merging Capture Cycles into a Single Cycle

..................................................

Whether in single- or dual-clocked scan design, the default capture procedure usually consists of three test cycles for applying inputs, observing outputs and pulsing the system clock, as shown below: capture_CLK { V{ "_pi"=#; } V{ "_po"=#; } V{ "CLK"=P; } }

186

//Apply primary inputs. //Observe primary outputs. //Pulse the system clock.

V{} represents a single test cycle. The following capture procedure, which is written within the Procedures construct, merges the three cycles into a single cycle. capture_CLK { V{ "_pi"=#; "_po"=#; "CLK"=P; } }

The Timing construct in an SPF must define the timing for _pi, _po and CLK in this order. Figure 8–16 Sample Timing Construct

Timing { WaveformTable "_default_WFT_" { Period ’100ns’; Waveforms { "_default_In_Timing_" { 0 { ’0ns’ D; } } "_default_In_Timing_" { 1 { ’0ns’ U; } } "_default_In_Timing_" { Z { ’0ns’ Z; } } "_default_In_Timing_" { N { ’0ns’ N; } } "_default_Clk0_Timing_" { P { ’0ns’ D; ’50ns’ U; "_default_Out_Timing_" { X { ’0ns’ X; } } "_default_Out_Timing_" { H { ’0ns’ X; ’40ns’ H; "_default_Out_Timing_" { T { ’0ns’ X; ’40ns’ T; "_default_Out_Timing_" { L { ’0ns’ X; ’40ns’ L;

’80ns’ D; } } } } } } } }

187

.....

Using TetraMAX ATPG 8.4 ATPG Test Cycles

8

8.5

Using TetraMAX ATPG 8.5 Running TFSA and LSF2DEF

Running TFSA and LSF2DEF

Overview

.................................................. Figure 8–17 illustrates the input and output files of TFSA and LSF2DEF. Figure 8–17 Input and Output Files of TFSA and LSF2DEF

TetraMAX

TSTL2

SCE

SPA

TFSA

FSA

TSC (Toshiba Sign-off System)

Testbench

Parallel-Load Simulation (PLS)

LSF

Scan-Chain Reordering (SCR) in conventional layout flow

LSF2DEF

SCRDEF

Scan-Chain Reordering (SCR) in layout-Verilog flow

Functions of TFSA Test patterns generated by TetraMAX must be simulated with timing. However, during a scan test, a scan input pattern is serially shifted in, and scan output response is evaluated by shifting data out serially. This means the actual number of test cycles is proportional to the length of the scan chain. With typical (serial-load) simulation, the runtime penalty is prohibitive. To slash simulation runtimes, a parallel-load simulation (PLS) can be employed.

188

Toshiba’s sign-off system supports parallel-load simulation. The sign-off system requires an FSA file to convert a TSTL2 file into a Verilog or VHDL description suitable for parallel-loading. The TFSA program in the Toshiba TetraMAX design kit is used to generate an FSA file. The FSA file contains information about scan flip-flops in a design. For PLS, see "Parallel-Load Simulation" on page 225. The TFSA program also allows you to generate an LSF file that describes the connections of cells in scan chains. The LSF file is used for scan-chain reordering (SCR) when place-and-route is performed using the conventional layout flow. For details on SCR, see Chapter 12, "Scan-Chain Reordering (SCR)," on page 301.

Functions of LSF2DEF When place-and-route is performed using the new layout-Verilog interface flow, an LSF file must be converted into an SCRDEF file for scan-chain reordering (SCR). To do this, use LSF2DEF contained in the Toshiba DFT design kit. For details on SCR, see Chapter 12, "Scan-Chain Reordering (SCR)," on page 301. Note: LSF2DEF is a Perl script that runs on Perl version 4 or above. To run LSF2DEF, set up the Perl environment.

Running TFSA

..................................................

Syntax To execute TFSA, enter the following command at a UNIX shell prompt. For a full description of the command syntax, input and output files, and error messages, see Chapter 10, "Toshiba TetraMAX Design Kit," on page 227. Note: To run TFSA, set up the VSO or VITALSO environment.

%> tfsa top_module_name [-verilog|-vhdl] [-lsf] [-chip] [-delimit character]

189

.....

Using TetraMAX ATPG 8.5 Running TFSA and LSF2DEF

8

Using TetraMAX ATPG 8.5 Running TFSA and LSF2DEF

Options -verilog|-vhdl Selects a sign-off system to be used. -lsf

Generates an LSF file. If omitted, only an FSA file is generated.

-chip

Generates a chip-level LSF file. This option is valid only when the -lsf option is specified. If you don’t give this option, TFSA generates an LSF file for block-based layout.

-delimit

Specifies the character used as the hierarchy delimiter when you changed it from the default / to another character in TetraMAX.

Command Input Example The following command is an example of running TFSA: %> tfsa TOP -lsf -delimit .

Running LSF2DEF

.................................................. Note: LSF2DEF is a Perl script that runs on Perl version 4 or above. To run LSF2DEF, set up the Perl environment.

Use LSF2DEF to convert an LSF file into an SCRDEF file required for scan-chain reordering in the layout-Verilog interface flow. To execute LSF2DEF, enter the following command at a UNIX shell prompt: %> lsf2def.pl top_module_name

The output SCRDEF file name will be design.scrdef.

190

8.6

Advanced Topics

Generating TetraMAX Memory Models

.................................................. To perform sequential ATPG for shadow logic around memory blocks, memory models are required. You can generate them with MDLGEN contained in the Toshiba sign-off system. 1. Create an MGDATA file to specify memory models to be generated. ■

When using the conventional layout flow ROMS1B ROMS1B RAMS2A RFS12A

■

WORD=256 WORD=512 WORD=256 WORD=256

BIT=8; BIT=16; BIT=8; BIT=10;

When using the new Layout-Verilog interface flow, use the keyword copy_count to specify the number of instances for ROMs. ROMS1B ROMS1B RAMS2A RFS12A

WORD=256 WORD=512 WORD=256 WORD=256

BIT=8 copy_count=1; BIT=16 copy_count=3; BIT=8; BIT=10;

2. Run MDLGEN. Specify tmax with the -target option. % mdlgen -tech TC240CT -target tmax -mg CKT.mgdata ■

When the conventional layout flow is used, memory model files will be named module_name.tmaxlib.

■

When the Layout-Verilog interface flow is used, RAM model files will be named module_name.tmaxlib, and ROM model files will be named module_name<sequence_number>.tmaxlib, like EOS1D0D4012A0001.tmaxlib, EOS1D0D4012A0002.tmaxlib, EOS1D0D4012A0003.tmaxlib, and so on.

3. When the Layout-Verilog interface flow is used, modify your netlist to reflect correct ROM module names. 4. Read in the library files generated by MDLGEN. For example: BUILD> read netlist -library EAS1A06G008A.tmaxlib

191

.....

Using TetraMAX ATPG 8.6 Advanced Topics

8

Using TetraMAX ATPG 8.6 Advanced Topics

Sequential ATPG

.................................................. TetraMAX allows you to perform sequential ATPG with a capture cycle depth of 2 to 10. Sequential ATPG (Fast-Sequential ATPG) is effective for designs with megacell models and non-scan latches. Disadvantages of sequential ATPG include long runtimes and increased pattern sizes. A capture cycle depth of zero causes only combinational ATPG (Basic-Scan ATPG) to be performed. Don’t use a large value in the first run of ATPG; doing so might lower fault coverage results. Run sequential ATPG as follows. 1. First, run combinational ATPG. TEST> set atpg -capture_cycles 0 TEST> run atpg -auto

2. The following command reports the maximum sequential depth in your design. TEST> report summaries sequential_depths

3. Set the capture cycle depth to maximum sequential depth plus 1. TEST> set atpg -capture_cycles <max_depth>+1 TEST> run atpg -fast_sequential_only

4. If the fault coverage results are not satisfactory, increase the capture cycle depth by one and rerun ATPG.

Recommended Flow for Running Sequential ATPG with Memory Models

..................................................

This section introduces the recommended flow for performing sequential ATPG using memory models.

192

1. First, run combinational ATPG. Identify all memory modules as black boxes, as follows: BUILD> set build -black_box EAS1D06G008A BUILD> set build -black_box EF12D06G008A .... TEST> run atpg

2. Save ATPG patterns, and create a fault list of undetected faults, as shown below: TEST> write faults DEMO_cmb.flt -class PT \ -class UD -class AU -class ND TEST> write patterns DEMO_cmb.tst -format tstl2 \ -internal -replace TEST> write patterns DEMO_cmb.bin -format binary \ -internal -replace

3. Quit TetraMAX once. TEST> quit -force

4. Restart TetraMAX and read in memory model files. This time, don’t set memory modules to black boxes. BUILD> read netlist -library EAS1D06G008A.tmaxlib BUILD> read netlist -library EF12D06G008A.tmaxlib

5. Read in the fault list. The next sequential ATPG run tries to generate test patterns for faults that were not detected by combinational ATPG to shorten the runtime. TEST> read faults DEMO_cmb.flt

193

.....

Using TetraMAX ATPG 8.6 Advanced Topics

8

Using TetraMAX ATPG 8.6 Advanced Topics

6. Run sequential ATPG using the flow described in the previous section. If fault coverage results are not satisfactory, rerun sequential ATPG with a larger capture cycle depth. TEST> set atpg -capture_cycles 3 TEST> run atpg

7. Save the test patterns. TEST> write patterns DEMO_seq.bin -format binary \ -internal -replace TEST> write patterns DEMO_seq.tst -format tstl2 \ -internal -replace

Figure 8–18 shows the entire flow for using sequential ATPG effectively and efficiently. The commands given above are highlighted in boldface. Figure 8–18 Flow for Using Sequential ATPG //Combinational ATPG BUILD> read netlist -library $TOSH_ROOT/lib/tmax/TC260CP/TC260CP.tmaxlib BUILD> read netlist DEMO.v BUILD> set build -black_box EAS1D06G008A BUILD> set build -black_box EF12D06G008A BUILD> run build TOP DRC> run drc DEMO.spf TEST> run atpg -auto TEST> write faults DEMO_cmb.flt -class PT -class UD -class AU -class ND TEST> write patterns DEMO_cmb.bin -format binary -internal -replace TEST> write patterns DEMO_cmb.tst -format tstl2 -internal -replace TEST> quit -force //Sequential ATPG BUILD> read netlist -library $TOSH_ROOT/lib/tmax/TC260CP/TC260CP.tmaxlib BUILD> read netlist -library EAS1D06G008A.tmaxlib BUILD> read netlist -library EF12D06G008A.tmaxlib BUILD> read netlist DEMO.v BUILD> run build TOP DRC> run drc DEMO.spf TEST> read faults DEMO_cmb.flt TEST> set atpg -capture_cycles 3 TEST> run atpg fast_sequential_only TEST> set atpg -capture_cycles 5 TEST> run atpg fast_sequential_only TEST> write patterns DEMO_seq.bin -format binary -internal -replace TEST> write patterns DEMO_seq.tst -format tstl2 -internal -replace TEST> quit -force

194

Test Coverage Calculations When Megacell Models Are Used

..................................................

Test coverage calculations are different when megacell models are used during ATPG. The following shows the equations for obtaining fault coverage, test coverage and testable fault coverage. Table 8–1 summarizes the symbols used in the equations. Table 8–1 Fault Classes Used in Test Coverage Calculations Symbol

DT_comb

Meaning

Number of faults detected by combinational ATPG

DT_seq

Number of faults detected by sequential ATPG

All_Fault_comb

Number of all faults targeted by combinational ATPG

UD_seq

Number of faults classified into the UD (undetected fault) class by sequential ATPG

AN_seq

Number of faults classified into the AN (ATPG undetectable) class by sequential ATPG

■

Fault coverage Fault coverage is the percentage of faults detected by combinational and sequential ATPG runs out of all faults. DT_comb + DT_seq Fault Coverage = --------------------------------------------------- × 100 All_Fault_comb

■

Test coverage Test coverage is the percentage of faults detected by combinational and sequential ATPG runs out of all faults minus those that are meaningless to fault during sequential ATPG. DT_comb + DT_seq Test Coverage = ----------------------------------------------------------------- × 100 All_Fault_comb – UD_seq

■

Testable fault coverage Testable fault coverage is the percentage of faults detected by combinational and sequential ATPG runs out of all faults minus those undetectable by sequential ATPG due to your ATPG constraint setups. DT_comb + DT_seq Testable Fault Coverage = ------------------------------------------------------------------------------------------ × 100 All_Fault_comb – UD_seq – AN_seq

195

.....

Using TetraMAX ATPG 8.6 Advanced Topics

8

Using TetraMAX ATPG 8.6 Advanced Topics

Estimating the TSTL2 File Size

.................................................. For a large, complex design, the generated TSTL2 file can be huge. This section describes how to estimate the size of a TSTL2 file that will be generated. These factors affect the resulting file size: ■

Number of scan chains (n)

■

Length of each scan chain (len0 to lenn-1)

■

Number of I/O pins (pin)

■

Number of generated ATPG patterns (pat)

The file size is calculated as follows: Scan flip-flop count n–1 n–1  File Size =  ∑ len k × ( pat + 1 ) × 2 + ( pin × pat × α ) + Header + ∑ len k × 8 k = 0  k=0

Scan-shift mode

Scan capture mode TSTL2 header

(bytes)

Shift test

■

The first term is related to scan shift cycles.

■

The second term is related to scan capture cycles.

■

The third term is related to the TSTL2 header statements.

■

The fourth term is related to a shift test (i.e., a test on scan chains themselves performed prior to scan test)

α in the second term indicates the number of cycles required per scan capture mode operation. It depends on your ATPG setups and is normally 2 to 5. For large designs, the first term (i.e., scan-shifting) contributes to a majority of the total file size. Thus, the above equation can be approximated as follows: n–1

FileSize = ∑ len k × ( pat + 1 ) × 2

(bytes)

k=0

≈ (total_sum_of_scan_chain_lengths) × pattern_count × 2 For example, if your design has 35-k scan flip-flops and TetraMAX generated 1,300 patterns for it, the resulting TSTL2 file size is estimated as: 35k × (1300 + 1) × 2 = 91 (MB)

196

Disk Space Required for TSTL2 Conversion

..................................................

When you run the write patterns -format tstl2 command, TetraMAX first creates a pattern file in WGL format, then invokes Ltran to convert it into TSTL2 format. Ltran generates three temporary files, which together will be as huge as the resulting TSTL2 file. So that TSTL2 generation will successfully complete, sufficient free disk space is required to accommodate the following files: ■

WGL file

■

Three Ltran temporary files

■

TSTL2 file

Therefore, to write out a TSTL2 file, you need a disk space three times a TSTL2 file size estimate. Figure 8–19 shows the results for an actual design with 35-k scan flip-flops and 1,300 patterns. Figure 8–19 Files Generated in the Course of TSTL2 Generation 110427950

design.tst_wgltmp

94427548

_vread1.trc.3505

Intermediate file from Ltran

3860428

_vread1.vec.3505

Intermediate file from Ltran

3860043

x_vtran.vec.3505

Intermediate file from Ltran

design.tst

Final TSTL2 file (96 MB)

96612488

WGL file from TetraMAX (110 MB)

197

.....

Using TetraMAX ATPG 8.6 Advanced Topics

8

8.7

Using TetraMAX ATPG 8.7 Known Problems

Known Problems

Writing Out a TSTL2 File in the TetraMAX Shell Mode

..................................................

If you give the -shell option when starting TetraMAX, it is launched in Shell mode instead of GUI mode.

TetraMAX 2002.05 and Above By setting the environmental variable LTRAN_SHELL to 1, you can have TetraMAX generate TSTL2 files without opening an Xterm window even in Shell mode. Enter as follows to invoke TetraMAX: %> setenv LTRAN_SHELL 1 %> tmax -shell command_file

TetraMAX 2001.08-SP1 and Earlier Even in Shell mode, the write patterns -format tstl2 command always launches the Xterm window to run Ltran. If the DISPLAY environment variable is not set correctly, an attempt to start Xterm fails. Note that, even in this case, TetraMAX does not issue an error message. When you use a command file for your ATPG run, be sure to set the DISPLAY variable and the path to Xterm before invoking TetraMAX. %> setenv DISPLAY display_name %> set path = (/usr/openwin/bin $path) %> tmax -shell command_file

Instance Names Including Slash (/) Characters (Verilog-HDL Only)

..................................................

The default hierarchical delimiter in TetraMAX is the slash (/) character. Therefore, instance names must not include any slash character. To avoid a problem, do either one of the following:

198

■

Disable use of the slash character in DFT Compiler.

■

Change the hierarchical delimiter to the dot (.) character by using the TetraMAX set build -hierarchical_delimiter command.

Comma (,) Characters in the Library Clause (VHDL Only)

..................................................

If your VHDL description file contains any comma (,) characters in the library clause, TetraMAX can not read in the library. To avoid this problem, specify one library with each library clause. ■

Wrong library IEEE, tc220c;

■

Correct library IEEE; library tc220c;

199

.....

Using TetraMAX ATPG 8.7 Known Problems

8

200

Using TetraMAX ATPG 8.7 Known Problems

Chapter 9

Validating the Scan Structure and ATPG Test Vectors .....

.....................................

T

his chapter describes how to evaluate the quality of your scan implementation and generated test patterns. The material is organized into the following sections. Note: This manual assumes that you use TSTL2 to write test patterns. If you want to use the Standard Tester Interface Language (STIL), contact your Toshiba design center engineer.

☞ Key Decision Criteria for Quality of Results ☞ Scan Design Rule Checking ☞ Verifying the ATPG Patterns

201

9

9.1

Validating the Scan Structure and ATPG Test Vectors 9.1 Key Decision Criteria for Quality of Results

Key Decision Criteria for Quality of Results

Today’s design teams work on sub-blocks in parallel. Ideally, it is best to run ATPG at the chip level before you decide you have reached ultimate DFT closure on your sub-block. However, you may need to complete your own sub-block before all the other sub-blocks are made available. In such cases, you should perform a trial ATPG on your sub-block to obtain a quick estimate of possible fault coverage and validate its test timing. This is necessary to ensure that your sub-block will not adversely affect chip-level testability when it is eventually embedded in the entire chip environment.

Principal Criteria for Final Scan Synthesis Closure

..................................................

Output Files Ensure that you have these files ready: ■

Test DRC reports • Transcript from the DFT Compiler check_test command • Transcript from the DFT Compiler report_test command • Transcript from the TetraMAX run drc command

■

SPF

Scan Design Rule Checking Ensure there are no design rule checking problems related to the following, at the time of scan synthesis and prior to ATPG.

202

■

Scan chains

■

Sequential cells

■

Internal 3-state buses

■

Bidirectional pins

■

Combinational feedback loops

Obtaining Quick Test Coverage Estimates Certain types of design rule violations, e.g., those on latches and feedback loops, invariably lower fault coverage. You can add test mode control logic to disable circuitry that causes design rule violations. However, the test mode control logic itself also affects fault coverage, as it blocks fault propagation. Therefore, to get a design closure on a sub-block, it is recommended to run ATPG on a random sample of faults to obtain an quick estimation of fault coverage.

Timing Verification You must perform timing verification at the chip level using the test timing. This is not a part of the scan synthesis process, but if the design does not work, you need to modify your design and rerun scan synthesis.

Principal Criteria for Final ATPG Closure

..................................................

Output Files Ensure that you have these files ready: ■

Transcript from the TetraMAX run drc command

■

ATPG test vector files Write out the generated patterns to four files as follows: • • • •

Chain test (patterns related to testing scan chains; also known as a shift test) First 10 ATPG patterns Last 10 ATPG patterns Full scan test patterns

■

ATPG log or fault summary report (including fault coverage results)

■

Detected fault report (optional)

203

.....

Validating the Scan Structure and ATPG Test Vectors 9.1 Key Decision Criteria for Quality of Results

9

Validating the Scan Structure and ATPG Test Vectors 9.1 Key Decision Criteria for Quality of Results

Scan Design Rule Checking Before deciding you have reached ATPG closure, examine the transcript from the TetraMAX run drc command to ensure there are no design rule checking problems related to the following. ■

Internal buses and external bidirectional pins

■

Test protocol procedures

■

Scan chain tracing

■

Clocks and clocked elements

■

Non-scan storage elements

■

Multidriver nets

■

Combinational feedback loops

Verifying Final ATPG Test Vectors Determine that the test vector functionality and timing match the predicted behavior from the ATPG. 9.3, "Verifying the ATPG Patterns," discusses vector verification.

204

■

Verify the functions of the chain test file and the ATPG pattern files, using a typical (i.e., serial-load) simulation method.

■

Verify the timing of the ATPG pattern files at the test timing.

9.2

Scan Design Rule Checking

You can perform test design rule checking (DRC) with both scan synthesis and ATPG tools. To weed out testability problems early in the design cycle, it is strongly recommended to check the design rules during the scan synthesis process. This section describes how to evaluate the DRC results from DFT Compiler and TetraMAX.

Test DRC Using DFT Compiler

..................................................

The check_test and report_test Commands During the scan synthesis process, use the check_test command to perform test design rule checking (DRC). Design rule checking can occur only at the gate level; so check the design rules right after the first compile (i.e., once your design is synthesized to gates) and after you have a fixed gate-level design. The report_test command allows you to generate detailed scan-related reports. Run the check_test command before report_test because check_test is an essential preprocess to guarantee that the reports from report_test are correct.

Scan Chains The check_test command reports design rule violations related to scan chains. Figure 9–1 shows a fragment of a check_test transcript. It describes potential problems with the scan chain. Figure 9–1 Transcript of check_test with Scan Chain Rule Violations Warning: Input pin SI of cell iii[1]/REG_A_reg_8 (FD4SFP) is unconnected. It is assumed ’X’ for the purpose of test. (TEST-332) ...basic sequential cell checks... ...checking combinational feedback loops... ...inferring test protocol... Information: Inferred test clock port SCONA (30.0,40.0). (TEST-260) Information: Inferred system/test clock port SCONB (60.0,70.0). (TEST-260) Information: Inferred system clock port CLK (45.0,55.0). (TEST-260) ...simulating parallel vector... ...simulating parallel vector... ...simulating serial scan-in... ...8 bits scanned-in to 8 cells (total scan-in 8)...

205

.....

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

9

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

...simulating parallel vector... ...binding scan-in state... Warning: Cell iii[1]/REG_A_reg_8 (FD4SFP) is not scan controllable. (TEST-302) Information: Because it clocks in an unknown value from pin SI. (TEST-512) Information: Because input pin SI of cell iii[1]/REG_A_reg_8 (FD4SFP) is unconnected. (TEST-526) ... ************************************************** Sequential Cell Summary 82 out of 82 sequential cells have violations ************************************************** SEQUENTIAL CELLS WITH VIOLATIONS * 82 cells have scan shift violations * 74 cells are not scan controllable * 8 cells are not scan observable * 1 cell is an identified cause of other reported violations

After running check_test, you can run the report_check command to generate detailed scan-related reports. To obtain information about existing scan chains in a design, enter the following command: dc_shell> report_test -scan_path

Figure 9–2 is a partial sample of a report generated when the design has a complete scan chain. Figure 9–2 Report on a Complete Scan Chain

**************************************** Report : test -scan_path Design : DEMO8 Version: 1999.05 Date : Fri Feb 11 15:16:36 2000 **************************************** (*) (c) (o) (x)

indicates indicates indicates indicates

change of polarity in scan data cell is scan controllable only cell is scan observable only cell cannot capture

Complete scan chain (DII0 --> DOO0) contains 82 cells: DII0 -> iii[1]/REG_A_reg_0 -> iii[1]/REG_A_reg_1 -> iii[1]/REG_A_reg_2 -> ...

206

The instance names of the flip-flops are not followed by error indicators.

Check the scan chain report to determine: ■

that all scan chains are reported as "Complete scan chain" connected from a scan-in port to a scan-out port.

■

that no scan flip-flop has an error flag such as (c) or (o) attached to it.

The report shown in Figure 9–3 identifies two incomplete scan chains, along with scan flip-flops that are only scan-controllable or only scan-observable. Figure 9–3 Report on Incomplete Scan Chains **************************************** Report : test -scan_path Design : DEMO8 Version: 1999.05 Date : Fri Feb 11 15:25:11 2000 **************************************** (*) (c) (o) (x)

indicates indicates indicates indicates

change of polarity in scan data cell is scan controllable only cell is scan observable only cell cannot capture

Incomplete scan chain (DII0 --> iii[1]/REG_A_reg_7) contains 8 cells: DII0 -> iii[1]/REG_A_reg_0 iii[1]/REG_A_reg_1 iii[1]/REG_A_reg_2 iii[1]/REG_A_reg_3 iii[1]/REG_A_reg_4 iii[1]/REG_A_reg_5 iii[1]/REG_A_reg_6 iii[1]/REG_A_reg_7

(c) (c) (c) (c) (c) (c) (c) (c)

-> -> -> -> -> -> -> ->

The instance names of the flip-flops are followed by error indicators.

Incomplete scan chain (iii[1]/REG_A_reg_8 --> DOO0) contains 74 cells: iii[1]/REG_A_reg_8 iii[1]/REG_A_reg_9 iii[1]/REG_B_reg_0 iii[1]/REG_B_reg_1 ...

(o) (o) (o) (o)

-> -> -> ->

Sequential Cells At the end of the check_test output, DFT Compiler provides a summary of the test status of sequential cells in your design, as shown in Figure 9–4.

207

.....

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

9

Figure 9–4 Sequential Cell Summary in the check_test Output ... ************************************************** Sequential Cell Summary No sequential cell has design rule violations. 0 out of 5 sequential cells have violations ************************************************** SEQUENTIAL CELLS WITHOUT VIOLATIONS * 3 cells are valid scan cells * 2 cells are transparent_latches : test

...

Of the sequential cells without violations, 3 cells are valid scan cells, but 2 cells are not.

Within the summary, sequential cells are divided into two categories: those with violations and those without. Although the report shown in Figure 9–4 says there is no sequential cell with violations, two sequential cells are transparent latches, not "valid scan cells." These latches might affect test coverage results; to ensure your fault coverage goal will be satisfied, it is recommended to perform a trial ATPG on a sample of faults.

Internal 3-State Buses To generate a report that identifies 3-state nets with ATPG conflicts, run the following command. dc_shell> report_test -atpg_conflicts

Note: TetraMAX might not be able to identify all 3-state violations. Be sure to check for bus conflict and float conditions through simulation.

Bidirectional Ports Check the check_test transcript to ensure that all bidirectional pins are forced to input mode during scan-shifting. Figure 9–5 shows a report summary with a violation message. Figure 9–5 Bidirectional Port Violation ************************************************** Test Design Rule Violation Summary Total violations: 3 ************************************************** PROTOCOL VIOLATIONS 3 net (connected to bidirectional port) with unknown 3-state driver mode violations (TEST-563)

208

Remember, even if your design has no problem, you will get bidirectional port violations unless you correctly set the Scan Shift Enable port with the set_signal_type command prior to check_test.

Combinational Feedback Loops Check the check_test transcript to ensure that your design has no combinational feedback loop. Figure 9–6 shows messages from check_test identifying cells in a combinational feedback loop. Figure 9–6 Messages from check_test About Combinational Feedback Loop Warning: Combinational feedback loop broken at pin B of cell mult32g/control/U31 (GNR2X1). (TEST-117) Information: The loop contains: mult32g/control/U40/D, mult32g/control/U40/Z, mult32g/control/current_reg[0]/D, mult32g/control/current_reg[0]/Q, mult32g/control/U42/A, mult32g/control/U42/Z, mult32g/control/U31/B, mult32g/control/U31/Z, mult32g/control/U38/B, mult32g/control/U38/Z, mult32g/control/U35/B, mult32g/control/U35/Z, mult32g/control/current_reg[2]/D, mult32g/control/current_reg[2]/Q. (TEST-175) ... ************************************************** Test Design Rule Violation Summary Total violations: 16 ************************************************** TOPOLOGY VIOLATIONS 16 Combinational feedback loop violations (TEST-117) ... ♦ Schematic of mult32g/control U35

current_reg[2]

U38

U40

current_reg[0]

U31

U42

Transparent latches specified by set_scan_transparent

To perform pattern generation, the combinational feedback loop must be disabled through constant logic values or injection of unknown (X) values. This lowers possible fault coverage results. To evaluate the fault coverage impact, it is recommended to perform a trial ATPG on a sample of faults. If the impact is significant, break the loop by using a test mode signal.

209

.....

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

9

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

The design in Figure 9–6 has two latches defined with the set_scan_transparent command. If you don’t specify these latches as transparent, a loop is not completed. However, that does not provide a solution to the fault coverage problem because more nets end up assuming X values during ATPG.

Test DRC Using TetraMAX

.................................................. In TetraMAX, use the run drc command in DRC command mode to perform test design rule checking. If it doesn’t complete successfully, TetraMAX won’t move to TEST command mode. In other words, you must fix all rule violations before you can perform ATPG.

Categories and Severity Levels of Test Design Rules ■

Test design rule categories Test design rules are organized into seven major categories: • • • • • • •

■

B (Build rules) C (Clock rules) N (Netlist rules) S (Scan trace rules for scan chain operation) V (Vector rules) X (X state rules) Z (3-state rules)

Test design rule severity Each design rule is assigned one of the four severity levels by default: • • • •

210

Ignore Warning Error Fatal

The rule is not checked, and no message is issued. A warning message is issued, and the DRC run is continued. An error message is issued, and the DRC run is aborted. Same as Error except that the severity level can not be changed.

Running the run drc Command Before issuing the run drc command, declare clock input ports and primary input constraints and create an SPF. The syntax of the run drc command is: DRC> run drc SPF_filename

The run drc command displays a series of messages. Figure 9–7 shows its processing flow. Figure 9–7 Processing Flow of the run drc command run drc SPF_filename

Bus contention/float checking

Simulation of test protocol procedures

Scan chain operation checking Clock rule checking Non-scan rule checking

Multidriver net checking Additional circuit learning (e.g., feedback path sensitization checking)

Summary generation

Bus Contention/Float Checking The run drc command first checks buses to identify any drivers that could potentially cause bus conflicts (contentions) and floating (Z-state) bus conditions. Figure 9–8 shows a fragment of the run drc transcript regarding the bus contention/float checking.

211

.....

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

9

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

Figure 9–8 Summary Report from the Bus/Wire Contention Ability Checking --------------------------------------------------------------------------Begin Bus/Wire contention ability checking... Bus summary: #bus_gates=30, #bidi=30, #weak=0, #pull=0, #keepers=0 Contention status : #pass=0, #bidi=30, #fail=0, #abort=0, #not_analyzed=0 Z-state status : #pass=0, #bidi=30, #fail=0, #abort=0, #not_analyzed=0 Bus/Wire contention ability checking completed, CPU time=0.05 sec. ---------------------------------------------------------------------------

In Figure 9–8, the "Bus summary" line provides the following information: ■

#bus_gates the total number of bus gates in your design

■

#bidi

the number of bus gates with external bidirectional ports

■

#weak

the number of bus gates that have "weak" inputs

■

#pull

the number of bus gates with pull-up or pull-down resistor

■

#keepers

the number of bus gates connected to a bus keeper

TetraMAX treats all 3-state devices as buses, including both internal and external buses. In the above example, the design has 30 bus gates, all of which are external bidirectional ports. Based on the results of this checking, bus gates are assigned one of the contention and Z-state status types: ■

#pass

the number of bus gates that can never be in a contention or Z-state condition.

■

#fail

the number of bus gates that can be in a contention or Z-state condition.

■

#abort

the number of bus gates for which TetraMAX couldn’t determine pass/fail classifications.

TetraMAX can not correctly control bus gates classified as "abort." Because these bus gates introduce unpredictable logic values, you should modify your design to eliminate them. For bus gates classified as "fail," TetraMAX discards any patterns that result in a contention or Z state, yet at the expense of a longer runtime and a lower fault coverage. Note: TetraMAX might not be able to identify all 3-state violations. Be sure to check for bus conflict and float conditions through simulation.

Bus Keepers If decode logic is not designed properly, bus gates can cause floating (Z-state) bus conditions. You can use a bus keeper so that a bus retains the last value driven on it to avoid a Z state.

212

Figure 9–9 shows a report generated for a design in which a bus has no bus keeper on it; the "Z-state status" line indicates the presence of one failing bus, which is accompanied by a Z2 violation warning message. Figure 9–9 Report for a Bus without a Bus Keeper --------------------------------------------------------------------------Begin Bus/Wire contention ability checking... Bus summary: #bus_gates=2, #bidi=1, #weak=0, #pull=0, #keepers=0 Contention status: #pass=1, #bidi=1, #fail=0, #abort=0, #not_analyzed=0 Z-state status : #pass=0, #bidi=1, #fail=1, #abort=0, #not_analyzed=0 Warning: Rule Z2 (bus capable of holding Z state) was violated 1 times. Bus/Wire contention ability checking completed, CPU time=0.00 sec. ---------------------------------------------------------------------------

Although TetraMAX discards any patterns that result in a Z state, bus gates classified as "fail" cause a longer runtime and lower fault coverage. Figure 9–10 shows a report for a design in which a bus has a bus keeper attached to it. The bus that was previously classified as "fail" without a bus keeper is now classified as "pass." Figure 9–10 Report for a Bus with a Bus Keeper --------------------------------------------------------------------------Begin Bus/Wire contention ability checking... Bus summary: #bus_gates=2, #bidi=1, #weak=0, #pull=1, #keepers=1 Contention status: #pass=1, #bidi=1, #fail=0, #abort=0, #not_analyzed=0 Z-state status : #pass=1, #bidi=1, #fail=0, #abort=0, #not_analyzed=0 Bus/Wire contention ability checking completed, CPU time=0.01 sec. ---------------------------------------------------------------------------

Simulating Test Protocol Procedures The run drc command simulates test protocol procedures in an SPF to determine the logic states of non-scan flip-flops and latches during ATPG. Figure 9–11 shows a report from a procedure simulation. Figure 9–11 Report from a Procedure Simulation Begin simulating test protocol procedures... Nonscan cell constant value results: #constant0 = 940, #constant1 = 72 Nonscan cell load value results : #load0 = 940, #load1 = 72 Warning: Rule Z4 (bus contention in test procedure) was violated 160 times. Warning: Rule Z5 (bidi pin not at input mode) was violated 120 times. Test protocol simulation completed, CPU time=6.97 sec.

213

.....

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

9

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

Scan Chain Operation Checking The run drc command simulates each scan chain as defined by test procedures to determine that it operates correctly and complies with a set of scan trace rules. During scan chain tracing, TetraMAX performs the following: 1. Initializes constrained ports to the specified values 2. Simulates the test_setup macro 3. Simulates the load_unload procedure 4. Simulates the Shift procedure to ensure: • that the scan data path is valid; • that the scan cells are synchronously clocked; and • that asynchronous set/reset pins are in their off states. Figure 9–12 shows a fragment of the report regarding scan chain operation. Figure 9–12 Report from Scan Chain Operation Checking Begin scan chain operation checking... Chain IN1 successfully traced with 18503 scan_cells. Warning: Rule S19 (nonscan cell disturb) was violated 25 times. Scan chain operation checking completed, CPU time=2.87 sec.

TetraMAX verifies the scan chain operation simultaneously while simulating test procedures. As each scan chain is simulated, TetraMAX displays the scan chain name and its length (or the number of scan cells in it).

Clock Rule Checking The run drc command checks all clocks against the clock rules. Figure 9–13 shows a report from the clock rule checking with three warning messages. Figure 9–13 Report from Clock Rule Checking Begin clock rules checking... Warning: Rule C2 (unstable nonscan DFF when clocks off) was violated 25 times. Warning: Rule C3 (no latch transparency when clocks off) was violated 440 times. Warning: Rule C15 (scan cell port unable to capture) was violated 102276 times. Clock rules checking completed, CPU time=17.58 sec.

214

Non-Scan Rule Checking The run drc command analyzes all non-scan storage elements, including: ■

Non-scan D-type flip-flops

■

Latches

■

RAMs

■

ROMs

■

Bus keepers

These cells hold state. Latches that can be put in transparent mode are identified, and latches that can not be made transparent are replaced by TIEX logic that always outputs an unknown (X) value. Figure 9–14 shows a report from non-scan rule checking. Figure 9–14 Report from Non-Scan Rule Checking Begin nonscan rules checking... Nonscan cell summary: #DFF=233 #DLAT=51619 tla_usage_type=hot_clock_tla Nonscan behavior: #CX=25 #C0=940 #C1=72 #TLA=50175 #LE=162 #TE=38 #LS=440 Nonscan rules checking completed, CPU time=0.95 sec.

The second line gives the number of D-type flip-flop (DFF) and latch (DLAT) primitives as well as the latch usage type (tla_usage_type). Use this summary as a basis to determine if you need to do something about non-scan flip-flops.

Multidriver Net Checking The run drc command analyzes the multidriver nets previously identified as potentially causing bus contentions. The purpose of this step is to determine which drivers actually cause bus contentions. Figure 9–15 shows a report from this checking. Figure 9–15 Report from Multidriver Net Checking Begin contention prevention rules checking... 163 scan cells are connected to bidirectional BUS gates. Warning: Rule Z9 (bidi bus driver enable affected by scan cell) was violated 19 times. Contention prevention checking completed, CPU time=0.03 sec.

The first message tells that 163 scan cells connected to bidirectional bus gates were identified. As a result, rule Z9 was violated 19 times.

215

.....

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

9

Validating the Scan Structure and ATPG Test Vectors 9.2 Scan Design Rule Checking

Feedback Path Sensitization Checking During the additional circuit learning process, the run drc command analyzes feedback loops to determine whether they can be logically broken by the Scan Test Enable signal. If it can not find a set of Scan Test Enable values to break a loop, run drc issues an X1 violation. Figure 9–16 shows a report from the feedback loop checking. Figure 9–16 Report from Feedback Loop Checking Begin feedback path sensitization checking... Feedback path rules checking completed for 1 loops, CPU time=0.53 sec.

In this example, one feedback loop was detected, and it has no violation.

Analyzing DRC Violations To analyze design rule violations, use the following steps: 1. To see the number of each class of violations, run the following command: DRC> report rules -fail

For more detailed information about the DRC violations in your design, enter: DRC> report violations -all

2. To view detailed help on a specific violation, use the man command as follows: DRC> man rule_violation_id

For example: DRC> man z4

3. You can visually inspect violations by using the Graphical Schematic Viewer (GSV). The GSV displays a schematic, zooming in on the logic gates involved in a particular violation, along with any useful diagnostic information.

216

9.3

Verifying the ATPG Patterns

ATPG doesn’t simulate timing events in a design. Therefore, you must verify through simulation that the generated patterns function correctly. To facilitate scan-pattern verification, save ATPG patterns in four files, as follows: ■

Chain test (also known as shift test)

■

First 10 or so ATPG patterns

■

Last 10 or so ATPG patterns

■

Full scan test patterns

Performing Full-Timing Simulation

.................................................. To perform full-timing simulation, use one of the Toshiba sign-off systems such as VSO and VITALSO. 1. Validate the chain test file by a typical (serial-load) simulation. The chain test shifts a sequence of 1s and 0s into a scan chain and examines the response at the scan-out pin to determine that the scan chain itself operates properly. 2. Validate the first 10 (or so) and last 10 (or so) ATPG patterns by a typical (serial-load) simulation. Since most of the simulation time is spent shifting data along the scan chain, you only need to simulate first 10 or so ATPG patterns and last 10 or so ATPG patterns to detect gross errors. You can create these pattern files by manually cutting out a subset of patterns to separate files, or by using the -first and -last options of the write patterns command. Generally, TetraMAX generates scan test patterns in two or more stages; thus first and last patterns are derived using different methods. That’s why scan test patterns are sampled from two different locations. 3. Validate the full scan test patterns by a parallel-load simulation. Simulating the serial shifting of scan chains is very time-consuming. Therefore, ATPG patterns are converted into a parallel-load testbench that directly loads and unloads scan

217

.....

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

9

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

flip-flops in parallel instead of performing a complete serial load. For the parallel-load simulation (PLS) flow, see the section "Parallel-Load Simulation" on page 225.

Using HSS

.................................................. For a huge design, full-timing simulation can exceed the memory and performance capacity of your sign-off simulator. In that case, you can use the HSS (High-Speed Simulation) System which provides runtime and capacity advantages by focusing on the circuit’s function with no concern for timing. The purpose of HSS is to provide an efficient design flow by separating functional and timing aspects of verification. For timing verification, an STA tool provides a full accuracy along with short runtimes and large capacities required by designers implementing large designs. HSS uses less elaborate or zero-delay models to speed up simulation. It supports both Verilog and VHDL simulations. For details on HSS, refer to the High-Speed Simulation (HSS) System User Guide. HSS is not a replacement for sign-off simulation. Therefore, HSS can not exist by itself in a sign-off flow; it only complements full-timing simulation by a Toshiba-certified sign-off simulator or static timing analysis. When performing simulation with HSS, follow the same steps as described in the previous section: 1. Validate the chain test file by a typical (serial-load) simulation. 2. Validate the first 10 (or so) and last 10 (or so) ATPG patterns by a typical (serial-load) simulation. 3. Validate the full scan test patterns by a parallel-load simulation.

Timing Verification Using an STA Tool

.................................................. Using an event-driven simulator incurs a significant runtime penalty on complex designs. To facilitate timing verification and debugging, it is recommended to verify the scan test timing by means of an STA tool such as PrimeTime.

218

General STA Tool Considerations These considerations relate to the timing verification of a scanned design using PrimeTime: ■

Don’t set any mutlicycle paths in normal mode of operation.

■

Perform a case analysis for scan test mode by setting certain test control pins to a constant value.

■

Create an SDF file with your tester conditions and set the tester’s input skew and output strobe margins.

■

Verify the circuit’s operation in scan shift and capture modes separately.

■

If your design has more than one clock group, verify the circuit’s scan capture mode operation group by group.

If you don’t know the tester conditions, run DCAL without using an IOPARAM file when generating an SDF (DCSDF) file.

Timing Verification of the Single-Clocked Scan Design Figure 9–17 illustrates the test timing for the single-clocked scan design. Figure 9–17 Test Timing for the Single-Clocked Scan Design ■

TSTL2 timing definition block TIMING TS1 ; CYCLE 100 ; TIMESET(0) DT 0 ; TIMESET(1) DT 5 ; TIMESET(2) PP, 45, 10 ; TIMESET(7) STB, 40 ; ENDTIM ; 100 ns Inputs TIMESET(0)

5 ns

Input-Mode Bidirects TIMESET(1) Output Strobe TIMESET(7)

40 ns

System/Scan Clock TIMESET(2)

45 ns

10 ns

Virtual Clock Multicycle Paths: (40 ns + 1cycle period) – 45 ns

219

.....

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

9

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

Figure 9–18 shows a sample script for verifying scan shift mode operation. Figure 9–19 shows a sample script for verifying scan capture mode operation. The assumptions are: ■

Primary ports • • • • • •

Input pin: Bidirectional pin: Output pin: Clock pins: Scan Test Enable pin: Scan Shift Enable pin:

■

Tester input skew: ±1 ns

■

Clock groups • Group 1: • Group 2:

DI1 DB1 DO1 CLK1, CLK2, CLK3 TEN (active-high) SEN (active-high)

CLK1 CLK2, CLK3

Figure 9–18 Sample Script for Scan Shift Mode Verification create_clock -period 100.0 -waveform {0 50.0} -name VCLK # Define all clocks for scan shift mode verification. create_clock -period 100.0 -waveform {45.0 55.0} CLK1 create_clock -period 100.0 -waveform {45.0 55.0} CLK2 create_clock -period 100.0 -waveform {45.0 55.0} CLK3 set_clock_uncertainty 1.0 -from VCLK -to CLK1 set_clock_uncertainty 1.0 -from VCLK -to CLK2 set_clock_uncertainty 1.0 -from VCLK -to CLK3 set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -min -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 6.0 DB1 set_input_delay -clock VCLK -min 4.0 DB1 set_output_delay -clock VCLK -max 61.0 [all_outputs] set_output_delay -clock VCLK -min 59.0 [all_outputs] # Treat register to output port paths as multicycle paths. set_multicycle_path 2 -from [all_clocks] -to [all_outpus] # This also causes input-to-output paths to be treated as multicycle paths. # Redefine these paths as single-cycle path. set_multicycle_path 1 -from [all_inputs] -to [all_outputs] # Constrain the Scan Test Enable port held at a constant value throughout scan # shift and capture modes with set_test_hold or in a STIL file. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its active state. set_case_analysis 1 SEN

220

Figure 9–19 Sample Script for Scan Capture Mode Operation create_clock -period 100.0 -waveform {0 50.0} -name VCLK # Define each clock group. create_clock -period 100.0 -waveform create_clock -period 100.0 -waveform set_clock_uncertainty 1.0 -from VCLK set_clock_uncertainty 1.0 -from VCLK

{45.0 55.0} -name CLK_GRP1 -port CLK1 {45.0 55.0} -name CLK_GRP2 -port {CLK2 CLK3} -to CLK_GRP1 -to CLK_GRP2

# Define paths going from one clock domain to another as false paths. # (There is no possibility of hold violations occurring in capture mode because # only one clock group is activated at a time.) set_false_path -from CLK_GRP1 -to CLK_GRP2 -hold set_false_path -from CLK_GRP2 -to CLK_GRP1 -hold set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -min -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 6.0 DB1 set_input_delay -clock VCLK -min 4.0 DB1 set_output_delay -clock VCLK -max 61.0 [all_outputs] set_output_delay -clock VCLK -min 59.0 [all_outputs] # Treat paths from registers to output ports as multicycle paths. set_multicycle_path 2 -from [all_clocks] -to [all_outpus] # This also causes paths from input ports to output ports to be treated as # multicycle path. Redefine these paths as single-cycle path. set_multicycle_path 1 -from [all_inputs] -to [all_outputs] # Constrain the Scan Test Enable port held at a constant value throughout scan # shift and capture modes with set_test_hold or in a STIL file. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its inactive state. set_case_analysis 0 SEN

Timing Verification of the Dual-Clocked Scan Design Figure 9–20 illustrates the test timing for the dual-clocked scan design.

221

.....

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

9

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

Figure 9–20 Test Timing for the Dual-Clocked Scan Design ■

TSTL2 timing definition block TIMING TS1 ; CYCLE 100 ; TIMESET(0) DT 0 ; TIMESET(1) DT 5 ; TIMESET(2) PP, 45, TIMESET(3) PP, 50, TIMESET(4) PP, 70, TIMESET(7) STB, 40 ENDTIM ;

10 ; 10 ; 10 ; ;

♦ Scan Shift Mode

Scan Shift Mode 100 ns

Inputs TIMESET(0)

5 ns

Input-Mode Bidirects TIMESET(1) Output Strobe TIMESET(7)

Multicycle path relative to Scan Clock B

System Clocks TIMESET(2) Scan Clock A TIMESET(3) Scan Clock B TIMESET(4)

50 ns

10 ns 10 ns

70 ns

Virtual Clock

♦ Scan Capture Mode

Scan Shift Mode

Scan Capture Mode

100 ns Inputs TIMESET(0) Input-Mode Bidirects TIMESET(1) Output Strobe TIMESET(7) System Clocks TIMESET(2) Scan Clock A TIMESET(3) Scan Clock B TIMESET(4) Virtual Clock

222

5 ns

Multicycle paths relative to Scan Clock A 45 ns 50 ns 70 ns

10 ns 10 ns

10 ns

Figure 9–21 shows a sample script for verifying scan shift mode operation. Figure 9–22 shows a sample script for verifying scan capture mode operation. The assumptions are: ■

Primary ports • • • • • • • •

Input pin: Bidirectional pin: Output pin: System clock pins: Scan Clock A: Scan Clock B: Scan Test Enable pin: Scan Shift Enable pin:

■

Tester input skew: ±1 ns

■

Clock groups • Group 1: • Group 2:

DI1 DB1 DO1 CLK1, CLK2, CLK3 ACK BCK TEN (active-high) SEN (active-high)

CLK1 CLK2, CLK3

Figure 9–21 Sample Script for Scan Shift Mode Verification create_clock -period 100.0 -waveform {0.0 50.0} -name VCLK # Define all clocks for scan shift mode verification. create_clock -period 100.0 -waveform {50.0 60.0} ACK create_clock -period 100.0 -waveform {70.0 80.0} BCK set_clock_uncertainty 1.1 -from VCLK -to ACK set_clock_uncertainty 1.1 -from VCLK -to BCK set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 1.0 DB1 set_input_delay -clock VCLK -max -1.0 DB1 set_output_delay -clock VCLK -max 31.0 [all_outputs] set_output_delay -clock VCLK -min 29.0 [all_outputs] # Constrain all system clocks to their inactive state. set_case_analysis 0 [list CLK1 CLK2 CLK3] # Constrain the Scan Test Enable port held at a constant value throughout scan # shift and capture modes with set_test_hold or in a STIL file. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its active state. set_case_analysis 1 SEN # Treat BCK to scan-out paths as multicycle paths. set_multicycle_path 2 -from BCK -to [all_outputs]

223

.....

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

9

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

# Output ports but scan-out ports change in response to ACK. Define ACK to scan-out # paths as false paths. set_false_path -from ACK -to [all_outputs] # Use the following command to avoid timing violations between ACK edges. # (This is a library problem.) set_false_path -from ACK -to ACK

Figure 9–22 Sample Script for Scan Capture Mode Operation create_clock -period 100.0 -waveform {0.0 50.0} -name VCLK # Define each clock group. create_clock -period 100.0 -waveform create_clock -period 100.0 -waveform create_clock -period 100.0 -waveform set_clock_uncertainty 1.0 -from VCLK set_clock_uncertainty 1.0 -from VCLK set_clock_uncertainty 1.0 -from VCLK

{50.0 60.0} ACK {45.0 55.0} -name CLK_GRP1 CLK1 {45.0 55.0} -name CLK_GRP2 {CLK2 CLK3} -to CLK_GRP1 -to CLK_GRP2 -to ACK

set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 1.0 DB1 set_input_delay -clock VCLK -max -1.0 DB1 set_output_delay -clock VCLK -max 31.0 [all_outputs] set_output_delay -clock VCLK -min 29.0 [all_outputs] # Constrain Scan Clock B to its inactive state. set_case_analysis 0 BCK # Constrain the Scan Test Enable port held at a constant value throughout scan # shift and capture modes with set_test_hold or in a STIL file. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its inactive state. set_case_analysis 0 SEN # Define paths from ACK to all clocks and output ports as multicycle paths. set_multicycle_path 2 -from ACK -to [all_clocks] # Define paths # (There is no # because only set_false_path set_false_path

going from one clock domain to another as false paths. possibility of these paths getting sensitized in 1-to2 cycles one clock group is activated at a time.) -from CLOCK_GRP1 -to CLOCK_GRP2 -from CLOCK_GRP2 -to CLOCK_GRP1

# Define paths from each clock group to output ports as false paths. # (In capture mode, output ports are not strobed after system clocks are exercised. set_false_path -from CLOCK_GRP1 -to [all_outputs] set_false_path -from CLOCK_GRP2 -to [all_outputs] # Define paths from each clock group to Scan Clock A as false paths. # (There is more than one cycle time between the active edge of a system # clock and the active edge of Scan Clock A. This is because a # cycle is inserted to apply Scan Clock B.) set_false_path -from CLOCK_GRP1 -to ACK set_false_path -from CLOCK_GRP2 -to ACK

224

Parallel-Load Simulation

.................................................. When you simulate scan test patterns, most of the time is spent serially loading and unloading the scan chain. This serial-load operation incurs a significant simulation runtime penalty because it requires thousands of tester cycles to shift data bit by bit into the scan chain. Parallel-load simulation performs this load operation in 2 to 3 cycles, reducing the runtime dramatically. Once you save your ATPG pattern set in TSTL2 format, you can convert it into a parallel-load testbench with the TSC program in the Toshiba sign-off environment. Figure 9–23 shows the parallel-load simulation flow. Figure 9–23 Parallel-Load Simulation Flow Verilog-HDL or VHDL Netlist

TetraMAX / Toshiba’s Design Kit (TFSA Program) SEGLEN / CLKBUF (Layout Info) TSTL2

FSA

Toshiba’s Sign-Off System

COMP

SDF

TSC

WAV / DRIVE / PARA (Testbench)

EXP (Expected Values File)

Sign-Off Simulator

Simulation Results File

SRA (Simulation Results Analysis)

To generate a parallel-load testbench with TSC, use the options explained below. For details, see the Sign-Off System Command Reference manual.

225

.....

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

9

Validating the Scan Structure and ATPG Test Vectors 9.3 Verifying the ATPG Patterns

iscan = [ON|OFF]

When set ON, generates a parallel-load testbench. In the VSO environment, WAV and DRIVE files are created. In the VITALSO environment, a PARA file is additionally created. plscmp = [ON|OFF]

When set ON, compacts a parallel-load testbench. The default is ON. Turn on this option for complex designs. fsaread = [ON|OFF]

When set ON, reads in an FSA file generated by the TFSA program. Be sure to turn on this option. fsa = filename

Specifies the name of the FSA file if it is different from the default (design.fsa). The following shows a sequence of commands to perform parallel-load simulation: %> %> %> %> %>

226

comp CKT1.v tsc testext=ATPG iscan=ON fsaread=ON force=ON tracegen sra=ON tsbsim CKT1.wav CKT1.v sra

Chapter 10 Toshiba TetraMAX Design Kit

.....

.....................................

T

oshiba’s TetraMAX design kit is comprised of four utility programs (SPFGen, TFSA, LSF2DEF and SCRTST), a cell library and a user manual. This chapter describes the SPFGen, TFSA, LSF2DEF and SCRTST programs. The material is organized into the following sections:

☞ System Requirements ☞ SPFGen ☞ TFSA ☞ LSF2DEF ☞ SCRTST

227

10

10.1

Toshiba TetraMAX Design Kit 10.1 System Requirements

System Requirements

This section shows the hardware and software requirements for using Toshiba’s TetraMAX design kit. Note: Be sure to obtain the latest design kit release before you begin creating a design. ■

Supported TetraMAX version TetraMAX 2000.11-SP1 and above Note: Ask your Toshiba design center engineer for the latest information about supported TetraMAX versions.

■

Supported hardware platforms • Sun-4 running under Sun Solaris 2.5, 2.6, 2.7 or 2.8 • HP running under HP-UX 11.0 • Red Hat Linux 7.1

■

Toshiba’s sign-off systems • VSO 1.12A and above • VITALSO 1.12A and above Note: The supported platforms differ, depending on the sign-off system versions. Ask your Toshiba design center engineer.

■

Estimated memory and hard disk requirements • For generating an FSA file alone Memory: number_of_flip-flops × 1 KB Hard disk: number of flip-flops × 0.3 KB (including the input SCE file) • For generating both FSA and LSF files Memory: number_of_flip-flops × 1 KB Hard disk: number of flip-flops × 1.3 KB (including the input SCE and SPA files) Note: The SPA file can be very huge for complex designs.

228

10.2

SPFGen

Functions of SPFGen

.................................................. To run TetraMAX, a STIL procedure file (SPF) is required. If you perform scan synthesis with DFT Compiler, you can write out an SPF within a DFT Compiler session. If you use another test synthesis tool for scan insertion, you must create an SPF. However, the SPF syntax is complicated, and mistakes in writing SPF descriptions often lead to trouble. SPFGen assists you in automatically generating an SPF. SPFGen is contained in version 1.12A and above of the Toshiba TetraMAX design kit.

Input and Output Files

.................................................. Depending on the tool used to perform scan synthesis, the required input files are different. Figure 10–1 to Figure 10–3 illustrate the input and output files of SPFGen. Figure 10–1 When DFT Compiler Was Used Netlist

tsb.config

SPF (DC)

INIT

SPFGen

DECLARE

SPF

Log

tsb.config

INIT

TMCMD

Figure 10–2 When VSO/DFT Was Used Netlist

TDCMD

SPFGen

DECLARE

TMCMD

SPF

Log

229

.....

Toshiba TetraMAX Design Kit 10.2 SPFGen

10

Toshiba TetraMAX Design Kit 10.2 SPFGen

Figure 10–3 When Other Scan Synthesis Tool Was Used Netlist

atpg.config

INIT

SPFGen

DECLARE

TMCMD

SPF

Log

Input Files This section briefly describes the input files required by SPFGen. ■

Netlist SPFGen supports netlists written in Verilog-HDL. To run SPFGen, the netlist of the top module suffices.

■

tsb.config

Configuration file for the Toshiba sign-off system. See page 237. ■

SPF (DC) SPF file generated by DFT Compiler. SPFGen provides the capability to tune the SPF file from DFT Compiler.

■

INIT The INIT file is optionally used to specify an initialization sequence and a sequence before and after scan shifting. This file is required when your design needs an initialization sequence and when scan circuitry is controlled by signals generated by JTAG logic. See page 236.

■

TDCMD Same setup file as that used by VSO/DFT to define test modes and scan chains.

■

atpg.config

Setup file used by SPFGen to define test modes and scan chains. See page 232.

Output Files This section briefly describes the output files produced by SPFGen.

230

■

DECLARE This file contains the DECLARE block written in TSTL2 format. Copy the contents of this file to the TSTL2 file appropriately when running parallel-load simulation. The default filename is top_module_name.declare.

■

TMCMD TetraMAX command file. You can run this command file without modification. The default filename is top_module_name.tmcmd.

■

SPF STIL procedure file that can be submitted to TetraMAX. The default filename is top_module_name.tmspf.

■

Log Execution log file. The default filename is top_module_name.spfgenlog.

Running SPFGen

..................................................

Syntax To execute SPFGen, enter the following command at a UNIX shell prompt: %> spfgen

[module = top_module_name] [netlist = netlist_filename] [spfin = SPF_filename_from_DC] [spfout = Output_SPF_filename] [cmdout = TMAXCMD_filename] [init = INIT_filename] [atpgconf = atpg.config_filename] [readspf = {on|off} [scan = {muxscan|fascan|mix}] [lang = [J|E]]

Options The options of the spfgen command are explained below: module

Specifies the name of the top module in your design.

231

.....

Toshiba TetraMAX Design Kit 10.2 SPFGen

10

Toshiba TetraMAX Design Kit 10.2 SPFGen

netlist

Specifies the name of the file containing the netlist.

spfin

Instructs SPFGen to use as input an SPF generated by DFT Compiler.

spfout

Specifies an alternative name to give the generated SPF file.

cmdout

Specifies an alternative name to give the generated TetraMAX command file.

init

Specifies the name of the INIT file.

atpgconf

Specifies an alternative name to give the generated ATPG configuration file.

readspf

If on, reads an SPF file from DC. The default is off.

scan

Selects the scan style, muxscan for a single-clocked scan design, fascan for a dual-clocked scan design, and mix for a mixed single/dual-clocked scan design.

lang

Selects the language in which log files are generated, J for Japanese and E for English. The default is English. Screen output (standard output) is always English.

atpg.config File

.................................................. Following is the format of the atpg.config file: $option { $module = top_module_name ; $tech = ASIC_technology ; $netlist = netlist_filename ; $spfin = SPF_filename_from_DC ; $spfout = Output_SPF_filename ; $cmdout = TMCMD_filename ; $init = INIT_filename ; $scan = {muxscan|fascan|mix} ; $lang = [J|E] ; $jtag = {JTAGC11|JTAGC14} ; $jtaginst = {SCANTEST|PSSCAN} ; } $chain scan_chain_name { pin_name = [+|-] attribute ; } $port { pin_name = [+|-] attribute ; }

232

$option block $module

Specifies the name of the top module in your design.

$tech

Specifies the ASIC technology.

$netlist

Specifies the name of the file containing the netlist.

$spfin

Instructs SPFGen to use as input an SPF generated by DFT Compiler.

$spfout

Specifies an alternative name to give the generated SPF file. The default filename is top_module_name.tmspf.

$cmdout

Specifies an alternative name to give the generated TetraMAX command file. The default filename is top_module_name.tmcmd.

$init

Specifies the name of the INIT file. The default filename is top_module_name.init.

$scan

Selects the scan style, muxscan for a single-clocked scan design, fascan for a dual-clocked scan design, and mix for a mixed single/dual-clocked scan design. This keyword is required.

$lang

Selects the language in which log files are generated, J for Japanese and E for English. The default is English. Screen output (standard output) is always English.

$jtag

Selects a JTAG controller when you want the internal-scan logic controlled by signals generated by the JTAG IP core, JTAGC11 for a 11-instruction JTAG controller or JTAGC14 for a 14-instruction JTAG controller. Give this option together with the $jtaginst option.

$jtaginst

Selects an instruction to be used when you want the internal-scan logic controlled by signals generated by the JTAG IP core. Give this option together with the $jtag option. When you give this option, you do not need to prepare an INIT file. For a detailed description of the SCANTEST and PSSCAN instructions, see the JTAG Design Guide application note.

$chain Block The $chain block provides information about a particular scan chain. This block is required for each of the scan chains in your design to specify the following: ■

Scan-in port

■

Scan-out port

■

System clock ports (only when $SCANTYPE=mix is specified)

233

.....

Toshiba TetraMAX Design Kit 10.2 SPFGen

10

■

Toshiba TetraMAX Design Kit 10.2 SPFGen

Scan clock ports (only when $SCANTYPE=mix is specified)

Identify only scan-in and scan-out ports for a design with a uniform single-clocked scan logic or a uniform dual-clocked scan logic; use the $port block to designate other ports. System and scan clocks can only be specified in the $chain block for a mixed single/dual-clocked design. $port Block The $port block provides information that is not specific to a given scan chain. Information in this block includes: ■

System clock ports

■

Scan clock ports (ACLK, BCLK)

■

Scan Test Enable ports

■

Scan Shift Enable ports

■

Asynchronous set/reset ports

■

JTAG ports

The attribute can be one of the following. The + and - signs denote active-high and active-low signals, respectively. For scan-in and scan-out ports, the + and - signs indicate whether a noninverting or inverting I/O buffer is used for a port. If the sign is omitted, the default is +.

234

■

SC

■

AC

■

BC

■

ST

■

RT

■

NC

■

TM

■

SM

■

SI

■

SO

■

TMS

■

TDI

■

TDO

■

TCK

■

TRST

System clock Scan clock A Scan clock B Asynchronous set Asynchronous reset Clock not exercised for capture operation Test mode (Scan Test Enable) Scan mode (Scan Shift Enable) Scan-in Scan-out JTAG TMS port JTAG TDI port JTAG TDO port JTAG TCK port JTAG TRST port

Following is an example of the atpg.config file: Figure 10–4 Sample atpg.config File

$option { $module = demo; $tech = tc240c; $netlist = demo.v; $scan = muxscan; $init = demo.init; $spfout = demo.spfnew; $lang = E; } $chain IN0 { SDI0 = +SI; SDO0 = +SO; } $chain IN1 { SDI1 = +SI; SDO1 = +SO; } $port { clk = +SC; reset = +RT; TMODE = +TM; SEN = +SM; bus_ctl = +SM; }

235

.....

Toshiba TetraMAX Design Kit 10.2 SPFGen

10

Toshiba TetraMAX Design Kit 10.2 SPFGen

INIT File

.................................................. The INIT file is optionally used to specify an initialization sequence and a sequence before and after scan shifting. It is required when your design requires an initialization sequence and when scan circuitry is controlled by signals generated by JTAG logic using the SCANTEST or PSSCAN instruction. Following is the format of the INIT file: // comment *INIT pin_name1 pin_name2 ... pin_nameN ; input_sequence ; input_sequence ; ... input_sequence ; $PRE_SHIFT pin_name1 pin_name2 ... pin_nameN ; input_sequence ; input_sequence ; ... input_sequence ; *POST_SHIFT pin_name1 pin_name2 ... pin_nameN ; input_sequence ; input_sequence ; ... input_sequence ;

Following is an example of the INIT file. Figure 10–5 Sample INIT File

// Sample INIT file *INIT TMODE0, TMODE1,TMODE2, MODECK; 001 P; 011 P; 100 P; 000 0; *PRE_SHIFT SMODE0, SMODE1, MODECK; 11 P; 10 P;

236

01 0; *POST_SHIFT SMODE0, SMODE1, MODECK; 01 P; 00 P; 11 0;

tsb.config File

.................................................. ATPG options are included under the *ATPG heading in the tsb.config file, as shown below: *COMMON module technology *ATPG netlist spfin spfout cmdout init scan lang jtag jtaginst tck tms tdi tdo trst

= top_module_name = ASIC_technology = = = = = = = = = = = = = =

filename filename filename filename filename {muxscan|fascan|mix} {J|E} {JTAGC11|JTAGC14} {SCANTEST|PSSCAN} JTAG_TCK_port JTAG_TMS_port JTAG_TDI_port JTAG_TDO_port JTAG_TRST_port

Each option in the tsb.config file is explained below: module

Specifies the name of the top module in your design.

technology

Specifies the ASIC technology.

netlist

Specifies the name of the file containing the netlist.

spfin

Specifies the name of the input SPF generated by DFT Compiler.

spfout

Specifies the name to give the generated SPF file.

237

.....

Toshiba TetraMAX Design Kit 10.2 SPFGen

10

Toshiba TetraMAX Design Kit 10.2 SPFGen

cmdout

Specifies the name to give the generated TMCMD file.

init

Specifies the name of the INIT file.

scan

Selects the scan style, muxscan for a single-clocked scan design, fascan for a dual-clocked scan design, and mix for a mixed single/dual-clocked scan design. This keyword is required.

lang

Selects the language in which log files are generated, J for Japanese and E for English. The default is English. Screen output (standard output) is always English.

jtag

Selects a JTAG controller when you want the internal-scan logic controlled by signals generated by the JTAG IP core, JTAGC11 for a 11-instruction JTAG controller or JTAGC14 for a 14-instruction JTAG controller. Give this option together with the jtaginst option.

jtaginst

Selects an instruction to be used when you want the internal-scan logic controlled by signals generated by the JTAG IP core. Give this option together with the jtag option. When you give this option, you do not need to prepare an INIT file. For a detailed description of the SCANTEST and PSSCAN instructions, see the JTAG Design Guide application note.

tck

Identifies the JTAG TCK port.

tms

Identifies the JTAG TMS port.

tdi

Identifies the JTAG TDI port.

tdo

Identifies the JTAG TDO port.

trst

Identifies the JTAG TRST port.

Following is an example of the tsb.config file. Figure 10–6 Sample tsb.config File

*common module technology *ATPG netlist spfout cmdout scan lang jtag jtaginst tck

238

= demo = TC240CQ = = = = = = = =

demo.v demo.spf demo.tmaxcmd muxscan E JTAGC14 SCANTEST TCK

tms tdi tdo trst

= = = =

TMS TDI TDO TRST

239

.....

Toshiba TetraMAX Design Kit 10.2 SPFGen

10

10.3

Toshiba TetraMAX Design Kit 10.3 TFSA

TFSA

Functions of TFSA

.................................................. TFSA generates FSA and LSF files. The FSA file is required to convert a TSTL2 test data file generated by TetraMAX into a parallel-load testbench. The LSF file is required to change the order in which scan chains are connected during place-and-route.

Input and Output Files

.................................................. Figure 10–7 illustrates the input and output files of TFSA. Figure 10–7 TFSA Input and Output

TetraMAX

TSTL2

SCE

SPA

TFSA

FSA

TSC (Toshiba Sign-off System)

Testbench

Parallel-Load Simulation (PLS)

240

LSF

Scan-Chain Reordering (SCR) in conventional layout flow

LSF2DEF

SCRDEF

Scan-Chain Reordering (SCR) in layout-Verilog flow

Input Files This section briefly describes the input files required by TFSA. SCE File The SCE file contains reports on the scan flip-flops and scan chains in your design generated by the TetraMAX report scan chains and report scan cells commands. To run TFSA, the SCE file must be named design_name.sce. Redirect the output of the report scan chains and report scan cells commands to the design_name.sce file, using the redirection operators > and >>, as shown below. The order of these commands is not important. For example: TEST> report scan chain > TMDEMO.sce TEST> report scan cells -all >> TMDEMO.sce

SPA File The SPA file contains reports on the scan chains in your design generated by the TetraMAX report scan path command. The SPA file is only required when generating an LSF file used for scan-chain reordering. To run TFSA, the SPA file must be named design_name.spa. Redirect the output of the report scan path command on each scan chain to the design_name.spa file, using the redirection operators > and >>. If your design has five scan chains, for example, repeat report scan path five times, as shown below: TEST> TEST> TEST> TEST> TEST>

report report report report report

scan scan scan scan scan

path path path path path

IN0 IN1 IN2 IN3 IN4

sco sco sco sco sco

sci sci sci sci sci

> TMDEMO.spa >> TMDEMO.spa >> TMDEMO.spa >> TMDEMO.spa >> TMDEMO.spa

Output Files This section briefly describes the output files produced by TFSA.

241

.....

Toshiba TetraMAX Design Kit 10.3 TFSA

10

Toshiba TetraMAX Design Kit 10.3 TFSA

FSA File The FSA file identifies scan flip-flops in each scan chain in your design and their properties. The FSA file is required by the Toshiba sign-off system when converting a TSTL2 test data file produced by TetraMAX into a parallel-load testbench, either in Verilog-HDL or VHDL format. TFSA names the FSA file design_name.fsa. LSF File The LSF file contains information about scan chain routing order. The LSF file is only required when performing scan-chain reordering (SCR) during place-and-route. TFSA names this file design_name.lsf. Log File TFSA generates a log file. The filename is design_name.tfsalog. Figure 10–8 shows a sample log. Figure 10–8 TFSA Log File TFSA 1.01 log file created 2000.3.21 9:22:10 ********************************************** * Execution conditions ********************************************** Date: 2000.3.21 Time: 9:22:10 Input Files: TMDEMO.sce TMDEMO.sch fsa.type Output Files: TMDEMO.fsa TMDEMO.lsf TMDEMO.tfsalog Option: S/O System: VSO Generate files: FSA, LSF LSF file: chip level description ********************************************** * Errors and Warning ********************************************** TFSA-2001 Get chains information. TFSA-2002 Get cells information. TFSA-2003 Writing a FSA file. TFSA-2004 Get scan chain IN0 information from SPA file. TFSA-2005 Search dummy instance in scan path data. TFSA-2006 Writing a LSF file. TFSA-2004 Get scan chain IN1 information from SPA file. TFSA-2005 Search dummy instance in scan path data. TFSA-2006 Writing a LSF file. TFSA-2004 Get scan chain IN2 information from SPA file. TFSA-2005 Search dummy instance in scan path data. TFSA-2006 Writing a LSF file. ********************************************** * Results

242

********************************************** Total error: 0 Total warning: 0 Number of instances in SPA

FF types: CFD1EXL CFD4EX4 CFD2EX4 Chain=IN0 Chain=IN1 Chain=IN2

Number of flip-flops processed to generate LSF

Number of flip-flops in SCE FF = 2/2 (FSA) 6 2/2(LSF) FF = 2/2 (FSA) 6 2/2(LSF) FF = 2/2 (FSA) 6 2/2(LSF) Number of flip-flops in SCE Number of flip-flops processed to generate FSA

Running TFSA

..................................................

Syntax Note: Before running TFSA, set up the VSO or VITALSO environment.

To execute TFSA, enter the following command at a UNIX shell prompt: %> tfsa top_module_name [-verilog|-vhdl] [-lsf] [-chip] [-delimit character]

Options The options of the tfsa command are explained below: -verilog|-vhdl Selects a sign-off system to be used. The default is -verilog (VSO). -lsf

Generates an LSF file. If omitted, only an FSA file is generated.

-chip

Generates a chip-level LSF file. This option is valid only when the -lsf option is specified. If you don’t give this option, TFSA generates an LSF file for block-based layout.

-delimit

Specifies the character used as the hierarchy delimiter when you changed it from the default / with this TetraMAX command: set build -hierarchical_delimiter character.

243

.....

Toshiba TetraMAX Design Kit 10.3 TFSA

10

Toshiba TetraMAX Design Kit 10.3 TFSA

Command Input Examples Several examples of the tfsa command are given below. The assumption is that the top module name is TMDEMO. ■

The following command generates an FSA file for the VSO environment, but not an LSF file: %> tfsa TMDEMO

■

The following command generates an FSA file and a block-based LSF file for the VSO environment: %> tfsa TMDEMO -lsf

■

The following command generates an FSA file for the VITALSO environment, but not an LSF file: %> tfsa TMDEMO -vhdl

■

The following command generates an FSA file and a chip-level LSF file for the VSO environment: %> tfsa TMDEMO -lsf -chip

■

The following command generates an FSA file and a chip-level LSF file for the VSO environment. The -delimit option is required when you have changed the hierarchy delimiter to the dot (.) character with the TetraMAX set build command. %> tfsa TMDEMO -lsf -chip -delimit .

Status, Warning and Error Messages

..................................................

Error Messages ..Error TFSA-0001 Can’t open LOG file:$1.

Meaning: An attempt to open a log file failed. Action: Check if there is enough free disk space. ..Error TFSA-0002 Can’t open SCE file:$1.

Meaning: An attempt to open the SCE file failed. Action: The identified file doesn’t exist. Check the name of the SCE file.

244

..Error TFSA-0003 Can’t open FSA file:$1.

Meaning: An attempt to open an FSA file failed. Action: Check if there is enough free disk space. ..Error TFSA-0004 Can’t open SPA file:$1.

Meaning: An attempt to open the SPA file failed. Action: The identified file doesn’t exist. Check the name of the SPA file. ..Error TFSA-0005 Can’t open LSF file:$1.

Meaning: An attempt to open an LSF file failed. Action: Check if there is enough free disk space. ..Error TFSA-0007 SPA file is illegal.

Meaning: The SPA file contains an illegal description. Action: Check the contents of the SPA file. ..Error TFSA-0009 Can’t allocate memory.

Meaning: Enough memory could not be allocated to run TFSA. Cause: TFSA has run out of memory. ..Error TFSA-0011 Scanchain $1 have no I/O cell for scan input pin.

Meaning: The scan-in pin for the identified scan chain has no input buffer when you attempted to generate a chip-level LSF file. Action: Add an input buffer to the scan-in pin. ..Error TFSA-0012 Scanchain $1 have no scan FF.

Meaning: There is no scan flip-flop in the identified scan chain. Action: Check the contents of the SPA and SCE files. ..Error TFSA-0013 Scanchain $1 have no I/O cell for scan output pin.

Meaning: The scan-out pin for the identified scan chain has no output buffer when you attempted to generate a chip-level LSF file. Action: Add an output buffer to the scan-out pin. ..Error TFSA-0014 SCE file have unknown FF type or inv data is illegal.

Meaning: An illegal flip-flop type or data inversion appears in the SCE file. Action: Check the contents of the SCE file. ..Error TFSA-0015 Can’t open TYPE file. Meaning: An attempt to open the TYPE file (fsa.type) failed.

Action:

Check if the design kit is properly installed.

..Error TFSA-0016 TYPE file is illegal. Meaning: The TYPE file (fsa.type) contains an unsupported description.

Action:

Contact your Toshiba design center engineer.

245

.....

Toshiba TetraMAX Design Kit 10.3 TFSA

10

Toshiba TetraMAX Design Kit 10.3 TFSA

..Error TFSA-0017 Can’t find SCE data block in SCE file. Meaning: The SCE file doesn’t contain the output of the TetraMAX report scan cells command.

Action:

Check the contents of the SCE file. If it doesn’t contain the output of the report scan cells command, append the output of report scan cells -all to the SCE file, using the redirection operator >>.

..Error TFSA-0018 SCE data is conflict with SCH data. Meaning: The blocks from the report scan chains and report scan cells

Action:

commands in the SCE file contain descriptions inconsistent with each other. Check the contents of the SCE file.

..Error TFSA-0019 SCE file have unknown FF type or inv data is illegal.

Meaning: An illegal flip-flop type or data inversion appears in the SCE file. Action: Check the contents of the SCE file. ..Error TFSA-0020 Can’t find SCH data block in SCE file. Meaning: The SCE file doesn’t contain the output of the TetraMAX report scan chains command.

Action:

Check the contents of the SCE file. If it doesn’t contain the output of the report scan chains command, append the output of report scan chains to the SCE file.

..Error TFSA-0021 Scan FF number in SCH data is conflict with data in SPA file($1).

Meaning: The number of scan flip-flops written in the SPA file doesn’t match the number of those written in the SCE file. Cause: The scan chain has logic gates with multiple inputs, causing scan chain information to be disrupted. The SPA file could not be generated properly. ..Error TFSA-0022 TYPE file don’t have module:$1.

Meaning: The identified module is not defined in the TYPE file (fsa.type) Action: You are using an out-of-date TYPE file. Obtain a new design kit. ..Error TFSA-0023 Can’t read SPA file correctly.

Meaning: An error was detected while reading the SPA file. Action: The SPA file may be corrupted. Re-generate an SPA file. ..Error TFSA-0024 SPA file has a unknown usage type.

Meaning: An unknown usage type appears in the SPA file. Action: Check the contents of the SPA file. ..Error TFSA-0025 Fail translation delimiter.

Meaning: An attempt to convert the hierarchy delimiter failed. Action: Check if the input files are correct.

246

..Error TFSA-0026 There is Illegal primitive that don’t have instance name.

Meaning: The SPA file contains a primitive that doesn’t have an instance name. Action: Run the set build -noadd_buffer command and regenerate an SPA file. ..Error TFSA-0027 SPA file have unknown primitive ID format.

Meaning: The SPA file contains a description that can not be interpreted correctly. Action: Check the SPA file. ..Error TFSA-0028 Instance name include "." character. Do you forget add option "tfsa -delimit ." ?

Meaning: Instance names include the dot (.) character. Action: If you changed the hierarchy delimiter to the dot character with the TetraMAX set build -hierarchical_delimiter command, give the option "-delimit ." when running TFSA. ..Error TFSA-0029 Can’t get output pin name of %s.

Meaning: An attempt to obtain an output pin name failed. Action: Check the SPA file. ..Error TFSA-0030 Can’t get input pin name of $1 Please type a below command on TetraMAX, and regenerate SPA file

Meaning: An attempt to obtain an input pin name failed. Action: Run the set build -noadd_buffer command and regenerate an SPA file. ..Error TFSA-1003 Can’t get certain information of input pin.

Meaning: Information about scan-in pins could not be retrieved reliably.

Warning Messages ..Warning TFSA-1001 The number of FFs is not enough to generate LSF file:$1.

Meaning: The number of scan flip-flops included in scan chain $1 is less than the minimum required to generate an LSF file. ..Warning TFSA-1002 $1(not FF) connects plural input to scan chain.

Meaning: Multiple instances of the identified non-scan cell are connected to the scan chain. ..Warning TFSA-1004 There is _BUS primitive that don’t have instance name.

Meaning: A scan chain includes _BUS primitives TetraMAX added for internal processing. TFSA ignores these primitives.

247

.....

Toshiba TetraMAX Design Kit 10.3 TFSA

10

Toshiba TetraMAX Design Kit 10.3 TFSA

..Warning TFSA-1010 Omit $1 from scan chain. ($1 is dummy instance.)

Meaning: The identified instance was removed from the scan chain. This instance was added by TetraMAX for internal processing. ..Warning TFSA-1011 $1 do not have information of pin names.

Meaning: The input and output pin names on the identified instance could not be retrieved. ..Warning TFSA-1012 $1 do not have information of input pin name.

Meaning: The input pin names on the identified instance could not be retrieved. ..Warning TFSA-1013 $1 do not have information of output pin name.

Meaning: The output pin names on the identified instance could not be retrieved. ..Warning TFSA-1014 TFSA skip a ununderstandable line (%d) in SPA file.

Meaning: The SPA file contains an unexpected description. TFSA ignored it. ..Warning TFSA-1015 TFSA ignore -delimit option and adopt "." char to delimiter. Meaning: The hierarchy delimiter you specified with the -delimit option is wrong.

Processing is continued, assuming the dot (.) character.

Status Messages TFSA-2001 Get chains information.

Meaning: TFSA is reading scan chain information from the SCE file. TFSA-2002 Get cells information.

Meaning: TFSA is reading scan cell information from the SCE file. TFSA-2003 Writing a FSA file.

Meaning: TFSA is writing an FSA file. TFSA-2004 Get scan chain $1 information from SPA file.

Meaning: TFSA is reading information about the identified scan chain from the SPA file. TFSA-2005 Search dummy instance in scan path data.

Meaning: TFSA is checking if there is any instance in the scan chain added by TetraMAX. TFSA-2006 Writing a LSF file.

Meaning: TFSA is writing an LSF file.

248

10.4

LSF2DEF

Function of LSF2DEF

.................................................. When place-and-route is performed using the new layout-Verilog interface flow, an LSF file must be converted into an SCRDEF file for scan-chain reordering (SCR). To do this, use LSF2DEF contained in the Toshiba DFT design kit. For details on SCR, see Chapter 12, "Scan-Chain Reordering (SCR)," on page 301. Note: LSF2DEF is a Perl script that runs on Perl version 4 or above. To run LSF2DEF, set up the Perl environment.

LSF File Format

.................................................. Used as an interface to a layout tool, an LSF file contains an identification of the scan-in and scan-out pins and scan flip-flop instances. If you want to specify which scan flip-flops are to be reordered, you can edit the LSF file. The LSF file produced by TFSA instructs the layout tool to reorder all scan flip-flops in your design. The syntax of the LSF file follows. All lines beginning with a # are treated as comments. All keywords begin with the $ character. Figure 10–9 LSF File Syntax

$ScanPath ChainName ; $ScanIn ScanInInstance Port ; $ScanOut ScanOutInstance Port ; $Arbit Arbitname ; ff_identification $End ArbitName ; $Sequence SequenceName ; ff_identification $End SequenceName ; $End ChainName ;

ChainName

Scan chain name (IN1, IN2, etc.)

249

.....

Toshiba TetraMAX Design Kit 10.4 LSF2DEF

Toshiba TetraMAX Design Kit 10.4 LSF2DEF

10

ScanInInstance, Port

Identifies the beginning of a scan chain (e.g., the Z or PO output of an input buffer, JTAG controller output, etc.) ScanOutInstance, Port

Identifies the end of a scan chain (e.g., the A input of an output buffer, an input of a mux, etc.) $Arbit

Marks the beginning of a section that identifies scan flip-flops which should be reordered.

$Sequence

Marks the beginning of a section that identifies scan flip-flops which should not be reordered.

The format of the ff_Identification in the $Arbit and $Sequence sections is: InstanceName PortI PortO

where, InstanceName is the instance name of a scan flip-flop written in the Verilog-HDL or VHDL convention, PortI is the scan-in port of the flip-flop (e.g., TI, SO), and PortO is the scan-out port of the flip-flop. A $Sequence section can be nested within a $Arbit section. A nested $Sequence section causes the scan-in pin of the first flip-flop and the scan-out pin of the last flip-flop listed in it to be reordered. Two LSF file examples are given in Figure 10–11 and Figure 10–12, with reference to the logic design below. Figure 10–10 Scan Design. ff_1 SI

io_2

module_1 ff_a

SO SI

ff_4

SO

SI

SO

ff_b

ff_2 io_1 SI

SI

SO

SO

ff_5 SI

ff_3 SI

250

SO

SO

Figure 10–11 shows an example of an LSF file that allows the routing order of all the scan flip-flops to be changed whereas Figure 10–12 shows an example of an LSF file to retain the order of the scan flip-flops in module_1. Figure 10–11 LSF File Example (a)

$ScanPath IN1 ; $ScanIn .io_1 Z ; $ScanOut .io_2 A ; $Arbit ARIN1 ; .ff_1 SI SO .ff_2 SI SO .ff_3 SI SO .module_1.ff_a SI SO .module_1.ff_b SI SO .ff_4 SI SO .ff_5 SI SO $end ARIN1 ; $end IN1 ; Figure 10–12 LSF File Example (b)

$ScanPath IN1 ; $ScanIn .io_1 Z ; $ScanOut .io_2 A ; $Arbit ARIN1 ; .ff_1 SI SO .ff_2 SI SO .ff_3 SI SO $Sequence SEQ1 ; .module_1.ff_a SI SO .module_1.ff_b SI SO $End SEQ1 ; .ff_4 SI SO .ff_5 SI SO $end ARIN1 ; $end IN1 ;

251

.....

Toshiba TetraMAX Design Kit 10.4 LSF2DEF

10

Toshiba TetraMAX Design Kit 10.4 LSF2DEF

Running LSF2DEF

.................................................. LSF2DEF converts an LSF file into an SCRDEF file required for scan-chain reordering in the layout-Verilog interface flow. To execute LSF2DEF, enter the following command at your UNIX shell prompt: %> lsf2def.pl top_module_name

The output SCRDEF file name will be design.scrdef.

252

10.5

SCRTST

Functions of SCRTST

.................................................. After scan-chain reordering, (SCR), SCRTST reformats TSTL2 scan test patterns according to the revised order of the scan chain.

Running SCRTST

.................................................. To run SCRTST, a TSTL2 test data file as well as the original and revised FSA files are required. The output from SCRTST is a TSTL2 test data file. Figure 10–13 illustrates the input and output files of SCRTST. Figure 10–13 SCRTST Input and Output

Original TSTL2

Original FSA

Revised FSA

SCRTST

Revised TSTL2

To execute SCRTST, enter the following command at a UNIX shell prompt: %> scrtst [module_name] [test_id] -bfsa=FSA_filename -afsa=FSA_filename [-column] [-ilist]

where: module_name

Is the name of the top-level module.

test_id

Is the test identifier of the input TSTL2 test data file.

-bfsa=FSA_filename

Specifies the name of the original FSA file.

253

.....

Toshiba TetraMAX Design Kit 10.5 SCRTST

10

Toshiba TetraMAX Design Kit 10.5 SCRTST

-afsa=FSA_filename

Specifies the name of the revised FSA file. -column

Permits test patterns that extend beyond column 72.

-ilist

Creates a detailed log.

Below is an example of the SCRTST command. In this example, the input TSTL2 test data file is named CKT.tstATPG. The output TSTL2 test data file will be named CKT.tstATPG_scr. %> scrtst CKT ATPG -bfsa=CKT.fsa.old -afsa=CKT.fsa

254

Chapter 11 JTAG Boundary-Scan Insertion Using BSD Compiler .....

.....................................

T

his chapter describes the design methodology for JTAG boundary-scan using Synopsys’ BSD Compiler. The material is organized into the following sections. Note: The information on BSD Compiler presented in this chapter is based on Version 2000.11 and above. If you are using an earlier version, you may encounter inconsistencies.

☞ Overview ☞ BSD Compiler Limitations ☞ JTAG Design and Verification Flow ☞ Step-by-Step JTAG Boundary-Scan Design Procedure ☞ Miscellaneous Commands ☞ JTAG Verification ☞ BSD Compiler Design Kit ☞ Known Problems

255

11

11.1

JTAG Boundary-Scan Insertion Using BSD Compiler 11.1 Overview

Overview

BSD Compiler is a boundary-scan automation tool that runs within the Design Compiler (DC) synthesis environment with the same DC library. BSD Compiler serves two purposes. One is to generate a boundary-scan design at the RTL simultaneously with synthesis. The other is to ensure that your design complies with IEEE Std 1149.1. You can generate a boundary-scan design, verifies that the design complies with the IEEE Std 1149.1 specification and create boundary-scan test patterns sequentially; or you can only check IEEE Std 1149.1 compliance for a design that already incorporates boundary-scan logic. The following terms and abbreviations will be used in this chapter:

256

■

JTAG:

IEEE Std 1149.1

■

BSR:

Boundary-scan register

■

TAP:

Test Access Port

■

TAPC:

TAP controller

■

BSDL:

Boundary-Scan Description Language

■

BSDL file:

File written in the BSDL format that describes the boundary-scan functions of an IEEE Std 1149.1-compliant chip

■

JTAG insertion:

Adding boundary-scan logic to a design

■

JTAG verification: Verifying that your design complies with the IEEE Std 1149.1 specification

■

Black box:

Empty module with only input/output declarations

11.2

BSD Compiler Limitations

This section describes the limitations for boundary-scan design using BSD Compiler 2000.11.

Top Module Requirements

.................................................. The top module must have I/O cells for all ports of a design, including the TAP. Figure 11–1 and Figure 11–2 illustrate the I/O and core interfaces for the top module before and after JTAG insertion. Figure 11–1 Top Module Before JTAG Insertion

System Input Pins

Core Design

System Output Pins

JTAG Input Pins

Top-Level

JTAG Output Pin

Figure 11–2 Top Module After JTAG Insertion

System Input Pins

Core Design

System Output Pins

BSR JTAG Input Pins

TAPC

JTAG Output Pins

257

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.2 BSD Compiler Limitations

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.2 BSD Compiler Limitations

TAP Requirements

.................................................. Before JTAG insertion, the TAP ports must have I/O cells attached in your RTL code, as shown in Figure 11–1.

Restrictions on Using Open-Drain Bidirectional Buffers

..................................................

Versions 2000.11 and 2000.11-SP1 of BSD Compiler do not support using open-drain bidirectional buffers for the TC190 to TC220, TC280 and TC300 technologies. There is a workaround for the TC240 to TC260 technologies. For details, see "Open-Drain Bidirectional Buffers" on page 295.

Toshiba Custom JTAG Components

.................................................. Toshiba’s IP core portfolio offers RTL custom JTAG components. It is advantageous to use these components if you must use the functions of private instructions implemented in them. However, at present, BSD Compiler does not provide a simple means for handling these JTAG components. If you want to use them with BSD Compiler, contact your Toshiba design center engineer.

258

11.3

JTAG Design and Verification Flow

This section shows a JTAG boundary-scan design flow using BSD Compiler and DesignWare components. Read the section "JTAG Insertion and Verification Flow" on page 259 if you want to insert and verify JTAG circuitry. Read the section "JTAG Verification-Only Flow" on page 264 if you only want to verify JTAG circuitry.

JTAG Insertion and Verification Flow

.................................................. The following provides a description of the JTAG insertion and verification flow using DesignWare (DW) components. Figure 11–3 shows the overall flow using BSD Compiler. Figure 11–3 Overall JTAG Insertion and Verification Flow Using BSD Compiler

DCF

PPA

VPPA

Either one of them is required.

DEV

PPMAPGEN

PPMAP

SCR_BSDC

Top-Level Design

Core Design (Black Box)

BSD Compiler (JTAG Insertion) Top-Level Design + TAPC + BSR

Core Design (RTL or Gate)

BSD Compiler (JTAG Verification)

BSDL

TSTL2

Figure 11–4 shows the design steps in a BSD Compiler session. Because BSD Compiler works on the top module, the core design module can be a black box.

259

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

Figure 11–4 JTAG Insertion and Verification Flow DCF

PPA

VPPA

DEV

Top Design w/ TAP

Core Design (Black Box)

PPMAPGEN Read RTL netlist

Synthesize design

Set design constraints

Optimize JTAG design

Top Design w/ JTAG

Prepare for JTAG insertion

Read core design

Core Design

Set DW JTAG components

Verify JTAG design

Insert DW JTAG components

Generate BSDL file

PPMAP SCR_BSDC

Generate JTAG test patterns

BSDL TSTL2

dc_shell (Design Compiler / BSD Compiler)

Figure 11–5 shows a sample script for JTAG boundary-scan design using DesignWare JTAG components. Replace search paths, top module name and design file names as appropriate. Figure 11–5 JTAG Boundary-Scan Design Flow /* =============================================================== FILE NAME jtag_insertion.scr JTAG TYPE : DW-JTAG This script inserts and verifies JTAG. =============================================================== */ /* -------------------------------------------------------------Set up design environment ----------------------------------------------------------------- */ search_path = { \ /usr/local/synopsys/libraries/syn \ /usr/local/synopsys/tsbdk/tc240c \ } target_library = tc240c.db_WCCOM25 symbol_library = tc240c.workview.sdb synthetic_library = { standard.sldb dw01.sldb dw02.sldb dw03.sldb dw04.sldb dwo6.sldb } link_library = { "*" tc240c.db_WCCOM25

260

\ \ \ \ \ \ \ \ \ \

}

tc240ct_io_macro.db + synthetic_library

\

/* -------------------------------------------------------------Read top module and core logic module (black box) ----------------------------------------------------------------- */ read -format verilog CKTTOP.v_prejtag read -format verilog CKTCORE.v_blackbox current_design CKTTOP link /* -------------------------------------------------------------Define clock signals and I/O delays ----------------------------------------------------------------- */ create_clock -name CLK -period 20 -waveform {0.0 10.0} CLK create_clock -name TCK -period 100 -waveform {0.0 50.0} TCK set_clock_skew -uncertainty 0.2 CLK set_fix_hold CLK set_input_delay 18.0 -clock CLK {all_inputs() - "CLK" - "TCK" } set_output_delay 18.0 -clock CLK all_outputs() set_max_fanout 32 CKTTOP /* -------------------------------------------------------------Read Port-to-Pin Mapping file (PPMAP) ----------------------------------------------------------------- */ read_pin_map CKTTOP.ppmap /* -------------------------------------------------------------Define IEEE Std 1149.1 Test Access Ports ----------------------------------------------------------------- */ set_bsd_signal tck TCK set_bsd_signal tdi TDI set_bsd_signal tdo TDO set_bsd_signal tms TMS set_bsd_signal trst TRST /* -------------------------------------------------------------Define I/O softmacrocells (Required for TC240 and later series) ----------------------------------------------------------------- */ include CKTTOP.scr_bsdc /* -------------------------------------------------------------Configure ID code register ----------------------------------------------------------------- */ test_bsd_manufacturer_id = 24 test_bsd_part_number = 32 test_bsd_version_number = 7 /* -------------------------------------------------------------Set JTAG configuration ----------------------------------------------------------------- */ set_bsd_configuration \ -style synchronous \ -instruction_encoding default \ -ir_width 4 \ -asynchronous_reset true \

261

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

-default_package

PKG00

/* -------------------------------------------------------------Set implemented JTAG instructions ----------------------------------------------------------------- */ set_bsd_instruction { \ BYPASS, \ EXTEST, \ SAMPLE, \ IDCODE, \ HIGHZ, \ CLAMP \ } set_bsd_instruction INTEST -input_clock_condition -output_condition

\ PI BSR

\

/* -------------------------------------------------------------Check design ----------------------------------------------------------------- */ check_design /* -------------------------------------------------------------Preview JTAG components ----------------------------------------------------------------- */ preview_bsd -show all /* -------------------------------------------------------------Generate and Insert JTAG components ----------------------------------------------------------------- */ insert_bsd /* -------------------------------------------------------------Check design ----------------------------------------------------------------- */ current_design CKTTOP check_design /* -------------------------------------------------------------Write GTECH design with JTAG components ----------------------------------------------------------------- */ write \ -format verilog \ -hierarchy \ -output CKTTOP.v_jtag_presynth /* -------------------------------------------------------------Synthesize and optimize JTAG components ----------------------------------------------------------------- */ current_design CKTTOP create_clock -name TCK -period 20 -waveform {0.0 10.0} TCK set_dont_touch_network TCK set_clock_skew -uncertainty 0.2 TCK set_fix_hold TCK set_input_delay 5.0 -clock TCK {all_inputs() - "CLK" - "TCK" } set_output_delay 5.0 -clock TCK all_outputs()

262

set_max_area 0 set_max_fanout 32 find(design) link all_bsrs = find( design, DW_bc* ) foreach( target_bsr, all_bsrs ){ current_design target_bsr compile } set_dont_touch all_bsrs current_design CKTTOP compile remove_attribute { all_bsrs } dont_touch report -timing /* -------------------------------------------------------------Optimize boundary-scan register ----------------------------------------------------------------- */ test_bsd_optimize_control_cell = true test_bsd_control_cell_drive_limit = 4 test_bsd_allow_tolerable_violations = true optimize_bsd /* -------------------------------------------------------------Write gate-level netlist (top module, TAPC and BSR) ----------------------------------------------------------------- */ remove_design CKTCORE write \ -format verilog \ -hierarchy \ -output CKT.v_jtag_postsynth_withJTAG /* -------------------------------------------------------------Read core design (black box) ----------------------------------------------------------------- */ read -format verilog CKTCORE.v_blackbox current_design CKTTOP link /* -------------------------------------------------------------Set test timing parameters ----------------------------------------------------------------- */ test_default_period = 50.0 test_default_delay = 5.0 test_default_bidir_delay = 5.0 test_default_strobe = 40.0 test_default_strobe_width = 1.0 create_test_clock TCK

-p 50 -w { 20, 30 }

/* -------------------------------------------------------------Check IEEE Std 1149.1 compliance ----------------------------------------------------------------- */ check_bsd -verbose -effort high

263

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

/* -------------------------------------------------------------Write BSDL file ----------------------------------------------------------------- */ write_bsdl -output CKTTOP.bsdl /* -------------------------------------------------------------Generate test patterns ----------------------------------------------------------------- */ write_test_formats = write_test_formats + tstl2_scan write_test_input_dont_care_value = 0 create_bsd_patterns -output CKTTOP_JTAG write_test \ -input CKTTOP_JTAG \ -format tstl2_scan \ -out CKTTOP.tst_jtag

JTAG Verification-Only Flow

.................................................. The following describes the flow to check IEEE Std 1149.1 compliance for a design with existing JTAG boundary-scan logic. Figure 11–6 shows the overall flow using BSD Compiler. Figure 11–6 General JTAG Verification Flow Using BSD Compiler

DCF

PPA

VPPA

DEV

Either one of them is required.

PPMAPGEN Netlist /w JTAG

PPMAP

BSD Compiler (JTAG Verification)

BSDL

TSTL2

Figure 11–7 shows the design steps in a BSD Compiler session.

264

Figure 11–7 JTAG Verification-Only Flow DCF

PPA

VPPA

DEV

Netlist w/ JTAG

PPMAPGEN Read netlists Prepare for JTAG verification

PPMAP

Verify JTAG design Generate BSDL file

BSDL

Generate JTAG test patterns

TSTL2

dc_shell (Design Compiler / BSD Compiler)

Figure 11–8 shows a sample script for JTAG verification. Replace search paths, top module name and design file names as appropriate. Figure 11–8 JTAG Verification Flow /* =============================================================== FILE NAME jtag_verification.scr JTAG TYPE : Anything This script verifies JTAG. =============================================================== */ /* -------------------------------------------------------------Set up design environment ----------------------------------------------------------------- */ search_path = { \ /usr/local/synopsys/libraries/syn \ /usr/local/synopsys/tsbdk/tc240c \ } target_library = tc240c.db_WCCOM25 symbol_library = tc240c.workview.sdb synthetic_library = { standard.sldb dw01.sldb dw02.sldb dw03.sldb dw04.sldb dwo6.sldb } link_library = { "*" tc240c.db_WCCOM25 tc240ct_io_macro.db } + synthetic_library

\ \ \ \ \ \ \

\ \ \ \

265

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

/* -------------------------------------------------------------Read all design netlists with JTAG components ----------------------------------------------------------------- */ read -format verilog CKTTOP.v_postsynth_withJTAG read -format verilog CKTCORE.v_blackbox current_design CKTTOP link /* -------------------------------------------------------------Define clock signals ----------------------------------------------------------------- */ create_clock -name CLK -period 20 -waveform {0.0 10.0} CLK create_clock -name TCK -period 20 -waveform {0.0 10.0} TCK set_dont_touch_network CLK set_dont_touch_network TCK /* -------------------------------------------------------------Read Port-to-Pin Mapping file (PPMAP) ----------------------------------------------------------------- */ read_pin_map CKTTOP.ppmap /* -------------------------------------------------------------Define IEEE Std 1149.1 Test Access Ports ----------------------------------------------------------------- */ set_bsd_port tck TCK set_bsd_port tdi TDI set_bsd_port tdo TDO set_bsd_port tms TMS set_bsd_port trst TRST /* -------------------------------------------------------------Set test timing parameters ----------------------------------------------------------------- */ test_default_period = 50.0 test_default_delay = 5.0 test_default_bidir_delay = 5.0 test_default_strobe = 40.0 test_default_strobe_width = 1.0 create_test_clock TCK

-p 50 -w { 20, 30 }

/* -------------------------------------------------------------Check IEEE Std 1149.1 compliance ----------------------------------------------------------------- */ check_bsd -verbose -effort high /* -------------------------------------------------------------Write BSDL file ----------------------------------------------------------------- */ write_bsdl -output CKTTOP.bsdl /* -------------------------------------------------------------Generate test patterns ----------------------------------------------------------------- */

266

write_test_formats = write_test_formats + tstl2_scan write_test_input_dont_care_value = 0 create_bsd_patterns -output CKTTOP_JTAG write_test \ -input CKTTOP_JTAG \ -format tstl2_scan \ -out CKTTOP.tst_jtag

267

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.3 JTAG Design and Verification Flow

11

11.4

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

Step-by-Step JTAG Boundary-Scan Design Procedure

This section guides you through the steps for the following tasks using BSD Compiler: ■

Inserting JTAG boundary-scan logic

■

Verifying a boundary-scan design

■

Generating a BSDL file

■

Generating JTAG test patterns

Invoking BSD Compiler

.................................................. Like Design Compiler, you can use BSD Compiler in one of the two user interfaces: dc_shell command line or graphical user interface (GUI). The invocation commands are: %> dc_shell %> design_analyzer &

//Command line //GUI

Reading the Design and Setting Synthesis Specifications

..................................................

Read the design’s netlists. The top-level module must have I/O cells for all I/O ports; the core design module can be a black box. Define clock signals and I/O delays for synthesis. The following command sequence illustrates these design flow activities: dc_shell> dc_shell> dc_shell> dc_shell>

read -format verilog CKTTOP.v_prejtag read -format verilog CKTCORE.v_blackbox current_design CKTTOP link

dc_shell> create_clock -name CLK -period 20 -waveform {0.0 10.0} CLK dc_shell> create_clock -name TCK -period 100 -waveform {0.0 50.0} \ TCK dc_shell> set_clock_skew -uncertainty 0.2 CLK dc_shell> set_fix_hold CLK

268

dc_shell> set_input_delay 18.0 -clock CLK \ {all_inputs() - "CLK" - "TCK" } dc_shell> set_output_delay 18.0 -clock CLK all_outputs()

Reading the PPMAP File

.................................................. Read the port-to-pin mapping (PPMAP) file using the read_pin_map command. The PPMAP file specifies the correspondence between logical ports and physical package pins, the order in which the boundary-scan register (BSR) cells are routed, and the package you intend to use. You can use PPMAPGEN contained in Toshiba’s BSD Compiler design kit to generate a PPMAP file for your design. For a description of PPMAPGEN, refer to "PPMAPGEN" on page 290.

Syntax The syntax of the read_pin_map command is: read_pin_map top_module.ppmap

Command Input Example Here is an example usage of read_pin_map. dc_shell> read_pin_map CKTTOP.ppmap

Defining Test Access Ports (TAPs)

.................................................. Use the set_bsd_signal command to define each of the test access ports (TCK, TDI, TMS, TRST, TDO) you intend to create.

269

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

Syntax The syntax of the set_bsd_signal command is: set_bsd_signal [tck|tdi|tms|trst|tdo] tap_port

[tck|tdi|tms|trst|tdo]

Specifies the type of the IEEE Std 1149.1 test signal.

Command Input Examples Here are example usages of set_bsd_signal: dc_shell> dc_shell> dc_shell> dc_shell> dc_shell>

set_bsd_signal set_bsd_signal set_bsd_signal set_bsd_signal set_bsd_signal

tck TCK tdi TDI tms TMS trst TRST tdo TDO

Defining I/O Softmacrocells (Only for TC240 to TC260)

..................................................

The I/O cells for the TC240 to TC260 series are configured as hierarchical softmacrocells. So that BSD Compiler can recognize I/O softmacrocells correctly, use the set_bsd_pad_design command to specify an I/O cell type and the list of pairs relating a signal type to a port of the design.

270

Syntax The syntax of the set_bsd_pad_design command is: set_bsd_pad_design I/O_cell_name -type input|output|tristate_output|bidirectional| open_drain_output|open_source_output| open_drain_bidirectional| open_source_bidirectional -access { data_in port_name, data_in_inverted port_name, data_out port_name, data_out_inverted port_name, enable port_name, enable_inverted port_name, port port_name, port_inverted port_name, } [-lib_cell true|false] [-differential true|false] [-disable_res WEAK0|WEAK1|PULL0|PULL1]

Options I/O_cell_name Specifies the library model name of an I/O cell. -type

Specifies the type of an I/O cell. open_drain_output and open_source_output are available with versions 2001.08 and above. open_drain_bidirectional and open_source_bidirectional are available with version 2002.05.

-access

Specifies the names of the ports to which BSR signals are connected. Table 11–1 shows the port type choices for each type of I/O cells. For example, specify data_out_inverted for an inverting input buffer; specify data_out, data_in and enable_inverted for a noninverting bidirectional buffer whose EN pin is connected to the BSR. Versions 2001.08 and above can define ports connected to package pins.

271

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

Table 11–1 Port Type Choices for Each Type of I/O Cells Input Polarity

Output Polarity

3-State Control Pins

I/O Cell Type Inverting

Noninverting

Inverting

Noninverting

Inverting

Noninverting

data_out

data_out_inverted

–

–

–

–

Output Buffer

–

–

data_in

data_in_inverted

–

–

Tristate Output Buffer

–

–

data_in

data_in_inverted

enable_inverted

enable

data_out

data_out_inverted

data_in

data_in_inverted

enable_inverted

enable

Input Buffer

Bidirectional Buffer

With 2001.08, give both port and port_inverted. -lib_cell

Specifies whether the I/O cell is a library cell. Set this option to false for an I/O cell configured as a softmacrocell. This option is available with versions 2001.08 and above.

-differential Specifies whether the I/O cell is a differential I/O cell. Set this option to true for a differential I/O cell. With 2001.08 and above, you must specify both port and port_inverted for the differential pad with the -access

option. -disable_res

Specifies the disable result for a 3-state output. This will be written to a BSDL file as the element. It can be one of the following: WEAK0: WEAK1: PULL0: PULL1:

External pull-down External pull-up Internal pull-down Internal pull-up

Command Input Example Here is an example usage of set_bsd_pad_design: dc_shell> set_bsd_pad_design -design BT4 -type tristate_output \ -access {data_in A, enable_inverted EN}

You can use PPMAPGEN to automatically generate a script file (called an SCR_BSDC file) that contains a series of set_bsd_pad_design commands. Include the SCR_BSDC file, as follows, prior to the JTAG insertion process: dc_shell> include CKTTOP.scr_bsdc

Take care if your design has custom I/O cells. PPMAPGEN only generates templates of set_bsd_pad_design for custom I/O cells; you must edit the SCR_BSDC file produced by PPMAPGEN. For a detailed description of the handling of custom I/O cells, refer to the section "Handling of Custom I/O Cells" on page 292.

272

Configuring the Device Identification Register

..................................................

Define the device identification code in conformance with IEEE Std 1149.1 in decimal notation. Toshiba’s manufacturer id is 00000011000, which translates to 24 in decimal. The part number and the version are unique to each IC.

Syntax You can specify the device identification code by setting the following environment variables: test_bsd_manufacturer_id = n test_bsd_part_number = n test_bsd_version_number = n

(n = 24) (n = 0 to 65535) (n = 0 to 15)

Command Input Examples Here are examples usages of the above variables: dc_shell> test_bsd_manufacturer_id = 24 dc_shell> test_bsd_part_number = 32 dc_shell> test_bsd_version_number = 1

Selecting the Boundary-Scan Configuration

..................................................

Use the set_bsd_configuration command to define the boundary-scan configuration.

273

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

Syntax The syntax of the set_bsd_configuration command is: set_bsd_configuration [-asynchronous_reset true|false] [-default_package package_name] [-instruction_encoding default|one_hot] [-ir_width ir_bit_width] [-style asynchronous|synchronous]

Options -asynchronous_reset

Set this option to true to use TRST as a JTAG reset. -default_package

Sets the default package to be used. -instruction_encoding

Selects the instruction register encoding style. default: one_hot:

Binary encoding One-hot encoding

-ir_width

Specifies the bit length of the instruction register.

-style

Set this option to synchronous to configure BSR cells to be synchronous with respect to TCK.

Command Input Example Here is an example usage of set_bsd_configuration: dc_shell> set_bsd_configuration -asynchronous_reset true \ -default_package PKG00 -instrcution_encoding default \ -ir_width 4 -style synchronous

274

Implementing IEEE Std 1149.1 Instructions

..................................................

If you want to implement optional instructions, you must specify them with the set_bsd_instruction command.

Syntax The syntax of the set_bsd_instruction command is: set_bsd_instruction {instruction_name, instruction_name,...} [-code inst_code_list] [-input_clock_condition PI|TCK] [-output_condition BSR|HIGHZ]

Options -code

Sets the binary code for the instruction. By default, BSD Compiler automatically assigns an appropriate code. To specify codes for multiple instructions, repeat the set_bsd_instruction command.

-input_clock_condition

Specifies the value that drives the system clock signal during instruction execution. -output_condition

Specifies how the system outputs are driven during instruction execution.

Command Input Example Here are example usages of set_bsd_instruction: dc_shell> set_bsd_instruction { IDCODE, HIGHZ, CLAMP } dc_shell> set_bsd_instruction INTEST -input_clock_condition PI \ -output_condition BSR

275

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

Previewing the Boundary-Scan Design

.................................................. You can preview your boundary-scan design you have set using the preview_bsd command.

Syntax The syntax of the preview_bsd command is: preview_bsd [-show cells|data_registers|instructions| tap|all] [-script]

Options -show

Selects information to be reported.

-script

Generates a script that contains the commands you used to configure your boundary-scan design.

Note: When both the -show and -script options are specified, the -script option takes precedence.

Command Input Example Here is an example usage of preview_bsd: dc_shell> preview_bsd -show all

Generating the Boundary-Scan Logic

.................................................. After you have previewed your boundary-scan design, you can generate it by using the insert_bsd command. The syntax is: insert_bsd

276

As the result of the insert_bsd command, the following two modules are added to the top module: ■

<design_name>_BSR_top_inst_design

■

DW_tap

These two modules are still empty at this point. The synthesis process will add DesignWare JTAG components to these modules. You can uniquify the boundary-scan register if you want. The following example illustrates the JTAG synthesis process: dc_shell> current_design CKTTOP dc_shell> uniquify dc_shell> link dc_shell> dc_shell> dc_shell> dc_shell> dc_shell>

create_clock -name TCK -period 20 -waveform {5 10} TCK set_clock_skew -uncertainty 1 TCK set_dont_touch_network TCK set_fix_hold TCK set_input_delay 5.0 -clock TCK {all_inputs() - "CLK" \ - "TCK" } dc_shell> set_output_delay 5.0 -clock TCK all_outputs() dc_shell> all_bsrs = find( design, DW_bc* ) dc_shell> foreach( target_bsr, all_bsrs ){ current_design target_bsr compile } dc_shell> set_dont_touch all_bsrs dc_shell> current_design CKTTOP dc_shell> compile dc_shell> remove_attribute { all_bsrs } dont_touch

The <design_name>_BSR_top_inst_design module generated by insert_bsd has no clock attributes. If you synthesize it separately, set a clock attribute to the TCK line (which will be run through clock tree synthesis) so that no buffer will be inserted to it.

Optimizing the Boundary-Scan Register

.................................................. Once you have finished with JTAG insertion and synthesis, you can optimize the boundary-scan register. Optimization occurs in the following steps:

277

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

■

To reduce area overhead, one control BSR cell is used to control the enable pin of many bidirectional and 3-state output buffers.

■

BSR cells are replaced by observe-only BSR cells to satisfy timing constraints.

Syntax To optimize the boundary-scan register, enter the following commands: test_bsd_optimize_control_cell = true|false test_bsd_control_drive_limit = number_of_cells set_bsr_cell_type -port port_list [-direction in|out] [control_observe|observe_only|none] set_max_delay -from port_name max_delay test_bsd_allow_tolerable_violations = true|false optimize_bsd

Command Input Example Here is an optimization example: dc_shell> dc_shell> dc_shell> dc_shell> dc_shell> dc_shell>

test_bsd_optimize_control_cell = true test_bsd_control_drive_limit = 4 set_bsr_cell_type -port BIDI0 -direction in observe_only set_max_delay -from BIDI0 0.0 test_bsd_allow_tolerable_violations = true optimize_bsd

Checking IEEE Std 1149.1 Compliance

.................................................. Now, you must verify the compliance of your boundary-scan design with IEEE Std 1149.1 by using the check_bsd command. If the check_bsd command does not complete or if any errors other than TEST-819 are generated, JTAG boundary-scan logic might not have been inserted correctly. Investigate and correct errors so that check_bsd terminates normally.

278

Syntax The syntax of the check_bsd command is: check_bsd [-verbose] [-effort low|mediumn|high]

Options -verbose

Provides more detailed message reporting for violations.

-effort

Controls the effort used to search for implemented instructions. If your design has binary (default) encoding, use medium or high effort.

Command Input Example Here is an example usage of check_bsd: dc_shell> check_bsd -verbose -effort high > chkbsd.log

Generating a BSDL File

.................................................. The boundary-scan features inserted in an IC are disclosed in the form of a BSDL file. Use the write_bsdl command to generate a BSDL file.

Syntax The syntax of the write_bsdl command is: write_bsdl [-naming_check VHDL|BSDL|none] [-output filename]

279

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

Options -naming_check

Specifies the type of naming checks to perform on the design. -output

Specifies the name to give the generated BSDL file. The default is top_design_name.bsdl.

Command Input Example Here is an example usage of write_bsdl: dc_shell> write_bsdl -naming_check BSDL -output CKTTOP.bsdl

Generating Test Patterns

.................................................. Use the create_bsd_patterns command to generate test patterns for your boundary-scan design.

Syntax The syntax of the create_bsd_patterns command is: create_bsd_patterns [-output test_pattern_name] [-effort low|medium|high] [-type tap_controller|reset|tdr|bsr|dc_parametric| functional|all]

Options

280

-output

Specifies the name to give the generated test pattern file.

-effort

Controls the effort used to search for implemented instructions. If your design has binary (default) encoding, use medium or high effort.

-type

Selects the types of patterns you want to generate.

Command Input Example Here is an example usage of create_bsd_patterns: dc_shell> create_bsd_patterns -output CKTTOP_program -type all

Formatting Test Patterns

.................................................. Run the write_test command to convert your test patterns to the TSTL2 format.

Syntax The syntax of the write_test command is: write_test [-input test_pattern_name] [-output filename] [-format verilog|tstl2_scan]

Options -input

Specifies the name of the test pattern file generated by the create_bsd_patterns command.

-output

Specifies the name to give the generated test pattern file.

-format

Selects the format for the output test pattern file. Set this option to tstl2_scan to create a TSTL2 file. Before creating a TSTL2 test pattern file, you need to add tstl2_scan to the write_test_formats variable and assign logic 0 to an input don’t-care value, as shown below: dc_shell> write_test_formats = write_test_formats + tstl2_scan dc_shell> write_test_input_dont_care_value = 0

281

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure

Command Input Example Here is an example usage of write_test: dc_shell> write_test -output CKTTOP.tstl2_jtag -format tstl2_scan

282

11.5

Miscellaneous Commands

This section describes useful commands and features that were not covered in the previous section.

Avoiding BSR Cells on Some Ports

.................................................. You can avoid putting BSR cells on some ports of your design such as analog, power and ground pins by using the set_bsd_linkage_port command. These ports are called linkage ports.

Syntax The syntax of the set_bsd_linkage_port command is: set_bsd_linkage_port -port_list port_list

Option -port_list

Identifies linkage ports.

Command Input Example Here is an example usage of set_bsd_linkage_port: dc_shell> set_bsd_linkage_port -port_list { AVS, AVD }

283

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.5 Miscellaneous Commands

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.5 Miscellaneous Commands

Assigning Specific BSR Cell Types

..................................................

Specifying Data Cells Use the set_bsd_data_cell command to assign a specific data BSR cell to some ports. For a bidirectional port, use the -direction option to specify the direction to be considered. If none is give as a cell type argument, no BSR cell is assigned to that port; use none to avoid putting BSR cells on JTAG-enable ports. Syntax The syntax of the set_bsd_data_cell command is: set_bsd_data_cell BC_1|BC_2|BC_4|none -port_list port_list [-direction in|out]

Options -port_list

Identifies ports of a design for which the specified BSR cell type is to be used.

-direction

Specifies the direction to be considered for bidirectional ports.

Command Input Example Here is an example usage of set_bsd_data_cell: dc_shell> set_bsd_data_cell BC_4 -port_list { data_bus_0, \ data_bus_1 } -direction in

Specifying Control Cells Use the set_bsd_control_cell command to assign a specific control BSR cell to some ports. cell_identifier is an arbitrary name.

284

Syntax The syntax of the set_bsd_control_cell command is: set_bsd_control_cell cell_identifier -type BC_1|BC_2 -port_list port_list

Options -type

Specifies the type of BSR cell to be used.

-port_list

Identifies ports of a design for which the specified BSR cell type is to be used.

Command Input Example Here is an example usage of set_bsd_control_cell: dc_shell> set_bsd_control_cell CTLCELL BC_2 port_list { data_bus_0, data_bus_1 }

Setting JTAG-Enable Ports

.................................................. JTAG-enable ports require two settings. One setting is to avoid putting BSR cells on JTAG-enable ports using the set_bsd_data_cell command described in the previous section; the other is to define JTAG-enable patterns using the set_bsd_compliance command.

Syntax The syntax of the set_bsd_compliance command follows.

285

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.5 Miscellaneous Commands

11

■

JTAG Boundary-Scan Insertion Using BSD Compiler 11.5 Miscellaneous Commands

2000.11 to 2001.08-SP1 set_bsd_compliance { port_name, 1|0, port_name, 1|0, ...}

■

2002.05 set_bsd_compliance pattern_name { port_name, 1|0, port_name, 1|0, ...}

Command Input Example Here are example usages of set_bsd_data_cell and set_bsd_compliance: ■

2002.05 dc_shell> set_bsd_data_cell none -port_list TSTMODE dc_shell> set_bsd_compliance P0 { TSTMODE, 0 }

■

2000.11 to 2001.08-SP1 dc_shell> set_bsd_data_cell none -port_list TSTMODE dc_shell> set_bsd_compliance { TSTMODE, 0 }

286

11.6

JTAG Verification

Be sure to verify that your design complies with the IEEE Std 1149.1 specification. BSD Compiler allows you to check IEEE Std 1149.1 compliance. Ensure that there is no violation in the verification results.

check_bsd Command Output

.................................................. Use the check_bsd command to check IEEE Std 1149.1 compliance. First, ensure that the command has terminated normally. Then examine the log to determine that you have no violation other than TEST-819 in your design. In case of any violations, you must investigate and correct them. In the following example, TEST-838 violations occurred. Figure 11–9 Rule Violation Example

*************************************************** IEEE 1149.1 Violation Summary *************************************************** 2 Violations found in extraction of TAP Controller Violates Rule: 3.3.1b Corresponds to Errors: TEST-819 Violates Rule: 3.6.1b Corresponds to Errors: TEST-819 2 Boundary scan design Violations found Violates Rule: 10.2.1b Corresponds to Errors: TEST-838 Violates Rule: 10.4.1a Corresponds to Errors: TEST-838 0 Violations found during BSR cell analysis 1 Return code

The last line of the violation summary shows the return code: a value of 1 indicates that check_bsd terminated normally; note that it does not mean your design fully complies with IEEE Std 1149.1. A value of 0 indicates abnormal termination. The check_bsd command verifies IEEE Std 1149.1 compliance of the TAP, the JTAG registers and inferred instructions, in this order. The subsections that follow describe what is checked and how to resolve violations.

287

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.6 JTAG Verification

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.6 JTAG Verification

Verification of the TAP

.................................................. The check_bsd command first checks the test access ports. During this checking, you might get TEST-819 messages, which tell you that the TRST, TMS or TDI input has no pull-up resistor. The check_bsd command might misrecognize I/O cells and generate TEST-819 messages even when you describe I/O cells with pull-up resistor at the RTL and they are defined in the library. Figure 11–10 Messages Regarding the TAP ...Analyzing TRST port. Warning: Undriven input port TRST is floating. When undriven, this port should behave as though it was driven by logic one.(TEST-819) ...Analyzing TMS Port. Warning: Undriven input port TMS is floating. When undriven, this port should behave as though it was driven by logic one.(TEST-819) ...Analyzing TCK halt state. Warning: Undriven input port TDI is floating. When undriven, this port should behave as though it was driven by logic one.(TEST-819)

Verification of the JTAG Registers

.................................................. After the TAP, the check_bsd command checks all JTAG registers, such as the instruction register, the data register, the bypass register and the boundary-scan register, to determine that they are properly connected and they operate correctly. Figure 11–11 shows a TEST-838a violation message. Figure 11–11 JTAG Register Violation Warning: An OUTPUT boundary scan register cell is missing on design port data_bus_0.(TEST-838a) Information: This problem occurred because port data_bus_0 has an unknown value ’X’, due to pin bidi0/IOMAIN/IO being in a high impedance state.(TEST-905) Information: This problem occurred because design inputport data_bus_0 controls the logic.(TEST-901)

The TEST-838a violation warns you that an output BSR cell is missing on a bidirectional buffer. You need to check the identified bidirectional buffer. One reason why an output BSR cell was not inserted to a bidirectional buffer is that it is intentionally used only as an input. If so, you can ignore this warning message.

288

Verification of Inferred Instruction

.................................................. Finally, the check_bsd command checks inferred instructions to see if all the instructions mandated by IEEE Std 1149.1 and optional instructions are implemented properly. Figure 11–12 shows a TEST-875 violation message. Figure 11–12 Instruction Violation ...Inferring the implemented SAMPLE/PRELOAD instructions. Warning: The boundary scan register cell demo_BSR_top_inst/demo_data_bus_3_bsr18/DW_bc_7_design/U1/U1/U3 is not able to capture the logic state of design input port during the instruction opcode 0010 (TEST-875) Information: Values at the port and BSR cell shift flops: Port data_bus_3 = Di. BSR cell Shift Flop demo_BSR_top_inst/demo_data_bus_3_bsr18/DW_bc_7_design/U1/U1/U3 Pin Values:D = X, CP = 0, Q = X, QN = X.(TEST-1133) Information: Cells with this violation: demo_BSR_top_inst/demo_data_bus_0_bsr4/DW_bc_7_design/U1/U1/U3, demo_BSR_top_inst/demo_data_bus_1_bsr6/DW_bc_7_design/U1/U1/U3, demo_BSR_top_inst/demo_data_bus_2_bsr8/DW_bc_7_design/U1/U1/U3, demo_BSR_top_inst/demo_data_bus_3_bsr10/DW_bc_7_design/U1/U1/U3 Error: Not able to infer the mandatory SAMPLE/PRELOAD instruction.(TEST-841)

The TEST-875 message indicates that the mandatory SAMPLE instruction is not implemented correctly; you need to check your boundary-scan design. This message tells you that the BSR cell at a bidirectional buffer is not able to capture the logic state of an input port; check if the identified bidirectional buffer is correctly connected with the boundary-scan register. Or the polarity of the 3-state enable input of that bidirectional buffer might be opposite to that required.

Verification Summary

.................................................. At the end of the report is a summary of the extracted JTAG boundary-scan logic. If you use the -verbose option, the check_bsd command provides you with a complete list of the instruction register’s instance name, the binary codes of the TAP controller states, the implemented instructions and the BSR cells.

289

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.6 JTAG Verification

11

11.7

JTAG Boundary-Scan Insertion Using BSD Compiler 11.7 BSD Compiler Design Kit

BSD Compiler Design Kit

Overview

.................................................. The BSD Compiler design kit facilitates boundary-scan design using BSD Compiler in the Toshiba ASIC design flow. The design kit contains a utility program (PPMAPGEN), demo files and a quick reference manual. The BSD Compiler design kit runs as an extension to the Toshiba ASIC sign-off system. Before installing the BSD Compiler design kit, make sure that you have the Toshiba ASIC sign-off system installed on your workstation. The versions of the BSD Compiler design kit and the sign-off system must match.

PPMAPGEN

.................................................. The BSD Compiler design kit contains a program called PPMAPGEN. You can use it to generate PPMAP and SCR_BSDC files. The PPMAP file is a port-to-pin mapping file that defines the correspondence between logical ports and physical package pins, the order in which the boundary-scan register (BSR) cells are routed, and the package you intend to use. The SCR_BSDC file is a script that containing a series of set_bsd_pad_design commands that define I/O softmacrocells. For a description of the set_bsd_pad_design command, see the section "Defining I/O Softmacrocells (Only for TC240 to TC260)" on page 270.

Syntax To execute PPMAPGEN, enter the following command at a UNIX shell prompt: %> ppmapgen top_module_name [-tdi port_name] [-input PPA|VPPA|DEV|DCF] [-series tc240c|tc240e|tc240dc|tc240de|tc240e| tc250c|tc260c|tc260e] [-bsdc00|-bsdc01] [-package package_name]

290

Options -tdi

Specifies the name of the TDI port.

-input

Specifies the type of the file that PPMAPGEN must use as input. • The PPA file is a file used as input to ADAS, Toshiba’s package design system. Generally, the designer creates one manually. • The VPPA file is generated by the design verifier program (DVER) of the Toshiba ASIC sign-off system. The VPPA file does not contain information about package pins and the package name; so you can only use it for a trial run of BSD Compiler. You must define a package name appropriately before you can use it with BSD Compiler. • The DEV file is an output from ADAS, Toshiba’s package design systems. For BGA packages, the DEV file enables BSD Compiler to stitch a boundary-scan path in an optimal order. • The DCF file is an output from FREEDOM, Toshiba’s package design system for the TC300 and later series. You must use a DCF file for the TC300 and later series.

-series

Specifies a Toshiba ASIC series if your design is built with TC240 to TC260 series. This option is required to generate an SCR_BSDC file. Generally, an SCR_BSDC file is not required for the TC190 to TC220 and TC280 series.

-bsdc00

Generates an SCR_BSDC file for BSD Compiler 2000.11 and 2000.11-SP1. If this option is not given, PPMAPGEN generates a script for BSD Compiler 2002.05.

-bsdc01

Generates an SCR_BSDC file for BSD Compiler 2008.08, 2001.08-SP1 and 2001.08-SP2. If this option is not given, PPMAPGEN generates a script for BSD Compiler 2002.05.

-package

Specifies the package name when submitting a DCF file.

Command Input Example Here is an example usage of PPMAPGEN: %> ppmapgen CKTTOP -tdi TDI -input DEV -series tc260c

291

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.7 BSD Compiler Design Kit

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.7 BSD Compiler Design Kit

Handling of Custom I/O Cells

.................................................. PPMAPGEN can generate a script that contains a series of set_bsd_pad_design commands for standard I/O cells, but not for custom I/O cells. The following subsections describe two methods to work around this limitation.

Modifying Templates (the Default Case) If PPMAPGEN encounters custom I/O cells, it builds templates of set_bsd_pad_design commands and prints messages telling you that you need to edit them. Templates are commented out; be sure to remove comment characters. For the syntax of the set_bsd_pad_design command, see "Defining I/O Softmacrocells (Only for TC240 to TC260)" on page 270.

Adding Custom I/O Cells to the Database Alternatively, you can add your custom I/O cells to the I/O database that accompanies PPMAPGEN. This way, PPMAPGEN can treat custom I/O cells as if they were standard cells. The I/O database is located in the $TOSH_ROOT/dft/bsdc/rule directory. There is one database file for each ASIC series. The filename is series_name.iocell. %> ls $TOSH_ROOT/dft/bsdc/rule/ tc240c.iocell tc240dc.iocell tc240de.iocell tc250c.iocell tc260c.iocell tc260e.iocell

tc240e.iocell

Copy the IOCELL file for your ASIC series to the directory in which PPMAPGEN will be run. For example: %> cp $TOSH_ROOT/dft/bsdc/rule/tc260c.iocell .

Add your custom I/O cells to this file. The format of the IOCELL file is shown below. Figure 11–13 IOCELL File Format #------------------------------------------------------------------# Comment #------------------------------------------------------------------cell_group_name INPUT|OUTPUT|BIDIRECT ( port_type = port_name, ... ): cell_name, ... ,cell_name ;

292

An example is given below Figure 11–14 IOCELL File Example #------------------------------------------------------------------# Type : BUF_I_DPLL( Input Buffer ) #------------------------------------------------------------------BUF_I_DPLL INPUT (ext=CLKIN, out=CLKOUT, pi=PI, po=PO): ZDPLLX1, ■

ZDPLLX2;

cell_group_name cell_group_name represents the type of I/O cells. PPMAPGEN uses it to determine the types of I/O cells used in your design. cell_group_name must be as follows: _<subgroup_id>

where, is one of the choices listed in Table 11–2. <subgroup_id> must consist of up to 10 alphanumeric characters. The underscore character (_) is not allowed in <subgroup_id>. A cell_group_name example is given below: BUF_OT_MYBUFFER Table 11–2 Choices

Function

BUF_I

Noninverting input buffer

BUF_IN

Inverting input buffer

BUF_IDR

Direct-type input buffer

BUF_O

Output buffer

BUF_OT

Tristate output buffer

BUF_OD

Open-drain output buffer

BUF_B

Noninverting bidirectional buffer

BUF_BN

Inverting bidirectional buffer

BUF_BD

Open-drain bidirectional buffer

BUF_BND

Inverting, open-drain bidirectional buffer

BUF_S

Other type of buffer

For BUF_S members, PPMAPGEN provides you with templates of set_bsd_pad_design commands and prints messages telling you that you need to edit them. In that case, edit the appropriate lines of the generated SCR_BSDC file. ■

cell_name

Provide a list of the names of all the I/O cells that belong to the same group. When listing multiple cell names, separate them with commas. End the entire cell name list with a semicolon.

293

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.7 BSD Compiler Design Kit

JTAG Boundary-Scan Insertion Using BSD Compiler 11.7 BSD Compiler Design Kit

11

■

port_type = port_name

Port names must be declared in the following format: ( port_type1 = port_name1, port_type2 = port_name2, ...):

where, port_type is one of the choices listed in Table 11–3. An example of the port name declaration is given below: (ext=CLKIN, out=CLKOUT, pi=PI, po=PO): Table 11–3 Port Type Choices Port Type

294

Function

ext

Port connected to a package pin

in

Input port of an output buffer

out

Output port of an input buffer

en

3-state output enable port (active-low)

tn

3-state output enable port (active-high)

pi

Input port for a NAND tree test

po

Output port for a NAND tree test

11.8

Known Problems

Open-Drain Bidirectional Buffers

..................................................

Problem Versions 2000.11 and 2000.11-SP1 of BSD Compiler do not support using open-drain bidirectional buffers for the TC190 to TC220, TC280 and TC300 technologies. There is a workaround for the TC240 to TC260 technologies. BSD Compiler 2001.08 and above can correctly insert BSR cells to open-drain bidirectional buffers for all ASIC series.

BSD Compiler Versions ■

BSD Compiler 2000.11 and 2000.11-SP1 • TC190 to TC220, TC280, TC300: There is no workaround. • TC240 to TC260: There is a workaround.

■

BSD Compiler 2001.08 and above There is a workaround for all ASIC series

Workaround TC240 to TC260 Series For the TC240 and TC260 series, I/O cells are configured as softmacrocells. Figure 11–15 shows a sample script to have BSD Compiler insert BSR cells to the open-drain bidirectional buffers. In this example, ports data_bus_0 to data_bus_7 use open-drain bidirectional buffers. Figure 11–15 Sample Script for BSD Compiler 2000.11 and Above /* * Define open-drain bidirectional I/O cells * */ set_bsd_pad_design BD4CODIF \ -type bidirectional \

295

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.8 Known Problems

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.8 Known Problems

-access { data_out data_in

\ \ \

ZI, EN

} /* * Insert BC_4 to ZI port * * data_bus_n ports have open-drain bidirectional I/O cells * */ set_bsd_data_cell BC_4 \ -port { \ data_bus_0, \ data_bus_1, \ data_bus_2, \ data_bus_3, \ data_bus_4, \ data_bus_5, \ data_bus_6, \ data_bus_7 } \ -direction in /* * Insert BC_1 to EN port * * data_bus_n ports have open-drain bidirectional I/O cells * */ set_bsd_data_cell BC_1 -port { \ data_bus_0, \ data_bus_1, \ data_bus_2, \ data_bus_3, \ data_bus_4, \ data_bus_5, \ data_bus_6, \ data_bus_7 } \ -direction out

Figure 11–16 Sample Script for BSD Compiler 2002.05 set_bsd_pad_design BD4CODIF -type open_drain_bidirectional -access { data_out ZI, enable_inverted EN } -libcell false

\ \ \ \

TC190 to TC220, TC280 and TC300 Series The I/O cells for the TC190 to TC220, TC280 and TC300 series are library cells. There is a workaround for BSD Compiler 2001.08 and above. Figure 11–17 shows a sample script to have BSD Compiler insert BSR cells to open-drain bidirectional buffers. This script does not work with 2000.11 and 2000.11-SP1.

296

Figure 11–17 Sample Script for BSD Compiler 2001.08 and Above /* * Define open-drain bidirectional I/O cells */ set_bsd_pad_design BD4CODIF \ -type bidirectional \ -access { \ data_out ZI, \ data_in EN \ } \ -lib_cell true

*

/* * Insert BC_4 to ZI port * * data_bus_n ports have open-drain bidirectional I/O cells * */ set_bsd_data_cell BC_4 \ -port { \ data_bus_0, \ data_bus_1, \ data_bus_2, \ data_bus_3, \ data_bus_4, \ data_bus_5, \ data_bus_6, \ data_bus_7 } \ -direction in /* * Insert BC_1 to EN port * * data_bus_n ports have open-drain bidirectional I/O cells * */ set_bsd_data_cell BC_1 -port { \ data_bus_0, \ data_bus_1, \ data_bus_2, \ data_bus_3, \ data_bus_4, \ data_bus_5, \ data_bus_6, \ data_bus_7 } \ -direction out

Figure 11–18 Sample Script for BSD Compiler 2002.05 set_bsd_pad_design BD4CODIF -type open_drain_bidirectional -access { data_out ZI, enable_inverted EN } -libcell true

\ \ \ \

297

.....

JTAG Boundary-Scan Insertion Using BSD Compiler 11.8 Known Problems

11

JTAG Boundary-Scan Insertion Using BSD Compiler 11.8 Known Problems

set_bsd_pad_design Problem for BC_4 Cells

..................................................

Problem If you run set_bsd_pad_design on an I/O cell to which a BC_4 cell is to be inserted, a net from that I/O cell to the core design module gets deleted.

BSD Compiler Versions This problem occurs with BSD Compiler 2000.11 to 2001.08

Workaround Use BSD Compiler 2001.08-SP1 or above. Or don’t run set_bsd_pad_design on an I/O cell to which a BC_4 cell is to be inserted. If you want to insert BC_4 and other types of BSR cell to I/O cells of the same type, run set_bsd_pad_design on them and modify the generated netlist.

298

CMOS ASIC Design Manual

Part 3 Advanced Topics

299

Synopsys-DFT User Guide

300

Chapter 12 Scan-Chain Reordering (SCR)

.....

.....................................

T

his chapter describes scan-chain reordering, a feature of the layout tool to change the order in which scan flip-flops are connected, based on cell placement. The material is organized into the following sections:

☞ What is Scan-Chain Reordering? ☞ Scan-Chain Reordering (SCR) Flow

301

12

12.1

Scan-Chain Reordering (SCR) 12.1 What is Scan-Chain Reordering?

What is Scan-Chain Reordering?

As a result of scan synthesis using DFT Compiler, flip-flops in your design are replaced by equivalent scan flip-flops, and the serial inputs and outputs of the scan flip-flops are connected together to form scan chains. By default, DFT Compiler determines scan-chain routing order, based on the instance names of the flip-flops. Consequently, closely-related flip-flops are not necessarily connected together. If the depth of your design hierarchy is shallow, the scan chain order can become inconsistent with the normal-mode operation of the flip-flops. In the past, the layout tool made no distinction between scan test circuitry and the rest of the design. When scan flip-flops were placed based on their normal-mode functionality, scan nets became unexpectedly long and thus caused routing congestion problems. Now, scan-chain reordering provides a solution to this problem by resynthesizing scan chains after cell placement. The layout tool first breaks or deletes scan nets from the original netlist, then reorders the scan chain to create new scan nets with optimal wire length. Scan-chain reordering thus helps to reduce area overhead due to scan nets.

302

Figure 12–1 Scan-Chain Reordering

Scan-in

SI SO

SI SO SI SO

SI SO SI SO

Scan-out

Scan-in

SI SO

The default scan chain order may not match the normal-mode function of the flip-flops, causing the scan nets to become unexpectedly long.

When your netlist contains scan chains, scan nets are deleted from the netlist based on the LSF file.

SI SO SI SO

SI SO SI SO

Scan-out

Scan-in

SI SO

New scan nets are created to connect scan flip-flops with optimal wire length.

SI SO SI SO

SI SO SI SO

Scan-out

303

.....

Scan-Chain Reordering (SCR) 12.1 What is Scan-Chain Reordering?

12

12.2

Scan-Chain Reordering (SCR) 12.2 Scan-Chain Reordering (SCR) Flow

Scan-Chain Reordering (SCR) Flow

Scan-chain reordering requires the information about the oreder in which scan cells are connected. When the conventional layout flow is used, the scan routing order is provided in a file called an LSF file. When the new Layout-Verilog interface flow is used, it is provided in a file called SCRDEF file. The SCRDEF file can be created by converting an LSF file with LSF2DEF contained in the Toshiba DFT design kit.

SCR in the Conventional Layout Flow The flow chart in Figure 12–2 illustrates the process of scan-chain reordering when the conventional layout flow is used.

304

Figure 12–2 Scan-Chain Reordering (Conventional Layout Flow) TetraMAX + TFSA

tdgs / def

Design

[1]

lsf

[2]

Physical Layout + SCR

chgcir Original fsa [3]

NETMOD

Verilog-HDL / VHDL

Original TSTL2

Revised netlist

TetraMAX + TFSA

[4]

Revised fsa [5] SCRTST

Revised TSTL2

1. Create LSF and FSA files Use TFSA to create LSF and FSA files. The LSF file is used as an interface to a layout tool for reordering the scan chain; it contains an identification of the scan-in pins, scan-out pins and scan flip-flops. The FSA file contains information about the order in which each scan chain is connected. After the routing order has been changed during layout, the revised order must be back-annotated through the FSA file to reformat the scan test patterns accordingly. For a detailed description of TFSA, see Chapter 10, "Toshiba TetraMAX Design Kit," on page 301. 2. Perform physical layout plus scan-chain reordering When your netlist contains scan chains, scan nets are deleted from the netlist based on the LSF file prior to cell placement, and new scan nets are created to connect scan flip-flops with optimal wire length. As a result of physical layout, you will obtain a CHGCIR file, which contains information about changes made to your logical design.

305

.....

Scan-Chain Reordering (SCR) 12.2 Scan-Chain Reordering (SCR) Flow

12

Scan-Chain Reordering (SCR) 12.2 Scan-Chain Reordering (SCR) Flow

3. Run NETMOD NETMOD in the sign-off system takes the CHGCIR file as input and implements logical netlist changes. For NETMOD, see the Sign-Off System Command Reference manual. 4. Create a revised FSA file In TetraMAX, regenerate SCE and SPA files. Then, generate a revised FSA file by means of TFSA. 5. Run SCRTST Use SCRTST in the Toshiba TetraMAX design kit to reformat the scan test patterns according to the revised FSA file. For a detailed description of SCRTST, see Chapter 10, "Toshiba TetraMAX Design Kit," on page 301.

306

SCR in the New Layout-Verilog Interface Flow The flow chart in Figure 12–3 illustrates the process of scan-chain reordering when the new Layout-Verilog Interface flow is used. TetraMAX + TFSA

Verilog-HDL

Netlist

[1]

lsf

LSF2DEF

[2]

scrdef Original fsa Physical Layout + SCR

Verilog-HDL

Original TSTL2

[3]

Revised netlist

TetraMAX + TFSA

[4]

Revised fsa [5] SCRTST

Revised TSTL2

Figure 12–3 Scan-Chain Reordering (Layout-Verilog InterfaceFlow)

1. Create LSF and FSA files Use TFSA to create LSF and FSA files. The LSF file is used as an interface to a layout tool for reordering the scan chain; it contains an identification of the scan-in pins, scan-out pins and scan flip-flops. The FSA file contains information about the order in which the scan chain is connected. After the routing order has been changed during layout, the revised order must be back-annotated through the FSA file to reformat the scan test patterns accordingly. For a detailed description of TFSA, see Chapter 10, "Toshiba TetraMAX Design Kit," on page 301.

307

.....

Scan-Chain Reordering (SCR) 12.2 Scan-Chain Reordering (SCR) Flow

12

Scan-Chain Reordering (SCR) 12.2 Scan-Chain Reordering (SCR) Flow

2. Create an SCRDEF file Use LSF2DEF contained in the Toshiba DFT design kit to convert an LSF file into an SCRDEF file. For how to run LSF2DEF, see the section "Running LSF2DEF" on page 165. 3. Perform physical layout plus scan-chain reordering When your netlist contains scan chains, scan nets are deleted from the netlist based on the SCRDEF file prior to cell placement, and new scan nets are created to connect scan flip-flops with optimal wire length. As a result of physical layout, you will obtain a new Verilog-HDL netlist. 4. Create a revised FSA file In TetraMAX, regenerate SCE and SPA files. Then, generate a revised FSA file by means of TFSA. 5. Run SCRTST Use SCRTST in the Toshiba TetraMAX design kit to reformat the scan test patterns according to the revised FSA file. For a detailed description of SCRTST, see Chapter 10, "Toshiba TetraMAX Design Kit," on page 301.

308

Chapter 13 Timing Analysis Using PrimeTime .....

.....................................

T

his chapter discusses case analysis useful for analyzing normal- and test-mode timing of your design using PrimeTime. The material is organized into the following sections:

☞ STA Considerations for a Design with DFT Logic ☞ Validating the Normal-Mode Operation of a Scanned Design ☞ Validating the Test-Mode Operation of a Scanned Design

309

13

13.1

Timing Analysis Using PrimeTime 13.1 STA Considerations for a Design with DFT Logic

STA Considerations for a Design with DFT Logic

In most cases, DFT structures such as internal-scan, JTAG boundary-scan and BIST logic operate off dedicated test clock pins. Even when system clock pins are used, during testing clock signals are usually operated at frequencies that differ from the system clock frequencies. Consequently, performing static timing analysis (STA) in normal operation mode can result in a lot of false timing violations. To avoid this problem, it is recommended that case analysis be used to perform timing analysis under different specific conditions, as follows:

310

■

Disable any DFT logic to validate the timing in normal operation mode.

■

Enable DFT logic to validate its timing.

13.2

Validating the Normal-Mode Operation of a Scanned Design

This section presents some tips for analyzing the normal-mode operation of a design that includes single- or dual-clocked scan logic.

Scan Test Enable

.................................................. Set a logic constant on the Scan Test Enable input to put the design in normal operation mode. Use the PrimeTime set_case_analysis command to hold it at its inactive state. The following example specifies that the port TEN1 is at a constant logic value 0. pt_shell> set_case_analysis 0 TEN1

Scan Shift Enable

.................................................. Like the Scan Test Enable input, set a logic constant on the Scan Shift Enable pin in normal operation mode. The following example specifies that the port SEN1 is at a constant logic value 0. pt_shell> set_case_analysis 0 SEN1

Scan Clocks

.................................................. For a dual-clocked scan design, set case analysis logic constants on the scan clocks to disable false paths. If your design allows the scan clocks to be disabled via the Scan Shift Enable input, set an appropriate logic constant on the Scan Shift Enable input. The following example specifies that the ports ACLK and BCLK are at a constant logic value 0. pt_shell> set_case_analysis 0 ACLK pt_shell> set_case_analysis 0 BCLK

311

.....

Timing Analysis Using PrimeTime 13.2 Validating the Normal-Mode Operation of a Scanned Design

13

Timing Analysis Using PrimeTime 13.2 Validating the Normal-Mode Operation of a Scanned Design

Scan Chains

.................................................. Generally, it is not necessary to add any constraints on scan chains. If you want a greater confidence that all scan chains will be excluded from timing analysis, you can set false paths on the scan chains with the set_false_path command. The following example specifies that all scan chains in a dual-clocked scan design are excluded. pt_shell> set_false_path -through [list */SI]

312

13.3

Validating the Test-Mode Operation of a Scanned Design

Using an event-driven simulator incurs a significant runtime penalty on complex designs. To facilitate timing verification and debugging, it is recommended to verify the scan test timing by means of an STA tool such as PrimeTime.

General STA Tool Considerations

.................................................. These considerations relate to the timing verification of a scanned design using PrimeTime: ■

Don’t set any mutlicycle and false paths that exist in normal mode of operation.

■

Perform a case analysis for scan test mode by setting certain test control pins to a constant value.

■

Create an SDF file with your tester conditions and set the tester’s input skew and output strobe margins.

■

Verify the circuit’s operation in scan shift and capture modes separately.

■

If your design has more than one clock group, verify the circuit’s capture mode operation group by group.

If you don’t know the tester conditions, run DCAL without using an IOPARAM file when generating an SDF (DCSDF) file.

Timing Verification of the Single-Clocked Scan Design

..................................................

Figure 13–1 illustrates the test timing for the single-clocked scan design.

313

.....

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

13

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

Figure 13–1 Test Timing for the Single-Clocked Scan Design ■

TSTL2 timing definition block TIMING TS1 ; CYCLE 100 ; TIMESET(0) DT 0 ; TIMESET(1) DT 5 ; TIMESET(2) PP, 45, 10 ; TIMESET(7) STB, 40 ; ENDTIM ; 100 ns Inputs TIMESET(0)

5 ns

Input-Mode Bidirects TIMESET(1) Output Strobe TIMESET(7)

40 ns

System/Scan Clock TIMESET(2)

45 ns

10 ns

Virtual Clock Multicycle Paths: (40 ns + 1cycle period) – 45 ns

Figure 13–2 shows a sample script for verifying scan shift mode operation. Figure 13–3 shows a sample script for verifying capture mode operation. The assumptions are: ■

Primary ports • • • • • •

Input pin: Bidirectional pin: Output pin: Clock pins: Scan Test Enable pin: Scan Shift Enable pin:

■

Tester input skew: ±1 ns

■

Clock groups • Group 1: • Group 2:

314

CLK1 CLK2, CLK3

DI1 DB1 DO1 CLK1, CLK2, CLK3 TEN (active-high) SEN (active-high)

Figure 13–2 Sample Script for Scan Shift Mode Verification create_clock -period 100.0 -waveform {0 50.0} -name VCLK # Define all clocks for scan shift mode verification. create_clock -period 100.0 -waveform {45.0 55.0} CLK1 create_clock -period 100.0 -waveform {45.0 55.0} CLK2 create_clock -period 100.0 -waveform {45.0 55.0} CLK3 set_clock_uncertainty 1.0 -from VCLK -to CLK1 set_clock_uncertainty 1.0 -from VCLK -to CLK2 set_clock_uncertainty 1.0 -from VCLK -to CLK3 set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -min -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 6.0 DB1 set_input_delay -clock VCLK -min 4.0 DB1 set_output_delay -clock VCLK -max 61.0 [all_outputs] set_output_delay -clock VCLK -min 59.0 [all_outputs] # Treat register to output port paths as multicycle paths. set_multicycle_path 2 -from [all_clocks] -to [all_outpus] # This also causes input-to-output paths to be treated as multicycle paths. # Redefine these paths as single-cycle path. set_multicycle_path 1 -from [all_inputs] -to [all_outputs] # Constrain the Scan Test Enable port held at a constant value throughout scan # shift and capture modes with set_test_hold or in a STIL file. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its active state. set_case_analysis 1 SEN

Figure 13–3 Sample Script for Capture Mode Operation create_clock -period 100.0 -waveform {0 50.0} -name VCLK # Define each clock group. create_clock -period 100.0 -waveform create_clock -period 100.0 -waveform set_clock_uncertainty 1.0 -from VCLK set_clock_uncertainty 1.0 -from VCLK

{45.0 55.0} -name CLK_GRP1 -port CLK1 {45.0 55.0} -name CLK_GRP2 -port {CLK2 CLK3} -to CLK_GRP1 -to CLK_GRP2

# Define paths going from one clock domain to another as false paths. # (There is no possibility of hold violations occurring in capture mode because # only one clock group is activated at a time.) set_false_path -from CLK_GRP1 -to CLK_GRP2 -hold set_false_path -from CLK_GRP2 -to CLK_GRP1 -hold set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -min -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 6.0 DB1 set_input_delay -clock VCLK -min 4.0 DB1 set_output_delay -clock VCLK -max 61.0 [all_outputs] set_output_delay -clock VCLK -min 59.0 [all_outputs]

315

.....

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

13

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

# Treat paths from registers to output ports as multicycle paths. set_multicycle_path 2 -from [all_clocks] -to [all_outpus] # This also causes paths from input ports to output ports to be treated as # multicycle path. Redefine these paths as single-cycle path. set_multicycle_path 1 -from [all_inputs] -to [all_outputs] # Constrain the Scan Test Enable port held at a constant value throughout scan # shift and capture modes with set_test_hold or in a STIL file. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its inactive state. set_case_analysis 0 SEN

Timing Verification of the Dual-Clocked Scan Design

..................................................

Figure 13–4 illustrates the test timing for the dual-clocked scan design. Figure 13–4 Test Timing for the Dual-Clocked Scan Design ■

TSTL2 timing definition block TIMING TS1 ; CYCLE 100 ; TIMESET(0) DT 0 ; TIMESET(1) DT 5 ; TIMESET(2) PP, 45, TIMESET(3) PP, 50, TIMESET(4) PP, 70, TIMESET(7) STB, 40 ENDTIM ;

316

10 ; 10 ; 10 ; ;

♦ Scan Shift Mode

Shift Scan Mode 100 ns

Inputs TIMESET(0)

5 ns

Input-Mode Bidirects TIMESET(1) Output Strobe TIMESET(7)

Multicycle path relative to Scan Clock B

System Clocks TIMESET(2) Scan Clock A TIMESET(3) Scan Clock B TIMESET(4)

50 ns

10 ns 10 ns

70 ns

Virtual Clock

♦ Scan Capture Mode

Scan Shift Mode

Scan Capture Mode

100 ns Inputs TIMESET(0) Input-Mode Bidirects TIMESET(1) Output Strobe TIMESET(7) System Clocks TIMESET(2) Scan Clock A TIMESET(3) Scan Clock B TIMESET(4)

5 ns

Multicycle paths relative to Scan Clock A 45 ns 50 ns 70 ns

10 ns

10 ns 10 ns

Virtual Clock

Figure 13–5 shows a sample script for verifying scan shift mode operation. Figure 13–6 shows a sample script for verifying capture mode operation. The assumptions are: ■

Primary ports • • • • •

Input pin: Bidirectional pin: Output pin: System clock pins: Scan Clock A:

DI1 DB1 DO1 CLK1, CLK2, CLK3 ACK

317

.....

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

13

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

• Scan Clock B: BCK • Scan Test Enable pin: TEN (active-high) • Scan Shift Enable pin: SEN (active-high) ■

Tester input skew: ±1 ns

■

Clock groups • Group 1: • Group 2:

CLK1 CLK2, CLK3

Figure 13–5 Sample Script for Scan Shift Mode Verification create_clock -period 100.0 -waveform {0.0 50.0} -name VCLK # Define all clocks for scan shift mode verification. create_clock -period 100.0 -waveform {50.0 60.0} ACK create_clock -period 100.0 -waveform {70.0 80.0} BCK set_clock_uncertainty 1.1 -from VCLK -to ACK set_clock_uncertainty 1.1 -from VCLK -to BCK set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 1.0 DB1 set_input_delay -clock VCLK -max -1.0 DB1 set_output_delay -clock VCLK -max 31.0 [all_outputs] set_output_delay -clock VCLK -min 29.0 [all_outputs] # Constrain all system clocks to their inactive state. set_case_analysis 0 [list CLK1 CLK2 CLK3] # Constrain the Scan Test Enable port you specified with set_test_hold or # in a STIL file to its active state. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its active state. set_case_analysis 1 SEN # Treat BCK to scan-out paths as multicycle paths. set_multicycle_path 2 -from BCK -to [all_outputs] # Output ports but scan-out ports change in response to ACK. Define ACK to scan-out # paths as false paths. set_false_path -from ACK -to [all_outputs] # Use the following command to avoid timing violations between ACK edges. # (This is a library problem.) set_false_path -from ACK -to ACK

318

Figure 13–6 Sample Script for Capture Mode Operation create_clock -period 100.0 -waveform {0.0 50.0} -name VCLK # Define each clock group. create_clock -period 100.0 -waveform create_clock -period 100.0 -waveform create_clock -period 100.0 -waveform set_clock_uncertainty 1.0 -from VCLK set_clock_uncertainty 1.0 -from VCLK set_clock_uncertainty 1.0 -from VCLK

{50.0 60.0} ACK {45.0 55.0} -name CLK_GRP1 CLK1 {45.0 55.0} -name CLK_GRP2 {CLK2 CLK3} -to CLK_GRP1 -to CLK_GRP2 -to ACK

set_input_delay -clock VCLK -max 1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max -1.0 {DI1 SEN TEN} set_input_delay -clock VCLK -max 1.0 DB1 set_input_delay -clock VCLK -max -1.0 DB1 set_output_delay -clock VCLK -max 31.0 [all_outputs] set_output_delay -clock VCLK -min 29.0 [all_outputs] # Constrain Scan Clock B to its inactive state. set_case_analysis 0 BCK # Constrain the Scan Test Enable port you specified with set_test_hold or # in a STIL file to its active state. set_case_analysis 1 TEN # Constrain the Scan Shift Enable port to its inactive state. set_case_analysis 0 SEN # Define paths from ACK to all clocks and output ports as multicycle paths. set_multicycle_path 2 -from ACK -to [all_clocks] # Define paths # (There is no # because only set_false_path set_false_path

going from one clock domain to another as false paths. possibility of these paths getting sensitized in 1-to2 cycles one clock group is activated at a time.) -from CLOCK_GRP1 -to CLOCK_GRP2 -from CLOCK_GRP2 -to CLOCK_GRP1

# Define paths from each clock group to output ports as false paths. # (In capture mode, output ports are not strobed after system clocks are exercised. set_false_path -from CLOCK_GRP1 -to [all_outputs] set_false_path -from CLOCK_GRP2 -to [all_outputs] # Define paths from each clock group to Scan Clock A as false paths. # (There is more than one cycle time between the active edge of a system # clock and the active edge of Scan Clock A. This is because a # cycle is inserted to apply Scan Clock B.) set_false_path -from CLOCK_GRP1 -to ACK set_false_path -from CLOCK_GRP2 -to ACK

319

.....

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

13

320

Timing Analysis Using PrimeTime 13.3 Validating the Test-Mode Operation of a Scanned Design

CMOS ASIC Design Manual

Part 4 Appendixes

321

Synopsys-DFT User Guide

322

Appendix A

Quick Tour

T

his appendix walks you through the entire process of synthesizing scan circuitry, running ATPG and verifying the generated scan test patterns. The material is organized into the following sections:

☞ General Design Flow ☞ 1-Pass Scan Synthesis Using DFT Compiler ☞ TetraMAX ATPG ☞ Verifying the Scan Test Patterns

323

A

A.1

Quick Tour A.1 General Design Flow

General Design Flow

The Quick Tour walks you through the flow shown in Figure A–1, starting with pre-synthesis RTL code. Figure A–1 General Design Flow Core Logic (RTL)

I/O Logic (Gate Level)

DC Synthesis Script

CKTCORE.v

CKTTOP.v_prescan

syn_muxscan.scr

DFT Compiler (Scan Synthesis) Netlist

SPF

CKTTOP.v_postscan

CKTTOP.spf

Command File CKTTOP.tmaxcmd

scan_design.report Report File

TetraMAX (ATPG)

CKTTOP.tst

CKTTOP.sce

TSTL2

Scan Report

CKTTOP.tmaxlog Log File

TFSA

CKTTOP.fsa Scan-related information

VSO (Design Verification & Simulation)

324

A.2

1-Pass Scan Synthesis Using DFT Compiler

This section covers scan synthesis, using DFT Compiler’s "test-ready compile," a feature that integrates logic optimization and scan replacement.

DC Synthesis Script

.................................................. Figure A–2 shows an example of a DC script that includes commands that are specifically used for scan synthesis. This script synthesizes single-clocked scan (multiplexed scan) circuitry. See Chapter 6 for a description of each command. Figure A–2 DC Synthesis Script (syn_muxscan.scr) /* ** FILE NAME : syn_muxscan.scr ** SCAN TYPE : Mux-scan ** This script performs test-ready compile. */ /* ** Read and link the design. */ read -f verilog {CKTCORE.v CKTTOP.v_prescan} current_design CKTTOP link /* ** Create a clock and set delay constraints on I/O ports. */ create_clock -name CLK -period 20 -waveform {0.0 10.0} CLK set_clock_skew -uncertainty 0.2 CLK set_fix_hold CLK set_input_delay 18.0 -clock CLK {all_inputs() - "CLK"} set_output_delay 18.0 -clock CLK all_outputs() /* ** Select a scan style and set a scan test mode constraint. */ set_scan_configuration -style multiplexed_flip_flop set_test_hold 1 RESETN /* ** Perform test-ready compile. */ set_max_area 0.0 compile -scan -map_effort high

325

.....

Quick Tour A.2 1-Pass Scan Synthesis Using DFT Compiler

A

Quick Tour A.2 1-Pass Scan Synthesis Using DFT Compiler

/* ** Identify scan-in, scan-out and scan shift enable ports. */ set_scan_signal test_scan_in -port DIA0 -hookup ui0/Z set_scan_signal test_scan_out -port DO0 -hookup uo0/A set_scan_signal test_scan_enable -port SCAN_ENABLE -hookup ui13/Z /* ** Check scan design rules. */ check_test /* ** Build scan chains. */ insert_scan /* ** Set timing parameters for scan test. */ write_test_input_dont_care_value = 0 test_default_period = 100 test_default_delay = 0 test_default_bidir_delay = 0 test_default_strobe = 40 create_test_clock "CLK" -waveform { 50 70 } /* ** Recheck scan design rules and generate a scan-related report. */ check_test > scan_design.report report_test -scan -assertions -atpg_conflict >> scan_design.report /* ** Write a STIL procedure file for TetraMAX. */ test_stil_netlist_format = verilog write_test_protocol -format stil -o CKTTOP.spf /* ** Write out a netlist. */ write -format verilog -o CKTTOP.v_postscan -h quit

Running DFT Compiler

.................................................. Set up and invoke Design Compiler. The script shown in Figure A–2 does not contain library setup commands; the assumption is that they are written in a setup file, such as .synopsys_dc.setup. This Quick Tour uses the TC220C technology. Make sure that you have these three files:

326

■

CKTCORE.v

■

CKTCORE.v_prescan

■

syn_muxscan.scr

To run DFT Compiler, enter: %> dc_shell -f syn_muxscan.scr

When you execute this script, DFT Compiler generates a scanned netlist (CKTTOP.v_postscan), a transcript from the check_test command (scan_design.report) and an SPF for TetraMAX (CKTTOP.spf).

327

.....

Quick Tour A.2 1-Pass Scan Synthesis Using DFT Compiler

A

A.3

Quick Tour A.3 TetraMAX ATPG

TetraMAX ATPG

Modifying the SPF

.................................................. TetraMAX ATPG requires an SPF. You can use the one generated by DFT Compiler with TetraMAX, with one minor modification. DFT Compiler assigns lowercase names to scan chains, like c0. However, Toshiba’s TSTL2 requires scan chain names to be all uppercase. Figure A–3 shows a fragment of an SPF after modification. Figure A–3 Scan Chain Name in an SPF ScanStructures { Scanchain "C0" { ScanLength 4; ScanIn "DIA0"; ScanOut "DO0"; } }

//Change scan chain name to uppercase.

Creating a TetraMAX Command File

.................................................. Next, create a command file for TetraMAX. Figure A–4 shows a sample command file (CKTTOP.tmaxcmd) for our design. See Chapter 8 for a description of each command. Figure A–4 TetraMAX Command File (CKTTOP.tmaxcmd) // TetraMAX Command File for CKTTOP.v // File name: CKTTOP.tmaxcmd // Turn on message logging set message log CKTTOP.tmaxlog -replace // Read the library and the netlist read netlist -library -noabort -master $TOSH_ROOT/lib/tmax/TC220C/TC220C.tmaxlib read netlist CKTTOP.v_postscan // Build the ATPG model run build CKTTOP // Perform test design rules checking run drc CKTTOP.spf // Create ATPG patterns run atpg -auto

328

// Generate an SCE file required by parallel-load simulation report scan chain > CKTTOP.sce report scan cells -all >> CKTTOP.sce // Write a TSTL2 file write patterns CKTTOP.tst -format tstl2 -internal -replace // Create a summary report report summaries fault primitive pattern // Turn off message logging set message nolog // Quit TetraMAX quit -force

Running TetraMAX ATPG

.................................................. Ensure that TetraMAX and the Toshiba design kit are properly set up. Because an Xterm window is launched in the course of ATPG pattern translation, the environment variable DISPLAY and the path to Xterm must be correctly set. Enter the following command to invoke TetraMAX and execute the command file: %> tmax CKTTOP.tmaxcmd

After TetraMAX ATPG is finished, make sure that you have a TSTL2 test data file (CKTTOP.tst), an SCE file (CKTTOP.sce) and a log file (CKTTOP.tmaxlog).

329

.....

Quick Tour A.3 TetraMAX ATPG

A

A.4

Quick Tour A.4 Verifying the Scan Test Patterns

Verifying the Scan Test Patterns

Creating the tsb.config File

.................................................. VSO requires a configuration file named tsb.config. You can use CONFIGURE to create one interactively. Figure A–5 shows an example of the tsb.config file. Figure A–5 Sample tsb.config File *COMMON hdl simulator edaversion technology arraytype voltage libdir project design module instance

= = = = = = = = = = =

verilog verilog 2.7 TC220C T3S60T8 3.0 . TetraMAX Design Kit CKTTOP CKTTOP wave.CKTTOP_wave

// // // // // // // // // // //

HDL language Simulator Verilog-XL version Technology Array size Core voltage Library directory Project name Design name Module name Top module instance name

Creating an FSA File

.................................................. An FSA file is required to convert the TSTL2 test data file from TetraMAX into a parallel-load testbench. Use the TFSA program contained in the Toshiba TetraMAX design kit to generate an FSA file. TFSA requires an SCE file (CKTTOP.sce) from TetraMAX as input. To run TFSA, enter: %> tfsa CKTTOP

TFSA generates an FSA file (CKTTOP.fsa) and a log file (CKTTOP.tfsalog).

330

Adding a DECLARE Block to the TSTL2 Test Data File

..................................................

The TSTL2 file must contain the DECLARE block when converting a TSTL2 test data file into a parallel-load testbench. TetraMAX can not write the DECLARE block; therefore, you must modify the TSTL2 file with a text editor. Figure A–6 shows an example of the DECLARE block, which must be written between the TITLE statement and the test vector block definition statement FUNCTEST. In this example, C0 is the scan chain name. Figure A–6 TSTL2 DECLARE Block Example TITLE TITLE; DECLARE; SYSCLK(P) CLK(C0); SCSEL(C0) SCAN_ENABLE=1; ENDDEC; FUNCTEST FC1;

// System clock polarity (P) and pin name // Scan Shift Enable pin name and active state

Running Parallel-Load Simulation

.................................................. This section briefly describes the sequence to run parallel-load simulation. 1. Run TNC to create a TDGS database. %> vetnc CKTTOP.v_postscan

2. Run DVER to check the design’s physical and electrical feasibility for implementation as real devices. %> dver

3. Run DCAL to calculate propagation delays for each cell in the design and generate an Open Verilog International (OVI) Standard Delay Format (SDF) file. %> dcal

4. Run TSC to convert a test data file written in the Toshiba TSTL2 format into a parallel-load testbench for Verilog simulation. TSC also generates an expected values (EXP) file used as input to SRA and an analysis command (SRACOM) file. %> tsc iscan=ON fsaread=ON force=ON

5. It is strongly recommended to produce four kinds of vector files to evaluate the scan test patterns, as described in Chapter 9. TSBSIM allows you to save signals listed in the SRACOM file during simulation. TSBSIM is run as a Verilog task.

331

.....

Quick Tour A.4 Verifying the Scan Test Patterns

A

Quick Tour A.4 Verifying the Scan Test Patterns

%> tracegen sra=ON %> tsbsim CKTTOP.wav CKTTOP.v_postscan

6. Run SRA to analyze the results of simulation, based on the SRACOM file from TSC. %> sra

The report file (CKTTOP.sralst) from SRA contains a summary of the detected error counts. Check the report file if any error occurred. Figure A–7 shows a fragment of the SRA report. Figure A–7 Error Count Summary in the SRALST File ********** SIMULATION RESULT ANALYSIS CHECK REPORT INFORMATION **********

332

COMPARE

CHECK REPORT COUNT =

0

SPIKE

CHECK REPORT COUNT =

0

CONFLICT

CHECK REPORT COUNT =

0

FLOAT

CHECK REPORT COUNT =

0

LAST TIME OF ALL STATE SAVE FILE

= 11800.000

LAST TIME OF EXPECT FILE

= 11640.000

Appendix B

T

TSTL2 Scan Test Data Description

his appendix provides an outline of serialized TSTL2 scan test vectors and how they are applied for scan testing. The material is organized into the following sections:

☞ TSTL2 Scan Vector File Organization ☞ DECLARE Block ☞ Scan Definition Blocks ☞ Scan Pattern Descriptions ☞ Scan Test Sequence Note: In January, 2002, Toshiba began to support the Standard Tester Interface Language (STIL), an industry standard for IC digital test vector representation approved as IEEE Std 1450-1999. If you wish to use the STIL format for test data interface, please consult with your Toshiba design center engineer.

333

B

B.1

TSTL2 Scan Test Data Description B.1 TSTL2 Scan Vector File Organization

TSTL2 Scan Vector File Organization

Figure B–1 shows a TSTL2 serialized scan vector file. When using TSTL2 scan vector files, keep the following points in mind: ■

Extra statements are required in the DECLARE block when performing parallel-load simulation (PLS).

■

Scan chains are defined, including scan-in and scan-out pins.

■

SP statements are used to describe serialized scan test vectors.

The TSTL2 file generated by TetraMAX does not include any statements required in the DECLARE block for parallel-load simulation. Those statements are used by the TSC program in the Toshiba sign-off system to convert a TSTL2 test data into a Verilog or VHDL parallel-load testbench. Serial-load simulation can be performed without the DECLARE block. Figure B–1 TSTL2 Scan Vector File Organization TITLE TITLE ; DECLARE ; Declarations required for parallel-load simulation SYSCLK(P) CLK(SC1) ; SCSEL(SC1) SEN=1 ; ENDDEC ; FUNCTEST FC1 ; INPUT(0) DIN1,DIN2,DIN3,DIN4,SIN,SEN; INPUT(1) CLK; OUTPUT(7) DOUT,SOUT; TIMING TS1 ; CYCLE 100 ; TIMESET(1) PP, 50, 20 ; TIMESET(7) STB, 40 ; ENDTIM ; SCAN SC1I; Scan-in and scan-out PATH SIN; definitions CONST DIN1=0, DIN2=0, DIN3=0, DIN4=0, CLK=1, SEN=1 ; ENDSCAN; SCAN SC1O; PATH SOUT; CONST DIN1=0, DIN2=0, DIN3=0, DIN4=0, CLK=1, SEN=1 ; ENDSCAN;

334

ASSIGN DOUT,SOUT,,DIN1,DIN2,DIN3,DIN4,,CLK,SIN,SEN; TESTPATT PAT1; ENABLE TS1 ; XX 0000 000; /* 1 */ XX 0000 000; /* 2 */ SP (SC1I) 0101, SP (SC1O) XXXX; Scan test vectors written using SP statements HL 1110 P00; /* 7 */ SP (SC1I) 0100, SP (SC1O) LHHH; LL 1001 P00; /* 12 */ Test cycle numbers SP (SC1I) 1100, SP (SC1O) LLLH; HH 0101 P00; /* 17 */ SP (SC1I) 1011, SP (SC1O) LLLH; LH 0010 P10; /* 22 */ SP (SC1I) 1110, SP (SC1O) LLLL; HH 1010 P10; /* 27 */ SP (SC1I) 0000, SP (SC1O) HLLH; ENDTEST ; ENDFUNC ; END ;

335

.....

TSTL2 Scan Test Data Description B.1 TSTL2 Scan Vector File Organization

B

B.2

TSTL2 Scan Test Data Description B.2 DECLARE Block

DECLARE Block

The DECLARE block begins with a DECLARE statement and ends with an ENDDEC statement. In a scan test pattern, the following statements are used within the DECLARE block: ■

SYSCLK

Specifies the polarity and pin name of the system clock.

■

SCMCLK

Specifies the polarity and pin name of Scan Clock A (for dual-clocked scan design).

■

SCSCLK

Specifies the polarity and pin name of Scan Clock B (for dual-clocked scan design).

■

SCSEL

Specifies the pin name and active state of the Scan Shift Enable pin.

■

PATTYPE

Controls bidirectional pin modes during scan shift. This statement is optional.

DECLARE and ENDDEC Statements

.................................................. Format DECLARE ; ... ENDDEC ;

Description ■

The DECLARE and ENDDEC statements define the beginning and end of the declaration block.

■

The DECLARE block must appear between TITLE and FUNCTEST statements.

■

The DECLARE block must appear exactly once in a TSTL2 file.

■

Only the following statements can appear in the DECLARE block: • VECTOR • SYSCLK

336

• • • •

SCMCLK (Only for dual-clocked scan design) SCSCLK (Only for dual-clocked scan design) SCSEL PATTYPE (Optional)

Example TITLE ATPG_FTEST; DECLARE; VECTOR Din[0:3], Dout[0:3], Dbid[4:7]; SYSCLK(P) CLK(IN1); SCMCLK(P) ACLK(IN1); SCSCLK(P) BCLK(IN1); ENDDEC;

SYSCLK Statement

.................................................. Format SYSCLK(polarity) pin_name1(scan_chain1, ...), ... ;

Description ■

The SYSCLK statement identifies one or more system clock pins for the scan chains.

■

The scan chains must be defined by SCAN blocks.

■

The polarity indicates the active edge of the clock(s). Use the letter P for PP (positive pulse) clocks and the letter N for NP (negative pulse) clocks.

■

The SYSCLK statement must appear at least once in the DECLARE block.

Example SYSCLK(P) CLK1(IN1); SYSCLK(N) CLK2(IN3,IN4); CLK1 is a system clock defined as a PP waveform for the flip-flops in scan chain IN1. CLK2 is a system clock defined as an NP waveform for the flip-flops in scan chains IN2 and IN3.

337

.....

TSTL2 Scan Test Data Description B.2 DECLARE Block

B

TSTL2 Scan Test Data Description B.2 DECLARE Block

SCMCLK and SCSCLK Statements

.................................................. Format SCMCLK(polarity) pin_name1(scan_chain1, ...), ... ; SCSCLK(polarity) pin_name1(scan_chain1, ...), ... ;

Description ■

The SCMCLK statement identifies one or more Scan Clock A (master) pins.

■

The SCSCLK statement identifies one or more Scan Clock B (slave) pins.

■

The scan chains must be defined by SCAN blocks.

■

The polarity indicates the active edge of the clock(s). Use the letter P for PP (positive pulse) clocks and the letter N for NP (negative pulse) clocks.

■

The SCMCLK and SCSCLK statements may appear at least once in the DECLARE block.

Example SCMCLK(P) ACLK(IN1,IN2); SCSCLK(P) BCLK(IN1,IN2); ACLK is a Scan Clock A pin for scan chains IN1 and IN2. BCLK is a Scan Clock B pin for scan chains IN1 and IN2.

338

SCSEL Statement

.................................................. Format SCSEL(scan_chain) pin_name1=active_state, ... ;

Description ■

The SCSEL statement identifies one or more Scan Shift Enable pins for a scan chain and their active states.

■

The scan chain must be defined by a SCAN block.

■

The Scan Shift Enable pins must also be defined with the same active states in a CONST statement within the SCAN block.

Example SCSEL(IN1) SEN=1; SCSEL(IN2) SEN=1,SEN2=1;

Scan chain IN1 is placed in scan shift mode when SEN is at logic 1. Scan chain IN2 is placed in scan shift mode when both SEN and SEN2 are at logic 1.

PATTYPE Statement

.................................................. Format PATTYPE {TSBINTERNAL|TSBJTAG} ;

Description ■

The PATTYPE statement affects the default values assigned to bidirectional pins during scan shift.

■

TSBINTERNAL causes bidirectional pins to be held in input mode and assigned input patterns throughout scan shift.

339

.....

TSTL2 Scan Test Data Description B.2 DECLARE Block

B

■

TSTL2 Scan Test Data Description B.2 DECLARE Block

TSBJTAG causes bidirectional pins to remain at the immediately previous logic values.

Therefore, when the previous pattern data is a 0, 1 or Z, a 0, 1 or Z is assumed respectively; when the previous pattern data is an L, H or X, an X (or a don’t-care) is assumed. ■

If the PATTYPE statement is omitted, bidirectional pins are assumed to be in the output unknown state and assigned Xs (or don’t-cares).

■

The PATTYPE statement may appear at most once within the DECLARE block.

Example Where a design is compliant with the internal-scan design rules, bidirectional pins are forced to input mode during scan shift. The following is the correct PATTYPE statement for such a design: PATTYPE TSBINTERNAL;

340

B.3

Scan Definition Blocks

The SCAN and ENDSCAN statements bracket a scan definition block, which defines either a scan-in or scan-out pin and any pins that are held constant during scan shift. The following statements are required in the scan definition block: ■

PATH

Identifies either an scan-in or scan-out pin.

■

CONST

Specifies any pins and fixed pattern data required to shift test data through a scan chain.

For a detailed description of these statements, refer to the TDL, TSTL2, ROM Data manual.

SCAN and ENDSCAN Statements

.................................................. Format SCAN scan_name ; ... ENDSCAN ;

Description ■

The SCAN and ENDSCAN statements define the beginning and end of a scan definition block.

■

The scan_name consists of a scan chain name and a suffix, as shown below: <scan_chain_name><suffix>

■

The scan_chain_name can be up to seven alphanumeric characters, beginning with a letter. The scan_chain_name must be in uppercase. The suffix must be the letter I for the definition of a scan-in pin, or the letter O for the definition of a scan-out pin.

■

Write SCAN blocks immediately before the ASSIGN statement. There may be multiple SCAN blocks.

341

.....

TSTL2 Scan Test Data Description B.3 Scan Definition Blocks

TSTL2 Scan Test Data Description B.3 Scan Definition Blocks

B

■

Only the following statements are allowed between the SCAN and ENDSCAN statements: • PATH • CONST

PATH Statement

.................................................. Format PATH pin_name ;

Description ■

Identify either the scan-in or scan-out pin for the scan chain defined with the SCAN statement.

■

The PATH statement must appear within a SCAN block.

CONST Statement

.................................................. Format CONST pin_name1 =pattern_data1, ... ;

Description ■

Specify any I/O pins for which pattern data do not change during scan shift mode.

■

The CONST statement must appear exactly once in a SCAN block.

Example Scan Definition Block

.................................................. Figure B–2 shows an example scan definition block.

342

Figure B–2 Scan Definition Block

SCAN IN1I; PATH SCIN1; CONST SYSCLK=0,ACLK=P,BCLK=P; ENDSCAN; SCAN IN1O; PATH SCOUT1; CONST SYSCLK=0,ACLK=P,BCLK=P; ENDSCAN;

Scan chain IN1 is implemented with scan-in pin SCIN1 and scan-out pin SCOUT1. Scan-in patterns to be applied to SCIN1 will be described using SP statements identifying the scan name with the I suffix, like SP(IN1I). Scan-out patterns coming out of SCOUT1 will also be described using SP statements identifying the scan name with the O suffix, like SP(IN1O). During scan shift, SYSCLK is assigned pattern data "0", ACLK is assigned pattern data "P" and BCLK is assigned pattern data "P"; i.e., SYSCLK is off, and ACLK and BCLK are on.

343

.....

TSTL2 Scan Test Data Description B.3 Scan Definition Blocks

TSTL2 Scan Test Data Description B.4 Scan Pattern Descriptions

B

B.4

Scan Pattern Descriptions

As opposed to parallel test data in which all I/O pins are assigned pattern data cycle by cycle, scan test data uses serialized vectors, each of which represent thousands of cycles. Scan-in patterns are serialized to be applied at the scan-in pin, and scan-out patterns are serialized to be measured at the scan-out pin.

SP Statement

.................................................. Format SP(scan_name1) serialized_vector ; SP(scan_name1) serialized_vector ; ...

Description ■

The SP statement is used to write a serialized scan vector for the specified scan chain. The scan_name1 identifies one of the scan chains defined with a PATH statement. Serialized scan vector is loaded into a scan chain, with the leftmost bit first (1 bit = 1 cycle).

■

Multiple scan chains can be loaded and unloaded in parallel by delimiting SP statements with commas. SP(SC1I)0011,SP(SC2I)0101; 00LH N00 00XX ; SP(SC1O)LLHH,SP(SC2O)LHLH, SP(SC1I)0101,SP(SC2I)0101 ; 11HL N00 00XX ; SP(SC1O)LHLH,SP(SC2O)LHLH ; ...

■

Two scan chains are loaded in parallel. Two scan chains are unloaded in parallel, while at the same time they are loaded with new vectors.

I/O pins other than the active scan-in and scan-out pins are assigned specific pattern data as follows (in priority order). • Pattern data defined with the CONST statement corresponding to the active scan chain. • Input pins are assigned the same pattern data as the immediately previous cycle; output pins are assigned Xs if the immediately previous cycle has an L or H. • Bidirectional pin values are determined by the PATTYPE statement.

344

For a detailed description of the SP statement, refer to the TDL, TSTL2, ROM Data manual. Figure B–3 shows a serialized scan test pattern, in comparison with parallel sequences. Figure B–3 Serialized Scan Test Pattern ✦ Serialized scan test patterns

4 5 6

✦ Equivalent parallel patterns

SDO1 SDI1 BCLK ACLK SYSCLK O2 O1 I2 I1

1 2 3

... SCAN IN1I; PATH SDI1; CONST SYSCLK=0,ACLK=P,BCLK=P; ENDSCAN; SCAN IN1O; PATH SDO1; CONST SYSCLK=0,ACLK=P,BCLK=P; ENDSCAN; ASSIGN I1,I2,O1,O2,,SYSCLK,,ACLK,BCLK,, SDI1,SDO1; TESTPAT SAMPLE; 10XX 0 00 0X; SP(IN1I) 00100; 10HL P 00 0X; SP(IN1O) LLHHH, SP(IN1I) 11010; 01LL P 00 1X; SP(IN1O) HHHLL, SP(IN1I) 01000; ...

10XX 10XX 10XX 10XX 10XX 10XX 10HL 10XX 10XX 10XX 10XX 10XX 01LL 01XX 01XX 01XX 01XX 01XX

0 0 0 0 0 0 P 0 0 0 0 0 P 0 0 0 0 0

00 PP PP PP PP PP 00 PP PP PP PP PP 00 PP PP PP PP PP

0X; 0X; 0X; 1X; 0X; 0X; 0X; 1L; 1L; 0H; 1H; 0H; 1X; 0H; 1H; 0H; 0L; 0L;

1. Capture mode

2. Scan shift mode (scan-in)

3. Capture mode

4. Scan shift mode (Scan-out and scan-in) 5. Capture mode

6. Scan shift mode (Scan-out and scan-in)

In the above example, I1, I2, O1 and O2 are functional data pins. The CONST statement within the SCAN block defines the pattern data for the system clock (SYSCLK) and the scan clocks (ACLK and BCLK) during scan shift mode. The SP statement is used to write serialized patterns for the scan-in (SDI1) and scan-out (SDO1) pins. Test patterns for the capture mode are written in parallel format without using the SP statement.

345

.....

TSTL2 Scan Test Data Description B.4 Scan Pattern Descriptions

B

B.5

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

Scan Test Sequence

This section provides an example of a scan design and illustrates the typical scan test sequence. Figure B–4 shows simple designs before and after scan insertion. Figure B–4 Designs Before and After Scan Insertion ✦ Before scan insertion c1 DIN1

ff1 n1

D

Q

n3

c3

ff3 n5

D

Q

n7 MUX 0 c5

DIN2

1

c2

ff2 n2

D

Q

n4

c4

DOUT

ff4 n6

D

Q

n8

DIN3 DIN4 CLK

✦ After scan insertion c1 DIN1

ff1 n1

DIN2

D

Q

n3

c3

ff3 n5

D

TI

TI

TE

TE

Q

n7 MUX 0 c5 1

c2

ff2 n2

D

Q

n4

c4

DOUT

ff4 n6

D

TI

TI

TE

TE

Q

n8

SOUT

DIN3 DIN4 CLK SIN SEN

In the design after scan insertion, the scan routing order is ff2 – ff1 – ff3 – ff4. Figure B–5 shows TSTL2 test data generated by TetraMAX. The TDL, TSTL2, ROM Data manual specifies scan test patterns in this order: scan-in – capture mode – scan-out; however, TetraMAX uses a different order: scan-in – scan-out – capture mode.

346

Figure B–5 TSTL2 Scan Test Data Generated by TetraMAX

TITLE TITLE ; FUNCTEST FC1 ; INPUT(0) DIN1,DIN2,DIN3,DIN4,SIN,SEN; INPUT(1) CLK; OUTPUT(7) DOUT,SOUT; TIMING TS1 ; CYCLE 100 ; TIMESET(1) PP, 50, 20 ; TIMESET(7) STB, 40 ; ENDTIM ; SCAN SC1I; PATH SIN; CONST DIN1=0, DIN2=0, DIN3=0, DIN4=0, CLK=1, SEN=1 ; ENDSCAN; SCAN SC1O; PATH SOUT; CONST DIN1=0, DIN2=0, DIN3=0, DIN4=0, CLK=1, SEN=1 ; ENDSCAN; ASSIGN DOUT,SOUT,,DIN1,DIN2,DIN3,DIN4,,CLK,SIN,SEN; TESTPATT PAT1; ENABLE TS1 ; XX 0000 000; /* 1 */ Cycles 1–2 XX 0000 000; /* 2 */ SP (SC1I) 0101, Cycles 3–6 SP (SC1O) XXXX; HL 1110 P00; /* 7 */ Cycle 7 SP (SC1I) 0100, Cycles 8–11 SP (SC1O) LHHH; LL 1001 P00; /* 12 */ Cycle 12 SP (SC1I) 1100, SP (SC1O) LLLH; HH 0101 P00; /* 17 */ SP (SC1I) 1011, SP (SC1O) LLLH; LH 0010 P10; /* 22 */ SP (SC1I) 1110, SP (SC1O) LLLL; HH 1010 P10; /* 27 */ SP (SC1I) 0000, SP (SC1O) HLLH; ENDTEST ; ENDFUNC ; END ;

Following is a description how this scan test pattern is used to test the scanned design.

347

.....

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

B

Cycles 1–2 (Initialization Cycles: 0–200 ns) The following two vectors constitute the initialization cycles before beginning a scan test. XX 0000 000; /*1*/ XX 0000 000; /*2*/

Cycles 3–6 (Scan Shift Mode: 200–600 ns) In scan shift mode, test vectors are written in serialized format using SP statements, as follows: SP (SC1I) 0101, SP (SC1O) XXXX;

Notice that the two SP statements are delimited by a comma; the first statement is for scan-in, and the second one is for scan-out. Thus, the scan chain is loaded while simultaneously being unloaded. The scan-in vector is applied at the scan-in pin (SIN) defined by the PATH statement within the SCAN SC1I block. The CONST statement within this SCAN block defines DIN1=0, DIN2=0, DIN3=0, DIN4=0, CLK=P, SEN=1, which specifies constant pattern data during scan shift mode. Consequently, the above SP statements are equivalent to: the following: SEN SIN CLK DIN4 DIN3 DIN2 DIN1 SOUT

X X X X

0000 0000 0000 0000

P01; P11; P01; P11;

/* /* /* /*

3 4 5 6

*/ */ */ */

The scan-in vector written in the SP statement is serially shifted into the scan chain, with the leftmost bit first. Therefore, a 0 is shifted in in cycle 3; a 1 is shifted in in cycle 4; a 0 is shifted in in cycle 5; and a 1 is shifted in in cycle 6. Figure B–6 illustrates the process of serially shifting in this scan-in vector.

348

Figure B–6 Serial Shift of Scan-in Vector 0101 Cycle 3

0

–

–

–

Cycle 4

1

0

–

–

Cycle 5

0

1

0

–

Cycle 6

1

0

1

0

1

0

1

0

ff2

ff1

ff3

ff4

Cycle 7 (Capture Mode: 600 –700 ns) Following is the functional test vector for the capture mode: HL 1110 P00; /* 7 */

The paragraphs that follow describe the sequence of events triggered by this vector. 1. The vector is applied to the input pins but the clock pin (CLK) at the beginning of the cycle (at time 700 ns), as specified by the timing definition in the TSTL2 file. Figure B–7 Application of the Parallel Vector to the Input Pins

DIN1 DIN2

1

c1

ff1 n1

D TI

1

SIN SEN

ff3 n5

0

Q

D TI

n7 MUX 0 c5

1

TE

ff2 n2

Q

D

TE

CLK

c3

1

TI

DIN4

n3

TE

c2

DIN3

Q

1

n4

c4

DOUT

ff4 n6

Q

D TI

0

n8

SOUT

TE

1 0 0 0 0

2. Test values propagate through the circuit. (700 ns + α) In scan shift mode, the flip-flops have been preloaded. Once the functional vector is applied at the primary input pins, combinational logic paths are sensitized, and the states of

349

.....

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

B

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

the input pins of the flip-flops (n1, n2, n5 and n6) and output signals to primary output pins (DOUT and SOUT) become stable. Figure B–8 Propagation of Test Response

DIN1 DIN2

1

c1

ff1 n1

1

TI

1

Q

D

n3

c3

ff3 n5 1

0

TI

n2

1

Q

D

n4

c4

1

TI

SIN SEN

DOUT

ff4

n6 0 D

TE

CLK

MUX 0 c5 1

1

1

ff2

TI

DIN4

n7

TE

TE

c2

DIN3

Q

D

0

Q

n8

0

SOUT

TE

1 0 0 0 0

3. The output response is examined for evaluation at the primary output pins (DOUT and SOUT) at time 740 ns, as specified by the timing definition in the TSTL2 file. 4. The system clock is pulsed once to capture the internal states (n1, n2, n5 and n6) into the flip-flops. Figure B–9 Capturing the Internal States into the Flip-Flops

DIN1 DIN2

1

c1

ff1 n1

1

TI

1

n2

1

1 0

CLK SEN

350

1

ff3 n5 1

Q

D TI

n7 MUX 0 c5 1

1

TE

ff2

0 0

Q

D

TE

SIN

c3

1

TI

DIN4

n3

TE

c2

DIN3

Q

D

1

n4

c4

ff4

n6 0 D TI TE

DOUT

0

Q

0

n8

SOUT

Cycles 8–11 (Scan Shift Mode: 700–1100 ns) Following is the scan test vector for the next scan shift mode: SP (SC1I) 0100, SP (SC1O) LHHH;

Since the two SP statements are delimited by a comma, the scan chain is loaded while simultaneously it is unloaded. These SP statements are equivalent to the following: SIN

SOUT

L H H H

0000 0000 0000 0000

P01; P11; P01; P01;

/* /* /* /*

8 */ 9 */ 10 */ 11 */

Figure B–10 illustrates the process of serially shifting the scan chain. As shown in this figure, the output response observed at SOUT in cycles 8 to 11 is expected to be 0111 (LHHH), which matches the expected outputs specified in the SP statement. Figure B–10 Scan-in and Scan-out Process

SIN

SOUT

0

1

1

1

0

Cycle 8

1

0

1

1

1

0

Cycle 9

0

1

0

1

1

1

Cycle 10

0

0

1

0

1

1

0

0

1

0

1

0

0

1

0

ff2

ff1

ff3

ff4

Cycle 11

Cycle 12– From cycle 12 onwards, the same process as cycles 3–11 is repeated using different vectors.

351

.....

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

B

352

TSTL2 Scan Test Data Description B.5 Scan Test Sequence

Synopsys-DFT User Guide

Index

Index Symbols $TOSH_ROOT directory structure 86

Numerics 3-state buses rules 38 scan design rule checking 208 3-state output buffers JTAG rule 60

A add clocks command (TetraMAX) 142, 147, 170 add faults command (TetraMAX) 175 add pi constraints command (TetraMAX) 171 add pi equivalences command (TetraMAX) 170 asynchronous set/reset ports defining in TetraMAX 170 ATPG 5, 11 ATPG design flow 160 ATPG model building in TetraMAX 169 ATPG patterns verifying 217 ATPG test cycles 184 atpg.config file 230, 232 automatic test pattern generation. See ATPG

B Basic-Scan ATPG. See combinational ATPG bidirectional buffers JTAG rules 60 bidirectional enable lines path delays 52 bidirectional ports check_test transcript 208 on a submodule 115 rules 39 SPF 134 used as a clock 115 binary pattern file reading 180 BIST 7

black boxes 256 check_test transcript 105, 116 defining 169 testability problems 44, 47 block-by-block scan synthesis 91 Boundary-Scan Description Language. See BSDL file boundary-scan register 17 boundary-scan. See JTAG boundary-scan BSD Compiler known problems 295 limitations 257 BSD Compiler commands check_bsd 279, 287 create_bsd_patterns 280 insert_bsd 276 optimize_bsd 278 preview_bsd 276 read_pin_map 269 set_bsd_compliance 285 set_bsd_configuration 273 set_bsd_control_cell 284 set_bsd_data_cell 284 set_bsd_instruction 275 set_bsd_linkage_port 283 set_bsd_pad_design 270 set_bsd_signal 269 set_bsr_cell_type 278 write_bsdl 279 write_test 281 BSD Compiler design kit 72, 84, 290 BSD Compiler library 72 BSD Compiler variables test_bsd_allow_tolerable_violations 278 test_bsd_control_drive_limit 278 test_bsd_manufacturer_id 273 test_bsd_optimize_control_cell 278 test_bsd_part_number 273 test_bsd_version_number 273 write_test_formats 281 BSDL file 58

353

Index

generating 279 BSR. See boundary-scan register buffer trees 29, 104 BUILD mode 166, 167, 168 build-in self-test 7 bus contention/float checking run drc transcript 211 bus keepers run drc transcript 212 BYPASS instruction 56 bypass register 17

C capture clock group 36 defining in TetraMAX 170 capture cycle depth 192 capture mode 10 capture procedure dual-clocked scan format 132 modifying an SPF from TetraMAX 152 single-clocked scan format 124 modifying an SPF from TetraMAX 146 single-cycle 186 three-cycle 186 chain test 177, 217 change_names command (DFT Compiler) 95, 109 change_names script 95 check_bsd command (BSD Compiler) 279, 287 -verbose option 289 verifying the inferred instructions 289 verifying the JTAG registers 288 verifying the TAP 288 check_test command (DFT Compiler) 94, 105, 108, 205 bidirectional ports 208 combinational feedback loops 209 scan chains 205 sequential cells 207 CHGCIR file 305, 306 CLAMP instruction 56 clock ports defining in TetraMAX 170 clock rule checking

354

Synopsys-DFT User Guide

run drc transcript 214 clock tree synthesis. See CTS combinational ATPG 192 combinational feedback loops 32 bypassing megacells 47 check_test transcript 209 rules 40 command file (TetraMAX) 163 compile command (DFT Compiler) 29, 30, 102 compile -scan command (DFT Compiler) 90 compliance-enable ports 61 compliance-enable ports. See JTAG-enable ports CONST statement (TSTL2) 342 controllability 6 Core Test 7 create_bsd_patterns command (BSD Compiler) 280 create_port command (DFT Compiler) 111 create_test_clock command (DFT Compiler) 107 CTS 29, 104

D DCAL 219, 313 DCF file 291 DCSDF file 219, 313 DECLARE block (TSTL2) 178, 334, 336 DECLARE file 231 deeply buried logic states 44 defect level 4 Design Compiler library 84, 87 design flow internal-scan and JTAG boundary-scan 75 internal-scan and memory BIST insertion 77 internal-scan insertion 74 memory BIST insertion 76 design kits 84 DesignWare libraries 88 DEV file 291 device identification code 57 device identification register 17 configuring 273 DFT Compiler commands change_names 95, 109 check_test 94, 105, 108, 205 compile 102 compile -scan 90

Synopsys-DFT User Guide

create_port 111 create_test_clock 107 insert_dft 94 insert_scan 90, 91, 94, 106 remove_design 118 report_test 108, 205 report_test -atpg_conflicts 208 report_test -scan_path 206 set_dont_touch_network 104 set_dont_use 110 set_scan_configuration 100 set_scan_path 114 set_scan_signal 103, 111, 112, 113, 114, 115 set_scan_transparent 210 set_signal_type 115 set_test_hold 102 write_test_protocol 109 DFT Compiler library 72 DFT Compiler variables test_default_bidir_delay 107 test_default_delay 107 test_default_period 107 test_default_strobe 107 test_stil_netlist_format 109 DFT considerations area impact 67 I/O pin requirements 67 internal-scan 66 JTAG boundary-scan 66 memory BIST 66 selecting DFT methodologies 66 DFT tools supported 84 direct-access approach 7 DISPLAY environment variable 178, 198 DL 4 DRC mode 166, 167, 169 dual-clocked scan design 25 inserting buffer trees 30 PrimeTime scripts 223, 318 scan test sequence 133 test timing parameters 49 timing verification 221, 316 TSTL2 timing definition 222, 316 dummy module creating 117

Index

RAM 117 removing 118

E environment variables (UNIX) 87 EXTEST instruction 20, 56

F Fast-Sequential ATPG. See sequential ATPG fault coverage 4, 181, 195 fault list 193 creating 193 fault models 5 fault summary report 176 feedback path sensitization checking run drc transcript 216 fixed logic values at nodes 43 flip-flop rules 31 FSA file 161, 164, 226, 242, 253, 305, 307

G GEMINISO 71

H hierarchical delimiter (TetraMAX) 168 HIGHZ instruction 56 implementation rule 59 hookup pins 104 HSS 218

I I/O buffers for the TC240 to TC260 series 114 IDCODE instruction 56 IEEE Std 1149.1. See JTAG boundary-scan INIT file 230, 236 insert_bsd command (BSD Compiler) 276 insert_dft (DFT Compiler) 94 insert_dft command (DFT Compiler) 29, 30, 90, 91 insert_scan command (DFT Compiler) 29, 30, 90, 91, 94, 106 instance names Verilog-HDL 198 instruction register 16 internal-scan design 7, 9 general design flow 74 I/O pin requirements 27 penalty 12 scan test sequence 10

355

Index

INTEST instruction 56 implementation rule 59 IOCELL file 292 IOPARAM file 219, 313

J JTAG boundary-scan 8, 13 architecture 13 assigning specific BSR cell types 284 avoiding BSR cells on some ports 283 checking IEEE Std 1149.1 compliance 278 configuring the device identification register 273 defining I/O softmacrocells 270 defining test access ports 269 design flow 259 device identification code 57 formatting test patterns 281 general test sequence 19 generating a BSDL file 279 generating test patterns 280 generating the boundary-scan logic 276 handling of custom I/O cells 292 I/O pin requirement 68 IEEE 1149.1 compliance checking 287 implementing IEEE Std 1149.1 instructions 56, 275 JTAG insertion and verification flow 259 open-drain bidirectional buffers 258, 295 optimizing the boundary-scan register 277 pin-sharing 62 previewing the boundary-scan design 276 reading the design 268 reading the PPMAP file 269 reset 63 rules for implementing optional instructions 59 rules for the EN and TN pins of I/O buffers 59 script for JTAG insertion and verification 260 script for JTAG verification 265 selecting the boundary-scan configuration 273 setting synthesis specifications 268 synthesis process 277 TAP requirements 258 top module requirements 257 Toshiba custom JTAG components 258 verification-only flow 264

356

Synopsys-DFT User Guide

JTAG instructions 56 JTAG IP cores 153, 233, 238, 258 JTAG logic disabling 153 JTAG test patterns 58 JTAG-enable ports 62, 63 avoiding putting BSR cells 284 set_bsd_compliance command 285 set_bsd_data_cell command 285 setting 285

L latch rules 32 library clause VHDL 199 library environment 87 linkage ports 283 load_unload procedure dual-clocked scan format 131 modifying an SPF from TetraMAX 152 single-clocked scan format 124 modifying an SPF from TetraMAX 146 LSF file 162, 164, 165, 242, 252, 305, 307 format 249 LSF2DEF 165, 188, 252, 308 functions 189 running 190 Ltran 198 LTRAN_SHELL environment variable 178, 198

M MacroDefs construct dual-clocked scan 132 single-clocked scan 125 MAIN 114 man command (TetraMAX) 216 manufacturer identify code 57 mapped netlist without scan 110 master_observe procedure 185 dual-clocked scan format 131 modifying an SPF from TetraMAX 152 MDLGEN 191 megacells 44, 46, 47

Synopsys-DFT User Guide

memory BIST general design flow 76 I/O pin requirement 68 memory models 191 MemoryBIST Design System 72 MGDATA file 191 mixed-clock scan chain 42 multidriver net checking run drc transcript 215 multiple system clock design 37 multiplexed flip-flop scan 24

N naming rules 95 NETMOD 306 non-scan rule checking run drc transcript 215

O observability 6 open-drain bidirectional buffers (JTAG) 258, 295 optimize_bsd command (BSD Compiler) 278

P parallel-load simulation 172, 188, 217, 225, 334 PATH statement (TSTL2) 342 Path Test 29, 30 PATTYPE statement (TSTL2) 339 PLS. See parallel-load simulation port-to-pin mapping file. See PPMAP file PPA file 291 PPMAP file 290 creating 269 reading 269 PPMAPGEN 269, 272, 290 custom I/O cells 292 I/O database 292 syntax 290 preview_bsd command (BSD Compiler) 276 primary input constraints defining in TetraMAX 171 PrimeTime 218, 313 PrimeTime commands set_case_analysis 311 set_false_path 312 PrimeTime scripts dual-clocked scan design 223, 318

Index

single-clocked scan design 220, 315 PrimeTime Sign-Off System 71 Procedures construct dual-clocked scan 131 single-clocked scan 123 PSSCAN instruction 233, 236, 238 PTSO 71

R RAM dummy module 117 read faults command (TetraMAX) 193 read netlist command (TetraMAX) 142, 147, 168, 169 read_pin_map command (BSD Compiler) 269 remove_design command (DFT Compiler) 118 report faults command (TetraMAX) 181, 182 report rules command (TetraMAX) 216 report scan cells command (TetraMAX) 172 report scan chains command (TetraMAX) 172, 241 report scan path command (TetraMAX) 173, 241 report summaries command (TetraMAX) 176 report summaries sequential_depths commands (TetraMAX) 192 report violations command (TetraMAX) 216 report_check command (DFT Compiler) scan chains 206 report_test -atpg_conflicts command (DFT Compiler) 208 report_test command (DFT Compiler) 108, 205 report_test -scan_path command (DFT Compiler) 206 run atpg command (TetraMAX) 175, 177 run atpg -fast_sequential_only command (TetraMAX) 192 run build_model command (TetraMAX) 142, 147, 169 run drc command (TetraMAX) 172, 211 bus contention/float checking 211 clock rule checking 214 feedback path sensitization checking 216 multidriver net checking 215 non-scan rule checking 215 scan chain operation checking 214 simulating test protocol procedures 213 run pattern_compression command (TetraMAX) 175

357

Index

RUNBIST instruction 56

S SAMPLE/PRELOAD instruction 56 scan assembly 9, 90 SCAN block 341 scan capture mode. See capture mode scan chain names 141 scan chain operation checking run drc transcript 214 scan chains 9 building 106 building at the top level 91 building in each module 93 check_test transcript 205 controlling with JTAG logic 153 different branches of a clock 42 mixed-clock 42 number and balancing 41 report_test transcript 206 static timing analysis 312 TSTL2 definition 334 scan clock ports 28 sharing functional input ports with 113, 139 static timing analysis 311 scan clocks SCMCLK statement (TSTL2) 338 SCSCLK statement (TSTL2) 338 scan design rule categories, TetraMAX 210 scan design rule checking correcting common errors 115 DFT Compiler 94, 105, 108, 205 TetraMAX 172, 210 scan design rule severity TetraMAX 210 scan design rules 31 3-state buses 38 bidirectional pins 39 combinational feedback loops 40 flip-flops 31 latches 32 system clocks 33 scan design. See internal-scan design scan flip-flop types 101 scan insertion 9

358

Synopsys-DFT User Guide

scan path. See scan chains scan replacement 9, 90 Scan Shift Enable port 27 buffer tree 29 SCSEL statement (TSTL2) 339 scan shift mode 10 scan style dual-clocked scan 25 selecting 100 single-clocked scan 24 scan synthesis 9 block-by-block 91 DC script example 98 overall flow 90 step-by-step procedure 100 Scan Test Enable port 27 static timing analysis 311 scan test patterns saving in ATPG binary storage format 180 size 69 splitting into multiple TSTL2 files 179 writing out in TSTL2 format 177 scan test ports creating 111 explicitly assigning to scan chains 114 identifying 103 specifying existing ports with I/O buffers 113 specifying existing ports without I/O buffers as 112 specifying nonexistent ports as 111 types and requirements 27 scan test sequence cycle-by-cycle 346 dual-clocked scan design 133 overall flow 10 single-clocked scan design 125 scan-chain reordering 172, 173, 253, 302 in the conventional layout flow 304 in the Layout-Verilog Interface flow 307 scan-in port 28 using a functional port as 136 scan-out port 28 using a bidirectional port 135 using a functional output port as 137 ScanStructures construct

Synopsys-DFT User Guide

dual-clocked scan format 129 modifying an SPF from TetraMAX 151 single-clocked scan format 123 modifying an SPF from TetraMAX 146 SCANTEST instruction 153, 155, 233, 236, 238 SCE file 161, 164, 241 example 173 generating 172 SCMCLK statement (TSTL2) 338 SCR. See scan-chain reordering SCR_BSDC file creating 290 reading 272 SCRDEF file 162, 165, 252, 308 SCRTST 306, 308 command syntax 253 functions 253 SCSCLK statement (TSTL2) 338 SCSEL statement (TSTL2) 339 sequential ATPG 192 recommended flow 192 sequential cells check_test transcript 207 set atpg -auto command (TetraMAX) 176 set atpg -capture_cycles command (TetraMAX) 192, 194 set atpg command (TetraMAX) 175, 176, 177 set build -black_box command (TetraMAX) 169, 193 set build -hierarchical_delimiter command (TetraMAX) 168, 199 set drc command (TetraMAX) 171 set faults command (TetraMAX) 175, 181, 182 set patterns command (TetraMAX) 180 set_bsd_compliance command (BSD Compiler) 285 set_bsd_configuration command (BSD Compiler) 273 set_bsd_control_cell command (BSD Compiler) 284 set_bsd_data_cell command (BSD Compiler) 284 set_bsd_instruction command (BSD Compiler) 275 set_bsd_linkage_port command (BSD Compiler) 283 set_bsd_pad_design command (BSD Compiler) 270

Index

custom I/O cells 292 known problem 298 set_bsd_signal command (BSD Compiler) 269 set_bsr_cell_type command (BSD Compiler) 278 set_case_analysis command (PrimeTime) 311 set_dont_touch_network command (DFT Compiler) 104 set_dont_use command (DFT Compiler) 110 set_false_path command (PrimeTime) 312 set_scan_configuration command (DFT Compiler) 100 -dedicated_scan_ports option 101, 102 set_scan_path command (DFT Compiler) 114 set_scan_signal command (DFT Compiler) 103, 111–115 -chain option 114 -hookup option 113, 114 -sense option 114 set_scan_transparent command (DFT Compiler) 210 set_signal_type command (DFT Compiler) 115 set_test_hold command (DFT Compiler) 102 shadow effects 44 shadow register 184 shadow_observe procedure 184 dual-clocked scan 132 single-clocked scan 124 signal type attributes 104 SignalGroups construct dual-clocked scan format 129 modifying an SPF from TetraMAX 151 sign-off systems 71 simulating test protocol procedures run drc transcript 213 single stuck-at fault model 6 single-clocked scan design 24 inserting buffer trees 29 preventing timing problems 42 PrimeTime scripts 220, 315 scan test sequence 125 test timing parameters 48 timing verification 219, 313 TSTL2 timing definition 219, 314 skew control 34 SP statement (TSTL2) 334, 344

359

Index

SPA file 161, 164, 241 example 174 generating 173 SPF 161 asynchronous set/reset input signals 125, 132 controlling bidirectional ports 134 creating in DFT Compiler 120 creating in TetraMAX 121 creating with SPFGen 120, 162 disabling JTAG logic 153 dual-clocked scan capture procedure 132 generated by TetraMAX 147 load_unload procedure 131 MacroDefs construct 132 master_observe procedure 131 organization 127 Procedures construct 131 ScanStructures construct 129 shadow_observe procedure 132 SignalGroups construct 129 test_setup macro 132 Timing construct 129 generated by DFT Compiler modifying scan chain names 141 sharing a functional input port with a scan-in port 136 sharing a functional output port with a scan-out port 137 sharing functional input ports with scan clock ports 139 single-clocked scan capture procedure 124 generated by TetraMAX 142 load_unload procedure 124 MacroDefs construct 125 organization 122 Procedures construct 123 ScanStructures construct 123 shadow_observe procedure 124 test_setup macro 125 using a bidirectional port as a scan-out port 135 using the JTAG SCANTEST instruction 155 writing in DFT Compiler 109 SPFGen 120, 162

360

Synopsys-DFT User Guide

command syntax 231 functions 229 input files 229, 230 output files 229, 230 SPFGENLOG file 231 STIL 65 STIL procedure file. See SPF stuck-at-0 fault 6 stuck-at-1 fault 6 SYSCLK statement (TSTL2) 337 system clock ports SYSCLK statement (TSTL2) 337 system clock rules 33

T TAP 15, 61 pin-sharing 62 TAP controller 16, 17 state diagram 17 TCK (Test Clock Input) 15 TDCMD file 230 TDI (Test Data Input) 16 TDO (Test Data Output) 16 Test Access Port. See TAP test coverage 182, 195 obtaining quick estimates 176 test data registers 17 TEST mode 166, 167, 172 test point insertion 45 test protocol defining 106 test protocol file. See SPF test synthesis 5 test timing parameters determinants 50 dual-clocked scan 49 single-clocked scan 48 test_bsd_allow_tolerable_violations variable (BSD Compiler) 278 test_bsd_control_drive_limit variable (BSD Compiler) 278 test_bsd_manufacturer_id variable (BSD Compiler) 273 test_bsd_optimize_control_cell variable (BSD Compiler) 278

Synopsys-DFT User Guide

test_bsd_part_number variable (BSD Compiler) 273 test_bsd_version_number variable (BSD Compiler) 273 test_default_bidir_delay variable (DFT Compiler) 107 test_default_delay variable (DFT Compiler) 107 test_default_period variable (DFT Compiler) 107 test_default_strobe variable (DFT Compiler) 107 test_disable_find_best_scan_out variable (DFT Compiler) 102 test_setup macro dual-clocked scan format 132 modifying an SPF from TetraMAX 152 single-clocked scan format 125 modifying an SPF from TetraMAX 146 test_stil_netlist_format variable (DFT Compiler) 109 testability 6 testable fault coverage 182, 195 test-ready compile 103 test-ready compile. See scan synthesis TetraMAX BUILD mode 168 building the ATPG model 169 command file 163 command modes 163 declaring primary input constraints 171 defining asynchronous set/reset ports 170 defining capture clock groups 170 defining clocks 170 design flow 160, 166 DRC mode 169 generating an SCE file 172 generating an SPA file 173 generating fault summary report 176 invoking 162 memory models 191 performing DRC 172 reading the library 168 reading the netlist 169 running ATPG 175 setting the hierarchical delimiter 168 specifying the pattern generation effort 175

Index

TEST mode 172 writing out a TSTL2 file 177 TetraMAX commands add clocks 142, 147, 170 add faults 175 add pi constraints 171 add pi equivalences 170 man 216 read faults 193 read netlist 142, 147, 168, 169 report faults 181, 182 report rules 216 report scan cells 172 report scan chains 172, 241 report scan path 173, 241 report summaries 176 report summaries sequential_depths 192 report violations 216 run atpg 175, 177 run atpg -fast_sequential_only 192 run build_model 142, 147, 169 run drc 172, 211 run pattern_compression 175 set atpg 175, 176, 177 set atpg -auto 176 set atpg -capture_cycles 192, 194 set build -black_box 169, 193 set build -hierarchical_delimiter 168, 199 set drc 171 set faults 175, 181, 182 set patterns 180 write drc_file 121, 129, 142, 147 write faults 193 write patterns 177, 178, 179, 180 TetraMAX design kit 72, 84 system requirements 228 TetraMAX library 85, 88 reading 168 TFSA 164, 188, 305 command input examples 244 command syntax 243 functions 188, 240 input files 241 messages 244 output files 241

361

Index

running 189 TFSALOG file 242 Timing construct dual-clocked scan format 129 modifying an SPF from TetraMAX 151 timing verification 218 dual-clocked scan design 221, 316 single-clocked scan design 219, 313 TMCMD file 161, 231 TMS (Test Mode Select Input) 16 Transition Test 29, 30 TRST* (Test Reset Input) 16, 63 tsb.config file 230, 237 TSC 225 TSTL2 generation 178 file size 196 in shell mode 198 required disk space 197 splitting into multiple files 179 TSTL2 serialized scan vector file 334

U unknown cell violations 116 USERCODE instruction 56

V VITALSO 71 VOYSO 71 VPPA file 291 VSO 71

W wrapper-scan approach 7 write drc_file command (TetraMAX) 121, 129, 142, 147 write faults command (TetraMAX) 193 write patterns command (TetraMAX) 177, 178, 179, 180 write_bsdl command (BSD Compiler) 279 write_test command (BSD Compiler) 281 write_test_formats variable (BSD Compiler) 281 write_test_protocol command (DFT Compiler) 109

362

Synopsys-DFT User Guide