DFT Compiler Pre-Scan Test

DRC User Guide (DB Mode)

Version X-2005.09, September 2005
Copyright Notice and Proprietary Information
Copyright  2005 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without
prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks (®)
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, Design
Compiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, I, iN-Phase, in-Sync, Leda, MAST, Meta,
Meta-Software, ModelAccess, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill,
PrimeTime, RailMill, Raphael, RapidScript, Saber, SiVL, SNUG, SolvNet, Stream Driven Simulator, Superlog, System
Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.
Trademarks (™)
abraCAD, abraMAP, Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail,
Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit
Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE,
Cyclelink, Davinci, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design
Analyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, DFT Compiler, Direct RTL, Direct Silicon Access,
Discovery, DW8051, DWPCI, Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler,
EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker,
FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Galaxy, Gatran, HDL Advisor, HDL Compiler,
Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace,
HSPICE-Link, iN-Tandem, Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT,
JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk,
Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200,
MS-3400, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon,
Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler,
PowerCODE, PowerGate, ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael-NES, RoadRunner,
RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon
Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design,
Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP,
SWIFT, Taurus, Taurus-Device, Taurus-Layout, Taurus-Lithography, Taurus-Process, Taurus-Topography, Taurus-Visual,
Taurus-Workbench, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice,
TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System
Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)
MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.
ARM and AMBA are registered trademarks of ARM Limited.
All other product or company names may be trademarks of their respective owners.
Printed in the U.S.A.

DFT Compiler Pre-Scan Test DRC User Guide (DB Mode), X-2005.09

ii
 Contents

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

1. Test Design Rule Checking

Test Design Rule Checking Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Creating the Test Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Assigning a Known Logic State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Reporting Test Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Performing Test Design Rule Checking . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Analyzing and Debugging Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Summary of Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Test Design Rule Checking Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Test Design Rule Checking Message Generation . . . . . . . . . . . . . . . . . . 8
Understanding Test Design Rule Checking Messages . . . . . . . . . . . . . . 8
Effects of Violations on Scan Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Viewing the Sequential Cell Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. The Design Debugger

Invoking Design Vision GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Basic Structure of the Design Vision GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

iii
 Debugging Unified Test DRC Violations in the GUI . . . . . . . . . . . . . . . . . . . . . 13
Opening the Violation Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Navigating Through the Violation Browser . . . . . . . . . . . . . . . . . . . . . . . . 14
Analyzing a Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Understanding the Violation Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Netlist Expansion in the Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Hierarchy Boundaries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Simulation Values in the Violation Schematic . . . . . . . . . . . . . . . . . . . . . . . . . 19
Changing the Annotation of Simulation Values . . . . . . . . . . . . . . . . . . . . 21
Changing the Font, Color and Size of Simulation Values. . . . . . . . . . . . . 22
Understanding the Simulation Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Design Rule Checking During RTL Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3. Classifying Sequential Cells

The Sequential Cell Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Sequential Cells With Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Cells With Scan Shift Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Black Box Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Constant Value Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Sequential Cells Without Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4. Checking for Modeling Violations

Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Correcting Black Box Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Unresolved Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Black Box Library Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Unsupported Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Generic Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Scan Cell Equivalents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Scan Cell Equivalents and the dont_touch Attribute . . . . . . . . . . . . . . . . . . . . 36
Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Nonscan Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

iv
5. Setting Timing Attributes
Protocols for Common Design Timing Requirements . . . . . . . . . . . . . . . . . . . 39
The Strobe-Before-Clock Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
The Strobe-After-Clock Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Setting Timing Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The test_default_period Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
The test_default_delay Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
The test_default_bidir_delay Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
The test_default_strobe Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
The test_default_strobe_width Variable . . . . . . . . . . . . . . . . . . . . . . . . . . 44
The Effect of Timing Attributes on Vector Formatting. . . . . . . . . . . . . . . . 46

6. Test Protocols
Design Characteristics for Test Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The scan_style Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The signal_type Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Clock Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Asynchronous Control Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
STIL Test Protocol File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Defining the test_setup Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Defining Basic Signal Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Defining the load_unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Defining the Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Defining an Initialization Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Scan Shift and Parallel Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Multiplexed Flip-Flop Scan Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Clocked-Scan Scan Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
LSSD Scan Style and Auxiliary-Clock LSSD Scan Style . . . . . . . . . . . . . 57
Examining a Test Protocol File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Updating a Protocol in a Scan Chain Inference Flow. . . . . . . . . . . . . . . . 60
Inferring Scan Structures in LSSD Designs . . . . . . . . . . . . . . . . . . . . . . . 60

7. Masking DRC Violations

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

v
 Setting the Severity of DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Resetting the Severity of DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Reporting the Severity of DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Index

vi
 About This Manual

The DFT Compiler Pre-Scan Test Design Rule Checking User Guide describes
addressing test design rule violations prior to inserting scan chains when using
DFT Compiler.

Audience
This manual is intended for ASIC deisgn engineers who have some exposure
to testability concepts and strategies. It is also useful for test and
design-for-test engineers who want to understand how basic test automation
concepts and practices relate to DFT Compiler.

Related Publications
For additional information about DFT Compiler, see:
• Documentation on the Web, which provides HTML and PDF documents and
is available through SolvNet at:
http://solvnet.synopsys.com
• The documentation installed with the DFT Compiler software and available
through the DFT Compiler Help menu
• Synopsys Online Documentation (SOLD), which is included with the
software for CD users or is available to download through the Synopsys
Electronic Software Transfer (EST) system

vii
About This Manual
Conventions

You might also want to refer to the documentation for the following related
Synopsys products:
• Design Compiler
• BSD Compiler
• TetraMAX

Conventions
The following conventions are used in Synopsys documentation.
Convention Description

Courier Indicates command syntax.

Courier italic Indicates a user-defined value in Synopsys syntax, such as

object_name.

Courier bold Indicates user input—text you type verbatim—in Synopsys

syntax and examples.

Regular bold User input that is not Synopsys syntax, such as a user
name or password you enter in a GUI.

[] Denotes optional parameters, such as

pin1 [pin2 ... pinN]

... Indicates that a parameter can be repeated as many times

as necessary

| Indicates a choice among alternatives, such as

low | medium | high
(This example indicates that you can enter one of three
possible values for an option: low, medium, or high.)

_ Connects terms that are read as a single term by the

system, such as set_annotated_delay

Control-c Indicates a keyboard combination, such as holding down

the Control key and pressing c.

\ Indicates a continuation of a command line.

viii
 About This Manual
Customer Support

Convention Description

/ Indicates levels of directory structure.

Edit > Copy Indicates a path to a menu command, such as opening the
Edit menu and choosing Copy.

Customer Support
Customer support is available through SolvNet online customer support and
through contacting the Synopsys Technical Support Center.

Accessing SolvNet
SolvNet includes an electronic knowledge base of technical articles and
answers to frequently asked questions about Synopsys tools. SolvNet also
gives you access to a wide range of Synopsys online services including
software downloads, documentation on the Web, and “Enter a Call to the
Support Center.”
To access SolvNet:

1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

2. If prompted, enter your user name and password. (If you do not have a
Synopsys user name and password, follow the instructions to register with
SolvNet.)
If you need help using SolvNet, click SolvNet Help in the Support Resources
section.

Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys
Technical Support Center in the following ways:
• Open a call to your local support center from the Web by going to
http://solvnet.synopsys.com (Synopsys user name and password required),
then clicking “Enter a Call to the Support Center.”
• Send an e-mail message to your local support center.
- E-mail support_center@synopsys.com from within North America.

ix
About This Manual
Customer Support

- Find other local support center e-mail addresses at

http://www.synopsys.com/support/support_ctr.
• Telephone your local support center.
- Call (800) 245-8005 from within the continental United States.
- Call (650) 584-4200 from Canada.
- Find other local support center telephone numbers at
http://www.synopsys.com/support/support_ctr.

x
 1
Test Design Rule Checking1

This chapter discusses the test design rule checking flow, the
types of messages generated during the process, and the
effects of violations on scan replacement.

Test Design Rule Checking Flow

Before you invoke dft_drc to perform design rule checking, you must create a
test protocol that includes timing attributes. See Chapter 6, “Test Protocols,” for
information on creating test protocols. If dft_drc reports any violations, you
can use the Graphical Schematic Debugger to fix them. Messages are reported
in three categories: information, warnings, and errors.
Figure 1 illustrates a general test design rule checking flow.

1
Test Design Rule Checking
Test Design Rule Checking Flow

Figure 1 Test DRC Flow

Read and link the design

Yes
Existing Protocol?

No

Set test attributes

on the design

Create a test protocol Read in a test protocol

Run design rule checking Change design and/or

Test protocol

Yes Analyze using Graphical

Violations? Schematic Debugger

No

Proceed to scan synthesis

To prepare for test design rule checking, follow these steps:

1. Read and link the design into DFT Compiler.
2. Determine if you have an existing test protocol for the design.
If so, read the test protocol into DFT Compiler.

2
 Test Design Rule Checking
Test Design Rule Checking Flow

If not, do the following:

- Set the appropriate test attributes on the design
- Create the test protocol.
3. Run Design Rule Checking.
- If test DRC reports no violations, you can insert DFT structures in your
design.
- If test DRC reports violations, analyze the violations using the Graphical
Schematic Debugger.
To fix the violations, either change your design, change your test
protocol, or both.

Preparing the Design

To prepare your design for test DRC, follow these steps:
1. Set the test_enable_dft_drc variable to true.
Note:
When you define this variable, DFT Compiler reports that you are
defining a new variable. This is normal.
2. Set the search_path variable to point to directory paths that contain your
design and library files.
3. Set the link_library variable to point to the technology library files
referred to by your design.
4. Set the target_library variable to point to technology library files you
want mapped to your design.
5. Use the read command to read your design into DFT Compiler;
6. Run the link command to link your design with your technology library.
Refer to Design Compiler documentation for more information on how to read
and link your design.

3
Test Design Rule Checking
Test Design Rule Checking Flow

Creating the Test Protocol

If you have an existing test protocol, read the test protocol into DFT Compiler
by using the read_test_protocol command. If you do not have an existing
test protocol, create it by following these steps:
1. Identify the test-related ports in your design. Such signals include:
- Clocks
- Asynchronous sets and resets
- Scan in
- Scan out
- Scan enable ports
2. Set the test attributes on these ports.
3. Run the create_test_protocol command to create the test protocol for
your design.
Note:
You can choose to infer clocks and asyncs in your design by using the
infer_clock and infer_async options to the create_test_clock
command. However, this action can have a significant runtime hit and it
might not yield optimum results.

Assigning a Known Logic State

You can use the set_test_assume command to assign a known logic state
to output pins of black box sequential cells. The command syntax is
set_test_assume value pin_list
value
Specifies the assumed value, 1 or 0, on this output pin (or pins).
pin_list
Specifies the names of output pins of unknown (black box) cells, including
nonscan sequential cells in full-scan designs. The hierarchical path to the
pin should be specified for pins in subblocks of the current design.
The dft_drc command takes into account the conditions you define with the
set_test_assume command.

4
 Test Design Rule Checking
Test Design Rule Checking Flow

Reporting Test Assertions

Example 1 shows a command sequence where set_test_assume and
set_test_hold were used to assign known logic states. The report_test
-assertions command produces a report that summarizes the assertions
placed on pins and ports in the design.
Example 1 Sample report_test -assertions Output

dc_shell-t> set_test_assume 1 U4/Q

1
dc_shell-t> set_test_hold 1 d1
1
dc_shell-t> report_test -assert

****************************************
Report : test
-assertions
Design : test_af
Version: V-2004.06
Date : Tue Apr 27 13:09:28 2004
****************************************

Assertions:
test_af:
U4/Q pin assumed to be 1
d1 port held to 1

Performing Test Design Rule Checking

After you create or read in a test protocol, perform test design rule checking by
running the dft_drc command.
By default, dft_drc only reports the first instance of any violation that exists in
the design. If you want to see all instances of the same violation, use the
dft_drc -verbose command to report all instances of all the violations.

Analyzing and Debugging Violations

You can analyze the cause of a violation by using the Graphic Schematic
Debugger within the Design Vision environment. The Graphic Schematic
Debugger shows you the list of violations organized by category.

5
Test Design Rule Checking
Test Design Rule Checking Flow

For each violation it reports, the debugger can bring up the schematic that
shows you the source of the violation. The schematic contains simulation
values annotated on the cell pins and design ports.
You can locate the source of the problem by tracing the schematic back to
source of the driver. If you analyze violations at the register-transfer level, the
debugger can also bring up the source RTL code and identify the cause of the
violation.
After you have located the cause of the violation, you can either change the
design, change the test protocol, or do both. Then rerun the steps outlined
above to see if the violations have been fixed.
You can also use AutoFix to fix uncontrollable clocks and asynchronous sets
and resets.

Summary of Violations
At the completion of design rule checking, the dft_drc command displays a
violation summary. Example 2 shows the format of the violation summary.
Example 2 Violation Summary

---------------------------------------------------------------
DRC Report
Total violations: 6
---------------------------------------------------------------

6 PRE-DFT VIOLATIONS
3 Uncontrollable clock input of flip-flop violations (D1)
3 DFF set/reset line not controlled violations (D3)

Warning: Violations occurred during test design rule checking.

(TEST-124)

---------------------------------------------------------------
Sequential Cell Report
3 out of 5 sequential cells have violations
---------------------------------------------------------------

SEQUENTIAL CELLS WITH VIOLATIONS

* 3 cells have test design rule violations

SEQUENTIAL CELLS WITHOUT VIOLATIONS

* 2 cells are valid scan cells

6
 Test Design Rule Checking
Test Design Rule Checking Messages

The total number of violations for the circuit appears in the header. If there are
no violations in the circuit, the dft_drc command displays only the violation
summary header. Within the summary, violations are organized by category. A
violation category appears in the summary only if there are violations in that
category. For each category, the dft_drc command displays the number (n)
of violations along with a short description of each violation and the
corresponding error message number. Using the error message number, you
can find the violation in the dft_drc run.
Unknown cell violations have message numbers in the TEST-450 to TEST-459
range. Unsupported cell violations have message numbers in the TEST-460 to
TEST-469 range. The following is an excerpt from a violation summary for
unsupported and unknown cells:

---------------------------------------------------------------
DRC Report
Total violations: 4
---------------------------------------------------------------

3 MODELING VIOLATIONS

1 Cell has unknown model violation (TEST-451)

Test Design Rule Checking Messages

When you invoke dft_drc, it generates messages to assist you in determining
problems with your scan design. These messages fall into three categories:
• Information
Information messages give you the status of the design rule checker or more
detail about a particular rule violation.
• Warning
A warning message indicates a testability problem that lowers fault
coverage of the design. Most of the violations reported by the dft_drc
command are warning messages. The warnings allow you to evaluate the
effect of violations and determine acceptable violations based on your test
requirements.

7
Test Design Rule Checking
Effects of Violations on Scan Replacement

All warnings reported by dft_drc reduce fault coverage. Try to correct all
violations, because a cell that violates a design rule, as well as the cells in
its neighborhood, are not testable. A cell’s neighborhood can be as large as
its transitive fanin and its transitive fanout.
• Error
An error message indicates a serious problem that prevents further
processing of the design in DFT Compiler until you resolve the problem.

Test Design Rule Checking Message Generation

By default, the dft_drc command generates a message only for the first
violation of a given type. To see all violations, use the dft_drc -verbose
command.
The dft_drc command reports only the first instance of a given violation type.

Understanding Test Design Rule Checking Messages

You can access online help for most warning messages generated by
dft_drc. Online help provides information about the violation and information
about how to proceed. Use the help command to access online help:
dc_shell_t> man message_id

Replace the message_id argument with the string shown in parentheses

following the warning text.
To keep a record of the information, warning, and error messages for your
design, direct the output from the dft_drc command to a file with a command
such as
dc_shell_t> dft_drc > my_drc.out

In this example, my_drc.out is the name of the output file.

Effects of Violations on Scan Replacement

For designs that are synthesized using the compile -scan command, the
default behavior is for violations on scan-replaced cells cause the insert_dft
command to unscan scan elements.

8
 Test Design Rule Checking
Viewing the Sequential Cell Summary

For designs that are not synthesized using the compile -scan command,
violations on sequential cells cause the insert_dft command not to perform
scan replacement.
If you have previously run the dft_drc command, the insert_dft command
uses the results. In the AutoFix flow, the insert_dft command does not use
these results, and it runs dft_drc again.
The insert_dft command issues the following message:
Using test design rule information from previous dft_drc run

If you have not explicitly run the dft_drc command, the insert_dft
command runs dft_drc as a preprocessor to determine which sequential
elements can be included in scan chains. The insert_dft command issues
the following message:
Information: Starting test design rule checking. (TEST-222)

In both cases, when violations occur, the insert_dft command issues the
following message:
Warning: Violations occurred during test design rule checking.
(TEST-124)

You should determine the causes of these violations before proceeding.

Sequential cells with violations are not included in a scan chain, because they
would probably prevent the scan chain from working as intended.

Viewing the Sequential Cell Summary

At the end of the dft_drc output, DFT Compiler provides a summary of the
test status of the sequential cells in your design. Example 3 shows the syntax
of the sequential cell summary generated by DFT Compiler.
Example 3 Sequential Cell Summary
---------------------------------------------------------------
Sequential Cell Report

2 out of 133721 sequential cells have violations

---------------------------------------------------------------

SEQUENTIAL CELLS WITH VIOLATIONS

* 2 cells have capture violations
SEQUENTIAL CELLS WITHOUT VIOLATIONS
*133719 cells are valid scan cells

9
Test Design Rule Checking
Viewing the Sequential Cell Summary

To get a complete listing of all cells in each category, run the dft_drc
-verbose command.
See the information about classifying sequential cells in the DFT Compiler
Scan Replacement User Guide for details about the sequential cell classes.

10
 2
The Design Debugger2

This chapter outlines the use of the violation browser and

violation schematic in Design Vision to debug test design rule
violations flagged by Unified Test DRC.

Invoking Design Vision GUI

To invoke the Design Vision GUI, execute the command:
% $SYNOPSYS_INSTALLATION_PATH/design_vision

Design Vision starts in Tcl mode by default. To invoke it in the standard

dc_shell (EQN) mode, run:
%> design_vision –dcsh_mode

The Design Vision GUI runs in both shell mode and GUI mode . The GUI can
be closed down and started as needed.
To start the Design Vision GUI from the command line, do the following:
%> gui_start

To close the Design Vision GUI in GUI mode, click on File ->Close GUI.
To close the Design Vision GUI from the command line, enter the following:
%> gui_close -all

11
The Design Debugger
Basic Structure of the Design Vision GUI

Basic Structure of the Design Vision GUI

Figure 2 shows the basic Design Vision GUI.
Figure 2 Design Vision GUI

Hierarchy browser Toolbar Console View port

The GUI is made up of the following parts:

• Hierarchy browser
The hierarchy browser lists the design hierarchy in a tree list. Clicking on a
+ sign expands the hierarchy. The schematic for any design in the hierarchy
can be viewed in the GUI by highlighting it and then creating its schematic
in the Viewport.

12
 The Design Debugger
Debugging Unified Test DRC Violations in the GUI

• Toolbar
The toolbar has a pulldown menu to give access to different functions in
design synthesis. It also has other customizable buttons that are used in the
schematic view.
• Console
The console is used in interactive mode when entering commands
manually. It has three tabs: Log, History and Errors/Warnings.
• View Port
The design schematic is displayed in view port. The violation browser
spawned by dft_drc uses this space to display violation schematics. Note
that this is equivalent to the GSV in TetraMAX.

Debugging Unified Test DRC Violations in the GUI

Violations can be debugged in the Design Vision GUI. To do this, open the
violation browser and navigate through the browser to find the violation. View
the violation to analyze and understand it. These steps are discussed in the
sections that follow.

Opening the Violation Browser

A violation browser is displayed when the dft_drc command is executed. See
Figure 3.

13
The Design Debugger
Debugging Unified Test DRC Violations in the GUI

Figure 3 Violation Browser

Violation browser for DRC

The violations are subdivided into different classes. Figure 3 shows two classes
of violations that exist in design modeling and pre-dft. Within each class, the
violations are further subdivided into different DRC rules.

Navigating Through the Violation Browser

DRC violations displayed in the browser can be expanded by clicking on the +
sign beside each rule violation. In Figure 4, DRC rule violation D9 is expanded
and highlighted. Since there is only one D9 rule violation, it expands to show
one violation. If more than one violation exists, they are all listed under that

14
 The Design Debugger
Debugging Unified Test DRC Violations in the GUI

particular rule. A tooltip appears with the complete text when the mouse is
placed over a test design rule violation. See Figure 4.
Figure 4 Violation Browser- A Detailed Look

Analyzing a Violation
A DRC rule violation can be investigated in the GUI schematic mode by
invoking the Violation schematic corresponding to that violation. This is done by
first selecting the violation and then bringing up the context menu with a right
click of the mouse. Select Analyze Violation to bring up the Tooltip with
complete text of the DRC violation shown in the schematic window. Note that
the “Show source” option is grayed out since the design is in a test-ready state
(after compile -scan). The “Show source” option is only enabled for design
rule checking during RTL TestDRC. See Figure 5. The option “Show help” is

15
The Design Debugger
Debugging Unified Test DRC Violations in the GUI

not currently enabled. It will be available in a future release when online help is
fully implemented.
An alternate way to bring up the violation schematic is to click on “Analyze
Violation” button, which is located on the upper right-hand corner of the
violation browser. See Figure 5 below.
Figure 5 Analyze Violation
Click

16
 The Design Debugger
Debugging Unified Test DRC Violations in the GUI

Understanding the Violation Schematic

The violation schematic can be displayed either as a path or a cell schematic,
depending on whether the violation involves a path or a single cell from the
design. The cell in the design for which the violation is reported is highlighted in
red, like the D9 rule violation shown in Figure 6.
Figure 6 Example of a Violation Schematic

Violation schematic Violating element

17
The Design Debugger
Debugging Unified Test DRC Violations in the GUI

Netlist Expansion in the Schematic

You can expand the netlist to the next level of fanin or fanout using the context-
sensitive menu as shown in Figure 7. This is analogous to the netlist expansion
capability in TetraMAX GSV.
Figure 7 Menu for Violation Schematics

To use Add Logic, you must click on the cell’s pin to select it, then right-click to
bring up the menu. This is the equivalent of just clicking on the pin in the GSV.

Hierarchy Boundaries
The violation schematic can span across hierarchies. This is shown through
hierarchy crossing objects, which appear as thin elongated rectangular boxes
in the schematic, as shown in Figure 8.

18
 The Design Debugger
Simulation Values in the Violation Schematic

Figure 8 Hierarchy Boundaries

A tooltip gives information about the hierarchy object and shows whether that
hierarchy separator represents a hierarchy crossing downwards or upwards in
the design.

Simulation Values in the Violation Schematic

The next step after bringing up the violation schematic for a DRC violation is to
understand and trace through the simulation values on the schematic to
understand the cause of the violation. Simulation values are annotated on the
pins of the cells as well as ports. The notation used for simulation values is the
same as that in TetraMAX (“Understanding the Simulation Values” on page 23)

19
The Design Debugger
Simulation Values in the Violation Schematic

Figure 9 shows how simulation values are displayed.

Figure 9 Simulation Values in the Schematic

When the mouse pointer is placed over any pin (or port) in the schematic, a
tooltip appears with the information about that pin (or port), including the
simulation value. This is a useful feature in a complex schematic with many
elements when the simulation values are not visible at the current zoom level.
This is also useful when a simulation value is truncated in the schematic if it is
too long.
Simulation values get annotated for any new netlist that is added to the original
schematic by expanding it (as shown in “Netlist Expansion in the Schematic” on
page 18).

20
 The Design Debugger
Simulation Values in the Violation Schematic

Note that this is a “static schematic” which means that the simulation values
displayed are as returned by the DRC engine. You cannot change these
simulation values “on the fly” to get a new set of corresponding simulation
values on the schematic.

Changing the Annotation of Simulation Values

The default is to display simulation values on all the pins and ports in a violation
schematic. However, controls are provided should you choose to display
simulation values either on input pins/ports only or output pins/ports only or on
both. This is done through a Preferences dialog box (View > Preferences OR
ctrl-K). See Figure 10.
Figure 10 Changing the Annotation of Simulation Values

The following five choices are given under the Visibility menu shown in
Figure 10:
1. None: Do not annotate simulation value on any pin/port
2. In: Annotate simulation values only on input pins and ports
3. Out: Annotate simulation values only on output pins and ports
4. InOut: Annotate simulation values on the bidirectional pins/ports
5. All: Annotate simulation values on all the pins and ports in the violation
schematic.

21
The Design Debugger
Simulation Values in the Violation Schematic

The change in the visibility is a global change and will be applied to all the
violations schematics until changed again.

Changing the Font, Color and Size of Simulation Values

The attributes such as the font, color and size of the simulation values can be
changed using the Preferences dialog box.
A color menu is displayed by left clicking the mouse button.
The fonts, font size and font style can be changed by clicking on the Set Font
menu, which brings up the dialog box for this change. See Figure 11.
Figure 11 Menu to Change Annotation of Sim Values

22
 The Design Debugger
Simulation Values in the Violation Schematic

Understanding the Simulation Values

The information below is intended to provide examples of typical data that is
displayed for pin data.
The data types vary and are explained below:
1. Bidi Control Value
The values displayed are the ones that result when the port is set to its off
state.
- X
- 1
2. Clock Cone
- C
- E
- CE
- N
The characters displayed are an indication of whether the attached net
is in the clock or effect cone for that clock. C indicates the net is in the
clock cone for the selected clock. E indicates the net is in the effect
cone, CE indicates the net is in both, and N indicates the net is in
neither.
3. Constraint Data
The constraint data consists of three pairs of characters T/B,C/B,S/B where:
Change color Change font, font size, font color
- T = simulated value due to tied gates
- B = fault blockage due to tied gates indicated by T
- C = simulated value due to constraints for combinational ATPG: tied
gates, constrained pins, constant value gates
- B = fault blockage due to constraints indicated by C
- S = simulated value due to constraints during sequential scan ATPG
- B = fault blockage due to any constraint indicated by S
The blockage fields are either the characters B for blocked, or - for not
blocked.

23
The Design Debugger
Design Rule Checking During RTL Stage

- A ~ followed by one or more characters is an indication of not allowed

(restricted) values. For example, ~01 means not 0 or 1, or the same as
restricted to X or Z. ~Z means restricted to 0,1, or X.
4. Shift Data
Simulation is performed by setting all constrained pins and constant value
gates to their appropriate values and then simulating the test cycles in the
load_unload prior to the shift procedure to determine the initial values at the
start of the shift procedure. Then the test cycles in the shift procedure are
simulated to provide the values which are displayed.
Examples:
a. XXX
b. 010
c. 000
d. 00010
e. 010/00110

Design Rule Checking During RTL Stage

When you perform test design rule checking in RTL, the Show Source button is
active in the GUI. When you click on the Show Source button, the Source
Browser window opens, highlighting the line of RTL code that caused the
violation, as shown in Figure 12.

24
 The Design Debugger
Design Rule Checking During RTL Stage

Figure 12 The Source Browser in RTL Test Design Rule Checking

25
The Design Debugger
Design Rule Checking During RTL Stage

26
 3
Classifying Sequential Cells3

After the violation summary, the dft_drc command displays

a summary of sequential cell information.

The Sequential Cell Summary

Example 4 shows the syntax of the sequential cell summary.
Example 4 Sequential Cell Summary

---------------------------------------------------------------
Sequential Cell Report

2 out of 133721 sequential cells have violations

---------------------------------------------------------------

SEQUENTIAL CELLS WITH VIOLATIONS

* 2 cells have capture violations

SEQUENTIAL CELLS WITHOUT VIOLATIONS

*133719 cells are valid scan cells

The number of sequential cells with violations appears in the header. This
number is the sum of cells with scan shift violations, capture violations, and

27
Classifying Sequential Cells
Sequential Cells With Violations

constant values, along with cells that are black boxes. If a design has no
sequential cells, only a header with the following message appears:
There are no sequential cells in this design

Within the summary, sequential cells are divided into two groups: those with
violations and those without. Only the categories of sequential cells that are
found in the design are listed in the summary. In verbose mode, cell names are
listed within each category. More information about the sequential cell
categories is provided in the following sections.

Sequential Cells With Violations

This section of the sequential cell summary points to problematic sequential
cells. The cells in this group have corresponding violations that can be found in
the dft_drc output.

Cells With Scan Shift Violations

This category includes cells with scan-in and scan connectivity violations.
Within this category, cells are listed by the type of scan shift violation.
• Not scan-controllable
The dft_drc command cannot transport data from a scan-in port into the
cell.
• Not scan-observable
The dft_drc command cannot transport data from the cell to a scan-out
port.
Note:
Cells in multibit components are homogenous. If a cell in a multibit
component has violations, all of the cells in that multibit component have
violations.
Once dft_drc has run, you can invoke the report_test -scan_path
command to observe the scan chains as extracted by the dft_drc command.

28
 Classifying Sequential Cells
Sequential Cells Without Violations

Black Box Cells

In the black box category are sequential cells that cannot be used for scan shift.
Unknown cells and unsupported cells are black boxes. Black box cells are not
scan-replaced by insert_dft.

Constant Value Cells

The constant value category includes sequential cells that are constant during
scan testing. These cells are assumed to hold constant values; they are not
scan-replaced by insert_dft. For every constant value sequential cell, there
is a corresponding TEST 504 or TEST 505 violation.

Sequential Cells Without Violations

The valid scan cells category displays the number of sequential cells that have
no test design rule violations. ATPG tools can use these cells for scan shift and
for measuring circuit response data. Valid scan cells can be scan-replaced by
insert_dft.
Note:
Valid scan cells can have capture violations. Valid cells with capture
violations only are scan replaced.
The number of synchronization latches is listed in the last category.

29
Classifying Sequential Cells
Sequential Cells Without Violations

30
 4
Checking for Modeling Violations4

If you instantiate a cell that Design Compiler doesn't

understand, you can get modeling violations. The dft_drc
command performs modeling checks locally, one cell at a
time.

Black Boxes
A cell whose output is considered unknown is a black box cell. Black box cells
can be cells without a functional description in the technology library (cells
marked as black box in the report_lib command) or black box sequential
cells identified in the dft_drc command.
The dft_drc command requires that you have a functional model in your
library for each leaf cell in your design. If you use cells that do not have
functional models, the dft_drc command displays the following warning:
Cell %s (%s) is unknown (black box) because functionality for
output pin %s is bad or incomplete (TEST-451)

See the Library Compiler reference manuals for more information on modeling
the behavior of cells.

31
Checking for Modeling Violations
Correcting Black Box Cells

Correcting Black Box Cells

DFT Compiler models a cell as a black box in these cases:
• The link command cannot resolve the cell reference using the technology
libraries or designs in the search_path (unresolved reference).
• The technology library model for the cell reference does not contain a
functional description (black box library cell).
In the following cases, a black box cell can have a severe impact on fault
coverage:
• The black box cells are pad cells.
The dft_drc command completely fails and prevents insert_dft from
working. This occurs at the very top level scan stitching.
• A black box cell controls the enable signal of an internal three-state driver or
a bidirectional.
The insert_dft command inserts three-state and bidirectional control
logic if the existing control logic is a black box, even if you don't need it.
DFT Compiler generates this message when it models a cell as a black box:
Warning: Cell %s (%s) is unknown (black box) because
functionality for output pin %s is bad or incomplete.
(TEST-451)

The method for correcting the violation depends on the source of the violation
and the complexity of the cell.

Unresolved Reference
Use the link command to correct unresolved references.

Black Box Library Cell

If no functional description of the cell exists in the technology library, you need
to obtain either a functional model or a structural model of the cell.
If the cell can be functionally modeled using Library Compiler, obtain an
updated technology library that includes a functional model of the cell.

32
 Checking for Modeling Violations
Unsupported Cells

If you have a simulation model for the black box, declare it by using the
following variable:
% test_simulation_library simulation_library_path

• If you do not have a Library Compiler license or library source code, ask your
semiconductor vendor for a library that contains a functional model of the
cell.
• If you have a Library Compiler license and the library source code, add the
functional description to the library cell model.
See the Library Compiler documentation for information about cell
modeling.
If Library Compiler syntax does not support functional modeling of the cell,
create a structural model for the cell and link the design to this structural model
instead of to the library cell model.

Unsupported Cells
Cells can have a functional description and still not be supported by the
dft_drc command. Using state table models, library developers can describe
cells that violate the current assumptions for test rule checking. The dft_drc
command detects those cells and flags them as black boxes.
DFT Compiler supports single-bit cells or multibit cells that have identical
functionality on each pin; these cells have the following characteristics:
• The functional view, which Design Compiler understands and manipulates,
is either a flip-flop, a latch, or a master-slave cell with clocked_on and
clocked_on_also attributes.
• The test view, used for scan shifting, is either a flip-flop or a master-slave
cell.
• The functional view and the test view each have a single clock per internal
state.
The multibit library cell interfaces must be either fully parallel or fully global. For
cells that do not meet these criteria, DFT Compiler uses single-bit cells.
For example, if you want to infer a four-bit banked flip-flop with an
asynchronous clear, the clear signal must be either different for each bit or
shared among all four bits. If the first and second bits share one asynchronous
reset, but the third and fourth bits share another reset, DFT Compiler does not

33
Checking for Modeling Violations
Unsupported Cells

infer a multibit flip-flop. Instead, DFT Compiler uses four single-bit flip-flops. For
more information about multibit cells and multibit components, see the Design
Compiler Reference Manual: Optimization and Timing Analysis.
DFT Compiler does not support registers or duplicate sequential logic within a
cell. The nonscan equivalent of a scan cell must have only one state. A scan
cell can have multiple states in shift mode.
If the dft_drc command detects such a cell, it issues the following warning:
Cell %s (%s) is not supported because it has too many
states (%d states). This cell is being black-boxed.(TEST-462)

When the dft_drc command recognizes part of a cell as a master-slave latch

pair but finds extra states, it issues one of the following warnings (depending on
the situation):
Master-slave cell %s (%s) is not supported because the state
pin %s is neither a master nor a slave. This cell is being
black-boxed,(TEST-463)
Master-slave cell %s (%s) is not supported because there
are two or more master states. This cell is being
black-boxed,(TEST-464)
Master-slave cell %s (%s) is not supported because there
are two or more slave states. This cell is being
black-boxed,(TEST-465)

If the dft_drc command detects a state with no clocks or with multiple clocks,
it issues one of the following warnings:
Cell %s (%s) is not supported because the state pin %s has no
clocks. This cell is being black-boxed,
(TEST-466)
Cell %s (%s) is not supported because the state pin %s is
multi-port. This cell is being black-boxed.(TEST-467)

In addition, the dft_drc command detects and rejects sequential cells with
three-stated outputs and issues the following warning:
Cell %s (%s) is not supported because it is a sequential
cell with three-state outputs. This cell is being
black-boxed,(TEST-468)

Black box cells have an adverse effect on fault coverage. To avoid this effect,
you must replace unsupported cells with cells that DFT Compiler can support.

34
 Checking for Modeling Violations
Generic Cells

Note:
Unsupported cells can originate only from explicit instantiation. They are not
used by Design Compiler or by DFT Compiler. For more information on
modeling sequential cells, see the Library Compiler User Guide.

Generic Cells
Your design should be a mapped netlist. In RTL stage, dft_drc will map your
design into an internal representation
Some generic cells, such as unimplemented DesignWare parts and operators,
have implicit functional descriptions. The dft_drc command treats as black
box cells and displays the following message:
Warning:Cell %s (%s) is unknown (black box) because functionality
for output pin %s is bad or incomplete. (TEST-451)

If you instantiate generic cells after running compile -scan, you must
recompile your design.

Scan Cell Equivalents

When checking test design rules in a design without scan chains, the dft_drc
command verifies that each sequential element that is not explicitly marked by
using set_scan_element false or set_test_isolate has a scan cell
equivalent in the target library. If a scan cell equivalent does not exist, the
dft_drc command issues the following message:
Warning: No scan equivalent exists for cell %s (%s).
(TEST-120)

Note:
Use the set_scan_element false command to prevent scan
replacement rather than the set_test_isolate command. The
set_test_isolate command is not supported in Unified Test DRC.
The cells in violation are marked as nonscan. In the full-scan methodology,
these cells are black boxes. If these cells are not valid nonscan, they are in
violation and are black boxes. You can suppress the TEST-120 warning with the
set_scan_element command. For example, to ensure that a nonscan latch
cell is not made scannable, enter the command

35
Checking for Modeling Violations
Scan Cell Equivalents and the dont_touch Attribute

dc_shell-t> set_scan_element false latch_name

If you use the set_scan_element command, the dft_drc command issues

the following informational message:
Information: Cell %s (%s) will not be scanned due to a
set_scan_element command. (TEST-202)

If the dft_drc command cannot find scan cell equivalents in the target library,
the probable cause is that the target library does not contain test cells. In such
cases, the dft_drc command issues the following warning:
Warning: Target library for design contains no scan-cell
models. (TEST-224)

For more information on library modeling, see the Library Compiler

documentation.

Scan Cell Equivalents and the dont_touch Attribute

If you set the dont_touch attribute on a cell in your design before scan cell
replacement, that cell is not modified or replaced when you optimize the
design.
If you apply the dont_touch attribute to a scan cell after running compile -
scan on your design, it will not be added to a scan chain.
If your design contains a sequential cell that has the dont_touch attribute
assigned, the dft_drc command produces the following warning:
Warning:Cell %s (%s) can’t be made scannable because it is
dont_touched. (TEST-121)

Note:
Use the dont_touch attribute carefully, because the dont_touch
attribute increases the number of nonscan cells and nonscan cells lower
fault coverage.
You can use set_scan_element false if you do not want to make a
sequential cell scannable but you do want to be able to modify the cell during
optimization.

36
 Checking for Modeling Violations
Latches

Latches
DFT Compiler replaces latches with scannable latches whenever possible. If
the dft_drc command cannot find scan cell equivalents for the latches, it
marks the latches as nonscan and issues the TEST-120 warning as previously
explained.

Nonscan Latches
DFT Compiler models nonscan latches in two ways:
1. As black boxes
2. As synchronization elements
If you don't scan replace your latches, you can ignore “no-scan equivalent”
messages for latches.
A nonscan latch is treated by default as a black box. However, if the latch
satisfies the requirements for a synchronization element, the dft_drc
command treats the latch as a synchronization element.
Note:
In dft_drc, synchronous elements can be on the scan chain.

37
Checking for Modeling Violations
Latches

38
 5
Setting Timing Attributes5

This chapter discusses the setting of timing attributes in your

design. Timing attributes are used by the test protocol for
design rule checking and for dft preview and insertion.

Protocols for Common Design Timing Requirements

Before creating a test protocol and checking test design rules, you need to
identify the timing information for your design. You do this by setting a number
of timing attributes, and, if necessary, by defining test clock requirements.
Timing attributes are discussed in detail in “Setting Timing Attributes” on
page 41.
Defining test clock requirements is discussed in detail in the DFT Compiler
Architecture User Guide.
If you intend to use TetraMAX ATPG, you need to change the default variable
values. If your design’s timing attributes are the same as the variables’ default
values, you do not need to make any changes.

39
Setting Timing Attributes
Protocols for Common Design Timing Requirements

The Strobe-Before-Clock Protocol

The timing requirements for a strobe-before-clock protocol are shown in
Example 5. Check with your semiconductor vendor for specific timing
information.
Example 5 Timing Attributes for a Strobe-Before-Clock Design

test_default_period : 100.00 ;
test_default_delay : 0.00 ;
test_default_bidir_delay : 0.00 ;
test_default_strobe : 40.00 ;
test_default_strobe_width : 1.00;

The Strobe-After-Clock Protocol

To use a strobe-after-clock protocol, set the timing values described in
Example 6. Although the strobe-after-clock protocol works with TetraMAX
ATPG, the strobe-before-clock is more efficient. These are not the default
variable values. Use those timing attributes in the test protocol for the
multiplexed flip-flop design example.
If you intend to use a strobe-after-clock protocol, use the timing attributes
shown in Example 6 for the multiplexed flip-flop design example:
Example 6 Timing Attributes for a Strobe-After-Clock Design

test_default_period : 100.00 ;
test_default_delay : 5.00 ;
test_default_bidir_delay : 55.00 ;
test_default_strobe : 95.00 ;
test_default_strobe_width : 0.0;

If you intend to use a strobe-after-clock protocol with TetraMAX ATPG, use the
timing attributes shown in Example 7 in the test protocol for the multiplexed flip-
flop design example.

40
 Setting Timing Attributes
Setting Timing Attributes

Example 7 Timing Attributes for a TetraMAX ATPG Strobe-After-Clock Design

test_default_period : 100.00 ;
test_default_delay : 0.00 ;
test_default_bidir_delay : 0.00 ;
test_default_strobe : 90.00 ;
test_default_strobe_width : 1.00;

Setting Timing Attributes

Before you run create_test_protocol, you need to define timing
attributes. The command uses the following test variables to determine the
values in the test protocol timing attributes:
test_default_period
test_default_delay
test_default_bidir_delay
test_default_strobe
test_default_strobe_width

Your semiconductor vendor’s requirements, together with the basic scan test
requirements, drive the specification of test timing parameters. If you intend to
use TetraMAX ATPG, you need to change the default variable values. You can
do this every time you create a new design or you can add these variable
values to your local .synopsys_dc.setup file.
The setting of test timing variables is discussed in the following sections.

The test_default_period Attribute

The test_default_period variable defines the default value (in ns) for the
period in the test protocol. The period value must be a positive real number.
By default, DFT Compiler uses a 100-ns test period. If your semiconductor
vendor uses a different test period, specify the required test period using the
test_default_period variable.
The syntax for setting the variable is:
set test_default_period period
For example:
dc_shell-t> set test_default_period 100.0

41
Setting Timing Attributes
Setting Timing Attributes

In the .synopsys_dc.setup file, test_default_period is 100.0 ns.

Note:
The create_test_clock command has a period associated with it. That
period has to be identical to the test_default_period value. If you
change the value of one, you must be sure to check the value of the other.

The test_default_delay Variable

The test_default_delay variable defines the default value (in ns) for the
input delay in the inferred test protocol. The delay value must be a nonnegative
real number less than the strobe value (refer to the default timing in Figure 13).
By default, DFT Compiler applies data to all nonclock input ports 5 ns after the
start of the cycle. If your semiconductor vendor requires different input timing,
specify the required input delay using the test_default_delay variable.
The syntax for setting the variable is:
set test_default_delay delay
For example:
dc_shell-t> set test_default_delay 0.0

If you intend to use TetraMAX ATPG, set the test_default_delay value to

0.0.
In the .synopsys_dc.setup file, test_default_delay is 5.0 ns.

The test_default_bidir_delay Attribute

The test_default_bidir_delay variable defines the default value (in ns)
for the bidirectional delay in the inferred test protocol. The bidir_delay must be a
positive real number less than the strobe value and can be less than, greater
than, or equal to the delay value (refer to the default timing in Figure 13).
By default, DFT Compiler applies data to all bidirectional ports in input mode 55
ns after the start of the parallel measure cycle. In any cycle where a
bidirectional port changes from input mode to output mode, DFT Compiler
releases data from the bidirectional port 55 ns after the start of the cycle. If your
semiconductor vendor requires different bidirectional timing, specify the
required bidirectional delay using the test_default_bidir_delay variable.

42
 Setting Timing Attributes
Setting Timing Attributes

The risks associated with incorrect specification of the bidirectional delay time
include:
• Test design rule violations
• Bus contention
• Simulation mismatches
Minimize these risks by carefully specifying the bidirectional delay time.
DFT Compiler uses the bidirectional delay time as:
• The data application time for bidirectional ports in input mode during the
parallel measure cycle (and during scan in for bidirectional ports used as
scan input or scan-enable signal)
• The data release time for bidirectional ports in input mode during cycles in
which the bidirectional port changes from input mode to output mode
DFT Compiler performs relative timing checks during test design rule checking.
The following requirements must be met:
• The bidirectional delay time must be less than the strobe time.
If you change the strobe time from the default value, confirm that the
bidirectional delay value meets this requirement.
• If the bidirectional port drives sequential logic, the bidirectional delay time
must be equal to or greater than the active edge of the clock.
The syntax for setting the variable is:
set test_default_bidir_delay bidir_delay
For example:
dc_shell-t> test_default_bidir_delay 40.0

If you intend to use TetraMAX ATPG, set the test_default_bidir_delay

value to 0.0. In the .synopsys_dc.setup file, test_default_bidir_delay is
55.0 ns.

The test_default_strobe Variable

The test_default_strobe variable defines the default value (in ns) for the
strobe in the inferred test protocol. The strobe value must be a positive real
number less than the period value and greater than the
test_default_delay value (refer to the default timing in Figure 13).

43
Setting Timing Attributes
Setting Timing Attributes

By default, DFT Compiler compares data at all output ports 95 ns after the start
of the cycle. If your semiconductor vendor requires different strobe timing,
specify the strobe time using the test_default_strobe variable.
The syntax for setting the variable is:
set test_default_strobe strobe
For example:
dc_shell-t> set test_default_strobe 100.0

If you intend to use TetraMAX ATPG, you should set the

test_default_strobe value to 40.0, although that value can vary.
In the .synopsys_dc.setup file, test_default_strobe is 95.0 ns.

The test_default_strobe_width Variable

The test_default_strobe_width variable defines the default value (in ns)
for the strobe width in the inferred test protocol. The strobe width value must be
a positive real number. The strobe value plus the strobe width value must be
less than or equal to the period value (refer to the default timing in Figure 13).
Clocking requirements specified by semiconductor vendors include:
• Clock waveform timing
• Maximum number of unique clock waveforms
• Minimum delay between different clock waveforms (to allow for clock skew
on the tester)
DFT Compiler provides the capability to specify clock waveform timing but does
not place any restrictions on the number of unique waveforms that can be
defined or the minimum time between clock waveforms. Determine what
restrictions the semiconductor vendor places on these timing parameters, and
define clock waveforms that meet the restrictions.
When DFT Compiler infers clock ports during dft_drc, the clock type
determines the default timing for each clock edge. Table 1 provides the default
clock timing for each clock type.

44
 Setting Timing Attributes
Setting Timing Attributes

Table 1 Default Clock Timing for Each Clock Type

Clock type First edge Second edge

Edge-triggered or 45.0 55.0

D-latch enable

Master clock 30.0 40.0

Slave clock 60.0 70.0

Edge-triggered 45.0 60.0

Master clock1 50.0 60.0

Slave clock1 40.0 70.0

1. Default timing for auxiliary-clock LSSD test clocks only

DFT Compiler determines the polarity of the first edge (rise or fall) so that the
first clock edge triggers a majority of cells on a clock. The timing arcs in the
technology library specify each cell’s trigger polarity. The polarity of the second
edge is the opposite of the polarity of the first edge (if the first edge is rising, the
second edge is falling; if the first edge is falling, the second edge is rising).
Use the create_test_clock command to specify clock waveforms if your
semiconductor vendor’s requirements differ from the default timing.
The create_test_clock command has a period associated with it. That
period has to be identical to the test_default_period value. If you change
the value of one, you must check the value of the other.
The syntax for setting the variable is:
set test_default_strobe_width strobe_width
For example:
dc_shell-t> set test_default_strobe_width 1.0

If you intend to use TetraMAX ATPG, set the test_default_strobe_width

value to 1.0.
In the .synopsys_dc.setup file, test_default_strobe_width is 0.0 ns.

45
Setting Timing Attributes
Setting Timing Attributes

Note:
When test_default_strobe_width is 0.0 ns, the strobe width is equal
to one of two values: the difference between the strobe time and the end of
the period, or the difference between the strobe time and the first input event
after the strobe occurs, whichever occurs first.

The Effect of Timing Attributes on Vector Formatting

Figure 13 shows a timing diagram for a stobe-before-clock scheme.
Figure 13 Effect of Timing Attributes on Vector Formatting

Input data stable

Bidirectionals inputs stable

Clocks inactive active inactive

Output data stable stable

Period

Delay = 0

Bidirectional delay = 0

Start of Strobe
Strobe width

46
 6
Test Protocols6

Test protocols are an intrinsic part of your design-for-test

process, and must be created before you run dft_drc. This
chapter describes the process for creating test protocols.

Design Characteristics for Test Protocols

The test protocol is based on certain characteristics of a design. This section
provides an overview of how the protocol is affected by these characteristics.

The scan_style Attribute

Each scan style has a unique method of performing scan shift, which must be
reflected in the test protocol. The “Scan Shift and Parallel Cycles” section, later
in this chapter, describes how scan style influences the scan shift process.

47
Test Protocols
Design Characteristics for Test Protocols

The signal_type Attributes

The signal_type attributes for each test port are set automatically by
insert_dft and preserved if you save the design in Synopsys .db format. If
you have an existing scan design that is not saved in Synopsys .db format, you
must identify each test port with the appropriate signal_type attribute. You
can do this by using the set_signal_type command.

Clock Ports
You specify clock ports (and their timing attributes) using the
create_test_clock command.
Clock ports can also be inferred by tracing back from the clock pins on all
sequential elements to the ports driving these pins. The default timing for the
clock signals is determined by the scan_style setting.

Asynchronous Control Ports

You specify asynchronous control ports by using the set_signal_type
test_asynch command for signals that are active high, and
set_signal_type test_asynch_inverted command for signals that are
active low.
Asynchronous control ports can also be inferred by tracing back from the
asynchronous pins on all sequential elements to the ports controlling these
pins. Asynchronous control ports must be identified because all asynchronous
inputs must be disabled during scan shift to allow predictable loading and
unloading of the scan data.

Bidirectional Ports
In all cycles except parallel measure and capture, all nondegenerated
bidirectional ports are assumed to be in output (driving) mode. They are
appropriately masked. During parallel measure and capture cycles, automatic
test-pattern generation (ATPG) data controls the bidirectional ports as normal
input or output ports, but test_default_bidir_delay controls the timing.

48
 Test Protocols
STIL Test Protocol File Syntax

STIL Test Protocol File Syntax

DFT Compiler reads test protocols written in the STIL (Standard Test Interface
Language). The STIL format is also used by TetraMAX ATPG.
Although the STIL protocol file syntax is the same used by TetraMAX ATPG,
DFT Compiler cannot read some of the STIL elements that are available in
TetraMAX ATPG.
The following STIL elements are not available in DFT Compiler:
• Post load_unload vectors.
• Multiple scan groups in the load_unload procedure.
• Multiple waveforms in the timing section.
The STIL test protocol file syntax elements that are available in DFT Compiler
are discussed in the following sections.
For general information on STIL standards (IEEE Std. 1450.0-1999), see the
STIL home page at:
http://grouper.ieee.org/groups/1450/index.html

Both DFT Compiler and TetraMAX use the IEEE P1450.1 extensions to STIL.
For details, see Appendix E, “STIL IEEE P1450.1 Extensions” in the TetraMAX
ATPG User Guide.

Defining the test_setup Macro

The test_setup macro is optional. It defines any initialization sequences that
the design might need for test mode, or to ensure that the device is in a known
state. A sample test_setup macro is shown in Example 8.

49
Test Protocols
STIL Test Protocol File Syntax

Example 8 Defining the test_setup Macro in the SPF

STIL;
ScanStructures {
ScanChain "c1" { ScanIn SDI2; ScanOut SDO2; }
ScanChain "c2" { ScanIn SDI1; ScanOut D1; }
ScanChain "c3" { ScanIn DIN; ScanOut YABX; }
ScanChain "c4" { ScanIn "IRQ[4]"; ScanOut XYZ; }
}
Procedures {
"load_unload" {
V { CLOCK=0; RESETB=1; SCAN_ENABLE = 1; }
Shift {
V { _si=####; _so=####; CLOCK=P;}
}
}
}
MacroDefs {
test_setup {
V {TEST_MODE = 1; PLL_TEST_MODE = 1; PLL_RESET = 1; }
V {PLL_RESET = 0; }
V {PLL_RESET = 1; }
}
}

If you need to initialize a port to X in the test_setup macro, the STIL

assignment character for this is “N”. An “X” indicates that outputs are measured
and the result is masked.

Defining Basic Signal Timing

If you do not define the signal timing explicitly, DFT Compiler uses its own
default values.
Example 9 contains many additions to define signal timing. Line numbers have
been added for reference.
• Lines 6–9. Defines some additional signal groups so that timing for all inputs
or outputs can be defined in just a few lines, instead of explicitly naming
each port and its timing.
• Lines 12–28. This is a waveform table with a period of 1000 ns that defines
the timing to be used during nonshift cycles.

50
 Test Protocols
STIL Test Protocol File Syntax

• Line 37. Addition of the W statement ensures that BROADSIDE_TIMING is

used for V cycles during the load_unload procedure.
• Line 48. Causes the test_setup macro to use BROADSIDE_TIMING.
Example 9 Defining Timing in the SPF

1. STIL;
2. UserKeywords PinConstraints;
3. PinConstraints { "TEST_MODE" 1; "PLL_TEST_MODE" 1; }
4. SignalGroups {
5. bidi_ports '"D[0]" + "D[1]" + "D[2]" + "D[3]" + "D[4]" +
"D[5]" + "D[6]" + "D[7]" + "D[8]" + "D[9]" + "D[10]" + "D[11]"
+ "D[12]" + "D[13]" + "D[14]" + "D[15]" ‘;
6. input_grp1 'SCAN_ENABLE + BIDI_DISABLE + TEST_MODE +
PLL_TEST_MODE' ;
7. input_grp2 'SDI1 + SDI2 + DIN + "IRQ[4]"' ;
8. in_ports 'input_grp1 + input_grp2';
9. out_ports 'SDO2 + D1 + YABX + XYZ';
10. }
11. Timing {
12. WaveformTable "BROADSIDE_TIMING" {
13. Period '1000ns';
14. Waveforms {
15. CLOCK { P { '0ns' D; '500ns' U; '600ns' D; } } // clock
16. CLOCK { 01Z { '0ns' D/U/Z; } }
17. RESETB { P { '0ns' U; '400ns' D; '800ns' U; } } // async
reset
18. RESETB { 01Z { '0ns' D/U/Z; } }
19. input_grp1 { 01Z { '0ns' D/U/Z; } }
20. input_grp2 { 01Z { '10ns' D/U/Z; } }
// outputs are to be measured at t=350
21. out_ports { HLTX { '0ns' X; '350ns' H/L/T/X; } }
// bidirectional ports as inputs are forced at t=20
22. bidi_ports { 01Z { '0ns' Z; '20ns' D/U/Z; } }
23. // bidirectional ports as outputs are measured at t=350
24. bidi_ports { X { '0ns' X; } }
25. bidi_ports { HLT { '0ns' X; '350ns' H/L/T; } }
26. }
27. } // end BROADSIDE_TIMING
28. }
29. ScanStructures {
30. ScanChain "c1" { ScanIn SDI2; ScanOut SDO2; }
31. ScanChain "c2" { ScanIn SDI1; ScanOut D1; }
32. ScanChain "c3" { ScanIn DIN; ScanOut YABX; }
33. ScanChain "c4" { ScanIn "IRQ[4]"; ScanOut XYZ; }
34. } // end scan structures
35. Procedures {

51
Test Protocols
STIL Test Protocol File Syntax

36. "load_unload" {
37. W "BROADSIDE_TIMING" ;
38. V {CLOCK=0; RESETB=1; SCAN_ENABLE=1; BIDI_DISABLE=1;
bidi_ports = \r16 Z;}
39. V {}
40. V { bidi_ports = \r4 1010 ; }
41. Shift {
42. V { _si=####; _so=####; CLOCK=P;}
43. }
44. } // end load_unload
45. } //end procedures
46. MacroDef {
47. "test_setup" {
48. W "BROADSIDE_TIMING" ;
49. V {TEST_MODE = 1; PLL_TEST_MODE = 1; PLL_RESET = 1;
50. BIDI_DISABLE = 1; bidi_ports = ZZZZZZZZZZZZZZZZ; }
51. V {PLL_RESET = 0; }
52. V {PLL_RESET = 1; }
53. } // end test_setup
54. } //end procedures

Defining the load_unload Procedure

The load_unload procedure contains information about placing the scan
chains into a shiftable state and shifting one bit through them. DFT Compiler
creates this procedure if you define the scan-enable information before you
write out the STIL file.
Example 10 shows the syntax used to define scan chains.
Example 10 Defining Scan Chain Loading and Unloading in the SPF

STIL;
ScanStructures {
ScanChain "c1" { ScanIn SDI2; ScanOut SDO2; }
ScanChain "c2" { ScanIn SDI1; ScanOut D1; }
ScanChain "c3" { ScanIn DIN; ScanOut YABX; }
ScanChain "c4" { ScanIn "IRQ[4]"; ScanOut XYZ; }
}
Procedures {
"load_unload" {
V { CLOCK=0; RESETB=1; SCAN_ENABLE=1; }
}
}

52
 Test Protocols
Defining an Initialization Protocol

Defining the Shift Procedure

The Shift procedure specifies how to shift the scan chains within the definition
of the load_unload procedure. The bold text shown in Example 11 defines the
Shift procedure.
Example 11 Defining the Scan Chain Shift Procedure in the SPF

STIL;
ScanStructures {
ScanChain "c1" { ScanIn SDI2; ScanOut SDO2; }
ScanChain "c2" { ScanIn SDI1; ScanOut D1; }
ScanChain "c3" { ScanIn DIN; ScanOut YABX; }
ScanChain "c4" { ScanIn "IRQ[4]"; ScanOut XYZ; }
}
Procedures {
"load_unload" {
V { CLOCK=0; RESETB=1; SCAN_ENABLE = 1; }
Shift {
V { _si=####; _so=####; CLOCK=P;}
}
}
}

Defining an Initialization Protocol

If your design requires an initialization sequence to configure it for scan testing,
provide the initialization vectors through an initialization protocol. With an
initialization protocol, you provide specific vectors to initialize the design while
letting the create_test_protocol command complete the scan shifting
steps of the protocol.
Use the following process to generate an initialization protocol:
1. Analyze the design to determine its test configuration requirements.
- Determine the initial state required and the initialization sequence
necessary to achieve this state.
- Determine the test configuration required to maintain this initial
condition throughout scan testing.

53
Test Protocols
Defining an Initialization Protocol

2. Generate a default test protocol file.

- Specify timing parameters if you require values other than the default.
- Specify test configuration requirements determined in the analysis step
using the set_test_hold or set_signal_type command.
- Run create_test_protocol to generate the default protocol.
- Use the write_test_protocol command to write the ASCII protocol
file.
3. Create the initialization protocol file.
Modify the initialization sequence in the test_setup section of the test
protocol file.
4. Read in the initialization protocol.
First remove the existing protocol using the remove_test_protocol
command, then read the initialization protocol using the
read_init_protocol command.
5. Re-run create_test_protocol to complete the test protocol.
Run test design rule checking.
If Design Rule Checking still reports test design rule violations, use the
debugging techniques, discussed in Chapter 2, “The Design Debugger,” to
identify and correct problems in the initialization protocol. Refer to the design in
Figure 14 for an illustration of the use of an initialization protocol.
Figure 14 Design that Needs an Initialization Protocol

FF2
test_mode FF1_out

enable FF1

clk

54
 Test Protocols
Defining an Initialization Protocol

In this design, the clock signal, clk, is active low. In order for the clock signal to
reach FF2, we need to initialize it by pulsing clk once, so that the enable signal
FF1_out is asserted. Since the create_test_protocol command has no
knowledge of this requirement, we need to modify the generated protocol to
include this special initialization sequence.
The initialization sequence generated by the create_test_protocol
command looks like the following:
"test_setup" {
W "_default_WFT_";
V { "CLK"=1; }
V { "CLK"=1; "test_mode"=1; }
}

If this initialization sequence has not been modified, test DRC gives the
following violations:
4 PRE-DFT VIOLATIONS
3 Uncontrollable clock input of flip-flop violations (D1)
1 Clock not able to capture violation (D8)

The initialization sequence that is necessary to initialize the circuit is the

following:
"test_setup" {
W "_default_WFT_";
V { "CLK"=1; }
V { "CLK"=1; "test_mode"=1; }
V { "CLK"=P; "test_mode"=1; }
V { "CLK"=1; "test_mode"=1; }

Test DRC requires that all clock signals must be in their inactive state at the end
of the initialization sequence. When this initialization sequence is applied, test
DRC indicates there are no test design rule violations.
However, after insert_dft, this initialization sequence is lost. You must
reapply the same initialization sequence to ensure that post-scan insertion test
DRC reports no violations.

55
Test Protocols
Scan Shift and Parallel Cycles

Scan Shift and Parallel Cycles

Both the standard protocol and the strobe-before-clock protocol access scan
chains in parallel. Scan out for the current pattern and scan in for the next
pattern occur simultaneously.
The process DFT Compiler uses to perform scan shift is determined by the
scan style you selected with the set_scan_configuration -style
command or with the test_default_scan_style environment variable.

Multiplexed Flip-Flop Scan Style

For the multiplexed flip-flop scan style, scan shift is performed by executing the
following steps n times, where n is the number of bits in the longest scan chain:
1. Assert the scan enable signals.
2. Apply scan data at the scan input ports.
3. Pulse the system clocks.
4. Compare scan data at the scan output ports.
During the parallel measure and capture cycles, test design rule checking
treats the scan enable signal as any other parallel input; in some capture
cycles, the captured data can be from the scan path rather than the functional
path. Because fault detection occurs only during the parallel measure cycle and
during comparison of captured data at the scan output ports, treating the scan-
enable signal as a parallel input allows inclusion of scan logic and clock logic in
the fault list and detection of faults on these nodes.
Caution!
Define clocks with the create_test_clock command, not the
test_scan_clock signal type.

56
 Test Protocols
Scan Shift and Parallel Cycles

Clocked-Scan Scan Style

For the clocked-scan scan style, scan shift is performed by executing the
following steps n times, where n is the number of bits in the longest scan chain:
1. Apply scan data at the scan input ports.
2. Pulse the scan clock ports. (Scan clock ports are identified with the
test_scan_clock attribute.)
3. Compare scan data at the scan output ports.

LSSD Scan Style and Auxiliary-Clock LSSD Scan Style

For level-sensitive scan design (LSSD) scan style and auxiliary-clock LSSD
scan style, scan shift is performed by executing the following steps n times,
where n is the number of bits in the longest scan chain:
1. Apply scan data at the scan input ports.
2. Pulse the test master clock, then pulse the slave clock. (Test master clock
ports are identified with the test_scan_clock_a attribute; test slave clock
ports are identified with the test_scan_clock_b attribute.)
3. Compare scan data at the scan output ports.
For full-scan designs, in the auxiliary-clock LSSD scan style, the system clock
is held inactive throughout scan testing; the test clock (identified by the set
signal_type test_clock command) is active in the capture cycle.
For all other scan styles, the parallel measure cycle is performed by applying
data to nonclock input ports, holding clocks inactive, and comparing data at
output ports. The capture cycle is performed by pulsing a clock. Nonclock input
ports remain unchanged from the parallel measure cycle; output ports and
bidirectional ports are masked.

57
Test Protocols
Examining a Test Protocol File

Examining a Test Protocol File

You can convert a test protocol file into an ASCII file that you can view and edit.
To examine this test protocol file, use the write_test_protocol command.
The command syntax is:
write_test_protocol [-out test_protocol_file_name]
[-format stil]

-out test_protocol_file_name
The name of the ASCII output file. The default file name is
design_name.spf, where design_name is the current design, and the
.spf extension identifies the file type as a STIL format test protocol file.
-format stil
Determines if the protocol is written in Standard Test Interface Language
(STIL) format or Synopsys test protocol format (tpf). The default format is
STIL. This book only discusses the STIL format.
Note:
Do not use the write_test_protocol command before you run
create_test_protocol. If you do, you will get an error message to the
effect that no test protocol exists.
Example 12 shows the test protocol file for a multiplexed flip-flop design. This
file was generated using the write_test_protocol command after
executing test design rule checking on the design.
Example 12 Test Protocol for Multiplexed Flip-Flop Design Example

STIL 1.0 {
Design P2000.9;
}
Header {
Title “DFT Compiler 2003.06 STIL output”;
Date “Thu Apr 10 14:30:34 2003”;
History {
}
}
Signals {
“CDN” In; “CLK” In; “DATA” In; “IN1” In; “TEST_SE” In; “TEST_SI”
In;
“OUT1” Out; “OUT2” Out;
}

58
 Test Protocols
Examining a Test Protocol File

SignalGroups {
“all_inputs” = ‘”CDN” + “CLK” + “DATA” + “IN1” + “TEST_SE” +
“TEST_SI”’; // #signals=6
“all_outputs” = ‘”OUT1” + “OUT2”’; // #signals=2
“all_ports” = ‘”all_inputs” + “all_outputs”’; // #signals=8
“_pi” = ‘”all_inputs”’; // #signals=6
“_po” = ‘”all_outputs”’; // #signals=2
}
Timing {
WaveformTable “_default_WFT_” {
Period ‘100ns’;
Waveforms {
“all_inputs” { 0 { ‘5ns’ D; } }
“all_inputs” { 1 { ‘5ns’ U; } }
“all_inputs” { Z { ‘5ns’ Z; } }
“all_inputs” { N { ‘5ns’ N; } }
“all_outputs” { X { ‘0ns’ X; } }
“all_outputs” { H { ‘0ns’ X; ‘95ns’ H; } }
“all_outputs” { T { ‘0ns’ X; ‘95ns’ T; } }
“all_outputs” { L { ‘0ns’ X; ‘95ns’ L; } }
“CLK” { P { ‘0ns’ D; ‘45ns’ U; ‘55ns’ D; } }
“CDN” { P { ‘0ns’ U; ‘45ns’ D; ‘55ns’ U; } }
}
}
}
PatternBurst “__burst__” {
PatList {
“__pattern__” {
}
}
}
PatternExec {
PatternBurst “__burst__”;
}
Procedures {
“capture” {
W “_default_WFT_”;
V { “_pi”=\r6 #; “_po”=\r2 #; }
}
“capture_CLK” {
W “_default_WFT_”;
“forcePI”: V { “_pi”=\r6 #; }
“measurePO”: V { “_po”=\r2 #; }
“pulse”: V { “CLK”=P; }
}
“capture_CDN” {
W “_default_WFT_”;
“forcePI”: V { “_pi”=\r6 #; }

59
Test Protocols
Examining a Test Protocol File

“measurePO”: V { “_po”=\r2 #; }
“pulse”: V { “CDN”=P; }
}
}
MacroDefs {
“test_setup” {
W “_default_WFT_”;
V { “CLK”=0; }
V { “CDN”=1; “CLK”=0; }
}
}

Updating a Protocol in a Scan Chain Inference Flow

If you import an existing-scan netlist without any test attributes, test DRC can
infer the scan structures if you perform the following steps:
1. Specify test clocks and other test attributes in the design.
2. Create a test protocol.
3. Run test DRC using the -infer_scan_structures option to the
dft_drc command.
If scan chain inference is successful, the protocol is updated to contain
procedures to shift the scan chain.

Inferring Scan Structures in LSSD Designs

If you use the infer_scan_structures option to the dft_drc command in
an LSSD scan style design, the protocol that is generated does not contain the
master_observe procedure. An S9 violation is reported, saying the
master_observe procedure is missing. This is a known problem. The
workaround is to run test DRC again, this time without the
infer_scan_structures option.

60
 7
Masking DRC Violations7

This chapter discusses the commands you can use to set,

reset, or report the severity of selected DRC violations for
constant cells.

Overview
DFT Compiler includes three commands that are used in support of setting,
resetting, or reporting the severity of DRC violations:
• set_dft_drc_rules
• reset_dft_drc_rules
• report_dft_drc_rules

This chapter describes how to use each of these commands.

61
Masking DRC Violations
Setting the Severity of DRC Violations

Setting the Severity of DRC Violations

The set_dft_drc_rules command is used to modify the severity of
selected DRC violations to either ERROR, WARNING, or IGNORE. The
following violations code are supported:
• TEST-504 : Constant 0 violations
• TEST-505 : Constant 1 violations
• D17 : Clock i/p type cell_name can not capture the data.

The syntax for the set_dft_drc_rules command is as follows:

set_dft_drc_rules
[-error {drc_error_ID}]
[-warning {drc_error_ID}]
[-ignore {drc_error_ID}]
[-cell {cell_list}]
-error {drc_error_ID}
Explicitly changes the severity of the specified violations to
ERROR. If you change the severity to ERROR, the dft_drc command will
report the specified violations as error and the insert_dft command will
fail.
-warning {drc_error_ID}
Explicitly changes the severity of the specified violations to
WARNING. If you change the severity to WARNING, the insert_dft
command will ignore the violation. However, the dft_drc command will
still report the specified violations.
-ignore {drc_error_ID}
Explicitly changes the severity of the specified violations to
IGNORE. If you change the severity to IGNORE, the dft_drc and
insert_dft commands will ignore the violation.
-cell {cell_list}
Specifies the cells for which the violation severity is to be changed.
If no cells are specified, the violation severity is changed for all
the cells in the design.
To use this command, you first need to specify the violation using the -error,
-warning, or -ignore options, then enter the applicable DRC violation ID.

62
 Masking DRC Violations
Resetting the Severity of DRC Violations

You can explicitly specify the cells you want to change using the -cell option
and entering the names of the applicable cells. If you don’t specify the -cell
option, the set_dft_drc_rules command will apply to all cells in the
design.
The following set of examples changes:
• the severity of DRC violation TEST-504 for all cells to WARNING
• the severity of DRC violation TEST-505 for cells reg3 and reg4 to WARNING
• the severity of DRC violation TEST-505 for cell reg6 to IGNORE

dc_shell-t> set_dft_drc_rules -warning {TEST-504}

dc_shell-t> set_dft_drc_rules -warning {TEST-505} \

-cell {reg3 reg4}

dc_shell-t> set_dft_drc_rules -ignore {TEST-505} \

-cell {reg6}

Resetting the Severity of DRC Violations

The reset_dft_drc_rules command can be used to change the severity of
the violations reported by the dft_drc command to their default value. The
reset_dft_drc_rules command can be used to change the severity only if
the severity of that violation is has been changed by using
set_dft_drc_rules command. A list of valid violations is shown below:
• TEST-504 : Constant 0 violations
• TEST-505 : Constant 1 violations
• D17 : Clock i/p type cell_name can not capture the data.

The syntax for the reset_dft_drc_rules command is as follows:

reset_dft_drc_rules
-violation {drc_error_ID}
[-cell {cell_list}]
-violation {drc_error_ID}
Explicitly changes the severity of the specified violations to their default
value.

63
Masking DRC Violations
Reporting the Severity of DRC Violations

-cell {cell_list}
Specifies the cells for which the violation severity is to be changed to their
default value. If no cells are specified, the violation severity is changed for
all the cells in the design.

The following set of examples changes the severity of DRC violation TEST-504
for all cells to default severity ERROR, and TEST-505 for cells reg3, reg4 to
default severity ERROR:

dc_shell-t> reset_dft_drc_rules -violation {TEST-504}

dc_shell-t> reset_dft_drc_rules -violation {TEST-505} \

-cell {reg3 reg4}

Reporting the Severity of DRC Violations

The report_dft_drc_rules command can be used to check the violation
severity status on cells in a design.
The syntax for the reset_dft_drc_rules command is as follows:
report_dft_drc_rules
[-all]
-violation {drc_error_ID}
[-cell {cell_list}]
-all
Reports all the cells for which the violation severity has been changed by the
user.
-violation {drc_error_ID}
Reports the cells for which the severity of the specified violation(s) has been
changed.
-cell {cell_list}
Specifies the cell(s) for which the violation severity is to be reported.
The following example set first changes the severity of DRC violation
TEST-504 for all cells to WARNING, TEST-505 for cells reg3, reg4 to
WARNING and TEST-505 for cell reg6 to IGNORE. The corresponding
outputs for the report_dft_drc_rules command are shown below:

64
 Masking DRC Violations
Reporting the Severity of DRC Violations

dc_shell-t> set_dft_drc_rules -warning {TEST-504}

dc_shell-t> set_dft_drc_rules -warning {TEST-505} \

-cell {reg3 reg4}

dc_shell-t> set_dft_drc_rules -ignore {TEST-505}

-cell {reg6}

dc_shell-t> report_dft_drc_rules

Severity of the following violations have been changed by

the user.
----------------------------------------------------------
TEST-504 : Constant 0 violation
TEST-505 : Constant 1 violation

dc_shell-t> report_dft_drc_rules -all

Violation Default Specifed Range/

Name Severity Severity Cell list
---------------------------------------------------------
TEST-504 error warning all cells
TEST-505 error warning reg3
error warning reg4
error ignore reg6

dc_shell-t> report_dft_drc_rules -violation \

{TEST-504 TEST-505}

Violation Default Specifed Range/

Name Severity Severity Cell list
---------------------------------------------------------
TEST-504 error warning all cells
TEST-505 error warning reg3
error warning reg4
error ignore reg6

dc_shell-t> report_dft_drc_rules -cell {reg2 reg4}

Cell Violation Default Specifed

Name Name Severity Severity
---------------------------------------------------------
reg2 TEST-504 error warning
reg4 TEST-504 error warning
TEST-505 error warning

65
Masking DRC Violations
Reporting the Severity of DRC Violations

66
 Index

A commands
create_test_clock 45, 48
asynchronous control ports 48 dft_drc
available STIL formats 49 violation reporting 8
help 8
B link 32
set_scan_configuration
behavioral modeling 31
-style option 56
bidirectional delay
write_test_protocol 58
(see also test_default_bidir_delay variable) 42
correcting
default 42
black box library cells 32
incorrect, risks of 43
create_test_clock command 45, 48
requirements 43
specifying 42
usage 43 D
bidirectional ports default test protocol
design characteristics 48 specifying timing information 41
bidirectional timing 42 design characteristics and test protocol 47
black box cell dft_drc
causes 32 and insert_dft 9
set_test_assume 31 directing output to a file 8
structural model 33 dont_touch attribute 36
functional cell models 31
C nonscan latches 37
scan equivalent cells 35
clock timing
set_scan false command 36
default 45
set_scan_element command 35
meeting vendor requirements 44
summarizing violations 6
specifying 45
dft_drc command
messages
error (see also messages, error) 8
warning (see also messages, warning) 7
-verbose option 8, 10
violation reporting 8

67
dont_touch attribute, and dft_drc 36 multibit
supported library cells 34
E
environment variables N
test_default_scan_style 56 nonscan latch modeling 37

F O
fault coverage online help, messages 8
evaluating output
sequential cell summary 9 strobe
functional model 31 default 44
specifying 44
H
help command 8 R
requirements
bidirectional delay 43
I
identifying
black box cells 32 S
inferred test protocol scan cell equivalent check 35
bidirectional delay 42 scan replacement
default delay 42 effects of violations 8
examining 58 scan shift
scan shift and parallel cycles 56 auxiliary-clock LSSD scan style 57
information message, dft_drc 7 clocked-scan scan style 57
input LSSD scan style 57
delay multiplexed flip-flop scan style 56
default 42 scan_style attribute 47
specifying 42 sequential cell
timing 42 summary report 9
insert_dft command sequential cells
and dft_drc 9 exclusion from scan chains 9
summary
with violations 28
L without violations 29
link command 32 set_scan_configuration command 56
load_unload procedure set_scan_element command
STIL format 52 and dft_drc 36
to prevent scan replacement 36
M to suppress TEST-120 warning 35
meeting vendor requirements set_test_hold 54
test timing shift procedure
clock waveforms 44 STIL format 53
messages signal timing
information 7 STIL format 50
warning signal_type attribute 48
TEST-451 32

68
specifying test_scan_clock attribute 57
bidirectional delay 42 test_scan_clock_a attribute 57
clock timing 45 test_scan_clock_b attribute 57
input delay 42
test_setup macro 49
output strobe 44
TEST-120 35
test period 41
STIL formats TEST-121 36
available 49 TEST-124 9
load_unload procedure 52 TEST-202 36
shift procedure 53 TEST-224 36
signal timing 50 TEST-450 to TEST-459 7
test_setup macro 49 TEST-451 31, 35
strobe 44 TEST-451 message 32
structural model, example 33 TEST-460 to TEST-469 7
summarizing violations 6 TEST-462 34
TEST-463 34
T TEST-464 34
test design rules 8 TEST-465 34
test period TEST-466 34
default 41 TEST-467 34
specifying 41 TEST-468 34
test protocol timing
design characteristics 47 attributes
test variables effect on vector formatting 46
test_default_bidir_delay 42
test_default_delay 42 U
test_default_period 41
unsupported cells 35
test_default_strobe 43
test_default_strobe_width 44
test_default_bidir_delay variable 42 V
definition 42 variables
setting 42 test
test_default_delay variable 42 test_default_bidir_delay 42
definition 42 test_default_delay 42
setting 42 test_default_period 41
test_default_period variable 41 test_default_strobe 43
definition 41 test_default_strobe_width 44
setting 41 test_default_bidir_delay 42
test_default_delay 42
test_default_scan_style variable 56
test_default_period 41
test_default_strobe variable 44
test_default_scan_style 56
definition 43
test_default_strobe 44
setting 43
vector
test_default_strobe_width variable
formatting, timing attributes 46
definition 44
-verbose option, dft_drc command 8, 10
setting 44

69
violations W
modeling
black boxes 31 write_test_protocol command 58
generic cells 35
latches 37
no scan cell equivalents 35
scan cell equivalents and dont_touch attribute
36
unsupported cells 33
preventing scan insertion 62, 63, 64
summarizing 6

70