DFT Compiler DFT Planning

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 DFT Planning User Guide (DB Mode), X-2005.09

ii
 Contents

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

1. Design-for-Test Methodologies
Getting the Best Results With Scan Design. . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Scan Insertion Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Bottom-Up Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Top-Down Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Design-for-Test Flows in the Logical Domain

Setting Up the Design Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Overview of Design-for-Test Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
DFT Flow for Unmapped Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Synthesizing the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Post-Processing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Building Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
DFT Flow for Mapped Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Reading in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Performing Scan Replacement and Building Scan Chains . . . . . . . 18
DFT Flow for Mapped Designs With Existing Scan . . . . . . . . . . . . . . . . . 20
Reading in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Checking Test Design Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Designing Block by Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii
 Invoking Constraint-Optimized Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . 25
Scan Replacement and Assembly in a Single Step . . . . . . . . . . . . . . . . . 25
Scan Replacement Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Specifying Scan Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3. Design-for-Test Flows in the Physical Domain

Introduction to Physical Scan Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Overview of Placement-Based Design-for-Test Flows . . . . . . . . . . . . . . . . . . . 30
RTL-to-Placed-Gates Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Gates-to-Placed-Gates Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Placement-Based Reordering of Existing Scan Chains . . . . . . . . . . . . . 34
Scan Chain Ordering and Partitioning Techniques . . . . . . . . . . . . . . . . . . . . . 35
Scan Cell Ordering to Reduce Congestion . . . . . . . . . . . . . . . . . . . . . . . 35
Timing-Based Scan Cell Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Placement-Based vs. Timing-Based Scan Cell Ordering. . . . . . . . . 36
Typical Flow for Timing-Based Scan Cell Ordering . . . . . . . . . . . . . 38
Placement-Based Scan Chain Partitioning . . . . . . . . . . . . . . . . . . . . . . . 39
Hierarchical Scan Synthesis in the Physical Domain. . . . . . . . . . . . . . . . . . . . 40
Introduction to Interface Logic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating ILMs for Hierarchical Scan Synthesis . . . . . . . . . . . . . . . . . . . . 42
Extracting Interface Logic Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Block-Level Gates-to-Placed Gates (G2PG) Flow . . . . . . . . . . . . . . 43
Block-Level RTL-to-Placed-Gates (RTL2PG) Flow . . . . . . . . . . . . . 44
Chip-Level Gates-to-Placed Gates (G2PG) Flow. . . . . . . . . . . . . . . 44
Chip-Level RTL-to-Placed-Gates (RTL2PG) Flow . . . . . . . . . . . . . . 45
Interface Logic Model Command and Variable Summary . . . . . . . . . . . . 46
The create_ilm Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The propagate_ilm -delay Command . . . . . . . . . . . . . . . . . . . . . . . . 47
The propagate_ilm -placement Command . . . . . . . . . . . . . . . . . . . . 47
The test_use_test_models Variable . . . . . . . . . . . . . . . . . . . . . . . . . 47
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Unknown Design State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Missing Port and Cell Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Existing Scan Setting Incorrect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Timing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Leaving Scan Enables Unrouted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
If Your Design Still Has Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

iv
4. Default Scan Synthesis
Scan Replacement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Scan Element Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Test Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Area and Timing Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5. Using Constraint-Optimized Scan Insertion

Constraint-Optimized Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Locating Scan Equivalents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Preparing for Constraint-Optimized Scan Insertion . . . . . . . . . . . . . . . . . 58
Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Scan Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
DFT Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Preview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6. Power Compiler and DFT Compiler Interoperability

Improving Testability in Clock Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Inserting Control Points in Control Clock Gating . . . . . . . . . . . . . . . . . . . 66
Scan Enable Versus Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Inserting Observation Points to Control Clock Gating . . . . . . . . . . . . . . . 69
Choosing a Depth for Observability Logic . . . . . . . . . . . . . . . . . . . . . . . . 71
Hooking Up Test Ports Through Hierarchies in Power Compiler . . . . . . . 71
Power Compiler / DFT Compiler Interoperability Flows . . . . . . . . . . . . . . . . . 74
Using test_mode with Power Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Using Scan Enables with Power Compiler . . . . . . . . . . . . . . . . . . . . . . . . 75
Latch-Free Clock Gating Configurations . . . . . . . . . . . . . . . . . . . . . 77
Same Clock Driving High and Low Clock Gating . . . . . . . . . . . . . . . . . . . 78

v
 7. More DFT Methodologies
What is Test Data Volume Reduction for Scan? . . . . . . . . . . . . . . . . . . . . . . . 81
Analyzing Observe Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Bottom-Up Observe Test Point Analysis and Insertion . . . . . . . . . . . . . . 82
AutoFix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Shadow LogicDFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Hierarchical Scan Synthesis (HSS) Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Introduction to Test Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Creating Test Models for Subdesigns . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Linking Test Models to Library Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Checking if a Library Contains CTL Models. . . . . . . . . . . . . . . . . . . . . . . 92
Scan Assembly Using Test Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Using Netlist Information Instead of the Test Model. . . . . . . . . . . . . . . . . 93
Saving Test Models for Subdesigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Using Test Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Reading Designs Into TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Managing Test Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Top Level Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Index

vi
 About This Manual

The DFT Compiler DFT Planning User Guide describes the planning phase for
your DFT project 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 [email protected] 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
Design-for-Test Methodologies1

This chapter discusses basic methodologies for performing

design-for-test, and top-down and bottom-up design flows.

Getting the Best Results With Scan Design

To get the best scan design results, your ATPG tool must be able to control the
inputs and observe the outputs of individual cells in a circuit. By observing all
the states of a circuit, the ATPG tool can check each output to see whether
circuitry is good or faulty. This process of checking every state of a device
under test to identify faulty circuitry is known as fault coverage. The quality of
the fault coverage depends on how well a device’s circuitry can be observed
and controlled.
If the ATPG tool cannot observe the states of individual sequential elements in
the circuit, fault coverage is lowered because the distinction between a good
circuit and a faulty circuit is not visible at some output.
To maximize your fault coverage, follow these recommendations:
• Use full scan.
• Fix all design rule violations.
• Follow these design guidelines:

1
Design-for-Test Methodologies
Getting the Best Results With Scan Design

- Be careful when you use gated clocks. If the clock signal at a flip-flop or
latch is gated, a primary clock input might not be able to control its state.
If your design has extensive clock gating, use AutoFix or provide
another way to disable the gating logic in test mode.
Note:
DFT Compiler supports gated-clock structures inserted by Power
Compiler.
- Generate clock signals off-chip. If clock signals are generated on-chip
(as in frequency dividers), you cannot control the state of the sequential
cells driven by these signals. If your design includes internally
generated clock signals, use AutoFix or provide another way to bypass
these signals during testing.
- Minimize combinational feedback loops. Combinational feedback loops
are difficult to test because they are hard to place in a known state.
- Use scan-compatible sequential elements. Be sure that the library you
select has scannable equivalents for the sequential cells in your design.
- Avoid uncontrollable asynchronous behavior. If you have asynchronous
functions in your design (for example, flip-flop preset and clear), use
AutoFix so that you can control the asynchronous pins, or make sure
you can hold the asynchronous inputs inactive during testing.
- Control bidirectional signals from primary inputs.
The scan design technique does not work well with certain circuit structures,
such as:
• Large, nonscan macro functions (for example, microprocessor cores)
• Compiled cells (for example, RAM and arithmetic logic units)
• Analog circuitry
For these structures, you must provide a test method that you can integrate
with the overall scan-test scheme.

2
 Design-for-Test Methodologies
Scan Insertion Methodologies

Scan Insertion Methodologies

This section discusses the following scan insertion methodologies:
• Bottom-Up Scan Insertion
• Top-Down Scan Insertion

Bottom-Up Scan Insertion

DFT Compiler supports bottom-up and top-down scan insertion. To improve
DFT Compiler performance on multimillion gate designs, use the hierarchical
scan synthesis flow. The hierarchical scan synthesis flow improves runtime,
reduces memory usage, and significantly increases the capacity of DFT
Compiler. For bottom-up scan insertion, follow the flows outlined earlier in this
chapter for each module of the design. For each subdesign, save a test model
for the scan-inserted design. At higher levels, stitch together the test models
containing the subdesigns (see Figure 1 on page 4).

3
Design-for-Test Methodologies
Scan Insertion Methodologies

Figure 1 Bottom-Up Scan Insertion Flow

Module 1 Module 2 Module n

Synthesize and Synthesize and Synthesize and

replace scan replace scan replace scan
…
Assemble scan Assemble scan Assemble scan
chains chains chains

Create test Create test Create test

model model model

Define test
protocol

Check scan
design rules

Assemble scan
chains

Check scan
design rules

Write test
protocol

ATPG

To use the bottom-up scan insertion flow, perform the following steps:

1. Synthesize your design, performing scan replacement.

2. Build scan chains in each module of the design.
3. Define the test protocol at the top level.

4
 Design-for-Test Methodologies
Scan Insertion Methodologies

The test protocol provides information about your design to the test design
rule checker.
4. Check design rules at the top level.
Evaluate the scan conformance of your design and determine if any
sequential cells violate the test design rules. Test design rule checking also
highlights design issues that can lower your fault coverage results.
If the results of your analysis show that the design does not meet your
requirements, you can often improve the results by modifying the test
protocol. However, in some cases you might have to modify the HDL
description.
5. Assemble the scan chains.
After inserting scan cells in all modules, assemble the scan chains at the top
level of the design. Use the same procedure for assembling scan chains at
the top level that you used at the module level, then run dft_drc to make
sure the resulting scan chains operate properly.
6. Finally, write out the verilog netlist and the test protocol to export to
TetraMAX (if you use TetraMAX as your ATPG tool).

Top-Down Scan Insertion

With top-down scan insertion, perform scan insertion only at the top level of the
design (See Figure 2).
Figure 2 Top-Down Scan Insertion

Complete Design
Synthesize and
replace scan

Assemble scan
chains

Write test
protocol

ATPG

5
Design-for-Test Methodologies
Scan Insertion Methodologies

To use the top-down scan insertion flow, perform the following steps:
1. Synthesize your design, performing scan replacement.
2. Build scan chains at the top level of the design.
3. Write out the verilog netlist and the test protocol to export to TetraMAX (if
you use TetraMAX as your ATPG tool).

6
 2
Design-for-Test Flows in the Logical Domain2

This chapter discusses design-for-test flows in the logical

domain. It includes the process for setting up your design
environment, an overview of the flows, and a description of
block-by-block design.

Setting Up the Design Environment

Regardless of the flow, use the following Synopsys system variables to define
the key parameters of your design environment:

Term Definition

link_library The ASIC vendor library where your design is initially

represented.

target_library Usually the same as your link_library, unless

you are translating a design between technologies.

symbol_library A file that contains definitions of the graphic symbols

that represent cells in design schematics.

7
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Term Definition

search_path A list of alternate directory names to search to find

the link_library, target_library,
symbol_library, and design files.

test_default_scan_style Defines the scan style used if you do not specify the
-style option of the set_scan_configuration
command. Possible scan styles are
multiplexed_flip_flop, clocked_scan,
lssd, and aux_clock_lssd.

For more information about these variables, see your Design Compiler
documentation.

Overview of Design-for-Test Flows

This section introduces the methodology recommended for simple designs
when you use DFT Compiler. All of these flows use top-down compile and scan
insertion flows.
The flow you use depends on the state of the design before you start using
DFT Compiler:
• If the design is not mapped (compiled), use the DFT flow for unmapped
designs.
• If the design is mapped and does not contain existing scan, use the DFT
flow for mapped designs.
• If the design is mapped and contains existing scan, use the DFT flow for
mapped designs with existing scan.

DFT Flow for Unmapped Designs

Using the command sequence provided in this section, you can take a design
from an HDL-level circuit description (without existing scan) to a fully optimized
design with internal scan circuitry. The sample command sequence applies to a
full-scan or partial-scan design. The basic process consists of the following:
• Synthesizing the design using test-ready compile
• Building scan chains

8
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

• Generating test patterns using TetraMAX

For information about how to pass the design on to TetraMAX ATPG to
generate test patterns, see the DFT Compiler Exporting to Other Tools User
Guide. Also, see the TetraMAX ATPG User Guide for information about
generating test patterns using TetraMAX from a DFT Compiler flow.
Figure 3 shows a typical unmapped design flow that uses HDL Compiler and
DFT Compiler. At the end of the flow, TetraMAX ATPG produces a set of high
fault coverage test vectors that you can readily adapt to your target tester.

9
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Figure 3 Typical Flat Design Flow From an Unmapped Design

HDL

HDL Compiler, Set constraints

Design Compiler,
Set scan style
DFT Compiler

Check design rules Correct problems

Run test-ready compile Adjust constraints

or compile strategy

Not met
Check constraints

Met
Check design rules Correct problems

Set scan configuration

Build scan chains

Optimized netlist with scan

Not
Check constraints Adjust constraints or
met try incremental compile
Met

Check design rules Correct problems

Save testable design

Create and format

test patterns

TetraMAX ATPG
Compacted high fault coverage
test vectors

10
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Synthesizing the Design

To synthesize the design, perform the following steps:

1. Select the target technology library and the link technology library.
dc_shell-t> set target_library asic_vendor.db
dc_shell-t> set link_library [ list * asic_vendor.db ]

2. Set up for design rule checking on the RTL source.

dc_shell-t> set hdlin_enable_dft_drc_info true

3. Use one of the following commands to read in an HDL circuit description:

dc_shell-t> read_file -format verilog design_name.v
dc_shell-t> read_file -format vhdl design_name.vhdl

4. Explicitly link the design:

dc_shell-t> link

If Design Compiler is unable to resolve any references, you must provide the
missing designs before proceeding. See your Design Compiler
documentation for details.
5. Select the design constraints. In this example, the design is constrained to
be no larger than 1,000 vendor units in area, and it runs with a 20-ns clock
period. Enter the following commands:
dc_shell-t> set max_area 1000
dc_shell-t> create_clock clock_port -period 20 \
-waveform {10,15}

6. Set the test timing variables to the values required by your ASIC vendor. If
you are using TetraMAX to generate test patterns and your vendor does not
have specific requirements, the following settings produce the best results:
dc_shell-t> set test_default_delay 0
dc_shell-t> set test_default_bidir_delay 0
dc_shell-t> set test_default_strobe 40
dc_shell-t> set test_default_period 100

11
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

7. Select the scan style if you did not previously set the
test_default_scan_style variable in the .synopsys_dc.setup file. In
this example, the scan style is multiplexed flip-flop.
Enter the following command:
dc_shell-t> set test_default_scan_style \
multiplexed_flip_flop

You can also use the set_scan_configuration -style command.

8. Define clocks and asynchs in your design, then generate a test protocol.
create_test_protocol

9. Check test design rules in the RTL source file using RTL TestDRC.
dc_shell-t> dft_drc

10. Synthesize a design that meets the constraints you set, and map your circuit
description to cells from the target technology library.
dc_shell-t> compile -scan

This performs a test-ready compile. Design Compiler synthesizes and

optimizes your design relative to area and speed, and it removes redundant
logic. This last feature eliminates logically untestable circuitry and is an
important part of the Synopsys test methodology. Because of the -scan
option, all flip-flops in the design are implemented as scan flip-flops.

Post-Processing the Design

After your design is synthesized, follow these post-processing steps:

1. Check that you have satisfied the constraints you specified in Step 5 of the
previous procedure. Enter the command:
dc_shell-t> report_constraint -all_violators

2. This step is optional. You can save a copy of the design at this point. Enter
the command:
dc_shell-t> write -format db -out design_test_ready.db

12
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Note:
Do not save a copy as ASCII text (Verilog, VHDL, or EDIF formats) and
then attempt to start a new session. DFT Compiler marks the test-ready
logic with attributes. These attributes are lost if you save the design as
ASCII text.
3. Generate a new test protocol for the synthesized design.
4. Check the test design rules, according to the scan style you chose in Step 7
of the previous procedure.
dc_shell-t> dft_drc

At this stage, DFT Compiler checks for and describes potential problems
with the testability of your design. After you correct all the problems that
cause warning messages, you can proceed with the next step. Failure to
correct the problems that cause warning messages typically results in lower
fault coverage.

Building Scan Chains

To build scan chains, perform the following steps:

1. If you want DFT Compiler to buffer the scan-enable signal, use

set_scan_signal to identify the dedicated port and declare a drive
strength for the port. Enter the commands
dc_shell-t> set_scan_signal test_scan_enable \
-port scan_enable_port
dc_shell-t> set_drive 2 scan_enable_port

If you do not follow this procedure, DFT Compiler creates a scan-enable port
and assumes an infinite drive strength on the port, and no buffering is
inserted.
2. Because you ran a test-ready compile, you do not want DFT Compiler to
perform a scan replacement on the design. To prevent DFT Compiler from
issuing a warning when you build scan chains, enter the command
dc_shell-t> set_scan_configuration \
-replace false

When you build scan chains using the insert_dft command, you
implicitly instruct DFT Compiler to perform scan replacement. If you do not
enter the set_scan_configuration -replace false command, DFT

13
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Compiler recognizes that the design is already scan replaced and issues a
warning stating that DFT Compiler is overriding your implicit instruction to
perform scan replacement.
Note:
Do not use the set_scan_configuration -existing_scan true
command to prevent scan replacement. Use this command only when
scan chains exist in the design.
The set_scan_configuration command determines most of the
aspects of how DFT Compiler makes designs scannable. In this example,
all of the default settings are used except for the -replace false option.
3. Build the scan chains in your design. Enter the command:
dc_shell-t> insert_dft

When you add scan-test circuitry to a design, its area and performance
change. DFT Compiler minimizes the effect of adding scan-test circuitry on
compile design rules and performance by using synthesis routines. For
details of synthesis concepts such as compile design rules, see the Design
Compiler Reference Manual: Optimization and Timing Analysis. For details
about how DFT Compiler fixes compile design rule violations and
performance constraint violations, refer to the DFT Compiler Pre-Scan Test
Design Rule Checking User Guide.
4. Check that you have satisfied the constraints you specified in Step 5 of the
preceding section, “Synthesizing the Design”. Enter the command:
dc_shell-t> report_constraint \
-all_violators

5. Recheck the test design rules, according to the scan style you chose in
Step 7 of the preceding section, “Synthesizing the Design”.
dc_shell-t> dft_drc

At this stage, DFT Compiler checks for and describes potential problems
with the testability of your design. The checks run are more comprehensive
than those in Step 10 of the “Synthesizing the Design”” section and also
include checks for the correct operation of the scan chain. After you correct
all the problems that cause warning messages, you can proceed with the
next step. Failure to correct the problems that cause warning messages
typically results in lower fault coverage.

14
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

The dft_drc command is an essential preprocess step to guarantee that

the reports generated by the report_test command are correct. You
must run the dft_drc command if you want to generate reports with the
report_test command.
Refer to the DFT Compiler Pre-Scan Test Design Rule Checking User Guide
for more information on design rule checking.
6. You can now use the report_test command to generate test reports. For
example, to view details of the scan chain, use the command:
dc_shell-t> report_test -scan_path

Note:
Rerun the dft_drc command before running report_test only if
you have modified your circuit since you last ran dft_drc.
7. Write out the complete design in Synopsys database format. Enter the
command
dc_shell-t> write -format db -hierarchy -out design.db

DFT Flow for Mapped Designs

Using the command sequence provided in this section, you can take a mapped
design (without existing scan) to a fully optimized design with internal scan
circuitry. The sample command sequence applies to a full-scan or partial-scan
design. The basic process consists of the following:
• Reading the design
• Performing scan replacement and building scan chains
• Generating test patterns using TetraMAX
For information about how to pass the design on to TetraMAX ATPG to
generate test patterns, see DFT Compiler Exporting to Other Tools User
Guide. Also, see the TetraMAX User Guide for information about generating
test patterns using TetraMAX from a DFT Compiler flow.
Figure 4 shows a typical mapped design flow for DFT Compiler and HDL
Compiler. At the end of the design flow, TetraMAX ATPG produces a set of high
fault coverage test vectors that you can readily adapt to your target tester.

15
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Figure 4 Typical Flat Design Flow From a Mapped Design

Mapped netlist

Set constraints
HDL Compiler,
Design Compiler,
Set scan style
DFT Compiler

Not met Adjust constraints or

Check constraints try incremental compile

Met

Check design rules Correct problems

Set scan configuration

Build scan chains

Optimized netlist with scan

Not
Check constraints Adjust constraints or
met try incremental compile
Met

Check design rules Correct problems

Save testable design

Create and format

test patterns
TetraMAX ATPG

Compacted high fault coverage

test vectors

16
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Reading in the Design

Perform the following steps to read in the design:

1. Select the target technology library and link technology library.

dc_shell-t> set target_library = asic_vendor.db
dc_shell-t> set link_library = { * asic_vendor.db }

2. Use one of the following commands to read in an HDL circuit description:

dc_shell-t> read_file-format db design_name.db
dc_shell-t> read_file-format verilog design_name.v
dc_shell-t> read_file-format vhdl design_name.vhdl

If you want DFT Compiler to buffer the scan-enable signal, include a

dedicated scan-enable port in your design. At this stage, the scan-enable
port should not be connected.
3. Explicitly link the design:
dc_shell-t> link

If Design Compiler is unable to resolve any references, you must provide the
missing designs before proceeding. See your Design Compiler
documentation for details.
4. Select the target technology library and the design constraints. In this
example, the design is constrained to be no larger than 1,000 vendor units
in area, and it runs with a 20-ns clock period. Enter the following commands:
dc_shell-t> max_area 1000
dc_shell-t> create_clock clock_port -period 20 \
-waveform {10,15}
Note:
If the file you read is a .db file, the target technology library and the
design constraints might already be set.
5. Set the test timing variables to the values required by your ASIC vendor. If
you are using TetraMAX to generate test patterns and your vendor does not
have specific requirements, the following settings produce the best results:
dc_shell-t> set test_default_delay = 0
dc_shell-t> set test_default_bidir_delay = 0
dc_shell-t> set test_default_strobe = 40
dc_shell-t> set test_default_period = 100

17
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

6. Select the scan style if you did not previously set the
test_default_scan_style variable in the .synopsys_dc.setup file. In
this example, the scan style is multiplexed flip-flop.
Enter the command:
dc_shell-t> set test_default_scan_style = \
multiplexed_flip_flop

You can also use the set_scan_configuration -style command.

7. Check that you have satisfied the constraints you specified in Step 4. Enter
the command:
dc_shell-t> report_constraint -all_violators

8. Check the test design rules, according to the scan style you chose in Step 6.
dc_shell-t> dft_drc

At this stage, DFT Compiler checks for and describes potential problems
with the testability of your design. After you correct all the problems that
cause warning messages, you can proceed with the next step. Failure to
correct the problems that cause warning messages typically results in lower
fault coverage. Refer to the DFT Compiler Pre-ScanTest Design Rule
Checking User Guide for more information on design rule checking.
Because this design did not go through a test-ready flow, the dft_drc
command checks the library for equivalent scan cells to all the flip-flops in
your design.

Performing Scan Replacement and Building Scan Chains

To perform scan replacement and build scan chains, follow these steps:

1. If you want DFT Compiler to buffer the scan-enable signal, use

set_scan_signal to identify the port and declare a drive strength for the
port.
Enter the following commands:
dc_shell-t> set_scan_signal test_scan_enable \
-port scan_enable_port
dc_shell-t> set_drive 2 scan_enable_port

18
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

If you do not follow this procedure, DFT Compiler creates a scan-enable port
and assumes an infinite drive strength on the port, and no buffering is
inserted.
2. Specify the scan architecture. In this example, direct DFT Compiler to build
two scan chains. Use the following command:
dc_shell-t> set_scan_configuration -chain_count 2

The set_scan_configuration command determines most of the

aspects of how DFT Compiler makes designs scannable. For more
information about the set_scan_configuration command, refer to the
DFT Compiler DFT Architecture User Guide.
3. Build the scan chains in your design. Enter the command:
dc_shell-t> insert_dft

Because your design has no scan cells, DFT Compiler replaces the flip-flops
in your design with scannable equivalents before it builds scan chains.
When you add scan-test circuitry to a design, its area and performance
change. DFT Compiler minimizes the effect of adding scan-test circuitry on
compile design rules and performance by using synthesis routines. For
details of synthesis concepts such as compile design rules, see the Design
Compiler Reference Manual: Optimization and Timing Analysis. For details
about how DFT Compiler fixes compile design rule violations and
performance constraint violations, refer to the DFT Compiler Pre-Scan Test
Design Rule Checking User Guide.
4. Check that you have satisfied the constraints you specified in Step 4 of the
preceding section, “Reading in the Design”. Enter the command:
dc_shell-t> report_constraint -all_violators

5. Recheck the test design rules, according to the scan style you chose in
Step 4 of the preceding section, “Reading in the Design”.
dc_shell-t> dft_drc

At this stage, DFT Compiler checks for and describes potential problems
with the testability of your design. The checks run are more comprehensive
than those in Step 8 of the “Reading in the Design” section and also include
checks for the correct operation of the scan chain. After you correct all the

19
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

problems that cause warning messages, you can proceed with the next
step. Failure to correct the problems that cause warning messages typically
results in lower fault coverage.
The dft_drc command is an essential preprocess step to guarantee that
the reports generated by the report_test command are correct. You
must run the dft_drc command if you want to generate reports with the
report_test command.
Refer to the DFT Compiler Pre-ScanTest Design Rule Checking User Guide
for more information on design rule checking.
6. You can now use the report_test command to generate test reports. For
example, to view details of the scan chain, use the command:
dc_shell-t> report_test -scan_path

Note:
Rerun the dft_drc command before running report_test only if
you have modified your circuit since you last ran dft_drc .
7. Write out the complete design in Synopsys database format. Enter the
command:
dc_shell-t> write -format db -hierarchy -out design.db

DFT Flow for Mapped Designs With Existing Scan

Using the command sequence provided in this section, you can take a design
from an HDL-level circuit description (with existing scan) to a fully optimized
design with internal scan circuitry. The sample command sequence applies to a
full-scan or partial-scan design. The basic process consists of the following:
• Reading the design
• Checking test design rules
• Generating test patterns
For information about how to pass the design on to TetraMAX ATPG to
generate test patterns, see the DFT Compiler Exporting to Other Tools User
Guide. Also, see the TetraMAX User Guide for information about generating
test patterns using TetraMAX from a DFT Compiler flow.

20
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Figure 5 shows a typical flow for using DFT Compiler on a design with existing
scan chains. At the end of the design flow, TetraMAX ATPG produces a set of
high fault coverage test vectors that you can readily adapt to your target tester.
Figure 5 Typical Flat Design Flow With Existing Scan Chains

Existing netlist

HDL Compiler, Set constraints

Design Compiler,
Set scan style
DFT Compiler

Not met Adjust constraints or

Check constraints try incremental compile
Met

Set scan configuration

Identify test ports

Check design rules Correct problems

Optimized netlist with scan

Save testable design

Create and format

test patterns
TetraMAX ATPG
Compacted high fault coverage
test vectors

21
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Reading in the Design

To read in the design, perform the following steps:

1. Select the target technology library and link technology library.

dc_shell-t> set target_library = asic_vendor.db
dc_shell-t> set link_library = { * asic_vendor.db }

2. Use one of the following commands to read in an HDL circuit description:

dc_shell-t> read_file -format db design_name.db
dc_shell-t> read_file -format verilog design_name.v
dc_shell-t> read_file -format vhdl design_name.vhdl

3. Explicitly link the design:

dc_shell-t> link

If Design Compiler is unable to resolve any references, you must provide the
missing designs before proceeding. See your Design Compiler
documentation for details.
4. Select the target technology library and the design constraints. In this
example, the design is constrained to be no larger than 1,000 vendor units
in area, and it runs with a 20-ns clock period. Enter the following commands:
dc_shell-t> max_area 1000
dc_shell-t> create_clock clock_port -period 20 \
-waveform {10,15}
Note:
If the file you read is a .db file, the target technology library and the
design constraints might already be set.
5. Set the test timing variables to the values required by your ASIC vendor. If
you are using TetraMAX to generate test patterns and your vendor does not
have specific requirements, the following settings produce the best results:
dc_shell-t> set test_default_delay = 0
dc_shell-t> set test_default_bidir_delay = 0
dc_shell-t> set test_default_strobe = 40
dc_shell-t> set test_default_period = 100

22
 Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

6. Select the scan style if you did not previously set the
test_default_scan_style variable in the .synopsys_dc.setup file. In
this example, the scan style is multiplexed flip-flop.
Enter the following command:
dc_shell-t> set test_default_scan_style = \
multiplexed_flip_flop

You can also use the set_scan_configuration -style command.

Refer to the DFT Compiler DFT Architecture User Guide for details.
7. Check that you have satisfied the constraints you specified in Step 4. Enter
the command:
dc_shell-t> report_constraint -all_violators

Checking Test Design Rules

To check test design rules, perform the following steps:

1. Because your design already has scan chains, you need to specify this to
DFT Compiler.
Enter the command:
dc_shell-t> set_scan_configuration -existing_scan true

Note:
If you read in the design from a .db file, this attribute might already be
set. You can check this with the report_test -configuration
command.
2. Identify the test ports to DFT Compiler. This example has a single scan
chain. Enter the commands:
dc_shell-t> set_signal_type test_scan_in \
test_scan_in_port
dc_shell-t> set_signal_type test_scan_out \
test_scan_out_port
dc_shell-t> set_signal_type test_scan_enable \
test_scan_enable_port

23
Design-for-Test Flows in the Logical Domain
Overview of Design-for-Test Flows

Note:
If you read in the design from a .db file, this attribute might already be
set. You can check this with the report_test -port command.
3. Check the test design rules, according to the scan style you chose in Step 6
of the preceding section, “Reading in the Design”, and using the test
attributes set in Step 1 and Step 2 of this section.
dc_shell-t> dft_drc

At this stage, DFT Compiler checks for and describes potential problems
with the testability of your design. The checks run include checks for the
correct operation of the scan chain. After you correct all the problems that
cause warning messages, you can proceed with the next step. Failure to
correct the problems that cause warning messages typically results in lower
fault coverage.
Running the dft_drc command is an essential preprocess to guarantee
that the reports generated by the report_test command are correct. You
must run the dft_drc command if you want to generate reports with the
report_test command.
Refer to the DFT Compiler Pre-ScanTest Design Rule Checking User Guide
for more information on design rule checking.
4. You can now use the report_test command to generate test reports. For
example, to view details of the scan chain, use the following command:
dc_shell-t> report_test -scan_path

Note:
Rerun the dft_drc command before running report_test only if
you have modified your circuit since you last ran dft_drc.
5. Write out the complete design in Synopsys database format. Enter the
following command:
dc_shell-t> write -format db -hierarchy -out design.db

24
 Design-for-Test Flows in the Logical Domain
Designing Block by Block

Designing Block by Block

Many designers prefer to develop their designs on a block-by-block basis. Most
of the process described in the preceding sections can be applied to a
particular block of your design, as well as to the complete design. For example,
you can check the design rules (refer to the DFT Compiler Pre-Scan Test
Design Rule Checking User Guide for more information) and generate an initial
fault coverage report on each block of your design as it is developed. The
report helps you identify the blocks that have unacceptable fault coverage, so
you can fix testability problems at an early stage.
Although fixing testability problems on a block-by-block basis is an important
divide-and-conquer technique, testability problems are global in nature. A
completely testable subblock might show testability problems when it is
embedded in its environment.

Invoking Constraint-Optimized Scan Insertion

The process of performing scan replacement and scan assembly in a single
step is called scan insertion. You use the insert_dft command to invoke
constraint-optimized scan insertion. You can also perform scan replacement
and scan assembly in separate steps. The following sections discuss the
single-step option, the scan-replacement-only option, and how to specify scan
cells.

Scan Replacement and Assembly in a Single Step

By default, the insert_dft command performs scan replacement and scan
assembly in a single step.
To prepare for scan insertion, perform the following steps:

1. Specify the desired scan architecture.

2. Preview the resulting scan architecture.
Figure 6 shows the role of the specification and preview steps in generating
scan chains.

25
Design-for-Test Flows in the Logical Domain
Invoking Constraint-Optimized Scan Insertion

Figure 6 Specify-Preview-Synthesize Flow

Nonscan Design

Specify Preview Assemble

User-Generated DFTC-Generated Scan Architecture

dc_shell Script dc_shell Script Preview Report Scan Design

See the DFT Compiler DFT Architecture User Guide for information about the
specification, preview and synthesis steps.
The following command sequence performs constraint-optimized scan
insertion (both scan replacement and scan assembly) on the optimized gate-
level design shown in Figure 7:
dc_shell-t> set_scan_configuration \
-style multiplexed_flip_flop
dc_shell-t> insert_dft

Figure 7 Gate-Level Design: Default Compile

d1
q1

FD1

d3 q2
clk
FD1S
d2
sel

26
 Design-for-Test Flows in the Logical Domain
Invoking Constraint-Optimized Scan Insertion

Figure 8 shows the result of the constraint-optimized scan insertion process

(when performing both scan replacement and scan assembly) on the design
example. DFT Compiler uses the multiplexed flip-flop scan cell (FD1S) to
implement the scan equivalent cells.
Figure 8 Gate-Level Design: Constraint-Optimized Scan
Insertion (Replacement and Assembly)

d3
d2 q2
sel
FD1S
d1

FD1S
test_si q1

clk
test_se

Scan Replacement Only

To perform scan replacement only, execute the set_scan_configuration
-route command before invoking constraint-optimized scan insertion.
dc_shell-t> set_scan_configuration -route false
dc_shell-t> insert_dft

The following command sequence performs constraint-optimized scan

insertion (scan replacement only) on the optimized gate-level design shown in
Figure 7 on page 26:
dc_shell-t> set_scan_configuration \
-style multiplexed_flip_flop \
-route false
dc_shell-t> insert_dft

Figure 9 shows the result of the constraint-optimized scan insertion process

(when you perform scan replacement only) on the design example. DFT
Compiler uses the multiplexed flip-flop scan cell (FD1S) to implement the scan
equivalent cells. DFT Compiler does not create temporary scan connections
during constraint-optimized scan insertion.

27
Design-for-Test Flows in the Logical Domain
Invoking Constraint-Optimized Scan Insertion

Figure 9 Gate-Level Design: Constraint-Optimized Scan

Insertion (Replacement Only)

d3

d2

q2
sel

d1

q1

clk

Specifying Scan Cells

The set_scan_register_type command lets you specify which flip-flop
scan cells are to be used for replacing nonscan cells. The command restricts
the choices of scan cells available for scan replacement when you use the
compile -scan command or insert_dft command. You can apply this
restriction to the current design, to particular designs, or to particular cell
instances in the design.
For information on using the set_scan_register_type command, see the
DFT Compiler DFT Architecture User Guide.

28
 3
Design-for-Test Flows in the Physical Domain3

This chapter describes design-for-test flows in the physical

domain. Included are an overview of the three common flows,
as well as discussions of scan cell ordering techniques and
hierarchical scan synthesis in the physical domain.

Introduction to Physical Scan Synthesis

Physical scan synthesis integrates scan and physical synthesis so that multiple
iterations between synthesis and place-and-route tools are unnecessary.
Because scan synthesis is tightly integrated into the physical environment, DFT
Compiler can perform physical scan synthesis so that:
• Wire length is minimized, to reduce congestion.
• DFT constraints (such as clock domains and scan chain length) are taken
into account.
• New cells introduced during DFT insertion, such as lock-up latches, are
understood by Physical Compiler.
• Timing violations are addressed and corrected during scan cell ordering.
Physical switches are included in DFT Compiler commands in which physical
information must be considered. Scan switches are included in Physical

29
Design-for-Test Flows in the Physical Domain
Overview of Placement-Based Design-for-Test Flows

Compiler commands in which scan information must be considered. Table 1

shows the commands with physical or scan switches.
Table 1 DFT Compiler Physical Commands and Physical
Compiler Scan Commands
DFT Compiler Physical Commands Physical Compiler Scan Commands

insert_dft -physical compile_physical -scan

preview_dft -physical

Since placement is driven by DFT Compiler, the result is a design with

increased signal speed and reduced total chip area. Power consumption is also
reduced by reducing capacitance on nets that are shared by both data and
scan.

Overview of Placement-Based Design-for-Test Flows

You can perform design-for-test in the physical domain using the same
preparatory steps, and similar scan-insertion steps, as the ones you use in the
logical domain.
Physical scan synthesis occurs when you use DFT Compiler in the Physical
Compiler environment. Physical scan synthesis supports the automatic
placement of all logic added by the one-pass test synthesis features such as
scan synthesis and AutoFix. You can perform selective optimization to fix timing
violations after scan stitching is performed to optimize scan net hold times.
In its most general form, independent of design state, the flow for one-pass
physical DFT synthesis is described in Figure 10.

30
 Design-for-Test Flows in the Physical Domain
Overview of Placement-Based Design-for-Test Flows

Figure 10 General Flow for One-Pass Physical DFT Synthesis

RTL check

Physical synthesis

Scan chain synthesis

and
automatic fixing of
DFT rule violations

Check DFT,
Check QOR

This section describes three different flows:

• RTL-to-Placed-Gates Flow
• Gates-to-Placed-Gates Flow
• Placement-Based Reordering of Existing Scan Chains
The specific flow you use depends on the state of the design before you start
using DFT Compiler.

31
Design-for-Test Flows in the Physical Domain
Overview of Placement-Based Design-for-Test Flows

RTL-to-Placed-Gates Flow
In the RTL-to-Placed-Gates Flow, commonly referred to as the RTL2PG flow,
you start with an RTL design, set your design constraints, and compile your
design in the physical domain, rather than in the logical domain. This flow is
depicted in Figure 11.
Figure 11 RTL to Placed Gates Flow

Command Summary

create_test_protocol
RTL check dft_drc

set_dft_configuration
set_scan_configuration
DFT specification
set_dft_signal

Physical scan synthesis read_pdef locations.pdef

compile_physical -scan

create_test_protocol
DFT check dft_drc

Preview physical scan preview_dft -physical

Insert physical scan insert_dft -physical

Check DFT, dft_drc

Check QOR report_timing

32
 Design-for-Test Flows in the Physical Domain
Overview of Placement-Based Design-for-Test Flows

Gates-to-Placed-Gates Flow
In the Gates-to-Placed-Gates Flow, commonly referred to as the G2PG flow,
you set your design constraints and compile your design in the logical domain,
rather than in the physical domain. Then you perform physical optimization and
insert placement-based scan chains. This flow is shown in Figure 12.
Figure 12 Gates-to-Placed-Gates Flow
Command Summary

Gate-level netlist read_verilog design.v

set_dft_configuration
DFT specification set_scan_configuration
set_dft_signal

Placement/Optimization
read_pdef locations.pdef
physopt
create_test_protocol
DFT check dft_drc

Preview physical scan preview_dft -physical

Insert physical scan insert_dft -physical

Check DFT, dft_drc

Check QOR report_timing

33
Design-for-Test Flows in the Physical Domain
Overview of Placement-Based Design-for-Test Flows

Placement-Based Reordering of Existing Scan Chains

If you have a design in which scan chains were inserted and routed in the
logical domain, you can use placement-based reordering. In this flow, you start
with a scan-stitched netlist, perform physical optimization on it, and then
identify the components of the scan chain. Then you reorder the scan chains
based on placement information. A description of this flow is shown in
Figure 13.
Figure 13 Physical Scan Reordering Flow
Command Summary
read_verilog top.v
Scan-stitched netlist
read_pdef locations.pdef
physopt
Placement/Optimization set_scan_configuration \
-existing_scan true
Scan chain identification set_signal_type test_scan_in ...
set_signal_type test_scan_out ...
set_signal_type test_scan_enable ...
DFT check set_scan_element false ...
report_test -state
create_test_protocol
dft_drc -infer_scan_structures
Preview scan preview_dft -physical

Reorder scan chains

based on insert_dft -physical
placement information

dft_drc
Check DFT,
Check QOR report_timing

34
 Design-for-Test Flows in the Physical Domain
Scan Chain Ordering and Partitioning Techniques

Scan Chain Ordering and Partitioning Techniques

This section discusses various techniques for ordering and partitioning scan
chains, including:
• Scan cell ordering to reduce congestion
• Timing-based scan cell ordering
• Placement-based scan chain partitioning

Scan Cell Ordering to Reduce Congestion

In logical scan synthesis, scan cells are ordered and partitioned alphabetically.
This can cause significant congestion and increases in net delays. Net delays
currently consume 70 percent of a design’s delay path. Figure 14 shows a
wiring diagram for a design in which the scan cells are ordered and routed
without physical information.
Figure 14 Wiring Diagram for Cells Ordered and Routed
Without Physical Information

Figure 15 shows a wiring diagram in which the scan cells are ordered and
routed with physical information.

35
Design-for-Test Flows in the Physical Domain
Scan Chain Ordering and Partitioning Techniques

Figure 15 Wiring Diagram for Cells Ordered and Routed With

Physical Information

Timing-Based Scan Cell Ordering

Physical Compiler performs placement-based scan cell ordering to minimize
wire length between adjacent scan cells. However, the placement-based scan
cell order may result in hold time violations if the wire length between cells is
too short. Timing-based scan cell ordering minimizes hold time violations by
increasing the distance between adjacent scan cells of a given scan chain.

Placement-Based vs. Timing-Based Scan Cell Ordering

Figure 16 shows how a simple scan chain might be connected after placement-
based scan cell ordering.

36
 Design-for-Test Flows in the Physical Domain
Scan Chain Ordering and Partitioning Techniques

Figure 16 After Placement-Based Scan Cell Ordering

SI Q SO

SI SI Q SI Q U4
U1 U2

SI Q
U3

In Figure 16, a hold time violation is discovered between U1 and U2. To direct
Physical Compiler to fix the hold time violation, add the following statement to
your scan chain specification:
set_scan_configuration -minimize_hold_time true

Once you run insert_dft -physical, the scan chain is reordered as

shown in Figure 17.

37
Design-for-Test Flows in the Physical Domain
Scan Chain Ordering and Partitioning Techniques

Figure 17 After Timing-Based Scan Cell Ordering

SI Q SO

SI SI Q SI Q U4
U1 U2

SI Q
U3

Note that timing-based scan cell ordering could increase the total scan wire
length compared to placement-based scan cell ordering. To limit the amount
the wire length increases as a result of scan cell reordering, add the following
statement to your scan architecture specification:
set_scan_configuration -max_additional_wirelength int
where int is an integer expressed as a percentage of the placement-based
wire length.
An analysis is done to ensure that no new hold time violations are introduced
as a result of the new scan cell ordering.

Typical Flow for Timing-Based Scan Cell Ordering

Example 1 shows a typical flow where Physical Compiler performs timing-
based scan cell ordering.

38
 Design-for-Test Flows in the Physical Domain
Scan Chain Ordering and Partitioning Techniques

Example 1 Typical Flow With Timing-Based Scan Cell Ordering

set test_enable_dft_drc true
read_db design.db
current_design TOP
set_scan_configuration -minimize_hold_time true
create_test_protocol
dft_drc
preview_dft -physical
insert_dft -physical
dft_drc
run_router
report_timing -delay min

The run_router command provides an update on timing information. The

report_timing -delay min command reports hold time violations that
were not fixed after timing-based scan cell ordering. You can use this report to
see how many hold time violations were fixed as a result of timing-based scan
cell ordering. You can also specify the -max_additional_wirelength
percentage and analyze the trade-off between increase in wire length and
number of hold time violations.

Placement-Based Scan Chain Partitioning

In the logical domain, scan cells are assigned to scan chains based on
alphabetical ordering. This usually results in congestion and large net delays.
With physical scan synthesis, you can perform automatic placement-based
scan chain partitioning. In the one-pass physical scan synthesis flow, the
following tasks are performed:
• Scan cells in the same area of the design are allocated to the same scan
chains.
• Scan cells with compatible clocks are added to the same scan chains,
according to the DFT constraints you set.
• Scan chains are balanced to reduce the sequential length of the longest
scan chain.
By default, physical scan synthesis partitions scan chains in the Y direction. In
this situation, the Y axis is sliced into thin layers and partitioning is performed
on those layers.
The resulting design contains placement-based partitioned scan-chains such
as the one shown in Figure 18.

39
Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

Figure 18 Placement-Based Scan Chain Partitioned Design

However, in some designs, partitioning scan chains in the Y direction may

cause significant congestion. In these cases, you can change the default scan
chain partitioning to the X direction by using the following variable:
set_test_scan_partition_x true

Physical scan synthesis slices the X axis into thin layers and performs
partitioning on each layer.
This alternate form of partitioning can be beneficial if routing resources are
scarce in a particular direction.

Hierarchical Scan Synthesis in the Physical Domain

Hierarchical scan synthesis uses interface logic models (ILMs), where the
original gate-level netlist for a block is modeled by another gate-level netlist that
contains the interface logic of a block. ILMs are highly accurate representations
of the original design because they preserve interface logic without any
modification. ILMs create models that capture only the interface and scan chain
information, discarding the rest of a block’s content. By using ILMs, your design
will take less memory and runtime is reduced.

40
 Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

Introduction to Interface Logic Models

The benefits of using ILMs include the following:
• They provide an accurate and robust model-generation solution.
• They provide a structural approach to model generation.
• They minimize routing congestion.
• They can be written out in .db format.
• They can be generated with physical information.
• They can be used for static-timing verification.
• Placement and back-annotation data can be propagated up to the top level.
Figure 19 shows an example of the extraction of interface logic performed when
creating ILMs.
Figure 19 Representation of a Block and Its Interface Logic Model

Figure 19 shows that the logic between the input port and the first shift register
is preserved, as is the logic between the last shift register and the output port.
Clock connections to the preserved shift registers are kept as well. If no shift
registers are present on a net, the entire net is preserved. When you create

41
Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

ILMs for hierarchical scan synthesis, the information about the scan chains in
the blocks is also preserved.
The interface logic contains all the circuitry from:
• Input ports to output ports.
• Transparent latches. They are treated as combinational logic.
• Input ports to edge-triggered registers.
• Edge-triggered registers to output ports.
• Clock trees that drive interface registers.
• Clock-gating circuitry that is driven by external ports.

Creating ILMs for Hierarchical Scan Synthesis

The process of creating ILMs for a synthesized hierarchical scan design is,
essentially, a bottom-up flow. Every block within a hierarchy must have an ILM
created for it. ILMs for nested blocks must be linked to the ILMs for their higher-
level parent blocks. At the top level, stitch all blocks together to form a top-level
design that includes the entire design hierarchy.
Note:
To ensure that you extract scan chains as well as interface logic from a
block, set the test_use_test_models variable to true. This step is
important, because the default value is false.
Use the following commands in your synthesis flow to create ILMs:
• create_ilm -output filename
This command transforms the current design into an ILM. After you execute
the command, the design in memory is the ILM, rather than the full gate-
level netlist. You can then use the write command to write out the ILM in
.db format.
• propagate_ilm -placement
This command propagates the placement information of a module upward
through the design hierarchy.
• propagate_ilm -delay
This command propagates the annotated delay information of a module
upward through the design hierarchy.

42
 Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

Extracting Interface Logic Models

You can extract an ILM for a block that has been created with the compile
-scan command or with the compile_physical -scan command. In the
first case, the flow you use is called the gates-to-placed-gates flow (G2PG),
and in the second, the flow you use is called the RTL-to-placed-gates flow
(RTL2PG). Both flows are discussed in the sections that follow.
The flows for block-level and chip-level designs are discussed in the sections
that follow.

Block-Level Gates-to-Placed Gates (G2PG) Flow

When you create a block-level ILM in the G2PG flow, you perform the following
steps:
• Set the test_use_test_models variable to true so that ILMs extracted
will also contain scan chain information.
• Compile the design in the logical domain using the compile -scan
command.
• Perform a physical optimization on the design.
• Perform test design-rule checking.
• Perform scan chain insertion in the physical domain.
• Perform test design-rule checking again.
• Identify the interface logic and the scan chains in the block.
• Extract the ILM.
To perform these tasks, use the commands in the order specified in Example 2:
Example 2 Block-Level G2PG Flow

set test_use_test_models true

compile -scan
physopt
create_test_protocol
dft_drc
insert_dft -physical
dft_drc
create_ilm
write -format db -output filename

43
Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

Block-Level RTL-to-Placed-Gates (RTL2PG) Flow

When you create a block-level ILM in the RTL2PG flow, you perform the
following steps:
• Set the test_use_test_models variable to true so that ILMs extracted
will also extract scan chains.
• Compile the design in the physical domain using the compile_physical
-scan command.
• Perform test design-rule checking.
• Perform scan chain insertion in the physical domain.
• Perform test design-rule checking again.
• Identify the interface logic and the scan chains in the block.
• Extract the ILM.
To perform these tasks, use the following commands in the order specified in
Example 3:
Example 3 Block-Level RTL2PG Flow

set test_use_test_models true

compile_physical -scan
create_test_protocol
dft_drc
insert_dft -physical
dft_drc
create_ilm
write -format db -output filename

Chip-Level Gates-to-Placed Gates (G2PG) Flow

When you create a chip-level ILM in the G2PG flow, you perform the following
steps:
• Set the test_use_test_models variable to true so that ILMs extracted
will also extract scan chains.
• Read in the design’s top-level .db file.
• Read in the block-level ILM files.
• Compile the design in the logical domain using the compile -scan
command.

44
 Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

• Perform physical optimization on the design.

• Use the propagate_ilm -placement command to propagate all the
placement information for the subdesigns up to the top level.
• Use the propagate_ilm -delay command to propagate the delay
information for the subdesigns up to the top level.
• Perform test design-rule checking.
• Perform scan chain insertion in the physical domain.
• Perform test design-rule checking again.
• Identify the interface logic and the scan chains in the block.
• Extract the ILM.
To perform these tasks, use the following commands in the order specified in
Example 4:
Example 4 Chip-Level G2PG Flow

set test_use_test_models true

read_db top.db
read_db a_sub_design.ilm.db b_sub_design.ilm.db
compile -scan
physopt
propagate_ilm -placement
propagate_ilm -delay
create_test_protocol
dft_drc
insert_dft -physical
dft_drc

Note:
The use of the propagate_ilm commands is required for the Physical
Compiler flow and is not unique to the physical scan flow.

Chip-Level RTL-to-Placed-Gates (RTL2PG) Flow

When you create a chip-level ILM in the RTL2PG flow:
• Set the test_use_test_models variable to true so that ILMs extracted
will also extract scan chains
• Read in the design’s top-level .db file.
• Read in the block-level ILM files.

45
Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

• Compile the design in the physical domain using the compile_physical

-scan command.
• Perform test design-rule checking.
• Perform scan chain insertion in the physical domain.
• Perform test design-rule checking again.
To perform these tasks, use the following commands in the order specified in
Example 5.
Example 5 Chip-Level RTL2PG Flow

set test_use_test_models true

read_db top.db
read_db a_sub_design.ilm.db b_sub_design.ilm.db
propagate_ilm -placement
propagate_ilm -delay
compile_physical -scan
create_test_protocol
dft_drc
insert_dft -physical
dft_drc

Note:
The use of the propagate_ilm commands is required for the Physical
Compiler flow and is not unique to the physical scan flow.

Interface Logic Model Command and Variable Summary

All the commands discussed in this section are available within the Physical
Compiler environment and are used to generate ILMs. To use these commands
in the DFT Compiler environment, set the test_use_test_models variable
to true.
The following commands are discussed in this section:
• create_ilm
• propagate_ilm -delay
• propagate_ilm -placement
The test_use_test_models variable is also discussed in this section. The
test_use_test_models variable instructs the ILM-generation functionality
to create ILMs with scan chain information, thereby creating ILM test models.

46
 Design-for-Test Flows in the Physical Domain
Hierarchical Scan Synthesis in the Physical Domain

The create_ilm Command

The create_ilm command sets the is_interface_logic attribute on
cells, nets, and pins of the current design, identifying them as interface logic
objects. This is the first step in the generation of an interface logic model (ILM).
Interface logic includes:
• All cells that lead from input ports to registers or output ports that terminate
the paths.
• All cells that lead to output ports from registers or input ports that originate
the paths.
• The module’s scan chain information (when the test_use_test_models
variable is set to true).
Interface logic does not include internal register-to-register paths or logic on a
block associated only with these paths.
The create_ilm command implicitly performs update_timing on the
design if required.
After this command is run successfully, the next step is to write out an interface
logic model using the write command.

The propagate_ilm -delay Command

The propagate_ilm -delay command propagates annotated delay
information for the specified list of hierarchical cells from their respective
reference designs to the current design.
This command is required when performing any kind of ILM extraction in the
Physical Compiler environment. It is not unique to hierarchical scan synthesis.

The propagate_ilm -placement Command

The propagate_ilm -placement command propagates placement
information for all leaf cells in the specified list of hierarchical cells from their
respective reference designs to the current design.
This command is required when performing any kind of ILM extraction in the
Physical Compiler environment. It is not unique to hierarchical scan synthesis.

The test_use_test_models Variable

When this variable is set to true, DFT Compiler automatically creates test
models when performing scan insertion. The default value is false.

47
Design-for-Test Flows in the Physical Domain
Troubleshooting

Setting the test_use_test_models variable to true causes DFT Compiler

to create test models when performing scan insertion. When the variable is set
to false (the default), DFT Compiler does not create test models when
performing scan insertion.
When you work with large designs, using the hierarchical scan synthesis DFT
flow helps to reduce memory usage and speed up runtime. Test models used
by the hierarchical scan synthesis flow describe only the portions of
subdesigns that are important for inserting DFT.

Troubleshooting
The following sections discuss what you can do to solve possible problems you
might encounter using DFT Compiler in the Physical Compiler environment.
Some common problems include:
• Unknown design state
• Missing port and cell locations
• Existing scan settings incorrect
• Timing problems
• Leaving scan enables unrouted

Unknown Design State

If your placement information changes after you perform insert_dft
-physical, the problem might be an unknown design state.
The following error message is generated if your design is in an unknown state
when you perform insert_dft.
TEST-1224 (Error) The scan state is invalid for -physical option
in insert_dft, preview_scan, insert_dft and preview_dft

To avoid this problem, check the design state before performing

insert_dft -physical. To check the design’s state, use the command
report_test -state. If the state reported back is unknown, set the state
properly by using the set_scan_state command.
If you set the state of the design to scan_existing, you must identify the
nonscan flip-flops in the design by using the set_scan_element false
command.

48
 Design-for-Test Flows in the Physical Domain
Troubleshooting

Missing Port and Cell Locations

When you perform scan ordering from within Physical Compiler through the
insert_dft -physical command, scan ports and scan cells should
already exist in the floorplan.
You can determine if ports have been defined by using the report_port
-physical command. If no ports are listed in the port report, you can specify
the ports needed by using the set_scan_signal command.
If cells are placed improperly you might see an error message that states that
scan cells do not have a location. To address this problem, use the
report_cell -physical command to determine whether cells have been
placed properly. If you discover cells have not been placed properly, you can fix
the problem by using the physopt -incremental -eco command.
TEST-1016 (error) XY locations are missing for %s scan cell or
scan port.

Existing Scan Setting Incorrect

When you run compile -scan on a design, DFT Compiler treats the design
as having no existing scan. If your design has existing scan, enter the following
command to set the -existing_scan option to true:
set_scan_configuration -existing_scan true

Timing Problems
The insert_dft -physical command performs local optimizations only on
the portions of the design that have changed. You can use the
report_timing command to determine if your timing needs have been met.
If timing needs are not met, you can perform a global optimization by using the
physopt -incremental command.

49
Design-for-Test Flows in the Physical Domain
Troubleshooting

Leaving Scan Enables Unrouted

In the logical domain, you can use the set_dont_touch variable on a scan
enable signal to prevent routing of the scan enable. However, using the
dont_touch attribute on a scan enable in the physical domain causes
Physical Compiler to create a new scan-enable signal. If you do not want a
scan enable signal to be routed, or if you do not want to create a new scan
enable pin, use the set_scan_configuration
-route_signals serial command.

If Your Design Still Has Problems

If your design still has problems after trying these trouble-shooting tips, try
inserting scan in the logical domain. If the problems disappear, they are not
caused by a scan issue, but rather a Physical Compiler issue.
The Physical Compiler problem might be related to one or more of the following
issues:
• Floor plan
• Port location
• Legalized cell locations
• Physical library

50
 4
Default Scan Synthesis4

If you do not specify scan detail, the insert_dft command

implements a default scan design using the full-scan
methodology. This section describes the ground rules that the
preview_dft and insert_dft commands apply to
generate a default scan design.

Scan Replacement
DFT Compiler performs the following scan replacement tasks:
• Unscans scan-replaced elements from compile -scan or a previous scan
insertion if test design rule violations prevent their inclusion in a scan chain.
• Scan-replaces sequential elements if you did not previously perform a scan
replacement on sequential elements.

Scan Element Allocation

DFT Compiler allocates scan elements to scan chains in the following manner:
• Allocates scan elements to produce the minimum number of scan chains
consistent with clock domain requirements. By default, the insert_dft
command generates a scan design with the number of scan chains equal to

51
Default Scan Synthesis
Test Signals

the number of clock domains. The resulting design contains one scan chain
for each set of sequential elements clocked by the same edge of the same
test clock.
• Automatically infers existing scan chains both in the current design and in
subdesigns. This is only true if the design has the proper attributes.
• Does not reroute existing scan chains built by the insert_dft command
or subdesign scan chains built by the insert_dft command, even if the
existing routing does not conform to default behavior.
• Orders scan elements in scan chains alphanumerically. By default, the
insert_dft command alphanumerically orders scan elements within
scan chains across the full hierarchical path specification of the scan
element name.

Test Signals
DFT Compiler inserts and routes test signals in the following manner:
• Automatically inserts and routes global test signals to support the specified
scan style. These test signals include clocks and enable signals.
• Allocates ports to carry test signals. Where possible, the insert_dft
command uses mission (normal function) ports to carry scan-out ports and
inserts multiplexing logic, if required. The insert_dft command performs
limited checking for existing multiplexing logic to prevent redundant
insertion.
• Inserts three-state and bidirectional disabling logic during default scan
synthesis. The insert_dft command checks for existing disabling logic to
prevent redundant insertion.

Pad Cells
If the current design includes pad cells, the insert_dft command identifies
the pad cells and correctly inserts test structures next to them by:
• Ensuring correct core-side hookup to all pad cells and three-state drivers
• Inserting required logic to force bidirectional pads carrying scan-out signals
into output mode during scan shift
• Inserting required logic to force bidirectional pads carrying scan-in, control,
and clock signals into input mode during scan shift

52
 Default Scan Synthesis
Area and Timing Optimization

• Determining requirements and, if necessary, inserting required logic to force

all other nondegenerated bidirectional ports into input mode during scan
shift
• Inserting required logic to enable three-state output pads associated with
scan-out ports during scan shift
• Inserting required logic to disable three-state outputs that are not associated
with scan-out ports during scan shift

Area and Timing Optimization

By default, the insert_dft command uses constraint-optimized scan
insertion to reduce the scan-related impact on performance and area. This
process minimizes constraint violations and eliminates compile design-rule
errors. For consistency with Design Compiler, insert_dft uses the clock
waveforms described by the create_clock command to determine whether a
logic path meets performance constraints. The insert_dft command does
not use the timing values described using create_test_clock for constraint
optimization. The insert_dft command also selects scan-out signal
connections (Q or QN) to minimize constraint violations.
Scan chain synthesis is primarily concerned with the scan shift operation. The
dft_drc command identifies problems associated with scan capture that
might require you to resolve problems caused by functional clock waveforms.
Scan chains synthesized by the insert_dft command are functional under
zero-delay assumptions. Before you perform scan synthesis, you can specify
test clocks using the create_test_clock command. All test clocks have the
same period.

53
Default Scan Synthesis
Area and Timing Optimization

54
 5
Using Constraint-Optimized Scan Insertion5

During the scan replacement process, constraint-optimized

scan insertion inserts the scan cells, optimizes the scan logic
based on your design constraints, and fixes all compile design
rule violations.

Constraint-Optimized Scan Insertion

Constraint-optimized scan insertion supports mixed scan states during scan
insertion. Modules can have the following scan states:
• Nonscan
The design contains nonscan sequential cells. Constraint-optimized scan
insertion must scan-replace and route these cells.
• Unrouted scan
The design contains unrouted scan cells. These unrouted scan cells can
result from test-ready compile or from the scan replacement phase of
constraint-optimized scan insertion. Constraint-optimized scan insertion
must include these cells in the final scan architecture.
• Scan
The design contains routed scan chains. Constraint-optimized scan
insertion must include these chains in the final scan architecture.

55
Using Constraint-Optimized Scan Insertion
Constraint-Optimized Scan Insertion

Because the focus of this chapter is the scan replacement process, this
discussion assumes:
• The input to constraint-optimized scan insertion is an optimized nonscan
gate-level design
• The output from constraint-optimized scan insertion is an optimized design
that contains unrouted scan cells (constraint-optimized scan insertion
performs scan replacement only)
Note:
When you do not route the scan chains, the optimization performed during
constraint-optimized scan insertion accounts for the timing impact of the
scan cell, but not of the additional loading due to the scan chain routing.

Locating Scan Equivalents

To perform scan replacement, constraint-optimized scan insertion first locates
simple scan equivalents using the identical-function method. If the
insert_test_map_effort_enabled variable is true and if constraint-
optimized scan insertion does not find a scan replacement using this method, it
uses sequential-mapping-based scan replacement. See the scan insertion
information in the Design Compiler Reference Manual: Optimization and
Timing Analysis for details about scan replacement methods.
Like test-ready compile, constraint-optimized scan insertion supports
degeneration of scan cells to create the required scan equivalent functionality.
Replacing sequential cells with their scan equivalents modifies the design
timing as shown in Figure 20. DFT Compiler performs scan-specific
optimizations to reduce the timing impact of scan replacement. By using
focused techniques, constraint-optimized scan insertion optimizes the scan
logic faster than the incremental compile process could.

56
 Using Constraint-Optimized Scan Insertion
Constraint-Optimized Scan Insertion

Figure 20 Timing Changes Due to Scan Replacement

Change in Change in
input load drive resistance

d q d
scan_in q
scan_enable
clk
Increase in Change in intrinsics
setup and
hold times clk

Figure 21 shows the flow used to insert scan cells using constraint-optimized
scan insertion and the commands required to complete this flow.
Figure 21 Constraint-Optimized Scan Insertion Flow (Scan Replacement
Only)

Select scan style

(test_default_scan_style = style)

Read design description

(read_file)

Define test protocol

(set_test_hold)

Analyze nonscan design

(dft_drc)

Insert scan cells

(insert_dft)

57
Using Constraint-Optimized Scan Insertion
Scan Insertion

Preparing for Constraint-Optimized Scan Insertion

Before performing constraint-optimized scan insertion:
• Verify the timing characteristics of the design.
Constraint-optimized scan insertion results in a violation-free design when
the design has the following timing characteristics:
- The nonscan design does not have constraint violations.
- The time budget is good.
- You have properly applied realistic path constraints.
- You have described the clock skew.
Note:
If your design enters constraint-optimized scan insertion with violations,
long runtimes can occur.
• Select a scan style.
• Identify barriers to scan replacement.

Scan Insertion
To alter a default scan design, you must specify changes to the scan
configuration. You can make specifications at any point before scan synthesis.
This section describes the specification commands you can use.
With the DFT Compiler scan insertion capability, you can:
• Implement automatically balanced scan chains
• Specify complete scan chains
• Generate scan chains that enter and exit a design module multiple times
• Automatically fix certain scan rule violations
• Automatically insert shadow logic
• Reuse existing modules that already contain scan chains
• Control the routing order of scan chains in hierarchy
• Perform scan insertion from the top or the bottom of the design

58
 Using Constraint-Optimized Scan Insertion
Scan Insertion

• Implement automatically enabling or disabling logic for bidirectional ports

and internal three-state logic
• Share functional ports as test data ports. DFT Compiler inserts enabling and
disabling logic, as well as multiplexing logic, as necessary
You can design scan chains using a specify-preview-synthesize process, which
consists of multiple specification and preview iterations to define an acceptable
scan design. After the scan design is acceptable, you can invoke the synthesis
process to insert scan chains. Figure 22 shows this specify-preview-synthesize
process.
Figure 22 The Scan Insertion Process

Scan Chain Design

Specification Synthesis

Reporting Preview

Modified scan chain design

User dc_shell script

"what-is" report

Scan Architecture Preview

report
DFTC-generated
dc_shell script

59
Using Constraint-Optimized Scan Insertion
Scan Insertion

Example 6 is a basic scan insertion script.

Example 6 Basic Scan Insertion Script

dc_shell-t> current_design Top

dc_shell-t> dft_drc
dc_shell-t> set_dft_configuration \
-autofix -shadow_wrapper
dc_shell-t> set_scan_configuration \
-chain_count 1
dc_shell-t> preview_dft
dc_shell-t> insert_dft
dc_shell-t> create_test_protocol
dc_shell-t> dft_drc
dc_shell-t> estimate_test_coverage
dc_shell-t> report_test -scan_path
dc_shell-t> report_constraints -all_violators

In this example, the dft configuration command is set_dft_configuration

-autofix -shadow_wrapper. It enables both the AutoFix and the Shadow
LogicDFT capabilities.
The scan specification command is set_scan_configuration
-chain_count 1. It specifies a single scan chain in the design.
The preview_dft command is the preview command. It builds the scan chain
and produces a range of reports on the proposed scan architecture.
The insert_dft command is the synthesis command. It implements the
proposed scan architecture.
The following sections describe these steps in the design process.

Specification
During the specification phase, you use the scan and dft specification
commands to describe how the insert_dft command should configure the
scan chains and the design. You can apply the commands interactively from
the dc_shell or use them within design scripts. The specification commands
annotate the database but do not otherwise change the design. They do not
cause any logic to be created or any scan routing to be inserted.
The specification commands apply only to the current design (as determined
by the current_design command) and to lower-level subdesigns within the

60
 Using Constraint-Optimized Scan Insertion
Scan Insertion

current design. If you want to do hierarchical scan insertion using a bottom-up

approach, use the following general procedure:
1. Set the current design to a lower-level subdesign (current_design
command).
2. Set the scan specifications for the subdesign (set_scan_path,
set_scan_element, and so on).
3. Insert the scan cells and scan chains into the subdesign (dft_drc,
preview_dft, and insert_dft).
4. Repeat steps 1, 2, and 3 for each subdesign, at each level of hierarchy, until
you finish scan insertion for the whole design.
By default, the insert_dft command recognizes and keeps scan chains
already inserted into subdesigns at lower levels. Thus, you can use different
sets of scan specifications for different parts or levels of the design by using
insert_dft separately on each part or level.
Note that each time you use the current_design command, any previous
scan specifications no longer apply. This means that you need to enter new
scan specifications for each newly selected design.

Scan Specification
Using the scan specification commands, you can specify as little or as much
scan detail as you want. If you choose not to specify any scan detail, the
insert_dft command implements the default full-scan methodology. If you
choose to completely specify the scan design that you require, you explicitly
assign every scan element to a specific position in a specific scan chain. You
can also explicitly define the pins to use as scan control and data pins.
Alternatively, you can create a partial specification, where you define some
elements but do not issue a complete specification. If you issue a partial
specification, the preview_dft command creates a complete specification
during the preview process.
The scan specification commands are as follows:
• set_scan_configuration
• set_scan_path
• set_scan_signal
• set_scan_element
• set_scan_segment

61
Using Constraint-Optimized Scan Insertion
Scan Insertion

• set_scan_link
• remove_scan_specification
These commands are described in detail later in this chapter.

DFT Configuration
The DFT configuration commands are as follows:
• remove_dft_configuration
• remove_port_configuration
• set_autofix_clock
• set_autofix_async
• set_autofix_configuration
• set_autofix_element
• set_dft_configuration
• set_dft_signal
• set_port_configuration
• set_wrapper_element

Preview
The preview_dft command produces a scan chain design that satisfies scan
specifications on the current design and displays the scan chain design for you
to preview. If you do not like the proposed implementation, you can iteratively
adjust the specification and rerun preview until you are satisfied with the
proposed design.
The scan preview process (the preview_dft command) performs two tasks:
• It checks the specification for consistency. For example, you cannot assign
the same scan element to two different chains.
• It creates a complete specification if you have specified only a partial
specification.
The dft preview process (the preview_dft command) performs the above
two tasks plus two more:
• It runs the specified utilities (AutoFix, Shadow LogicDFT).

62
 Using Constraint-Optimized Scan Insertion
Scan Insertion

• It produces a list of test points that are to be inserted into the design based
on currently enabled utilities.
When you use either of the preview commands, you create a dc_shell script
that completely specifies the proposed implementation. You can edit this script
and use the edited script as an alternative means of iterating to a scan design
that meets your requirements.
Limitation:
Neither preview command annotates the database. If you want to annotate
the database with the completed specification, use the -script option to
create a specification dc_shell script, then run this script. The specification
commands in this script add attributes to the database.

Synthesis
You invoke the synthesis process using the insert_dft command, which
implements the scan design determined by the preview process. If you issue
this command without explicitly invoking the preview process, the insert_dft
command transparently runs preview_dft.
Execute the dft_drc command at least once before executing insert_dft.
Executing dft_drc provides information on circuit testability before inserting
scan into your design.

63
Using Constraint-Optimized Scan Insertion
Scan Insertion

64
 6
Power Compiler and DFT Compiler Interoperability6

Issues associated with the interoperability between DFT

Compiler and Power Compiler are discussed in this chapter.

Improving Testability in Clock Gating

Clock gating raises some concerns for Automatic Test Pattern Generation
(ATPG). These concerns involve enabling clock controllability and scan testing,
as well as optimizing ATPG results.
DFT Compiler might not include a clock-gated register in a scan chain during
scan synthesis if gating the register clock makes it uncontrollable for test. When
the register is excluded from the scan chain, test controllability is reduced at the
register input and test observability is reduced at the register output. If many
registers are gated, the fault coverage can significantly be reduced.
If you add control points during clock gating, you can enable scan testing, thus
improving the testability of the design. However, by controlling the clock signal,
you might introduce untestable faults into the design. To optimize the ATPG
results, you might need to insert observation points during clock gating.

65
Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

Inserting Control Points in Control Clock Gating

A control point is an OR gate driven by a control signal. This signal eliminates
the gating of the clock signal during test, thus restoring the controllability of the
clock signal.
Figure 23 shows a control point (OR gate) placed before a latch connected to a
test_control port. When the test_control signal is high, it overrides clock gating,
thus making the gated clock and CLK signals identical.
Figure 23 Control Point in Gated Clock Circuitry

Control Point Register

D D Q Q
test_control
Latch
I EN D Q
FSM
G

CLK
Clock Gating

You can place the control point OR gate in front of or behind the latch. Latch-
based clock gating requires that the enable signal always arrives after the
trailing edge (rising edge for falling-edge signal) of the clock. If the control point
is inserted before the latch, it is impossible for the control point to violate this
requirement. If it is inserted behind the latch, it behefits the circuit by adding
extra hold time margin for the clock glitch hold check. It does this by delaying
the data signal, which helps the clock pulse arrive ahead of the data.
Inserting the control point after the latch causes performance degradation
because a gate is added between the latch and the register. In addition, the
test_control signal must then transition after the trailing edge (rising edge
for falling-edge signal) of the clock signal during test because it does not go
through the latch; otherwise glitches in the resulting signal corrupt the clock
signal.
You can choose to make the test_control port either a scan_enable
signal or a test_mode signal. The scan_enable signal is active only during
scan shifting. The test_mode signal is active during the entire test.

66
 Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

The set_clock_gating_style command has two options for determining

the location and the type of the control point for test:
• The –control_point option can be none, before or after. The default
is none. When you use a latch-free clock-gating style, the before and
after options are equivalent.
• The –control_signal option can be test_mode or scan_enable. The
default is scan_enable. This option uses an existing test port or creates a
new test port and connects the test port to the control point OR gate.
You can only use the -control_signal option if the -control_point
option is used. For existing test ports, this option relies on the
set_dft_signal command for the test_mode signal and on the
set_scan_signal command for the scan_enable.

Scan Enable Versus Test Mode

Scan enable and test mode differ in the following ways:
• Scan enable is active only during scan mode.
• Test mode is active during the entire test (scan mode and parallel mode).
The scan_enable signal typically provides higher fault coverage than the
test_mode signal. Fault coverage with scan_enable is comparable to a
circuit without clock gating, as shown in Figure 24. During the ATPG capture
mode, the register bank is clocked whenever the output of the flip-flop is a "1";
this behavior matches functional operation.

67
Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

Figure 24 Test Coverage with Test Scan Enable

“1” during Levels of

shift Design
Hierarchy
scan_enable
Data In
Data out
Latch
D Q
Register
Control LD LQ Bank
DFlip Q
Logic EN
Flop LG clk
Enclk
clk

= tested by other vectors

= fully tested

In some situations you must use a test_mode. The control logic preceding
the clock-gating circuitry is not tested, as shown in Figure 25. In addition, the
clock gating logic can only be tested for "stuck-at-one" faults. During test, the
test_mode signal is always a logic "1", forcing the clock at the register bank to
switch at all times. One way to test the clock-gating logic circuitry is to add
observability logic to the design.

68
 Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

Figure 25 Test Coverage with test_mode

Levels of
“1” Design
Hierarchy
test_mode
Data In Data out
Latch
D Q
Register
Control LD LQ
Bank
D
Flip Q Logic EN
Flop LG clk
Enclk
clk

= tested by other vectors = partially tested

= fully tested = not tested

Inserting Observation Points to Control Clock Gating

When you use the test_mode signal, the EN signal and other signals in the
control logic are untestable. You can add observation points during clock gating
can increase the fault coverage.
Figure 26 shows clock gating circuitry, including a XOR tree and a scan
register, to observe the ENL and ENL1 signals, which are outputs of the clock
gating latches.

69
Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

Figure 26 Observability Circuitry in Clock Gating Circuits

Power Saving Logic XOR tree

Observability Circuitry
Observation
ENL1 Register
Q
scan_in
scan_enable

Register
D D Q Q
test_mode
Latch
I EN
FSM D Q
ENL
G
CLK
Control Point
Clock Gating

During test, observability circuitry allows observation of the ENL and ENL1
signals. In normal operation of the circuit, the XOR tree does not consume
power, because the NAND gates block all signal transitions of the ENL and
ENL1 signals.
The insertion of observation test points has high testability and is power-
efficient, because the XOR tree consumes power only during test and the clock
of the observation register is also gated.
The set_clock_gating_style command has two options for increasing
observability when you use the -control_signal test_mode option:
• The –observation_point option can be true or false. The default is
false. When you set this option to true, the
set_clock_gating_style command adds a cell that contains at least
one observation register and an appropriate number of XOR trees. The
scan chain includes the observation register. The output of the observation
register is not functionally connected to the circuit.
• The –observation_logic_depth option allows a depth_value
specification. The default depth_value is 5. The value determines the
depth of the XOR tree.

70
 Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

Choosing a Depth for Observability Logic

Use the -observation_logic_depth option of the
set_clock_gating_style command to set the logic depth of the XOR tree
in the observability cell. The default for this option is 5.
Clock-gating software builds one observability cell for each clock-gated design.
Each gated register in the design provides a gated enable signal as input to the
XOR tree in the observability cell.
If you set the logic depth of your XOR tree too small, clock gating creates more
XOR trees (and associated registers) to provide enough XOR inputs to
accommodate signals from all the gated registers. Each additional XOR tree
adds some overhead for area and power. Using one XOR tree adds the least
amount of overhead to the design.
If you set the logic depth of your XOR tree too high, clock gating can create one
XOR tree with plenty of inputs. However, too large a tree can cause the delay in
the observability circuitry to become critical.
Use a value that meets the following two criteria in choosing or changing the
XOR logic tree depth:
1. High enough to create the fewest possible XOR trees
2. Low enough to prevent critical delay in the observability circuitry

Hooking Up Test Ports Through Hierarchies in Power Compiler

In Power Compiler, use the hookup_testports command to connect test
ports through all the levels of hierarchy to the test_mode or scan_enable
pins of the OR gate in the clock-gating logic, and to the XOR gates in the clock-
gating observability logic. If your design does not have a test port at any level of
hierarchy, Power Compiler will create one. If a test port exists, it will be used.
Use the hookup_testports command on the top-level of the design after all
lower levels have been elaborated. It connects to two test port types:
• test_mode
• scan_enable
You can use the clock_gate_test_pin attribute to designate a test port. In
this case, label it as a scan_enable or a test_mode signal using the
set_signal_type or set_test_hold and set_attribute commands,
respectively.

71
Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

A scan_enable port can only be connected to other scan_enable ports in

the design hierarchy. If a scan_enable port does not exist at a higher level of
hierarchy, Power Compiler will create one.
The design in Example 7 uses the hookup_testports command on a three-
level hierarchy. Note that the lowermost level is clock gated with a
scan_enable control point. In this case, scan_enable ports are created at
all levels — low_design, med_design, and top_design — if they do not
already exist. They are connected then to the scan_enable pin on the clock-
gating logic cell. If the ports are available on one or more designs, Power
Compiler connects them to each other.
Example 7 Hooking Up Test Ports in Power Compiler

dc_shell-t> set_clock_gating_style -control_point after \

-control_signal scan_enable
dc_shell-t> analyze -f vhdl low.vhdl med.vhdl top.vhdl
dc_shell-t> elaborate low_design -gate_clock
dc_shell-t> elaborate med_design
dc_shell-t> elaborate top_design
dc_shell-t> hookup_testports -verbose

Example 8 uses a test_mode port instead of a scan_enable port. Since an

observation circuit is included, the test_mode port of the observation circuit is
connected to the rest of the test_mode ports.
Example 8 Hooking Up Test Mode Ports in Power Compiler

dc_shell-t> set_clock_gating_style -control_point before \

-control_signal test_mode -observation_point true \
-observation_logic_depth 4
dc_shell-t> analyze -f vhdl low.vhdl med.vhdl top.vhdl
dc_shell-t> elaborate low_design -gate_clock
dc_shell-t> elaborate mid_design
dc_shell-t> elaborate top_design
dc_shell-t> hookup_testports -verbose

Example 9 directs hookup_testports to use an existing port ’te’ of module

low_design as a scan_enable.

72
 Power Compiler and DFT Compiler Interoperability
Improving Testability in Clock Gating

Example 9 Hooking Up Scan Enable Ports Using an Existing Port

dc_shell-t> set_clock_gating_style -control_point before \

-control_signal scan_enable -observation_point true
dc_shell-t> analyze -f vhdl low.vhdl
dc_shell-t> elaborate low_design -gate_clock
dc_shell-t> set_scan_signal -port te test_scan_enable
dc_shell-t> hookup_testports -verbose

Example 10 directs hookup_testports to use an existing port ’te’ of module

low_design as a scan_enable using alternate commands.
Example 10 Hooking Up Scan Enable Ports Using an Existing Port

dc_shell-t> set_clock_gating_style -control_point before \

-control_signal scan_enable -observation_point true
dc_shell-t> analyze -f vhdl low.vhdl
dc_shell-t> elaborate low_design -gate_clock
dc_shell-t> set_signal_type test_scan_enable te
dc_shell-t> set_attribute -type boolean te \
test_port_clock_gating true
dc_shell-t> hookup_testports -verbose

Example 11 directs hookup_testports to use an existing port ’te’ of module

low_design for test_mode.
Example 11 Hooking Up Test Mode Ports Using an Existing Port

dc_shell-t> set_clock_gating_style -control_point before \

-control_signal test_mode -observation_point true
dc_shell-t> analyze -f vhdl low.vhdl
dc_shell-t> elaborate low_design -gate_clock
dc_shell-t> set_dft_signal -port te test_mode
dc_shell-t> hookup_testports -verbose

Example 12 directs hookup_testports to use an existing port ’te’ of module

low_design for test_mode using alternate commands.

73
Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

Example 12 Hooking Up Test Ports

dc_shell-t> set_clock_gating_style -control_point before \

-control_signal test_mode -observation_point true
dc_shell-t> analyze -f vhdl low.vhdl
dc_shell-t> elaborate low_design -gate_clock
dc_shell-t> set_test_hold 1 te
dc_shell-t> set_attribute te test_port_clock_gating \
-type boolean true
dc_shell-t> hookup_testports -verbose

Power Compiler / DFT Compiler Interoperability Flows

This section suggests methodologies that can help you avoid interoperability
problems between Power Compiler and DFT Compiler. You can apply these
methodologies directly within the current Power Compiler / DFT Compiler flow.

Using test_mode with Power Compiler

The -control_signal test_mode option of the
set_clock_gating_style command relies on the signal_type or
test_hold attribute to stitch an existing test_mode signal to the clock gating
control point.
Power Compiler identifies the test_mode signal in the following manner:
1. Power Compiler looks for an existing test_mode signal specified with the
set_dft_signal command. You can set the signal_type attribute to
be either test_mode or test_mode_inverted.
2. If a test_mode signal has not been specified with the set_dft_signal
command, Power Compiler looks for an existing port with a test_hold
attribute, which can then be set with the set_test_hold command.
3. If no port has been identified in steps 1 and 2, Power Compiler creates a
new test_mode port during clock gating.

74
 Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

Using Scan Enables with Power Compiler

To achieve high fault coverage in clock-gated designs, the scan chain must be
shifted when scan_enable is asserted. The easiest way to assure this is to
disable all gating elements when scan_enable is asserted. This can be
achieved by placing an OR gate or a NOR gate on the EN input, which forces
EN on when scan_enable is asserted.
In parallel capture mode, the scan chain must also be clocked to ensure data is
captured in the scan registers. However, the use of a scan_enable to control
latch-based and latch-free clock gating might not guarantee this. Furthermore,
the use of a scan_enable to control latch-free clock gating might make the
clock pin of the clock-gated registers uncontrollable.
In Figure 27 the latch-based clock gating does not have violations that prevent
scan insertion. The clock pin is correctly forced to a known state at time = 0,
and it correctly changes state as a result of the test clock toggling (toggling to
an unknown state X is a change of state). Test DRC verifies that the test clock
pulse arrives at the test clock pin to check the scan shift process. Since the
scan_enable port is constrained to logic state 1 during this process, the clock
pin is controllable.
Figure 27 Violation-free Clock Gating

signal_type Register
D D Q Q
scan_enable
Latch
I X/X/X X/X/X
EN D Q 0/X/0
FSM
G
0/1/0
CLK

0/1/0

Table 2 shows the possible combinations of latch-based clock gating, clock

waveforms, control signals and control point location. For each combination,
the last column indicates whether scan insertion can be performed on the
clock-gated register.

75
Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

Table 2 Latched-Based Clock-Gating Configurations

Control Point Register Scan-

Clock Gating CLK Control Signal
Location inserted?

HIGH test_mode Before Latch YES

Latch-based
After Latch YES

scan_enable Before Latch YES

After Latch YES

test_mode Before Latch YES**

After Latch YES

LOW test_mode Before Latch YES

Latch-based
After Latch YES

scan_enable Before Latch YES

After Latch YES

test_mode Before Latch YES**

After Latch YES

HIGH scan_enable Before Latch NO

Latch-based After Latch NO

LOW scan_enable Before Latch NO

Latch-based
After Latch NO

Table 2 describes the configurations that can be used in the Power Compiler —
DFT Compiler flow. Two special cases (marked by ** in Table 2) require you to
modify the test protocol.
Consider the case of high latch-based clock gating controlled by a test_mode
and driven by a return-to-1 clock. If the control point is inserted before the latch,
then when the clock port is off (time = 0), the latch is blocked and the clock pin
is not controllable. This violation also occurs in the case of a low latch-based
clock gating controlled by a test_mode and driven by return-to-0.
To achieve a known state in the latch, add a clock pulse to the test_setup
section of the test protocol. Use the variable

76
 Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

test_setup_additional_clock_pulse = true so that DFT Compiler

automatically updates the protocol.
Consider a latch state that is known, as in the case of a high latch-based clock
gating controlled by a scan_enable with a return-to-1 clock. When the clock
port is off (time = 0), the register does not hold its state. During pre-DFT DRC
capture check, the EN signal goes through the control point and the system
clock pulse might not arrive at the register clock pin. Because the register might
receive invalid data during the capture phase of ATPG, it will not be scan-
inserted. The same DRC violations occur for the low latch-based clock gating
controlled by scan_enable with a return-to-0 clock.

Latch-Free Clock Gating Configurations

Table 3 shows combinations of latch-free clock gating, clock waveforms, and
control signals. For each combination, the last column indicates when the
clock-gated register can be scan-inserted and when it cannot.

Table 3 Latch-Free Clock Gating Configurations

Control Point Register Scan-

Clock Gating CLK Control Signal
Location inserted?

HIGH test_mode Before YES

Latch-based
scan_enable Before NO

test_mode Before YES

scan_enable Before YES

LOW test_mode Before YES

Latch-based
scan_enable Before NO

test_mode Before YES

scan_enable Before YES

Figure 28 shows a latch-free gated clock circuit with violations.

77
Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

Figure 28 Latch-Free Gated-Clock Circuit Violations

Register
D D Q Q
time = 0
scan_enable
I X/X/X X/1/X
EN
FSM

CLK 0/1/0
Clock pin is not controlled (Violation 1)
time = 0
Clock CLK not able to capture (Violation 6)

Do not use the scan_enable to control clock gating. This is similar to the
situation discussed for the high latch-free clock gating driven by a return-to-0
clock. Test DRC prevents the clock-gated register from being scan-inserted.
This also happens for low latch-free clock gating controlled by a scan_enable
and driven by a return-to-0 clock.
Note:
Never use AutoFix to fix the clock pins of clock-gated registers if a control
point has been inserted during clock gating and if the clock-gating’s clock
signal is a primary input. In this case, AutoFix becomes glue logic; the clock-
gating control point and the AutoFix test point are redundant. The control
point of the clock gating should by itself control the clock pin since it was
inserted for this purpose.

Same Clock Driving High and Low Clock Gating

Test DRC flags violations when a combination of high and low latch-based
clock gating is driven by the same clock port CLK. The clock pin of either the
positive edge trigger or the negative edged triggered flip-flop is uncontrollable,
depending upon the clock waveform of CLK. This is shown in Table 2.
Set the test_dft_drc_ungate_clocks variable to address this issue.
When you set this variable to true, DFT Compiler enables clock gating
optimizations to be performed when it excecutes the dft_drc command.
Clock gating optimization ensures that both AND-type and OR-type Power
Compiler style clock gating is correctly supported by the test design rule
checker.

78
 Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

The dft_drc command checks if the clock off state is consistent with the build
optimizations. Both methods of defining clocks (through command or STIL
procedure files) are checked. If the intended clock off state is inconsistent with
build optimizations, an error is reported immediately and no further test design
rule checking is performed.
Error: invalid state offstate (Offstate of "CLK" is incompatible
with build optimizations). (TEST-570)

To address this issue, you need to modify the clock off state.

79
Power Compiler and DFT Compiler Interoperability
Power Compiler / DFT Compiler Interoperability Flows

80
 7
More DFT Methodologies7

This chapter discusses TDVR-Scan, Test Point Insertion

methodologies, and CTL-based Hierarchical Scan Insertion.

What is Test Data Volume Reduction for Scan?

With the advent of multi-million gate system-on-chip (SOC) designs, design-for-
test (DFT) has entered a new phase.
The cost of testing digital integrated circuits for manufacturing defects
continues to be an increasing percentage of overall device cost. The common
perception in the industry is that this cost will soon be unacceptable. Many
factors contribute to increases in the cost of test. Scan test data volume is one
area of prime concern.
Scan test data is the set of ATPG patterns that need to be applied to a device
under test. The volume of that scan test data is directly proportional to the cost
of test.
Some testers have limited pattern memory. In this case, if the test data does
not fit into the ATE memory, it needs to reload vectors. This reloading also
increases test cost.
If you could optimize the use of existing or new ATE hardware, either by
reducing test application time and data volume required to test a device, or by
eliminating or reducing the need to reload vectors on testers with limited

81
More DFT Methodologies
What is Test Data Volume Reduction for Scan?

pattern memory, without compromising test coverage, you could reduce the
cost of test. This is possible with test data volume reduction for scan (TDVR-
Scan).
TDVR-Scan allows you to insert observe test points into a design to reduce the
test data volume while maintaining the test coverage in the design.

Analyzing Observe Points

A node in a design that must be observed in order to improve the testability of a
design is called an observe point. The node can be made observable either by
connecting it to a primary output, or by connecting it to a functional input of a
scan flop and stitching the flip-flop into a scan chain. The new scan flop
inserted to observe the node is called an observe flop. The observe flop can
detect a large number of hard-to-detect faults and significantly reduce the scan
pattern count.
The signal that triggers the observe flop is called the observe clock. There are
two types of observe clocks:
• A dominant observe clock.
This clock is the existing scan test clock that triggers the most scan flip-flops
in the design.
• A dedicated observe clock.
An existing data port or a newly created dedicated port could be used as an
observe clock.
DFT Compiler supports two methods for doing observe point analysis: bottom-
up observe analysis and top-down observe analysis. The preferred method for
SoC designs is bottom-up observe analsys, which is discussed here.

Bottom-Up Observe Test Point Analysis and Insertion

In the bottom-up observe test point analysis flow, you use DFT Compiler to
specify the observe test point selection and implementation constraints for
each scan-replaced module of a top-level design. DFT Compiler performs
observe point analysis, and synthesizes selected observe points for each
module. This is done independently, with specified clocking mechanisms for
observe flops. All modules are stitched together to create the top-level design.
Finally, ATPG analysis is performed to obtain the test coverage for the entire
chip-level design.

82
 More DFT Methodologies
AutoFix

AutoFix
Each scan flip-flop in a design must be clocked by a signal that can be
controlled by a primary input port. Otherwise, clocking of data into the flip-flop
cannot be controlled during test. In addition, the asynchronous preset and clear
inputs of each flip-flop must be inactive during test. Otherwise, the data in the
flip-flop can be set or cleared at any time, leaving unknown data in the flip-flop.
If a flip-flop is clocked by an uncontrollable signal, the command flags the
condition as a design rule violation. For example, Figure 29 shows a portion of
a schematic containing a flip-flop whose clock input cannot be controlled from a
primary input. The dft_drc command reports this as a design rule violation. If
you do not fix this violation, the flip-flop will not be included in a scan chain, and
faults downstream from the flip-flop output might not be detectable.
Figure 29 Uncontrollable Clock Input

D Q

D Q Combinational
logic

Uncontrollable
CLK clock input

AutoFix can automatically fix each uncontrollable clock input as shown in

Figure 30. It inserts a multiplexer at the clock input. The multiplexer is
controlled by a “test mode” primary input signal, called TM in this example. For
normal (mission-mode) operation, the TM signal is inactive, and the circuit
operates the same as before. During test, the TM signal is asserted, causing
the flip-flop to be clocked by a primary input signal, which is CLK in this
example. This configuration allows the flip-flop to be controlled during test.

83
More DFT Methodologies
AutoFix

Figure 30 Uncontrollable Clock Input Fixed by AutoFix

D Q
D Q Combinational 0
logic 1
CLK

TM

The same TM signal can be used to enable and disable all multiplexers
inserted by AutoFix (and by Shadow LogicDFT as well). Note that the TM
signal is different from the scan-enable signal used to control shift and capture
using scan chains. The test mode signal is always active during test, including
during capture time.
AutoFix can automatically fix uncontrollable asynchronous preset and clear
inputs in a similar manner. For example, consider the subcircuit in Figure 31.
The asynchronous clear input of the upper-right flip-flop is connected directly to
the Q output of the lower-left flip-flop, causing the upper-right flip-flop to be
cleared at unpredictable times.
Figure 31 Uncontrollable Asynchronous Clear Input

Pre
D Q

Clr

D Q

CLK
Clr Uncontrollable
Asynchronous
RSTN Clear Input

84
 More DFT Methodologies
Shadow LogicDFT

When asked to fix this type of violation, AutoFix inserts a multiplexer with one
input connected to logic 1, as shown in Figure 32. This is functionally the same
as an OR gate. For mission-mode operation, the TM signal is inactive, and the
circuit operates the same as without the inserted logic. During test, the TM
signal is asserted, which holds the clear input inactive.
Figure 32 Uncontrollable Asynchronous Clear Input Fixed by AutoFix

Pre
Pre
D D QQ

ClrClr

D Q
D Q 00
CLK
Clr 1 11

RSTNCLK

TM
TM

Shadow LogicDFT
The Shadow LogicDFT utility inserts test points on the inputs and outputs of a
designated element such as a RAM block. A RAM block is not controllable or
observable during test, so any combinational logic feeding a RAM input is not
observable, and any combinational logic at a RAM output is not controllable.
For test purposes, the RAM block is a “shadow” that interferes with the
testability of the surrounding logic, as illustrated in Figure 33.

85
More DFT Methodologies
Shadow LogicDFT

Figure 33 Untestable Logic Surrounding a RAM Block

RAM
Combinational block
logic Combinational
logic

Unobservable Uncontrollable
address or data input data output

The Shadow LogicDFT utility inserts a “wrapper” around the block to make the
surrounding logic testable, as shown in Figure 34. Note that the two figures
show only the logic for one input and one output. Shadow LogicDFT works
similarly for each input and output of the RAM block.

86
 More DFT Methodologies
Shadow LogicDFT

Figure 34 Inserted Shadow LogicDFT on Address and Data Pins

RAM
Combinational 0
logic block Combinational
1 logic

Sink Source

D Q D Q

TPCLK

TM

scan_in scan_out

On each address and data input to the block, Shadow LogicDFT adds a “sink”
to record the signal values during test. A sink is a scan flip-flop clocked by a
“test point clock” signal, shown as TPCLK in the figure. During test, the sink
captures the output of the combinational logic that ordinarily feeds the RAM
block input.
On each data output of the block, Shadow LogicDFT adds a “source” to provide
a signal value during test. A source is a scan flip-flop whose output is
multiplexed with the RAM block output. A test mode signal, shown as TM in the
figure, allows the flip-flop to provide a controllable output value during test. This
is typically the same test mode signal used by AutoFix.
Shadow LogicDFT adds somewhat different logic for the RAM chip select and
output enable inputs. During test, TM is asserted, causing the added logic to

87
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

deselect the chip and disable its outputs, thus isolating the RAM block from the
rest of the circuit during test.
If the RAM block has three-state outputs, Shadow LogicDFT connects another
three-state driver to each output signal line. During test, assertion of the TM
signal disables the RAM chip outputs and enables the added three-state
drivers, thus allowing the added circuitry to drive each output line with
controllable data stored in a scan flip-flop.

Hierarchical Scan Synthesis (HSS) Flow

When you work with large designs, you may need to use the hierarchical scan
synthesis design-for-test (DFT) flow to reduce memory usage and speed up the
runtime. With the DFT Compiler hierarchical scan insertion capability, you can:
• Implement automatically balanced scan chains
• Specify complete scan chains
• Generate scan chains that enter and exit a design module multiple times
• Automatically fix certain scan rule violations
• Automatically insert shadow logic
• Reuse existing modules that already contain scan chains
• Control the routing order of scan chains in hierarchy
• Perform scan insertion from the top or the bottom of the design
• Implement automatically enabling or disabling logic for bidirectional ports
and internal three-state logic
• Implement automatically multiplexed and enabling or disabling logic to
shared function ports as test data ports
The hierarchical scan synthesis flow uses test models that describe only the
portions of subdesigns that are important for inserting DFT flow.
Note:
Because DFT Compiler saves the test model as an attribute to the design in
.db binary format, you cannot use a text editor to view these test models.
Important:
Test models are not adequate for the generation of test patterns, so you
must have an actual netlist representation for use with automatic test pattern
generation (ATPG).

88
 More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

Introduction to Test Models

Test models store the following test information:
• Port names
• Port directions (input, output, bidirectional)
• Scan structures
• Scan clocks
• Asynchronous sets and resets
• Three-state disables
• Test attributes on ports
• Test protocol information, such as initialization, sequencing, and clock
waveforms
Figure 35 shows a sample design schematic, and Figure 36 shows how a test
model might represent the test attributes of that design.
Figure 35 Sample Schematic

CLK

MINS
U1 U2 U3 U4
TEST_SI

TEST_SE HOURS
RESETN

HOURS_BUTTON

MINUTES_BUTTON

ALARM_BUTTON

89
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

Figure 36 Test Model Representation

Scan structure
Clock

CLK Scan out

Scan in
MINS
Scan enable TEST_SI U1 U2 U3 U4 Output
Active low
TEST_SE HOURS
asynchronous
reset RESETN

HOURS_BUTTON
Inputs
MINUTES_BUTTON

ALARM_BUTTON

Creating Test Models for Subdesigns

DFT Compiler creates test models automatically during scan insertion if the
test_use_test_models variable is set to true. By default, this variable is
set to false. When you set this variable, its value must remain consistent
throughout your design process.
You can create a test model in one of two ways:
• For a non-scan design, set test_use_test_models to true and run
insert_dft to perform scan replacement and scan stitching in one step.
DFT Compiler automatically generates a test model at the same time.
• If your design already has scan inserted (by running insert_dft), but the
test_use_test_models variable was set to false, first set the variable
to true. Next, read in the .db format netlist, which includes the necessary
scan chain information for the test model. Run dft_drc on the design to
extract the scan chain information and generate the test model.
Lock-up latches are necessary in order to freely mix scan chains from different
clock domains; but when you use test models to assemble the top-level design,

90
 More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

DFT Compiler cannot insert lock-up latches inside the test models. At the
subdesign level, you might want to insert a lock-up latch at the end of each
scan chain in the module. You can specify the insertion of lock-up latches
inside the module using the -insert_end_of_chain_lockup_latch
option of the set_scan_configuration command. See the DFT Compiler
DFT Architecture User Guide for more information about this option.

Linking Test Models to Library Cells

When library cells have built-in scan chains, CTL test models must be linked,
either inside the library or inside the design, for DFT Compiler to connect the
scan chains at the top level. To link a test model inside the library, enter the
command:
read_lib <lib_file>.lib -test_model \
<cell_name>:<model_file>.ctl
To link multiple cells in one library, use the following syntax:
read_lib <lib_file>.lib -test_model [list \
<model_file1>.ctl <model_file2>.ctl]
To link a test model inside a design (which must be done if it has not been
linked in the library), enter the command:
read_test_model -format ctl -design <cell_name> \
<model_file>.ctl
Note:
If your library already contains library test models, and you do not want to
overwrite those models with CTL test models, do not use the
read_test_model command. Remove this command from your scripts as
well.

91
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

Checking if a Library Contains CTL Models

To determine if a library has CTL models attached to it, read in the library with
the link command or the compile command, then run report_lib. If the
library has CTL models attached, the report will indicate ctl in the
Attributes list as shown in Example 13.
Example 13 Simple report_lib Output

Cell Footprint Attributes

___________________________________________
my_memory b, d, s, u, ctl, t

Scan Assembly Using Test Models

In practice, you should use test models to represent subdesigns, then stitch the
test models together at the top level of the design. Because the test model
stores less information than a full gate-level representation in a .db database, a
design with test models uses less memory than a design with subdesigns
represented by gate-level .db files.
Figure 37 shows scan assembly at the top level of a design with several
subdesigns represented by test models. The top-level scan assembly process
also works if some of the subdesigns are implemented at the gate level, or if
user-defined logic exists at the top level.
Figure 37 Scan Assembly Using Test Models

Module 1 Scan in Module 1

Test model Test model

Scan out
Module 3 Module 3
Test model Test model

Module 2 Module 2
Test model Test model

Before top-level scan assembly After top-level scan assembly

92
 More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

The following sections contain more detail about creating and using test
models.

Using Netlist Information Instead of the Test Model

When you have a design with both test model and gate information, DFT
Compiler uses the test model by default instead of the gate-level netlist. If you
want DFT Compiler to retrieve test information from the full design (or a module
of the design) and not from the test model, use the set_test_model false
block_name command on the instance or design name. This way, design rule
checking and scan insertion do not use the block’s test model test information,
but rather the full gate-level design’s test information.
Note:
Do not use the set_test_model false command on a block that
contains only test models loaded with the read_test_model command,
or on blocks loaded as interface logic models (ILMs).

Saving Test Models for Subdesigns

At the end of the flow, use the write_test_model command to save the test
model to disk. Alternatively, you can use the write command to generate a .db
file containing both the test model and gate information.
You should also write out a Verilog or VHDL netlist of the design to use with
TetraMAX.
Example 14 shows a script for creating and saving a test model on a design
that has no existing scan structures.
Example 14 Test Model Creation on Nonscan Design

dc_shell-t> set test_use_test_models true

dc_shell-t> remove_design -all
dc_shell-t> read -f verilog ALARM_BLOCK.v
dc_shell-t> read -f verilog TIME_BLOCK.v
dc_shell-t> read -f verilog COMPUTE_BLOCK.v
dc_shell-t> read_test_model alarm_sm_2.ctldb
dc_shell-t> read -f verilog COMPARATOR.v
dc_shell-t> link
dc_shell-t> list_test_models
dc_shell-t> current_design COMPUTE_BLOCK
dc_shell-t> link

93
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

dc_shell-t> create_test_clock CLK -period 100 -waveform {45 55}

dc_shell-t> set_signal_type test_asynch_inverted RESETN
dc_shell-t> create_clock CLK -period 100 -waveform {0 50 }
dc_shell-t> compile -scan
dc_shell-t> set_scan_configuration -chain_count 1
dc_shell-t> set_scan_path chain0 { U1, U5/chain0, U2}
dc_shell-t> create_test_protocol
dc_shell-t> dft_drc
dc_shell-t> preview_dft -show all
dc_shell-t> insert_dft
dc_shell-t> dft_drc -verbose
dc_shell-t> write -format db -hier -o psc.db
dc_shell-t> write -format verilog -hier -o psc.v
dc_shell-t> report_test -scan
dc_shell-t> write_test_model -o COMPUTE_BLOCK.ctldb
dc_shell-t> set test_stil_netlist_format verilog
dc_shell-t> write_test_protocol -format stil -o ana_top.spf
dc_shell-t> exit

Using Test Models

At the top level of your design, you have to read in the test models that you
created for the subdesigns and perform scan insertion.
To read in the test models at the top level, use the read command as with any
other .db file, or you can use the read_test_model command:
dc_shell-t> read_test_model test_model_filenames

Use the list_test_models command to create a list of the test models

loaded and the associated designs.
You can use the top-level DFT flow, described in Chapter 1, “Design-for-Test
Methodologies,” to insert scan at the top level of the design. DFT Compiler uses
the test models loaded instead of the .db files for subdesigns.
Important:
DFT Compiler does not touch scan chains within the test models—it
combines scan chains only at the top level to make the total lengths of the
combined chains as close as possible.
DFT Compiler recognizes when lock-up latches have been inserted in a test
model and does not insert another lock-up latch when connecting scan chains
between two test models unless it is necessary.
After inserting scan at the top level of your design, write out the test protocol
file in Standard Test Interface Language (STIL) format, and write out a Verilog

94
 More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

or VHDL top-level netlist. The following commands write out a protocol file and
a Verilog netlist for a top-level design called top:
dc_shell-t> write_test_protocol -format stil -out top.spf
dc_shell-t> write -format verilog -output top.v

If your top-level design contains test models for a subdesign, DFT Compiler
does not write out a gate-level netlist for that subdesign, even if you use the
-hierarchy option. The netlist written contains an empty module for the test
model subdesign. You must write a gate-level netlist for each subdesign
separately.
Example 15 shows how test models can be used at the top level of a design.
Example 15 Test Model Usage

dc_shell-t> remove_design -all

dc_shell-t> read -f verilog ALARM_BLOCK.v
dc_shell-t> read -f verilog TIME_BLOCK.v
dc_shell-t> read -f verilog COMPUTE_BLOCK.v
dc_shell-t> read_test_model alarm_sm_2.ctldb
dc_shell-t> read -f verilog COMPARATOR.v
dc_shell-t> link
dc_shell-t> list_test_models
dc_shell-t> current_design COMPUTE_BLOCK
dc_shell-t> link
dc_shell-t> create_test_clock CLK -period 100 -waveform {45 55}
dc_shell-t> set_signal_type test_asynch_inverted RESETN
dc_shell-t> create_clock CLK -period 100 -waveform {0 50 }
dc_shell-t> compile -scan
dc_shell-t> set_scan_configuration -chain_count 1
dc_shell-t> set_scan_path chain0 { U1, U5/chain0, U2}
dc_shell-t> dft_drc
dc_shell-t> preview_dft -show all
dc_shell-t> insert_dft
dc_shell-t> dft_drc -verbose
dc_shell-t> report_test -scandc_shell-t> write -format db -hier \
-o psc.db
dc_shell-t> write -format verilog -hier -o psc.v
dc_shell-t> write_test_model -o COMPUTE_BLOCK.ctldb
dc_shell-t> set test_stil_netlist_format verilog
dc_shell-t> write_test_protocol -format stil -o ana_top.spf
dc_shell-t> exit

Example 15 shows a typical script for the HSS flow. Note that dft_drc is run
right after insert_dft to verify that scan insertion is correct, without errors. If
dft_drc reports any serious violations, such as scan chain blockages, you

95
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

must fix these and rerun the script. Once dft_drc is successful, you can run
report_test -scan to get more information about scan chains.
Note:
When you use HSS flow, you must run dft_drc after scan insertion and
check the results. The results from the report_test command can be
considered only after dft_drc is error-free.

Reading Designs Into TetraMAX

By default, in TetraMAX if you read in two modules with the same name, the
last one takes precedence. If you have a top-level netlist with empty
submodules, read that into TetraMAX first, then read in the netlists for the
submodules. For example,
BUILD> read netlist top.v
BUILD> read netlist module_1.v module_2.v ... module_n.v
BUILD> run build top

Managing Test Models

As shown in Figure 38, DFT Compiler creates test models when you insert
scan, and you can save the test models using the write or
write_test_model command.

96
 More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

Figure 38 Creating and Saving Test Models

External .db file

DFT Compiler
Test model

insert_dft

Internal representation Gates

Test model
write -format db External .db file

Gates (.db)
Test model
write_test_model

Module interface

As shown in Figure 39, you can read test models into DFT Compiler using the
read or read_test_model command.

97
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

Figure 39 Using Test Models

External .db file DFT Compiler

Internal representation
Test model
read -format db
Test model

Gates read_test_model
Gates (.db)

External .db file

Internal representation
Test model
read -format db Test model

Module interface
read_test_model Module interface

The different commands that you can use to write and to read test models allow
you to tailor the flow you use to meet your needs. There are several possible
flows:
• Use write_test_model to save a test model, and use read or
read_test_model to read it into DFT Compiler.
In this case, the file created by write_test_model contains only the test
model and module interface information, so this flow uses less memory and
improves execution time.
This flow is recommended for the greatest improvement in runtime and
memory usage, but you have the flexibility of using either of the following
flows.
• Use write to save a design with a test model, and use read_test_model
to read it into DFT Compiler.

98
 More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

The file created by the write command contains both a test model and
gate information. But the read_test_model command reads in only the
test model portion of the file, and notifies you DFT Compiler has removed all
implementation information. This flow uses less memory and improves
execution time.
• Use write to save a design with a test model, and use read to read it into
DFT Compiler.
The write command creates a file containing both the test model and the
gate information. The read command reads in both the test model and the
gate information, but DFT Compiler uses the test model by default. Because
of the test model usage, the execution time is improved, but you do not save
as much memory as with the other flows. This flow does not use commands
specific to test models, so it might fit in your existing flow with minimal
changes.
If you use the read command to read in both test model and gate
information, any optimization will be timing blind when the
test_use_test_models variable is set to true. If you want to perform top-
level optimization after scan insertion, first perform scan insertion with
test_use_test_models set to true, then perform subsequent
optimization steps with test_use_test_models set to false.
The test_use_test_models variable affects only test-related
commands such as dft_drc, and insert_dft. It does not affect
commands that perform timing or area optimization such as compile.
After such optimization, you might receive the OPT-463 warning message,
which states that scan chain information will be deleted from your design.
Note, however, that the test model will remain intact. To avoid receiving this
warning message, you can execute set_dont_touch on the instances
concerned.

Top Level Integration

Once the individual modules are complete, with scan chain and observe test
logic inserted, stitch the modules together at the top level.
When you use the HSS flow, keep the following points in mind:
• If you are using TDVR, no observe analysis is performed for any user-
defined logic or glue logic at the top level.

99
More DFT Methodologies
Hierarchical Scan Synthesis (HSS) Flow

• If dedicated clocks exist in some of the modules, they need to be stitched

with a chip-level pin to avoid creating another chip-level port.
• If an observe_test_mode exists in some modules, they need to be stitched
with a chip-level pin to avoid creating another chip-level port.
HSS flow is shown in Figure 40.
Figure 40 Chip Level Integration Using the HSS Flow

Postscan netlist of Postscan netlist of Postscan netlist of

Module 1 with Module 2 with Module N with
observe points observe points observe points

Extract Test Model Extract Test Model Extract Test Model

for Module 1 for Module 2 for Module N

Chip level Integration

(Using HSS)

Chip level Test Design Rule Checking

Generation of Test Logic Inserted

Netlist and Database for chip level

Verilog DB STIL

100
 Index

A C
analog circuitry 2 cells
asynchronous behavior 2 obtaining lists of 49
attributes checking design rules in DFT Compiler design flow
clock_gate_test_pin 71 13, 18
AutoFix 78 chip level ILMs
running with preview_dft 62 gates to placed gates command flow 45
summary of 83 gates to placed gates flow 44
Automatic 65 RTL to placed gates command flow 46
RTL to placed gates flow 45
circuit description
B HDL-level 20
benefits reading an HDL-level 11, 17, 22
interface logic models 41 circuitry
benefits to using ILMs 41 in interface logic models 42
block level ILMs circuitry included in ILMs 42
gates to placed gates command flow 43 clock gating
gates to placed gates flow 43 improving testability 65
RTL to placed gates command flow 44 inserting control points 66
RTL to placed gates flow 44 inserting observation points 69
block-by-block design strategy 25 latch-based configurations 76
bottom up flow latch-free configurations 77
extracted in interface logic models 42 observability
bottom up flow for ILMs 42 logic depth, choosing 71
bottom-up design flow observability logic 71
overview 3 scan mode versus test mode 67
support for mixed scan states 55 clock signals, internally generated 2
clock_gate_test_pin attribute 71
combinational feedback loops, effect on scan
design 2

101
commands constraint-optimized scan insertion
create_ilm 47 degeneration support 56
extract_ilm 42 process 55
hookup_testports 71 process flow, scan replacement 57
insert_dft 25 scan replacement 55
default scan design 51 support for mixed scan states 55
invoking synthesis process 63 constraints, design 11, 17, 22
pad cells 52 control point 66
list_test_models 94 controllability 1
preview_dft 62 create_ilm command 47
creating a specification dc_shell script 63
default scan design 51
propagate_annotated_delay_up 42 D
propagate_ilm -delay 47 definitions
propagate_ilm -placement 47 nonscan design 55
propagate_placement_up 42 scan design 55
read_test_model 94, 97 scan insertion 25
remove_dft_configuration 62 test protocol 5
remove_port_configuration 62 unrouted scan design 55
remove_scan_specification 62 depth_value 70
report_cell -physical 49 description of interfaced logic models 40
report_port -physical 49 design constraints 11, 17, 22
set_attribute 71 design environment 7
set_autofix_clock 62 design flows
set_autofix_configuration 62 physical scan synthesis 30
set_autofix_element 62 design state
set_clock_gating_style 67, 70, 74 unknown 48
set_dft_configuration 62 design-for-test flows 7, 29
set_dft_signal 62, 67 DFT Compiler
set_port_configuration 62 interoperability issues 74
set_scan_configuration 27, 61 dft_drc command
set_scan_element 61 fixing violations with AutoFix 83
set_scan_link 62
set_scan_path 61 E
set_scan_register_type 28
set_scan_segment 61 extract_ilm command 42
set_scan_signal 61, 67
set_signal_type 71 F
set_Test_hold 71 fault coverage
set_test_model 93 and controllability 1
set_wrapper_element 62 maximizing 1
write_test_model 93, 96 fixing timing problems 49
compile command, test-ready 12 flows
compile -scan command, specifying scan cells 28 bottom-up scan insertion 4
compiled cells 2 design-for-test 7, 29
congestion top-down scan insertion 5
physical scan synthesis and 35

102
G interface logic models
benefits to using 41
gated clocks 2
bottom up flow 42
gates to placed gates
circuitry included in 42
block level ILM command flow 43
description of 40
chip level ILM command flow 45
gates to placed gates command flow at the block
chip level ILM flow 44
level 43
gates to placed gates flow gates to placed gates command flow at the chip
block level ILM 43 level 45
gates-to-placed-gates flow gates to placed gates flow at the block level 43
physical scan synthesis 33 gates to placed gates flow at the chip level 44
logic extracted for 41
H RTL to placed gates command flow at the block
HDL-level circuit description 20 level 44
RTL to placed gates command flow at the chip
hierarchical scan insertion 58 level 46
hierarchical scan synthesis, benefits of 3 RTL to placed gates flow at the block level 44
hookup_testports command 71 RTL to placed gates flow at the chip level 45
scan chain information in 40
I
ILMs L
benefits to using 41 list_test_models command 94
bottom up flow 42 logic
circuitry included in 42 extracted in interface logic models 41
described 40 logic extracted for ILMs 41
logic extracted for 41
scan chain information in 40
insert_dft M
unknown design state and 48 macro functions 2
insert_dft command 25 mapping your circuit description 12
default scan design 51 memory, reducing use of 88
invoking synthesis process 63 missing scan cells
pad cells 52 scan ordering and 49
specifying scan cells 28 missing scan ports
scan ordering and 49

O
observability logic, logic depth 71
obtaining lists of cells 49
obtaining lists of ports 49
off-chip clock signals 2

P
pad cells
insert_dft command 52
partitioning
placement based scan chain 39

103
Physical Compiler RTL to placed gates
and problems with physical scan synthesis 50 block level ILM command flow 44
physical scan block level ILM flow 44
unknown design state 48 chip level ILM command flow 46
physical scan placement chip level ILM flow 45
scan cell allocation 39 RTL-to-placed-gates flow
scan chain balancing 39 physical scan synthesis 32
scan clocks 39
physical scan problems
troubleshooting 48 S
physical scan synthesis scan cell
congestion and 35 specifying 28
design flows 30 scan cell allocation
gates-to-placed gates flow 33 physical scan placement 39
general flow 31 scan chain
partitioning 39, 40
problems with Physical Compiler and 50
with asserted scan_enable 75
reordering flow 34
scan chain balancing
RTL-to-placed-gates 32
physical scan placement 39
placement
scan chain information
scan chain partitioning based on 39
interface logic models 40
ports
obtaining lists of 49 scan chain information in ILMs 40
Power Compiler scan chain partitioning
interoperability issues 74 placement based 39
using scan enables 75 scan clocks
physical scan placement 39
using test_mode 74
scan design
preview_dft command 62
default 51
creating a specification dc_shell script 63
scan design technique 1
default scan design 51
scan enable 67
propagate_annotated_delay_up command 42
scan enables
propagate_ilm -delay command 47 leaving unrouted 50
propagate_ilm -placement command 47 scan insertion
propagate_placement_up command 42 bottom-up 3
definition 25
R hierarchical 58
preparing for 25
RAM cells 2
previewing (see also preview_dft command) 62
RAM, inserting shadow logic 85 previewing (see alsopreview_dft command) 62
read_test_model command 94, 97 specifying scan chain configuration 60
remove_dft_configuration command 62 remove_scan_specification command 62
remove_port_configuration command 62 set_scan_configuration command 61
remove_scan_specification command 62 set_scan_element command 61
reordering set_scan_link command 62
physical scan synthesis flow 34 set_scan_path command 61
report_cell -physical command 49 set_scan_segment command 61
report_port -physical command 49 set_scan_signal command 61
-route option, set_scan_configuration command 27 synthesis (see also insert_dft command) 63
top-down 5

104
scan ordering T
missing scan cells 49
target technology library 11, 17, 22
missing scan ports 49
scan replacement test mode 67
method 56 test mode signal 87
timing impact 56 inserted by AutoFix 83
using constraint-optimized scan insertion 55 test models 88
scan states creating 90
nonscan 55 managing 96
scan 55 overriding creation 93
supported by constraint-optimized scan insertion saving 93
55 scan assembly using 92
unrouted scan 55 using 94
scan style test points
selecting, in design flow 12, 18, 23 clock signal 87
scan_enable 75 inserting 63, 85
scan_enable port 71 test ports, connecting 71
scan_enable signal 66, 67 test protocol 76
scannable cell equivalents in library 2 test protocol, defined 5
set_attribute command 71 test_control port 66
set_autofix_clock command 62 test_mode port 71
set_autofix_configuration command 62 test_mode signal 66, 67, 69, 74
set_autofix_element command 62 test_setup_additional_clock_pulse variables 77
set_clock_gating_style command 67, 70, 74 test_use_test_models variable 42, 47, 90, 99
set_dft_configuration command 62 Test-ready compile 12
set_dft_signal command 62, 67 timing problems
set_port_configuration command 62 fixing 49
set_scan_configuration command 61 top-down design flow, overview 5
-route option 27 troubleshooting
physical scan 48
set_scan_element command 61
set_scan_link command 62
set_scan_path command 61 U
set_scan_register_type command 28 unknown design state 48
set_scan_segment command 61
set_scan_signal command 61, 67 V
set_signal_type command 71 variables
set_test_hold command 71 set_test_scan_partition 40
set_test_model command 93 test_setup_additional_clock_pulse 77
set_test_scan_partition variable 40 test_use_test_models 42, 47, 90, 99
set_wrapper_element command 62 violations, fixing with AutoFix 83
Shadow LogicDFT
running with preview_dft 62
understanding 85
W
sink, inserted by Shadow LogicDFT 87 write_test_model command 93, 96
source, inserted by Shadow LogicDFT 87
system variables 7

105
106