Scanuser PDF

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Beta
Product Version 4.0.10 August 2001
1999-2000 Cadence Design Systems, Inc. All rights reserved. Printed in the United States of America. Cadence Design Systems, Inc., 555 River Oaks Parkway, San Jose, CA 95134, USA Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) contained in this document are attributed to Cadence with the appropriate symbol. For queries regarding Cadences trademarks, contact the corporate legal department at the address shown above or call 1-800-862-4522. All other trademarks are the property of their respective holders. Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. Except as specied in this permission statement, this publication may not be copied, reproduced, modied, published, uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions: 1. The publication may be used solely for personal, informational, and noncommercial purposes; 2. The publication may not be modied in any way; 3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other proprietary notices and this permission statement; and 4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be discontinued immediately upon written notice from Cadence. Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and condential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadences customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information. Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
ra
ft
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS
Contents
Preface ............................................................................................................................ 7
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Other Information Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Text Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 About the Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Using Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Using Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Test Synthesis Benets and Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Synthesis: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benets: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Whats New? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Features of Cadence Test Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unsupported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..................................................................... 11 11 11 12 12 13 13 13 13
2 Test Synthesis Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Start the Synthesis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set Test Synthesis Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check DFT Assertions and Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set Timing Constraints and Optimize the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connect the Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . View the Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the Scan Chain Text Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16 17 18 19 21 22
August 2001
Product Version 4.0.10
Viewing the Scan Chain in the Schematic Viewer
. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Tips for Performing Test Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Requirements for Test Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended Command Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Top-Down Test Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bottom-Up Test Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When to Use Tieback Mode and Chain Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using ADB Files from Prior Test Synthesis Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Gate-Level Netlist Files from Prior Test Synthesis Runs . . . . . . . . . . . . . . . . . Understanding the Impact of Test Synthesis on the Design Database . . . . . . . . . . . Avoiding DFT Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overriding the Declarations of DFT Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . Finding the RTL Code Causing DFT Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . Handling Non-Scannable Design Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAMs and ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Test Synthesis Assertions and Using Test Synthesis Commands . . . . . . . . . . . . 25 26 26 28 31 32 35 38 39 44 45 46 47 47 48
4 Using Test Synthesis Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Handling of Different Scan Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiplexed Scan Style Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiplexed Scan Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clocked-Scan Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clocked-LSSD Scan Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auxiliary Clocked-LSSD Scan Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Special Scan Flip-Flop for Alcatel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single Latch LSSD or Double Latch LSSD Scan Flip-Flops Not Handled . . . . . . . . . 53 54 54 55 56 58 59 59
August 2001
Specifying Multiple Scan Mode Signals and set_scan_data . . . . . . . . . . . . . . . . . . . . Specifying Shared Scan-in and Scan-out Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Internal Scan Mode, Scan Data, and Test Mode Ports or Pins . . . . . . . . . . . Specifying an Internal Clock Domain as a Separate DFT Clock Domain . . . . . . . . . . . . General Notes Regarding Internal Ports and Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Insertion of Data Lockup Latches in the Multiplexed Scan Style . . . . . . . . . . . . . . . . . . . Multiple Clocks in Test Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..................................................................... Analysis of Data Lockup Latches in an Existing Scan Chain . . . . . . . . . . . . . . . . . . . . . .
60 65 68 76 83 85 95 97 97
5 How Test Synthesis Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

When Test Synthesis is Called During the Optimization Process . . . . . . . . . . . . . . . . . . 99 Routines of the Scan Connection Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Conguring the Scan Chain using test synthesis commands . . . . . . . . . . . . . . . . . . . . 102 Controlling the Scan Chain Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Using the Scan Order File to Order and Congure the Scan Chains . . . . . . . . . . . . . . 106
6 PKS Ordering of Scan Chains
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Running the Scan Connection Engine in preserve_config Mode . . . . . . . . . . . . . . 118 Running the Scan Connection Engine Without the preserve_config Mode Option . 120 Summary of Running Scan Connection Engine in preserve_config Mode . . . . . . . 121 Re-establishing Test Synthesis Setup on a Gate-Level Netlist Prior to PKS Reordering 123 Block-Level Database: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Chip-Level Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Handling of Scan Mode Network and Scan Data Path Connections During PKS Reordering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Using Test Synthesis Commands with PKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Test Synthesis Commands with PKS RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Test Synthesis Commands with PKS Mapped Netlist . . . . . . . . . . . . . . . . . . . . . 133
August 2001
A Tutorial Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 B Test Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 C General Note Regarding Scan Order File Format . . . . . . . . . . . 145
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Hierarchical Scan Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Flat Scan Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
D Example Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Using Test Synthesis Commands with PKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source RTL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Source RTL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL Script 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL Script 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL Script 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RTL Script 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gate Level Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GatesRTL1.vm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GatesRTL2.vm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GatesRTL3.vm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GatesRTL4.vm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 153 155 155 156 157 159 161 161 162 163 164
E Understanding Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
August 2001
Preface
This preface contains the following sections:
I I I I
About This Manual on page 7 Other Information Sources on page 7 Syntax Conventions on page 8 About the Graphical User Interface on page 9
About This Manual

This manual describes the how to use the Envisia test synthesis tool. To use this manual, you should be familiar with synthesis techniques, in general, and with Ambit BuildGates, in particular. The terms ip-op and register are used interchangeably in this manual.
Other Information Sources

For more information about Ambit BuildGates synthesis and other related products, you can consult the sources listed here.
I I I I I I
Command Reference for Ambit BuildGates Synthesis and Cadence PKS Ambit BuildGates User Guide Timing Analysis for Ambit BuildGates Synthesis and Cadence PKS HDL Modeling for Ambit BuildGates Synthesis Distributed Processing of Ambit BuildGates Synthesis Constraint Translator for Ambit BuildGates Synthesis and Cadence PKS
Depending on the product licenses your site has purchased, you could also have these documents.
I I
PKS User Guide Datapath Option of Ambit BuildGates Synthesis and Cadence PKS
7 Product Version 4.0.10
August 2001
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Preface
I
Low Power Option of Ambit BuildGates Synthesis and Cadence PKS
BuildGates synthesis is often used with other Cadence tools during various design ows. The following documents provide information about these tools and ows. Availability of these documents depends on the product licenses your site has purchased.
I I I
Cadence Timing Library Format Reference Cadence Pearl Timing Analyzer User Guide Cadence General Constraint Format Reference
The following books are helpful references.

I I
IEEE 1364 Verilog HDL LRM TCL Reference, Tcl and the Tk Toolkit , John K. Ousterhout, Addison-Wesley Publishing Company
Syntax Conventions
This section provides the Text Command Syntax used in this document.
Text Command Syntax

The list below describes the syntax conventions used for the Ambit BuildGates synthesis text interface commands. Important Command names and arguments are case sensitive. User-dened information is case sensitive for Verilog designs and, depending on the value specied for the global variable hdl_vhdl_case, may be case sensitive as well.
literal
Nonitalic words indicate keywords that you must enter literally. These keywords represent command or option names. Words in italics indicate user-dened arguments or information for which you must substitute a name or a value. Vertical bars (OR-bars) separate possible choices for a single argument.
argument
August 2001
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Preface Brackets denote optional arguments. When used with OR-bars, they enclose a list of choices from which you can choose one. Braces are used to indicate that a choice is required from the list of arguments separated by OR-bars. You must choose one from the list. { argument1 | argument2 | argument3 }
{ }
[ ]
{ }
Bold braces are used in Tcl commands to indicate that the braces must be typed in literally. Three dots (...) indicate that you can repeat the previous argument. If the three dots are used with brackets (that is, [argument ]...), you can specify zero or more arguments. If the three dots are used without brackets (argument...), you must specify at least one argument, but can specify more. The pound sign precedes comments in command les.
...
About the Graphical User Interface

This section describes the conventions used for the BuildGates synthesis graphical user interface (GUI) commands and describes how to use the menus and forms in the BuildGates synthesis software.
Using Menus
The GUI commands are located on menus at the top of the window. They can take one of three forms. CommandName CommandName A command name with no dots or arrow executes immediately. A command name with three dots displays a form for choosing options. A command name with a right arrow displays an additional menu with more commands. Multiple layers of menus and commands are presented in what are called command sequences, for example: File Import LEF. In this example, you go to the File menu, then the Import submenu, and, nally, the LEF command.
CommandName ->
August 2001
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Preface
Using Forms
A menu button that contains only three dots provides browsing capability. When you select the browse button, a list of choices appears. The Ok button executes the command and closes the form. The Cancel button cancels the command and closes the form. The Defaults button displays default values for options on the form. The Apply button executes the command but does not close the form. The Help button provides information about the command.
Ok Cancel Defaults
Apply
Help
August 2001
10
1
Introduction
The following topics are located in this chapter:
I I I
Test Synthesis Benets and Impact on page 11 Whats New? on page 12 Getting Started on page 13
Test Synthesis Benets and Impact

Test Synthesis:
I
Refers to a set of automated techniques that you can use during logic synthesis to integrate design-for-test (DFT) logic into your designs. Adds logic structures to your chip design. Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS refers to the test synthesis capabilities of the BuildGates synthesis tool, including automatic scan insertion.
I I
Benets:
I
The foundrys tester uses these logic structures to check the chip for manufacturing defects. The logic structures produced by test synthesis do not affect the function of the chip. Cadence test synthesis can improve the time-to-market for your product. Cadence test synthesis performs single-pass test synthesis, test synthesis is performed prior to and during optimization. Test synthesis can affect the area and timing of your design, depending on the DFT approach that you choose.
I I I
August 2001
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Introduction
I
The tool performs full-scan synthesis; that is, it replaces all registers in the design that pass DFT rules with scannable registers, by default. Full-scan test synthesis allows for efcient testing, and may be required for BIST techniques. The test synthesis tool handles VHDL and Verilog code equally. You can use the same test synthesis commands and the same command sequence for both VHDL and Verilog.
Impact:
I
Scan insertion is critical to many other DFT techniques, such as boundary scan and builtin self test (BIST), but it is a tedious task to perform manually. Automating the integration of DFT technology in the synthesis process reduces the problems associated with generating, applying, and analyzing test and debug data. The ability to trade off timing and area during logic synthesis lets you preserve your most critical design parameters.
Whats New?
The Cadence test synthesis tool incorporates the following new features in the 4.0 release:
I I I I I I I
Test synthesis of clocked-scan, clocked-LSSD or aux-clocked LSSD scan styles Scan insertion into a mapped netlist DFT rule checking in test mode Insertion of data lockup latches between user-specied compatible clock domains PKS ordering of scan chains PKS reordering of scan chain segments separated by data-lockup latches Multiple scan enables in single clock domain/multiple chains or multi-clock domain designs Shared scan data in with functional input ports Shared scan data out with functional output ports through insertion of a multiplexor Support for test mode, scan mode and scan data to pins of technology components or lower level module ports (hierarchical pins) Support for internal clock domain points as separate DFT scan chain domains
I I I
August 2001
I
Support for internal scan data and scan control pins.
Other Features of Cadence Test Synthesis

I I I I I I
Single-pass test synthesis Multiplexed ip-op scan style Top-down and bottom-up scan insertion Verilog designs and VHDL designs Multiple clock domains Multiple balanced scan chains
Unsupported Features
The following tools are not part of nor are they supported by the test synthesizer:
I
Automatic test pattern generation (ATPG), boundary scan, JTAG, or BIST.
Getting Started
To start using Cadence test synthesis immediately, use the command sequence shown in Figure 3-1 on page 27 (for top-down synthesis) or Figure 3-2 on page 30 (for bottom-up synthesis), and consult the Command Reference for Ambit BuildGates Synthesis and Cadence PKS . For information about special situations, see Chapter 3, Tips for Performing Test Synthesis. For a complete introduction to the Cadence test synthesis tool, you can begin by reading this document in its entirety. In addition, you can perform a sample test synthesis run with the Chapter 2, Test Synthesis Tutorial. When you are ready to start using Cadence test synthesis, use Figure 3-1 on page 27 or Figure 3-2 on page 30 as a guide to the correct sequence of commands.
August 2001
13
August 2001
14
2
Test Synthesis Tutorial
This chapter guides you through scan insertion in a top-down synthesis run. You perform test synthesis in a single run, as follows:
I I I I I I
Start the Synthesis Tool on page 15 Set Test Synthesis Assertions on page 16 Check DFT Assertions and Rule Violations on page 17 Set Timing Constraints and Optimize the Design on page 18 Connect the Scan Chains on page 19 View the Scan Chains on page 21
Start the Synthesis Tool

To start the BuildGates synthesis tool and initialize the design: 1. From a UNIX system prompt, copy the tutorial RTL les to your machine:
mkdir ~/testSyn cd ~/testSyn cp install_dir /examples/BuildScan/*.v .
Substitute the appropriate path to your installation directory for install_dir. The tutorial example is made up of a top level Verilog le, top.v, and three submodules, submod1.v, submod2.v, and bottom2.v. See Appendix A, Tutorial Source Files, for a listing of the source RTL. 2. Start the BuildGates synthesis tool:
ac_shell
After Ambit synthesis displays a copyright notice, it displays the ac_shell prompt, as follows:
ac_shell[1]>
August 2001
15
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial The number in brackets increments after each command that you enter. 3. Set the global variable to echo the BuildGates commands within the ac_shell and the log le:
set_global echo_commands true
4. Specify the target library: Read the target library prior to building the generic database. The technology library must be read prior to executing the check_dft_rules command so that the test synthesis tool can verify the available scan cells of the specied scan style in the technology library. These scan cells will be used by the technology mapper during optimization.
read_alf lca300k.alf set_global target_technology lca300kv
5. Read the RTL design into the synthesis database:

read_verilog "top.v submod1.v submod2.v bottom2.v"
6. Create a generic database:

do_build_generic -module top Specify the top level module: set_top_timing_module top set_current_module top
Note: The top module for timing assertions and DFT rule checking is set_top_timing_module. The top module for timing optimization and scan chain conguration, analysis and connection is set_current_module. By default, the current module is also the top module for timing and DFT purposes. See the Ambit BuildGates Synthesis User Guide for a more detailed explanation of these steps.
Set Test Synthesis Assertions

To set the test synthesis assertions that you need for mapping the design: 1. Set the scan selection style:
set_scan_style muxscan
Test synthesis supports muxscan, clocked_scan, clocked_LSSD, and aux_clocked_LSSD scan styles. In the absence of specifying a scan selection style, test synthesis will default to muxscan.
August 2001
16
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial 2. Set the global variable to suppress buffering of the scan mode signal (optional):
set_global dft_scan_avoid_control_buffering true
This optional command prevents buffering of the high fanout scan control signal after it is inserted. By default, timing optimization and design rule xing buffer high fanout signals. This command overrides the default behavior for the scan mode signal only. 3. Set the global variable for specifying the scan chain connection mode (recommended):
set_global dft_scan_path_connect tieback
This command sets the scan mode for later connection to tieback. The tieback mode connects the scan cells scan-data output pin back to its own scan-data input pin. Cadence recommends that you set the scan mode to tieback before optimization. You set the dft_scan_path_connect global variable to chain later, when the scan chain is created and connected. For more information, see When to Use Tieback Mode and Chain Mode on page 31. 4. Specify the name of the input port to activate scan mode (optional):
set_scan_mode scan_enable 1
If the specied scan mode port is not dened in the input port list of the current_module, the test synthesis tool will create an input port named scan_enable to activate the shifting of the scan-data through the scan chain. If you use set_scan_mode to dene the scan mode signal, then you must also specify the polarity of this signal to activate the scan shift process; an active high is designated by a 1, and an active low is designated by a 0. In the absence of specifying the set_scan mode command, the test synthesis tool will create a top level port named BG_scan_enable with an active high (1) polarity. For more information, refer to Setting Test Synthesis Assertions and Using Test Synthesis Commands on page 48. The recommended sequence of the various test synthesis assertions is described in Figure 3-1 on page 27 and Figure 3-2 on page 30.
Check DFT Assertions and Rule Violations

To check the generic database for DFT rule violations and to verify the test synthesis assertions applied to the database: 1. Display the current test synthesis assertions (optional):
report_dft_assertions -module top
This command shows you the test synthesis assertions that are in effect.
August 2001
17
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial 2. Check for combinational loops and race conditions in your design (optional):
set_global dft_enable_combinational_loop_check true set_global dft_enable_race_condition_check true
When you set the dft_enable_combinational_loop_check global variable to true, Cadence Test Synthesis process tool checks for combinational feedback loops. When you set the dft_enable_race_condition_check global variable to true, Envisia test synthesis checks for any ip-ops with potential race conditions between the data and clock signal. 3. Check for DFT rules violations:
check_dft_rules
This command checks for DFT rules violations, such as uncontrollable clocks and uncontrollable asynchronous signals. The tool does not insert scannable elements where DFT violations occur. It prints a message if it detects any violations. You should x all reported problems in your RTL. Otherwise, your fault coverage is reduced. The check_dft_rules command will create a report summary listing the top level clocks, their internal clock domain and the number of registers associated with those domains that have passed the DFT rules checks. 4. Report the scannable and non-scannable registers in the design hierarchy:
report_dft_registers -scan report_dft_registers -non_scan
The report_dft_registers commands will report the total number of registers in the design, which have either passed or violated the design for test rule checks, as a hierarchical refererence.
Set Timing Constraints and Optimize the Design

To set your timing constraints and optimize the design: 1. Set timing constraints, as needed. For information on setting timing constraints, see Timing Analysis for Ambit BuildGates Synthesis and Cadence PKS . 2. Perform generic optimizations, technology mapping, connect the scan registers, and perform timing optimization:
do_optimize
Based on the results of the DFT rule check, the test synthesis tool determines the scan status of registers and to which clock domain the scan registers belong. In addition, the
August 2001
18
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial tool adds a scan mode port (tieback and chain mode), and it adds pairs of scan-data in and scan-data out ports (chain mode only), if required. The test synthesis tool maps the design registers to scan registers and connects the scan chains as specied by the global variable dft_scan_path_connect. Because you had set dft_scan_path_connect to tieback, the tool connects the scan-data output pin of each scan register back to its own scan-data input pin.
Connect the Scan Chains

To set up for scan connection the following assertions are needed to specify the scan domain architecture:
I I I
The number of and/or maximum length of the scan chains The compatible clock domains for data lockup latch analysis and/or insertion The scan-data input/output pairs optionally use the -shared_out option
This can be done as follows: 1. Set the global variable for specifying the scan chain connection mode (required):
set_global dft_scan_path_connect chain
Chain mode connects the scan registers into a single scan chain per clock domain (default). Setting this global variable to chain overrides the previous setting of tieback. However, this command does not actually connect the scan chains; scan chains are connected when you run the do_xform_connect_scan command. Multiple scan chains can also be specied by setting the set_number_of_scan_chains or set_max_scan_chain_length command prior to running do_xform_connect_scan. 2. Specify the desired number of scan chains (optional):
set_number_of_scan_chains 3
This command instructs the test synthesis tool to create three scan chains. 3. Allow data lockup latch insertion between compatible clock domains:
set_dft_compatible_clock_domain clk1 -rise clk2 -rise
By default, the test synthesis tool will create one scan chain for each clock domain. The set_dft_compatible_clock_domain command species domain and phase compatibility between the top level clock domains. This command is to be specied prior
August 2001
19
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial to running the scan connection engine in chain mode. It instructs the scan connection engine to create a scan chain(s) in which a data lockup latch(es) is (are) inserted between the scan chain segments clocked by clk1 and the scan chain segments clocked by clk2 in a single scan chain. 4. Specify the names of the input and output ports (or hierarchical pins) for the scan-data (optional):
set_scan_data {idata[0]} {odata[0]} -shared_out set_scan_data {idata[1]} {odata[1]} -shared_out set_scan_data {idata[2]} {odata[2]} -shared_out
Each scan chain needs its own input and output port. This command allows you to name the ports and associate them with a specic clock domain. The scan_data input port can be a dedicated port for scan in purposes only, or it can be a shared functional input port. The scan-data output port can be a dedicated port for scan out purposes only, or it can be a shared functional output port. Use the -shared_out option if the scan-data output port is also a shared output port. This instructs the test synthesis tool to insert a multiplexor to select between the internal scan-data output (from the last register in the scan chain) and the internal functional output signal; the output of the multiplexor being the scan-data output port specied in the set_scan_data command. The multiplexors are instantiated into the design database at the level of hierarchy specied by the set_current_module pointer. In this example: a. idata[2], idata[1], idata[0] will be the scan-data input ports for the three scan chains. b. odata[2], odata[1], odata[0] will be the shared functional output ports for the three scan chains. c. the three multiplexors will be instantiated as leaf cells within the top level module. If you do not use the set_scan_data command, the test synthesis tool creates pairs of scan-data in and scan-data out ports with the default base names of BG_scan_in and BG_scan_out. Each additional scan chain will be have the base names appended with _2, _3 .... _n for as many scan chains as are being congured in the database. 5. Connect the scan chains and name the scan chain order les:
do_xform_connect_scan -scan_file top.scan
The test synthesis tool connects the scan registers into three scan chains and creates two scan chain order les in the run directory, named top.scan and top.scan.flat. If you do not specify a name for the scan chain order les, both les have the same name as the top level module; one has an extension of .scan, and one has the extension of .scan.flat.
August 2001 20 Product Version 4.0.10
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial In this example, two scan chains have been created for registers clocked by the clk1 domain. The third scan chain is a single scan chain comprising two scan chain segments clocked by the clk1 and clk2 domains, respectively, with a data lockup latch between the domain crossings. The data lockup latch is denoted by llatch bitNumber hierReference in the scan chain order les. 6. Write the output les and exit the Ambit BuildGates synthesis tool:
write_verilog top.scan.vm
Note: This command returns a warning because the tool has added continuous assignment statements to your design to represent the internal register output to internal scan-data output signal assignments in the design. This warning does not indicate a problem at this time.
write_adb top.scan.adb quit
View the Scan Chains

The tutorial example contains three scan chains, because the assertion set_number_of_scan_chains is set to 3. There are ten registers on each scan chain, as shown in Figure 2-1 on page 21. Figure 2-1 Scan Chain Linkage
top idata[2] submod1 submod2
bottom2 odata[2]
idata[1] idata[0]
odata[1]
odata[0]
You can examine the scan chains in a text le or in the schematic viewer.
August 2001
21
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial
Viewing the Scan Chain Text Files

To view the hierarchical scan chain report le, enter the following command:
more top.scan
The hierarchical scan chain report le is organized by module, listing the chain connections visible at each level of hierarchy, see Appendix, Tutorial Source Files. on page 137. To view the at scan chain report le, enter the following command:
more top.scan.flat
The at scan chain report le is organized by scan chain, listing all the bits on each scan chain in the order of connection, see Appendix, Tutorial Source Files. on page 137.
Viewing the Scan Chain in the Schematic Viewer

To view the scan chains with the schematic viewer: 1. Start the Ambit synthesis GUI, as follows:
ac_shell -gui
2. Read the target library and your designs Ambit synthesis database (.adb) le into the synthesis database:
read_alf lca300k.alf read_adb top.scan.adb
The GUI displays the design hierarchy in the Modules tab. 3. Double-click on the top module to see the schematic diagram of the design in the Schematic tab. 4. Display the scan chains for the top module, as follows:
display_scan_chains [get_names [get_current_module]]
The GUI highlights the scan chains in the design, as shown in Figure 2-2 on page 23.
August 2001
22
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial Figure 2-2 Schematic Viewer
For more information on using the GUI, see the Ambit BuildGates Synthesis User Guide .
August 2001
23
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Synthesis Tutorial
August 2001
24
3
Tips for Performing Test Synthesis
This chapter describes the following tips for performing test synthesis:
I I I I I
Requirements for Test Synthesis on page 25 Recommended Command Flows on page 26 Avoiding DFT Rule Violations on page 39 Handling Non-Scannable Design Elements on page 46 Setting Test Synthesis Assertions and Using Test Synthesis Commands on page 48
Requirements for Test Synthesis

Before you begin test synthesis, you should be sure that you can satisfy the following requirements for the test synthesis tool and for your ASIC vendors:
I
Cadence Test Synthesis tool requirements:
You should avoid DFT (Design for Test) rule violations on ip-ops that you want to include in the scan chain. You can safely ignore DFT rule violations on ip-ops that you do not want to include in the scan chain. The input database [in Verilog or VHDL (VHSIC Hardware Description Language) format] can be comprised of RTL (Register Transfer Language), structural netlist (mapped to D ip-ops or MuxD scan ip-ops), or mixed RTL and structural netlist.
ASIC vendors requirements:

Scan styles supported by the ASIC (Application Specic IC) library Number of clocks allowed in test mode Maximum number of test vectors allowed Maximum number of scan chains allowed Maximum allowable scan chain length
August 2001
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta

Maximum number of scan bits allowed Whether the ATPG (Automatic Test Pattern Generator) tool allows inversions on the scan-data path Whether the ATPG tool allows multiple clocks and mixed-edge single clocks in capture mode If either bidirectional chip pins or internal buses are used in your design, any tester or ATPG-related cautions or restrictions, especially with regard to scan mode operation can be used. (See Bus conicts and oating conditions on page 44.)
Recommended Command Flows

In this section the recommended command ows pertaining to BuildGates Test Synthesis is described. Refer to PKS Ordering of Scan Chains on page 117 for recommended command ows using BuildGates Test Synthesis with PKS. You can perform test synthesis in either a top-down or a bottom-up test synthesis ow. Regardless of the approach you choose, you perform the following basic steps: 1. Optimize and map the design in tieback mode. 2. Connect the scan chains in chain mode after optimization is complete.
Top-Down Test Synthesis Flow

The top-down test synthesis ow maps an entire RTL design to scan registers and creates scan chains in a single synthesis run. The selection of test synthesis commands depends on whether you are performing optimization in tieback mode or connecting the scan chains following optimization. Figure 3-1 on page 27 shows the order in which you specify the test synthesis commands relative to the hierarchy and timing commands.
August 2001
26
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis Figure 3-1 Top-Down Test Synthesis Flow
Read Libraries, Design Data No test synthesis commands needed set_global dft_scan_path_connect tieback set_global dft_scan_avoid_control_buffering true (optional) set_scan_style set_scan_mode (optional)(recommended) set_dont_scan (design-dependent) set_must_scan (design-dependent) set_dont_touch_scan (design-dependent) set_test_mode_setup (design-dependent) set_dft_internal_clock_domain (design-dependent) report_dft_assertions (optional)
Set Test Synthesis Assertions
Report DFT Assertions
Check DFT Rule Violations
check_dft_rules
Report Scan Registers
report_dft_registers (optional)
Set Timing and Other Constraints
No test synthesis commands needed
Optimize and Map Design
do_optimize set_global dft_scan_path_connect chain set_scan_data (optional)(recommended) set_number_of_scan_chains (optional) set_max_scan_chain_length (optional) set_dft_compatible_clock_domain (optional)
Set Scan Chain Assertions
Connect Scan Chains
do_xform_connect_scan
Report Scan Chain Information
get_scan_chain_info
Fix Timing Violations Design completely synthesized
No test synthesis commands needed
August 2001
27
Bottom-Up Test Synthesis Flow

The bottom-up test synthesis ow consists of multiple synthesis iterations before the nal top level synthesis. You can perform test insertion on a synthesis database that is made up of RTL and optimized netlists. An optimized netlist consists of one or more lower level modules in a design that have already undergone test synthesis containing scan register instances that have been inserted in either tieback mode or chain mode. When you perform test synthesis on a database comprised of RTL and optimized netlists, you have the following options:
I
You can synthesize the entire database in chain mode and recongure the scan chains in the optimized netlist. You do not need to make any additional test synthesis assertions to identify scan enable, scan-data in, or scan-data out ports for the lower level optimized modules. You can synthesize the entire database in tieback mode and thus disconnecting the scan chains in the optimized netlist. You do not need to make any additional test synthesis assertions to identify scan enable, scan-data in ports, or scan-data out ports for the lower level optimized modules. You can synthesize the entire database in tieback mode without reprocessing the scan chains in the lower level modules. However, you need to make test synthesis assertions, using either of the following methods:
Use the set_dont_touch_scan command to set the dont-touch attribute on the precompiled lower level modules. This prevents the test synthesis tool from modifying the scan connections within those modules when it congures the scan chains in the rest of the design. You must also use the following command to prevent constant propagation from removing the scan-data output port and to let scan chain connection proceed without error:
set_port_property -boundary_optimization false [find -ports HierPathToModuleInstance /scanDataOutputPort ]
The scan-data output port is a oating net. If you do not use the set_port_property command, the synthesis tool treats it as an unconnected pin in the context of the entire chip and subject to removal by constant propagation.
Use the set_dont_modify command to set the dont-modify attribute on the precompiled lower level modules. This prevents the test synthesis tool from modifying the scan connections and the scan logic within those modules when it congures the scan chains in the rest of the design. This attribute also prevents timing-driven optimization from making any changes to the netlist.
August 2001
28
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis When optimization is complete, you can congure the top level scan chains in chain mode by specifying the set_number_of_scan_chains and set_max_scan_chain_length test assertions. The test synthesis tool preserves the scan chains that have the dont-touch or the dont-modify attributes and incorporates them into the top level chains by connecting them to the scan-data in and scan-data out ports that are dened at the module level. Figure 3-2 on page 30 shows the order in which you specify the test synthesis commands.
August 2001
29
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta Figure 3-2 Bottom-Up Test Synthesis Commands
Start synthesis set_global dft_scan_path_connect tieback set_global dft_scan_avoid_control_buffering true (optional) set_scan_style (see options available) set_scan_mode (optional) set_dont_scan (design-dependent) set_test_mode_setup (design-dependent) set_dft_internal_clock_domain (design-dependent) report_dft_assertions (optional) check_dft_rules report_dft_registers (optional) do_optimize No test synthesis commands needed
Mapping synthesis runs: Hierarchy changes Set test synthesis assertions Check DFT rules Set timing constraints Optimize and map to scan cells
Fix timing violations
Yes More modules to map?
No
Final synthesis run: Set scan chain assertions Connect scan chain
set_global dft_scan_path_connect chain set_global dft_scan_avoid_control_buffering true (optional) set_scan_mode (optional)(recommended) set_scan_data (optional)(recommended) set_number_of_scan_chains (optional) set_max_scan_chain_length (optional) set_dft_compatible_clock_domain (optional) do_xform_connect_scan No test synthesis commands needed
Fix timing violations
Design completely synthesized
August 2001
30
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis As with top-down synthesis, the selection of test synthesis commands depends on whether you are performing optimization or connecting the scan chains after optimization.
When to Use Tieback Mode and Chain Mode

In tieback mode, the test synthesis tool connects the scan registers scan-data output pin to its own scan-data input pin. In chain mode. the test synthesis tool connects the scan-data output pin from one register to the scan-data input pin of the next register in the chain. You select the mode by setting the dft_scan_path_connect global variable to either tieback or chain. When you run the do_optimize command, the following steps are performed by the synthesis engine: 1. generic optimization 2. technology mapping to scan equivalent registers (for all registers which pass the DFT rule checks) 3. scan register connection as per the dft_scan_path_connect global variable. 4. globally route the scan mode signal (if applicable) 5. timing-driven optimization Cadence recommends that you perform your initial synthesis in tieback mode using BuildGates or during pre-placement optimization (do_optimize -pks -stop_before_placement) with PKS. The tieback mode speeds up synthesis due to the fact that chain path connections are not being considered.. After you have optimized the design in tieback mode, you can change the dft_scan_path_connect global variable to chain. Later, when you run the do_xform_connect_scan command, the test synthesis tool disconnects any existing scan chains or connections and reconnects the scan registers in chain mode. Whenever you use either the do_optimize or do_xform_connect_scan command, the test synthesis tool disconnects the existing scan chains not attributed with a set_dont_touch_scan or dont_modify property and any tieback mode connections. The test synthesis tool then reconnects the scan registers as specied by the dft_scan_path_connect global variable. To create scan chains of equal length, create the scan chains after you have optimized all of the modules in your design to tieback mode. You create the equal-length scan chains by
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta specifying top level test assertions such as set_number_of_scan_chains or set_max_scan_chain_length and then performing a nal synthesis run in chain mode.
Using ADB Files from Prior Test Synthesis Runs

The test synthesis attributes and DFT rule checking data are saved to the ADB (Ambit Database) le(s).The test synthesis attributes and DFT rule checking data will be preserved and used by the test synthesis tool, if the database being restored is complete, i.e., there are no existing designs loaded in shell memory. In this scenario, additional test synthesis commands need only be specied if the user would like to change the state of the circuit from a test synthesis perspective. Important Restoring ADB les generated prior to v4.0-s008, is not recommended. If you must restore an ADB le, then the scan data assertions must be reset and respecied, and the scan mode signal must be respecied prior to running any subsequent test synthesis commands as shown below:
ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> read_adb oldVersion.adb set_top_timing_module set_current_module # reset and respecify the set_scan_data commands: reset_scan_data set_scan_data # respecify the set_scan_mode command: set_scan_mode # rerun the test design rule checks check_dft_rules ;# recommended
Example 1: Restored ADB in tieback mode. Specify test synthesis commands to congure the database in chain mode: 1. Read the technology library:
read_alf
2. Read the design database:

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis
read_adb tiebackMode.adb
3. Specify the top level modules:

set_top_timing_module set_current_module
4. Specify the test synthesis commands:

set_global dft_scan_path_connect chain set_scan_data (optional) set_max_scan_chain_length | set_number_of_scan_chains (optional)
5. Congure and connect the scan chains:

Example 2: Restored ADB in chain mode. Specify the test synthesis commands to recongure the scan chains in chain mode (change the number of chains or chain lengths): 1. 1. Read the technology library:
read_alf
2. Read the design database:

read_adb chainMode.adb
3. Specify the top level modules:


set_scan_data (optional) set_max_scan_chain_length | set_number_of_scan_chains
5. Recongure and connect the scan chains:

Note: In the event that conicting DFT rule check data is identied in the database after the ADB has been restored in the shell, the tool will issue the following message: WARNING: DFT rule-check data is being reset. You must re-run check_dft_rules to perform scan-synthesis <DFT-309>. This indicates that the DFT rule checking data has been invalidated by the test synthesis tool. The user must re-run the DFT rule checks with respect to the top level module, by issuing the check_dft_rules commands.
August 2001
33
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta Note: The test synthesis tool converts/remaps any non-scan ip-ops which pass the DFT rules checks into scan equivalent ip-ops when the do_xform_connect_scan scan connection engine is run. Note: If you are using PKS, this re-mapping step is only performed prior to placement. If multiple ADB les are being restored into the shell, the user must specify the test assertions with respect to the top level module, and run the DFT rule checks. In this scenario, the user has already performed test synthesis of the lower level modules as described in the bottomup test synthesis ow. An example ow is: Restored ADBs of lower level modules in tieback or chain mode. Specify the top level test synthesis commands to congure the scan chains in chain mode. Note: Module lower3 will be attributed with a set_dont_touch_scan property. 1. Read the technology library:
read_alf
2. Read in the design databases and link to technology library:

read_adb lower1_tieback.adb read_adb lower2_tieback.adb read_adb lower3_chain.adb read_verilog top.v do_build_generic
3. Specify the top level modules

4. Specify the top level test synthesis commands:

set_scan_style set_scan_mode set_test_mode_setup (design dependent)
5. Check the design for DFT rule violations and report the scannable/non-scannable register counts:
check_dft_rules report_dft_registers

set_global dft_scan_avoid_control_buffering true (optional) set_global dft_scan_path_connect chain
August 2001
34
set_scan_data (optional) set_dont_touch_scan lower3 (design dependent) set_max_scan_chain_length | set_number_of_scan_chains do_xform_connect_scan
Using Gate-Level Netlist Files from Prior Test Synthesis Runs

Test synthesis attributes and DFT rule checking data are not saved to the gate-level netlist. Therefore, the setup commands must be re-specied in order to continue with test synthesis. Setup commands include set_scan_mode, set_test_mode, set_scan_data (ow dependent), and set_dont_scan commands. Important For all scan styles including clocked_scan, clocked_lssd, and aux_clocked_lssd, the appropriate test synthesis commands specic to each of these scan styles must be respecied after the netlist has been read into ac_shell. For more information refer to section, Handling of Different Scan Styles on page 53. In addition, if multiplexors have been synthesized into the netlist in support of shared scan data output signals, the control signal to the mulitplexor must be respecied using the set_scan_mode command. Note: The ows outlined below are specic to the BuildGates test synthesis product. Recommended ows for gate-level netlists using PKS reordering will be addressed in section PKS Ordering of Scan Chains on page 117. Example 1: Restored Verilog Structural Netlist in tieback mode. Specify test synthesis commands to congure the database in chain mode. 1. Read the technology library:
read_alf
2. Read the gate-level netlist:

read_verilog tiebackMode.vm do_build_generic
3. Specify the top level module pointers:

August 2001
35
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta 4. Specify the test synthesis commands:
set_scan_style set_scan_mode set_test_mode_setup (design-dependent) set_dont_scan (design-dependent)
5. Run the design for test rule checks, and report the non-scannable registers:
check_dft_rules report_dft_registers -non_scan

set_global dft_scan_avoid_control_buffering true (optional) set_global dft_scan_path_connect chain set_scan_data (optional) set_max_scan_chain_length | set_number_of_scan_chains (optional) do_xform_connect_scan
7. Proceed with slack optimization:

do_xform_optmize_slack
Example 2: Restored Verilog Structural Netlist in chain mode. Specify the test synthesis commands to recongure (change the number of chains or chain lengths) in chain mode. 1. Read the technology library:
read_alf
2. Read the verilog netlist:

read_verilog chainMode.vm do_build_generic


set_scan_style set_scan_mode set_test_mode_setup (design-dependent) set_dont_scan (design-dependent)
5. Run the design for test rule checks, and report the non-scannable registers
check_dft_rules report_dft_registers -non_scan
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis 6. Generate a scan order le for the initial scan chain conguration (optional): Prerequisite commands: set_scan_mode, set_global dft_scan_path_connect chain, check_dft_rules
write_scan_order_file -flat initialSOfile
7. Recongure and connect the scan chains:

set_global dft_scan_avoid_control_buffering true (optional) set_global dft_scan_path_connect chain set_scan_data (optional) set_max_scan_chain_length | set_number_of_scan_chains (optional) do_xform_connect_scan
8. Write a new scan order le

write_scan_order_file -flat newSOfile

do_xform_optimize_slack
Example 3: Restored Verilog Structural Netlists compiled in both tieback and chain mode. Specify the test synthesis commands to congure the top level scan chains in chain mode. Note: Module lower3, will be attributed with a set_dont_touch_scan property, prior to running the scan connection function. 1. Read the technology library:
read_alf
2. Read in the gate-level netlists and link to technology library:

read_verilog lower1_tieback.vm read_verilog lower2_tieback.vm read_verilog lower3_chain.vm read_verilog top.v do_build_generic

4. Specify the top level test synthesis commands:

set_scan_style set_scan_mode set_test_mode_setup (design dependent)
August 2001
37
set_dont_scan (design dependent)
5. Check the design for DFT rule violations and report the scannable/non-scannable register counts:
check_dft_rules report_dft_registers

set_global dft_scan_avoid_control_buffering true (optional) set_global dft_scan_path_connect chain set_scan_data (optional) set_dont_touch_scan lower3 (design dependent) set_max_scan_chain_length | set_number_of_scan_chains do_xform_connect_scan
7. Write the scan order le

write_scan_order_file -flat SOfile

do_xform_optimize_slack
Understanding the Impact of Test Synthesis on the Design Database

Test synthesis of the design database can lead to setup timing violations. These violations may be caused by:
I
The extra incremental delay of the multiplexor in the datapath imposed by the muxscan style. If your timing constraints are not met along a critical path, you can exclude a register from scan chain with the set_dont_scan command. However, excluding a register(s) from the scan chain may reduce your fault coverage. The extra load on the registers output pin due to scan data output connection. To decrease the load on the registers output pin, move the scan data output connection to the least loaded Q or Q output pin. This is done by setting the dft_scan_output_pref global variable to min_load prior to running the scan chain connection engine. If your ATPG tool or ASIC vendor does not allow inversions in the scan chain, then set the dft_scan_allow_path_inv global variable to false prior to running the scan chain connection engine. See Controlling the Scan Chain Conguration on page 102.
Note: The scan chain connection engine is run by do_optimize command if the DFT rule checks, check_dft_rules, has been previously run on the database or if the do_xform_connect_scan command has been run directly.
August 2001
38
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis By default, test synthesis will globally route the scan mode (scan enable) signal when the dft_scan_path_connect global variable is set to either tieback or chain. To prevent both timing optimization and design rule xing from adding buffers along the high-fanout scan mode path, set the dft_scan_avoid_control_buffering global variable to true prior to running the scan connection engine. This has the affect of attributing a set_dont_modify property on the scan mode network. The user can also opt to tieoff or float the scan mode signal at the pins of the scan registers by setting the dft_scan_enable_connect global variable to tieoff or floating respectively, prior to running the scan connection engine. However, when the scan chains are going to be congured (created), you must set the dft_scan_enable_connect global variable to on prior to running the scan connection engine. Both approaches, described above, are recommended if an external tool, such as CTPKS or CTGEN, will be used to buffer the scan mode network.
Avoiding DFT Rule Violations

The check_dft_rules command checks your design for selected DFT rule violations. Any registers that violate DFT rules are marked for exclusion from the scan chain. If a design contains DFT violations, your ATPG tool may not be able to generate test patterns with high fault coverage. The test synthesis tool does not x DFT violations. However, it does report all violations, and it will let you override some of them by specifying a test mode signal. (See Overriding the Declarations of DFT Rule Violations on page 44.) Important Flip-ops which pass the DFT rule checks are replaced with their scan-equivalent ip-ops and placed on the scan chains. Flip-ops which fail the DFT rule checks are implicitly marked as dont_scan ip-ops and are not placed on the scan chains. To achieve the best possible fault coverage, you should attempt to x as many DFT rule violations in order to maximize the number of ip-ops which can be scan replaced. If necessary, you may need to modify your RTL to x any remaining DFT rule violations. The test synthesis tool detects the following DFT rule violations:
I
Combinational feedback loops Combinational feedback loops violate ATPG tool assumptions by giving a time dependency to the combinational logic. While combinational feedback loops do not affect
August 2001
39
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta your test synthesis results, they do affect your ATPG results because they decrease your designs fault coverage. To check for combinational loops, set the dft_enable_combinational_loop_check global variable to true. Next run the check_dft_rules command.
DFT Violation: Combinational Feedback Loop
If combinational loops are detected, you should modify the RTL to eliminate them. The use of test mode signals to break a combinational loop is not supported the test synthesis tool.
I
Race conditions The test synthesis tool can detect any ip-ops with potential race conditions. To check for race conditions, set the dft_enable_race_condition_check global variable to true. Next, run the check_dft_rules command.
DFT Violation: Race Condition A Clk D Q Clk A Clk D Q I ?
Uncontrollable asynchronous signals Asynchronous signals, such as preset and clear inputs to ip-ops, must be disabled (held to their inactive-state) during the scan shift cycle of the test process. See Test Process on page 141. The preset or clear signals must be directly controllable from a primary input or disabled through the use of a test mode signal. Depending upon how the preset and clear control logic has been implemented, the test mode signal may be used directly or may provide a direct control from a primary input in test mode. To specify
August 2001
40
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis a test mode signal, set the set_test_mode_setup -scan_shift command before running check_dft_rules.
DFT Violation: Uncontrollable Asynchronous Signal
async_reset I
Gated-clock and derived-clock violations In the muxed-scan style, clocks must be controllable from a primary input, so that the tester can control the clock pins of the ip-ops during the test process. See Test Process on page 141. In the clocked-scan and clocked-LSSD scan styles, the functional clocks must be disabled during test mode. If the clock pins to the ip-ops are gated, or internally derived, controllability of the internal nets connected to the clock pins of the ipops can be achieved by using a test mode signal. The test mode signal is used to bypass the gating logic or internal clock domains. To specify a test mode signal, set the set_test_mode_setup command before running check_dft_rules.
DFT Violation: Gated Clock clock
DFT Violation: Derived Clock
derived clock
int_clk
August 2001
41
I
Registers clock port connected to tied lines A register whose clock port is tied to an uncontrollable line (such as VDD or VSS) cannot function as a shift register. Therefore, the test synthesis tool does not automatically include the register in the scan chain.
DFT Violation: Registers Clock Port Connected to Tied Lines set
reset I
Multiple sequential control function violations In scan mode, the ATPG tool must be able to simultaneously trigger all registers on a scan chain and inactivate asynchronous signals from a primary input. Figure 3-3 on page 43 explains the situations in which multiple sequential control functions yield a DFT rule violation. The test synthesis tool checks for these situations when you run the check_dft_rules command. The tool displays a message if it detects any of these situations, and it includes those registers that are in the scan chain.
August 2001
42
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis Figure 3-3 Multiple Sequential Controls and DFT Violations
Designs with multiple sequential control DFT violation? If design is unchanged, is the scan chain valid?
No
Primary input
Maybe The test synthesis tool places rising-edge ip-ops on one scan chain and falling-edge ip-ops on a different scan chain. Check whether your ATPG tool can handle this situation.
set reset Primary input
No
Yes The tester can inactivate both asynchronous controls during scan mode.
set reset Primary input
Yes
No When the tester inactivates one asynchronous control, it activates the other. Therefore, a scan chain with both of these registers would not pass out valid scan data.
Yes reset
No When the tester triggers the clock, it also activates the asynchronous reset. A scan chain with an active asynchronous reset does not pass out valid scan data.
Primary input I
Clocks feeding the data path ATPG tools require a signal to be either a clock signal or a data signal. Therefore, it may be a DFT rule violation if your design has a clock signal feeding into a combinational datapath. The test synthesis tool does not check for this violation since this condition does not affect the scan operation. The test synthesis tool adds the affected ip-ops to the scan chains, which may decrease the designs fault coverage.
August 2001
43
DFT Violation: Clocks Feeding the Data Path
clock
Bus conicts and oating conditions You must ensure that tri-state buses have only one active driver in scan mode. Because of the shifting of data through the scan chain, multiple drivers might be simultaneously active in scan mode, even if they are not simultaneously active in system mode. A solution to this DFT violation is to disable all but one driver during scan mode. The ATPG tool usually ensures that only one driver is active in capture mode. Therefore, this solution needs to be active only in scan mode, not throughout test mode.
DFT Violation: Bus Conflicts and Floating Conditions scan_in 11 This bus does not have a conict in system mode. However, this bus can have a conict in scan mode because a value of 11 can get shifted through the registers.
scan_out Solution
scan_mode
Overriding the Declarations of DFT Rule Violations

The check_dft_rules command checks your design for selected DFT rule violations. Any registers found to violate DFT rules are marked for exclusion from the scan chain. For example, the test synthesis tool currently does not recognize the use of a test mode signal to
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis disable asynchronous resets or gated clocks during test mode. Therefore, check_dft_rules marks any registers controlled by gated clocks or asynchronous signals for exclusion from the scan chain. You may override the DFT violation designation of any register with the command set_test_mode_setup. In Figure 3-4 on page 45, there is no DFT rule violation associated with register r1, because clk1 is directly controllable. However, there is a DFT violation associated with r2 and r3, because clk2 is connected to a combinational gate. To override this DFT violation, use the set_test_mode_setup command to set the test_mode signal to 1. This forces the clock signal to pass through the gate. For example:
set_test_mode_setup test_mode 1
There is also a DFT rule violation associated with r4, because it is controlled by an internal gate. You can use set_test_mode_setup to inactivate asynchronous control during the scan-shift cycle of test mode, as follows:
set_test_mode_setup -scan_shift reset_L 1
Figure 3-4 Overriding the Designation of DFT Rule Violation

top_mod clk1
r1
sub_mod r2 clk2 enable test_mode gclk clk3 r3
r4 reset_L enable_L
Finding the RTL Code Causing DFT Rule Violations

Error messages generated by check_dft_rules specify the RTL le name and the line number (if possible) responsible for generating the DFT rule violation. The tool can highlight the RTL code responsible for detected DFT violations in the HDL and Schematic windows.
To highlight the source of an error in the RTL displayed in the HDL window, press Shift and triple-click on the error message in the console. You can edit the RTL code directly in the window, and resynthesize the design. To highlight the source of an error in the Schematics window, triple-click on the error message.
August 2001
45
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta For example, triple-clicking the error message as shown in Figure 3-5 on page 46, highlights the source of the error in the Schematics window. Figure 3-5 Highlighting the Source of a DFT Violation
The highlighting (in red) indicates that the declaration of gatedclk is the source of the selected error message.
Handling Non-Scannable Design Elements

RAMs, ROMs, and latches are ordinarily excluded from scan chains. However, the following sections describe how you can increase the fault coverage of designs that contain these design elements.
August 2001
46
RAMs and ROMs

ATPG tools often cannot generate vectors to test RAMs and ROMs. Therefore, to allow the scan chain generated during test synthesis to bypass the RAMs or ROMs, you can insert ipops (shadow registers) around the RAM or ROM input and output ports. Alternate approaches for testing RAMs include BIST and holding the RAM in write-through mode during scan testing by using a test mode signal.
Latches
The multiplexed ip-op scan style does not map latches to scannable registers. (The test cannot control non-scannable latches.) Therefore, if you are using the multiplexed ip-op scan style, you should make latches transparent in test mode. Making a latch transparent, however, could have the side effect of creating a combinational feedback loop, which is a DFT violation. Therefore, in addition to making latches transparent, you must ensure that the outputs of latches that feed combinational logic do not feed back into the latch. This is shown in Figure 3-6 on page 48.
August 2001
47
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta Figure 3-6 Making a Latch Transparent
Latch
latch
enable
Solution: Prevent Feedback
latch test_mode enable
Setting Test Synthesis Assertions and Using Test Synthesis Commands

The test synthesis assertions are used by specic test synthesis commands. When to specify and use these assertions is ow dependent. The test synthesis commands that are used are specic to a module reference in the design hierarchy. When to specify the test synthesis assertions and their usage by the test synthesis commands is outlined below:
I
Test Assertions which are specied prior to and used by the DFT rule checks are:
August 2001
48
Command
check_dft_rules
Scope
set_top_timing_module
Assertions
set_global dft_enable_combinational_ loop_check set_global dft_enable_race_condition_ check set_scan_style set_dont_scan set_must_scan set_dft_internal_clock_ domain set_dft_transparent set_test_mode_setup
Test Assertions which are specied prior to and used by the scan chain connection engine for scan chain analysis, conguration and connection are:
Command
do_xform_connect_scan do_optimize(FN1)
Scope
set_current_module
Assertions
set_global dft_scan_path_connect set_global dft_scan_enable_connect set_global dft_scan_avoid_control_ buffering set_global dft_scan_output_pref set_global dft_allow_scan_path_inv set_scan_mode set_scan_data set_dont_touch_scan set_dft_compatible_clock_ domain set_number_of_scan_chains set_max_scan_chain_length
August 2001
49
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tips for Performing Test Synthesis - Beta FN1 The scan connection engine is run by do_optimize if the DFT rule checks, using check_dft_rules, have been previously run on the database.
I
When to use the test synthesis commands in a ow, and their usage within the design hierarchy (scope), is as follows:
Command
check_dft_rules
Used after command(s)

do_build_generic
Scope
set_top_timing_ module set_top_timing_ module set_current_module
Database
RTL (generic database),mixed RTL and gates RTL (generic database), mixed RTL and gates RTL (generic database), mixed RTL and gates gates (chain mode only) gates (chain mode only) gates (chain mode only) gates (chain mode only)
report_dft_ registers do_xform_connect_ scan write_scan_order_ file
check_dft_rules
check_dft_rules do_xform_map
do_xform_connect_ scan do_optimize (FN2) read_scan_order_ N/A (Not file applicable) do_remove_scan_ do_xform_connect_ order_data scan do_optimize (FN2) get_scan_chain_info do_xform_connect_ scan do_optimize (FN2) do_place do_xform_connect_ -scan_reorder scan do_optimize -pks -stop (FN2)
set_current_module
set_current_module set_current_module
set_current_module
set_top_timing_modu gates (chain mode le only)
FN2 The scan connection engine is run by do_optimize if the DFT rule checks, using check_dft_rules, have been previously run on the database.
I
The test synthesis tool propagates all assertions to lower levels of hierarchy. You can override any propagated assertions, except set_number_of_scan_chains and set_max_scan_chain_length, by setting the assertion at a lower level. The set_number_of_scan_chains and set_max_scan_chain_length assertions are stored as global settings at the level of the top timing module. If you perform test synthesis at a lower level of the design hierarchy (i.e., you have specied set_current_module at a module other than the top timing module), these global settings are still in effect.
August 2001
50
I
You can re-specify or remove most of the test assertions specied. Where applicable, the default values of the assertions are also noted:
Set Assertion
set_scan_style set_dont_scan set_must_scan set_dft_internal_ clock_domain
Remove Assertion
<respecify> reset_dont_scan reset_must_scan
Default
muxscan N/A N/A
Scope
set_top_tming_ module set_top_timing_ module set_top_timing_ module set_top_timing_ module set_top_timing_ module set_top_timing_ module set_current_module
reset_dft_internal_ N/A clock_domain N/A N/A
set_dft_transparent reset_dft_ transparent set_test_mode_setup reset_test_mode_ setup set_global dft_scan_path_ connect set_global dft_scan_enable_ connect set_global dft_scan_avoid_ control_buffering set_scan_mode set_scan_data <respecify>
chain
<respecify>
on
set_current_module
<respecify>
false
set_current_module
<respecify> reset_scan_data
BG_scan_enable BG_scan_in/out N/A N/A
set_current_module set_current_module set_current_module set_current_module
set_dont_touch_scan reset_dont_touch_ scan set_dft_compatible_ reset_dft_ clock_domain compatible_clock_ domain set_number_of_scan_ <respecify> chains set_max_scan_chain_ <respecify> length
*FN3 *FN3
set_current_module set_current_module
*FN3 By default, the scan connection engine will create a single scan chain per clock domain; where the clock
August 2001
51
domains are identied from having run the DFT rule checks, check_dft_rules. I
The test synthesis tool saves assertions and constraints when you save the design ADB le, including test-mode setup. You do not need to reset your assertions and constraints when you read an ADB le into the synthesis database. For more information, refer to Using ADB Files from Prior Test Synthesis Runs on page 32.
You should set different test assertions based on whether the test synthesis tool is performing the design for test rule checks, and/or optimizing the database and connecting the scan chains. For an outline of the different sets of test synthesis assertions, see Figure 3-1 on page 27 and Figure 3-2 on page 30.
August 2001
52
4
Using Test Synthesis Commands
This chapter describes the following tips for performing test synthesis:
I I I I I I I I I
Handling of Different Scan Styles on page 53 Specifying Multiple Scan Mode Signals and set_scan_data on page 60 Specifying Shared Scan-in and Scan-out Ports on page 65 Specifying Internal Scan Mode, Scan Data, and Test Mode Ports or Pins on page 68 Specifying an Internal Clock Domain as a Separate DFT Clock Domain on page 76 General Notes Regarding Internal Ports and Pins on page 83 Insertion of Data Lockup Latches in the Multiplexed Scan Style on page 85 Multiple Clocks in Test Synthesis on page 95 Analysis of Data Lockup Latches in an Existing Scan Chain on page 97
Handling of Different Scan Styles

The following types of scan styles and scan ip-ops can be handled:
I I I I I I I
Multiplexed Scan Style Description on page 54 Multiplexed Scan Style on page 54 Clocked-Scan Style on page 55 Clocked-LSSD Scan Style on page 56 Auxiliary Clocked-LSSD Scan Style on page 58 Special Scan Flip-Flop for Alcatel on page 59 Single Latch LSSD or Double Latch LSSD Scan Flip-Flops Not Handled on page 59
August 2001
53
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands
Multiplexed Scan Style Description

The multiplexed ip-op scan style is the most commonly used scan style. (See Figure 4-1 on page 54.) In the multiplexed ip-op scan style, the test synthesis tool performs as follows:
I
It replaces ip-ops with scannable ip-ops. A scannable ip-op has a multiplexer placed before a ip-op. The multiplexer selects between system data and scan data. It adds a scan-mode port to control scannable ip-op multiplexers. It adds dedicated scan-in and scan-out ports for the scan data.
I I
Figure 4-1 The Multiplexed Flip-Flop Scan Style

Without Scan Insertion Data_in Data_out
D Q Clock With Scan Insertion Data_i
D Q
D Q
Data_out
Scan_in
D Q
D Q
D Q
Scan_out
Scan_mode Clock
Multiplexed Scan Style

In Multiplexed (muxscan) Scan Style a multiplexer is used to select between System Data input (under system mode) and Scan Input (under scan-shift mode). The Scan Control signal Scan Enable is used as the select_control signal for the multiplexer. See Figure 4-2 on page 55.
August 2001
54
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-2 Multiplexed Scan Flip-Flop
Scan Enable System Data Scan In
0 1
System Data System Clock
D CLK
System Out
D
CLK
System Out/Scan Out
System Clock
Regular D-Flip-Flop
Multiplexer Scan Flip-Flop
Table 4-1 Truth TableMultiplexed Scan Style System Data System Mode System Mode Scan Shift Mode Scan Shift Mode Either 0 1 X X X Scan In X X 0 1 X Scan Enable 0 0 1 1 X 0 System Clock System Out/ Scan Out 0 1 0 1 Q
Relevant Command for Multiplexed Scan Style

set_scan_style muxscan set_scan_mode <ScanModePortorPinName> <Value>
Clocked-Scan Style
Clocked-Scan Style ip-op has two clock input ports, System Clock and Scan Clock. During system mode, Scan Clock is held inactive while System Clock is used to capture data at System Data Input port.Similary, in Scan Shift Mode, the System Clock is held inactive and Scan Clock is used to shift data in from Scan Input port. See Figure 4-3 on page 56. See Table 4-2 on page 56
August 2001
55
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-3 Clock-Scan Cell
System Out/ Scan Out
System Data
D System Clock Scan In Scan Clock
Table 4-2 Truth Table Clocked-Scan Clock D System Mode System Mode Scan Shift Mode Scan Shift Mode Either 0 1 X X X Scan In X X 0 1 X 0 0 0 0 System Clock Scan Clock 0 0 System Out/ Scan Out 0 1 0 1 Q
Relevant Commands
set_scan_style clocked_scan set_test_scan_clock <TopLevelPortClockedScanClockName>
Clocked-LSSD Scan Style

In clocked-LSSD (Level Sensitive Scan Design) Scan Style, a regular edge-triggered D-ipop is replaced by a clocked-LSSD scan cell that has one edge-triggered System Clock input and two level-sensitive scan clocks, Scan Clock A and Scan Clock B. In the system mode, the two level-sensitive scan clocks remain inactive while the System Clock is pulsed to capture the data at the System Input. In the Scan-Shift mode, the System Clock is held inactive and Scan Clock A and Scan Clock B are pulsed sequentially to shift the data at the Scan Input. See Figure 4-4 on page 57. See Table 4-3 on page 57
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-4 Clocked-LSSD Scan Cell
Q SYSTEM OUT SCAN OUT
SYSTEM DATA SYSTEM CLOCK Q
D1 CLOCK1 D2 CLOCK2
D1 CLOCK1 SCAN IN SCAN CLOCK A D2 CLOCK2
SCAN CLOCK B
Table 4-3 Truth Table Clocked-LSSD System Data System Mode System Mode Scan Shift Mode Scan Shift Mode Either 0 1 X X X 0 0 X System Clock Scan In X X 0 1 0 0 Scan Clock A 0 0 Scan Clock B 0 0 System Out/ Scan Out 0 1
* *
0
* *
0 1 Q
* Pulse on Scan Clock A preceeds the pulse on Scan Clock B. Relevant Commands for Clocked-LSSD Style
set_scan_style clocked_lssd set_lssd_scan_clock_a <TopLevelPortLSSDScanClockAName> set_lssd_scan_clock_b <TopLevelPortLSSDScanClockBName>
August 2001
57
Auxiliary Clocked-LSSD Scan Style

In the Auxilary Clocked-LSSD Scan Style, an edge-triggered ip-op is replaced by Auxiliary Clocked-LSSD Scan Cell. The scan cell has 3 level sensitive scan clocks Aux_Test_Clock, Scan_Clock A and Scan_Clock B, and one edge-triggered system clock. In System Mode, all three scan clocks are held inactive and System Clock is pulsed to capture data at the System Input. In Scan Shift Mode, aux test clock is held high and Scan Clock A and Scan Clock B are pulsed sequentially to shift scan-data from Scan-Input to the Scan-Output. The data at System Input can be captured by pulsing either the System Clock (with Aux-Test Clock held low) or by pulsing the aux-test-clock (with System Clock held low). See Table 4-4 on page 58. See Figure 4-5 on page 59. Table 4-4 Truth TableAuxiliary Clocked-LSSD Scan Style System Clock Aux Test Scan Clock Scan Clock Clock A B 0 0 0 0 0 0 0 0 0 System Out/Scan Out 0 1 0
System In System Mode System Mode Test Mode (Capture System Data) Test Mode (Capture System Data) Scan Shift Mode Scan Shift Mode 0 1 0
Scan In X X X
X X
0 1
X X
1 1
0 1
August 2001
58
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-5 Auxiliary Clocked-LSSD Scan Cell
System In System Clock Aux Test Clock Scan In Scan Clock A
Data 1 Clock 1 Data 2 Clock 2
Data 1
System Out/ Scan Out
Clock 1
Scan Clock B
Relevant Commands for Auxillary Clocked-LSSD Style

set_scan_style aux_clocked_lssd set_lssd_scan_clock_a <TopLevelPortLSSDScanClockAName> set_lssd_scan_clock_b <TopLevelPortLSSDScanClockBName> set_lssd_auxiliary_clock <TopLevelPortLSSDAuxTestClockName>
Special Scan Flip-Flop for Alcatel

The special scan ip-op for Alcatel has been modeled using the auxiliary clocked-lssd scan style. See Auxiliary Clocked-LSSD Scan Style on page 58 for more details.
Single Latch LSSD or Double Latch LSSD Scan Flip-Flops Not Handled
Important The tool will not handle Single Latch LSSD or Double Latch LSSD scan ip-ops, since the tool does not map latches onto scan ip-ops. Only edge-triggered ipops are converted into scan ip-ops.
August 2001
59
Specifying Multiple Scan Mode Signals and set_scan_data

The specication of multiple scan mode signals in a single domain/multi-chain or multidomain/multi-chain design database is supported by test synthesis. The scan mode signals are specied by associating them to the scan-data input and output signals using the set_scan_data command. The enhanced format of this command is as follows:
set_scan_data {scanDataInput } {scanDataOutput } \ [-enable scanMode ] \ [-clock clockName ] \ [-shared_out]
If you specify a scan mode signal, that signal will be used to connect the scan enable pin of the scan registers in that chain between the associated scan-data input and scan-data output signals. If the clock option is specied along with the scan mode and scan-data input and output signals, the scan mode signal will be used to connect the scan enable pins of the scan registers in the specied clock domain between the associated scan-data input and scandata output signals. Important Test synthesis will honor the command provided the user has NOT additionally specied domain merging into a single scan chain using the set_dft_compatible_clock_domain command. If this command is specied, the scan-data input and scan-data output signals associated to the scan chain is determined by the domain of the rst register in the scan chain. Important The polarity of the scan mode signal is specied using the set_scan_mode command. This command must be specied in addition to the set_scan_data command. Additionally, the set_scan_mode command has been enhanced with a default option. This option is used to specify the default scan mode signal to be used for all scan chains congured in the database which have not been associated to specic scan-data input, scan-data output and scan mode signals. If the default option is not specied, the scan mode signal specied by the rst set_scan_mode command becomes the default signal name. In the absence of specifying a scan mode signal, test synthesis will create a top level port, named BG_scan_enable, with an active high polarity.
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands It is recommended that you specify as many set_scan_data commands as scan chains to be congured in the design database. If there are more scan chains congured than set_scan_data pairs specied, the test synthesis tool will create scan-data input and scandata output ports using the default names BG_scan_in and BG_scan_out. The default names BG_scan_in and BG_scan_out are used as base names to create successive scan chains by appending the sufxes _2, _3 and so on as needed. These port names will be randomly assigned to the scan chains. However, the scan mode signal associated to these scan chains will be the signal name specied by the rst use of the set_scan_mode command or the scan mode signal specied using the -default option of the set_scan_mode command. Also note that the scan chains associated to the default BG_scan_in and BG_scan_out ports will use the default scan mode signal, irrespective of the clock domain polarity at the registers. Important The specication of the set_scan_data commands is not considered by the conguration algorithm in determining the number of scan chains to be created for each clock domain. For more details regaring scan chain conguration and specifying set_scan_data -clock. See Naming Scan-Data Ports on page 103. Note: The -shared_out option is explained further in Specifying Shared Scan-in and Scan-out Ports on page 65. Refer to the following examples: Example 1: Single domain/multi-chain.
set_number_of_scan_chains 2 set_scan_mode sen1 1 set_scan_mode sen2 1 set_scan_data -clock clk sdi1 sdo1 -enable sen1 set_scan_data -clock clk sdi2 sdo2 -enable sen2
In this example, the test synthesis tool will create 2 scan chains: chain 1 and chain 2. In chain 1, the registers triggered by the rising or falling edge of domain clk, will be associated to the scan mode signal sen1 and scan-data ports: sdi1 and sdo1. In chain 2, the registers triggered by the rising or falling edge of domain clk, will be associated to the scan mode signal sen2 and scan-data ports: sdi2 and sdo2. Example 2: Single domain multi-edge/multi-chain.
set_number_of_scan_chains 4 set_scan_mode sen1 1
August 2001
61
set_scan_mode sen2 1 set_scan_data -clock clk sdi sdo -enable sen1 set_scan_data -clock clk -fall sdiF sdoF -enable sen2
In this example, the test synthesis tool will create 4 scan chains: two scan chains will be created in the clock rising-edge domain and two scan chains created in the clk fallingedge domain. However, since only two set_scan_data commands were specied, two scan chains will be created using default scan-data input and scan-data output ports. Chain 1: the registers triggered by the rising edge of domain clk will be associated to the scan mode signal sen1 and scan-data ports sdi and sdo. Chain 2: the registers triggered by the falling edge of domain clock will be associated to the scan mode signal sen2 and scan-data ports sdiF and sdoF. Chain 3: the registers triggered by the rising edge of domain clk will be associated to the scan mode signal sen1 and scan-data ports BG_scan_in and BG_scan_out. Chain 4: the registers triggered by the falling edge of domain clk will be associated to the scan mode signal sen1 and scan-data ports BG_scan_in_2 and BG_scan_out_2. Important The scan mode signal sen1 is the default scan mode signal, specied by the rst use of the set_scan_mode command. Example 3: Single domain multi-edge/multi-chain example:
set_number_of_scan_chains 4 set_scan_mode sen1 1 set_scan_mode sen2 1 -default set_scan_data -clock clk sdi sdo -enable sen1 set_scan_data -clock clk -fall sdiF sdoF -enable sen2
In this example, the test synthesis tool will create 4 scan chains: two scan chains will be created in the clk rising-edge domain and two scan chains created in the clk fallingedge domain. However, since only two set_scan_data commands were specied, two scan chains will be created using the default BG_scan_in and BG_scan_out ports. Chain 1: the registers triggered by the rising edge of domain clk, will be associated to the scan mode signal sen1 and scan-data ports sdi and sdo. Chain 2: the registers triggered by the falling edge of domain clk, will be associated to the scan mode signal sen2 and scan-data ports sdiF and sdoF.
August 2001
62
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Chain 3: the registers triggered by the rising edge of domain clk, will be associated to the scan mode signal sen2 and scan-data ports BG_scan_in and BG_scan_out. Chain 4: the registers triggered by the falling edge of domain clk, will be associated to the scan mode signal sen2 and scan-data ports BG_scan_in_2 and BG_scan_out_2. Important Scan mode signal sen2 is the default scan mode signal, specied using the -default option in second set_scan_mode command. Example 4: Single domain,multi-edge/multi-chain example:
set_number_of_scan_chains 4 set_scan_mode sen1 1 set_scan_mode sen2 1 set_scan_data -clock clk sdi1 sdo1 -enable set_scan_data -clock clk sdi2 sdo2 -enable set_scan_data -clock clk -fall sdi1F sdo1F set_scan_data -clock clk -fall sdi2F sdo2F
sen1 sen1 -enable sen2 -enable sen2
In this example, the test synthesis tool will create 4 scan chains; two scan chains will be created in the clk rising-edge domain and two scan chains created in the clk falling edge domain. Since four set_scan_data commands were specied, each scan chain will be fully associated to their own scan-data input, scan-data output and scan mode signals. Chain 1: the registers triggered by the rising edge of domain clk, will be associated to he scan mode signal sen1 and scan-data ports sdi1 and sdo1. Chain 2: the registers triggered by the rising edge of domain clk, will be associated to the scan mode signal sen1 and scan-data ports sdi2 and sdo2.. Chain 3: the registers triggered by the falling edge of domain clk, will be associated to the scan mode signal sen2 and scan-data ports sdi1F and sdo1F. Chain 4: the registers triggered by the falling edge of domain clk, will be associated to the scan mode signal sen2 and scan-data ports sdi2F and sdo2F. Example 5: Multi-domain/multi-chain example:
set_number_of_scan_chains 4 set_scan_mode sen1 1 set_scan_mode sen2 1 set_scan_data -clock clk1 sdiRc1 sdoRc1 -enable sen1 set_scan_data -clock clk2 sdiRc2 sdoRc2 -enable sen2
set_scan_data -clock clk1 -fall sdiFc1 sdoFc1 -enable sen1 set_scan_data -clock clk2 -fall sdiFc2 sdoFc2 -enable sen2
In this example, the test synthesis tool will create 4 scan chains; two scan chains will be created in the clk1 domain (both rising and falling edge domains), and two scan chains will be created in the clk2 domain (both rising and falling edge domains). Since four set_scan_data commands were specied, each scan chain will be fully associated to their own scan-data input, scan-data output and scan mode signals. Chain 1: the registers triggered by the rising-edge of domain clk1, will be associated to the scan mode signal sen1 and scan-data ports sdiRc1 and sdoRc1. Chain 2: the registers triggered by the falling edge of domain clk1, will be associated to the scan mode signal sen1, and scan-data ports sdiFc1 and sdoFc1. Chain 3: the registers triggered by the rising-edge of domain clk2, will be associated to the scan mode signal sen2, and scan-data ports sdiRc2, and sdoFc2. Chain 4: the registers triggered by the falling edge of domain clk2, will be associated to the scan mode signal sen2 and scan-data ports sdiFc2 and sdoFc2. Example 6: Multi-domain/single chains with data lockup latch insertion example:
set_scan_style muxscan set_scan_mode sen1 1 set_scan_mode sen2 1 set_scan_data -clock clk1 sdiRc1 sdoRc1 -enable sen1 set_scan_data -clock clk2 sdiRc2 sdoRc2 -enable sen2 set_scan_data -clock clk1 -fall sdiFc1 sdoFc1 -enable sen1 set_scan_data -clock clk2 -fall sdiFc2 sdoFc2 -enable sen2 set_dft_compatible_clock_domain clk1 -rise clk2 -rise set_dft_compatible_clock_domain clk1 -fall clk2 -fall
In this example, the test synthesis tool will create 2 scan chains since the user has specied clock domain merging using the set_dft_comptible_clock_domain commands. The test synthesis tool will insert data lockup latches between the scan chain segments. Chain 1: scan chain segment clocked by rising-edge of clk1 separated by a data lockup latch to a scan chain segment clocked by rising-edge of clk2. The scan chain will be associated to scan mode signal sen1 and scan-data ports sdiRc1 and sdoRc1. Chain 2: scan chain segment clocked by falling edge of clk1 separated by a data lockup latch to a scan chain segment clocked by falling edge of clk2. The scan chain will be associated to scan mode signal sen1 and scan-data ports sdiFc1 and sdoFc1.
August 2001
64
Important Scan mode signal sen1 is the default scan mode signal, specied using the rst set_scan_mode command.
Specifying Shared Scan-in and Scan-out Ports

The specication of shared scan-in and shared scan-out signals is supported by test synthesis. The term, shared scan-in, refers to the usage of a functional signal as the scandata input to the rst register in the scan chain. The term, shared scan-out, refers to the multiplexing of the scan-data output signal from the last register in the scan chain with the internal functional signal; where the select control signal to the multiplexor is the scan mode signal. The shared scan-in signal is specied directly as the scanDataInput argument to the set_scan_data command. The shared scan-out signal is specied as the scanDataOutput argument and declaring the -shared_out option to set_scan_data command. The enhanced format of this command is as follows:
set_scan_data {scanDataInput } {scanDataOutput } \ [-enable scanMode ] \ [-clock clockName ] \ [-shared_out]
When the functional logic is driving the specied functional port that is to be shared with scanout signal from the last scan ip-op in a chain, the synthesis tool will insert a 2-to-1 multiplexor, see Figure 4-6 on page 66. The output of the multiplexor drives the shared port, and the data inputs of the multiplexor are connected to the functional driver, and the scan-out signal. The select-control of the multiplexor is connected to the scan-enable signal for the scan chain, such that in scan-shift mode, the scan-out value appears on the shared port. The functional logic value appears on the shared port in non-scan-shift mode. Important If there is already a multiplexor instantiated between the shared port and functional driver the tool will be able to trace and identify the multiplexor based on its control pin and output pin connectivity, in most cases, and reuse the multiplexor for scanout connection. However, if the control pin of the multiplexor is not connected to the scan-enable signal or if the multiplexor function is implemented using multiple gates the tool may not be able to precisely analyze the logic and may add an additional multiplexor in front of the existing multiplexor logic. The additional multiplexor would be redundant but functionally correct in both scan-shift mode and functional mode will be used to control the select pin the multliplexor.
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-6 Insertion of a 2-to-1 Multiplexer
Functional Logic Functional port to be shared for scan_out
Before Scan Connection Scan In Scan ipop Scan Out
Scan Enable
Functional Logic
1 0 P
After Scan Connection
The following are examples of specifying shared scan-in and scan-out ports: Example 1: Single-domain, multi-edge/multi-chain example:
set_number_of_scan_chains 2 set_scan_mode sen1 1 set_scan_mode sen2 1 set_scan_data -clock clk {in1[0]} {out1[0]} -enable sen1 -shared_out set_scan_data -clock clk {in2[0]} {out2[0]} -enable sen2 -shared_out
In this example, the test synthesis tool will create 2 scan chains. Chain 1: The registers triggered by the rising edge (or falling edge) of domain clk, will be associated to the scan mode signal sen1 and scan-data ports {in1[0]} and {out1[0]}. A multiplexor will be added for shared out port out1[0] with the scan mode signal sen1 as the select control signal. Chain 2: The registers triggered by the rising edge (or falling edge) of domain clk, will be associated to the scan mode signal sen2 and scan-data ports {in2[0]}and {out2[0]}.
August 2001
66
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands A multiplexor will be added for the shared out port out2[0] with the scan mode signal sen2 as the select control signal. Example 2: Multi-domain/multi-chain example:
set_number_of_scan_chains set_scan_mode sen1 1 set_scan_mode sen2 1 set_scan_data -clock clk1 set_scan_data -clock clk2 set_scan_data -clock clk1 set_scan_data -clock clk2 4
{in1[0]} {out1[0]} -enable sen1 -shared_out {in2[0]} {out2[0]} -enable sen2 -shared_out -fall {in1[1]} {out1[1]} -enable sen1 -shared_out -fall {in2[1]} {out2[1]} -enable sen2 -shared_out
In this example, the test synthesis tool will create 4 scan chains: two scan chains will be created in the clk1 domain (both rising- and falling-edge domains), and two scan chains will be created in the clk2 domain (both rising- and falling-edge domains). Since four set_scan_data commands were specied, each scan chain will be fully associated to their own scan-data input, scan-data output and scan mode signals. Chain 1: the registers triggered by the rising edge of domain clk1 will be associated to the scan mode signal sen1 and scan-data ports {in1[0]} and {out1[0]}. A multiplexor will be added for the shared out port out1[0] with the scan mode signal sen1 as the select control signal. Chain 2: the registers triggered by the falling edge of domain clk1 will be associated to the scan mode signal sen1 and scan-data ports {in1[1]} and {out1[1]}. A multiplexor will be added for shared out port out1[1] with scan mode signal sen1 as the select control signal. Chain 3: the registers triggered by the rising edge of domain clk2 will be associated to the scan mode signal sen2 and scan-data ports {in2[0]} and {out2[0]}. A multiplexor will be added for shared out port out2[0] with scan mode signal sen2 as the select control signal. Chain 4: the registers triggered by the falling edge of domain clk2, will be associated to the scan mode signal sen2 and scan-data ports {in2[1]} and {out2[1]}. A multiplexor will be added for the shared out port out2[1] with the scan mode signal sen2 as the select control signal. Example 3: Multi-domain/multi-chain example:
set_number_of_scan_chains 4 set_scan_mode sen1 1 set_scan_mode sen2 1
August 2001
67
set_scan_data -clock clk1 {in1[0]} {out1[0]} -enable sen1 -shared_out set_scan_data -clock clk2 {in2[0]} {out2[0]} -enable sen2 -shared_out
In this example, the test synthesis tool will create 4 scan chains: two scan chains will be created in the clk1 domain (both rising- and falling-edge domains), and two scan chains will be created in the clk2 domain (both rising- and falling-edge domains). Since only two set_scan_data commands were specied, the test synthesis tool will create two additional scan chains using default BG_scan_in and BG_scan_out ports. The default scan mode signal sen1 will be used as the scan mode select for the registers in these chains. Chain 1: the registers triggered by the rising edge of domain clk1, will be associated to the scan mode signal sen1 and scan-data ports {in1[0]} and {out1[0]}. A multiplexor will be added for shared out port out1[0] with scan mode signal sen1 as the select control signal. Chain 2: the registers triggered by the falling edge of domain clk1 will be associated to the default scan mode signal sen1 and scan-data ports BG_scan_in and BG_scan_out. Chain 3: the registers triggered by the rising edge of domain clk2 will be associated to the scan mode signal sen2 and scan-data ports {in2[0]} and {out2[0]}. A multiplexor will be added for shared out port out2[0] with scan mode signal sen2 as the select control signal. Chain 4: the registers triggered by the falling edge of domain clk2 will be associated to the scan mode signal sen1 and scan-data ports BG_scan_out_2 and BG_scan_out_2.
Specifying Internal Scan Mode, Scan Data, and Test Mode Ports or Pins
This release of test synthesis supports the specication of the scan mode, and the scan-data signals to ports of lower level modules or internal pins of technology components in the design database with the following restriction: Important The hierarchical path to the internal port or pins is restricted to 1 level of design hierarchy below the module specied by the set_current_module pointer. Remember that the set_current_module pointer is the module reference in the design hierarchy from which the scan chain connection engine is run.
August 2001
68
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Additionally, the user must ensure that the internal pins specied for the scan mode, scandata or internal clock domain points do not get optimized away. If specifying these signals to pins of components (other than inferred registers), these components should rst be mapped to the technology library and then attributed with a set_dont_modify property. Or for better reliability, it is recommended to specify a hierarchical reference to ports of a lower level module. This is the preferred approach since optimization does not typically remove port declarations from the module hierarchy and optimization preserves the design hierarchy.
I
set_scan_mode:
specied to the input port of the top level module pointed to by the set_current_module pointer:
set_scan_mode <ScanModePort> <Value>
specied as a hierarchical reference to a lower level port or pin of a technology component (restricted to 1 level of design hierarchy below the module specied by the set_current_module pointer):
set_scan_mode <HierPathToLowerLevelPortorTechnologyPin> <Value>
If the internal scan mode port is a oating pin in the context of the hierarchical design (the lower level output port which generates the scan mode signal is NOT pin2signal mapped to the scan mode ports of modules undergoing test synthesis), then the scan mode port in the module which generates the scan mode signal must be attributed with a port property to prevent constant propagation from removing the logic generating this signal.This attribute must be specied prior to running optimization. It is specied using the following command:
set_port_property -boundary_optimization false [find -port \ <HierPathToModule/ScanModePort> ]
Refer to Example 1: on page 71 for more details. If the internal scan mode pin is a oating pin in the context of the hierarhical design (i.e., the technology component which generates the scan mode signal is NOT pin2 signal mapped to the scan mode ports of modules undergoing test synthesis), then the technology component must rst be mapped to the target library, and the component must be attributed with a set_dont_modify property to prevent constant propagation from removing the technology component. The property is specied using the following command:
set_dont_modify [find -instance \ <HierPathToTechnologyComponentInstance>]
Note: If the scan mode port for the module which generates the scan mode signal is pin2signal mapped to the scan mode ports of top level modules which will undergo test synthesis, then the set_port_property command is not necessary. In this scenario, the connectivity of the scan mode network will be traced and maintained by the
August 2001
69
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands scan connection engine provided that the user has not issued the -shared_out option to the set_scan_data command. If the -shared_out option is specied, the scan mode ports declared on the top level modules undergoing test synthesis will be replaced with the scan mode port declared using the set_scan_mode command. The new top level scan mode signal will inherit the port name specied in the scan mode command. This top level signal will then be pin2signalmapped to the select control pin of the multiplexors synthesized into the netlist in support of -shared_out option. For any modules instantiated as cell references in the top level modules undergoing test synthesis, if the scan mode port of the cell references have not been created and/or are not connected to the scan mode network, then the test synthesis tool will create a scan mode port for these cell references using the port name specied in the set_scan_mode command. This port (pin at the lower level modules) will then be pin2signal mapped to the scan mode port traced by the connection engine at the next highest level in design hierarchy. Refer to Example 2: on page 74 for more details.
I
set_scan_data:
specied to the input ports of the top level module pointed to by the set_current_module pointer set_scan_data <ScanDataInputPort> <ScanDataOutputPort> specied as a hierarchical reference to a lower level port or pin of a technology component (restricted to 1 level of design hierarchy below the module specied by the set_current_module pointer):
set_scan_data <HierPathToLowerLevelSDIPortorPin> \ <HierPathToLowerLevelSDOPortorPin>
set_test_mode_setup (test mode signals):
specied to the input port of the top level module:

set_test_mode_setup <TestModePort > <Value >
specied to the input port of a lower level module:

set_test_mode_setup -module <ModuleName >\ <TestModeInputPortOfLowerModule > <Value >
specied from the output port of a lower level module:

set_test_mode_setup -module <ModuleName >\ <TestModeOutputPortofLowerModule > <Value >
Note: The -module option to the set_scan_mode and set_scan_data commands has been obsoleted. This means that the user is no longer able to specify specic scanmode and scan-data ports to be used by the scan connection engine for lower level modules which will undergo test synthesis. The signal names specied in the set_scan_mode and set_scan_data commands are specied for the module in
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands design hierarchy that is pointed to by the set_current_module pointer. The scan-data ports created and used by the scan connection engine for all lower level modules will use the default BG_scan_in and BG_scan_out ports. Example 1: RTL description of a circuit creating internal scan mode and test mode signals. The scan-data input and output signals will be specied to pins of technology components one hierarhical level below the module pointed to by the set_current_module pointer. Since the internal scan mode signal IscanMode has NOT been pin2signal mapped from the jtag module to the top level modules a and b which will undergo test synthesis, the user must specify the set_port_property attribute on the u_jtag/scan_enable port prior to optimization The circuit will rst be optimized to scan ip-ops in tieback mode. Afterwards, the dft_scan_path_connect global variable will be specied to chain, and the scan connection engine will be run to create two scan chains.
module top (testclk, clk, scanEnableIn, en1, en2, in1, in2, testModeIn, out1, out2) input input output testclk, clk, scanEnableIn, en1, en2, testModeIn; in1, in2; out1, out2; SI0, SI1, SO0, SO1; Iout1, Iout2; IscanMode, ItestMode, ItestClk;
[3:0] [3:0]
wire wire [3:0] wire
// Output the functional output signals assign out1[3:1] = Iout1[3:1]; assign out2[3:1] = Iout2[3:1]; // Buffer the scan data signals from functional ports BUFXL buf_0 (.A(in1[0]), .Y(SI0)); BUFXL buf_1 (.A(in2[0]), .Y(SI1)); BUFXL buf_2 (.A(Iout1[0]), .Y(out1[0])); BUFXL buf_3 (.A(Iout2[0]), .Y(out2[0])); assign ItestClk = ItestMode ? testclk : clk; jtag u_jtag(.test_mode(testModeIn), .scan_enable_in(scanEnableIn),
August 2001
71
.en1(en1), .en2(en2), .scan_enable(IscanMode), .test_mode_out(ItestMode)); a u_a(.in(in1), .clk(ItestClk), .out(Iout1), .SI(SI0), .SO(SO0)); b u_b(.in(in2), .clk(ItestClk), .out(Iout2), .SI(SI1), .SO(SO1)); endmodule // top
An example script in TCL format for the above RTL code is: Read in the technology library
read_alf <technologyLibrary >.alf
Read in the RTL description and build the generic database

read_verilog top.v do_build_generic
Specify the top timing and current module pointers

set_top_timing_module top set_current_module top
Specify the test synthesis global variables

set_global dft_scan_path_connect tieback
Specify the test mode setup signal to multiplex to testClk (output from jtag module)
set_test_mode_setup -module jtag test_mode_out 1
Specify the hierarchical path to the scan mode signal (output from jtag module)
set_scan_mode u_jtag/scan_enable 1
Run the DFT rule checks

check_dft_rules
August 2001
72
Important To prevent the removal of the logic generating the internal scan mode signal, the lower level port of the module which generates this signal must be attributed with a port property. This is because the internal scan mode port is a oating pin in the context of the hierarchical design and subject to removal by constant propagation.
set_port_property -boundary_optimization false [find -port u_jtag/scan_enable]
Important Prevent constant propgation from removing the technology buffers whose output pins are oating. The buffers output and input pins will be specied as the internal scan-data pins. Connections will be made to these pins when the scan connection engine is run in chain mode.
set_dont_modify [find -instance -of_cell_type BUFXL]
Optimize the design to tieback mode

do_optimize
Specify the scan connection mode to chain

set_global dft_scan_path_connect chain
Specify the scan-data ports to internal pins of technology components

set_scan_data -module top buf_0/Y buf_2/A -shared_out set_scan_data -module top buf_1/Y buf_3/A -shared_out
These will be ignored by the scan connection engine

set_scan_data -module a SI SO set_scan_data -module b SI SO
Run the scan connection engine in chain mode

Save the netlist to disk

write_verilog top.vm quit
The resultant circuit after optimzation is:

Module top (testclk, clk, scanEnableIn, en1, en2, in1, in2, testModeIn, out1, out2); input testclk, clk, scanEnableIn, testModeIn, en1, en2;input [3:0] in1, in3; output [3:0] out1, out2;
Buffered scan-data input path:
August 2001
73
BUFXL buf_0(.A(in1[0]), .Y(SI0)); BUFXL buf_1(.A(in2[0]), .Y(SI1));
Multiplexor used to select between testclk and system clk:

MUX21SP i_01(.Z(ItestClk), .A(clk), .B(testclk), .S(n_47));
The jtag module which generates internal scan mode and test mode signals:
jtag u_jtag(.test_mode(testModeIn), .scan_enable_in(scanEnableIn), .en1(en1), .en2(en2), .scan_enable(scan_enable), .test_mode_out(n_47));
Modules a and b which have undergone test syntheis:

a u_a(.in(in1), .clk(ItestClk), .out({out1[3], out1[2], out1[1], n_62}), .SI(SI0), .scan_enable(scan_enable), .BG_scan_in(SI0), .BG_scan_out(n_63)); b u_b(.in(in2), .clk(ItestClk), .out({out2[3], out2[2], out2[1], n_68}), .SI(SI1), .scan_enable(scan_enable), .BG_scan_in(SI1), .BG_scan_out(n_69));
Multipexors added by test synthesis for -shared scan-out ports:

MUX21SP i_80(.Z(\Iout2[0] ), .A(n_68), .B(n_69), .S(scan_enable)); MUX21SP i_74(.Z(\Iout1[0] ), .A(n_62), .B(n_63), .S(scan_enable));
Buffered scan-data output path to primary output signals:

out1[0], out2[0] BUFXL buf_2(.A(\Iout1[0] ), .Y(out1[0])); BUFXL buf_3(.A(\Iout2[0] ), .Y(out2[0]));
Example 2: RTL description of a circuit creating internal scan mode and test mode signals. The scan-data input and output signals will be specied to pins of technology components one hierarhical level below the module pointed to by the set_current_module pointer. The internal scan mode signal IscanMode has been pin2signal mapped from the jtag module to the top level modules, a and b, which will undergo test synthesis. Since the internal scan mode signal IscanMode is pin2signal mapped, the set_port_property attribute is NOT necessary and can be commented out from the TCL script. Note: Since the user specied the -shared_out option to the set_scan_data command, the top level scan mode signal IscanMode in the original circuit has been replaced with the top level signal scan_enable. Additionally, the scan mode port se for modules a and b, in the original circuit, have been replaced with port, scan_enable, and pin2signal mapped to the top level scan mode signal, scan_enable, in the optimized netlist.
August 2001
74
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands The resultant circuit after optimization is identical to the circuit documented in Example 1.
module top (testclk, clk, scanEnableIn, en1, en2, in1, in2, testModeIn, out1, out2); input testclk, clk, scanEnableIn, en1, en2, testModeIn; input [3:0] in1, in2; output [3:0] out1, out2; wire SI0, SI1, SO0, SO1; wire [3:0] Iout1, Iout2; wire IscanMode, ItestMode, ItestClk;
Output the functional output signals

assign out1[3:1] = Iout1[3:1]; assign out2[3:1] = Iout2[3:1];
Buffer the scan-data signals from functional ports

BUFXL buf_0 (.A(in1[0]), .Y(SI0)); BUFXL buf_1 (.A(in2[0]), .Y(SI1)); BUFXL buf_2 (.A(Iout1[0]), .Y(out1[0])); BUFXL buf_3 (.A(Iout2[0]), .Y(out2[0])); assign ItestClk = ItestMode ? testclk : clk; jtag u_jtag(.test_mode(testModeIn), .scan_enable_in(scanEnableIn), .en1(en1), .en2(en2), .scan_enable(IscanMode), .test_mode_out(ItestMode)); a u_a(.in(in1), .clk(ItestClk), .out(Iout1), .se(IscanMode), .SI(SI0), .SO(SO0)); b u_b(.in(in2), .clk(ItestClk), .out(Iout2), .se(IscanMode), .SI(SI1), .SO(SO1)); endmodule // top
August 2001
75
Specifying an Internal Clock Domain as a Separate DFT Clock Domain

If there are different internal clock domains that are logically connected to the same top level clock in test mode, these internal clock domains can be identied as separate DFT clock domains for scan chain connection purposes. The motivation to do this is that different clock branches derived from the same logical clock source may have large differences in clock skew. Hence, intermixing ip-ops along different clock branches into the same scan chain can lead to reliability problems during scan-shift cycle of the test process. See Test Process on page 141. The following command, set_dft_internal_clock_domain, can be used to identify an internal clock domain point as a separate DFT clock domain:
set_dft_internal_clock_domain <HierObjectIDofModulePortorTechnologyPin >
The set_dft_internal_clock_domain must be specied prior to running the DFT rule checks, check_dft_rules. The DFT rule checks will use the internal clock domain points to separate the ip-ops along the clock branches into separate DFT clock domains, such that all ip-ops driven by the specied port or pin will be considered as separate clock domains for scan chain connection. See Figure 4-7 on page 76. Figure 4-7 Internal Clock Domain A1 A A2
Clock
B1 B
B2
Internal Clock Domain Points
Flip-ops A1 and A2, clocked by internal clock point A will be placed in a separate DFT clock domain and separate scan chain from ip-ops B1 and B2, clocked by internal clock point B. Note: The set_dft_internal_clock_domain command cannot be used to bypass the DFT rule check violations. In order for the ip-ops along the different clock branches to be
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands considered for scan chain connection, they must pass all the DFT rule checks. The clock pins to the registers must be driven and controllable from the top level clock port (primary input) under test mode. It is the top level clock, under test mode, which is reported by the DFT rule checks as the controlling clock domain. Example 1: RTL description of a circuit which buffers the top level clock, clk, into two separate clock branches, clk1A and clk1B. These clock branches will be identied as separate DFT clock domains by specifying the set_dft_internal_clock_domain command to the output pin of the buffers.
module top (in, clk, out); input clk; input [7:0] in; output [7:0] out; BUFX1 u1 (.A(clk), .Y(clk1A)); BUFX1 u2 (.A(clk), .Y(clk1B)); core u_core (.in(in), .clk1A(clk1A), .clk1B(clk1B), .out(out)); endmodule // top module core (in, clk1A, clk1B, out); input clk1A, clk1B; input [7:0] in; output [7:0] out; reg [7:0] out; always @(posedge clk1A) out[7:4] <= in[7:4]; always @(posedge clk1B) out[3:0] <= in[3:0]; endmodule
August 2001
77
read_alf <technologyLibrary>.alf


Specify the internal clock domain points

set_dft_internal_clock_domain [find -pin u1/Y] ;#clk1A set_dft_internal_clock_domain [find -pin u2/Y] ;#clk1B

check_dft_rules
Report the scannable registers relative to the internal DFT domains

report_dft_registers -scan
Important Prevent the buffers from being removed by area reclamation, place a set_dont_modify on the buffer instance prior to running optimization.
set_dont_modify [find -instance u1] ;# clk1A set_dont_modify [find -instance u2] ;# clk1B
The DFT rule check summary report is as follows: Info: Partitioning registers for scan based on clock domain. <DFT-325>. Clock Domain 0 from pin clk (Pos Edge) has 4 f/f Clock Domain 1 from pin clk (Pos Edge) has 4 f/f Total Clock domains: 2 for 8 f/f Info: Total Scannable register count: 8 <DFT-340>. Info: Design has no TDRC violation <DFT-343>. Note:
I
Registers driven by internal clock domain point clk1A: The DFT rule checks separated the registers into internal DFT domain 0: Clock Domain 0 from pin clk (Pos Edge) has 4 f/f
August 2001
78
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands The registers reported by the report_dft_registers -scan command is:
u_core/out_reg_7 u_core/out_reg_6 u_core/out_reg_5 u_core/out_reg_4 I -> -> -> -> [clock-domain [clock-domain [clock-domain [clock-domain 0] 0] 0] 0]
Registers driven by internal clock domain point clk1B: The DFT rule checks separated the registers into internal DFT domain 1: Clock domain 1 from pin clk (Pos Edge) has 4 f/f The registers reported by the report_dft_registers -scan command is:
u_core/out_reg0_3 u_core/out_reg0_2 u_core/out_reg0_1 u_core/out_reg0_0 -> -> -> -> [clock-domain [clock-domain [clock-domain [clock-domain 1] 1] 1] 1]
For the above example, if the user did not specify the set_dft_internal_clock_domain commands, then the top level clock level domain, clk, would be reported by DFT rule checks, and all 8 registers (4 registers clocked by clk1A, and 4 registers clocked by clk1B), would be placed in the same DFT domain for scan chain connection. The DFT rule check output for this scenario is: The DFT rule check summary report is as follows: Info: Partitioning registers for scan based on clock domain. <DFT-325>. Clock Domain 0 from pin clk. (Pos Edge) has 8 f/f Total Clock domains: 1 for 8 f/f Info: Total Scannable register count: 8 <DFT-340>. Info: Design has no TDRC violation <DFT-343>. The DFT rule checks placed all 8 registers into domain 0:
u_core/out_reg0_3 u_core/out_reg0_2 u_core/out_reg0_1 u_core/out_reg0_0 u_core/out_reg_7 u_core/out_reg_6 u_core/out_reg_5 -> -> -> -> -> -> -> [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain 0] 0] 0] 0] 0] 0] 0]
August 2001
79
u_core/out_reg_4 -> [clock-domain 0]
Example 2: RTL description of a circuit which multiplexes top level system clock domains clk and clk2 with the top level test clock domain tclk onto internal clock signals, mclk1, mclk2A and mclk2B. The multiplexed clock signal mclk1 originating from clk domain, and mclk2A and mclk2B are the multliplexed clock signals originating from clk2 domain. The mclk2A and mclk2B clock branches will be identied as separate DFT clock domains by specifying the set_dft_internal_clock_domain command to the mclk2A and mclk2B output ports of the clock module.
module top (in, tclk, clk, clk2, tm, out); input tclk, clk, tm, clk2; input [31:0] in; output [31:0] out; wire mclk1, mclk2A, mclk2B; clock u_clock (.tclk(tclk), .clk(clk), .clk2(clk2), .tm(tm), .mclk1(mclk1), .mclk2A(mclk2A), .mclk2B(mclk2B)); core u_core (.in(in), .mclk1(mclk1), .mclk2A(mclk2A), .mclk2B(mclk2B), .out(out)); endmodule // top module clock (tclk, clk, clk2, tm, mclk1, mclk2A, mclk2B); input tclk, clk, tm, clk2; output mclk1, mclk2A, mclk2B; wire mclk1, mclk2A, mclk2B;
assign mclk1 = tm ? tclk : clk; assign mclk2A = tm ? tclk : clk2; assign mclk2B = tm ? tclk : clk2; endmodule // clock module core (in, mclk1, mclk2A, mclk2B, out); input mclk1, mclk2A, mclk2B; input [31:0] in; output [31:0] out; reg [31:0] out;
always @(posedge mclk1) out[31:21] <= in[31:21]; always @(posedge mclk2A) out[20:8] <= in[20:8]; always @(negedge mclk2B) out[7:0] <= in[7:0]; endmodule // core
read_alf <technologyLibrary>.alf


Specify the test mode signal to allow multiplexing of top level clocks
set_test_mode_setup tm 1
tclk propagates forward as the DFT clock domain. Specify the internal clock domain points
set_dft_internal_clock_domain [find -pin u_clock/mclk2A] set_dft_internal_clock_domain [find -pin u_clock/mclk2B]

check_dft_rules
Report the scannable registers relative to the internal DFT domains

report_dft_registers -scan
August 2001
81
Important To prevent optimization from minimizing the muxed clock paths in the clock modules for signals mclk2A and mclk2B, map this block prior to optimization; otherwise, the mclk2B mux will be removed since it is considered redundant logic, and assign mclk2B = mclk2A.
do_push_module [find -module clock] do_xform_map do_pop_module set_dont_modify [find -module clock]
The DFT rule check summary report is as follows: Info: Partitioning registers for scan based on clock domain. <DFT-325>. Clock Domain 0 from pin tclk (Pos Edge) has 13 f/f Clock Domain 1 from pin tclk (Pos Edge) has 11 f/f Clock Domain 2 from pin tclk (Neg Edge) has 8 f/f Total Clock domains: 3 for 32 f/f Note: Registers driven by internal clock domain point mclk1: The DFT rule checks separated the registers into internal DFT domain 1: Clock Domain 1 from pin tclk (Pos Edge) has 11 f/f The registers reported by the report_dft_registers -scan command are:
u_core/out_reg_31 u_core/out_reg_30 u_core/out_reg_29 u_core/out_reg_28 u_core/out_reg_27 u_core/out_reg_26 u_core/out_reg_25 u_core/out_reg_24 u_core/out_reg_23 u_core/out_reg_22 u_core/out_reg_21 I -> -> -> -> -> -> -> -> -> -> -> [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain 1] 1] 1] 1] 1] 1] 1] 1] 1] 1] 1]
Registers driven by internal clock domain point mclk2A: The DFT rule checks separated the registers into internal DFT domain 0: Clock Domain 0 from pin tclk (Pos Edge) has 13 f/f
August 2001
82
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands The registers reported by the report_dft_registers -scan command is:
u_core/out_reg0_20 u_core/out_reg0_19 u_core/out_reg0_18 u_core/out_reg0_17 u_core/out_reg0_16 u_core/out_reg0_15 u_core/out_reg0_14 u_core/out_reg0_13 u_core/out_reg0_12 u_core/out_reg0_11 u_core/out_reg0_10 u_core/out_reg0_9 u_core/out_reg0_8 I -> -> -> -> -> -> -> -> -> -> -> -> -> [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain 0] 0] 0] 0] 0] 0] 0] 0] 0] 0] 0] 0] 0]
Registers driven by internal clock domain point mclk2B: The DFT rule checks separated the registers into internal DFT domain 2: Clock Domain 2 from pin tclk (Neg Edge) has 8 f/f The registers reported by the report_dft_registers -scan command is:
u_core/out_reg1_7 u_core/out_reg1_6 u_core/out_reg1_5 u_core/out_reg1_4 u_core/out_reg1_3 u_core/out_reg1_2 u_core/out_reg1_1 u_core/out_reg1_0 -> -> -> -> -> -> -> -> [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain [clock-domain 2] 2] 2] 2] 2] 2] 2] 2]
General Notes Regarding Internal Ports and Pins

Test synthesis supports the specication of scan mode and scan-data signals to ports of lower level modules or to internal pins of technology components in the design database with the following restriction: The hierarchical path to the internal port or pins is restricted to 1 level of design hierarchy below the module specied by the set_current_module pointer. Please remember that
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands the set_current_module pointer is the module reference in the design hierarchy from which the scan chain connection engine is run. When specifying a hierarchical path to an internally generated scan mode port, if the port is a oating pin in the context of the hierarchical design (i.e. the lower level output port which generates the scan mode signal is NOT pin2signal mapped to the scan mode ports of modules undergoing test synthesis), then the scan mode port must be attributed with a port property to prevent constant propagation from removing the logic generating this signal. This attribute must be specied prior to running optimization as outlined in the example TCL script in section Specifying Internal Scan Mode, Scan Data, and Test Mode Ports or Pins on page 68. The attribute is specied using the following command:
set_port_property -boundary_optimization false [find -port\ <HierPathToModule /ScanModePort >]
When specifying a hierarchical path to pins of technology components which are to be used as the internal scan-data input and output signals for scan chain connection, the technology components must be attributed with a set_dont_modify property to prevent their removal during the optimization process. This attribute must be specied prior to running optimization as outlined in the example TCL script in section Specifying Internal Scan Mode, Scan Data, and Test Mode Ports or Pins on page 68". The attribute is specied using the following command:
set_dont_modify [find -instance\ <HierPathToTechnologyComponentInstance >]
If a scan chains scan-data input pin and scan-data output pin is NOT specied by the user, and the pins are connected to pins of black box components (i.e., no function) in the scandata path, analysis of the scan chains to the top level scan-data input and scan-data output ports becomes blocked. As a result, commands which rely on analysis data, such as write_scan_order_file, and do_optimize -pks/do_xform_connect_scan -pks will not succeed. In this scenario, the test synthesis tool will print a WARNING message specifying the hierarchical pin to which analysis stopped; the WARNING message has the following syntax:
--> WARNING: Scan analysis backtrace stop at buf_0/Y pin in module top <DFT451>.
In order for the scan chain analysis routine to succeed, the user MUST specify the hierarchical paths to the internal scan-data input and scan-data output pins. If the user does not know as to the path specication to these pins, then for the scenario above, the hierarchical path to the internal scan-data input pin and the scan-data output pins can be specied relative to the output pin and input pin, respectively, of the black box component; where the hierarchical path is captured in the DFT-451 WARNING message. In summary, for any command where you are specifying an internal pin, you must ensure that the internal pin, such as scan mode, scan data, or internal clock domain points, do not get
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands optimized away. When specifying these signals to pins of components (other than inferred registers), these components should rst be mapped to the technology library and then attributed with a set_dont_modify property. For better reliability, it is recommended that you specify a hierarchical reference to ports of a lower level module. This is the preferred approach since optimization does not typically remove port declarations from the module hierarchy. Additionally, you may need to specify a set_dont_modify to the internal pins or ports so that they continue to exist through the optimization process.
Insertion of Data Lockup Latches in the Multiplexed Scan Style

Insertion of data lockup latch(es) into a design database is supported only for the multiplexed scan (muxscan) style of test insertion. Insertion of data lockup latches by the test synthesis tool refers to the insertion of latch(es) from the target technology library between the userspecied:
I I
Top level clock domains in a multi-clock domain design and/or Gated-clock branches of the same top level logical clock source.
Insertion of data lockup latches allows the user to reduce the number of scan chains congured in a multi-clock domain design. Additionally, insertion of data lockup latches between different gated-clock branches derived from the same logical clock source, is used to prevent capture problems during scan-shift cycle of the test mode due to clock skew variances between the different gated-clock branches. Without this capability, test synthesis would create a single scan chain for each top level clock domain and/or for each phase of a clock domain. The default handling of mulitple clock domains by test synthesis is further described in section Multiple Clocks in Test Synthesis on page 95. Insertion of data lockup latches is specied using the set_dft_compatible_clock_domain command. This command must be specied prior to running test synthesis in chain mode. The command instructs the scan connection engine to create a scan chain(s) in which a data lockup latch(es) is (are) inserted between the different user-specied top level clock domains in the same scan chain. The test synthesis tool will try to make the scan chains balanced according to the user constraints, and simultaneously try to minimize the number of data lockup latches inserted into the design database. If the top level commands set_number_of_scan_chains and/or set_max_scan_chain_length are also specied, test synthesis will determine how many scan chains will be allocated for each
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands compatible clock-domain group. If the number of different groups (G), exceeds the userspecied number of chains (N), then G number of scan chains will be created. The set_dft_compatible_clock_domain command species the top level compatible clock domains which can be merged into a single scan chain placing, data lockup latches between the domain-specic scan chain segments. The format of this command is as follows:
set_dft_compatible_clock_domain <list_of_clock_sources | -all | -sameclock > I
list_of_clock_sources: species the top level clock domains that are compatible and can be merged into a single scan chain. -sameclock: species that different phases (edges) of the same top level clock domain are compatible (including internal clock domains derived through gating logic from the same clock root) and can be merged into a single scan chain. -all: specifes that any two top level clock domains are compatible scan can be merged into a single scan chain.
When data lockup latches are inserted between scan chain segments from different clock domains and/or different edges of the same clock domain, the test synthesis tool creates the clock nets connected to the enable pin of the data lockup latches by inverting the phase of the clock signal associated to the registers belonging to the scan chain segment preceding the data lockup latch. Both the data lockup latches and the inverters for the clock nets are instantiated within the module hierarchy undergoing test synthesis, provided that the module has not been previously attributed with a set_dont_modify or set_dont_touch_scan property. If the above attributes exist, then the data lockup latches and the inverters for the clock nets will be instantiated at the next highest level of design hierarchy. Example 1:
set_dft_compatible_clock_domain clk1 -rise clk1 -fall
In the above example, the single scan chain may be ordered as follows: scan chain segment 1 -> registers (clk1 RE) data Lockup Latch -> enable pin (clk1 FE) scan chain segment 2 registers (clk1 FE)
Example 2:
set_dft_compatible_clock_domain clk1 -rise -clk3 -rise
August 2001
86
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands In the above example, the single scan chain may be ordered as follows:
scan chain segment 1 -> registers (clk1 RE)
data lockup latch -> enable pin (clk1 FE)
scan chain segment 2 registers (clk3 RE)
Note: The reset_dft_compatible_clock_domain command will reset all previous specications of the set_dft_compatible_clock_domain command. A subsequent run of the scan connection engine in chain mode will default to a single scan chain for each top level clock domain and/or for each phase of a clock domain. The default handling of mulitple clock domains by test synthesis is further described in section Multiple Clocks in Test Synthesis on page 95. Example 3: RTL description of a multi-clock domain, multi-phase circuit. This circuit will be used to illustrate how to specify the set_dft_compatible_clock_domain command in order to include data lockup latches in the design database.
module top (in, out, clk1, clk2, clk3); input [15:0] in; output [15:0] out; input clk1, clk2, clk3; reg [15:0] out; always @(posedge clk1) out[3:0] <= in[3:0]; always @(negedge clk1) out[7:4] <= in[7:4]; always @(posedge clk2) out[11:8] <= in[11:8]; always @(negedge clk3) out[15:12] <= in[15:12]; endmodule // top
Illustration 1: Specifying <list_of_clock_sources >

I
set_dft_compatible_clock_domain clk1
August 2001
87
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands The above command implicitly species that all phases of clk1 are compatible for domain merging. After the above command is specied, the following Info message is returned by the shell: Info: Compatible clock list set to: Clock clk1 rise/fall. After optimization has been run in chain mode, three top level scan chains will have been congured in the database as follows:
ac_shell> do_xform_connect_scan
Info: Connecting scan chains (mode = chain)... <DFT-026>. Info: Inserting a lockup latch instance i_132 to connect scan ip-ops out_reg1_11 and out_reg2_15 in a single chain <DFT-344>. Top level chain 1 (BG_scan_in -> BG_scan_out) has 8 registers <DFT-024>. Top level chain 2 (BG_scan_in_2 -> BG_scan_out_2) has 4 registers. <DFT-024>. Top level chain 3 (BG_scan_in_3 -> BG_scan_out_3) has 4 registers.<DFT-024>. Where: Top level chain1 is a single scan chain with a data lockup latch inserted between the scan chain segments clocked by clk1 rising-edge and clk1 falling-edge domains. Top level chain2: is a single scan chain clocked by clk2 rising-edge domain. Top level chain3: is a single scan chain clocked by clk3 falling-edge domain.
I
set_dft_compatible_clock_domain clk1 -fall clk3 -fall
The above command species that the clk1 falling and clk3 failling edges are compatible for domain merging. After the above command is specied, the following Info message is returned by the shell: Info: Compatible clock list set to: Clock clk1 fall. Clock clk3 fall. After optimization has been run in chain mode, the three top level scan chains will have been congured in the database as follows:
Info: Connecting scan chains (mode = chain)... <DFT-026>.

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Info: Inserting a lockup latch instance i_132 to connect scan ip-ops out_reg1_11 and out_reg2_15 in a single chain <DFT-344>. Top level chain 1 (BG_scan_in -> BG_scan_out) has 8 registers <DFT-024>. Top level chain 2 (BG_scan_in_2 -> BG_scan_out_2) has 4 registers. <DFT-024>. Top level chain 3 (BG_scan_in_3 -> BG_scan_out_3) has 4 registers.<DFT-024>. Where: Top level chain1 is a single scan chain with a data lockup latch inserted between the scan chain segments clocked by clk1 falling edge and clk3 falling edge domains. Top level chain2: is a single scan chain clocked by clk1 rising-edge domain. Top level chain3: is a single scan chain clocked by clk2 rising-edge domain.
I
set_dft_compatible_clock_domain clk1 clk2 clk3
The above command implicitly species that the all phases of the clk1, clk2, and clk3 domains are compatible for domain merging. After the above command is specied, the following Info message is returned by the shell: Info: Compatible clock list set to: Clock clk1 rise/fall. Clock clk2 rise/fall. Clock clk3 rise/fall. After optimization has been run in chain mode, one top level scan chain will have been congured in the database as follows:
Info: Connecting scan chains (mode = chain)... <DFT-026>. Info: Inserting a lockup latch instance i_132 to connect scan top level chain 1 (BG_scan_in -> BG_scan_out) has 16 registers <DFT-024>. Where: Top level chain1 is a single scan chain with three data lockup latches inserted between the scan chain segments clocked by clk1 rising-edge, clk1 falling-edge, clk2 rising-edge and clk3 falling-edge domains respectively.
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands A scan chain order le, top.scan.flat, catpures the location of the lockup latch inserted between the clock domain segments. The lockup latch is denoted as llatch in the scan order le, as shown below:
module top begin_chain 1 port BG_scan_in bit 1 out_reg_0/Q bit 2 out_reg_1/Q bit 3 out_reg_3/Q bit 4 out_reg_2/Q llatch 4 i_21/Q bit 5 out_reg0_4/Q bit 6 out_reg0_5/Q bit 7 out_reg0_6/Q bit 8 out_reg0_7/Q llatch 8 i_29/Q bit 9 out_reg1_11/Q bit 10 out_reg1_10/Q bit 11 out_reg1_9/Q bit 12 out_reg1_8/Q llatch 12 i_33/Q bit 13 out_reg2_15/Q bit 14 out_reg2_14/Q bit 15 out_reg2_13/Q bit 16 out_reg2_12/Q end_chain 1 port BG_scan_out
Where: Registers out_reg_[3:0] are clocked by clk1 rising-edge domain. Registers out_reg0_[7:4] are clocked by clk1 falling-edge domain registers out_reg1_[11:8] are clocked by clk2 rising-edge domain. Registers out_reg2_[15:12] are clocked by clk3 falling edge domain. Illustration 2: Specifying <-all>
set_dft_compatible_clock_domain -all
Note: This is the same as specifying: set_dft_compatible_clock_domain clk1 clk2 clk3
August 2001
90
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Illustration 3: Specifying <-sameclock> set_dft_compatible_clock_domain -sameclock Note: In this example, the above command is the same as specifying:
set_dft_compatible_clock_domain clk1 -rise clk1 -fall
-orset_dft_compatible_clock_domain clk1
Note: For all of the above illustrated examples, since the user did not specify the scan mode and scan-data signal names, the test synthesis tool will create a default scan mode port named BG_scan_enable and default scan-data ports named BG_scan_in and BG_scan_out in the top level module. Example 2: RTL description of a circuit which buffers the top level clock, clk, into two separate internal clock branches, clk1A and clk1B. These clock branches will be identied as separate DFT clock domains by specifying the set_dft_internal_clock_domain command to the output pin of the buffer and inverter. An initial optimization of the database will be performed in tieback mode. Afterwards, the set_dft_compatible_clock_domain will be specied using sameclock option, and a single scan chain will be congured by running the scan connection engine using the do_xform_connect_scan command. A single data lockup latch will be inserted between the internal clock branches clk1A and clk1B of the top level clock domain, clk.
module top (in, clk, out); input clk; input [7:0] in; output [7:0] out; BUFX1 u1 (.A(clk), .Y(clk1A)); INVX1 u2 (.A(clk), .Y(clk1B)); core u_core (.in(in), .clk1A(clk1A), .clk1B(clk1B), .out(out)); endmodule // top module core (in, clk1A, clk1B, out); input clk1A, clk1B; input [7:0] in; output [7:0] out; reg [7:0] out; always @(posedge clk1A) out[7:4] <= in[7:4];
always @(posedge clk1B) out[3:0] <= in[3:0]; endmodule
An example script in TCL format for the above RTL code is:
# read in the technology library read_alf <technologyLibrary>.alf # read in the RTL description and build the generic database read_verilog top.v do_build_generic # specify the top timing and current module pointers set_top_timing_module top set_current_module top # specify the internal clock domain points set_dft_internal_clock_domain [find -pin u1/Y] ;#clk1A set_dft_internal_clock_domain [find -pin u2/Y] ;#clk1B # run the DFT rule checks check_dft_rules # report the scannable registers relative to the internal DFTdomains report_dft_registers -scan #******************* IMPORTANT ************************* # prevent the buffers from being removed by area reclamation, place a # set_dont_modify on the buffer instance prior to running optimization #********************************************************** set_dont_modify [find -instance u1] ;# clk1A set_dont_modify [find -instance u2] ;# clk1B # optimize the design in tieback mode. set_global dft_scan_path_connect tieback do_optimize # configure the scan chains by placing a data lockup latch between # internal clock domains clk1A and clk1B. set_global dft_scan_path_connect chain set_dft_compatible_clock_domain -sameclock do_xform_connect_scan # save the database and exit the session write_verilog top.vm quit
While the scan connection engine is processing the database, a <DFT-344> Info message is issued to the shell and written to the log le indicating that a data lockup latch is being inserted into the design database. The Info message is reported as follows:
August 2001
92
ac_shell[19]>do_xform_connect_scan
Info: Connecting scan chains (mode = chain)... <DFT-026>. Info: Inserting a lockup latch instance u_core/i_163 to connect scan ip-ops u_core/out_reg0_3 and u_core/ out_reg_4 in a single chain <DFT-344>. Top level chain 1 (BG_scan_in -> BG_scan_out) has 8 registers. <DFT-024>. Analyzed chain # 1 (total 8 regs; BG_scan_in ->BG_scan_out connected in module top. <DFT-025>. Analyzed chain # 1 has 1 lockup latches connected in module top <DFT-450>. Finished scan connection <DFT-400>. A scan chain order le, top.scan.flat, captures the location of the lockup latch inserted between the internal clock domain branches. The lockup latch is denoted as llatch in the scan order le, as shown below:
module top begin_chain 1 port BG_scan_in bit 1 u_core/out_reg0_0/Q bit 2 u_core/out_reg0_1/Q bit 3 u_core/out_reg0_2/Q bit 4 u_core/out_reg0_3/Q llatch 4 u_core/i_163/Q bit 5 u_core/out_reg_4/Q bit 6 u_core/out_reg_7/Q bit 7 u_core/out_reg_6/Q bit 8 u_core/out_reg_5/Q end_chain 1 port BG_scan_out
Where: Registers u_core/out_reg0_[3:0] are clocked by internal clock domain branch clk1A. Registers u_core/out_reg_[7:4] are clocked by internal clock domain branch clk1B. Note: In this example, since the user did not specify the scan mode and scan-data signal names, the test synthesis tool will create a default scan mode port named BG_scan_enable and default scan-data ports named BG_scan_in and BG_scan_out in the top level module.
August 2001
93
August 2001
94
Multiple Clocks in Test Synthesis

In the absence of specifying top level clock domains which are compatible for domain merging, the test synthesis tool will create a single scan chain for each top level clock domain and/or each phase of a clock domain as as outlined in Figure 4-8 on page 95.
I I
The tool treats positive and negative edges of the same clock as different clock domains. The tool places only one clock domain on a scan chain.
Figure 4-8 Multiple Clock Distribution on Scan Chains

scan chain 1 Each scan chain belongs to only one clock domain.
clock1 scan chain 2 A clock domain can be spread over several scan chains.
scan chain 3
clock2
Multiple clock domains on a single scan chain can lead to hold violations on the scan path if there is excessive clock skew. Incorrect shift-in of the test vectors can occur if a downstream register is clocked after the preceding register is clocked. (See Figure 4-9 on page 96.)
August 2001
95
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-9 Hold Violations Due to Multiple Clock Domains on Single Scan Chain
0 ns 1 0 x Scan_out
Int
A 0 is output from the rst register in the scan chain at time 0.
Clk1 Clk2 Clk1 triggers at 10 ns, changing the signal on the net Int to 1. 10 ns 1 1 Int 1 x Scan_out
Clk1 Clk2
11 ns
Int
1 Scan_out
Clk2 triggers at 11 ns, lagging Clk1, so 1 is passed to Scan_out. The initial 0 is lost from the test result.
Clk1 Clk2
To avoid capture problems due to excessive clock skew, it is recommended that a data lockup latch be placed between the scan chain segments of the multiple clock domains on the same scan chain. (See Figure 4-10 on page 97.) For additional information regarding insertion of data lockup latches, refer to section Insertion of Data Lockup Latches in the Multiplexed Scan Style on page 85.
August 2001
96
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Using Test Synthesis Commands Figure 4-10 Hold Violations Due to Multiple Clock Domains on Single Scan Chains Using a Lockup Latch
Lockup Latch
Clk1 triggers at 10 ns, changing the signal on the net Int to 1. The latch locks the old data and the signal on Int-L remains at 0. x Scan_out
10 ns
1 Int
Int-L
Clk1 Clk2
Analysis of Data Lockup Latches in an Existing Scan Chain

The existence of a data lockup latch in a scan chain implies that there are multiple clock domains in that scan chain. Existing data lockup latches are identied during scan chain analysis and are preserved in the database during PKS reordering. PKS reorders each scan chain segment that is separated by a data lockup latch based on the physical placement of the data lockup latch. For additional information on PKS ordering, refer to PKS Ordering of Scan Chains on page 117. Important If multiple clock domains exist on the same scan chain without a data lockup latch between the scan chain segments, then you must run the DFT rule checks, check_dft_rules, to determine which ip-ops along the scan chain belong to each of the different clock domains. On the next execution of the scan chain connection engine in PKS mode, a data lockup latch will be inserted between the scan chain segments and PKS ordering of the ip-ops along the scan chain segments will be performed. In the absence of running check_dft_rules, the next execution of the scan connection engine in PKS mode can intermingle the ipops belonging to the multiple clock domains along the scan chain causing the scan chain to operate incorrectly. In summary, if you know there are multiple clock domains in the same scan chain without a data lockup latch between the scan chain segments, then after specifying the test mode setup, you must run the DFT checks prior to reordering the scan chains in PKS mode as shown below:
pks_shell> # read in target libraries pks_shell> read_alf <targetLibraries>.alf pks_shell> read_lef <largetLibraries>.lef pks_shell> pks_shell> # read in structural netlist, build the database and link to target library pks_shell> read_verilog <structruralNetlist>.vm pks_shell> do_build_generic pks_shell> pks_shell> # specify the test mode setup pks_shell> set_scan_mode pks_shell> set_scan_data pks_shell> set_test_mode_setup pks_shell> pks_shell> # run the design for test rule checks pks_shell> check_dft_rules pks_shell> pks_shell> # place the design, run the scan connection engine in PKS mode pks_shell> # followed by PKS reordering of the flip flops along the scan chain segments. pks_shell> do_place pks_shell> do_xform_connect_scan -pks -preserve_config
August 2001
98
5
How Test Synthesis Works
I I I I
When Test Synthesis is Called During the Optimization Process on page 99 Routines of the Scan Connection Engine on page 101 Conguring the Scan Chain using test synthesis commands on page 102 Using the Scan Order File to Order and Congure the Scan Chains on page 106
When Test Synthesis is Called During the Optimization Process

As outlined in the previous chapters, the scan connection engine is run during optimization, do_optimize, provided that the design for test rule checks, check_dft_rules, has been previously run on the database. The scan connection engine can be run directly using the do_xform_connect_scan command. The use of these commands within a TCL script is ow dependent given the incoming database representation and the synthesis methodology assumed by the customer. Note: The do_xform_connect_scan command can only be run on a technology-mapped (gate-level) database. Having rst run the design for test rule checks, check_dft_rules, any inferred registers (generic level) and any instantiated edge triggered registers (D-ip-ops, technology mapped) which pass the design for test rule checks, and are not annotated with a set_dont_scan property, will be mapped to their scan-equivalent cell when the technology mapper do_xform_map is run. Next, the scan equivalent cells will be connected as per the dft_scan_path_connect global variable, and the scan mode signals will be globally routed as per the dft_scan_enable_connect global variable, by the scan connection engine. Timing-driven optimization will be performed. If check_dft_rules is run prior to do_optimize, the following XFORMs are performed by the optimization process as shown in the ow below:
August 2001
99
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works The ow:
# DFT rule checks check_dft_rules # Optimization do_optimze <-pks >
Translates to:
# DFT rule checks check_dft_rules # Optimization: do_optimize <-pks>, breaks down into the following XFORMs: # generic optimization do_xform_optimize_generic # all flops which pass DFT rule checks are mapped to scan equiv cells do_xform_map # scan chain configuration is created. # scan flops are connected as per "dft_scan_path_connect" global. # scan mode signal(s), are routed as per "dft_scan_enable_connect" global. do_xform_connect_scan # slack optimization (BuildGates test synthesis only) do_xform_optimize_slack # -OR# slack optimization w/-pks flag (BuildGates test synthesis and PKS) do_xform_pre_placement_optimize_slack # placement do_place # post-placement slack optimization do_xform_optimize_slack -pks Note: PKS reordering of the flip flops is NOT performed. This can be done by invoking the scan connection engine after placement using the following command: do_xform_connect_scan -pks
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works Note: The default behavior of the scan connection engine is to globally route the scan mode signal(s) specied by the set_scan_mode command. The scan mode signal(s) will be routed independently of the scan data path connect style, specied using the dft_scan_path_connect global variable. To avoid routing the scan mode signals, specify the dft_scan_enable_connect global variable to either floating or tieoff.
Routines of the Scan Connection Engine

The three independent routines which comprise the scan connection engine are Analyze, Congure, and Connect. The routine that is used depends upon the state of the design database (RTL mappednetlists) or the command ow invoked by the user. A description of each routine is as follows:
I
Analyze: The analyze routine, on a module-by-module basis, determines the number of scan chains and the number of scannable registers connected on the scan chains for each module in the design hierarchy which was previously optimized to scan. Congure: The conguration routine uses the analyzed data (if present), to congure (create) the scan chains in the design database. By default, one scan chain will be created for each top level clock domain identied by the DFT rule checks, check_dft_rules. When conguration assertions are specied, such as set_max_scan_chain_length | set_number_of_scan_chains, multiple scan chains may be created across each clock domain. Additionally, if clock domain merging is allowed, by specifying the set_dft_compatible_clock_domain command, data lockup latch(es), will be inserted between the scan chain segments of the specied top level clock domains when the connection routine is run. Connect: The connection routine uses the conguration data to connect the registers which pass the DFT rule checks as per the dft_scan_path_connect global variable. If this variable is set to chain, the scan registers will be connected in the scan chains throughout the design hierarchy.
Commands which call the scan connection engine routines are: Database Representation
RTL -> Gates (tieback) RTL -> Gates (chain) Gates (tieback->chain)
Command
do_optimize <-pks> do_optimize <-pks>
Routines
-> Connect -> Configure -> -> Configure -> -> Configure -> -> Connect
Gates (chain )
Analyze Analyze Connect do_xform_connect_scan Analyze <-pks> Connect do_optimize <-pks> Analyze Connect do_xform_connect_scan -pks Analyze \ -preserve_config
August 2001
101
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works
Gates (chain) Gates (chain) Gates (chain) Gates (chain)
do_place -scan_reorder get_scan_chain_info write_scan_order_file read_scan_order_file
Analyze -> (Disconnection ->Placement) -> Connect Analyze Analyze Configure -> Connect
Conguring the Scan Chain using test synthesis commands

The scan chain conguration creates the scan chains and the assignment of the scannable registers to those chains. The assignment of the registers across the scan chains is done on a per clock domain basis (assumes domain merging has not been specied); where the initial order of the registers across the scan chains is generated according to a hierarchical alphanumeric ordering style. The test synthesis tool connects the registers in an alpha-numeric order within a level of hierarchy, and then it links the chains across the level of the design hierarchy. The conguration routine attempts to make scan chains of approximately equal length within each clock domain and attempts to group registers within a level of hierarchy on the same scan chain. To create multiple scan chains of equal length, you should use the test synthesis tool in chain mode after you have completely optimized the design. See Recommended Command Flows on page 26. When doing bottom-up synthesis, the test synthesis tool discards any existing scan chains and create new scan chains from the individual scan registers. This allows the tool to recognize clock domains and redistribute registers accordingly. Therefore, scan chains created during the nal synthesis run may look very different from the scan chains created during intermediate synthesis runs.
Controlling the Scan Chain Conguration

You can control scan chain congurations by setting the number of scan chains, setting the length of scan chains, controlling inversions of the scan data, and controlling the naming and recognition of scan-data input and output ports. Setting the Number and Length of Scan Chains If tester memory is not a limiting factor, you do not have to set any limits on the number and length of scan chains. By default, the test synthesis tool inserts one scan chain per clock domain and one scan chain for each phase of a clock domain. The length of each scan chain equals the number of scannable registers in its clock domain. If your design is pin-limited, you do not have to set any restrictions on the number or length of scan chains.
August 2001
102
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works If you want more than one scan chain, or if tester memory is limited, you should set a limit on either the number or the length of scan chains. If you specify both, meeting the specied maximum length takes priority over meeting the specied number of scan chains. You must run the set_number_of_scan_chains and set_max_scan_chain_length commands at the level of the top timing module. The set_number_of_scan_chains and set_max_scan_chain_length assertions are stored as global settings at the level of the top timing module. If you perform test synthesis at a lower level of the design hierarchy (i.e., you have specied set_current_module at a module other than the top timing module), these global settings are still in effect. If the value you set for set_number_of_scan_chains is less than the number of clock domains, the tool increases the number of scan chains to equal the number of clock domains. These commands must be specied prior to running the scan connection engine. Refer to the section Setting Test Synthesis Assertions and Using Test Synthesis Commands on page 48. Controlling Scan Data Inversions in the Scan Chain Inversions in the scan-data path can occur in the following situations:
I
The test synthesis tool moves the scan-data output to the scan registers Q-bar pin to decrease the load on the system data path. (See the dft_scan_output_pref min_load global variable .) The test synthesis tool maps an RTL register to a scan register with a single Q-bar output pin.
The scan chain report le marks inversions in the scan chain with the notation <i>. If you do not want inverted scan data, you can instruct the test synthesis tool to add inverters to any inverted scan data, by setting the dft_allow_scan_path_inv global variable to false. This global variable must be specied prior to running the scan connection engine. Refer to the section Setting Test Synthesis Assertions and Using Test Synthesis Commands on page 48. Naming Scan-Data Ports You can specify the names of the scan-data ports at the level of the design hierarchy specied by the set_current_module pointer. It is recommended that you specify as many set_scan_data commands as scan chains to be congured in the database. If there are more chains congured than set_scan_data pairs specied, the test synthesis tool will create scan-data input and scan-data output ports using the default names BG_scan_in and BG_scan_out. The default names are used as base name for each succeeding scan chain by appending the sufxes _2, _3 and so on, as needed.
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works For example:
ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shlel> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> # read in the RTL and build the generic database read_verilog top.v do_build_generic # specify the top and current module pointers set_current_module top set_top_timing_module top # specify the scan style and specify 3 scan chains set_scan_style muxscan set_number_of_scan_chains 3 # run the DFT rule checks and optimize the design (chain mode) check_dft_rules do_optimize
The scan connection engine will create 3 scan chains. The scan-data ports will use the default names of BG_scan_in and BG_scan_out where: Chain1: BG_scan_in, BG_scan_out Chain2: BG_scan_in_2, BG_scan_out_2 Chain3: BG_scan_in_3, BG_scan_out_3 For the muxscan style of test insertion, you can also use the -clock, rise or -fall options with set_scan_data command to associate a specic chain to a particular top level clock and its triggering edge. For all other supported scan sytles clocked_scan, clocked_lssd, and aux_clocked_lssd, specifying the -clock option to the set_scan_data command has no signicance, since the scan registers are NOT partitioned based on top level clock domains as is done for the muxscan style. Inherent to these scan styles are specic scan clock(s) that are globally routed to all scan ip-ops in the design. For more information refer to section, Handling Non-Scannable Design Elements on page 46. Therefore, specing the -clock option to set_scan_data for scan styles other than muxscan is NOT recommended.
August 2001
104
Important The specication of the set_scan_data commands is NOT considered by the conguration algorithm in determining the number of scan chains to be created in each clock domain. Rather, the number of scan chains created in the database, is specied using the top level commands set_number_of_scan_chains and set_max_scan_chain_length commands. When specifying the set_number_of_scan_chains command, this assertion will be translated into a maximum scan chain length parameter that will be used by the conguration algorithm to create the number of scan chains across all clock domains in the design. If the set_scan_data command is specied with the -clock option:
I I
The set data pairs will be associated to the scan chains created for that clock domain. If there are more scan data pairs specied than scan chains created in a clock domain the scan data pairs will be ignored by the test synthesis tool. If there are more scan chains created in a clock domain than scan data pairs specied the test synthesis tool will use the next scan data pair specied without the -clock option, or it will create new ports using the default base names of BG_scan_in and BG_scan_out.
In summary, for a multi-clock domain database in which multiple scan chains are to be created across each clock domain using the -clock option for all scan-data pairs may lead to unpredicatable results. This is because in most cases, the user is not able to predict how many scan chains will be created by the conguration algorithm in a given clock domain. When creating large numbers of scan chains across multiple clock domains specifying the set_scan_data command with the -clock option is not recommended. If this is an absolute requirement the recommendation is to rst create a conguration using default port names. Once the number of scan chains created in each domain is known, resynthesize the design specifying the number of scan data pairs accordingly using the -clock option. An example TCl script is as follows:
ac_shell> ac_shell> ac_shell> ac_shell> ac_shell>
read_verilog RTL.v do_build_generic # specify the test synthesis setup set_dont_scan set_test_mode_setup
August 2001
105
ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> check_dft_rules # perform generic opto, map and generate a configuration do_xform_optimize_generic do_xform_map set_number_of_scan_chains | set_max_scan_chain_length do_xform_connect_scan write_scan_order_file -flat <SOfile>
Note: Compare the number of registers in each scan chain in the scan order le to the number of registers identifed by the check_dft_rules output to determine how many scan chains have been created in each clock domain. For additional information on this command, see Specifying Multiple Scan Mode Signals and set_scan_data on page 60.
Using the Scan Order File to Order and Congure the Scan Chains
Test synthesis gives you control over the order and conguration of scan chains through the use of a scan order le. The scan order le is an ASCII text le that uses language-neutral naming conventions. There are two scan order le formats:
I
A hierarchical format shows the local connections by module. The hierarchical format contains lower level module port names for each instance referenced in a chain. A at format shows the path names from the top level down to the scan registers, using full hierarchical path names for each register. The at form does not contain lower level module port names for each instance referenced in a chain, except for blackboxes where the contents are not known.
The do_xform_connect_scan command creates both hierarchical and at versions of the scan order le. By default, they have the same name as the top timing module, plus the .scan and .scan.flat extensions, but you can specify a lename as an argument to do_xform_connect_scan. The same scan order le formats are used for both input and output purposes. That is, you can create a scan order le to specify how you want test synthesis to connect scan chains, and the test synthesis tool writes to the scan order les to report the results of scan insertion. If you are not satised with the way in which the test synthesis tool has ordered your scan chains, you can edit the scan order le and reconnect the scan chains in that new order.
August 2001
106
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works The scan order le controls the conguration and the specic connection order of instances and registers in scan chains throughout the hierarchy. After you have mapped your design with scan constraints, you can run the read_scan_order_file command to modify or directly specify scan conguration or the specic ordering of instances and bits in any chain, given that a le is consistent with the clock domains and the hierarchy of the design. You can use the scan order le to reorder scan chains, as follows:
I
You can make changes to a scan order le and apply those changes during a single test synthesis session. You can apply a scan order le to an Ambit database (.adb le). You can apply a scan order le to a mapped-scan netlist.
I I
The hierarchy instance names referenced and the clock domain separation in the design must be consistent with the scan order le data. You must manually control mixing clock domains in the same scan chain because this is outside the scope of the test synthesis tools ordering feature. You may join chains manually at the top level by using lock up latch elements after order-driven chaining is complete. The scan order data should be fully specied, and you should apply set_dont_scan or set_dont_touch_scan attributes to any instances, chains, or modules that you leave out of the scan order le. Important The test synthesis tool generates warnings for any registers and instances that you did not specify in the scan-order data and to which you have not applied the set_dont_scan command. The test synthesis tool leaves the scan-data pins on these elements unconnected, and such registers are not scan initializable, which reduces fault coverage. However, the scan-enable pins on these registers are connected so that they still operate correctly in system mode. Alternatively, references to sequential elements that are not mapped, or otherwise included for scan, can cause connection errors. You can delete active scan order data with the do_remove_scan_order_data command, so that subsequent add and connect cycles can freely congure and assign scan order using only the user constraints set at the generic level, prior to mapping. You may nd this technique useful for error recovery, or whenever a change in the hierarchy benets from regenerating an initial le. The scan chain connections listed in the scan order le are established onto the database by running the connection engine in a non-preserve_config mode. As such, the connection engine is NOT congnizent of muxes that have been added in support of shared scan data
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works output signals. To retain these muxes and their connections in the scan data path, the scan data output signals specied in the scan order le, must be specied in one of the following ways: 1. The scan data output signal can be specied as a hierarchical reference to the input pin of the MUX. 2. The scan data output signal can be specied as a hierarchial reference to the port of the lower level module which is connected to the input pin of the mux. If the scan data output signal is specied hierarchically to the output pin of the mux or any other hierarchical pin or port in the fanout of the mux, the specied pin or port will be directly connected to the internal scan data output signal when the scan connection engine is run. This has the effect of bypassing the mux logic and any other logic in the fanout of the mux. The scan chain connection engine will break the connections in the original circuit by disconnecting the logic which was orignally connected to the specied scan data output signal listed in the scan order le as shown in the example below. Example:
module top ((tclk, clk, sen, en1, en2, in1, in2, test_mode, out1, out2); // buffered scan data input path, and functional path to top level output ports pads u_pads(.in2(in2[0]), .out2(n_60), .in1(in1[0]), .out1(n_58), .in3(Iout2[0]), .out3(out2[0]), .in4(Iout1[0]), .out4(out1[0]));
// buffered scan mode path BUFXL i_sen2(.A(sen), .Y(Isen)); BUFXL i_sen1(.A(Isen), .Y(sen2));
// internal test mode signal used to multiplex test clock w/functional clock jtag u_jtag(.en1(en1), .en2(en2), .test_mode_out(n_51)); MX2X1 i_01(.S0(n_51), .B(tclk), .A(clk), .Y(tclk_out));
// modules a and b have undergone test synthesis -each w/a single scan chain of 4 regs each b u_b(.in(in2), .clk(tclk_out), .out({out2[3], out2[2], out2[1], n1}), .se(sen2), .BG_scan_in(n_60), .BG_scan_out(n_59)); a u_a(.in(in1), .clk(tclk_out), .out({out1[3], out1[2], out1[1], n0}), .se(sen2), .BG_scan_in(n_58), .BG_scan_out(n_56));
August 2001
108
// multiplexing internal scan data output signals and internal funcitonal signals MX2XL mux_1(.S0(sen2), .B(n_59), .A(n1), .Y(Iout2[0])); MX2XL mux_0(.S0(sen2), .B(n_56), .A(n0), .Y(Iout1[0])); endmodule
Examples of scan order les which will preserve the mux_0, mux_1 instances and their connections in the circuit are: 1. Scan Order File:
module top begin_chain 1 port u_pads/in1 bit 1 u_b/out_reg_3/Q bit 2 u_b/out_reg_2/Q bit 3 u_b/out_reg_1/Q bit 4 u_b/out_reg_0/Q end_chain 1 port mux_0/B begin_chain 2 port u_pads/in2 bit 1 u_a/out_reg_3/Q bit 2 u_a/out_reg_2/Q bit 3 u_a/out_reg_1/Q bit 4 u_a/out_reg_0/Q end_chain 2 port mux_1/B
2. Scan Order File:

module top begin_chain 1 port u_pads/out1 bit 1 u_b/out_reg_3/Q bit 2 u_b/out_reg_2/Q bit 3 u_b/out_reg_1/Q bit 4 u_b/out_reg_0/Q end_chain 1 port u_a/BG_scan_out begin_chain 2 port u_pads/out2 bit 1 u_a/out_reg_3/Q bit 2 u_a/out_reg_2/Q bit 3 u_a/out_reg_1/Q bit 4 u_a/out_reg_0/Q end_chain 2 port u_b/BG_scan_out
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works An example of scan order les which will short the output pin of the mux instances, mux_0, mux_1, to the internal scan data output siganls are as follows: Scan Order File:
module top begin_chain 1 port u_pads/in1 bit 1 u_b/out_reg_3/Q bit 2 u_b/out_reg_2/Q bit 3 u_b/out_reg_1/Q bit 4 u_b/out_reg_0/Q end_chain 1 port mux_0/Y begin_chain 2 port u_pads/in2 bit 1 u_a/out_reg_3/Q bit 2 u_a/out_reg_2/Q bit 3 u_a/out_reg_1/Q bit 4 u_a/out_reg_0/Q end_chain 2 port mux_1/Y
An example of scan order les which will bypass the mux logic, mux_0, mux_1, and break the connection after the buffers instantiated in the scan data output path, (instantiated in u_pads), is as follows: Scan Order File:
module top begin_chain 1 port u_pads/in1 bit 1 u_b/out_reg_3/Q bit 2 u_b/out_reg_2/Q bit 3 u_b/out_reg_1/Q bit 4 u_b/out_reg_0/Q end_chain 1 port out1[0] begin_chain 2 port u_pads/in2 bit 1 u_a/out_reg_3/Q bit 2 u_a/out_reg_2/Q bit 3 u_a/out_reg_1/Q bit 4 u_a/out_reg_0/Q end_chain 2 port out2[0]
August 2001
110
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works Once the scan order le scan data output pins are compliant as per the suggestions above, the scan order le is annotated onto the design, and the connections re-established using the following ows: BuildGates Test Synthesis Flow
ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> set_scan_mode set_global dft_scan_path_connect chain read_scan_order_file <ScanOrderFile> set_scan_data do_xform_connect_scan
BuildGates and PKS Test Synthesis Flows: Flow 1: Non-placed design

pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> set_scan_mode set_global dft_scan_path_connect chain read_scan_order_file <ScanOrderFile> set_scan_data do_xform_connect_scan
Flow 2: Placed design: No xed segments and NO PKS reordering

pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> set_scan_mode do_place set_global dft_scan_path_connect chain read_scan_order_file <ScanOrderFile> set_scan_data do_xform_connect_scan
Flow 3: Placed design: No xed segments and allow PKS reordering

pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> set_scan_mode do_place set_global dft_scan_path_connect chain read_scan_order_file <ScanOrderFile> set_scan_data do_xform_connect_scan -pks
Flow 4: Placed design: With xed segments, followed by PKS reordering:

pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> set_scan_mode do_place set_global dft_scan_path_connect chain read_scan_order_file <ScanOrderFile> set_scan_data
August 2001
111
pks_shell> pks_shell> pks_shell> pks_shell> do_xform_connect_scan do_remove_scan_order_data set_dont_touch_scan <moduleName> ;# design dependent do_xform_connect_scan -pks -preserve_config
Note: 1. If the design contains xed segments, the module must be attributed with a set_dont_touch_scan property to prevent PKS reordering from modifying the scan data path connections in the specied module(s). See Flow 4. above. 2. The -pks option performs PKS reordering of the annotated scan chain conguration. 3. When muxes are added in support of shared scan data output signals, the analysis code will trace the scan data path through the mux to the top level functional output ports. The top level output ports will be captured as the scan data output signals to the scan order le. If this scan order le is used to re-establish a scan chain conguration, it must be modied to capture the scan data output signals to the input pins of the muxes for each of the scan chains. Otherwise, the muxes in the scan data path will be bypassed. Important Scan chain conguration using a scan order le specied relative to internal data pins is supported but NOT recommended. Rather, the recommended approach is to generate the scan order le with respect to a lower level module, such that the scandata signals will be captured relative to PORT object IDs and not pin object IDs. For example:
ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> ac_shell> file ac_shell> ac_shell> ac_shell> ac_shell> # read in the structural design (optimized to scan and chained) read_verilog top.vm do_build_generic # specify the top level pointers set_top_timing_module set_current_module # push into the lower level module and generate the scan order do_push_module [find -module core] set_global dft_scan_path_connect chain set_scan_mode write_scan_order_file -flat SOfile
August 2001
112
Important The scan order le format presumes a single scan mode signal is used for all scan chains congured in the design database. The scan order le format does not support multi-scan mode signals. This will be addressed in a future release of test synthesis. For additional information, please refer to General Note Regarding Scan Order File Format on page 145. Changing the Scan Order During a Test Synthesis Session When the scan order le is parsed by the test synthesis tool, the bit numbers are irrelevant in the connection of the scan chain. The register pins indicate the order in which the scan chain is connected. To reorder a scan chain in the tutorial example design: 1. Start ac_shell, read the library and the design into the synthesis database, and set the current module.
ac_shell read_alf lca300k.alf set_global target_technology lca300kv read_verilog [glob *.v] do_build_generic set_current_module top
This example uses the glob Tcl command to read all les in your current working directory that have the .v extension into the synthesis database. 2. Set your test synthesis assertions and check for any DFT violations.
set_global dft_scan_path_connect chain set_scan_mode scan_enable 1 set_number_of_scan_chains 3 set_scan_data -clock clk1 {idata[0]} {odata[0]} -shared_out set_scan_data -clock clk1 {idata[1]} {odata[1]} -shared_out set_scan_data {idata[2]} {odata[2]} -shared_out report_dft_assertions -all_modules check_dft_rules
In this example, you set the scan mode to chain before optimizing the design so that the test synthesis tool can generate the scan order data. 3. Set your timing constraints.
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works 4. Optimize the design.
do_optimize -effort low -scan_file init.scan_order
The test synthesis tool creates a hierarchical scan order le named init.scan_order and a at le named init.scan_order.flat. 5. Edit the hierarchical scan order le and reorder some of the registers. For example, suppose that you want to insert do_reg_5/Q in submod1 between do_reg_1/Q and do_reg_2/Q. To do this, cut bit 6 from its original position and paste it into the third bit position:
module submod1 begin_chain 1 port BG_scan_in bit 1 do_reg_0/Q bit 2 do_reg_1/Q bit 6 do_reg_5/Q bit 3 do_reg_2/Q bit 4 do_reg_3/Q bit 5 do_reg_4/Q bit 7 do_reg_6/Q end_chain 1 port BG_scan_out
Save the reordered scan data to a le named new.scan_order. 6. Read the new scan order le into the synthesis database and recongure and connect the scan chains.
read_scan_order_file new.scan_order do_xform_connect_scan
7. Write the nal scan order data to a le.

write_scan_order_file final.scan_order
When you look at the scan-data le, you can see that the test synthesis tool has reordered the bit numbers and placed do_reg_5/Q in its new location.
8. After you have performed any nal optimization steps, save the design database and exit:
write_adb reorder_test.adb write_verilog reorder_test.vm exit
August 2001
114
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works Changing the Scan Order in an Ambit Database You can change the order of the scan chains in that design that you saved to the reorder_test.adb le, as follows: 1. Change the order of the new.scan_order le, so that scan bit 2 comes after scan bit 3.
Save these changes to the le. 2. Start ac_shell, read the library and the ADB le into the synthesis database, and read the modied scan order le.
read_alf lca300k.alf read_adb reorder_test.adb read_scan_order_file new.scan_order
3. Connect the scan chain with this new scan order data.
4. Continue with any further synthesis operations. Changing the Scan Order in a Mapped Scan Netlist To make changes to a mapped-scan netlist, you must reestablish your test synthesis assertions before reconnecting the scan chain, as follows: 1. Change the order of the new.scan_order le, so that scan bit 2 comes after scan bit 3, as in the previous example.
Save these changes to the le.

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS How Test Synthesis Works 2. Start ac_shell, read the technology library and the mapped scan netlist into the synthesis database.
read_alf lca300k.alf read_verilog reorder_test.vm do_build_generic
3. Reestablish your test synthesis assertions by running commands such as set_test_mode_setup, then propagate your assertions throughout the design.
check_dft_rules
4. Read the scan order le.

read_scan_order_file new.scan_order
5. Connect the scan chain with the new scan order data.
August 2001
116
6
PKS Ordering of Scan Chains
I I I
Introduction on page 117 Running the Scan Connection Engine in preserve_config Mode on page 118 Running the Scan Connection Engine Without the preserve_config Mode Option on page 120 Summary of Running Scan Connection Engine in preserve_config Mode on page 121 Re-establishing Test Synthesis Setup on a Gate-Level Netlist Prior to PKS Reordering on page 123 Handling of Scan Mode Network and Scan Data Path Connections During PKS Reordering. on page 128 Using Test Synthesis Commands with PKS on page 131 See Example Database on page 149
I I
Introduction
Important The following feature requires a CadencePhysically Knowledgeable Synthesis (PKS) software license. PKS provides physical placement and timing information along with logic synthesis to resolve the timing closure issues of conventional synthesis. Using placement information from PKS, the Cadence test synthesis tool orders and connects the scan chain according to the proximity of its constituent ip-ops.
August 2001
117
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains
Running the Scan Connection Engine in preserve_config Mode

There are two different approaches to performing scan chain reordering of an optimized netlist with PKS. Both approaches run the scan connection engine in preserve_config mode. The preserve_config mode refers to the analysis and usage of the existing scan chain conguration in the netlist by PKS during scan chain reordering. The analyzed conguration takes precedence over the default conguration created by running the check_dft_rules command, or any subsequent conguration which may be created by the scan connection engine, having specied set_number_of_scan_chains or set_max_scan_chain_length commands. For more information on creating a scan chain conguration, refer to Conguring the Scan Chain using test synthesis commands on page 102. The two different commands used to perform scan chain reordering in the preserve_config mode with PKS are as follows:
do_place -scan_reorder do_xform_connect_scan -pks -preserve_config I
do_place -scan_reorder This command runs the scan connection engine in preserve_config mode starting from the top level of the design hierarchy specied by the top_timing_module pointer. The command disconnects existing scan chains and records the constituent ip-ops of each chain. The command reorders the ip-ops by using placement information from PKS and reconnects the ip-ops in that order. This command does not create any new scan mode or scan-data ports at the top level module. In particular: a. The scan connection engine performs an analysis of the scan chain conguration, i.e., determines the number of scan chains in the design and what ip-ops correspond to which chains. b. The analyzed conguration is then saved, and the scan chains are disconnected. c. MACRO block and CELL placement are performed. d. The analyzed conguration is rerun on the design database to reestablish the original scan chains and scan connection order. e. The scan connection engine is run in chain mode, and the scan ip-ops are reordered with PKS based on their placement to minimize interconnect wire length between the Q to SI pin connections of successive scan ip-ops in the same scan chain.
August 2001
118
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains Note: The -scan_reorder option is only available with the do_place command. It is not available with the do_optimize -pks command. This is an optimal command to use if:
The gate-level netlist has been previously optimized with fully congured scan chains. Timing-driven placement of the netlist given functional timing assertions is desired without considering the wire congestion of the scan chain connections during placement.
do_xform_connect_scan -pks -preserve_config This command runs the scan connection engine in preserve_config mode starting from the level in the design hierarchy specied by the set_current_module pointer. The command reorders the ip-ops by using placement information from PKS and reconnects the ip-ops in that order. This command does not create new scan mode or scan data ports at the current_module level. In particular:

This command is run on a placed design. The scan connection engine performs an analysis of the scan chain conguration determining the number of scan chains in the design and what ip-ops correspond to which chains. The scan connection engine is run in chain mode and the scan ip-ops are reordered with PKS based on their placement to minimize interconnect wire length between the Q to SI pin connections of successive scan ip-ops.
This is an optimal command to use if:

The design database has been placed. The user prefers to reorder the scan chains at the level of design hierarchy specied by the set_current_module pointer. The gate level netlist has been previously optimized with fully congured scan chains. The scan chain conguration is created after the design has been placed.
August 2001
119
Running the Scan Connection Engine Without the preserve_config Mode Option
The scan connection engine is called during the optimization process after rst running the DFT rule checks. The following commands run the scan connection engine in a non-preserve_config mode:
do_optimize -pks -stop_before_placement do_optimize -pks do_xform_connect_scan -pks
If the scan connection engine is run without the preserve_config option, the impact to a gate-level netlist with fully congured scan chains, is as follows:
I
If the DFT rule checks, check_dft_rules, is rst run on the database, a default conguration will be created. The default conguration associates the ip-ops according to their clock domain and phase. In the absence of further specifying by the use of set_number_of_scan_chains or set_max_scan_chain_length commands, a single scan chain will be created for each clock domain identied by the DFT rule checks on the next invocation of the scan connection engine. This would have the effect of rechaining the netlist, creating the number of scan chains equal to the number of clock domains identied by the DFT rule checks.
An example command ow is: Example: Read in a gate-level netlist with 8 scan chains across 3 clock domains:
pks-shell> # read in the netlist and link to technology library: pks_shell> read_verilog <GateLevelNetlist>.vm pks_shell> do_build_generic pks_shell> # run the DFT rule checks pks_shell> check_dft_rules ;# identified 3 DFT clock domains pks_shell> pks_shell> pks_shell> pks_shell> # specify the scan mode and scan data signals set_scan_mode set_scan_data .
pks_shell> # place the design and run PKS reordering (non-preserve_config mode) pks_shell> do_place pks_shell> do_xform_connect_scan -pks
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains Note: The original conguration of 8 scan chains was lost. The netlist was recongured to 3 scan chains, followed by PKS reordering of the ip-ops along those chains.
I
If the DFT rule checks, check_dft_rules, is run, the set_number_of_scan_chains or set_max_scan_chain_length commands can be re-specied to keep the scan chain conguration, created by the scan connection engine, consistent with the number of scan chains in the netlist. This ensures that the connectivity to the scan data signals is preserved. However, the ip-op association to the scan chains, and the number of scan chains created for each clock domain, will most likely change and will not be representative of the original conguration (number of scan chains per clock domain, etc.) in the netlist. An example command ow is:
Example: Read in a gate-level netlist with 8 scan chains across 3 clock domains:
pks-shell> # read in the netlist and link to technology library: pks_shell> read_verilog <GateLevelNetlist>.vm pks_shell> do_build_generic pks_shell> # run the DFT rule checks pks_shell> check_dft_rules ;# identified 3 DFT clock domains pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> pks_shell> # specify the scan mode and scan data signals set_scan_mode set_scan_data . # place the design and run PKS reordering (non-preserve_config mode) do_place set_number_of_scan_chains 8 do_xform_connect_scan -pks
Note: A new scan conguration of 8 scan chains will be created, followed by PKS reordering of the ip ops along those chains.
Summary of Running Scan Connection Engine in preserve_config Mode

When starting with a gate-level netlist which has been previously optimized to scan with fully congured scan chains, the scan connection engine should be run in preserve_config mode, so that the scan chain conguration of the netlist is analyzed, preserved, and used by PKS reordering.
August 2001
121
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains It is recommended that the DFT rule checks be run on the netlist to identify any scan chain(s) congured with mixed edges or mixed domains without a lockup latch between the scan chain segments. In this scenario, a data lockup latch will be inserted by the scan connection engine and incrementally placed prior to reordering the ip-ops using PKS. An example ow is: Example 1: Read in a gate-level netlist with 8 scan chains across 3 clock domains:
pks-shell> # read in the netlist and link to technology library: pks_shell> read_verilog <GateLevelNetlist>.vm pks_shell> do_build_generic pks_shell> # run the DFT rule checks pks_shell> check_dft_rules ;# identified 3 DFT clock domains pks_shell> pks_shell> pks_shell> pks_shell> # specify the scan mode and scan data signals set_scan_mode set_scan_data .
pks_shell> # place the design and run PKS reordering (defaults: preserve_config mode) pks_shell> do_place -scan_reorder
OR
pks_shell> # place the design and run PKS reordering (preserve_config mode) pks_shell> do_place pks_shell> do_xform_connect_scan -pks -preserve_config
Note: The original scan chain conguration of 8 scan chains was analyzed, preserved, and used by PKS to reorder the ip-ops along the scan chains. Example 2: Read in a gate-level netlist with 8 scan chains across 3 clock domains:
pks-shell> # read in the netlist and link to technology library: pks_shell> read_verilog <GateLevelNetlist>.vm pks_shell> do_build_generic pks_shell> # Do NOT run the DFT rule checks pks_shell> #check_dft_rules pks_shell> # specify the scan mode and scan data signals pks_shell> set_scan_mode pks_shell> set_scan_data
pks_shell> . pks_shell> # place the design and run PKS reordering pks_shell> do_place pks_shell> do_xform_connect_scan -pks ;# defaults to preserve_config mode.
Important Since the DFT rule checks were not run on the gate-level netlist, the scan connection engine will default to preserve_config mode. Important Because the DFT rule checks were not run on the netlist, if there are any scan chain(s) congured with mixed edges or mixed domains without a data lockup latch between the scan chain segments, the ip-ops belonging to the multiple domains along the scan chain may become intermingled, causing the scan chain not to shift correctly.
Re-establishing Test Synthesis Setup on a Gate-Level Netlist Prior to PKS Reordering

The test synthesis setup must be re-established on the gate-level netlist prior to PKS reordering. The test synthesis setup consists of re-specifying the scan mode, scan data and test mode signals. A set_dont_touch_scan attribute should be placed on any module which contains a xed segment to prevent the scan ip-ops in the segment from undergoing reordering by PKS. As discussed above, it is recommended that the DFT rule checks should be run to identify any mixed-edge or mixed-domain scan chains that do not have a data lockup latch between the scan chain segments. How the test synthesis commands are specied is dependent upon the database representation of the gate-level netlist.
Block-Level Database:
A block-level database is a module in the design hierarchy which has undergone test synthesis as a standalone module. A block-level database does not include PAD
August 2001
123
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains instantiations and, therefore, does not usually include the mulitplexors in support of shared scan-data output signals. The scan mode, scan-data and test mode signals are typically referenced to the PORTs of the block level module. PKS reordering will be performed from the top level of the module hierarchy. Given the above assumptions, an example script for a block-level database is as follows: 1. Specify global setup variables and create any TCL variables. 2. Read in the technology libraries, both timing and physical. 3. Read in the gate-level netlist for the block-level database. 4. Build the design database and link to the technology library. 5. Read in the DEF or specify the oorplan commands (optional). 6. Re-establish the test synthesis setup prior to PKS reordering:
Specify the scan chain connection mode.

pks_shell> set_global dft_scan_path_connect chain
Specify the scan mode signal (top level port or internal port of lower level module). Restriction: The hierarchical path to the internal port or pins, is restricted to 1 level of design hierarchy below the module specied by the set_current_module pointer.
pks_shell> set_scan_mode <signalName > <value > pks_shell> # set_scan_mode <hierPathToScanMode /Port > <value >
Specify the scan data signals for all congured scan chains (top level ports).
pks_shell> set_scan_data <TopLevelSDIPort > <TopLevelSDOPort > pks_shell> .
Specify the test mode signals (design dependent - top level port or internal port of lower level module).
pks_shell> set_test_mode_setup <signalName > <value > pks_shell> # set_test_mode_setup -module <moduleName > <outputPinName > <value >
Specify dont_touch_scan attributes for modules which contain xed segments.

pks_shell> set_dont_touch_scan <module >
Run the DFT rule checks (recommended).

pks_shell> check_dft_rules
For accuracy, review the list of non-scan registers in the design (informational).
pks_shell> report_dft_registers -non_scan
August 2001
124
Generate a scan order le of the existing scan chains prior to reordering with PKS (recommended).
pks_shell> write_scan_order_file -flat <fileNameSO >
7. Source timing assertions and generate preliminary timing report 8. Precondition the netlist for high-fanout signals prior to placement
pks_shell> do_xform_pre_placement_optimize_slack
9. Perform placement, and reorder the scan chains with PKS in preserve_config mode.
pks_shell> do_place -scan_reorder
10. Generate a scan order le

pks_shell> write_scan_order_file -flat <fileNamePKS>
Important It is highly recommended that a scan order le be generated prior to reordering the ip-ops with PKS. This is important because the scan order le will analyze the scan chain conguration in the netlist. The user can then validate that the analyzed conguration is representative of the scan conguration obtained in the synthesized database, prior to invoking optimization and PKS reordering. Important Netlist preconditioning prior to placement should be done using the command do_xform_pre_placement_optimize_slack Netlist preconditioning prior to placement using the command do_optimize -pks -stop_before_placement should be avoided if the DFT rule checks have been previously run, for the following reasons: a. do_optimize -pks -stop_before_placement runs the scan connection engine in a non-preserve_config mode. b. The DFT rule checks will create a default conguration which will be used by the scan connection engine during optimization to re-chain the netlist.
Chip-Level Database
A chip-level database is comprised of all the modules in the design hierarchy optimized to gates. A chip level database usually includes but is not limited to the PAD instantiations, clocking circuitry, TAP controller (design dependent), and block-level modules which have undergone test synthesis, each database instantiated in their own level of design hierarchy.
August 2001
125
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains Additionally, any mulitplexors inserted by test synthesis in support of shared scan data output signals are usually instantiated at the chip level of design hierarchy, either paralle to the PADs module and/or parallel to the block-level (core-level) modules which have undergone test synthesis. Depending upon how these signals are created, the scan mode, scan data and test mode signals maybe referenced to either the ports of the top level module, ports of a lower level module(s) and/or pins of technology components as described in Specifying Internal Scan Mode, Scan Data, and Test Mode Ports or Pins on page 68. Given the above assumptions, an example script for a chip-level database is: 1. Specify global setup variables and create any TCL variables. 2. Read in the technology libraries, both timing and physical. 3. Read in the gate level netlist for the chip level database. 4. Build the design database and link to the technology library. 5. Read in the DEF or specify the oorplan commands. 6. Re-establish the test synthesis setup prior to PKS reordering.
Specify the scan chain connection mode.

pks_shell> set_global dft_scan_path_connect chain
Specify the scan mode signal (top level port or internal port of a lower level module or pin of a technology component). Restriction: The hierarchical path to the internal port or pins is restricted to 1 level of the design hierarchy below the module specied by the set_current_module pointer.
pks_shell> set_scan_mode <Port Name > <value > pks_shell> # set_scan_mode <hierPathToScanMode /Port > <value >
Specify the scan data signals (to ports of lower level modules or pins of technology components) Restriction: The hierarchical path to the internal port or pins, is restricted to 1 level of design hierarchy below the module specied by the set_current_module pointer.
pks_shell> set_scan_data <hierPathToSDI /PortorTechPin > <hierPathToSDO / PortorTechPin > pks_shell> .
Specify the test mode signals (design dependent - top level port or internal port of a lower level module)
pks_shell> set_test_mode_setup <PortName> <value> pks_shell> # set_test_mode_setup -module <moduleName> <outputPinName> <value>
Specify dont_touch_scan attributes for modules which contain xed segments.

pks_shell> set_dont_touch_scan <module >
August 2001
126
Run the DFT rule checks (recommended).

pks_shell> check_dft_rules
For accuracy review the list of non-scan registers in the design (informational).
pks_shell> report_dft_registers -non_scan
Generate a scan order le of the existing scan chains prior to reordering with PKS (recommended).
pks_shell> write_scan_order_file -flat <fileNameSO >
7. Source timing assertions and generate preliminary timing report. 8. Precondition the netlist for high-fanout signals prior to placement.
pks_shell> do_xform_pre_placement_optimize_slack
9. Perform placement and reorder the scan chains with PKS in preserve_config mode from the top level module.
pks_shell> do_place -scan_reorder
10. Generate a new scan order le.

pks_shell> write_scan_order_file -flat <fileNamePKS >
11. Buffer the clock trees using CTPKS (optional, but recommended). 12. Buffer the scan mode signals using do_build_physical_tree (optional, but recommended). 13. Perform slack optimization using PKS.
pks_shell> do_xform_optimize_slack -pks
Important It is highly recommended that a scan order le be generated prior to reordering the ip-ops with PKS. This is important because the scan order le will analyze the scan chain conguration in the netlist. The user can then validate that the analyzed conguration is representative of the scan conguration obtained in the synthesized database, prior to invoking optimization and PKS reordering. Important Netlist preconditioning prior to placement should be done using the command:
do_xform_pre_placement_optimize_slack
Netlist preconditioning prior to placement using the command do_optimize -pks -stop_before_placement should be avoided if the DFT rule checks have been previously run because:
August 2001
127
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains a. do_optimize -pks -stop_before_placement runs the scan connection engine in a non-preserve_config mode. b. The DFT rule checks will create a default conguration which will be used by the scan connection engine during optimization to rechain the netlist. Important If PAD cells are instantiated in the design database, then the scan-data signals should be specied to the PORTs of the lower module which instantiates the PAD cells, or directly to the pins of the PAD components. This is necessary to prevent the analyze routine of the scan connection engine from trying to analyze through the PAD cells to the top level ports, since for many libraries, the PAD cells do not contain a function denition. Important If multiplexors have been added by test synthesis in support of shared scan-data output signals, then the scan-data output signals should be referenced to either the input pin of the multiplexors or to the input pin of the PAD which is connected to the output pin of the multiplexor. Refer to section Handling of Scan Mode Network and Scan Data Path Connections During PKS Reordering. on page 128.
Handling of Scan Mode Network and Scan Data Path Connections During PKS Reordering.
During PKS reordering in both preserve or non-preserve_config modes, the scan connection engine will trace and preserve the buffers and/or inverters in the scan mode path. The scan mode network will be preserved, even if the scan mode signal is specied as a hierarchical reference point in the design database. During PKS reordering in both preserve or non-preserve_config modes, the scan connection engine will remove all buffers and inverters in the scan-data path (scan data input path and scan-data output path) from the level of the design hierarchy specied by the set_current_module pointer on downwards. To preserve any buffers or inverters in the direct fanout of the scan-data path, the user must specify the scan-data signals as a hierarchical reference to a port of a lower level module or pin of the component in the design database; the reference point should be specied after or prior to the buffers or inverters which are to be retained in the scan data input and scan data output paths respectively. An example of running the scan connection engine in a non-preserve_config mode, is when the scan chain conguration is re-established through the annotation of a scan order
August 2001
128
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains le. The scan chain connection engine, when run in a non-preserve_config mode, is NOT cognizent of multiplexers which have been added in the scan data path in support of scan data output signals. To retain these multiplexers and their connections in the scan data path, the scan data output signals specied in the scan order le, must adhere to the guidelines outlined in section, Using the Scan Order File to Order and Congure the Scan Chains on page 106. In addition, during PKS reordering, any buffers or inverters in the direct fanout of the Q pin to SI pin connections of successive scan ip-ops in a chain will removed. The removal of these components occurs prior to the reconnection pass of the ip-ops by PKS given their physcial placement in the scan chain. Reconnection will query the settings of two global variables:
set_global dft_allow_scan_path_inv set_global dft_scan_output_pref
when re-establishing the connections between successive scan ops along the scan data path. These variables are further described in section Controlling Scan Data Inversions in the Scan Chain on page 103. During PKS reordering in preserve_config mode, if the netlist contains multiplexors which have been added by test synthesis in support of shared scan-data output signals, the scandata output signals, specied using the set_scan_data command, can be hierarchically referenced to either the input pin of the multiplexors, or to the input pin of the PAD which is connected to the output pin of the multiplexor. Specifying the -shared_out option to the set_scan_data command is optional. See the following example: Example: RTL circuit with buffered scan-data input path (module pads), 2 top level scan chains (module a and module b), and mulitplexed scan-data output path, and buffered functional output path (module pads) to the top level output signals.
module top ((tclk, clk, sen, en1, en2, in1, in2, test_mode, out1, out2);
//buffered scan data input path, and functional path to top level output ports
pads u_pads(.in2(in2[0]), .out2(n_60), .in1(in1[0]), .out1(n_58), .in3(Iout2[0]), .out3(out2[0]), .in4(Iout1[0]), .out4(out1[0]));
// buffered scan mode path

BUFXL i_sen2(.A(sen), .Y(Isen)); BUFXL i_sen1(.A(Isen), .Y(sen2));
// internal test mode signal used to multiplex test clock w/functional clock
jtag u_jtag(.en1(en1), .en2(en2), .test_mode_out(n_51));
August 2001
129
MX2X1 i_01(.S0(n_51), .B(tclk), .A(clk), .Y(tclk_out));
// modules a and b have undergone test synthesis, -each with a single scan chain of 4 regs each
b u_b(.in(in2), .clk(tclk_out), .out({out2[3], out2[2], out2[1], n1}), .se(sen2), .BG_scan_in(n_60), .BG_scan_out(n_59)); a u_a(.in(in1), .clk(tclk_out), .out({out1[3], out1[2], out1[1], n0}), .se(sen2), .BG_scan_in(n_58), .BG_scan_out(n_56));
// multiplexing internal scan-data output signals and internal functional signals

MX2XL mux_1(.S0(sen2), .B(n_59), .A(n1), .Y(Iout2[0])); MX2XL mux_0(.S0(sen2), .B(n_56), .A(n0), .Y(Iout1[0])); endmodule
Alternate ways to specify the set_scan_mode commands for the above example:
set_scan_mode sen 1 set_scan_mode i_sen1/Y 1 set_scan_mode i_sen2/Y 1
Note: Buffer instances i_sen1and i_sen2 will be retained during PKS reordering.
Alternate ways to specify the set_scan_data commands for the above example:
Example 1: 1. Buffered scan-data input path, scan-data output path to input pin of mulitplexor
set_scan_data u_pads/out1 set_scan_data u_pads/out2 set_scan_data u_pads/out1 set_scan_data u_pads/out2 mux_0/B mux_1/B mux_0/B mux_1/B -shared_out -shared_out ;# -shared_out is optional
2. Buffered scan-data input path, scan-data output path to input pin of PADs module
set_scan_data u_pads/out1 set_scan_data u_pads/out2 set_scan_data u_pads/out1 set_scan_data u_pads/out2 u_pads/in3 u_pads/in4 u_pads/in3 -shared_out ;# -shared_out is optional u_pads/in4 -shared_out
Note: For all of the set_scan_data commands specied in this example, the buffered scan-data input path and buffered scan data output path will be retained during PKS reordering. The multiplexors in support of shared scan-data output signals will be analyzed and retained during PKS reordering. Example 2:
August 2001
130
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains 1. Scan-data input path specied to top level functional input signals, scan-data output path to input pin of mulitplexor
set_scan_data set_scan_data set_scan_data set_scan_data {in1[0]} {in2[0]} mux_0/B mux_1/B -shared_out ;# -shared_out is optional -shared_out
{in1[0]} mux_0/B {in2[0]} mux_1/B
2. Scan-data input path specied to top level functional input signals, scan-data output path to input pin of PADs module.
set_scan_data set_scan_data set_scan_data set_scan_data {in1[0]} {in2[0]} {in1[0]} {in2[0]} u_pads/in3 u_pads/in4 u_pads/in3 u_pads/in4 -shared_out ;# -shared_out is optional -shared_out
Note: For all of the commands specied in this example, the buffered scan data input path will be removed during PKS reordering, and the functional input signals, in1[0] and in 2[0], will be mapped directly to the BG_scan_in pins of modules a and b respectively. The buffered scan data output path will be retained. The multiplexors in support of shared scan data output signals will be analyzed and retained during PKS reordering.
Using Test Synthesis Commands with PKS

You have several options for using test synthesis commands with PKS. The following sections describe how to use test synthesis commands with PKS for RTL designs and mapped scan netlists.
Test Synthesis Commands with PKS RTL

I
Scan insertion in tieback mode prior to placement, followed by scan chain conguration and ordering according to PKS placement.
read_verilog <RTL >.v . . . check_dft_rules set_global dft_scan_path_connect tieback set_scan_mode do_optimize -pks -stop_before_placement do_place set_global dft_scan_path_connect chain set_scan_data
August 2001
131
set_number_of_scan_chains | set_max_scan_chain_length (optional) do_xform_connect_scan -pks do_xform_optimize_slack -pks I
Scan insertion in tieback mode with PKS, followed by scan chain conguration and ordering according to PKS placement.
read_verilog <RTL>.v . . . check_dft_rules set_global dft_scan_path_connect tieback set_scan_mode do_optimize -pks set_global dft_scan_path_connect chain set_scan_data set_number_of_scan_chains | set_max_scan_chain_length (optional) do_xform_connect_scan -pks do_xform_optimize_slack -pks
Scan insertion in tieback mode using WIRELOAD model optimization, followed by scan chain conguration and ordering according to PKS placement.
read_verilog <RTL >.v . . . check_dft_rules set_global dft_scan_path_connect tieback set_scan_mode do_optimize set_global dft_scan_path_connect chain set_scan_data set_number_of_scan_chains | set_max_scan_chain_length (optional) do_xform_connect_scan do_place -scan_reorder do_xform_optimize_slack -pks
Scan insertion and scan chain creation prior to placement, followed by scan ordering according to PKS placement.
read_verilog <RTL >.v . . . check_dft_rules set_global dft_scan_path_connect chain set_scan_data set_scan_mode set_number_of_scan_chains | set_max_scan_chain_length (optional) do_optimize -pks -stop_before_placement do_place -scan_reorder do_xform_optimize_slack -pks
Scan insertion and scan chain creation with PKS, followed by scan ordering according to PKS placement.
read_verilog <RTL >.v .
August 2001
132
. . check_dft_rules set_global dft_scan_path_connect chain set_scan_data set_scan_mode set_number_of_scan_chains | set_max_scan_chain_length (optional) do_optimize -pks do_xform_connect_scan -pks do_xform_optimize_slack -pks
Test Synthesis Commands with PKS Mapped Netlist

In the following command sequences, the do_xform_connect_scan command remaps all registers in the database that are not annotated with set_dont_scan and that pass the DFT rule checks (check_dft_rules) to their scan equivalent. In addition, each register is placed on the scan chain according to its corresponding clock domain. To prevent this from occurring, place a set_dont_scan attribute on the hierarchical path to the D ip-op register instance, if applicable. Remapping of teh D ip-ops to their scan-equivalent registers after they have passed the DFT rule checks occurs prior to placement only. For mapped-netlists, you must reestablish the test synthesis setup before you perform the DFT rule checks. Test synthesis setup is comprised of but not limited to the following commands: set_scan_mode, set_scan_data, set_dont_scan, set_dont_touch_scan, and set_test_mode_setup.
I
In a non-scan-mapped netlist, replace all ip-ops that pass DFT rule checks with equivalent scan ip-ops (presumes edge-triggered D ip-ops). Place the scan ip-ops in tieback mode. Congure and order the scan chains according to PKS placement.
read_verilog <Netlist>.vm . . . <Establish test synthesis setup> check_dft_rules set_global dft_scan_path_connect tieback set_scan_mode do_xform_connect_scan do_xform_pre_placement_optimize_slack do_place set_global dft_scan_path_connect chain set_scan_data set_number_of_scan_chains | set_max_scan_chain_length (optional) do_xform_connect_scan -pks do_xform_optimize_slack -pks
In a non-scan-mapped netlist, replace all ip-ops that pass DFT rule checks with equivalent scan ip-ips (presumes edge-triggered D ip-ops). Create and order the scan chains according to PKS placement.
August 2001
133
read_verilog <Netlist >.vm . . . <Establish test synthesis setup> check_dft_rules set_global dft_scan_path_connect chain set_scan_data set_scan_mode set_number_of_scan_chains | set_max_scan_chain_length (optional) do_xform_connect_scan do_xform_pre_placement_optimize_slack do_place -scan_reorder do_xform_optimize_slack -pks I
Bring a scan-mapped netlist into PKS, analyze the scan connections, and order the scan chains according to PKS placement.
read_verilog <Netlist >.vm . . . <Re-establish test synthesis setup> check_dft_rules set_global dft_scan_path_connect chain write_scan_order_file -flat <SO file > do_xform_pre_placement_optimize_slack do_place -scan_reorder do_xform_optimize_slack -pks
Bring a scan-mapped netlist into PKS, analyze the scan connections within a lower level module (for example, the CORE module), then order the scan chains according to PKS placement.
read_verilog <Netlist >.vm . . . <Re-establish test synthesis setup> check_dft_rules do_xform_pre_placement_optimize_slack do_place do_push_module [find -module <CORE >] set_global dft_scan_path_connect chain set_scan_mode write_scan_order_file -flat <CORE >.scanOrder_priorTo_PKS (optional) do_xform_connect_scan -pks -preserve_config write_scan_order_file -flat <CORE >.scanOrder_after_PKS (optional) do_pop_module do_xform_optimize_slack -pks
Bring a scan-mapped netlist into PKS, disconnect the scan chains that exist in a lower level module (for example, the CORE module). Connect the scan registers in tieback mode. Place the entire design and reestablish the scan connections within the CORE module through the annotation of a scan order le (which you may have modied). The connections dened in the scan order le persist until you explicitly remove them using the do_remove_scan_order_data command or the do_xform_connect_scan
August 2001
134
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS PKS Ordering of Scan Chains command is not run with the -PKS option. If the -PKS option is specied, the ip-ops will be reordered according to their physical placement.
read_verilog <Netlist >.vm . . . <Re-establish test synthesis setup> check_dft_rules do_push_module [find -module <CORE >] set_global dft_scan_path_connect chain set_scan_mode write_scan_order_file -flat <CORE >.scanOrder_priorTo_PKS set_global dft_scan_path_connect tieback do_xform_connect_scan do_pop_module do_xform_pre_placement_optimize_slack do_place do_push_module [find -module <CORE >] set_global dft_scan_path_connect chain read_scan_order_file <CORE>.AnnotateScanOrderFile do_xform_connect_scan do_pop_module do_xform_optimize_slack -pks I
Bring a scan-mapped netlist into PKS, disconnect the scan chains that exist in a lowerlevel module (for example, the CORE module). Connect the scan registers in tieback mode. Place the entire design and reestablish the scan connections within the CORE module through the annotation of a scan order le (which you may have modied). Afterwards, use PKS to reorder the ip-ops according to their physical placement.
read_verilog <Netlist>.vm . . . Re-establish test synthesis setup check_dft_rules do_push_module [find -module <CORE >] set_global dft_scan_path_connect chain set_scan_mode write_scan_order_file -flat <CORE >.scanOrder_priorTo_PKS set_global dft_scan_path_connect tieback do_xform_connect_scan do_pop_module do_xform_pre_placement_optimize_slack do_place do_push_module [find -module <CORE >] set_global dft_scan_path_connect chain read_scan_order_file <CORE>.AnnotateScanOrderFile do_xform_connect_scan -pks do_pop_module do_xform_optimize_slack -pks
August 2001
135
August 2001
136
A
Tutorial Source Files
top.v
module top output input input input reg wire (odata, idata, irin, clk1, clk2); [6:0] odata; [6:0] idata; [1:5] irin; clk1, clk2; [1:5] ireg; [6:0] hdata;
submod1 submod1i(.do(hdata), .di(idata), .load(ireg[1]), .clk(clk1)); submod2 submod2i(.dout(odata), .din1(idata), .din2(hdata), .chop(ireg[2:5]), .clk(clk1)); always @(posedge clk2) ireg <= irin; endmodule
submod1.v
module submod1 (do,di,load,clk); output [6:0] do; input [6:0] di; input load,clk; reg [6:0] do; always @(posedge clk) do <= (load) ? di : do; endmodule
submod2.v
module submod2(dout,din1,din2,chop,clk); output [6:0] dout; input [6:0] din1,din2; input [1:4] chop; input clk; reg [1:4] creg; wire [6:0] din = (creg[1]) ? din1 : din2; bottom2 bottom2i (dout,din,creg[2:4],clk); always @(posedge clk) creg <= chop; endmodule
August 2001
137
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tutorial Source Files bottom2.v
module bottom2 (dto,dti,cni,clk); output [6:0] dto; input [6:0] dti; input [1:3] cni; input clk; reg reg [6:0] areg; [6:0] breg;
wire [6:0] dto = (cni[3]) ? areg : breg; always @(posedge clk) begin if (cni[1:2] == 2b00) begin areg <= areg; breg <= breg; end else if (cni[1:2] == 2b01) begin areg <= dti; breg <= areg; end else if (cni[1:2] == 2b10) begin areg <= breg; breg <= areg; end else if (cni[1:2] == 2b11) begin areg <= 7b1111111; breg <= 7b0000000; end end endmodule
top.scan
module bottom2
August 2001
138
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tutorial Source Files
begin_chain 1 port BG_scan_in bit 1 breg_reg_0/Q end_chain 1 port BG_scan_out begin_chain 2 port BG_scan_in_2 bit 1 breg_reg_1/Q bit 2 breg_reg_2/Q bit 3 breg_reg_3/Q end_chain 2 port BG_scan_out_2 begin_chain 3 port BG_scan_in_3 bit 1 breg_reg_4/Q bit 2 breg_reg_5/Q bit 3 breg_reg_6/Q bit 4 areg_reg_0/Q bit 5 areg_reg_1/Q bit 6 areg_reg_2/Q bit 7 areg_reg_3/Q bit 8 areg_reg_4/Q bit 9 areg_reg_5/Q bit 10 areg_reg_6/Q end_chain 3 port BG_scan_out_3 module submod2 begin_chain 1 port BG_scan_in bit 1 bottom2i/ { BG_scan_in : bit 2 creg_reg_4/Q bit 3 creg_reg_3/Q bit 4 creg_reg_2/Q bit 5 creg_reg_1/Q llatch 5 i_442/Q end_chain 1 port BG_scan_out begin_chain 2 port BG_scan_in_2 bit 3 bottom2i/ { BG_scan_in_2 end_chain 2 port BG_scan_out_2 begin_chain 3 port BG_scan_in_3 bit 10 bottom2i/ { BG_scan_in_3 end_chain 3 port BG_scan_out_3 module submod1 begin_chain 1 port BG_scan_in bit 1 do_reg_0/Q bit 2 do_reg_1/Q bit 3 do_reg_2/Q bit 4 do_reg_3/Q bit 5 do_reg_4/Q bit 6 do_reg_5/Q bit 7 do_reg_6/Q end_chain 1 port BG_scan_out module top begin_chain 1 port idata[2]] bit 10 submod2i/ { BG_scan_in_3 end_chain 1 port odata[2] begin_chain 2 port idata[1] bit 3 submod2i/ { BG_scan_in_2 bit 10 submod1i/ { BG_scan_in : end_chain 2 port odata[1]
BG_scan_out }
: BG_scan_out_2 }
: BG_scan_out_3 }
: BG_scan_out_3 }
: BG_scan_out_2 } BG_scan_out }
August 2001
139
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Tutorial Source Files
begin_chain 3 port idata[0] bit 5 submod2i/ { BG_scan_in : BG_scan_out } bit 6 ireg_reg_1/Q bit 7 ireg_reg_2/Q bit 8 ireg_reg_5/Q bit 9 ireg_reg_3/Q bit 10 ireg_reg_4/Q end_chain 3 port odata[0]
top.scan.at
module top begin_chain 1 port idata[2] bit 1 submod2i/bottom2i/breg_reg_4/Q bit 2 submod2i/bottom2i/breg_reg_5/Q bit 3 submod2i/bottom2i/breg_reg_6/Q bit 4 submod2i/bottom2i/areg_reg_0/Q bit 5 submod2i/bottom2i/areg_reg_1/Q dontbit 6 submod2i/bottom2i/areg_reg_2/Q bit 7 submod2i/bottom2i/areg_reg_3/Q bit 8 submod2i/bottom2i/areg_reg_4/Q bit 9 submod2i/bottom2i/areg_reg_5/Q bit 10 submod2i/bottom2i/areg_reg_6/Q end_chain 1 port odata[2] begin_chain 2 port idata[1] bit 1 submod2i/bottom2i/breg_reg_1/Q bit 2 submod2i/bottom2i/breg_reg_2/Q bit 3 submod2i/bottom2i/breg_reg_3/Q bit 4 submod1i/do_reg_0/Q bit 5 submod1i/do_reg_1/Q bit 6 submod1i/do_reg_2/Q bit 7 submod1i/do_reg_3/Q bit 8 submod1i/do_reg_4/Q bit 9 submod1i/do_reg_5/Q bit 10 submod1i/do_reg_6/Q end_chain 2 port odata[1] begin_chain 3 port idata[0] bit 1 submod2i/bottom2i/breg_reg_0/Q bit 2 submod2i/creg_reg_4/Q bit 3 submod2i/creg_reg_3/Q bit 4 submod2i/creg_reg_2/Q bit 5 submod2i/creg_reg_1/Q llatch 5 submod2i/i_442/Q bit 6 ireg_reg_1/Q bit 7 ireg_reg_2/Q bit 8 ireg_reg_5/Q bit 9 ireg_reg_3/Q bit 10 ireg_reg_4/Q end_chain 3 port odata[0]
August 2001
140
B
Test Process
The test process refers to testing the chip for manufacturing defects. It is the act of analyzing the logic on a chip to detect logic faults. During testing, the test process puts the circuit into the following test modes:
I
Capture mode is the part of the test process that analyzes the combinational logic on the chip. The registers act rst as pseudo-primary inputs (using ATPG-generated test vector data), and then as pseudo-primary outputs (capturing the output of the combinational logic). Scan-shift mode is the part of the test process in which registers act as shift registers in a scan chain. Test vector data is shifted into the scan chain registers and the captured data (from capture mode) are shifted out of the scan chain registers. System mode is the normal, or intended, operation of the chip. Any logic dedicated to DFT purposes is not active in system mode.
August 2001
141
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Process Figure B-1 Equivalent Circuits for Scan, Capture, and System Mode
Equivalent Circuit for System Mode out1 in1 out2 in2 A B In system mode, the registers act as intermediate storage devices, storing data between clock cycles.
Equivalent Circuit for Scan Mode scan_in A In scan mode, the registers act as shift registers in a scan chain. The captured data is shifted out while the test vector data is shifted in.
B Equivalent Circuit for Capture Mode out1 in1 out2 in2 A A B C B C
scan_out
In capture mode, the registers act as pseudoprimary inputs (loaded with test vector data) and pseudo-primary outputs (capturing one cycle of test data).
Test vector data
Captured data
August 2001
142
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Process The steps of the test process for the multiplexed ip-op scan style are as follows: 1. Shift the rst test vector into the scan chain. 2. Capture one cycle of system function. a. Apply the primary input vector states to the primary inputs. The loaded test vector (the shifted-in register states and the primary input states) supplies the input to the combinational logic. The systems response is propagated to the primary outputs and register inputs. b. Compare the actual and expected test results at the primary outputs. c. Clock the systems response to the test vector into the registers. 3. Shift the test result out of the scan chain registers and simultaneously shift in the new test vector. 4. Compare the actual and expected test results as each bit is shifted out of the scan chain. 5. Repeat steps 2, 3, and 4 until all test vectors have been run.
August 2001
143
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Test Process
August 2001
144
C
General Note Regarding Scan Order File Format
I I I
Introduction on page 145 Hierarchical Scan Files on page 145 Flat Scan Files on page 147
Introduction
The test synthesis tool creates two types of scan order les. Both le types show the order in which scan cell pins are connected in a scan chain. The les differ in the way that they are organized. Hierarchical scan les are organized by module, and at scan les are organized by scan chain. Hierarchical and at les use the same convention for reporting inversions on the scan chain. To report an inversion between the preceding and current scan bit, the test synthesis tool adds <i> to the end of the line listing the inverted bit:
bit 9dataOut_reg_5/QN <i>
Hierarchical Scan Files

Hierarchical scan les (designated with a .scan extension) are organized by module. (See Figure C-1 on page 147.) Scan chain and scan bit numbering restart from 1 in each module. The hierarchical scan le format is useful for nding the port names used by each scan chain at a given module boundary and the number of scan register bits per module. For each module, the hierarchical scan le lists the module name, each scan chain in the module, and the names of the scan chains scan-data input and output ports:
module topDFT begin_chain 1 port scanInName1 ...(chain_details)... end_chain 1 port scanOutName1 begin_chain 2 port scanInName2 ...(chain_details)... end_chain 2 port scanOutName2
August 2001
145
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS General Note Regarding Scan Order File Format Between the begin_chain and end_chain statements, the hierarchical le lists the instances to which the scan chain connects. Three types of instance designations are possible: modules, black boxes, and scan register cells. Modules The hierarchical scan le lists the local name of each module, the scan bit corresponding to the last bit of the module, and the scan-data input and output ports.
begin_chain 1 ... bit 1 ireg1/ { SDI_1_1 : SDO_1_1} bit 9 accum1/ { SDI_1 : SDO_1} bit 18 alu1/ { SDI_1 : SDO_1} alu1 scan-data input and output port are named SDI_1 and SDO_1. The current module instantiates alu1. The 18th bit of scan chain 1 is the last register in instance alu1, which supplies registers for scan bits 10 through 18.
Black Boxes The hierarchical scan le uses the same conventions for black boxes as modules:
begin_chain 1 ... bit 25 bbox1/ { SDI_1_1 : SDO_1_1}
Scan Register Cells The hierarchical scan le lists the scan cell pins belonging to the scan chain at the level of a given module:
begin_chain 1 ... bit 1 dataOut_reg_1/Q bit 2 dataOut_reg_2/Q bit 3 dataOut_reg_3/Q bit 4 dataOut_reg_4/Q bit 5 dataOut_reg_5/Q bit 6 dataOut_reg_6/Q bit 7 dataOut_reg_7/Q bit 8 dataOut_reg_8/Q
August 2001
146
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS General Note Regarding Scan Order File Format Figure C-1 Hierarchical Scan Chain Report File
module cpu begin_chain 1 port SDI_1_1 bit 1 ireg1/ { SDI_1_1 : SDO_1_1} bit 9 accum1/ { SDI_1 : SDO_1} bit 18 alu1/ { SDI_1 : SDO_1} end_chain 1 port SDO_1_1 begin_chain 2 port SDI_2_2 bit 3 decode1/ { SDI_1 : SDO_1 } bit 10 ireg1/ { SDI_2_2 : SDO_2_2 } bit 18 pcount1/ { SDI_1 : SDO_1 } end_chain 2 port SDO_2_2 . . . module decode begin_chain 1 port SDI_2_2 bit 1 state_reg_2/Q bit 2 state_reg_1/Q bit 3 state_reg_0/Q end_chain 1 port SDO_2_2 . . . module alu begin_chain 1 port SDI_1 bit 1 aluout_reg_7/Q bit 2 aluout_reg_6/Q bit 3 aluout_reg_5/Q bit 4 aluout_reg_4/Q bit 5 aluout_reg_3/Q bit 6 aluout_reg_2/Q bit 7 aluout_reg_1/Q bit 8 aluout_reg_0/Q bit 9 zero_reg/Q end_chain 1 port SDO_1 Scan chain 1 in the module cpu connects to scan cell pins in submodules ireg1, accum1, and
Only the last bit of each submodule is listed. Bit 3 is listed here, but this line implies that bit 1, bit 2, and bit 3 of scan chain 2 are found in instance decode1.
Bit 1, bit 2, and bit 3 of scan chain 1 are specied completely under the listing for submodule decode. These three bits belong to pins on the scan cell named state_reg.
In hierarchical scan les, scan chain numbering and bit numbering are relative. The rst scan chain in a module is always scan chain 1, and the rst bit on a scan chain in each module is always bit 1.
Flat Scan Files

Flat scan les (designated with a .scan.flat extension) are organized by scan chain. Each scan chain of the design is listed along with all the scan bits belonging to each chain. The scan register corresponding to each scan bit is identied with its full hierarchical name. Unlike hierarchical scan les, the bit numbering of at scan les is absolute. An example of a hierarchical scan chain report le is shown in Figure C-2 on page 148.
August 2001
147
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS General Note Regarding Scan Order File Format Figure C-2 Flat Scan Report File Example
module cpu begin_chain 1 port SDI_1_1 bit 1 ireg1/dataOut_reg_1/Q bit 2 accum1/dataOut_reg_8/Q bit 3 accum1/dataOut_reg_7/Q bit 4 accum1/dataOut_reg_6/Q bit 5 accum1/dataOut_reg_5/Q bit 6 accum1/dataOut_reg_4/Q bit 7 accum1/dataOut_reg_3/Q bit 8 accum1/dataOut_reg_2/Q bit 9 accum1/dataOut_reg_1/Q bit 10 alu1/aluout_reg_7/Q bit 11 alu1/aluout_reg_6/Q bit 12 alu1/aluout_reg_5/Q bit 13 alu1/aluout_reg_4/Q bit 14 alu1/aluout_reg_3/Q bit 15 alu1/aluout_reg_2/Q bit 16 alu1/aluout_reg_1/Q bit 17 alu1/aluout_reg_0/Q bit 18 alu1/zero_reg/Q end_chain 1 port SDO_1_1 begin_chain 2 port SDI_2_2 bit 1 decode1/state_reg_2/Q bit 2 decode1/state_reg_1/Q bit 3 decode1/state_reg_0/Q bit 4 ireg1/dataOut_reg_2/Q bit 5 ireg1/dataOut_reg_3/Q bit 6 ireg1/dataOut_reg_4/Q bit 7 ireg1/dataOut_reg_5/Q bit 8 ireg1/dataOut_reg_6/Q bit 9 ireg1/dataOut_reg_7/Q bit 10 ireg1/dataOut_reg_8/Q bit 11 pcount1/count_reg_3/Q bit 12 pcount1/count_reg_2/Q bit 13 pcount1/count_reg_1/Q bit 14 pcount1/q_reg_5/Q bit 15 pcount1/q_reg_4/Q bit 16 pcount1/q_reg_3/Q bit 17 pcount1/q_reg_2/Q bit 18 pcount1/q_reg_1/Q end_chain 2 port SDO_2_2 The current module is module cpu.
Scan chain 1 has 18 bits. The at scan le shows the hierarchical name of each scan register bit and the order in which it appears on the scan chain.
state_reg_2 through state_reg_0 in submodule decode1 are the rst through third bits on scan chain 2 in the cpu design.
August 2001
148
D
Example Database
Using Test Synthesis Commands with PKS
This section features an example source RTL testcase, four different sample TCL scripts used to optimize the design using BuildGates test synthesis with PKS, and the resultant gatelevel netlist created by each of these les. These scripts have been crafted to showcase the versatility of constructing various ows dependent upon your overall synthesis stragegy and objectives. The Source RTL le, see Source RTL File on page 153, has the following characteristics:
I
The scan mode signal, Ise, is created as an internal signal within the jtag module. Because this signal is a oating pin, the scan mode port, u_jtag/Ise, will be attributed with a boundary_optimization property to prevent its removal by constant propagation. The test mode signal test_mode is referenced as a top level port, and will be used to multiplex the test clock, tclk, and the functional clock, clk, to create an internal clock, mclk. This clock is pin2signal mapped to the clock pin of the core module. The modules a and b, which will undergo test synthesis, have been instantiated in the lower level module, core. The scan-data input signals are shared with the functional input signals, in1[0], in2[0]. These signals are buffered in the pads module. The scan data output signals will be shared with the top level functional output signals, out1[0] and out2[0], which are buffered signals in the pads module. This will be done by referencing the scan-data input and scan data output signals to the pins of the pads module to establish the internal connections points used by the connection engine. Two scan chains will be created in the design database residing in u_core/a and u_core/b, using default port names: BG_scan_in, BG_scan_out, BG_scan_in_2, BG_scan_out_2.
RTL Script 1, see RTL Script 1 on page 155, has the following objectives:
August 2001
149
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Example Database
The RTL database is optimized from the top level module, with PKS stopping before placement, using the command:
do_optimize -pks -stop_before_placement
Two scan chains are created referencing the scan data signals to the ports of the pads module.
Afterwards, scan chain reordering with PKS is called using the command:
do_place -scan_reorder
The resultant gate-level netlist can be found in the le GatesRTL1.vm. See GatesRTL1.vm on page 161.
The RTL database is optimized and placed from the top level module with PKS using the command:
do_optmize -pks
The scan ip-ops have been placed in tieback mode.

The scan data signals are referenced to the ports of the pads module. The scan chain conguration for the two chains is created on the placed design, and the ip-ops are reordered according to their physical placement using the command:
do_xform_connect_scan -pks
The resultant gate-level netlist can be found in le, see GatesRTL2.vm on page 162.
The scan ip-ops have been placed in tieback mode.
The design is placed using the command:

do_place
The scan-data signals are referenced to the ports of the PAD module and the scan chain conguration for the two scan chains are created on the placed design using the command:
August 2001
150
The user implicitly moves the set_current_module pointer to the core level module, and performs scan chain reordering with PKS at the core level, using the command:
do_xform_connect_scan -pks -preserve_config
The resultant gate-level netlist can be found in le, see GatesRTL3.vm on page 163.
Two scan chains are created referencing the scan-data signals to the ports of the PAD module.
The user implicitly moves the set_current_module pointer to the core level module and generates a scan order le of the scan chain conguration in the core module. The ip-ops in the core module are then placed in tieback mode using command:
The design is placed from the top level using the command:
do_place
The user implicitly moves the set_current_module pointer back to the core level module and restores the scan chain conguration by annotating a scan order le using the command:
read_scan_order_file
The ip-ops are reordering by PKS according to their phyiscal placement using command:
do_xform_connect_scan -pks
The resultant gate-level netlist is located in GatesRTL4.vm on page 164.
Note 1: Since there is only one technology gate in module jtag, and the logic which creates this signal is a oating pin until the scan mode network is created by the scan connection engine, the jtag module would have been removed by constant propagation, which is called as the rst XFORM during optimization. To prevent this module from being removed, it had to be rst mapped to gates, and then attributed with a set_dont_modify property. Also, note that this issue arose given that the example RTL source le is a contrived circuit. In most situations,
August 2001
151
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Example Database there would be additional logic created in the jtag module and the need to rst map and attribute this module would not occur. Note 2: The following commands run the scan chain connection engine in non-PKS mode:
do_optimize do_xform_connect_scan
The following commands run the scan chain connection engine in PKS mode:
do_optimize -pks do_optimize -pks -stop_before_placement do_place -scan_reorder do_xform_connect_scan -pks <-preserve_config>
August 2001
152
Source RTL File

module top(tclk, clk, scan_mode, test_mode, in1, in2, out1, out2); input tclk, clk, scan_mode, test_mode; input [3:0] in1, in2; output [3:0] out1, out2; wire wire wire [3:0] mclk; SI0, SI1, SO0, SO1; Iout1, Iout2;
assign out1[3:1] = Iout1[3:1]; assign out2[3:1] = Iout2[3:1]; assign mclk = test_mode ? tclk : clk; pads u_pads (.in1(in1[0]), .in2(in2[0]), .Iout1(Iout1[0]), .Iout2(Iout2[0]), .si0(SIO), .si1(SI1), .out1(out1[0]), .out2(out2[0])); jtag u_jtag (.test_mode(test_mode), .scan_mode(scan_mode), .Ise()); core u_core (.in1(in1), .in2(in2), .clk(mclk), .out1(Iout1), .out2(Iout2)); endmodule // top module pads (in1, in2, Iout1, Iout2, si0, si1, out1, out2); input in1, in2, Iout1, Iout2; output si0, si1, out1, out2; BUFXL buf_0 (.A(in1), .Y(si0)); BUFXL buf_1 (.A(in2), .Y(si1)); BUFXL buf_2 (.A(Iout1), .Y(out1)); BUFXL buf_3 (.A(Iout2), .Y(out2)); endmodule // pads module core (in1, in2, clk, out1, out2); input [3:0] in1, in2; input clk; output [3:0] out1, out2; a u_a b u_b (.in(in1), .clk(clk), .out(out1)); (.in(in2), .clk(clk), .out(out2));
August 2001
endmodule // core module a (in, clk, out); input [3:0] in; input clk; output [3:0] out; reg [3:0] out; always @(posedge clk) out <= in; endmodule // a module b (in, clk, out); input [3:0] in; input clk; output [3:0] out; reg [3:0] out; always @(negedge clk) out <= in; endmodule // b module jtag(test_mode,scan_mode,Ise); input test_mode, scan_mode; output Ise; wire Ise = test_mode & scan_mode;
endmodule // jtag
August 2001
154
Source RTL Scripts

RTL Script 1
read_verilog test.v do_build_generic set_test_mode_setup test_mode 1 check_dft_rules set_global dft_scan_path_connect chain set_number_of_scan_chains 2 set_scan_mode u_jtag/Ise 1 check_dft_rules set_scan_data set_scan_data u_pads/si0 u_pads/Iout1 -shared_out u_pads/si1 u_pads/Iout2 -shared_out
set_port_property -boundary_optimization false [find -port u_jtag/Ise] set_dont_modify [find -instance buf_*]
See Note 1: on page 151.

do_push_module [find -module jtag] do_xform_optimize_generic do_xform_map do_pop_module set_dont_modify [find -module jtag] do_optimize -pks -stop_before_placement write_verilog foo.vm write_scan_order_file -flat SO do_place -scan_reorder do_xform_optimize_slack -pks write_verilog GatesRTL1.vm
August 2001
155
RTL Script 2
read_verilog test.v do_build_generic set_test_mode_setup test_mode 1 check_dft_rules set_global dft_scan_path_connect tieback set_scan_mode u_jtag/Ise 1 set_port_property -boundary_optimization false [find -port u_jtag/Ise] set_dont_modify [find -instance buf_*]
# See Note 1: on page 151.

do_push_module [find -module jtag] do_xform_optimize_generic do_xform_map do_pop_module set_dont_modify [find -module jtag] do_optimize -pks write_verilog foo.vm set_global dft_scan_path_connect chain set_number_of_scan_chains 2 set_scan_data -module top u_pads/si0 u_pads/Iout1 -shared_out set_scan_data -module top u_pads/si1 u_pads/Iout2 -shared_out do_xform_connect_scan -pks do_xform_optimize_slack -pks write_verilog GatesRTL2.vm
August 2001
156
RTL Script 3
read_verilog test.v do_build_generic set_test_mode_setup test_mode 1 check_dft_rules set_global dft_scan_path_connect tieback set_scan_mode u_jtag/Ise 1 set_port_property -boundary_optimization false [find -port u_jtag/Ise] set_dont_modify [find -instance buf_*]

do_push_module [find -module jtag] do_xform_optimize_generic do_xform_map do_pop_module set_dont_modify [find -module jtag] do_optimize -pks -stop_before_placement write_verilog foo.vm do_place set_global dft_scan_path_connect chain set_number_of_scan_chains 2
set_scan_data -module top u_pads/si0 u_pads/Iout1 -shared_out set_scan_data -module top u_pads/si1 u_pads/Iout2 -shared_out do_xform_connect_scan write_verilog foo2.vm do_push_module [find -module core] set_global dft_scan_path_connect chain set_scan_mode Ise 1 do_xform_connect_scan -pks -preserve_config do_pop_module
do_xform_optimize_slack -pks write_verilog GatesRTL3.vm
August 2001
158
RTL Script 4
read_verilog test.v do_build_generic set_test_mode_setup test_mode 1 check_dft_rules set_global dft_scan_path_connect chain set_number_of_scan_chains 2 set_scan_mode u_jtag/Ise 1
set_scan_data -module top u_pads/si0 u_pads/Iout1 -shared_out set_scan_data -module top u_pads/si1 u_pads/Iout2 -shared_out set_port_property -boundary_optimization false [find -port u_jtag/Ise] set_dont_modify [find -instance buf_*]

do_push_module [find -module jtag] do_xform_optimize_generic do_xform_map do_pop_module set_dont_modify [find -module jtag] do_optimize -pks -stop_before_placement write_verilog foo.vm do_push_module [find -module core] set_scan_mode Ise 1 set_global dft_scan_path_connect chain write_scan_order_file -flat SOcore set_global dft_scan_path_connect tieback do_xform_connect_scan do_pop_module write_verilog foo2.vm do_place do_push_module [find -module core]
set_global dft_scan_path_connect chain set_scan_mode Ise 1 read_scan_order_file SOcore do_xform_connect_scan -pks do_pop_module do_xform_optimize_slack -pks write_verilog GatesRTL4.vm
August 2001
160
Gate Level Netlists

GatesRTL1.vm
module top(tclk, clk, scan_mode, test_mode, in1, in2, out1, out2); input tclk; input clk; input scan_mode; input test_mode; input [3:0] in1; input [3:0] in2; output [3:0] out1; output [3:0] out2; BUFXL u_pads_buf_0(.A(in1[0]), .Y(n_73)); BUFXL u_pads_buf_1(.A(in2[0]), .Y(n_72)); BUFXL u_pads_buf_2(.A(n_42), .Y(out1[0])); BUFXL u_pads_buf_3(.A(n_46), .Y(out2[0])); MX2X1 i_77(.S0(Ise), .B(n_67), .A(n_66), .Y(n_46)); MX2X1 i_71(.S0(Ise), .B(n_60), .A(n_59), .Y(n_42)); MX2X1 i_00(.S0(test_mode), .B(tclk), .A(clk), .Y(mclk)); jtag u_jtag(.test_mode(test_mode), .scan_mode(in1[0]), .Ise(Ise)); core u_core(.in1(in1), .in2(in2), .clk(mclk), .out1({out1[3], out1[2],.out1[1], n_59}), .out2({out2[3], out2[2], out2[1], n_66}), .Ise(Ise), .BG_scan_out(n_60), .BG_scan_out_2(n_67), .BG_scan_in(n_72), .BG_scan_in_2(n_73)); endmodule
August 2001
161
GatesRTL2.vm
module top(tclk, clk, scan_mode, test_mode, in1, in2, out1, out2); input tclk; input clk; input scan_mode; input test_mode; input [3:0] in1; input [3:0] in2; output [3:0] out1; output [3:0] out2; MX2X1 i_77(.S0(Ise), .B(n_65), .A(n_64), .Y(n_46)); MX2X1 i_71(.S0(Ise), .B(n_59), .A(n_58), .Y(n_42)); BUFXL u_pads_buf_0(.A(in1[0]), .Y(u_pads_si0)); BUFXL u_pads_buf_1(.A(in2[0]), .Y(u_pads_si1)); BUFXL u_pads_buf_2(.A(n_42), .Y(out1[0])); BUFXL u_pads_buf_3(.A(n_46), .Y(out2[0])); MX2X1 i_00(.S0(test_mode), .B(tclk), .A(clk), .Y(mclk)); jtag u_jtag(.test_mode(test_mode), .scan_mode(in1[0]), .Ise(Ise)); core u_core(.in1(in1), .in2(in2), .clk(mclk), .out1({out1[3], out1[2],out1[1], n_58}), .out2({out2[3], out2[2], out2[1], n_64}), .Ise(Ise), .BG_scan_in(u_pads_si0), .BG_scan_out(n_59), .BG_scan_in_2 (u_pads_si1), .BG_scan_out_2(n_65)); endmodule
August 2001
162
GatesRTL3.vm
module top(tclk, clk, scan_mode, test_mode, in1, in2, out1, out2); input tclk; input clk; input scan_mode; input test_mode; input [3:0] in1; input [3:0] in2; output [3:0] out1; output [3:0] out2; MX2X1 i_77(.S0(Ise), .B(n_67), .A(n_66), .Y(n_46)); MX2X1 i_71(.S0(Ise), .B(n_60), .A(n_59), .Y(n_42)); MX2X1 i_00(.S0(test_mode), .B(tclk), .A(clk), .Y(mclk)); jtag u_jtag(.test_mode(test_mode), .scan_mode(in1[0]), .Ise(Ise)); pads u_pads(.in1(in1[0]), .in2(in2[0]), .Iout1(n_42), .Iout2(n_46), .si0(n_58), .si1(n_65), .out1(out1[0]), .out2(out2[0])); core u_core(.in1(in1), .in2(in2), .clk(mclk), .out1({out1[3], out1[2],out1[1], n_59}), .out2({out2[3], out2[2], out2[1], n_66}), .Ise(Ise), .BG_scan_in(n_58), .BG_scan_out(n_60), .BG_scan_in_2(n_65), .BG_scan_out_2(n_67)); endmodule
August 2001
163
GatesRTL4.vm
module top(tclk, clk, scan_mode, test_mode, in1, in2, out1, out2); input tclk; input clk; input scan_mode; input test_mode; input [3:0] in1; input [3:0] in2; output [3:0] out1; output [3:0] out2; MX2X1 i_77(.S0(Ise), .B(n_67), .A(n_66), .Y(n_46)); MX2X1 i_71(.S0(Ise), .B(n_60), .A(n_59), .Y(n_42)); MX2X1 i_00(.S0(test_mode), .B(tclk), .A(clk), .Y(mclk)); jtag u_jtag(.test_mode(test_mode), .scan_mode(in1[0]), .Ise(Ise)); pads u_pads(.in1(in1[0]), .in2(in2[0]), .Iout1(n_42), .Iout2(n_46), .si0(n_58), .si1(n_65), .out1(out1[0]), .out2(out2[0])); core u_core(.in1(in1), .in2(in2), .clk(mclk), .out1({out1[3], out1[2],out1[1], n_59}), .out2({out2[3], out2[2], out2[1], n_66}), .Ise(Ise), .BG_scan_in(n_58), .BG_scan_out(n_60), .BG_scan_in_2(n_65), .BG_scan_out_2(n_67)); endmodule
August 2001
164
E
Understanding Errors and Warnings
This chapter guides you through the error and warning messages associated with Envisia test synthesis.
I I
Error Messages on page 165 Warning Messages on page 166
Error Messages
Error messages identify serious problems. These messages may be used to explain why a program is terminating processing prematurely or indicate that the results produced should not be relied upon. The following error messages may occur in Envisia test synthesis. Error messages are identied by number and title. A brief explanation and solution is given with more complex error messages. ERROR: DFT-010 : Cannot nd view '%s' in module '%s'. Detail: Enter a new %s to nd in the module %s. ERROR: DFT-015 : Scan-connections: link '%s' specied for %s was unresolved. Detail: The 'link' connection attribute was specied for an output which named a signal/ function that could not be found. A signal/function is expected on an input pin. This is used to determine the scan chain data paths. ERROR: DFT-018: Feedback in scan chain found at %s. Detail: The scan-chain data path appears to wrap on itself at this point. ERROR: DFT-019 : Scan-connections processing terminated due to %d unresolved connections in module '%s'.
August 2001
165
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Understanding Errors and Warnings Detail: Scan-chain wiring could not be completed because of connection constraints present for this module (ports + cell/module instances). ERROR: DFT-037 : Scan data input port '%s' (module '%s') is also a functional input. Detail: This module is used as an instance and this port is used as a functional input. Therefore the scan connections at the instance level cannot be modied without affecting the functional logic. ERROR: DFT-050 : Scan connection problem: cannot resolve %s to %s. Detail: The connection expected to the specied target element was unresolvable, indicating internal consistency problem. ERROR: DFT-103 : Scan-cell selection failed. %s. Detail: This may indicate that the current target library is incompatible with the scan style selected. Otherwise it may be an internal error or library problem.
Warning Messages
Warning messages identify situations that could be problematic. The program may not terminate prematurely but the results produced should not be relied upon. The following warning messages may occur in Envisia test synthesis. Warning messages are identied by number and title. A brief explanation and solution is given with more complex warning messages. WARNING: DFT-012 : Scan-connections: links for equivalent pins '%s' and '%s' on instance '%s' are inconsistent. Detail: The 'link' and 'equivalence' connection attributes applied to these pins are inconsistent. Link options (reecting scan input data dependencies across this instance) should be the same for equivalent pins. WARNING: DFT-013 : Scan-connections: pins '%s' and '%s' are not mutually equivalenced on instance '%s'. Detail: The 'equivalence' connection attributes applied to these pins must be applied consistently for both. For example, if A is specied equivalent to B, then B must be specied equivalent to A. WARNING: DFT-017 : Linked connection branches at source %s.
August 2001
166
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Understanding Errors and Warnings Detail: The chain data-path appears to have multiple branches at this point. This is assumed to be unintentional. WARNING: DFT-020 : Could not open le '%s' for writing scan chain data. Detail: Open/write failed for scanle. Processing will continue without creating the le. WARNING: DFT-033 : Scan connection modes inconsistent between module '%s' and its sub-module '%s'. Connections may be incomplete. Detail: A non-hierarchical chain mode will probably cause errors when sub-modules connected here were not chained using the same mode. WARNING: DFT-034 : No scan data I/O ports designated for module '%s'. Detail: Scan connections are made for the internals of this module, but no corresponding ports to support these are found. A subsequent connection-resolution error is likely. Check that 'do_xform_add_test_logic' has been run. WARNING: DFT-036 : Scan data input port '%s' (module '%s') has functional connection. Detail: If this module is later used as an instance, and this port is assumed to be a functional input, modifying the scan connection at this level will modify functional logic. WARNING: DFT-038 : %s at %s. Element(s) may be excluded from scan. Detail: Analysis of existing scan connections could not trace this connection. This chain or related elements may not be recognized or included in subsequent scan connection operations, depending on the processing mode. WARNING: DFT-051 : Scan connection problem: cannot resolve %s to %s. Detail: The connection expected to the specied target element was unresolvable, indicating internal consistency problem.
August 2001
167
Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Understanding Errors and Warnings
August 2001
168

Scanuser PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scanuser PDF

Uploaded by

Copyright:

Available Formats

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS Beta

Product Version 4.0.10 August 2001

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

2 Test Synthesis Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

Viewing the Scan Chain in the Schematic Viewer

3 Tips for Performing Test Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Using Test Synthesis Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

5 How Test Synthesis Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6 PKS Ordering of Scan Chains

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

D Example Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

E Understanding Errors and Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

About This Manual

Other Information Sources

Low Power Option of Ambit BuildGates Synthesis and Cadence PKS

The following books are helpful references.

Text Command Syntax

Product Version 4.0.10

About the Graphical User Interface

Product Version 4.0.10

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

Test Synthesis Benets and Impact

Support for internal scan data and scan control pins.

Other Features of Cadence Test Synthesis

Automatic test pattern generation (ATPG), boundary scan, JTAG, or BIST.

Product Version 4.0.10

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

Start the Synthesis Tool

Product Version 4.0.10

5. Read the RTL design into the synthesis database:

6. Create a generic database:

Set Test Synthesis Assertions

Product Version 4.0.10

Check DFT Assertions and Rule Violations

Product Version 4.0.10

Set Timing Constraints and Optimize the Design

Product Version 4.0.10

Connect the Scan Chains

Product Version 4.0.10

View the Scan Chains

Product Version 4.0.10

Viewing the Scan Chain Text Files

Viewing the Scan Chain in the Schematic Viewer

Product Version 4.0.10

Product Version 4.0.10

Product Version 4.0.10

Test Synthesis for Ambit BuildGates Synthesis and Cadence PKS

Requirements for Test Synthesis

Cadence Test Synthesis tool requirements:

ASIC vendors requirements:

Recommended Command Flows

Top-Down Test Synthesis Flow

Product Version 4.0.10