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 scan-

chain 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
♦ Boundary Scan Reference Manual

♦ BSD Compiler User Guide
♦ Scan Synthesis Reference Manual
♦ Scan Synthesis User Guide
♦ Test Automation Tutorial
♦ TetraMAX ATPG User Guide
iv
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 Scan Implementation Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 I/O Pin Requirements for Scan Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Scan Design Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Scan Chain Number and Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5 Fixing Testability Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6 Determining Timing Parameters for Scan Test Patterns . . . . . . . . . . . . . . . . . . . . . . 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 Overview of Test-Ready Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2 Naming Rules for Ports, Cells and Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 Sample DC Script for Scan Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.4 Step-by-Step Scan Synthesis Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.5 Considerations for Scan Synthesis Using DFT Compiler . . . . . . . . . . . . . . . . . . . . 110
v
Contents Synopsys-DFT User Guide
Chapter 7 STIL Procedure File (SPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7.1 Creating an SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.2 SPF Organization for Single-Clocked Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.3 SPF Organization for Dual-Clocked Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.4 Controlling Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.5 SPF Description for Scan-Out Ports with Bidirectional Buffers . . . . . . . . . . . . . . . 135
7.6 Pin-Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.7 Editing an SPF Generated by DFT Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.8 Editing an SPF Generated by TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.9 SPF for a Design with JTAG Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Chapter 8 Using TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.2 Running TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
8.3 Various Test Coverage Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.4 ATPG Test Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.5 Running TFSA and LSF2DEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.6 Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
8.7 Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
10.2 SPFGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
10.3 TFSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
10.4 LSF2DEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
10.5 SCRTST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Chapter 11 JTAG Boundary-Scan Insertion Using BSD Compiler . . . . . . . . . 255

11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
11.2 BSD Compiler Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
11.3 JTAG Design and Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
11.4 Step-by-Step JTAG Boundary-Scan Design Procedure . . . . . . . . . . . . . . . . . . . . . . 268
11.5 Miscellaneous Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
11.6 JTAG Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
11.7 BSD Compiler Design Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
11.8 Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
vi
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 General Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
A.2 1-Pass Scan Synthesis Using DFT Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
A.3 TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
A.4 Verifying the Scan Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Appendix B TSTL2 Scan Test Data Description . . . . . . . . . . . . . . . . . . . . . . . 333

B.1 TSTL2 Scan Vector File Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
B.2 DECLARE Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
B.3 Scan Definition Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
B.4 Scan Pattern Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
B.5 Scan Test Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
vii
Contents Synopsys-DFT User Guide
viii
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 Synopsys-DFT User Guide
x
CMOS ASIC Design Manual
Part 1
DFT Fundamentals
1
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
Understanding DFT Concepts
1 1.1 Introduction
1.1 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
.....
1.1 Introduction
Figure 1–1 Defect Level as a Function of Yield and Fault Coverage
100
90 Yield
80 10
20
Defect Level (%)
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
1 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
.....
1.1 Introduction
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
1 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.
8
.....
1.2 Internal-Scan
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
D Q
Scan Replacement
D Q D Q
CP QN = TI
CP QN TI CP QN
TE
TE
Standard D Flip-Flop
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
1 1.2 Internal-Scan
Figure 1–4 Scan Chain Through a Scanned Design
Scan-in Scan-out
F/F F/F
Primary Comb Comb Primary

Inputs Logic Comb Logic Outputs
Logic F/F
Island Island
Island
F/F
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
.....
1.2 Internal-Scan
Figure 1–5 Scan Test Sequence

1. Test vector values are
shifted in.
Scan
Shift 1. Test vector values are serially
shifted into scan flip-flops F/F F/F
Mode through the scan chain. 2. The test
(Scan-in) pattern is Comb Comb Comb
applied to the Logic F/F Logic F/F Logic
primary inputs. Island Island Island
Scan
Capture 2. A functional test vector is F/F F/F
applied to the primary inputs.
Mode
This completes test stimulus

input to the combinational logic.
F/F F/F
3. The output response is 3. The response
checked at the primary outputs Comb Comb Comb is checked at
and compared to the expected Logic F/F Logic F/F Logic the primary
response. Island Island Island outputs.
4. The response F/F F/F
from the comb
4. The clock is exercised to logic is clocked
capture the response from the into scan
combinational logic into scan flip-flops.
flip-flops.
5. The contents of scan
flip-flops are shifted out.
Scan
Shift 5. The contents of the scan
Mode flip-flops are serially shifted out F/F F/F
from the scan chain and Comb Comb Comb
compared to the expected
response. (Scan-out) Logic F/F Logic F/F Logic
Island Island Island
F/F 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
1 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:
■ 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.
12
.....
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
1 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
IC pad
From core
BSR Cell BSR Cell logic
BSR Cell BSR Cell
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 System
Inputs Boundary-Scan Register Outputs
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
TCK
Controller
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
■ 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
Figure 1–8 TAP Controller State Diagram
1 Test-Logic-Reset
0
1 1 1
0 Run-Test/Idle Select-DR-Scan Select-IR-Scan
0 0
1 1
Capture-DR Capture-IR
0 0
Shift-DR 0 Shift-IR 0
1 1
1 1
Exit1-DR Exit1-IR
0 0
Pause-DR 0 Pause-IR 0
1 1
0 0
Exit2-DR Exit2-IR
1 1
Update-DR Update-IR
1 0 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
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 IC-B
BSR BSR
Inst. Reg Inst. Reg

TDI TAPC TAPC TDO
TCK
01100... 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 IC-B
BSR BSR
Inst. Reg Inst. Reg

11111... TDI TDO
(Instruction Code) TAPC TAPC
TCK
00000... TMS
TRST
3. The controller is moved to the Shift-DR state via the Update-IR state.
IC-A IC-B
BSR BSR
Inst. Reg Inst. Reg

TDI TAPC TAPC TDO
TCK
11100... TMS
TRST
20
.....
4. Test data is shifted into the boundary-scan register from the TDI input.
IC-A IC-B
BSR BSR
Inst. Reg Inst. Reg

01100... TDI TDO
(Test Data) TAPC TAPC
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
Inst. Reg 1 Inst. Reg

TDI TAPC TAPC TDO
TCK
1100 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 IC-B
BSR BSR
Inst. Reg Inst. Reg

TDI TAPC TAPC TDO
LHLH...
(Expected Values)
TCK
TMS
TRST
21
22
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 2.1 Scan Implementation Alternatives
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
Scan Replacement D
D Q D Q D Q Q
CP QN = TI
CP QN TI CP QN QN
TE
TE
Standard D Flip-Flop
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 Q D Q Q
CP QN = TI
TI SO CP QN QN
TE
TE
Scan Flip-Flop 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
.....
2.1 Scan Implementation Alternatives
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
2 2.1 Scan Implementation Alternatives
Figure 2–3 Dual-Clocked Scan Flip-Flop
Latch1 Latch2
Scan Replacement D Q
D Q D Q
CP
=
CP QN SI QN QN
A
CP
B SO
Standard D Flip-Flop SI
A
Scan Flip-Flop SO
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
2 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 Chain 1

Scan Clock A
System Input/ A B A B
Scan Clock 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
2 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 A
B
30
.....
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
2 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 Non-Scan Latches Flip-Flops To Be Scanned
Combinational Logic
Combinational Logic
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
Figure 2–12 Clock Divider
(a)
Clock
Divider
is
t Th Scan Flip-Flops
Clock
No
(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
Clock skew can cause
MUX hold violations during
testing.
CTS2
Clock
Scan Test Enable 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
Figure 2–14 Gated Clocks
Enable Logic
Test Enable
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
CLK2 Top Level
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

■ 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
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
h is
T
A
B
Combinational
Logic
o t
N
Flip-Flops
Decoder
A
B
Combinational
Logic
38
.....
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 Decoder

A
Test Input 2 B
Test Enable
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
Figure 2–18 Controlling Bidirectional Pins
Scan Shift Enable

(Held at 1 During Scan Shift)
System Enable
Bidirectional Pin
Logic
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
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
2 2.4 Scan Chain Number and Balancing
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.
h is Q Q
TI
t T TI TI
Clock1
N o
Clock2
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.
TI
Q
h is TI
Q
TI
Q
Clock
t T
No
Divider
Clock
Test Enable
You can prevent timing problems by the following ways:

■ 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.
42
.....
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

43
2 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 Any signal between the black box
(primary inputs) and the black box and scan flip-flops that is affected
that pass only into the black box by the outputs of the black box
are unobservable. 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 MUX
VDD 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
The output of a multiple-input
during testing.
AND gate has poor controllability.
Test-Point
Control Input
Test Enable
Cancels the effect of the OR gate
during normal functional operation.
45
2 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 Create a direct path
flow through the RAM, making them to an external output pin.
difficult to observe.
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 Functional Output /

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

Test Point
0/1 Control Input
Test Enable
46
.....
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
D Q
From Previous Scan Flip-Flop SI SO To Next Scan Flip-Flop
System Clock
Test Enable
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 Combinational
Logic Logic
Test Enable
Note: Make sure that bypassing a megacell does not create combinational
feedback loops.
47
2 2.6 Determining Timing Parameters for Scan Test Patterns
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
Tstb
Output Strobe
Tdc
System/Scan Clock Pin
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
48
.....
■ 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
Tstb Tstb
Output Strobe
Tdc
System Clock Pin
Twc
Scan Clock A Pin Tdca
(Master Clock) Tdca
Scan Clock B Pin Tdcb
(Slave Clock) 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
■ 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 Dff F/F Dfo
IN2 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
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
Bidirectional Pins
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
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
54
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
Using JTAG Boundary-Scan Methodology
3 3.1 Implementing Instructions
3.1 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 All 1’s (1111....)
and TDO to bypass the IC’s boundary-scan chain.
SAMPLE/PRELOAD In Sample mode, samples data traffic flowing through the input Arbitrary
and output pads of an IC. In Preload mode, initializes the
boundary-scan register with test values.
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
.....
3.1 Implementing Instructions
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
3 3.2 JTAG Boundary-Scan Data
3.2 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
3 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)
EN
h is EN
t T System System
No
Logic Logic
TN 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)
i s
Th
EN
EN
ot TN
System
Logic
TN System
Logic
N EN
TN
EN
TN
60
.....
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
System
TN 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
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
TDO /
TMS / Other Test Input TMS TDO Other Test Output
TCK / Other Test Input TCK TDO-EN
TRST / Other Test Input TRST
TDI / Other Test Input TDI
Non-JTAG
Test Logic
62
.....
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
64
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
DFT Considerations
4 4.1 Selecting DFT Methodologies
4.1 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
.....
DFT Considerations
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
Scan-out Output Shareable Serial data output
Required for each scan chain
67
DFT Considerations
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
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 Test data output pin
JTAG Enable 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
BIST Enable Input – 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)
BIST Data Out Output Shareable Test response output pin
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
.....
DFT Considerations
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
Test Mode 1 Test Mode 2 Clock Data In 1 Data In 2 Data In 3 Data Out 1 Data Out 2
State
Normal System Functional Functional Functional Functional Functional

0 0
Operation Clock Data Input Data Input Data Input Data Output Data Output
Scan Test Scan Shift
1 0 Scan Clock Scan-in 1 Scan-in 2 Scan-out 1 Scan-out 2
Mode Enable
BIST BIST Shift BIST Test
BIST Mode 0 1 BIST Clock — —
Enable Enable Out
Other Test Test Data Test Data Test Data Test Data Test Data
1 1 Test Clock
Mode Input Input Input Output 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
■ 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.
70
.....
DFT Considerations
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 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
.....
DFT Considerations
■ 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 4.3 Design-for-Test Flows
4.3 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 2. Scan Design

(Synthesis / Scan Insertion) 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
.....
DFT Considerations
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 Top-Level Design

(Black Boxes/Gate) (RTL/Gate/db)
1. BSD Compiler
(Synthesis / JTAG Insertion & Verification)
JTAG Test Patterns Top-Level Design Netlist Subdesigns

(TSTL2) w/ JTAG (Gate) (RTL/Gate/db)
2. DFT Compiler
(Synthesis / Scan Insertion)
Netlist with JTAG and Scan

(Gate)
4. TetraMAX
(ATPG)
3. BSD Compiler ATPG Test Patterns

(JTAG Verification) (TSTL2)
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
• 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
.....
DFT Considerations
Figure 4–4 Typical Design Flow for MemoryBIST
Design
BISTGROUP File
(RTL/Gate/db)
1. bist_lib_gen
(BIST Generation)
DC script RTL BIST Logic
Design Compiler Design Compiler

(Synthesis) (Synthesis)
Gate-Level BIST Logic Gate-Level Netlist
2. bist_insert
(BIST Insertion / Test Pattern Generation)
Gate-Level
TSTL2 Test Data
BISTed Netlist
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
Figure 4–5 Typical Design Flow Using MemoryBIST with DFT Compiler and TetraMAX
Design
BISTGROUP File
(RTL/Gate/db)
2. Manual Editing 1. bist_lib_gen

(Add scan commands.) (BIST Generation)
3. DFT Compiler
DC script RTL BIST Logic (Synthesis / Scan Insertion)
3. DFT Compiler
(Synthesis / Scan Insertion)
Gate-Level Gate-Level
Scanned BIST Logic Scanned Netlist
4. bist_insert
(BIST Insertion / Test Pattern Generation)
Gate-Level TSTL2 BIST

BISTed Netlist Test Data
5. Manual Editing or DFT Compiler

(BIST Scan Connection)
Gate-Level
SPF
Scanned/BISTed Netlist
6. TetraMAX
(Test Pattern Generation)
ATPG Patterns
(TSTL2)
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
.....
DFT Considerations
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
80
Part 2
Using the Synopsys DFT Tools
81
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
Setting Up the Design Environment
5 5.1 Synopsys DFT Tools and Toshiba Design Kits
5.1 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
■ 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
■ Synopsys TetraMAX
■ Toshiba TetraMAX design kit
84
.....
5.1 Synopsys DFT Tools and Toshiba Design Kits
■ 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
5 5.2 Installing and Setting Up Toshiba’s Design Kits and Libraries
5.2 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
.....
5.2 Installing and Setting Up Toshiba’s Design Kits and Libraries
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_<platform> /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
5 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
Scan Synthesis Methodology Using DFT Compiler
6 6.1 Overview of Test-Ready Compile
6.1 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.)
Set a scan style and constraints.

(set_scan_configuration,
Describe design constraints. set_scan_signal,
set_test_hold)
Synthesize a design. Perform scan synthesis.

(compile) (compile -scan, insert_scan)
Evaluate the design. Check scan design rules.

(check_design, etc.) (check_test, report_test)
Set ATPG timing attributes.

Write out the design. Write a test protocol file.
(write) (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
Test-ready compile maps all sequential cells directly to
scan flip-flops. Scan flip-flops are not scan-chained
Set synthesis constraints together; a loop is connected from the scan-out pin of a
and scan style. flip-flop to the scan-in pin of the same flip-flop. All scan
control pins are tied to ground.
compile -scan FD1SF FD1SF
SI SO SI SO
Gate-Level Design
Identify scan ports and

check design rules.
Temporary connections are deleted and replaced by
actual scan connections.
insert_scan
FD1SF FD1SF
Gate-Level SI SO SI SO
Scanned Design
Scan-in 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
Figure 6–3 Building Scan Chains at the Top Level of a Design
Module A (RTL) Module B (RTL)
No scan port No scan port
DFT Compiler DFT Compiler

compile -scan compile -scan
Gate-level Gate-level
No scan port No scan port

Mapped to scan flip-flops Mapped to scan flip-flops
No scan chain 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:

■ 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.
92
.....
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 Existing scan ports
DFT Compiler DFT Compiler

compile -scan compile -scan
insert_scan insert_scan
Gate-level Gate-level
A scan chain is stitched A scan chain is stitched

and connected to scan and connected to scan
ports. 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
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
6 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_9, \
bc_10, bc_11, bc_12, bc_13, bc_14, bc_15, bc_16, bc_17, bc_18, bc_19, \
96
.....
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
6 6.3 Sample DC Script for Scan Synthesis
6.3 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
.....
6.3 Sample DC Script for Scan Synthesis
/*
** 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
6 6.4 Step-by-Step Scan Synthesis Procedure
6.4 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 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.
100
.....
-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
Up to TC220G Gate Arrays and

FDnSm FDnSFm
Embedded Arrays
Up to TC220C Cell-Based ICs FDnEm FDnSFm
From TC240E Embedded Arrays GFDnEXm GFDnSFXm
TC240C to TC260C Cell-Based ICs CFDnEXm, CFDnEAXm CFDnSFXm
TC280 CFDnEXm, CFDnEQXm, CFDnSFXm,CFDnSFQXm,
CFDnMEXm, CFDnMEQXm CFDnMSFXm, CFDnMSFQXm
TC300 CFDnMSQXm, CFDnMSXm,
Provided on an individual basis
CFDnSQXm, CFDnQXm
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
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
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.
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
Table 6–2 shows the valid scan signal types.

Table 6–2 Valid Scan Signal Types
Scan Signal Type Function I/O
test_scan_in Scan-in Input

test_scan_out Scan-out Output
test_scan_enable Scan Shift Enable (active-high) 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> set_scan_signal test_scan_enable -port SEN -hookup usen/Z
dc_shell> set_dont_touch_network usen/Z
dc_shell> set_scan_signal test_scan_in -port DIA[0] -hookup udiA0/Z
dc_shell> set_scan_signal test_scan_out -port DOA[0] -hookup \
udoA0/A
104
.....
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
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
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.
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}
■ Here is an example for the single-clocked scan design:

dc_shell> test_default_period = 100
dc_shell> test_default_delay = 0
dc_shell> test_default_bidir_delay = 5
dc_shell> test_default_strobe = 40
dc_shell> 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 50 ns
Clock
■ Here is an example for the dual-clocked scan design:

dc_shell> test_default_period = 100
dc_shell> test_default_delay = 0
dc_shell> test_default_bidir_delay = 5
dc_shell> test_default_strobe = 40
dc_shell> create_test_clock "CLK" -waveform {50 60}
dc_shell> create_test_clock "SCAN_ACLK" -waveform {50 60}
107
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.
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> current_design CKT
dc_shell> change_names -hierarchy -rules toshiba
dc_shell> change_names -hierarchy -rules toshiba_scan
dc_shell> change_names -rules toshiba_ports
dc_shell> write -format verilog -hierarchy -o CKT.v_scan
This completes the scan synthesis process using DFT Compiler.
109
6 6.5 Considerations for Scan Synthesis Using DFT Compiler
6.5 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 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 synthesis constraints
and scan style. set_dont_use tc220c/FT* /* Toggle */
set_dont_use tc220c/FJK* /* JK */
set_dont_use tc220c/FDN* /* Negedge */
compile
All sequential cells are mapped to D-type flip-flops such as

Gate-Level Design 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
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 MUX
and DOUT. If DOUT is connected to internal
logic, a mux logic is automatically added. DIN DOUT
Scan Shift
Enable
112
.....
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 MUX
of the I/O buffers at DIN and DOUT. If
DOUT is connected to internal logic, a mux DIN DOUT
logic is automatically added. 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
A Scan Chain
u0
Scan Clock A is connected to the Z output
DIN
of cell u0. The scan_clock_a attribute is
assigned to the DIN port. Scan Shift
Enable
113
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 \ u1 u2
-hookup u2/A DIN DOUT
insert_scan
Scan Chain
The scan-in signal is connected to pin u1/Z, MUX
u1 u2
and the scan-out signal is connected to pin DIN DOUT
u2/A. If u2/A is connected to internal logic, a
Scan Shift
mux logic is automatically added. 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
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)
...
************************************************

************************************************

* 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 RAM
clock is assumed to have an X
value, causing clock rule
violations.
FD1
Clock
FD1
All flip-flops driven by this

clock cause 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
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
STIL Procedure File (SPF)
7 7.1 Creating an SPF
7.1 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
.....
7.1 Creating an SPF
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.
Error
DRC
OK
TEST Mode
write drc_file
SPF
121
7 7.2 SPF Organization for Single-Clocked Scan
7.2 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 #; //Specify the number of scan-in and scan-out ports
//in the form \r<number>. _si and _so are naming
//conventions expected by TetraMAX. Enter a space
//between number and #.
"CLK"=P; //Shared system/scan clock port is pulsed (P).
"RST"=1 //Async. reset is set to off state.
"SEN0"=1; //Scan Shift Enable port is set to on state.
}
}
}
}
MacroDefs {
test_setup { //Define an initialization sequence.
V { "CLK=0; //System clock port is set to off state.
"RST"= 1 //Async. reset is set to off state.
"SEN0"=0; //Scan Shift Enable port is set to off state.
"BIDI_DISABLE"=1; //Bidirectional 3-state enable is set to off state
} //(input mode).
}
}
122
.....
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"; }
//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
Procedures {
load_unload {
V { ... } //Vector for placing scan chains in shift mode
Shift { //Specify how to shift scan chains.
V { ... } //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.
V { ... } //Vector for placing scan chains in capture mode
}
shadow_observe { //Required only when your design has shadow registers
V { ... } //Set up a path from shadow registers back to scan registers
}
capture_<clk_name> { //Define a capture clock procedure.
F { ... } //Primary inputs fixed during capture cycles
V { ... } //Define a capture operation.
}
capture_<async_sig_name> { //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; }
}
}
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

shadow_
test_setup load_unload capture_xxx observe load_unload
Shift V ...
V V ... V V V ...
V V ....... F 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
3. Capture operation (capture_<clk_name>)

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
7 7.3 SPF Organization for Dual-Clocked Scan
Procedures {
load_unload {
W "_default_WFT_";
"RST"=1; //Async reset is set to off state.
"ACK0"=0; //Scan Clock A is set to off state.
"BCK0"=0; //Scan Clock B is set to off state.
//(input mode).
}
Shift {
V { _si=\r1 #; _so=\r1 #; //Specify the number of scan-in and scan-out ports
//in the form \r<number>. _si and _so are naming
//conventions expected by TetraMAX. Enter a space
//between number and #.
"CLK"=0; //System clock is set to off state.
"ACK0"=P; //Scan Clock A is pulsed (P).
"BCK0"=P; //Scan Clock B is pulsed (P).
}
}
}
master_observe { //Propagate the captured data from master latches
//to slave latches before scan-out.
V { "CLK"=0;
"RST=1;
"ACLK0"=0;
"BCLK0"=P; //Only Scan Clock B is pulsed (P).
}
}
}
MacroDefs {
test_setup { //Define an initialization sequence.
"ACK0"=0; //Scan Clock A is set to off state.
"BCK0"=0; //Scan Clock B 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:
■ SignalGroups construct
■ Timing construct
■ master_observe procedure
128
.....
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 {
//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
■ 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_" { //Identify the timing definition.
Period ’100ns’; //Tester cycle period
Waveforms {
"_default_Out_Timing_" { H { ’0ns’ X; ’40ns’ H; } } //Place strobe before
"_default_Out_Timing_" { T { ’0ns’ X; ’40ns’ T; } } active clock edge.
"_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; } }
}
}
}
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 80
_default_Out_Timing_ 40
130
.....
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 { ... } //Vector for placing scan chains in shift mode
Shift { //Specify how to shift scan chains.
V { ... } //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.
V { ... } //Vector for placing scan chains in capture mode
}
master_observe { //Required only for dual-clocked scan design
V { ... } //Vector for propagating the captured data from master latches
//to slave latches
shadow_observe { //Required only when your design has shadow registers
V { ... } //Set up a path from shadow registers back to scan registers
}
capture_<clk_name> { //Define a capture clock procedure.
F { ... } //Primary inputs fixed during capture cycles
V { ... } //Define a capture operation.
}
capture_<async_sig_name> { //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
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 {
}
}
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

shadow_ master_
test_setup load_unload capture_xxx observe observe load_unload
Shift V ...
V V ... V V V ... V
V V ....... F
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_<clk_name>)

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
7 7.4 Controlling Bidirectional Ports
7.4 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; //Set bidi_ports to a Z state.
}
}
}
134
.....
7.5 SPF Description for Scan-Out Ports with Bidirectional Buffers
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; // Assign Z states to scan-out pin.
"clk"= 0; // Set clock to off state.
"rst"= 1; // Set async reset to off state.
"sen"=1; // Set Scan Shift Enable to on state.
}
shift {
V{
_si=\r8 #;
_so=\r8 #;
"clk" = P; // Pulse the clock.
"rst" =1; // 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
7 7.6 Pin-Sharing
7.6 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
A Z
D0
PI
IBUFU
Scan Chain SOUT
Figure 7–13 ScanChain Statement Identifying the Shared Scan-in Port
STIL 1.00;
ScanStructures {
ScanChain "C0" { ScanIn "D0"; ScanOut "SOUT"; } //Shared scan-in port
}
... Omitted ...
Procedures {
load_unload {
Shift {
V { _si=#; _so=#; //No change needed
... Omitted ...
}
}
}
}
MacroDefs {
... Omitted ...
}
136
.....
7.6 Pin-Sharing
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
padi_0 CMX2X1
pado_9
A Z A0
D0 A Z
PI A1 OUT99
S
Scan Chain
padi_sen
A Z
SCAN_EN
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; //Scan Shift Enable port is set to on state.
}
}
}
master_observe {
V { "CLK"=0
"ACLK0"=0;
"BCLK0"=P;
}
}
137
7 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
A Z
D0
PI
IBUFU Scan Chain
SIN SOUT
padi_1
A Z
TEST_EN
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; //Scan Shift Enable port is set to on state.
"TEST_EN"=1; //Scan Test Enable port is set to on state.
}
138
.....
7.6 Pin-Sharing
}
}
}
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
A Z
D1
PI
ack_ctl
padi_1 ACK
A Z
D2
PI
bck_ctl
padi_sen
BCK
A Z
SCAN_EN
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
7 7.6 Pin-Sharing
Shift {
V { _si=\r3 #; _so=\r3 #;
"CLK"=0;
"D1"=P; //Shared Scan Clock A port
"D2"=P; //Shared Scan Clock B port
}
}
}
master_observe {
V { "CLK"=0
"D1"=0;
"D2"=P;
}
}
capture_clk {
F { "SCAN_EN"=0; "D1"=0; "D2"=0; } //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
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" { //Change scan chain name to uppercase.
ScanLength 4;
ScanIn "DIA0";
ScanOut "DO0";
}
}
141
7 7.8 Editing an SPF Generated by TetraMAX
7.8 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 ; }
(2)
}
"capture_reset" {
W "_default_WFT_";
"measurePO": V { "_po"=\r10 # ; }
"pulse": V { "reset"=P; "_po"=\j \r10 X ; }
}
"capture" {
W "_default_WFT_";
"measurePO": V { "_po"=\r10 # ; }
}
143

// load_unload {
// V { "clk" = 0; "reset" = 0; } // force clocks off and shift enable pins active (3)
// Shift { V { _si=#; _so=#; "clk" = P; "reset" = P; }} // pulse shift clocks
// }
}
MacroDefs {
"test_setup" {
W "_default_WFT_";
V { "clk"=0; "reset"=0; } (4)
}
}
Figure 7–22 shows a sample SPF after modification.
Figure 7–22 SPF After Modification (for Single-Clocked Scan)
STIL 1.0 {
}
Header {
Date "Tue May 8 21:29:47 2001";
History {
...
}
}
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
}
144
.....
ScanStructures {
ScanChain "IN0" { ScanIn "test_si1"; ScanOut "test_so1"; }
ScanChain "IN1" { ScanIn "test_si2"; ScanOut "test_so2"; } (1)
}
Timing {
Period '100ns';
Waveforms {
}
}
}
"_pattern_" {
}
}}
PatternExec {
}
Procedures {
"capture_clk" {
W "_default_WFT_";
V { "_pi"=\r16 # ; "_po"=\r10 # ; "clk"=P; }
}
(2)
"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 { (3)
V {
_si = \r2 #;
_so = \r2 #;
"clk = P;
}
}
}
}
145
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_<clk_name> 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<number> # and
_so = \r<number> #, where <number> 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 {
}
Header {
Date "Wed May 9 16:47:02 2001";
History {
...
}
}
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[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[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[0]" + "SDO0" + "SDO1"'; // #signals=10
"_po" = '"data_bus[7]" + "data_bus[6]" + "data_bus[5]" + "data_bus[4]"
+ "SDO0" + "SDO1"'; // #signals=10
"_default_Clk0_Timing_" = '"clk" + "reset" + "ACK" + "BCK"'; // #signals=4 (1)
147
}
ScanStructures {
// ScanChain "chain_name" { ScanIn "chain_input_name"; ScanOut "chain_output_name"; } (2)
}
Timing {
Period '100ns';
Waveforms {
"_default_In_Timing_" { N { '0ns' N; } } (3)
}
}
}
"_pattern_" {
}
}}
PatternExec {
}
Procedures {
"capture_clk" {
W "_default_WFT_";
"measurePO": V { "_po"=\r10 # ; }
"pulse": V { "clk"=P; "_po"=\j \r10 X ; }
}
"capture_ACK" {
W "_default_WFT_";
"measurePO": V { "_po"=\r10 # ; }
"pulse": V { "ACK"=P; "_po"=\j \r10 X ; }
}
"capture_BCK" {
W "_default_WFT_"; (4)
"measurePO": V { "_po"=\r10 # ; }
"pulse": V { "BCK"=P; "_po"=\j \r10 X ; }
}
"capture_reset" {
W "_default_WFT_";
"measurePO": V { "_po"=\r10 # ; }
"pulse": V { "reset"=P; "_po"=\j \r10 X ; }
}
"capture" {
W "_default_WFT_";
"measurePO": V { "_po"=\r10 # ; }
148
.....
}
// load_unload {
// V { "clk" = 0; "ACK" = 0; "BCK" = 0; "reset" = 0; } // force clocks off and
//scan shift enable pins active (5)
// 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; } (7)
}
}
Figure 7–24 shows a sample SPF after modification.
Figure 7–24 SPF After Modification (for Dual-Clocked Scan)
STIL 1.0 {
}
Header {
Date "Wed May 9 16:47:02 2001";
History {
...
}
}
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[0]" InOut; "SDO0" Out; "SDO1" Out;
}
SignalGroups {
"_default_In_Timing_" = '"clk" + "reset" + "data_bus[7]"
+ "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[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]"
149
+ "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_ACK_Timing_" = '"ACK"'; // #signals=1 (1)
"_default_BCK_Timing_" = '"BCK"'; // #signals=1
}
ScanStructures {
ScanChain "IN0" { ScanIn "SDI0"; ScanOut "SDO0"; } (2)
ScanChain "IN1" { ScanIn "SDI1"; ScanOut "SDO1"; }
}
Timing {
Period '100ns';
Waveforms {
"_default_ACK_Timing_" { P { '0ns' D; '10ns' U; '30ns' D; } } (3)
"_default_BCK_Timing_" { P { '0ns' D; '50ns' U; '80ns' D; } }
}
}
}
"_pattern_" {
}
}}
PatternExec {
}
Procedures {
"capture_clk" {
W "_default_WFT_";
V { "_pi"=\r17 # ; "_po"=\r10 # ; "clk"=P; }
} (4)
"capture_reset" {
W "_default_WFT_";
V { "_pi"=\r17 # ; "_po"=\r10 # ; "reset"=P; }
}
load_unload {
V {
"clk" = 0;
"ACK" = 0; (5)
"BCK" = 0;
"reset" = 0;
"bus_ctl" = 1;
}
150
.....
Shift {
V {
_si = \r2 #;
_so = \r2 #;
"clk" = 0;
"ACK" = P; (5)
"BCK" = P;
"reset" = 0;
}
}
}
master_observe {
V {
"clk" = 0;
"ACK" = 0;
"BCK" = P; (6)
"reset" = 0;
"bus_ctl" = 1;
}
}
}
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
4. capture procedure in the Procedures construct
Delete a procedure named capture.
Modify capture_<clk_name> 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<number> # and _so = \r<number> #, where <number> 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
7. test_setup macro in the MacroDefs construct
Add a definition to force bidirectional buses into input mode. If your design has any
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
7 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[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 "IN2" {
ScanIn "SDI2";
ScanOut "SDO2";
}
}
Timing {
Period ’100ns’;
Waveforms {
"_default_In_Timing_" { N { ’0ns’ N; } }
"_default_Out_Timing_" { H { ’0ns’ X; ’30ns’ H; } }
"_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; "TCK"=0; }
//Hold TRST at 1 and TCK at 0.
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 at 1 and TCK at 0.
"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 at 1 and TCK at 0.
V { "_pi"=\r40 # ; "_po"=\r28 # ; }
}
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
"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 {
Period ’100ns’;
Waveforms {
"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
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 8.1 Overview
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 SCE SPA
To Toshiba’s
Sign-off System TFSA (Toshiba’s TetraMAX Design Kit)
FSA LSF
To Toshiba’s To place & route and

Sign-off System scan-chain reordering (SCR) LSF2DEF (Toshiba’s DFT Design Kit)
in conventional layout flow
SCRDEF
To place & route and scan-chain
reordering (SCR) in Layout-Verilog
interface flow
160
.....
Using TetraMAX ATPG
8.1 Overview
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 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 //GUI mode

%> tmax -shell //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
.....
Using TetraMAX ATPG
8.1 Overview
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 //GUI mode

%> tmax -shell command_file //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 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
.....
Using TetraMAX ATPG
8.1 Overview
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 8.2 Running TetraMAX ATPG
8.2 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
.....
Using TetraMAX ATPG
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> 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> run drc TMDEMO.spf
TEST> rep scan chains > TMDEMO.sce
TEST> rep scan cells -all >> TMDEMO.sce
167
Using TetraMAX ATPG
TEST> rep scan path IN0 sco sci > TMDEMO.spa

TEST> rep scan path IN1 sco sci >> TMDEMO.spa
TEST> rep scan path IN2 sco sci >> TMDEMO.spa
TEST> set faults -model stuck
TEST> add faults -all
TEST> run atpg
TEST> run pattern_compress
TEST> report summaries
TEST> write patterns TMDEMO.bin -format binary -internal -replace
TEST> write patterns TMDEMO.tst -format tstl2 -internal -replace
TEST> quit -force
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.
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
.....
Using TetraMAX ATPG
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
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
.....
Using TetraMAX ATPG
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 Scan-out
(SDI) (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.
171
Using 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
.....
Using TetraMAX ATPG
Figure 8–7 SCE File Example
Number of flip-flops
Scan chain names in a scan chain Scan-in port 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
Figure 8–8 SPA File
Scan path for chain=C0: begin_position=SCO, end_position=SCI

/DO0 (117) PO (_PO)
--- I 92-/uo0/Z Header for each scan chain
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 110-
QN O 87-/U6/A1
/ucore/\store_reg[3] (110) DFF (FD4E)
!SD I 48-/ui11/Z Information about scan flip-flop
--- I (/TIE_0) .ucore.\store_reg[3]
CP I 49-/ui12/Z • Input and output pin connections
• Instance name
--- I 109- • Cell name, etc.
--- O 52-
51-
scan_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-
--- I 112-
QN O 109-/ucore/\store_reg[3]/TI
/ucore/\store_reg[2] (112) DFF (FD2E)
--- I (/TIE_0) Information about scan flip-flop
!CD I 48-/ui11/Z .ucore.\store_reg[2]
• Input and output pin connections
CP I 49-/ui12/Z • Instance name
--- I 108- • Cell name, etc.
--- O 68-
69-
scan_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-
--- I 111-
QN O 108-/ucore/\store_reg[2]/TI
.......
.......
174
.....
Using TetraMAX ATPG
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
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
.....
Using TetraMAX ATPG
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}

-repalce -first 0 -last 0
aaaaaa
177
Using 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

-replace -exclude chain_test

-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 )
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
.....
Using TetraMAX ATPG
■ 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
■ Specifying the number of patterns per output file

-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

-external -replace
180
.....
Using TetraMAX ATPG
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
Undetectable UD 3
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 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
Figure 8–12 Fault Summary Report (Test Coverage)
...
--------------------------------------------------
------------------------------ ---- ---------
Detected DT 181
Undetectable UD 3
Not detected ND 0
--------------------------------------------------
total faults 188
...
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
182
.....
Using TetraMAX ATPG
Figure 8–13 Fault Summary Report (Test Fault Coverage)
...
---------------------------------------------------
------------------------------ ---- ---------
Detected DT 181
Undetectable UD 3
Not detected ND 0
--------------------------------------------------
total faults 188
...
183
Using TetraMAX ATPG
8 8.4 ATPG Test Cycles
8.4 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
.....
Using TetraMAX ATPG
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
L1 L2 L1 L2
A
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 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"=#; } //Apply primary inputs.
V{ "_po"=#; } //Observe primary outputs.
V{ "CLK"=P; } //Pulse the system clock.
}
186
.....
Using TetraMAX ATPG
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 {
Period ’100ns’;
Waveforms {
"_default_Clk0_Timing_" { P { ’0ns’ D; ’50ns’ U; ’80ns’ D; } }
187
Using TetraMAX ATPG
8 8.5 Running TFSA and LSF2DEF
8.5 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 LSF
TSC Scan-Chain Reordering (SCR)

LSF2DEF
(Toshiba Sign-off System) in conventional layout flow
Testbench SCRDEF
Scan-Chain Reordering (SCR)

Parallel-Load Simulation in layout-Verilog flow
(PLS)
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
.....
Using TetraMAX ATPG
8.5 Running TFSA and LSF2DEF
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.

[-chip] [-delimit character]
189
Using TetraMAX ATPG
8 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.
The following command is an example of running TFSA:

%> tfsa TOP -lsf -delimit .
Running LSF2DEF
..................................................
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:
The output SCRDEF file name will be design.scrdef.
190
.....
Using TetraMAX ATPG
8.6 Advanced Topics
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 WORD=256 BIT=8;
ROMS1B WORD=512 BIT=16;
RAMS2A WORD=256 BIT=8;
RFS12A WORD=256 BIT=10;
■ When using the new Layout-Verilog interface flow, use the keyword copy_count to
specify the number of instances for ROMs.
ROMS1B WORD=256 BIT=8 copy_count=1;
ROMS1B WORD=512 BIT=16 copy_count=3;
RAMS2A WORD=256 BIT=8;
RFS12A WORD=256 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 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

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
.....
Using TetraMAX ATPG
8.6 Advanced Topics
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
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> 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> 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> run atpg fast_sequential_only
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
.....
Using TetraMAX ATPG
8.6 Advanced Topics
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 Meaning
DT_comb 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
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 (bytes)

k = 0  k=0
Scan-shift mode Scan capture mode TSTL2 header 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
.....
Using TetraMAX ATPG
8.6 Advanced Topics
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 WGL file from TetraMAX (110 MB)

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
96612488 design.tst Final TSTL2 file (96 MB)
197
Using TetraMAX ATPG
8 8.7 Known Problems
8.7 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
.....
Using TetraMAX ATPG
8.7 Known Problems
■ 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
200
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
Validating the Scan Structure and ATPG Test Vectors
9 9.1 Key Decision Criteria for Quality of Results
9.1 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
Ensure there are no design rule checking problems related to the following, at the time of scan
synthesis and prior to ATPG.
■ Scan chains
■ Sequential cells
■ Internal 3-state buses
■ Bidirectional pins
■ Combinational feedback loops
202
.....
9.1 Key Decision Criteria for Quality of Results
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
9 9.1 Key Decision Criteria for Quality of Results
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.
■ 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.
204
.....
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 serial scan-in...
...8 bits scanned-in to 8 cells (total scan-in 8)...
205
9 9.2 Scan Design Rule Checking

...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)
...
**************************************************

**************************************************

* 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
****************************************
(*) indicates change of polarity in scan data

(c) indicates cell is scan controllable only
(o) indicates cell is scan observable only
(x) indicates cell cannot capture
Complete scan chain (DII0 --> DOO0) contains 82 cells:
DII0 ->
iii[1]/REG_A_reg_0 -> The instance names of the flip-flops
iii[1]/REG_A_reg_1 -> are not followed by error indicators.
iii[1]/REG_A_reg_2 ->
...
206
.....
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
****************************************
(*) indicates change of polarity in scan data

(c) indicates cell is scan controllable only
(o) indicates cell is scan observable only
(x) indicates cell cannot capture
Incomplete scan chain (DII0 --> iii[1]/REG_A_reg_7) contains 8 cells:
DII0 ->
iii[1]/REG_A_reg_0 (c) ->
iii[1]/REG_A_reg_2 (c) -> The instance names of the flip-flops
iii[1]/REG_A_reg_3 (c) -> are followed by error indicators.
Incomplete scan chain (iii[1]/REG_A_reg_8 --> DOO0) contains 74 cells:
iii[1]/REG_A_reg_8 (o) ->

iii[1]/REG_A_reg_9 (o) ->
iii[1]/REG_B_reg_0 (o) ->
iii[1]/REG_B_reg_1 (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
Figure 9–4 Sequential Cell Summary in the check_test Output
...
**************************************************
Sequential Cell Summary No sequential cell has design
rule violations.
**************************************************
SEQUENTIAL CELLS WITHOUT VIOLATIONS Of the sequential cells without

* 3 cells are valid scan cells violations, 3 cells are valid
* 2 cells are transparent_latches : test 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 U38 U31
current_reg[2] U40 current_reg[0] 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
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:
• Ignore The rule is not checked, and no message is issued.

• Warning A warning message is issued, and the DRC run is continued.
• Error An error message is issued, and the DRC run is aborted.
• Fatal Same as Error except that the severity level can not be changed.
210
.....
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
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
---------------------------------------------------------------------------
Contention status: #pass=1, #bidi=1, #fail=0, #abort=0, #not_analyzed=0
Warning: Rule Z2 (bus capable of holding Z state) was violated 1 times.
---------------------------------------------------------------------------
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
---------------------------------------------------------------------------
Contention status: #pass=1, #bidi=1, #fail=0, #abort=0, #not_analyzed=0
---------------------------------------------------------------------------
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
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
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
9 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 40 ns
TIMESET(7)
10 ns
System/Scan Clock 45 ns
TIMESET(2)
Virtual Clock
Multicycle Paths: (40 ns + 1cycle period) – 45 ns
219
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: DI1

• Bidirectional pin: DB1
• Output pin: DO1
• Clock pins: CLK1, CLK2, CLK3
• Scan Test Enable pin: TEN (active-high)
• Scan Shift Enable pin: SEN (active-high)
■ Tester input skew: ±1 ns

■ Clock groups
• Group 1: CLK1
• Group 2: 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
set_clock_uncertainty 1.0 -from VCLK -to CLK1
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
# Define each clock group.

create_clock -period 100.0 -waveform {45.0 55.0} -name CLK_GRP1 -port CLK1
create_clock -period 100.0 -waveform {45.0 55.0} -name CLK_GRP2 -port {CLK2 CLK3}
set_clock_uncertainty 1.0 -from VCLK -to CLK_GRP1
# 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

# Treat paths from registers to output ports as multicycle paths.

# This also causes paths from input ports to output ports to be treated as
# multicycle path. Redefine these paths as single-cycle path.
# Constrain the Scan Shift Enable port to its inactive state.

Timing Verification of the Dual-Clocked Scan Design
Figure 9–20 illustrates the test timing for the dual-clocked scan design.
221
Figure 9–20 Test Timing for the Dual-Clocked Scan Design

TIMING TS1 ;
CYCLE 100 ;
TIMESET(0) DT 0 ;
TIMESET(1) DT 5 ;
TIMESET(2) PP, 45, 10 ;
TIMESET(3) PP, 50, 10 ;
TIMESET(4) PP, 70, 10 ;
ENDTIM ;
♦ Scan Shift Mode Scan Shift Mode
100 ns
Inputs
TIMESET(0)
5 ns
TIMESET(1)
Output Strobe
TIMESET(7)
Multicycle path relative to
System Clocks Scan Clock B
TIMESET(2)
10 ns
Scan Clock A 50 ns
TIMESET(3)
10 ns
Scan Clock B 70 ns
TIMESET(4)
Virtual Clock
♦ Scan Capture Mode Scan Shift Mode Scan Capture Mode

100 ns
Inputs
TIMESET(0)
5 ns
TIMESET(1)
Output Strobe
TIMESET(7) Multicycle paths relative to
Scan Clock A 10 ns
System Clocks 45 ns
TIMESET(2)
10 ns
Scan Clock A 50 ns
TIMESET(3)
10 ns
Scan Clock B 70 ns
TIMESET(4)
Virtual Clock
222
.....
a sample script for verifying scan capture mode operation. The assumptions are:
■ Primary ports
• Input pin: DI1

• Output pin: DO1
• System clock pins: CLK1, CLK2, CLK3
• Scan Clock A: ACK
• Scan Clock B: BCK

■ Clock groups
• Group 1: CLK1
create_clock -period 100.0 -waveform {0.0 50.0} -name VCLK

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 DB1
# Constrain all system clocks to their inactive state.

set_case_analysis 0 [list CLK1 CLK2 CLK3]

# Treat BCK to scan-out paths as multicycle paths.

set_multicycle_path 2 -from BCK -to [all_outputs]
223
# 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 {45.0 55.0} -name CLK_GRP1 CLK1
create_clock -period 100.0 -waveform {45.0 55.0} -name CLK_GRP2 {CLK2 CLK3}

# Constrain Scan Clock B to its inactive state.

set_case_analysis 0 BCK

# Define paths from ACK to all clocks and output ports as multicycle paths.
set_multicycle_path 2 -from ACK -to [all_clocks]
# (There is no possibility of these paths getting sensitized in 1-to2 cycles
# because only one clock group is activated at a time.)
set_false_path -from CLOCK_GRP1 -to CLOCK_GRP2
# 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]
# 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
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 TSC
WAV / DRIVE / PARA EXP

SDF (Expected Values File)
(Testbench)
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
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:

%> comp CKT1.v
%> tsc testext=ATPG iscan=ON fsaread=ON force=ON
%> tracegen sra=ON
%> tsbsim CKT1.wav CKT1.v
%> sra
226
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
Toshiba TetraMAX Design Kit
10 10.1 System Requirements
10.1 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
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 TMCMD SPF Log
Figure 10–2 When VSO/DFT Was Used
Netlist TDCMD tsb.config INIT
SPFGen
229
10 10.2 SPFGen
Figure 10–3 When Other Scan Synthesis Tool Was Used
Netlist atpg.config INIT
SPFGen
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
.....
10.2 SPFGen
■ 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
10 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
.....
10.2 SPFGen
$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
scan design. This keyword is required.
$lang Selects the language in which log files are generated, J for Japanese and E
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
10 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 +.
■ SC System clock
■ AC Scan clock A
■ BC Scan clock B
■ ST Asynchronous set
■ RT Asynchronous reset
■ NC Clock not exercised for capture operation
■ TM Test mode (Scan Test Enable)
■ SM Scan mode (Scan Shift Enable)
■ SI Scan-in
■ SO Scan-out
■ TMS JTAG TMS port
■ TDI JTAG TDI port
■ TDO JTAG TDO port
■ TCK JTAG TCK port
■ TRST JTAG TRST port
234
.....
10.2 SPFGen
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
10 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
input_sequence ;
input_sequence ;
...
input_sequence ;
*POST_SHIFT
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
.....
10.2 SPFGen
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 = top_module_name
technology = ASIC_technology
*ATPG
netlist = filename
spfin = filename
spfout = filename
cmdout = filename
init = filename
scan = {muxscan|fascan|mix}
lang = {J|E}
jtag = {JTAGC11|JTAGC14}
jtaginst = {SCANTEST|PSSCAN}
tck = JTAG_TCK_port
tms = JTAG_TMS_port
tdi = JTAG_TDI_port
tdo = JTAG_TDO_port
trst = 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
10 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
scan design. This keyword is required.
lang Selects the language in which log files are generated, J for Japanese and E
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 = demo
technology = TC240CQ
*ATPG
netlist = demo.v
spfout = demo.spf
cmdout = demo.tmaxcmd
scan = muxscan
lang = E
jtag = JTAGC14
jtaginst = SCANTEST
tck = TCK
238
.....
10.2 SPFGen
tms = TMS
tdi = TDI
tdo = TDO
trst = TRST
239
10 10.3 TFSA
10.3 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 LSF
TSC Scan-Chain Reordering (SCR)

LSF2DEF
(Toshiba Sign-off System) in conventional layout flow
Testbench SCRDEF

Parallel-Load Simulation in layout-Verilog flow
(PLS)
240
.....
10.3 TFSA
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> report scan path IN0 sco sci > TMDEMO.spa
TEST> report scan path IN1 sco sci >> TMDEMO.spa
Output Files
This section briefly describes the output files produced by TFSA.
241
10 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.
**********************************************
* Results
242
.....
10.3 TFSA
**********************************************
Total error: 0
Total warning: 0
FF types: Number of instances in SPA

CFD1EXL
CFD4EX4 Number of flip-flops processed to generate LSF
CFD2EX4
Number of flip-flops in SCE
Chain=IN0 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:

[-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
10 10.3 TFSA
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
.....
10.3 TFSA
..Error TFSA-0003 Can’t open FSA file:$1.

Meaning: An attempt to open an FSA file failed.
..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.
..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
10 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
commands in the SCE file contain descriptions inconsistent with each other.
..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.
..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
.....
10.3 TFSA
..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 <top module> -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
10 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.
Meaning: TFSA is checking if there is any instance in the scan chain added by
TetraMAX.
Meaning: TFSA is writing an LSF file.
248
.....
10.4 LSF2DEF
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.
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
10 10.4 LSF2DEF
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.
io_2
ff_1 module_1
ff_a
SI SO ff_4
SI SO
SI SO
ff_2 ff_b
io_1
SI SO SI SO
ff_5
SI SO
ff_3
SI SO
250
.....
10.4 LSF2DEF
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
10 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:
The output SCRDEF file name will be design.scrdef.
252
.....
10.5 SCRTST
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
10 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
JTAG Boundary-Scan Insertion Using BSD Compiler
11 11.1 Overview
11.1 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:

■ 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
256
.....
11.2 BSD Compiler Limitations
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 Core System

Input Pins Design Output Pins
JTAG Top-Level JTAG

Input Pins Output Pin
Figure 11–2 Top Module After JTAG Insertion
Core System
System
Design Output Pins
Input Pins
BSR
JTAG JTAG
Input Pins Output Pins
TAPC
257
11 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
Either one of them is required.

DCF PPA VPPA DEV
PPMAPGEN
Core Design
Top-Level Design (Black Box)
PPMAP SCR_BSDC
BSD Compiler (JTAG Insertion)
Top-Level Design Core Design

+ TAPC + BSR (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
11 11.3 JTAG Design and Verification Flow
Figure 11–4 JTAG Insertion and Verification Flow
Top Design Core Design

DCF PPA VPPA DEV w/ TAP (Black Box)
PPMAPGEN
Read RTL netlist Synthesize design
Set design constraints Optimize JTAG design Top Design

w/ JTAG
PPMAP
Prepare for JTAG insertion Read core design Core Design
SCR_BSDC
Set DW JTAG components Verify JTAG design
Insert DW JTAG components Generate BSDL file BSDL
Generate JTAG test patterns 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
link
/* --------------------------------------------------------------
Define clock signals and I/O delays
----------------------------------------------------------------- */
create_clock -name TCK -period 100 -waveform {0.0 50.0} TCK
set_fix_hold CLK
set_input_delay 18.0 -clock CLK {all_inputs() - "CLK" - "TCK" }
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
-default_package PKG00
/* --------------------------------------------------------------
Set implemented JTAG instructions
----------------------------------------------------------------- */
set_bsd_instruction { \
BYPASS, \
EXTEST, \
SAMPLE, \
IDCODE, \
HIGHZ, \
CLAMP \
}
set_bsd_instruction INTEST \
-input_clock_condition PI \
-output_condition BSR
/* --------------------------------------------------------------
Check design
----------------------------------------------------------------- */
check_design
/* --------------------------------------------------------------
Preview JTAG components
----------------------------------------------------------------- */
preview_bsd -show all
/* --------------------------------------------------------------
Generate and Insert JTAG components
----------------------------------------------------------------- */
insert_bsd
/* --------------------------------------------------------------
Check design
----------------------------------------------------------------- */
check_design
/* --------------------------------------------------------------
Write GTECH design with JTAG components
----------------------------------------------------------------- */
write \
-format verilog \
-hierarchy \
-output CKTTOP.v_jtag_presynth
/* --------------------------------------------------------------
Synthesize and optimize JTAG components
----------------------------------------------------------------- */
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
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)
----------------------------------------------------------------- */
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
/* --------------------------------------------------------------
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
Either one of them is required.

DCF PPA VPPA DEV
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
PPMAP Prepare for JTAG verification
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
/* --------------------------------------------------------------
Read all design netlists with JTAG components
----------------------------------------------------------------- */
read -format verilog CKTTOP.v_postsynth_withJTAG

link
/* --------------------------------------------------------------
Define clock signals
----------------------------------------------------------------- */
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

create_bsd_patterns -output CKTTOP_JTAG
write_test \
-input CKTTOP_JTAG \
-format tstl2_scan \
-out CKTTOP.tst_jtag
267
11 11.4 Step-by-Step JTAG Boundary-Scan Design Procedure
11.4 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 //Command line

%> design_analyzer & //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> read -format verilog CKTTOP.v_prejtag
dc_shell> read -format verilog CKTCORE.v_blackbox
dc_shell> current_design CKTTOP
dc_shell> 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
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
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.
Here are example usages of set_bsd_signal:

dc_shell> set_bsd_signal tck TCK
dc_shell> set_bsd_signal tdi TDI
dc_shell> set_bsd_signal tms TMS
dc_shell> set_bsd_signal trst TRST
dc_shell> set_bsd_signal 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
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
Input Buffer data_out data_out_inverted – – – –

Output Buffer – – data_in data_in_inverted – –
Tristate Output Buffer – – data_in data_in_inverted enable_inverted enable
Bidirectional Buffer data_out data_out_inverted data_in data_in_inverted enable_inverted enable
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 <disable result> element. It can be one of the following:
WEAK0: External pull-down

WEAK1: External pull-up
PULL0: Internal pull-down
PULL1: Internal pull-up
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 (n = 24)
test_bsd_part_number = n (n = 0 to 65535)
test_bsd_version_number = n (n = 0 to 15)
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
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: Binary encoding

one_hot: 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.
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.
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
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.
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> uniquify
dc_shell> link
dc_shell> create_clock -name TCK -period 20 -waveform {5 10} TCK

dc_shell> set_clock_skew -uncertainty 1 TCK
dc_shell> set_dont_touch_network TCK
dc_shell> set_fix_hold TCK
dc_shell> 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> 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
■ 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
Here is an optimization example:

dc_shell> test_bsd_optimize_control_cell = true
dc_shell> test_bsd_control_drive_limit = 4
dc_shell> set_bsr_cell_type -port BIDI0 -direction in observe_only
dc_shell> set_max_delay -from BIDI0 0.0
dc_shell> test_bsd_allow_tolerable_violations = true
dc_shell> 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.
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
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.
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
-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.
280
.....
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
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.
Here is an example usage of set_bsd_linkage_port:

dc_shell> set_bsd_linkage_port -port_list { AVS, AVD }
283
11 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.
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.
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
11 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, ...}
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
2 Boundary scan design Violations found
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
11 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
...Analyzing TCK halt state.
Warning: Undriven input port TDI is floating. When undriven, this port should behave
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_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
11 11.7 BSD Compiler Design Kit
11.7 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.
Here is an example usage of PPMAPGEN:

%> ppmapgen CKTTOP -tdi TDI -input DEV -series tc260c
291
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 tc240e.iocell
tc250c.iocell tc260c.iocell tc260e.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:
<cell_type_id>_<subgroup_id>
where, <cell_type_id> 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 <cell_type_id> Choices
<cell_type_id> 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
■ 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 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
294
.....
11.8 Known Problems
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
-access { \
data_out ZI, \
data_in 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 *
*/
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
.....
11.8 Known Problems
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 *
*/
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 *
*/
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
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
Part 3
Advanced Topics
299
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 What is Scan-Chain Reordering?
12.1 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
.....
12.1 What is Scan-Chain Reordering?
Figure 12–1 Scan-Chain Reordering
Scan-in SI SO SI SO The default scan chain order

SI SO may not match the
normal-mode function of the
SI SO flip-flops, causing the scan
nets to become unexpectedly
SI SO
long.
Scan-out
Scan-in When your netlist contains

SI SO SI SO
scan chains, scan nets are
SI SO
deleted from the netlist based
on the LSF file.
SI SO
SI SO
Scan-out
Scan-in SI SO SI SO New scan nets are created to

SI SO connect scan flip-flops with
optimal wire length.
SI SO
SI SO
Scan-out
303
12 12.2 Scan-Chain Reordering (SCR) Flow
12.2 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 [1]
tdgs / def Design lsf
Physical Layout + SCR [2]
chgcir
Original fsa Original TSTL2
[3]
NETMOD
Verilog-HDL / VHDL 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
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 [1]
Verilog-HDL
Netlist lsf
LSF2DEF [2]
scrdef
Original fsa Original TSTL2
Physical Layout + SCR [3]
Verilog-HDL 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
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
Timing Analysis Using PrimeTime
13 13.1 STA Considerations for a Design with DFT Logic
13.1 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:
■ Disable any DFT logic to validate the timing in normal operation mode.
■ Enable DFT logic to validate its timing.
310
.....
13.2 Validating the Normal-Mode Operation of a Scanned Design
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
13 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
13 13.3 Validating the Test-Mode Operation of a Scanned Design
Figure 13–1 Test Timing for the Single-Clocked Scan Design

TIMING TS1 ;
CYCLE 100 ;
TIMESET(0) DT 0 ;
TIMESET(1) DT 5 ;
TIMESET(2) PP, 45, 10 ;
ENDTIM ;
100 ns
Inputs
TIMESET(0)
5 ns
TIMESET(1)
Output Strobe 40 ns
TIMESET(7)
10 ns
System/Scan Clock 45 ns
TIMESET(2)
Virtual Clock
Multicycle Paths: (40 ns + 1cycle period) – 45 ns
a sample script for verifying capture mode operation. The assumptions are:
■ Primary ports
• Input pin: DI1

• Output pin: DO1
• Clock pins: CLK1, CLK2, CLK3

■ Clock groups
• Group 1: CLK1
314
.....


# Treat register to output port paths as multicycle paths.

# This also causes input-to-output paths to be treated as multicycle paths.

# Redefine these paths as single-cycle path.

Figure 13–3 Sample Script for Capture Mode Operation

create_clock -period 100.0 -waveform {45.0 55.0} -name CLK_GRP1 -port CLK1
create_clock -period 100.0 -waveform {45.0 55.0} -name CLK_GRP2 -port {CLK2 CLK3}
# (There is no possibility of hold violations occurring in capture mode because
# only one clock group is activated at a time.)

315
# Treat paths from registers to output ports as multicycle paths.

# This also causes paths from input ports to output ports to be treated as
# multicycle path. Redefine these paths as single-cycle path.

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

TIMING TS1 ;
CYCLE 100 ;
TIMESET(0) DT 0 ;
TIMESET(1) DT 5 ;
TIMESET(2) PP, 45, 10 ;
TIMESET(3) PP, 50, 10 ;
TIMESET(4) PP, 70, 10 ;
ENDTIM ;
316
.....
♦ Scan Shift Mode Shift Scan Mode
100 ns
Inputs
TIMESET(0)
5 ns
TIMESET(1)
Output Strobe
TIMESET(7)
Multicycle path relative to
System Clocks Scan Clock B
TIMESET(2)
10 ns
Scan Clock A 50 ns
TIMESET(3)
10 ns
Scan Clock B 70 ns
TIMESET(4)
Virtual Clock
♦ Scan Capture Mode Scan Shift Mode Scan Capture Mode

100 ns
Inputs
TIMESET(0)
5 ns
TIMESET(1)
Output Strobe
TIMESET(7) Multicycle paths relative to
Scan Clock A 10 ns
System Clocks 45 ns
TIMESET(2)
10 ns
Scan Clock A 50 ns
TIMESET(3)
10 ns
Scan Clock B 70 ns
TIMESET(4)
Virtual Clock
a sample script for verifying capture mode operation. The assumptions are:
■ Primary ports
• Input pin: DI1

• Output pin: DO1
• System clock pins: CLK1, CLK2, CLK3
• Scan Clock A: ACK
317
• Scan Clock B: BCK

■ Clock groups
• Group 1: CLK1

create_clock -period 100.0 -waveform {70.0 80.0} BCK
set_clock_uncertainty 1.1 -from VCLK -to BCK

# 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.

# 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 {45.0 55.0} -name CLK_GRP1 CLK1
create_clock -period 100.0 -waveform {45.0 55.0} -name CLK_GRP2 {CLK2 CLK3}

# 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.

# Define paths from ACK to all clocks and output ports as multicycle paths.
set_multicycle_path 2 -from ACK -to [all_clocks]
# (There is no possibility of these paths getting sensitized in 1-to2 cycles
# because only one clock group is activated at a time.)
# 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.
# 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.)
319
320
Part 4
Appendixes
321
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
Quick Tour
A A.1 General Design Flow
A.1 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 Command File
CKTTOP.v_postscan CKTTOP.spf CKTTOP.tmaxcmd scan_design.report
Report File
TetraMAX (ATPG)
CKTTOP.tst CKTTOP.sce CKTTOP.tmaxlog
TSTL2 Scan Report Log File
TFSA
CKTTOP.fsa
Scan-related information
VSO (Design Verification & Simulation)
324
.....
Quick Tour
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}
link
/*
** Create a clock and set delay constraints on I/O ports.
*/
set_fix_hold CLK
set_input_delay 18.0 -clock CLK {all_inputs() - "CLK"}
/*
** 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 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.
*/
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
.....
Quick Tour
■ 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 A.3 TetraMAX ATPG
A.3 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" { //Change scan chain name to uppercase.
ScanLength 4;
ScanIn "DIA0";
ScanOut "DO0";
}
}
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
.....
Quick Tour
A.3 TetraMAX ATPG
// 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 A.4 Verifying the Scan Test Patterns
A.4 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 = verilog // HDL language
simulator = verilog // Simulator
edaversion = 2.7 // Verilog-XL version
technology = TC220C // Technology
arraytype = T3S60T8 // Array size
voltage = 3.0 // Core voltage
libdir = . // Library directory
project = TetraMAX Design Kit // Project name
design = CKTTOP // Design name
module = CKTTOP // Module name
instance = wave.CKTTOP_wave // 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
.....
Quick Tour
A.4 Verifying the Scan Test Patterns
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); // System clock polarity (P) and pin name
SCSEL(C0) SCAN_ENABLE=1; // Scan Shift Enable pin name and active state
ENDDEC;
FUNCTEST FC1;
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 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 **********
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
332
Appendix B TSTL2 Scan Test Data
Description
T 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
TSTL2 Scan Test Data Description
B B.1 TSTL2 Scan Vector File Organization
B.1 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 ;
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;
ENDSCAN;
334
.....
B.1 TSTL2 Scan Vector File Organization
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
B B.2 DECLARE Block
B.2 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
.....
B.2 DECLARE Block
• 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
B 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
.....
B.2 DECLARE Block
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
B 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
B B.3 Scan Definition Blocks
■ 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;
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
B B.4 Scan Pattern Descriptions
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; Two scan chains are loaded in parallel.
00LH N00 00XX ;
SP(SC1O)LLHH,SP(SC2O)LHLH, Two scan chains are unloaded in parallel, while
SP(SC1I)0101,SP(SC2I)0101 ; at the same time they are loaded with new vectors.
11HL N00 00XX ;
SP(SC1O)LHLH,SP(SC2O)LHLH ;
...
■ 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
.....
B.4 Scan Pattern Descriptions
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 ✦ Equivalent parallel patterns

...
SCAN IN1I;
PATH SDI1;
ENDSCAN;
SYSCLK
SDO1
SCAN IN1O;
BCLK
ACLK
SDI1
O1
O2
PATH SDO1;
I1
I2
ENDSCAN;
ASSIGN I1,I2,O1,O2,,SYSCLK,,ACLK,BCLK,, 10XX 0 00 0X; 1. Capture mode
SDI1,SDO1; 10XX 0 PP 0X;
TESTPAT SAMPLE; 10XX 0 PP 0X;
1 10XX 0 00 0X; 10XX 0 PP 1X; 2. Scan shift mode (scan-in)
2 SP(IN1I) 00100; 10XX 0 PP 0X;
3 10HL P 00 0X; 10XX 0 PP 0X;
SP(IN1O) LLHHH, 10HL P 00 0X; 3. Capture mode
4
SP(IN1I) 11010; 10XX 0 PP 1L;
5 01LL P 00 1X; 10XX 0 PP 1L;
6 SP(IN1O) HHHLL, 10XX 0 PP 0H; 4. Scan shift mode
SP(IN1I) 01000; 10XX 0 PP 1H; (Scan-out and scan-in)
... 10XX 0 PP 0H;
01LL P 00 1X; 5. Capture mode
01XX 0 PP 0H;
01XX 0 PP 1H;
01XX 0 PP 0H; 6. Scan shift mode
01XX 0 PP 0L; (Scan-out and scan-in)
01XX 0 PP 0L;
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
B B.5 Scan Test Sequence
B.5 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 ff1 ff3
n1 n3 c3 n5 n7
DIN1 D Q D Q
MUX
0 c5
DIN2 1 DOUT
c2 ff2 ff4
n2 n4 c4 n6
D Q D Q
n8
DIN3
DIN4
CLK
✦ After scan insertion
c1 ff1 ff3
n1 n3 c3 n5 n7
DIN1 D Q D Q
TI TI MUX
TE TE 0 c5
DIN2 1 DOUT
c2 ff2 ff4
n2 n4 c4 n6
D Q D Q SOUT
n8
TI TI
TE TE
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 ;
ENDTIM ;
SCAN SC1I;
PATH SIN;
ENDSCAN;
SCAN SC1O;
PATH SOUT;
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
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:
SOUT
DIN1
DIN2
DIN3
DIN4
SEN
CLK
SIN
X 0000 P01; /* 3 */
X 0000 P11; /* 4 */
X 0000 P01; /* 5 */
X 0000 P11; /* 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
c1 ff1 ff3
1 n1 n3 c3 n5 n7
DIN1 D Q D Q
TI 0 TI 1 MUX
1 TE TE 0 c5
DIN2 1 DOUT
c2 ff2 ff4
n2 n4 c4 n6
D Q D Q SOUT
n8
TI 1 TI 0
TE TE
1
DIN3
0
DIN4
0
CLK
0
SIN
0
SEN
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
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
c1 ff1 ff3
1 n1 1 n3 c3 n5 1 n7
DIN1 D Q D Q
TI 0 TI 1 MUX
1 TE TE 0 c5 1
DIN2 1 DOUT
c2 ff2 ff4
n2 1
Q
n4 c4 n6 0 D Q
0
D SOUT
n8
TI 1 TI 0
TE TE
1
DIN3
0
DIN4
0
CLK
0
SIN
0
SEN
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
c1 ff1 ff3
1 n1 1 n3 c3 n5 1 n7
DIN1 D Q D Q
TI 1 TI 1 MUX
1 TE TE 0 c5 1
DIN2 1 DOUT
c2 ff2 ff4
n2 1
Q
n4 c4 n6 0 D Q
0
D SOUT
n8
TI 1 TI 0
TE TE
1
DIN3
0
DIN4
CLK
0
SIN
0
SEN
350
.....
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:
SOUT
SIN
L 0000 P01; /* 8 */
H 0000 P11; /* 9 */
H 0000 P01; /* 10 */
H 0000 P01; /* 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
Cycle 11 0 0 1 0 1
0 0 1 0
ff2 ff1 ff3 ff4
Cycle 12–
From cycle 12 onwards, the same process as cycles 3–11 is repeated using different vectors.
351
352
Synopsys-DFT User Guide Index
Index
Symbols black boxes 256

$TOSH_ROOT directory structure 86 check_test transcript 105, 116
defining 169
Numerics testability problems 44, 47
3-state buses block-by-block scan synthesis 91
rules 38 Boundary-Scan Description Language. See BSDL
scan design rule checking 208 file
3-state output buffers boundary-scan register 17
JTAG rule 60 boundary-scan. See JTAG boundary-scan
A BSD Compiler
add clocks command (TetraMAX) 142, 147, 170 known problems 295
add faults command (TetraMAX) 175 limitations 257
add pi constraints command (TetraMAX) 171 BSD Compiler commands
add pi equivalences command (TetraMAX) 170 check_bsd 279, 287
asynchronous set/reset ports create_bsd_patterns 280
defining in TetraMAX 170 insert_bsd 276
ATPG 5, 11 optimize_bsd 278
ATPG design flow 160 preview_bsd 276
ATPG model read_pin_map 269
building in TetraMAX 169 set_bsd_compliance 285
ATPG patterns set_bsd_configuration 273
verifying 217 set_bsd_control_cell 284
ATPG test cycles 184 set_bsd_data_cell 284
atpg.config file 230, 232 set_bsd_instruction 275
automatic test pattern generation. See ATPG set_bsd_linkage_port 283
B set_bsd_pad_design 270
set_bsd_signal 269
Basic-Scan ATPG. See combinational ATPG
set_bsr_cell_type 278
bidirectional buffers
write_bsdl 279
JTAG rules 60
write_test 281
bidirectional enable lines
BSD Compiler design kit 72, 84, 290
path delays 52
BSD Compiler library 72
bidirectional ports
BSD Compiler variables
check_test transcript 208
test_bsd_allow_tolerable_violations 278
on a submodule 115
test_bsd_control_drive_limit 278
rules 39
test_bsd_manufacturer_id 273
SPF 134
test_bsd_optimize_control_cell 278
used as a clock 115
test_bsd_part_number 273
binary pattern file
test_bsd_version_number 273
reading 180
write_test_formats 281
BIST 7
BSDL file 58
353
Index Synopsys-DFT User Guide
generating 279 run drc transcript 214

BSR. See boundary-scan register clock tree synthesis. See CTS
buffer trees 29, 104 combinational ATPG 192
BUILD mode 166, 167, 168 combinational feedback loops 32
build-in self-test 7 bypassing megacells 47
bus contention/float checking check_test transcript 209
run drc transcript 211 rules 40
bus keepers command file (TetraMAX) 163
run drc transcript 212 compile command (DFT Compiler) 29, 30, 102
BYPASS instruction 56 compile -scan command (DFT Compiler) 90
bypass register 17 compliance-enable ports 61
C compliance-enable ports. See JTAG-enable ports
CONST statement (TSTL2) 342
capture clock group 36
controllability 6
defining in TetraMAX 170
Core Test 7
capture cycle depth 192
create_bsd_patterns command (BSD Compiler) 280
capture mode 10
create_port command (DFT Compiler) 111
capture procedure
create_test_clock command (DFT Compiler) 107
dual-clocked scan
CTS 29, 104
format 132
modifying an SPF from TetraMAX 152 D
single-clocked scan DCAL 219, 313
format 124 DCF file 291
modifying an SPF from TetraMAX 146 DCSDF file 219, 313
single-cycle 186 DECLARE block (TSTL2) 178, 334, 336
three-cycle 186 DECLARE file 231
chain test 177, 217 deeply buried logic states 44
change_names command (DFT Compiler) 95, 109 defect level 4
change_names script 95 Design Compiler library 84, 87
check_bsd command (BSD Compiler) 279, 287 design flow
-verbose option 289 internal-scan and JTAG boundary-scan 75
verifying the inferred instructions 289 internal-scan and memory BIST insertion 77
verifying the JTAG registers 288 internal-scan insertion 74
verifying the TAP 288 memory BIST insertion 76
check_test command (DFT Compiler) 94, 105, 108, design kits 84
205 DesignWare libraries 88
bidirectional ports 208 DEV file 291
combinational feedback loops 209 device identification code 57
scan chains 205 device identification register 17
sequential cells 207 configuring 273
CHGCIR file 305, 306 DFT Compiler commands
CLAMP instruction 56 change_names 95, 109
clock ports check_test 94, 105, 108, 205
defining in TetraMAX 170 compile 102
clock rule checking compile -scan 90
354
create_port 111 RAM 117

create_test_clock 107 removing 118
insert_dft 94 E
insert_scan 90, 91, 94, 106 environment variables (UNIX) 87
remove_design 118 EXTEST instruction 20, 56
report_test 108, 205
report_test -atpg_conflicts 208 F
report_test -scan_path 206 Fast-Sequential ATPG. See sequential ATPG
set_dont_touch_network 104 fault coverage 4, 181, 195
set_dont_use 110 fault list 193
set_scan_configuration 100 creating 193
set_scan_path 114 fault models 5
set_scan_signal 103, 111, 112, 113, 114, 115 fault summary report 176
set_scan_transparent 210 feedback path sensitization checking
set_signal_type 115 run drc transcript 216
set_test_hold 102 fixed logic values at nodes 43
write_test_protocol 109 flip-flop rules 31
DFT Compiler library 72 FSA file 161, 164, 226, 242, 253, 305, 307
DFT Compiler variables G
test_default_bidir_delay 107 GEMINISO 71
test_default_delay 107
test_default_period 107 H
test_default_strobe 107 hierarchical delimiter (TetraMAX) 168
test_stil_netlist_format 109 HIGHZ instruction 56
DFT considerations implementation rule 59
area impact 67 hookup pins 104
I/O pin requirements 67 HSS 218
internal-scan 66 I
JTAG boundary-scan 66 I/O buffers for the TC240 to TC260 series 114
memory BIST 66 IDCODE instruction 56
selecting DFT methodologies 66 IEEE Std 1149.1. See JTAG boundary-scan
DFT tools supported 84 INIT file 230, 236
direct-access approach 7 insert_bsd command (BSD Compiler) 276
DISPLAY environment variable 178, 198 insert_dft (DFT Compiler) 94
DL 4 insert_dft command (DFT Compiler) 29, 30, 90, 91
DRC mode 166, 167, 169 insert_scan command (DFT Compiler) 29, 30, 90, 91,
dual-clocked scan design 25 94, 106
inserting buffer trees 30 instance names
PrimeTime scripts 223, 318 Verilog-HDL 198
scan test sequence 133 instruction register 16
test timing parameters 49 internal-scan design 7, 9
timing verification 221, 316 general design flow 74
TSTL2 timing definition 222, 316 I/O pin requirements 27
dummy module penalty 12
creating 117 scan test sequence 10
355
INTEST instruction 56 JTAG instructions 56

implementation rule 59 JTAG IP cores 153, 233, 238, 258
IOCELL file 292 JTAG logic
IOPARAM file 219, 313 disabling 153
J JTAG test patterns 58
JTAG-enable ports 62, 63
JTAG boundary-scan 8, 13
avoiding putting BSR cells 284
architecture 13
set_bsd_compliance command 285
assigning specific BSR cell types 284
set_bsd_data_cell command 285
avoiding BSR cells on some ports 283
setting 285
checking IEEE Std 1149.1 compliance 278
configuring the device identification register 273 L
defining I/O softmacrocells 270 latch rules 32
defining test access ports 269 library clause
design flow 259 VHDL 199
device identification code 57 library environment 87
formatting test patterns 281 linkage ports 283
general test sequence 19 load_unload procedure
generating a BSDL file 279 dual-clocked scan
generating test patterns 280 format 131
generating the boundary-scan logic 276 modifying an SPF from TetraMAX 152
handling of custom I/O cells 292 single-clocked scan
I/O pin requirement 68 format 124
IEEE 1149.1 compliance checking 287 modifying an SPF from TetraMAX 146
implementing IEEE Std 1149.1 instructions 56, LSF file 162, 164, 165, 242, 252, 305, 307
275 format 249
JTAG insertion and verification flow 259 LSF2DEF 165, 188, 252, 308
open-drain bidirectional buffers 258, 295 functions 189
optimizing the boundary-scan register 277 running 190
pin-sharing 62 Ltran 198
previewing the boundary-scan design 276 LTRAN_SHELL environment variable 178, 198
reading the design 268 M
reading the PPMAP file 269 MacroDefs construct
reset 63 dual-clocked scan 132
rules for implementing optional instructions 59 single-clocked scan 125
rules for the EN and TN pins of I/O buffers 59 MAIN 114
script for JTAG insertion and verification 260 man command (TetraMAX) 216
script for JTAG verification 265 manufacturer identify code 57
selecting the boundary-scan configuration 273 mapped netlist without scan 110
setting synthesis specifications 268 master_observe procedure 185
synthesis process 277 dual-clocked scan
TAP requirements 258
format 131
top module requirements 257 modifying an SPF from TetraMAX 152
Toshiba custom JTAG components 258 MDLGEN 191
verification-only flow 264 megacells 44, 46, 47
356
memory BIST single-clocked scan design 220, 315

general design flow 76 PrimeTime Sign-Off System 71
I/O pin requirement 68 Procedures construct
memory models 191 dual-clocked scan 131
MemoryBIST Design System 72 single-clocked scan 123
MGDATA file 191 PSSCAN instruction 233, 236, 238
mixed-clock scan chain 42 PTSO 71
multidriver net checking R
run drc transcript 215 RAM
multiple system clock design 37 dummy module 117
multiplexed flip-flop scan 24 read faults command (TetraMAX) 193
N read netlist command (TetraMAX) 142, 147, 168, 169
naming rules 95 read_pin_map command (BSD Compiler) 269
NETMOD 306 remove_design command (DFT Compiler) 118
non-scan rule checking report faults command (TetraMAX) 181, 182
run drc transcript 215 report rules command (TetraMAX) 216
O report scan cells command (TetraMAX) 172
report scan chains command (TetraMAX) 172, 241
observability 6
report scan path command (TetraMAX) 173, 241
open-drain bidirectional buffers (JTAG) 258, 295
report summaries command (TetraMAX) 176
optimize_bsd command (BSD Compiler) 278
report summaries sequential_depths commands
P (TetraMAX) 192
parallel-load simulation 172, 188, 217, 225, 334 report violations command (TetraMAX) 216
PATH statement (TSTL2) 342 report_check command (DFT Compiler)
Path Test 29, 30 scan chains 206
PATTYPE statement (TSTL2) 339 report_test -atpg_conflicts command (DFT
PLS. See parallel-load simulation Compiler) 208
port-to-pin mapping file. See PPMAP file report_test command (DFT Compiler) 108, 205
PPA file 291 report_test -scan_path command (DFT
PPMAP file 290 Compiler) 206
creating 269 run atpg command (TetraMAX) 175, 177
reading 269 run atpg -fast_sequential_only command
PPMAPGEN 269, 272, 290 (TetraMAX) 192
custom I/O cells 292 run build_model command (TetraMAX) 142, 147,
I/O database 292 169
syntax 290 run drc command (TetraMAX) 172, 211
preview_bsd command (BSD Compiler) 276 bus contention/float checking 211
primary input constraints clock rule checking 214
defining in TetraMAX 171 feedback path sensitization checking 216
PrimeTime 218, 313 multidriver net checking 215
PrimeTime commands non-scan rule checking 215
set_case_analysis 311 scan chain operation checking 214
set_false_path 312 simulating test protocol procedures 213
PrimeTime scripts run pattern_compression command (TetraMAX) 175
dual-clocked scan design 223, 318
357
RUNBIST instruction 56 scan path. See scan chains

S scan replacement 9, 90
Scan Shift Enable port 27
SAMPLE/PRELOAD instruction 56
scan assembly 9, 90 buffer tree 29
SCSEL statement (TSTL2) 339
SCAN block 341
scan shift mode 10
scan capture mode. See capture mode
scan style
scan chain names 141
dual-clocked scan 25
scan chain operation checking
selecting 100
run drc transcript 214
single-clocked scan 24
scan chains 9
scan synthesis 9
building 106
block-by-block 91
building at the top level 91
DC script example 98
building in each module 93
overall flow 90
check_test transcript 205
step-by-step procedure 100
controlling with JTAG logic 153
Scan Test Enable port 27
different branches of a clock 42
static timing analysis 311
mixed-clock 42
scan test patterns
number and balancing 41
saving in ATPG binary storage format 180
report_test transcript 206
size 69
static timing analysis 312
splitting into multiple TSTL2 files 179
TSTL2 definition 334
writing out in TSTL2 format 177
scan clock ports 28
scan test ports
sharing functional input ports with 113, 139
static timing analysis 311 creating 111
scan clocks explicitly assigning to scan chains 114
SCMCLK statement (TSTL2) 338 identifying 103
SCSCLK statement (TSTL2) 338 specifying existing ports with I/O buffers 113
scan design rule categories, TetraMAX 210 specifying existing ports without I/O buffers
scan design rule checking as 112
correcting common errors 115 specifying nonexistent ports as 111
DFT Compiler 94, 105, 108, 205 types and requirements 27
TetraMAX 172, 210 scan test sequence
scan design rule severity cycle-by-cycle 346
TetraMAX 210 dual-clocked scan design 133
scan design rules 31 overall flow 10
3-state buses 38 single-clocked scan design 125
bidirectional pins 39 scan-chain reordering 172, 173, 253, 302
combinational feedback loops 40 in the conventional layout flow 304
in the Layout-Verilog Interface flow 307
flip-flops 31
latches 32 scan-in port 28
using a functional port as 136
system clocks 33
scan-out port 28
scan design. See internal-scan design
scan flip-flop types 101 using a bidirectional port 135
using a functional output port as 137
scan insertion 9
ScanStructures construct
358
dual-clocked scan custom I/O cells 292

format 129 known problem 298
modifying an SPF from TetraMAX 151 set_bsd_signal command (BSD Compiler) 269
single-clocked scan set_bsr_cell_type command (BSD Compiler) 278
format 123 set_case_analysis command (PrimeTime) 311
modifying an SPF from TetraMAX 146 set_dont_touch_network command (DFT
SCANTEST instruction 153, 155, 233, 236, 238 Compiler) 104
SCE file 161, 164, 241 set_dont_use command (DFT Compiler) 110
example 173 set_false_path command (PrimeTime) 312
generating 172 set_scan_configuration command (DFT
SCMCLK statement (TSTL2) 338 Compiler) 100
SCR. See scan-chain reordering -dedicated_scan_ports option 101, 102
SCR_BSDC file set_scan_path command (DFT Compiler) 114
creating 290 set_scan_signal command (DFT Compiler) 103,
reading 272 111–115
SCRDEF file 162, 165, 252, 308 -chain option 114
SCRTST 306, 308 -hookup option 113, 114
command syntax 253 -sense option 114
functions 253 set_scan_transparent command (DFT Compiler) 210
SCSCLK statement (TSTL2) 338 set_signal_type command (DFT Compiler) 115
SCSEL statement (TSTL2) 339 set_test_hold command (DFT Compiler) 102
sequential ATPG 192 shadow effects 44
recommended flow 192 shadow register 184
sequential cells shadow_observe procedure 184
check_test transcript 207 dual-clocked scan 132
set atpg -auto command (TetraMAX) 176 single-clocked scan 124
set atpg -capture_cycles command (TetraMAX) 192, signal type attributes 104
194 SignalGroups construct
set atpg command (TetraMAX) 175, 176, 177 dual-clocked scan
set build -black_box command (TetraMAX) 169, format 129
193 modifying an SPF from TetraMAX 151
set build -hierarchical_delimiter command sign-off systems 71
(TetraMAX) 168, 199 simulating test protocol procedures
set drc command (TetraMAX) 171 run drc transcript 213
set faults command (TetraMAX) 175, 181, 182 single stuck-at fault model 6
set patterns command (TetraMAX) 180 single-clocked scan design 24
set_bsd_compliance command (BSD Compiler) 285 inserting buffer trees 29
set_bsd_configuration command (BSD preventing timing problems 42
Compiler) 273 PrimeTime scripts 220, 315
set_bsd_control_cell command (BSD Compiler) 284 scan test sequence 125
set_bsd_data_cell command (BSD Compiler) 284 test timing parameters 48
set_bsd_instruction command (BSD Compiler) 275 timing verification 219, 313
set_bsd_linkage_port command (BSD TSTL2 timing definition 219, 314
Compiler) 283 skew control 34
set_bsd_pad_design command (BSD Compiler) 270 SP statement (TSTL2) 334, 344
359
SPA file 161, 164, 241 command syntax 231

example 174 functions 229
generating 173 input files 229, 230
SPF 161 output files 229, 230
asynchronous set/reset input signals 125, 132 SPFGENLOG file 231
controlling bidirectional ports 134 STIL 65
creating in DFT Compiler 120 STIL procedure file. See SPF
creating in TetraMAX 121 stuck-at-0 fault 6
creating with SPFGen 120, 162 stuck-at-1 fault 6
disabling JTAG logic 153 SYSCLK statement (TSTL2) 337
dual-clocked scan system clock ports
capture procedure 132 SYSCLK statement (TSTL2) 337
generated by TetraMAX 147 system clock rules 33
load_unload procedure 131 T
MacroDefs construct 132 TAP 15, 61
master_observe procedure 131
pin-sharing 62
organization 127 TAP controller 16, 17
Procedures construct 131 state diagram 17
ScanStructures construct 129 TCK (Test Clock Input) 15
shadow_observe procedure 132 TDCMD file 230
SignalGroups construct 129 TDI (Test Data Input) 16
test_setup macro 132 TDO (Test Data Output) 16
Timing construct 129 Test Access Port. See TAP
generated by DFT Compiler test coverage 182, 195
modifying scan chain names 141 obtaining quick estimates 176
sharing a functional input port with a scan-in test data registers 17
port 136 TEST mode 166, 167, 172
sharing a functional output port with a scan-out test point insertion 45
port 137 test protocol
sharing functional input ports with scan clock defining 106
ports 139 test protocol file. See SPF
single-clocked scan test synthesis 5
capture procedure 124 test timing parameters
generated by TetraMAX 142 determinants 50
load_unload procedure 124 dual-clocked scan 49
MacroDefs construct 125 single-clocked scan 48
organization 122 test_bsd_allow_tolerable_violations variable (BSD
Procedures construct 123 Compiler) 278
ScanStructures construct 123 test_bsd_control_drive_limit variable (BSD
shadow_observe procedure 124 Compiler) 278
test_setup macro 125 test_bsd_manufacturer_id variable (BSD
using a bidirectional port as a scan-out port 135 Compiler) 273
using the JTAG SCANTEST instruction 155 test_bsd_optimize_control_cell variable (BSD
writing in DFT Compiler 109 Compiler) 278
SPFGen 120, 162
360
test_bsd_part_number variable (BSD Compiler) 273 TEST mode 172

test_bsd_version_number variable (BSD writing out a TSTL2 file 177
Compiler) 273 TetraMAX commands
test_default_bidir_delay variable (DFT add clocks 142, 147, 170
Compiler) 107 add faults 175
test_default_delay variable (DFT Compiler) 107 add pi constraints 171
test_default_period variable (DFT Compiler) 107 add pi equivalences 170
test_default_strobe variable (DFT Compiler) 107 man 216
test_disable_find_best_scan_out variable (DFT read faults 193
Compiler) 102 read netlist 142, 147, 168, 169
test_setup macro report faults 181, 182
dual-clocked scan report rules 216
format 132 report scan cells 172
modifying an SPF from TetraMAX 152 report scan chains 172, 241
single-clocked scan report scan path 173, 241
format 125 report summaries 176
modifying an SPF from TetraMAX 146 report summaries sequential_depths 192
test_stil_netlist_format variable (DFT report violations 216
Compiler) 109 run atpg 175, 177
testability 6 run atpg -fast_sequential_only 192
testable fault coverage 182, 195 run build_model 142, 147, 169
test-ready compile 103 run drc 172, 211
test-ready compile. See scan synthesis run pattern_compression 175
TetraMAX set atpg 175, 176, 177
BUILD mode 168 set atpg -auto 176
building the ATPG model 169 set atpg -capture_cycles 192, 194
command file 163 set build -black_box 169, 193
command modes 163 set build -hierarchical_delimiter 168, 199
declaring primary input constraints 171 set drc 171
defining asynchronous set/reset ports 170 set faults 175, 181, 182
defining capture clock groups 170 set patterns 180
defining clocks 170 write drc_file 121, 129, 142, 147
design flow 160, 166 write faults 193
DRC mode 169 write patterns 177, 178, 179, 180
generating an SCE file 172 TetraMAX design kit 72, 84
generating an SPA file 173 system requirements 228
generating fault summary report 176 TetraMAX library 85, 88
invoking 162 reading 168
memory models 191 TFSA 164, 188, 305
performing DRC 172 command input examples 244
reading the library 168 command syntax 243
reading the netlist 169 functions 188, 240
running ATPG 175 input files 241
setting the hierarchical delimiter 168 messages 244
specifying the pattern generation effort 175 output files 241
361
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 UG

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Synopsys DFT UG

Original Title:

Uploaded by

Copyright:

Available Formats

ASIC Design Manual

Synopsys-DFT User Guide 2003

(C) Copyright 2003 TOSHIBA Corporation

All Rights Reserved

Design-for-testability (DFT) is essential to enhance the efficiency and effectiveness

Supported Synopsys Tool Versions

♦ BSD Compiler 2000.11 and above

♦ TetraMAX 2000.11 and above

This manual is organized as follows:

Part 1: DFT Fundamentals

Part 1 provides basic information for design-for-testability (DFT). Designers who

♦ Chapter 1, "Understanding DFT Concepts," discusses motivation for DFT

♦ Chapter 2, "Using the Internal-Scan Methodology," describes things you

♦ Chapter 4, "DFT Considerations," describes the considerations for DFT

Part 2: Using the Synopsys DFT Tools

♦ Chapter 5, "Setting Up the Design Environment," describes how to set up

♦ Chapter 6, "Scan Synthesis Methodology Using DFT Compiler," describes

♦ Chapter 7, "STIL Procedure File (SPF)," provides guidelines for creating

♦ Chapter 8, "Using TetraMAX ATPG," describes how to perform ATPG

♦ Chapter 9, "Validating the Scan Structure and ATPG Test Vectors,"

♦ Chapter 10, "Toshiba TetraMAX Design Kit," mainly describes the

♦ Chapter 11, "JTAG Boundary-Scan Insertion Using BSD Compiler,"

Part 3: Advanced Topics

♦ Chapter 12, "Scan-Chain Reordering (SCR)," provides an outline of scan-

♦ Chapter 13, "Timing Analysis Using PrimeTime," discusses case analysis

♦ Appendix B, "TSTL2 Scan Test Data Description," describes serialized

The following documents provide additional information. Contact your Toshiba

♦ CMOS ASIC Design Manual

♦ VSO/DFT and VITALSO/DFT

♦ Boundary Scan Reference Manual

Part 1 DFT Fundamentals

Chapter 1 Understanding DFT Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Using the Internal-Scan Methodology . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 3 Using JTAG Boundary-Scan Methodology . . . . . . . . . . . . . . . . . . . 55

Chapter 4 DFT Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Part 2 Using the Synopsys DFT Tools

Chapter 5 Setting Up the Design Environment . . . . . . . . . . . . . . . . . . . . . . . . . 83

Chapter 6 Scan Synthesis Methodology Using DFT Compiler . . . . . . . . . . . . 89

Chapter 7 STIL Procedure File (SPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 8 Using TetraMAX ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Chapter 10 Toshiba TetraMAX Design Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Chapter 11 JTAG Boundary-Scan Insertion Using BSD Compiler . . . . . . . . . 255

Part 3 Advanced Topics

Chapter 12 Scan-Chain Reordering (SCR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Chapter 13 Timing Analysis Using PrimeTime . . . . . . . . . . . . . . . . . . . . . . . . . 309

Appendix A Quick Tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Appendix B TSTL2 Scan Test Data Description . . . . . . . . . . . . . . . . . . . . . . . 333

Courier Bold Indicates any reference to a command. In many cases, it

Motivation for DFT

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

Design-for-testability (DFT) is a deliberate design effort to assure that a chip may be

Figure 1–2 Testability Factors

Ad Hoc DFT Techniques

Structured DFT Techniques

Basic Structure of Internal-Scan Design

Figure 1–3 Standard and Scannable Flip-Flops

Figure 1–4 Scan Chain Through a Scanned Design

Primary Comb Comb Primary

Scan Test Sequence

Figure 1–5 Scan Test Sequence

This completes test stimulus

Generally, ATPG has two phases: