Tshell User

Tessent® Shell User’s Manual
Software Version 2017.4

December 2017
Document Revision 7
© 2012-2017 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
Note - Viewing PDF files within a web browser causes some links not to function (see MG595892).
Use HTML for full navigation.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: mentor.com/trademarks.
The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.
Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: mentor.com
Support Center: support.mentor.com
Send Feedback on Documentation: support.mentor.com/doc_feedback_form

Revision History
Revision Changes Status/

Date
7 Modifications to improve the readability and comprehension of Released
the content. Approved by Lucille Woo. Dec 2017
All technical enhancements, changes, and fixes listed in the
Tessent Release Notes for this product are reflected in this
document. Approved by Ron Press.
the content. Approved by Lucille Woo. Sep 2017
the content. Approved by Lucille Woo. Jun 2017
the content. Approved by Lucille Woo. Mar 2017
Author: In-house procedures and working practices require multiple authors for documents. All
associated authors for each topic within this document are tracked within the Mentor Graphics
Technical Publication’s source. For specific topic authors, contact Mentor Graphics Technical
Publication department.
Revision History: Released documents maintain a revision history of up to four revisions. For
earlier revision history, refer to earlier releases of documentation which are available at the
following URL:
http://support.mentor.com
Tessent® Shell User’s Manual, v2017.4

December 2017
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
4 Tessent® Shell User’s Manual, v2017.4
December 2017
Table of Contents
Revision History
Chapter 1
Tessent Shell Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
What Is Tessent Shell?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
What Can You Do With Tessent Shell? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tessent Shell Tcl Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Command Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Command Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Dofile Transcription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Tcl Command Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2
Tool Invocation and Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Tool Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tessent Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tessent Shell Environment Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Contexts and System Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
System Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Context and System Mode Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Design Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Design Data Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Flat Design Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Hierarchical Design Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ICL Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Object Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 3
Design Introspection and Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Design Introspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Object Specification Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Introspection Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Design Introspection Command Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Design Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Design Editing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Design Editing Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Simulation Contexts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Simulation Context Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Introspection and Analysis Using Simulation Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tessent® Shell User’s Manual, v2017.4 5

December 2017
Table of Contents
Chapter 4
Tessent Shell Work Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Tessent Shell Flow for Flat Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Overview of the RTL and Scan DFT Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
First DFT Insertion Pass: MemoryBIST and Boundary Scan . . . . . . . . . . . . . . . . . . . . . . 63
Second DFT Insertion Pass: EDT and OCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Load the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Specify and Verify the DFT Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Create the DFT Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Generate the EDT and OCC Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Extract the ICL Module Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Generate IJTAG Patterns and Run Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Perform Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Perform Scan Chain Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Perform ATPG Pattern Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Considerations for Using Gate-Level Verilog Netlists. . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Tessent Shell Flow for Hierarchical Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Hierarchical DFT Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
How the DFT Insertion Flow Applies to Hierarchical Designs . . . . . . . . . . . . . . . . . . . . . 88
RTL and Scan DFT Insertion Flow for Physical Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 89
First DFT Insertion Pass: Performing Block-Level MemoryBIST . . . . . . . . . . . . . . . . . 89
Second DFT Insertion Pass: Block-Level EDT and OCC . . . . . . . . . . . . . . . . . . . . . . . . 92
Specify and Verify the DFT Requirements: DFT Signals for Wrapped Cores . . . . . . . . 95
Perform Scan Chain Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Perform ATPG Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Run Recommended Validation Step for Pre-Layout Design Sign Off. . . . . . . . . . . . . . . 104
RTL and Scan DFT Insertion Flow for the Top Chip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Top-Level DFT Insertion Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan. . . 109
Second DFT Insertion Pass: Top-Level EDT and OCC. . . . . . . . . . . . . . . . . . . . . . . . . . 112
Scan Chain Insertion Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
ATPG Pattern Generation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Performing Top-Level ATPG Pattern Retargeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
RTL and Scan DFT Insertion Flow for Sub-Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
DFT Insertion Flow for the Sub-Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
DFT Insertion Flow for the Next Parent Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Tessent Shell Post-Layout Validation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Overview of the Post-Layout Validation Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Soft Link TSDB and Post-Layout Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Verify MemoryBIST, Boundary Scan and IJTAG Patterns . . . . . . . . . . . . . . . . . . . . . . . . 127
Verify the Scan-Inserted ATPG Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic . . . . . . . . 129
Running Multi-Load ATPG on Memories for Wrapped Cores with Built-In Self Repair . . 134
Overview of Multi-Load ATPG on Memories for Wrapped Cores with Built-in Self Repair
134
Performing Multi-Load ATPG Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Performing Multi-Load Top-Level ATPG Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . 137

December 2017
Table of Contents
Chapter 5
TSDB Data Flow for the Tessent Shell Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Core-Level or Flat TSDB Data Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Top-Level TSDB Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Chapter 6
Tessent Examples and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
How to Handle Clocks Sourced by Embedded PLLs During Logic Test . . . . . . . . . . . . . . . 153
How to Design Capture Windows for Hybrid TK/LBIST. . . . . . . . . . . . . . . . . . . . . . . . . . . 159
How to Use Boundary Scan in a Wrapped Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
TAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Stand-alone TAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
TAP with IJTAG Host Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Compliance Enable TAP with IJTAG Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Daisychained TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Master TAP Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Slave TAP Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Connecting to a Third-Party TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
How to Set Up Third-Party Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
How to Set Up Support for Third-Party OCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
How to Configure Files for Third-Party OCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Test Logic Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Pattern Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Chapter 7
DFTVisualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
DFTVisualizer Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
DFTVisualizer Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
DFTVisualizer Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
DFTVisualizer Quality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Performing Basic Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Saving and Restoring Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Searching for an Instance, Net, or Pin in the Active Window . . . . . . . . . . . . . . . . . . . . . . 190
Searching for an Instance, Net, or Pin in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Interruption of Operations from DFTVisualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Undocking and Docking Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Resizing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Repositioning Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Accessing Popup Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Object Name Copied from a Popup Menu to the System Clipboard . . . . . . . . . . . . . . . . . 194
Adding Instances to the Current Display Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Cross-Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Selecting Multiple Objects in the Flat and Hierarchical Schematic Windows. . . . . . . . . . 196
Unselecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Customizing Marking Colors in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . . . 197

December 2017
Table of Contents
Marking and Unmarking Objects in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . 197

Viewing Instances in Other Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Copying and Pasting Object Names in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Compaction of Buffers and Inverters in Traced Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . 202
Tracing Signal Paths on a Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Tracing a Specific Signal Value to the Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Signal Path Tracing in the Hierarchical Schematic Window . . . . . . . . . . . . . . . . . . . . . . . 206
Tracing Up and Down the Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Annotation of Schematic Data in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . . 212
Adding User-Defined Annotations to Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Viewing K19 and K22 Simulation Data in the Schematic Windows . . . . . . . . . . . . . . . . . 215
Reporting Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Expansion of Library Instances in the Flat Schematic Window. . . . . . . . . . . . . . . . . . . . . 217
Display of Multiple Data Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Working with Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Attributes in the Hierarchical and Flat Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . 219
Setting Global Attribute Display Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Setting Attribute Background Display Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Controlling the Display of Callouts in the Flat and Hierarchical Schematic Windows . . . 222
Attribute Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Working With Specifications in the Configuration Data Window . . . . . . . . . . . . . . . . . . . . 225
Modifying the Contents of the Configuration Data Window . . . . . . . . . . . . . . . . . . . . . . . 225
Adding a Test Data Register to a SIB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Adding a Multiplexer to a SIB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Customizing the DFT Specification for EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
DFTVisualizer Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Setting DFTVisualizer Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Saving/Loading Session Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
DFTVisualizer Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Global Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Colors Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Schematics Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Attributes Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Browser Window Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Data Window Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Text Editor Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
DFTVisualizer Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Objects Added to DFTVisualizer Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Design Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Flat Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Hierarchical Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Configuration Data Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Global Search Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Test Structures Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Text Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Console Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

December 2017
Table of Contents
DFTVisualizer Command Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Chapter 8
Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Test Procedure File Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Test Procedure File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Test Procedure File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
#include Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Set Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Alias Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Timing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Timeplate Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Multiple-Pulse Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
The pulse_clock Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Inferred Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Differences Between Default add_clock and 1x Multiplier Clock . . . . . . . . . . . . . . . . . 310
Always Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Procedure Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Clock Control Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
The Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Test_Setup (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Shift (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Alternate Shift Procedure (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Load_Unload (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Shadow_Control (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Master_Observe (Sometimes Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Shadow_Observe (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Seq_Transparent (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Clock (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Skew_Load (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Clock_run (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Capture Procedures (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Rules for Creating and Editing a Default Capture Procedure . . . . . . . . . . . . . . . . . . . . . 350
Rules for Creating and Editing Named Capture Procedures . . . . . . . . . . . . . . . . . . . . . . 350
Slow and Load Types in the Cycle Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
launch_capture_pair Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Viewing Optimized Named Capture Procedures (NCPs) . . . . . . . . . . . . . . . . . . . . . . . . 354
Clock_po (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Ram_sequential (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Ram_passthru (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Clock_sequential (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Init_force (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Test_end (Optional, all ATPG tools) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Sub_procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Additional Support for Test Procedure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Creating Test Procedure Files for End Measure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Serial Register Load and Unload for LogicBIST and ATPG . . . . . . . . . . . . . . . . . . . . . . . . 367
Register Load and Unload Use Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

December 2017
Table of Contents
Static Versus Dynamic Register Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Test Procedure File Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Dofile Modifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Serial Load and Unload DRC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
P13 and P54 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
P66 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
W5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Procedure Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Notes About Using the stil2mgc Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Extraction of Strobe Timing Information from STIL (SPF). . . . . . . . . . . . . . . . . . . . . . . . 380
The STIL ClockStructures Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Test Procedure File Commands and Output Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Chapter 9
Timing Constraints (SDC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Generating and Using SDC for Tessent Shell Embedded Test IP . . . . . . . . . . . . . . . . . . . . . 384
SDC File Generation with Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
SDC Design Synthesis with Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Preparation Step 1: Sourcing SDC File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Preparation Step 2: Setting and Redefining Tessent Tcl Variables . . . . . . . . . . . . . . . . . . 386
Preparation Step 3: Verifying the Declaration of Functional Clocks . . . . . . . . . . . . . . . . . 387
Preparation Step 4: Redefining Other Tessent Tcl Variables . . . . . . . . . . . . . . . . . . . . . . . 388
Synthesis Step 1: Loading the Design Into Your Synthesis Tool. . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 2: Applying the SDC Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 3: Preparing the DFT Logic for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 4: Synthesizing Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Synthesis Step 5: Writing Out Your Final SDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Synthesis Step 6: Writing Out Your Final Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
SDC for Modal Static Timing Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Checking Your Functional Logic Alone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Checking Your Embedded Test Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
VHDL and Mixed Language Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
VHDL Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
SDC File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
tessent_set_default_variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
tessent_create_functional_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
tessent_<design_name>_set_dft_signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
tessent_constrain_<design_name>_non_modal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
IJTAG Instrument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
LOGICTEST Instruments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
MemoryBIST Instrument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
BoundaryScan Instrument. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Cell and Pin Mapping Procs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Synthesis Helper Procs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Appendix A
Example Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Example Design Compiler Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

December 2017
Table of Contents
Example Encounter Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Example PrimeTime STA Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Appendix B
The Tessent Tcl Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
General Tcl Guidelines in Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Guidelines for Modifying Existing Dofiles for Use with Tcl . . . . . . . . . . . . . . . . . . . . . . . . 420
Special Tcl Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Custom Tcl Packages in Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Tcl Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Appendix C
Transitioning from the Classic Point Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Transitioning from the Classic FastScan Point Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Transitioning from the Classic TestKompress Point Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Transitioning from the Classic DFTAdvisor Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Transitioning from the Classic Diagnosis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Appendix D
Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Constraints for Formality Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Appendix E
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Mentor Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Index
Third-Party Information
End-User License Agreement

December 2017
Table of Contents

December 2017
List of Figures
Figure 2-1. Hierarchical Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 3-1. Hierarchical Design Example With Colors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 3-2. Hierarchical Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 3-3. Inverter Inception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 3-4. DFTVisualizer Flat Schematic (gate level). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 4-1. Two-Pass Insertion Flow for RTL, Flat Designs . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 4-2. DFT-Ready Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 4-3. After the First DFT Insertion Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 4-4. After the Second DFT Insertion Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 4-5. Flow for the Second DFT Insertion Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 4-6. Flow for Loading the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 4-7. Flow for Specifying and Verifying the DFT Requirements . . . . . . . . . . . . . . . . 70
Figure 4-8. Flow for Creating the DFT Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 4-9. Flow for Inserting the Second-Pass Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 4-10. Flow for Extracting ICL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4-11. Flow for Generating and Simulating IJTAG Patterns. . . . . . . . . . . . . . . . . . . . 78
Figure 4-12. Two-Pass Insertion Flow for RTL, Gate-Level Designs . . . . . . . . . . . . . . . . . 83
Figure 4-13. Hierarchical Design Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 4-14. Two-Pass Insertion Flow for RTL, Wrapped Cores . . . . . . . . . . . . . . . . . . . . . 89
Figure 4-15. Flow for Specifying and Verifying the DFT Requirements . . . . . . . . . . . . . . . 95
Figure 4-16. ATPG Pattern Generation Flow for Wrapped Cores . . . . . . . . . . . . . . . . . . . . 100
Figure 4-17. Two-Pass Insertion Flow for RTL, Top Level . . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 4-18. Top-Level Example, Before DFT Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Figure 4-19. Top-Level Example, After DFT Insertion for Wrapped Cores. . . . . . . . . . . . . 108
Figure 4-20. Top-Level Example, After DFT Insertion at the Top Level . . . . . . . . . . . . . . . 109
Figure 4-21. Post_Layout Validation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 4-22. Post-Layout Validation Flow with Ungrouped IJTAG/OCC/EDT Logic . . . . 130
Figure 4-23. Generate Graybox Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 4-24. Run ATPG on the Core’s Internal Mode Example . . . . . . . . . . . . . . . . . . . . . . 132
Figure 4-25. Two-Pass Insertion Flow for RTL, Wrapped Cores . . . . . . . . . . . . . . . . . . . . . 135
Figure 4-26. Two-Pass Insertion Flow for RTL, Top Level . . . . . . . . . . . . . . . . . . . . . . . . . 138
Figure 5-1. TSDB Data Flow, Core Level, First Insertion Pass . . . . . . . . . . . . . . . . . . . . . . 143
Figure 5-2. TSDB Data Flow, Core Level, Second Insertion Pass . . . . . . . . . . . . . . . . . . . . 144
Figure 5-3. TSDB Data Flow, Core Level, Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Figure 5-4. TSDB Data Flow, Core Level, Pattern Generation. . . . . . . . . . . . . . . . . . . . . . . 145
Figure 5-5. TSDB Data Flow, Top Level, First Insertion Pass . . . . . . . . . . . . . . . . . . . . . . . 147
Figure 5-6. TSDB Data Flow, Top Level, Second Insertion Pass . . . . . . . . . . . . . . . . . . . . . 148
Figure 5-7. TSDB Data Flow, Top Level, Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Figure 5-8. TSDB Data Flow, Top Level, ATPG Pattern Generation. . . . . . . . . . . . . . . . . . 150
Figure 5-9. TSDB Data Flow, Top Level, ATPG Pattern Generation with Pattern Retargeting

December 2017
List of Figures
151
Figure 6-1. Example Chip with PLL Embedded Inside Lower Core . . . . . . . . . . . . . . . . . . 155
Figure 6-2. Active OCCs During Internal Test Modes of corec and coreb . . . . . . . . . . . . . . 156
Figure 6-3. Active OCCs During Internal Test Modes of corea and coreb . . . . . . . . . . . . . . 157
Figure 6-4. Active OCCs During Test Modes of Top Level . . . . . . . . . . . . . . . . . . . . . . . . . 158
Figure 6-5. Wrapped Core Boundary Scan Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Figure 7-1. DFTVisualizer Quality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Figure 7-2. Trace Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Figure 7-3. Tracing Down One Hierarchical Level from a Selected Pin. . . . . . . . . . . . . . . . 208
Figure 7-4. Tracing Up One Hierarchical Level from a Selected Pin . . . . . . . . . . . . . . . . . . 209
Figure 7-5. Hierarchical Schematic Window Display with Net Bundling Off . . . . . . . . . . . 211
Figure 7-6. Same Display with Net Bundling On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Figure 7-7. Attributes in DFTVisualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Figure 7-8. Configuration Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Figure 7-9. Design Browser Tabbed Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Figure 7-10. Design Browser Window with Library Tab Active . . . . . . . . . . . . . . . . . . . . . 257
Figure 7-11. DRC Violation Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Figure 7-12. Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Figure 7-13. Flat Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Figure 7-14. Hierarchical Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Figure 7-15. Configuration Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Figure 7-16. Global Search Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Figure 7-17. Test Structures Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Figure 7-18. Text Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Figure 7-19. Console Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Figure 7-20. Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Figure 8-1. 200ns Timing Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Figure 8-2. Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Figure 8-3. Timing Diagram for Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Figure 8-4. Load_Unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Figure 8-5. Timing Diagram for Load_Unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Figure 8-6. Shadow_Control Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Figure 8-7. Master_Observe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Figure 8-8. Shadow_Observe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Figure 8-9. Sequential Transparent Circuitry Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Figure 8-10. Skew_Load Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Figure 8-11. Skew_load applied within Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Figure 8-12. Full Ram Sequential Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Figure 8-13. Full Clock Sequential Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Figure 8-14. Init_force Procedure Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Figure 9-1. tessent_test_clock and tessent_shift_capture_clock Creation. . . . . . . . . . . . . . . 399
Figure 9-2. Generated Clock Muxed Multi-Clock Memories . . . . . . . . . . . . . . . . . . . . . . . . 404

December 2017
List of Tables
Table 1-1. Tessent Shell Command Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Table 1-2. Commands for Tcl Command Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 2-1. Application-Specific Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Table 2-2. Tessent Shell Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Table 2-3. Tessent Shell System Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 2-4. Tessent Shell Context and System Mode Commands . . . . . . . . . . . . . . . . . . . . . 31
Table 3-1. Commands That Interact With Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 3-2. Design Introspection Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Table 3-3. Attribute Introspection Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 3-4. Design Editing Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 3-5. Design Editing Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Table 5-1. Core-Level TSDB Data Flow Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . 142
Table 5-2. Top-Level TSDB Data Flow Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . 146
Table 7-1. Windows Between Which You Can View Instances . . . . . . . . . . . . . . . . . . . . . 198
Table 7-2. Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Table 7-3. Icons for Managing Attributes and Callouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Table 7-4. DFTVisualizer Preferences Dialog Box, Attributes Tab . . . . . . . . . . . . . . . . . . . 224
Table 7-5. What is Added to the Flat/Hierarchical Schematic and Data Windows . . . . . . . 250
Table 7-6. Design Browser Window Instance Type Icons . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Table 7-7. Design Browser Window Data Menu Choices . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Table 7-8. Configuration Data Window Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Table 7-9. Console Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Table 7-10. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Table 8-1. Reserved Punctuation Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Table 8-2. Procedure File Tool Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Table B-1. Common Dofile Issues and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Table B-2. Common Tcl Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

December 2017
List of Tables

December 2017
Chapter 1
Tessent Shell Introduction
Tessent Shell is a platform from which you can run all the Tessent tools. The platform includes
a shared design data, a common database, and powerful scripting utilities that provides a fully
automated DFT flow as well as the ability to customize the flow to fit specific requirements.
What Is Tessent Shell? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
What Can You Do With Tessent Shell?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tessent Shell Tcl Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Command Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tcl Command Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
What Is Tessent Shell?

Tessent Shell is a design-for-test environment within which you can perform all the tasks
required to insert DFT hardware, generate manufacturing test patterns, and post-silicon tasks
such as diagnosis and yield analysis.
Tessent Shell provides a flexible design flow that supports a high-level of automation at the
same time that it allows you to customize flows to your requirements. Key aspects of the
environment that support automation as well as enhance flexibility are:
• Shared data model: Tessent Shell uses data models to store your design data. These
models are shared across all tools and functions, and you can access the data stored
within them for purposes of customizing your own design flow.
For standard automated flows, you do not need to be aware of this infrastructure. For
those that need to customize design flow steps that are not supported by the native tool
commands, you have the same access to the design data model as the Tessent Shell tools
do.
For more information about the data models, refer to “Design Data Models.”
• Attributes: Attributes are characteristics associated with design objects, such as library
cell, pins and modules, that are stored within data models. Some are pre-defined, and
you can also create your own attributes. Using attributes increases visibility into your
design, allowing you to manipulate and query attributes on the design objects.

December 2017
What Can You Do With Tessent Shell?
• Design introspection: Examine the design objects and attributes stored within the data
models. Introspection allows you to retrieve the design data you need so that you can
using Tcl scripting techniques to automate your own custom designs flows.
For more information about design introspection, refer to “Design Introspection.”
• Tcl: Use this common scripting language across all Tessent tools and functions.
Through scripting, you can jump into and out of the Tessent Shell out-of-the-box flows
as needed for your design requirements.
For more information about Tcl usage, refer to “Tessent Shell Tcl Interface.”
• Tessent Shell Database (TSDB): The TSDB is a database that stores all the directories
and files that Tessent Shell generates as you move through a design flow. The TSDB
enhances flow automation by acting as the central location where any Tessent tool can
access the data it requires for the current task, whether that task be reading in a design,
performing DRC, inserting logic test hardware, or performing ATPG pattern generation.
For more information about the TSDB, refer to “TSDB Data Flow for the Tessent Shell
Flow.”
• IJTAG automation: By default, the DFT instruments you create and insert with Tessent
Shell are controlled through an IJTAG network and protocol (IEEE 1687). Tessent Shell
automatically inserts the IJTAG infrastructure, which simplifies test setup and control of
all the instruments.
For more information about IJTAG, refer to the “Tessent IJTAG User’s Manual.”

The Tessent Shell platform is a jumping-off point for accomplishing a full array of DFT tasks.
Specific DFT tasks may require different licenses but all tools are launched from and managed
through Tessent Shell.
DFT tasks include:
• Instrument insertion — Generate and insert logic test hardware such as EDT (embedded
deterministic testing) and OCC (on-chip clock controller), in addition to LogicBIST,
MemoryBIST, in-system test, and boundary scan.
• Scan analysis and insertion — Perform scan analysis and scan chain insertion.
• ATPG — Generate ATPG patterns and perform fault simulation, which includes
compression technology.
• Defect diagnosis and yield analysis — Perform test failure diagnosis to determine a
defect’s most probable failure mechanism and statistical analysis of diagnostic failures
to find systemic defects.

December 2017
In addition, Tessent Shell provides general purpose design editing support so that you can
modify your design netlists, as needed. You can work on the command line as described in
“Design Editing” or used the DFTVisualizer graphical interface.
If you are getting started with Tessent Shell, refer to “Tessent Shell Work Flows” for
information about the Tessent Shell work flow for RTL and scan DFT insertion.

December 2017
Tessent Shell Tcl Interface
Tessent Shell Tcl Interface

The Tessent Shell environment uses a Tcl command-based interface that you use from the
command line or by using dofile scripts.
The Tcl interface supports Tcl constructs, such as variables, command substitution, flow
control, and procedures. You can embed Tcl constructs in tool commands and embed tool
commands within Tcl constructs the same as any Tcl command.
For guidelines about using Tcl in Tessent Shell, and information about converting existing
dofiles and using special characters, refer to “The Tessent Tcl Interface” appendix.
Command Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Tcl Command Registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Command Conventions
Tessent Shell provides a unified Tcl-style command set and naming convention. Commands
that begin with a certain first word (for example, “get” in get_attribute_value_list) perform
operations on the current data model.
Table 1-1 provides a summary listing by command first word of the Tessent Shell commands.
Refer to the Tessent Shell Reference Manual for a complete list of commands and options. You
can also use the “help” command with a wildcard to see a complete list of commands that start
with the same word:
> help get_*
Table 1-1. Tessent Shell Command Conventions

Command First Word Types of Operations Performed
append_ Operates on collections. Refer to “Collections” for more
compare_ information.
copy_
filter_
foreach_
index_
remove_
sizeof_
sort_

December 2017
Command Completion
Table 1-1. Tessent Shell Command Conventions (cont.)

Command First Word Types of Operations Performed
get_ Returns data strings, or collections of lists, objects, or
object attributes from the design object model for
introspection.
read_ Reads files into memory, such as libraries and netlists.
report_ Displays information about a specific item, such as the
current context or licenses currently checked out.
set_ Specifies options, contexts, modes, attributes, and the
current design. Refer to “Contexts and System Modes”
and “Object Attributes” for more information.
write_ Writes design data to a file or set of files.
Command Completion
In the Tessent Shell interface, you can use the Tab key to complete command names, command
option names, and command option values. If the command you type is ambiguous, pressing the
Tab key lists all matching commands. Additionally, within a command, pressing the Tab key
can match variable names with $.
Many Tessent Shell commands are constructed as follows:
command_name command_options command_option_values
For example:
set_config_value -in_wrapper /TopBuilder(CHIP)
Using Tab key completion, you can complete each of the command parts (name, options, and
option values).
For information about Tcl shell handling in Tessent Shell, refer to the set_tcl_shell_options
command.
Command Name Tab Completion

As an example of command name completion, you can abbreviate the get_attribute_list
command in the Tessent Shell interface by typing the following:
SETUP> g_a_l <tab>
Pressing the Tab key after the string completes and expands the command so that it looks like
this:
SETUP> get_attribute_list

December 2017
Dofile Transcription
Command Option Name Tab Completion

Tab completion for command option names is available for most commands. For example:
SETUP> get_config_value -m<tab>

-meta_id -meta_name -meta_object
SETUP> get_config_value -meta_
Command Option Value Tab Completion

Tab completion for command option values is available for the following value types:
• Configuration data path

• Enum values
Configuration Data Path Example
In this example, pressing the Tab key on the partial configuration data path completes the path:
SETUP> set_config_value -in_wrapper /TopB<tab>

SETUP> set_config_value -in_wrapper /TopBuilder(CHIP)/
Enum Value Example

In this example, using the Tab key lists the supported time values -time_unit option to the
get_config_value command:
SETUP> get_config_value -time_unit <tab>

as_is fs ms ns ps s us
SETUP> get_config_value -time_unit
Dofile Entries
Although you can use minimum typing of commands in Tessent Shell dofiles, it is best to
always use the full command name in all cases. There is no fixed minimum typing for any
command or option, and current minimum typing could change in a future release due to the
addition of new commands or options.
Dofile Transcription
By default, the transcript style is Full, which means the tool writes out all commands read from
a dofile before any Tcl evaluation occurs. The command appears in the transcript as entered but
is commented out. During the Tcl evaluation, Tcl commands are written to the transcript as
follows:
• The tool writes all commands from the dofile with a “// command:” prefix. This includes
Tessent Shell commands, Tcl commands, and complete loop, if/else constructs.

December 2017
Tcl Command Registration
• The tool writes all commands embedded in Tcl constructs to the transcript as executed
with a “// sub_command:” prefix. Tessent Shell completes the variable and command
substitutions and writes the resolved values in the loop to the transcript.
Note
This does not apply to introspection commands. Introspection commands are not
written to the transcript again as subcommands.
• The tool indents nested dofiles when they are written to the logfile.
• The tool can read a Tcl routine similar to a dofile. If you issue the source command
(>source my_report_env), then all the Tcl commands in the routine are not transcripted.
Control the Tessent Shell transcription behavior using the set_transcript_style command.
For information about modifying existing dofiles for use with the Tessent Shell Tcl interface,
refer to “Guidelines for Modifying Existing Dofiles for Use with Tcl.”

You can convert any Tcl procedure into a Tessent Shell application command. This enables you
to implement functionality in Tcl and register that functionality as a command so that Tessent
Shell handles it like any other built-in command. Like any built-in command, newly registered
Tcl commands support Tab completion, and you can control its availability relative to the
context and system mode. The help system also includes the new command.
The following commands allow you to register new commands and to define arguments and
options for the commands.
Table 1-2. Commands for Tcl Command Registration
Command Description
display_message Controls messages produced by Tcl commands.
lock_current_registration Locks all current Tcl commands.
register_tcl_command Registers a Tcl command.
unregister_tcl_command Unregisters a Tcl command.
When you first execute the new command, the tool performs syntactic and semantic checks, and
provides the parsed results to your Tcl implementation of the command. The tool also provides
a mechanism to automatically define and register user-defined commands at tool invocation.
For more information about creating your own application commands, refer to the examples
included with the register_tcl_command description in the Tessent Shell Reference Manual.

December 2017

December 2017
Chapter 2
Tool Invocation and Basic Concepts
In the Tessent Shell environment, setting the context and system mode orients the tool as to
which task you will be performing. The tool uses design data models to store the relevant data
about your design.
Tool Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Contexts and System Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Design Data Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

December 2017
Tool Invocation
Tool Invocation
When you invoke Tessent Shell, the tool starts up in setup mode.
Invoke Tessent Shell from a Linux shell using the following syntax:
% tessent -shell
To use most Tessent Shell functionality, you must load a cell library after invocation, which you
can do with the read_cell_library command.
Refer to the tessent shell command description in the Tessent Shell Reference Manual for
additional invocation options.
Tessent Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Tessent Shell Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Tessent Startup File

During invocation, Tessent Shell reads the .tessent_startup startup file. You can use this startup
file for both general and tool-specific settings. The default location for the startup file is the
home directory: $HOME/.tessent_startup.
This startup file is common to the contexts listed in Table 2-2 on page 28.
Tessent Shell Environment Variables

Tessent Shell provides environment variables for Tessent Shell environment operation in
addition to application-specific environment variables. During invocation, the tool reads all
environment variables that you have set.
Table 2-1 lists the environment variables that you can set for Tessent Shell environment
operation. For information about application-specific environment variables, see the “Managing
Mentor Graphics Tessent Software” manual.
Table 2-1. Application-Specific Environment Variables
Variable Default Value and Description
TESSENT_LICENSE_ Specifies the order that Tessent tools check out licenses. The
ORDER list of licenses uses the same terminology accepted by the
command “set_context -license”.
TESSENT_STARTUP Default: No default
The pathname of a directory that contains a Tessent tool
startup file.

December 2017
Tessent Shell Environment Variables
Table 2-1. Application-Specific Environment Variables (cont.)

Variable Default Value and Description
TESSENT_TMP_LOCATION Specifies the location at which the tool creates the
.tessent.tmp.hostname.process_id scratch directory. For more
information, see the get_scratch_directory command
description in the Tessent Shell Reference Manual.
TESSENT_UNDERSCORE_ Directs the tool to only allow commands that use the
COMMANDS_ONLY underscore style. When this environment variable is set to any
value, the legacy commands that used spaces are disabled. For
example, the tool would accept analyze_drc_violation but
would not accept “analyze drc violation”.
.

December 2017
Contexts and System Modes
Contexts and System Modes

One of the first tasks you perform after invoking Tessent Shell is setting the context and system
mode for the current session.
The term “context” refers to a broad category of functionality that often corresponds to a
specific point tool, product, or license feature, such as Tessent FastScan. Each context includes
several system modes, which specifies the tool’s current state of operation. By setting the
context and then the system mode, you indicate the type of tasks you want Tessent Shell to
perform.
In addition, you must specify the design level at which Tessent Shell will be executing tasks.
Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
System Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Context and System Mode Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Design Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Contexts
The context specifies the functional category of tasks you want to perform with Tessent Shell.
Table 2-2 lists the contexts that are currently available.
Table 2-2. Tessent Shell Contexts
Context Description
dft Editing and introspection of the following types of designs: gate-
level Verilog, RTL Verilog, RTL System Verilog, and RTL
VHDL.
dft -edt EDT IP generation and optional insertion. This corresponds to
the IP creation phase of Tessent TestKompress.
dft -logic_bist -edt Configuration, generation, and insertion of the EDT/LBIST
hybrid controller IP. This corresponds to Tessent LogicBIST.
dft -no_sub_context Specifies that a command is only available in the dft context
when no sub-context, such as -scan and -edt, was specified. See
the register_tcl_command in the Tessent Shell Reference Manual
for more information.
dft -scan Scan analysis and scan chain insertion. This corresponds to
Tessent Scan. Additionally in this context you can prepare a
BIST-ready design and include tasks such as x-bounding, MCP/
FP handling, and test point insertion. These features correspond
to Tessent ScanPro.

December 2017
Contexts
Table 2-2. Tessent Shell Contexts (cont.)

Context Description
dft -test_points Test point identification and insertion. The test point
identification algorithm focuses on either pattern count reduction
or improving random pattern testability of the design.
patterns Reverse map top-level failures to the core so that you can
-failure_mapping perform diagnosis with Tessent Diagnosis. Used after performing
scan pattern retargeting within the patterns -scan_retargeting
context.
patterns -ijtag PDL command retargeting for IJTAG (IEEE 1687-2014) plus
extraction of the ICL network from the design.
patterns -scan Test pattern generation and good and fault simulation. This
corresponds to Tessent FastScan and the test pattern generation
phase of Tessent TestKompress. The patterns -scan context
supports uncompressed scan ATPG/fault simulation, EDT
ATPG/fault simulation, and Logic BIST fault simulation.
patterns -scan_diagnosis Test failure diagnosis to determine a defect’s failure mechanism
and location. This corresponds to Tessent Diagnosis.
patterns -scan_retargeting Scan pattern retargeting for retargeting core-level test patterns at
the top level.
patterns -silicon_insight Control, simulate, debug, and characterize BIST-related
memories, logic, PLLs, and SerDes. This corresponds to Tessent
SiliconInsight.
Context Specification
Set the Tessent Shell context using the set_context command. For example:
SETUP> set_context dft -scan
You must set the context after you invoke Tessent Shell and before you can enter most
commands. The set_context command is available only in setup mode. You can use the
get_context command to see the current context.
Prior to setting the context, you can only run a small set of setup commands. These commands
are those that you would typically place inside the startup file.
Context and Licensing

When you set the context, the tool automatically acquires the appropriate license, if available.
Alternatively, you can directly specify the license Tessent Shell acquires by using the
set_context command with the optional -license switch.

December 2017
System Modes
You can control the order in which Tessent Shell checks out licenses by setting the
TESSENT_LICENSE_ORDER environment variable. You provide, as the value of the
environment variable, a space-separated list of licenses using the terminology described for
“set_context -license.” For example:
setenv TESSENT_LICENSE_ORDER “Scan TestKompress IJTAG”
Any available licenses not explicitly listed in the value of the TESSENT_LICENSE_ORDER
environment variable are appended to the list in their original order. The tool issues a warning if
the environment variable contains a license that does not exist.
For more information about specifying a license feature, refer to the set_context command
description in the Tessent Shell Reference Manual. For a complete list of license feature names,
refer to Managing Mentor Grahpics Tessent Software.
System Modes
A system mode in Tessent Shell defines the operational state of the tool. The default system
mode is setup. The available system mode depends on the current context of the tool.
Table 2-3 lists the available system modes.
Table 2-3. Tessent Shell System Modes
System Mode Description
setup Used as the entry point into the tool. Used to define the current
context and specify the design information.
analysis Used to perform design analysis, test pattern generation, PDL
retargeting, and simulation.
insertion Used to perform design editing and introspection.
Change the Tessent Shell system mode using the set_system_mode command. For example:
SETUP> set_system_mode insertion
Context and System Mode Combinations

Together, the context and system modes imply a Tessent Shell task flow from setup to analysis
to insertion when you are working with DFT designs, and from setup to analysis when you are
working with patterns. For example, if you are working on a DFT design while in setup mode,
you cannot perform scan analysis.
The following matrix lists the actions you can perform in the available contexts and system
modes. The tool filters out the functionality that does not apply to the context/mode you are
currently in and issues an error when you attempt to perform a task not within the scope of the
current context/system mode.

December 2017
Design Levels
Context Setup Mode Analysis Mode Insertion Mode

dft • Read and configure design • Scan analysis • RTL or gate-
• Prepare for design editing, • Test point analysis level design
editing with
IP creation, scan insertion, • EDT IP creation
test point analysis and design
• Hybrid TK/LBIST IP introspection
insertion creation
• MemoryBIST IP creation
• Boundary scan IP
creation
• In-System Test IP
creation
patterns • Read and configure design • ATPG/fault simulation (not applicable)
• Define test pattern • PDL retargeting
generation type to perform: • Scan pattern retargeting
scan, IJTAG • Execute an IJTAG test
• IJTAG pattern
• Execute an IJTAG test • Perform SimDUT
pattern simulation
• Perform SimDUT
simulation
The tool provides a set of commands that allow you to interact with contexts and system modes.
Table 2-4. Tessent Shell Context and System Mode Commands
Command Description
get_context Returns the current context as specified by the set_context
command. Also returns inferred subcontexts, such as whether
patterns -scan is configured to perform LogicBIST or ATPG.
set_context Sets the current context and its options.
set_system_mode Sets the system mode.
Design Levels
When working with DFT designs—that is, you are working in context dft—you must set the
design level at which you are performing tasks. There is no default setting for the design level.
The available design levels are chip, physical block, and sub-block. For flat designs, you always
work at the chip level. For hierarchical designs, it is crucial to differentiate whether you are
work at the top-level (chip) or at lower levels within physical blocks or sub-blocks. Refer to
“Hierarchical DFT Terminology” for definitions of these terms.

December 2017
Design Levels
For complete information, refer to the set_design_level command description in the Tessent
Shell Reference Manual.

December 2017
Design Data Models
Design Data Models

Tessent Shell has the following data models: the hierarchical design data model, the flat design
data model, and the ICL data model. Each of these data models contains one or more design
objects, such as pins and modules, and each design object is associated with a set of attributes,
such as an ID or bit-width of a bus.
For a complete description of the various data models, object types, and attributes, refer to the
“Data Models” chapter in the Tessent Shell Reference Manual.
Flat Design Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Hierarchical Design Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ICL Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Flat Design Data Model

The flat design data model is an internal, flattened representation of a hierarchical design that
the tool creates when entering analysis mode. You can also explicitly create the flat model using
the create_flat_model command.
The flat design data model consists of gates that are connected together. A gate is an instance of
a primitive module, and a gate_pin object represents a pin on a gate instance. Gate_pin objects
have no unique instance name. Instead they have a unique ID that differentiates one from
another. The format of the ID is two integers separated by a period character. The first integer
represents the gate ID, and the second integer represents the pin index (where 0 is the output
pin, 1 is first input pin, and so on). However, this ID does not remain in place from one netlist
version to the next or from one Tessent Shell invocation to the next. For this reason, you should
avoid hard-coding this ID into a script.
Note
You can preserve hierarchical pins in the flat model by using the set_attribute_options
-preserve_boundary_in_flat_model option.
For more information about the flat design data model and the gate_pin object type, refer to
“Flat Design Data Model” in the Tessent Shell Reference Manual.
Hierarchical Design Data Model

Tessent Shell translates your design netlist into a hierarchical design data model in memory
when you load the design into the tool using a command such as read_verilog. The design data
remains in memory during the Tessent Shell session until you delete the model or exit the tool.

December 2017
Hierarchical Design Data Model
The hierarchical design data model contains the following object types:
• Module — A basic building block of your design. A module can be a Verilog module, a
Tessent library model, or a built-in primitive.
• Instance — A single instantiation of a module.
• Port — An input, output, or inout interface of a module.
• Pin — An input or output interface of an instance.
• Net — A wire that connects the pins of instances.
• Pseudo_port — Represents a user-added primary input or primary output.
These object types are described in detail in the “Data Models” chapter of the Tessent Shell
Reference Manual.
Use the set_current_design command to designate one module within your design as the current
design. Instances, pins, and nets are hierarchical objects defined relative to the current design.
Figure 2-1 shows a hierarchical design upon which many of the examples in this chapter are
based. The label above the elements is the instance name while the label below the elements is
the module name. For example, the module name of the AND gate in the upper-left corner is
and3, and its instance name is u1.
The dashed boxes are modules instantiated in the parent module. For example, module modc is
instantiated inside of module modb. Its complete instance path is u4/u5.
Figure 2-1. Hierarchical Design Example

December 2017
ICL Data Model
ICL Data Model

The Instrument Connectivity Language (ICL) describes the elements that comprise the IJTAG
network as well as their logical (though not necessarily physical) connections to each other and
to the instruments at the endpoints of the network.
ICL bears a loose resemblance to a hierarchical netlist such as Verilog; it is organized by
modules that may contain instances of other modules, and it describes the connections between
the pins of the instances. However, it is important to note that ICL is not a complete netlist. The
connections are port-to-port rather than through nets, and ICL uses abstraction rather than
include the detailed physical construction of the circuitry. That is, ICL represents only the
behavioral operation of the network.
The ICL data model defines objects as one of the following four data types: icl_module,
icl_instance, icl_port, and icl_pin.
Each icl_module object has its list of icl_port objects. Once the current design is set using the
set_current_design command, the ICL data model is elaborated downward from the current
design and icl_instance objects are created for each instance of icl_module, and icl_pin objects
are created for each port of the modules associated to the icl_instances. The icl_instance and
icl_pin objects are hierarchical objects and therefore only exist after the current design is set.
For more information about the ICL data model and the icl_module, icl_instance, icl_port, and
icl_pin object types, refer to “ICL Data Model” in the Tessent Shell Reference Manual.
Object Attributes
Each design object in a design data model has a list of characteristics, called attributes, attached
to that object. For example, each pin has an attribute that specifies its hierarchical name and its
parent instance. There are both predefined and user-defined attributes.
Predefined attributes provide access to information known to the tool such as the name of a
module or the direction of a pin. All design objects have some predefined attributes, and every
design object can have user-defined attributes as well. For a complete list of attributes for each
type of data model, refer to “Data Models” chapter in the Tessent Shell Reference Manual.
The process for creating a new user-defined attribute is called registration. The predefined
attributes, unlike the user-defined attributes, do not need to be registered.
You must register each new user-defined attribute and specify a default value before you can
use the attribute. If you want to later change the default value, you must unregister and then re-
register the attribute. For more information about the registration process, refer to the
description of the register_attribute command in the Tessent Shell Reference Manual.
You can query any attribute and change any user-defined attribute. Most predefined attributes
are read-only, although some are read-write, such as the is_hard_module attribute.

December 2017
Object Attributes
You can filter and sort objects based on the attributes and their values. The filter_collection and
sort_collection commands perform these operations. For more information about filtering
attributes, refer to “Attribute Filtering Equation Syntax” in the Tessent Shell Reference Manual.
Intuitively named “get_” commands return collections of objects from the data model and the
model’s attributes that you can use for design introspection of various design objects.

December 2017
Chapter 3
Design Introspection and Editing
Tessent Shell provides a full range of commands for examining (introspecting) and editing
designs.
Along with the command-line interface, Tessent Shell provides a graphical user interface,
DFTVisualizer, that allows you to edit and introspect designs, and adjust object attributes. For
details, refer to “DFTVisualizer” on page 183.
Design Introspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Design Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Simulation Contexts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

December 2017
Design Introspection
Design Introspection
Tessent Shell introspection commands allow you to examine the design objects within a design
data model. They provide access to the tool’s internal data structures, giving you the flexibility
of Tcl scripting while keeping all compute-intensive processing in the tool’s backend. The
commands operate on object specifications that you include as arguments to the commands, and
they return collections.
Note
Some restrictions apply to design introspection. You can introspect only simple or vector
port, pin, or net object types. You cannot introspect ports, pins, or nets of complex System
Verilog or VHDL modules. Examples for such complex objects are multi-dimensional ports or
record ports.
Object Specification Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Collections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Introspection Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Design Introspection Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Object Specification Format

An object specification lists the design objects (such as instances, pins, or nets) that will be
acted upon by the specified command. The object specification can be the name of an object, a
Tcl list of names of objects, or a collection of objects. For design objects that have unique IDs,
like instances, you can use the IDs as the object names.
The following examples show the add_display_instances command with valid object
specifications listed within square brackets or curly brackets.
add_display_instances [get_instances u*] -display hierarchical_schematic
add_display_instances [list u1 u2 u3] -display hierarchical_schematic
add_display_instances {u1 u2 u3} -display hierarchical_schematic
These commands display the results in DFTVisualizer.
All Tessent Shell commands operating on user-specified objects accept object specifications as
arguments.
Collections
Collections are an extension of Tcl that are specific to Tessent Shell applications. Native Tcl
commands such as “foreach” and “puts” do not recognize collections. A collection represents a
group of zero (an empty set) or more design objects.

December 2017
Collections
Design introspection commands return collections of objects. The objects are stored in the
internal data structures, and the tool returns a string handle to this collection. The string handle
is a “@” character followed by a numeric ID (in this case, “@1”). The entire data volume
remains in the tool’s internal data structures, so the Tcl interface is not overloaded with large
amounts of data.
Introspection commands issued directly from the shell display the “name” attribute of the first
50 elements of the collection, because the name is more useful than displaying the collection’s
ID. However, names are not displayed in non-interactive mode such as when executing a dofile.
The following example demonstrates the use of the get_instances and get_name_list commands
to return collections of objects:
SETUP>set var1 [get_instances u* -hierarchical –of_modules MOD1]

{u1 u2 u3 u4 u5 u6 u7}
SETUP>puts $var1@1
SETUP>puts [get_name_list $var1]
u1 u2 u3 u4 u5 u6 u7
In this example, the first command returns a collection of names. The objects are stored in
internal data structures, and the tool returns a string handle to this collection which is “@”
followed by a number ID (“@1”).
In the following example, the collection created by the get_instances command is stored in the
variable instCollection (which means that the collection is referenced).
set instCollection [get_instances -of_type cell]
Tessent Shell deletes the collection when you unset the variable instCollection or set the
variable to a new value, or when the Tcl variable(s) referring to the collection go out of scope.
In the following example, the collection created by the command get_pins is passed to the
get_attribute_value_list command. This means that the collection is referenced.
get_attribute_value_list [get_pins u1/a*] -name direction
Tessent Shell deletes the collection when the command get_attribute_value_list returns a value.
Collections can refer to objects that no longer exist because they have been deleted using editing
commands, such as delete_pins. The built-in attribute “is_valid” is set to false when an object
has been deleted. All commands that accept collection pointers as input automatically ignore
objects with the “is_valid” attribute set to false.

December 2017
Collections
Persistence of Collections
The tool references a collection when the collection is stored in a Tcl variable or when it is
passed to a command or procedure. The tool automatically deletes a collection when it is no
longer referenced.
You should not use Tcl built-in commands that expect a Tcl list, such as the foreach command,
with collections. When you pass a collection to this type of command, the command
dereferences the collection and, as a result, deletes the collection.
How to Transcript the Contents of Collections

Use the get_name_list command to return a list of the names of all the elements in the
collection. So, to transcript the names in the log file, you can use the “puts” command with
get_name_list (or any other Tessent get_* command):
Commands That Work With Collections or Tcl Lists

Tessent Shell provides commands that create, manipulate, and query collections. Table 3-1
presents some Tessent Shell commands based on how they interact with collections.1
Table 3-1. Commands That Interact With Collections
Commands that... Command Name
Create collections or Tcl lists get_attribute_list
get_attribute_option
get_attribute_value_list
get_current_design
get_fanins
get_fanouts
get_gate_pins
get_instances
get_modules
get_name_list
get_nets
get_pins
get_ports
1. The table does not list all the applicable commands. Refer to the Tessent Shell Reference Manual.

December 2017
Introspection Examples
Table 3-1. Commands That Interact With Collections (cont.)

Operate on collections add_to_collection
append_to_collection
compare_collections
copy_collection
filter_collection
foreach_in_collection
index_collection
remove_from_collection
sort_collection
Read and write attributes of objects get_attribute_list
found within collections or Tcl lists
get_attribute_value_list
report_attributes
set_attribute_value
Design introspection allows you to create procedures to show design data of interest, create and
set attributes, create and manipulate collections, create custom reports, and other tasks.
Example of Creating a Procedure to Show Flip-Flop Fanouts

The following example is based on Figure 2-1 on page 34 and creates a procedure called
show_fanouts that returns the fanouts of a specified flip-flop.
proc show_fanouts {flop} {

set ff_fanout [get_fanouts $flop/Q]
puts "$flop/Q is connected to: [get_name_list $ff_fanout]"
}
The following two examples show how to use the show_fanouts procedure you just created.
> show_fanouts u2
u2/Q is connected to : u4/u4/A0 u4/u1/A1
> foreach_in_collection ff [get_instances * -of_module dff* -hierarchical]

{show_fanouts [get_name_list $ff]}

December 2017
u2/Q is connected to: u4/u1/A1 u4/u4/A0

u7/Q is connected to: O3 u6/A0 u5/u3/A1 u5/u4/S0
u4/u2/Q is connected to: u4/u3/D
u4/u3/Q is connected to: u6/A1 u5/u1/A1
u4/u5/u2/Q is connected to: u5/u4/A0
u5/u2/Q is connected to: u5/u1/A0 u5/u3/A0
u4/u5/u3/Q is connected to: u6/A2
Example of Displaying the Number of Input Ports

The following example displays the number of input ports on modules (objects with names that
begin with “mod” in Figure 2-1).
> set mods [get_modules mod* -of_type design]

> foreach_in_collection itr $mods \{puts "The number of input ports of
[get_attribute_value_list $itr -name name] \is
[sizeof_collection [get_ports -of_module $itr -direction input]]"}
The number of input ports of modb is 6
The number of input ports of modc is 4
The number of input ports of modd is 4
The design in Figure 3-1 is identical to Figure 2-1, with the addition of colors to help you
understand the examples that follow.
Figure 3-1. Hierarchical Design Example With Colors
Example of Creating Attributes and Manipulating Collections

The following example is based on Figure 3-1 and shows the complete process of creating and
setting user-defined attributes, and then creating and manipulating collections.

December 2017
register_attribute -name color -value_type string -default "blue" -enum "red green blue"
-object_types instance
# Set the “color” attribute of each instance to match Figure 3-1
set_attribute_value {/u4/u4 /u4/u5/u3 /u5/u2} -name color -value "green"
{u4/u4 u4/u5/u3 u5/u2}
set_attribute_value {u1 u2 u6 /u4/u5/u1 /u4/u3 /u5/u4 /u5/u3} -name color

-value "red"
{u1 u2 u6 u4/u5/u1 u4/u3 u5/u4 u5/u3}
set_attribute_value {u3 u7 /u4/u1 /u4/u2 /u4/u5/u2 /u5/u1} -name color

-value "blue"
{u3 u7 u4/u1 u4/u2 u4/u5/u2 u5/u1}
# Create collections of instances with the same color values

set all_inst [get_instances -of_type cell]
{u1 u2 u3 u6 u7 u4/u1 u4/u2 u4/u3 u4/u4 u4/u5/u1 u4/u5/u2 u4/u5/u3 u5/u1
u5/u2 u5/u3 u5/u4}
set red_inst [filter_collection $all_inst {color == "red"}]

{u1 u2 u6 u4/u3 u4/u5/u1 u5/u3 u5/u4}
set blue_inst [filter_collection $all_inst {color == "blue"}]

{u3 u7 u4/u1 u4/u2 u4/u5/u2 u5/u1}
set green_inst [filter_collection $all_inst {color == "green"}]

{u4/u4 u4/u5/u3 u5/u2}
# Manipulate the collections and create additional collections

puts "Number of red cells in the design: [sizeof_collection $red_inst]"
Number of red cells in the design: 7
puts [compare_collections $red_inst $blue_inst]

1
set red_green [add_to_collection $red_inst $green_inst]

{u1 u2 u6 u4/u3 u4/u5/u1 u5/u3 u5/u4 u4/u4 u4/u5/u3 u5/u2}
set sort_red [sort_collection $red_inst name -descending]

{u6 u5/u4 u5/u3 u4/u5/u1 u4/u3 u2 u1}
Example of Displaying Attribute Values of a Collection

After Tessent Shell has executed the previous commands, the following commands display the
colors assigned to gates in the collection named ANDs.
> set ANDs ""> append_to_collection

ANDs [get_instances -of_type cell -filter {module_name == "AND"}]
> foreach_in_collection itr
$ANDs {puts "The color value for \[get_attribute_value_list
$itr -name name] is [get_attribute_value_list \$itr -name color] "}

December 2017
The color value for u1 is red

The color value for u4/u4 is green
The color value for u4/u5/u1 is red
As an alternate way to register the attribute in the previous example, you can use the
register_attribute command as shown here:
register_attribute -name is_red -value_type bool \-object_types “instance"

–description "True if color is red."
So, instead of using the color attribute with enumerated values of red, green, and blue as shown
previously, you could instead register three Boolean type attributes of is_red, is_green, and
is_blue. This allows you to use Boolean values for filtering and tracing. For example:
> set red_inst [filter_collection $all_inst {is_red}]
Example of Changing an Attribute of a Collection

The following command example is based on Figure 3-1 and shows how to change the color
attribute of a collection of DFFs to green.
> set DFFs [get_instances -of_modules dff]
# display all of the instances that have a color attribute of blue

> set all_blue [filter_collection $all_inst "color == blue"]
{u7 u4/u2 u4/u5/u2}
# change all instances in the collection DFFs to have a “color” attribute

value of green
> set_attribute_value $DFFs -name color -value green
# now check the results

> set all_green [ filter_collection [$all_inst {color == "green"}] ]
{u2 u7 u5/u2 u4/u4 u4/u2 u4/u3 u4/u5/u2 u4/u5/u3}
Example of Removing Duplicate Objects from a Collection

The following example shows how to create a collection containing three duplicate objects and
then remove the duplicate objects from the collection.
> set t [get_instances {u3 u3 u3}]

{u3 u3 u3}
> sizeof_collection $t
3
> set tt [add_to_collection "" $t -unique]

{u3}
> sizeof_collection $tt

1

December 2017
Design Introspection Command Summary
Example of Creating a Custom Report

The following example creates a collection of all instance objects with a leaf name starting with
“u” and then displays ten instance names per row.
set cnt 0
set line ""
foreach_in_collection element [get_instances u* -hierarchical] {
if {$cnt < 10} {
append line "[get_single_name $element] "
incr cnt
} else {
puts $line
set line ""
append line "[get_single_name $element] "
set cnt 1
}
}
if {$cnt > 0} {puts $line}

The design introspection commands include the get_ commands as well as various commands
for manipulating attributes.

Table 3-2 lists the common design introspection commands. Refer to the Tessent Shell
Reference Manual for more information.
Table 3-2. Design Introspection Commands
Command Name Description
get_common_parent_instance Returns the common ancestor of all instances, pins, or
nets found in object_spec.
get_current_design Returns a collection of one element that specifies the top-
level design when previously set.
get_design_level Returns the design level previously defined with the
set_design_level command.
get_fanins Returns a collection of all objects found in the fanin of
the specified pin, net, or port objects.
get_fanouts Returns a collection of all requested objects found in the
fanout of the specified pin, net, or port object.
get_gate_pins Returns a collection of all gate_pin objects found below
the current design in the flat model.
get_instances Returns a collection of instances relative to the current
design.

December 2017
Table 3-2. Design Introspection Commands (cont.)

get_modules Returns a collection of modules.
get_nets Returns a collection of nets relative to the current design.
get_pins Returns a collection of pins relative to the current design.
get_ports Returns a collection of ports on a given module.
Attribute Introspection Command Summary

Table 3-3 lists all of the commands that introspect attributes.
Table 3-3. Attribute Introspection Commands
get_attribute_list Lists registered attributes.
get_attribute_option Returns the current setting of an attribute's option.
get_attribute_value_list Returns the attribute's value.
get_name_list Returns the name attribute of the specified objects.
get_single_name Returns a string with the name of the element specified by the
object_spec argument.
register_attribute Registers a new attribute by adding it to the attribute manager.
report_attributes Prints a report for the registered attributes.
reset_attribute_value Resets the attribute to its default value.
set_attribute_options Configures attribute options.
set_attribute_value Defines the attribute's value.
unregister_attribute Makes an attribute unusable by removing it from the attribute
manager.

December 2017
Design Editing
Design Editing
Tessent Shell design editing commands allows you to modify your design after reading in the
RTL or gate-level netlist. Tessent Shell supports gate-level netlist editing or RTL design editing
with full language support, including multiple logical libraries, VHDL, Verilog, and System
Verilog. Parameterized modules are also fully supported.
The Design editing commands allow you to manipulate a design’s modules, instances, nets,
ports, and pins, either interactively or through Tcl scripting.
Note
There are language restrictions. See “HDL Limitations in the Tessent Shell Flow” in the
Tessent Shell Reference Manual for details.
Design editing commands work with collections and introspection commands, as well as native
Tcl commands, to automate many tasks. Table 3-4 presents the common design editing
commands based on the function they perform— that is, whether they create, modify, or remove
elements and so on. For more information on collections and introspection commands, see
“Design Introspection.”
Note
The design editing commands are not available when using some product licenses, such as
Tessent FastScan and Tessent Scan.
Table 3-4. Design Editing Commands

Read netlists and specify logical read_verilog
libraries
read_vhdl
set_logical_design_libraries
Create design elements create_connections
create_instance
create_module
create_net
create_pin
create_port

December 2017
Design Editing Examples
Table 3-4. Design Editing Commands (cont.)

Remove design elements delete_connections
delete_instances
delete_nets
delete_pins
delete_ports
Modify the design copy_module
intercept_connection
replace_instances
uniquify_instances
Set or get editing options get_insertion_option
set_insertion_options
Design Editing Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Design Editing Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

There are many ways to create, modify, and remove elements from your design in a Tcl
scripting environment.
Figure 3-2 is an example design, which is followed by related examples that show some of the
ways you can edit designs within Tessent Shell.

December 2017
Figure 3-2. Hierarchical Design Example
Example of Creating a Module From Scratch

The following example shows how to create module C (modc) in Figure 3-2 as a standalone
module.
set_context dft –no_rtl

set_system_mode insertion
create_module modc
set_current_design modc
create_port I1 -on_module modc -direction input

create_port O1 -on_module modc -direction output
create_port O2 -on_module modc -direction output
create_instance u1 -of_module and2

create_instance u2 -of_module dff
create_instance u3 -of_module dffr
create_connection I1 u1/A0
create_connection I2 u1/A1
create_connection I2 u3/R
create_connection I3 u3/D
create_connection I4 u3/CLK
create_connection I4 u2/CLK
create_connection u1/Y u2/D
create_connection u2/Q O1
create_connection u3/Q O2
write_design -output_file MODC.v -replace

December 2017
Example of Replacing a Module With Another Module

The following example replaces the module definition for instance u5 (modd) to modc. The
original module and the new module have the same pinout, and the connecting nets remain the
same after issuing the replace_instances command. After replacing instance u5 with modc, that
instance u5/u1 changes from an or2 gate to an and02 gate.
INSERTION> get_attribute_value_list u5 -name module_name

modd
INSERTION> get_fanin u5/I1 -stop_on net

{u4_O1}
INSERTION> replace_instances u5 -with_module modc

{u5}
INSERTION> get_fanin u5/I1 -stop_on net

{u4_O1}
INSERTION> set_system_mode setup

SETUP> set_design_level sub_block
SETUP> set_sys_mode analysis
// Flattening process completed, cell instances=15, gates=45, PIs=8
// POs=3, CPU time=0.00 sec.
// -----------------------------------------------------------------
// Begin circuit learning analyses.
// --------------------------------
// Learning completed, CPU time=0.00 sec.
ANALYSIS> report_gates u5/u1

// /u5/u1 and02
// A0 I /u4/u3/Q
// A1 I /u4/u5/u2/Q
// Y O /u5/u2/D
Example of Intercepting a Connection

The following example inserts a simple inverter gate by intercepting the existing connection
between the u7/D pin and the u6/Y pin, shown on the left side of the following figure. After the
interception, the inverter A pin is connected to the u6/Y pin and the inverter Y pin is connected
to the u7/D pin as shown on the right side of the figure.

December 2017
Figure 3-3. Inverter Inception
INSERTION> intercept_connection u7/D -cell_function_name inverter

{insertion_inverter}
Example of Adding Input and Output Pads to a Design

The following commands add input and output pads to a design by creating a collection of port
names from the design, creating a collection of pad names that match the ports, then connecting
the ports and pads together in the design. The example also adds the TAP's IO ports, including
the respective pads.

December 2017
# Setting the context to netlist editing

set_context dft -no_rtl
# Reading the library and all necessary Verilog files

read_cell_library ../libs/libs/adk.atpg
read_verilog ./counter_block2_edt_top_gate.v
read_verilog ../libs/pads/*.v
# Telling the tool, which module 'top' is

set top_module "counter_block2"
set_current_design $top_module
# Now for the editing

set_sys_mode insertion
# First, insert the pad cells for all inputs of the netlist
set inputPortList [ get_ports -of_module $top_module -direction input ]
foreach_in_collection inputPort $inputPortList {
# Creating the name of the pad cell:

# The following lines take care of '[' and ']' in the portname,
# substituting these by '_'. This makes the Tcl-life easier
set portName [lindex [get_name_list $inputPort] 0]
set padName [ string map { \[ _ \] _ } ${portName}_PAD ]
# Adding the pad cell

create_instance $padName -of_module INPAD
# Connecting it up in the netlist

# The first line moves the existing net from the input port to the output
# of the pad cell. The second line creates a new net and connects the
# input port to the input of the pad cell
# Note: We are not connecting anything else here.
# We leave this to boundary scan insertion
move_connection -from $inputPort -to $padName/FP
create_connection $inputPort $padName/IO
}
# Second, insert the pad cells for all outputs of the netlist
set outputPortList [ get_ports -of_module $top_module -direction output ]
foreach_in_collection outputPort $outputPortList {
# Creating the name of the pad cell:

# The following lines take care of '[' and ']' in the portname,
# substituting these by '_'.
set portName [lindex [ get_name_list $outputPort ] 0]
set padName [ string map { \[ _ \] _ } ${portName}_PAD ]

create_instance $padName -of_module OUTPAD_2S
# Connecting it up in the netlist

# The first line moves the existing net from the IO port to the input
# of the pad cell. The second line creates a new net and connects the
# IO port to the output of the pad cell.
# Note: We are not connecting anything else here.
# We leave this to boundary scan insertion
move_connection -from $outputPort -to $padName/TP

December 2017
Design Editing Command Summary
create_connection $outputPort $padName/IO

}
# Next, add the JTAG IO pins and their respective PAD cell. Connecting #
them up.
set inputPortList { TDI TMS TRST TCK }

set outputPortList { TDO }
foreach portName $inputPortList {

set padName ${portName}_PAD
create_instance $padName -of_module INPAD
# Creating an Input IO pin and connecting the pad

create_port $portName -direction input
create_connection $portName $padName/IO
}
foreach portName $outputPortList {

set padName ${portName}_PAD
create_instance $padName -of_module OUTPAD_EN1
# Creating an output pin and connecting the pad

create_port $portName -direction output
create_connection $portName $padName/IO
}
# Write the new netlist

write_design -output_file "${top_module}.v" -replace
exit

The design editing commands allow you to work with modules, connections, instances, nets,
pins, and ports.
The commands listed in the following table are commonly used design editing commands.
Refer to the Tessent Shell Reference Manual for more information.
Table 3-5. Design Editing Command Summary
copy_module Creates an exact copy of a design module and gives it a new name,
which the tool can use as part of create_instance and
replace_instances operations.
create_connections Creates a connection between pin, net, or port objects.
create_instance Instantiates a module (design or cell type) inside of a design module
that is part of the current design.

December 2017
Table 3-5. Design Editing Command Summary (cont.)

create_module Creates a new design module.
create_net Creates a net inside an instance of a design module.
create_pin Creates a pin on an instance of a design module.
create_port Creates a port on a design module.
delete_connections Disconnects the specified pin objects.
delete_instances Removes an instance of a module.
delete_nets Removes net objects inside an instance of a design module.
delete_pins Removes pin objects on an instance of a design module.
delete_ports Removes port objects on a design module.
get_insertion_option Introspects the default values of options affecting many design
editing commands.
intercept_connection Using the get_dft_cell command, obtains a cell with the specified
function name and uses it to intercept a connection to a pin, port, or
net.
move_connections Moves a net connected on one pin or port to another pin or port. The
first pin is left open after the move.
rename_instance Renames the leaf name of an instance object.
replace_instances Replaces the module object used in an instantiation.
set_insertion_options Specifies default values of options affecting many design editing
commands.
uniquify_instances If the module of the specified instance has other instantiations in the
design, the tool copies the module and the specified instance
becomes an instance of the copied module.

December 2017
Simulation Contexts
Simulation Contexts
Tessent Shell provides simulation contexts to aid your design analysis and introspection efforts.
You can use these contexts to create “simulation scratch pads” for rapid investigation of good-
machine behavior of specific portions of your design.
Simulation Context Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Introspection and Analysis Using Simulation Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Simulation Context Overview

Tessent Shell provides commands for creating and managing simulation contexts. From a
particular user-defined simulation context, you can use these commands to apply stimulus
forces to specified gate_pins, run simulation for a specific number of cycles, and then introspect
gate_pins for simulation values.
Commands for Managing Simulation Contexts

Use the following commands to create and manage user-defined simulation contexts, as well as
use predefined simulation contexts:
• add_simulation_context — Creates a new user-defined simulation context.

• copy_simulation_context — Copies the simulation values and forces from one
simulation context to another.
• delete_simulation_contexts — Deletes one or more user-defined simulation contexts.
• get_current_simulation_context — Returns the name of the current simulation context.
• get_simulation_context_list — Returns the available simulation contexts in a Tcl list.
• report_simulation_contexts — Lists the available simulation contexts and indicates the
current simulation context.
• set_current_simulation_context — Sets the current simulation context.
Commands for Managing Stimulus and Simulating within Simulation

Contexts
The following commands are for managing stimulus (simulation forces and clock pulses) and
running limited simulations within a simulation context:
• add_simulation_forces — Forces one or more gate_pin objects to the specified value.

• delete_simulation_forces — Removes forces from one or more gate_pin objects.
• report_simulation_forces — Lists the active forces on the specified gate_pin objects.

December 2017
Introspection and Analysis Using Simulation Contexts
• simulate_clock_pulses — Pulses one or more clocks within the current simulation

context.
• simulate_forces — Simulates the queued forces in the current simulation context.
Commands for Introspection and Analysis within Simulation Contexts

The following commands are for introspection and analysis within simulation contexts, which
includes examining simulation results:
• get_current_simulation_context — Returns the name of the current simulation context.

• get_simulation_context_list — Returns the available simulation contexts in a Tcl list.
• get_simulation_value_list — Returns the simulation values on the specified gate_pin
objects.
• report_simulation_contexts — Lists the available simulation contexts and indicates the
current simulation context.
• report_simulation_forces — Lists the active forces on the specified gate_pin objects.
• set_gate_report — Specifies the information displayed by the report_gates command.
This command allows reporting of simulated values in the current simulation context.
• trace_flat_model — Traces the flat model within the current simulation context. This
command always operates within the current simulation context.
Attributes for gate_pin Objects

For a complete list of attributes, refer to the “Data Models” chapter in the Tessent Shell
Reference Manual.
Simulation Context Data in DFTVisualizer

DFTVisualizer can display the simulation context values in the Flat Schematic after you issue
the “set_gate_report simulation_context” command or select the Data > Simulation Context
menu item.
For more information on displaying simulation data, see “Flat Schematic Window.” For
information on setting the number of simulation characters displayed, see the “Schematics
Preferences Dialog Box.”
Introspection and Analysis Using Simulation

Contexts
Simulation contexts allow you to perform various types of design analysis and introspection.
The four predefined simulation contexts are: stable_after_setup, stable_load_unload,

December 2017
stable_shift, and stable_capture. After setting a simulation context, you can introspect gate_pins
for simulation values based on that specific simulation context. For example, the
trace_flat_model command can do design tracing based on values specified for the current
simulation context.
In order to use any of the following techniques in this chapter, you must be doing the following:
• Operating in the analysis system mode of Tessent Shell.

• Operating on a flattened design, and have read in the test procedure file (if available). At
this point, the values specified in the setup, shift, capture, and load_unload procedures
are in place in the design when you set the corresponding simulation context as current.
Example
For example, if you want to trace the design based on the values specified in the shift procedure,
use the “set_current_simulation_context stable_shift” command. When you use this command
with a small design containing two 2-cell scan chains, the values on the gate_pins display in the
DFTVisualizer Flat Schematic as shown in Figure 3-4.
Figure 3-4. DFTVisualizer Flat Schematic (gate level)
In this case, no values are forced except for sen (scan enable), which is set to 1. Note that the
four possible simulation values are 0, 1, X, and Z.

December 2017
In addition to viewing values in the Flat Schematic, you can get the current simulation values of
gate_pins using any of the following techniques:
• Use the get_simulation_value_list command and specify the desired gate_pin object(s):
ANALYSIS> set_current_simulation_context stable_shift
ANALYSIS> get_simulation_value_list sc2_f1/D
X
• Check the value of the simulation_value attribute for the gate_pins:

ANALYSIS> get_attribute_value_list [get_gate_pin sc2_f1/D]
-name simulation_value
X
• Issue the command “set_gate_report simulation_context,” after which you can use the
report_gates command and the Flat Schematic to display the simulated values from the
current simulation context:
ANALYSIS> set_gate_report simulation_context
ANALYSIS> report_gates sc2_f1
// /sc2_f1 sff
// D I (X) /d3
// SI I (X) /si2
// SE I (1) /sen
// CLK I (X) /clk
// Q O (X) /an_2/A2 /sc2_f2/SI
// QB O (X)
You can use simulation context functionality for different types of analysis. For example, by
default the trace_flat_model command uses the stable_after_setup values as a simulation
background. You can now change it to stable_capture, for example, if you want to trace based
on sensitized paths during capture. Another example is to copy an existing simulation context to
a new one, force some simulation value changes, then evaluate the results in the circuit after
simulating the forces and/or clock pulses.

December 2017
Chapter 4
Tessent Shell Work Flows
This chapter introduces you to the basic building blocks for understanding the pre-layout DFT
insertion work flow when using Tessent Shell, for both flat and hierarchical designs. In
addition, it described the post-layout validation flow for netlists that have gone through place
and routing.
Tessent Shell Flow for Flat Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tessent Shell Flow for Hierarchical Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Tessent Shell Post-Layout Validation Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Running Multi-Load ATPG on Memories for Wrapped Cores with Built-In Self Repair
134

December 2017
Tessent Shell Flow for Flat Designs
Tessent Shell Flow for Flat Designs

This discussion centers on the RTL and scan DFT pre-layout insertion flow for flat designs.
Understanding this flow will aid you when working with hierarchical designs or when
implementing a variation of the basic flow.
In the RTL and scan DFT insertion flow for flat designs, you perform DFT insertion for the
entire chip-level design. This flat DFT implementation aligns with the physical implementation
of the design. The flow consists of performing DFT hardware insertion, followed by synthesis,
optional scan insertion, and ATPG pattern generation at the gate level.
Refer to the following test case for a detailed usage example of the flow described in this
chapter:
tessent_example_flat_flow_<software_version>.tgz
You can access this test case by navigating to the following directory:
<software_release_tree>/share/UsageExamples/
Overview of the RTL and Scan DFT Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

First DFT Insertion Pass: MemoryBIST and Boundary Scan . . . . . . . . . . . . . . . . . . . . 63
Second DFT Insertion Pass: EDT and OCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Load the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Specify and Verify the DFT Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Create the DFT Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Generate the EDT and OCC Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Extract the ICL Module Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Generate IJTAG Patterns and Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Perform Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Perform Scan Chain Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Perform ATPG Pattern Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Considerations for Using Gate-Level Verilog Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

December 2017
Overview of the RTL and Scan DFT Insertion Flow

Whether you are using a flat design or a hierarchical design, the RTL and scan DFT insertion
flow requires you to use a two-pass insertion process to insert the DFT hardware.
As shown in the following figure, insert MemoryBIST and boundary scan prior to Embedded
Deterministic Test (EDT) and the On-Chip Clock Controller (OCC). The DFT logic you insert
during the first DFT insertion pass gets tested by EDT. When inserting DFT into an RTL
design, you only need to run synthesis once after you have performed the two DFT insertion
passes.
Figure 4-1. Two-Pass Insertion Flow for RTL, Flat Designs
During the first pass, Tessent also inserts the IJTAG network. In addition, it inserts any IJTAG
instruments you may have present in the design as long as they have ICL descriptions. Refer to
the create_dft_specification command for details about this process.
Optionally, you can perform scan chain insertion at the same time as synthesis. This does not
effect how you perform DFT insertion, but you will lose some of the automation that Tessent
Shell provides during ATPG pattern generation.
The following figures show an example of the progression of DFT hardware inserted into a
DFT-ready design.

December 2017
Figure 4-2. DFT-Ready Design
In the first DFT insertion pass, Tessent inserts the MemoryBIST and boundary scan hardware.
Figure 4-3. After the First DFT Insertion Pass
In the second DFT insertion pass, Tessent inserts the EDT and OCC hardware. You clock the
MemoryBIST logic using the same functional clock that feeds the memories, as shown in
yellow in Figure 4-3. The IJTAG network (blue) will be scan tested using the IJTAG clock,

December 2017
First DFT Insertion Pass: MemoryBIST and Boundary Scan
which is the TCK clock. The TAP network (red) is not scan tested or is made non-scan during
ATPG.
Figure 4-4. After the Second DFT Insertion Pass
First DFT Insertion Pass: MemoryBIST and

Boundary Scan
Insert MemoryBIST and boundary scan prior to EDT and OCC so that you can accurately
estimate the number of scannable sequential elements (often referred to as “flops”) to be tested.
The number of flops determines the size of the EDT controller that Tessent generates in the
second DFT insertion pass.
The flow for inserting MemoryBIST and boundary scan together is the same as inserting them
separately. For details about this insertion pass flow, refer to:
• “Getting Started” in the Tessent MemoryBIST User’s Manual, or

• “Getting Started” in the Tessent BoundaryScan User’s Manual
Note
The line numbers used in this procedure refer to the command flow dofile in Example 4-1
on page 65.

December 2017
Prerequisites
• To insert boundary scan, you must have an RTL design with instantiated IO pads if you
are using a chip-level design.
• For RTL netlists, you must have a Tessent cell library or the pad library for the IO pads.
For more information, refer to the Tessent Cell Library Manual.
Procedure
1. Load the RTL design data. (See lines 1-6.) The following step is important for the first
DFT insertion pass:
a. Set the set_context -design_id switch to “rtl1.”
For a specified design, the -design_id switch stores all the data associated with a
particular DFT insertion pass in the TSDB. For information about how Tessent
interacts with the TSDB during the DFT insertion flow, refer to “TSDB Data Flow
for the Tessent Shell Flow”. For the first pass, “rtl1” contains the data for the
MemoryBIST and boundary scan hardware, and for the IJTAG network.
Note
“rtl1” is the recommended naming convention for the design ID for the first
insertion pass, but you can specify any name, as desired. Refer to “Load the
Design” for more information about setting the design ID.
2. Set the set_dft_specification_requirements command to “on” for both -memory_test and

-boundary_scan. (See line 9.)
This tells Tessent Shell that you are generating the MemoryBIST and boundary scan
hardware at the same time. There is nothing further you need to do. The process is
automated.
3. Ensure that you set the design level to “chip.” (See line 11.) Refer to “Design Levels”
4. Identify test pins and apply options to special pins. (See lines 12-24.)
5. Apply the check_design_rules command to instruct the tool to leave setup mode and
enter analysis mode. If there are issues with the design, the tool remains in setup mode.
(See line 29.)
6. Create the DFT specification. (See lines 31-41.)
a. To configure the functional pins so that they are shared as EDT channel input and
output pins, add the required logic using the AuxiliaryInput ports and
AuxiliaryOutput ports wrappers, respectively.
Tessent Shell allows for functional pins to be shared as EDT channel pins. You must
insert auxiliary input and output logic at the same time as you insert boundary scan
to avoid cascading two multiplexers along the functional output paths. For additional

December 2017
information, refer to the AuxiliaryInputOutputPorts wrapper in the Tessent Shell

Reference Manual.
Note
You can also share test_clock, scan_en and edt_update pins with functional pins.
The functional coverage is maintained when you use boundary scan during scan
test.
7. Create the DFT hardware, IJTAG network connectivity, and input test patterns. (See
lines 44-51.)
8. Run simulations to verify the design. (See lines 53-60.)
Results
For MemoryBIST, Tessent inserts the MemoryBIST controllers, interfaces, BIST Access Port
(BAP), and segment insertion bits (SIBs). This hardware is later scan-tested using EDT, which
you insert during the second insertion pass. In addition, Tessent automatically connects pre-
existing scan testable instruments and scan resource instruments to the Scan Tested Instrument
(STI) and Scan Resource Instrument (SRI) sides of the IJTAG network, respectively.
For boundary scan, you can segment the boundary scan chain into smaller chains that are used
during logic testing with Tessent TestKompress. To segment the boundary scan chain into
smaller chains to be connected to the EDT, specify max_segment_length_for_logictest within
the BoundaryScan wrapper or alternatively specify the following command prior to running
create_dft_specification:
set_defaults_value DftSpecification/BoundaryScan/max_segment_length_for_logictest
Examples
The following dofile example shows a typical command flow as detailed in the Getting Started
discussions listed above.
The highlighted command lines illustrate additional considerations for inserting the Tessent
Shell MemoryBIST and Tessent Shell Boundary Scan instruments in the first insertion pass of a
two-pass DFT insertion process. The functional pins are equipped with logic so that they can be
shared as EDT channel input and output pins.
Example 4-1. Dofile Example for MemoryBIST and BoundaryScan
1 # Load the design

2 set_context dft –rtl –design_id rtl1
3 set_tsdb_output_directory ../tsdb_rtlread_verilog ../RTL/cpu_top.v
4 read_cell_library ../library/tessent/adk.tcelllib
5 set_design_sources -format tcd_memory -Y ../library/memory \
6 -extension memlib
7 set_current_design cpu_top
8
9 # Specify and verify the DFT requirements
10 set_dft_specification_requirements –memory_test on -boundary_scan on
11 set_design_level chip

December 2017
12
13 # Identify TAP pins
14 set_attribute_value tck_p -name function -value tck
15 set_attribute_value tdi_p -name function -value tdi
16 set_attribute_value tms_p -name function -value tms
17 set_attribute_value trst_p -name function -value trst
18 set_attribute_value tdo_p -name function -value tdo
19 set_boundary_scan_port_options ramclk_p -cell_options clock
20 set_boundary_scan_port_options reset_p -cell_options sample
21
22 # Some pins cannot add any boundary scan cells
23 set_boundary_scan_port_options test_clock_p -cell_options dont_touch
24 set_boundary_scan_port_options edt_update -cell_options dont_touch
25 set_boundary_scan_port_options scan_en_p -cell_options dont_touch
26
27 # Specify the clocks feeding the memories
28 add_clocks 0 ramclk_p -Period 5ns
29
30 check_design_rules
31
32 # Create DFT specification
33 set spec [create_dft_specification]
34 report_config_data $spec
35 set_config_value $spec/BoundaryScan/max_segment_length_for_logictest 150
36 read_config_data -in ${spec}/BoundaryScan -from_string {
37 AuxiliaryInputOutputPorts {
38 auxiliary_input_ports : portain_p[0], portain_p[1], portain_p[2] ;
39 auxiliary_output_ports : portbout_p[0], portbout_p[1],
40 portbout_p[2];
41 }
42 }
44
45 # Create the hardware for the DFT inserted with the DFT specification
46 process_dft_specification
47
48 # Extract the IJTAG network connectivity and create ICL for the design
49 extract_icl
50
51 # Create patterns specification for validating the inserted hardware
52 create_patterns_specification
53
54 # Process the patterns specification and create simulation test benches
55 process_patterns_specification
56
57 # Run and check testbench simulations
58 set_simulation_library_sources -v ../library/verilog/adk.v \
59 -v ../library/pad_cells.v -v ../library/memory/ram.v
60 run_testbench_simulations
61 check_testbench_simulations -report_status

December 2017
Second DFT Insertion Pass: EDT and OCC

In the second DFT insertion pass, insert the logic test hardware: EDT and OCC. This insertion
pass includes requirements and consideration that differ from the first DFT insertion pass,
including inserting the DFT signals.
For information about OCC, refer to “Tessent On-Chip Clock Controller” in the Tessent Scan
and ATPG User’s Manual.
Before running this flow for chip-level designs, source nodes must be present in the RTL design
so that you can define dynamic DFT signals as described in “Specify and Verify the DFT
Requirements.” Dynamic DFT signals are signals such as scan enable, edt_clock, edt_update,
and so on, that need to change during specific tests.
Figure 4-5. Flow for the Second DFT Insertion Pass
Note
For the second DFT insertion pass, use the same process for generating ATPG patterns and
performing simulation that you used during the first DFT insertion pass.
Load the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Specify and Verify the DFT Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Create the DFT Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Generate the EDT and OCC Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Extract the ICL Module Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Generate IJTAG Patterns and Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

December 2017
Load the Design

When loading the design for the second DFT insertion pass, you must ensure that you specify a
new design ID name and, optimally, use the same TSDB directory that you used in the first
insertion pass. In addition, you must read in the design from the first insertion pass and
elaborate the design.
The design loading process for the second pass is similar to the process you used in the first
insertion pass, with a few exceptions as described in this section.
Figure 4-6. Flow for Loading the Design
Prerequisites
• For chip-level designs, source nodes must be present in the RTL design so that you can
define dynamic DFT signals as described in “Specify and Verify the DFT
Requirements.” Dynamic DFT signals are signals such as scan enable, edt_clock,
edt_update, and so on, that need to change during specific tests.
Procedure
1. Apply the set_context command with the ID “rtl2” for the second pass. For example:
set_context dft -rtl design_id rtl2
In the first DFT insertion pass, you set the design ID to “rtl1” with the set_context
command.
Note
This manual uses recommended naming conventions for the design IDs for flat
designs, which are “rtl1” for the first DFT insertion pass, “rtl2” for the second DFT
insertion pass, and “gate” for the scan chain insertion pass. Refer to “Considerations for
Using Gate-Level Verilog Netlists” for the naming conventions when using gate-level
Verilog netlists.

December 2017
For a specified design, the design ID stores all the data associated with a DFT insertion
pass into the TSDB. For the first pass, “rtl1” contains the data for the MemoryBIST and
boundary scan hardware. Setting the design_id to “rtl2” at the beginning of the second
DFT insertion pass identifies that “rtl2” will store the EDT and OCC hardware data
generated during the second pass.
The rtl2 design data is cumulative. That is, it contains the necessary rtl1 data in addition
to the new data generated for EDT and OCC. The “rtl2” designation captures the fact
that the second insertion pass is performed on the resulting edits of the first pass RTL
data. In subsequent insertion passes, you can use either design ID to load the design and
its supporting files.
Tessent generates IJTAG nodes during both insertion passes and their module names are
differentiated using the design ID you specified in each pass.
2. Specify the set_tsdb_output_directory command with the same directory location for
both the first and second DFT insertion passes.
set_tsdb_output_directory ../tsdb_rtlread_verilog ../RTL/cpu_top.v
If you forget to specify the command for the second DFT insertion pass, Tessent creates
a default tsdb_outdir directory in the current working directory. If you use a different
output TSDB directory for the two insertion passes, ensure that you open the TSDB used
by the first insertion pass by specifying the open_tsdb command.
For more information about the TSDB, refer to “Tessent Shell Data Base (TSDB)” in
the Tessent Shell Reference Manual. For information about the TSDB data flow, refer to
“TSDB Data Flow for the Tessent Shell Flow.”
3. Specify the read_cell_library command to read in the library file for the standard cells
and the pad IO macros. The following command reads the Tessent cell library file for
the standard cells and pad IO macros:
read_cell_library ../library/adk_complete.tcelllib
If the pad IO library and standard cell library are separate, use the following commands
to read in the atpg.lib files and the library for the pad IO description:
read_cell_library ../library/atpg.lib
read_cell_library ../library/pad.library
4. Specify the read_design command to load the design:

read_design cpu_top –design_id rtl1
The design was created in the first DFT insertion pass when you used the read_verilog
and/or read_vhdl commands. This command also loads supporting files such as the
TCD, ICL, and PDL, if present in the TSDB.
For example, the following command reads in the design using the design ID from the
first DFT insertion. In this case, this is “rtl1”

December 2017
To load the design correctly for the second insertion pass, the read_design command
refers to the design source dictionary that was created during the first DFT insertion pass
and stored in the dft_inserted_designs directory.
5. Specify the set_current_design command to elaborate the design.
set_current_design cpu_top
If any module descriptions are missing, design elaboration identifies them. You can fix
elaboration errors by adding the missing modules or by specifying the add_black_box
-module command.
Specify and Verify the DFT Requirements

After loading your design data, define the DFT requirements for the EDT and OCC hardware
you will be inserting. This includes adding DFT signals followed by performing design rule
checking.
Figure 4-7. Flow for Specifying and Verifying the DFT Requirements
Procedure
1. Specify the set_dft_specification_requirements command to run pre-DFT design rule
checking as follows:
set_dft_specification_requirements -logic_test on
Since you already specified that you were working at the chip level in the first DFT
insertion pass, you do not need to re-specify this information for the second insertion
pass.
2. Specify the add_dft_signals command to define the DFT signals. For example:
add_dft_signals ltest_en
…
See “DFT Signals” on page 71 for a more complete example.

December 2017
DFT signals are used to determine the various modes of operation, control values and
signal behaviors that are necessary for each test mode. The DFT signals capability in
Tessent Shell automates the following tasks:
• Adding DFT signals.
• Configuring DFT signals for various modes of operation.
• Transferring information about DFT signals from one step to the next.
Based on the desired mode of operation, Tessent creates the necessary setup procedures
to control DFT signals through an IJTAG network.
3. Specify the check_design_rules command to run pre-DFT design rule checking.
When DRC passes, Tessent Shell shifts from setup mode to analysis mode. Pre-DFT
DRC verifies that clocks are defined for all of the scannable sequential elements that
will be scan tested and identifies the async sets and resets so that they can be turned off
during shift operations. In addition, if you have specified the add_dft_clock_enable
command, Tessent checks clock-gating logic and module-type clocks.
Tessent Shell generates DFT_C violations when error conditions are detected. For
details, refer to “Pre-DFT Clock Rules (DFT_C Rules)” in the Tessent Shell Reference
Manual.
Examples
DFT Signals
You can add static DFT signals and dynamic DFT signals. Static DFT signals include global
DFT control, logic test control and scan mode signals. As described in the add_dft_signals
command description, these DFT signals are typically controlled by a Test Data Register that is
part of the IJTAG network.
Most dynamic DFT signals originate from primary input ports. For chip-level designs, these
primary input ports must already be present in the RTL and be pre-connected to a pad buffer
cell. The three dynamic DFT signals that originate from primary inputs are test_clock, scan_en,
and edt_update. To share their input ports with the functional mode, ensure that you added
auxiliary input logic for them during boundary scan insertion. Tessent cannot create the nodes
as ports.
The following example shows the required DFT signals for the second insertion pass when you
are inserting both EDT and OCC.

December 2017
// Create the static DFT signals

add_dft_signals ltest_en
// Generate dynamic DFT signals from source nodes

add_dft_signals scan_en edt_update test_clock \
–source_node { porta_in1 portb_in1 porta_in2 }
// Create shift_capture_clock and edt_clock as gated versions of

test_clock
add_dft_signals shift_capture_clock edt_clock -create_from_other_signals
// Used by top-level EDT

add_dft_signals edt_mode
// Required for boundary scan to be used with logic test without

contacting inputs
add_dft_signals int_ltest_en output_pad_disable
// Required for scan-tested instruments (STI network) such as MemoryBIST

and boundary scan
add_dft_signals tck_occ_en
// To bypass memories or to run multi-load ATPG for memories

add_dft_signals memory_bypass_en
Note
Tessent Shell automatically recognizes scan-tested instruments and stitches them into scan
chains.
Refer to the Tessent Shell Reference Manual for information about the following commands:
• add_dft_signals: Insert DFT signals.

• register_static_dft_signal_names: Register your DFT signal, if, for example, you need to
augment the default DFT signals for specific usage requirements.
• report_dft_signal_names: Return a list of available DFT signals.
• report_dft_signals: View a list of the DFT signals added with the add_dft_signals
command.
• delete_dft_signals: Delete any previously specified DFT signals.
• add_dft_modal_connections: Though not normally required for flat designs, if you have
multiple EDT configurations that you want to multiplex into a common set of top-level
IOs, use this command to implement the multiplexing. In addition, if the EDT channel
pins are shared with functional pins, they need to include auxiliary input/output muxing
logic.

December 2017
Create the DFT Specification

After defining the DFT requirements for the DFT signals in setup mode, you are ready to create
the DFT specification for EDT and OCC in analysis mode. The DFT specification defines how
the hardware will be inserted into the design.
Figure 4-8. Flow for Creating the DFT Specification
Procedure
1. Specify the create_dft_specification command as follows:
create_dft_specification -sri_sib_list {occ edt}
For EDT and OCC, you must first generate a skeleton DFT specification that contains
two empty SRI SIBs that will specify the EDT and OCC sections of the IJTAG network.
Creating the DFT specification for EDT and OCC differs from the process you use for
MemoryBIST and boundary scan in the first DFT insertion pass.
2. Apply commands to customize the DFT specification using one of the following
interfaces:
o GUI — To fill in the EDT and OCC wrapper details for the DFT specification, you
can either use the Tessent GUI, known as DFTVisualizer (see Customizing the DFT
Specification for EDT), or the Tessent Shell command line.
o Command-Line — To customize the DFT specification on the command line, type
the EDT and OCC data as an argument to the read_config_data -from_string
command. Modify the DFT specification with introspected data using the
add_config_element and set_config_value commands. Tessent automatically saves
modifications to the dofile/scripts directory for use in future sessions. See “DFT
Customization Example” on page 74 for an example.

December 2017
Note
Tessent automatically connects the divided boundary scan segment (if present from
the first DFT insertion pass) to the EDT hardware that Tessent inserts in the second
insertion pass. Refer to connect_bscan_segments_to_lsb_chains for details.
3. Specify the following command to ensure that no errors exist in the DFT specification:
process_dft_specification -validate_only
This step should be done before generating the EDT and OCC hardware.
Examples
DFT Customization Example
The following example modifies a DFT specification to add EDT and OCC and saves the
changes.
Note
If you are using Tessent OCC, Tessent Scan automatically identifies and stitches the sub-
chains in the OCC into scan chains.
read_config_data -in $spec -from_string {

OCC {
ijtag_host_interface : Sib(occ);
}
}
# The following illustrates a generic way to populate the OCC. The clock
# list is design specific and needs to be updated for the design to the
# OCC, scan_enable and shift_capture_clock are connected automatically
# Modify the following for your specific design requirements
set id_clk_list [list \
clk1 clk1_p \
clk2 clk2_p \
clk3 clk3_p \
clk4 clk4_p \
ramclk_p ramclk_p \
]
foreach {id clk} $id_clk_list {

set occ [add_config_element OCC/Controller($id) -in $spec]
set_config_value clock_intercept_node -in $occ $clk
}
report_config_data $spec

December 2017
# To the EDT controller, the edt_clock and edt_update are connected

# automatically. The EDT controller is built-in with bypass
# Modify the following for your specific design requirements
EDT {
ijtag_host_interface : Sib(edt);
Controller (c1) {
longest_chain_range : 65, 100;
scan_chain_count : 85;
input_channel_count : 3;
output_channel_count : 3;
Connections +{
EdtChannelsIn(1) {
}
EdtChannelsIn(2) {
}
EdtChannelsIn(3) {
}
EdtChannelsOut(1) {
}
EdtChannelsOut(2) {
}
EdtChannelsOut(3) {
}
}
}
}
}
# Connecting the EDT channel in to the primary input and connecting

# EDT channel out to the primary output
# You had inserted the auxiliary logic for these ports during the first
DFT insertion pass
set_config_value port_pin_name \
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsIn(1) \
[get_single_name [get_auxiliary_pins portain_p[0] -direction input]]
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(1) \
[get_single_name [get_auxiliary_pins portbout_p[0] -direction output] ]

December 2017
Generate the EDT and OCC Hardware

After creating the DFT specification, generate the EDT and OCC hardware. The
process_dft_specification command generates and inserts the DFT hardware—as defined by the
DFT specification—into your design.
Figure 4-9. Flow for Inserting the Second-Pass Hardware
Procedure
1. Specify the process_dft_specification command to insert EDT and OCC in the second
pass.
process_dft_specification
2. If you want to generate the hardware, but not insert it into the design, specify the
following command:
process_dft_specification -no_insertion
You can then insert the hardware into the design manually.
Extract the ICL Module Description

After inserting the EDT and OCC hardware, verify the connectivity of the ICL modules that
were inserted with the process_dft_specification command. This is a preparatory step for
IJTAG pattern generation.

December 2017
Figure 4-10. Flow for Extracting ICL
Procedure
1. Specify the extract_icl command to find all modules (both Tessent instruments and non-
Mentor Graphics instruments) and their associated ICL descriptions, and to run DRC to
verify their connectivity.
The top-level ICL description corresponds to the design name you specified with the
set_current_design command during the first insertion pass (which is also the same
design name you specified when you elaborated the design at the beginning of the
second insertion pass).
2. Specify the analyze_drc_violation command to debug the DRC violations.
Tessent generates I-rule errors when it detects ICL extraction errors and opens
DFTVisualizer to a schematic view of the error. For more information about the DRC I-
rule errors, refer to “ICL Extraction Rules (I Rules)” in the Tessent Shell Reference
Manual. For details about using DFTVisualizer, refer to “DFTVisualizer” on page 183.
The extract_icl command also creates a Synopsys Design Compiler file that you can use
for synthesis. Refer to “Timing Constraints (SDC)” for more information.
Generate IJTAG Patterns and Run Simulation

The process for generating and simulating the IJTAG patterns for EDT and OCC is identical to
the process you used during the first DFT insertion pass for MemoryBIST and boundary scan.
The following figure shows the tasks required to complete the second insertion pass and move
on to synthesis.

December 2017
Perform Synthesis
Figure 4-11. Flow for Generating and Simulating IJTAG Patterns
Procedure
1. Generate the test patterns for the design:
create_patterns_specification
2. Validate and process the content of the test patterns:

process_patterns_specification
3. Run and check testbench simulations. For example:

# Run and check testbench simulations
set_simulation_library_sources -v ../library/verilog/adk.v \
-v ../library/pad_cells.v -v ../library/memory/ram.v
run_testbench_simulations
check_testbench_simulations -report_status
Perform Synthesis
Synthesize the original RTL as well as the DFT-inserted RTL for MemoryBIST, boundary scan,
EDT and OCC. For RTL designs, perform synthesis once after performing the first and second
DFT insertion passes.
Prerequisites
• Tessent Shell supports synthesis using Synopsys Design Compiler. For details, refer to
“Timing Constraints (SDC)” for more information.

December 2017
Perform Scan Chain Insertion
Procedure
Specify the write_design_import_script command to create a dc_shell design load script that
you can use to load the RTL design as it exists after the two DFT insertion passes.
write_design_import_script for_synthesis.tcl -replace
Note
If you are not using Synopsys Design Compiler as your third-party synthesis tool,
you can still use the command to create a dc_shell script and adjust it to match your
synthesis tool’s command set.

During scan chain insertion, Tessent inserts and stitches scan chains on the gate-level netlist that
was synthesized after DFT insertion. After you run scan chain insertion, proceed to ATPG
pattern generation.
During scan insertion using Tessent Scan, the non-scan instances such as EDT are automatically
understood. In addition, the built-in OCC sub-chains are understood and stitched into scan
chains. Tessent uses DFT signals such as the scan enable that you specified in the previous
insertion passes, therefore you do not need to specify them again.
For information about scan chain insertion using Tessent Shell, refer to the “Internal Scan and
Test Circuitry Insertion” in the Tessent Scan and ATPG User’s Manual.
Procedure
1. Specify the following command to set the DFT context:
set_context dft –scan -design_id gate
Once again, when setting the context, ensure that you specify the design ID with a
unique name. The recommended name is “gate” for a flat design, although you can
choose a name as desired. As described in “Load the Design,” for a gate-level netlist the
recommended name is “gate3”.
2. Load the synthesized netlist. For example:
read_verilog ../Synthesis/cpu_top_synthesized.vg
This netlist contains the gates for the original RTL design and the DFT-inserted
hardware.
3. Specify the same output directory you used in the first and second DFT passes:
set_tsdb_output_directory ../tsdb_rtl

December 2017
Perform ATPG Pattern Generation
4. Load the rtl2 design data for the DFT hardware you previously inserted. For example:
read_design cpu_top -design_id rtl2 -no_hdl
The -no_hdl switch specifies to read in all of the DFT data files—such as ICL, PDL and
TCD—except for the design files. (You are using the synthesized design from this point
forward.)
After design elaboration and design rule checking, Tessent Shell transitions from Setup
mode to Analysis mode.
5. Specify the add_scan_mode edt_mode command to connect the scan chains to the EDT
signals and EDT hardware that you inserted during the second insertion pass.
The use of pre-registered DFT signal “edt_mode” as the scan mode using the
add_scan_mode command infers the -enable_dft_signal also as the edt_mode DFT
signal.
Results
The scan stitched and inserted netlist is located in the TSDB under the design ID “gate” for RTL
designs or “gate3” for gate-level netlists. Refer to “Considerations for Using Gate-Level
Verilog Netlists” for details.
Examples
The following dofile shows a command flow for scan insertion and stitching:
set_context dft –scan -design_id gate

read_cell_library ../library/tessent/adk.tcelllib
read_verilog ../Synthesis/cpu_top_synthesized.vg
set_tsdb_output_directory ../tsdb_rtl
read_design cpu_top -design_id rtl2 -no_hdl
check_design_rules
set edt_instance [get_name_list [get_instance -of_module [get_name

[get_icl_module -filter tessent_instrument_type==mentor::edt]]]]
add_scan_mode edt_mode -edt_instance $edt_instance
analyze_scan_chains
report_scan_chains
insert_test_logic
exit

After inserting scan chains, proceed to ATPG pattern generation.

December 2017
Procedure
1. Do one of the following:
• If you used Tessent Scan to insert the scan chains, specify the import_scan_mode
edt_mode command for ATPG pattern generation.
• If you did not use Tessent Scan for scan insertion, use the TCD IP mapping flow as
described in “Running ATPG Patterns without Tessent Scan” in the Tessent Scan
When you specify the import_scan_mode command, Tessent Shell passes through the
scan-insert design data for the EDT and OCC logic. This data includes the scan
structures (scan chains and scan channels) that are stored in the TSDB under the “gate”
design ID. The gate design ID was created during scan insertion when you specified the
insert_test_logic command.
In addition, Tessent automatically creates and simulates the test_setup procedure cycles
that are required to initialize the EDT and OCC static signals. You only need to specify
non-default parameter values, if, for example, you run EDT with bypass on or set
int_ltest_en to 1 to use the boundary scan as the source of the core values and isolate the
ATPG test from the top-level IOs.
You can create ATPG patterns for any mode that you need, such as stuck-at and
transition. These patterns are stored in the TSDB database under the logic_test_cores
directory. The import_scan_mode command uses the same scan configuration—that is,
the DFT signals—that were used for the add_scan_mode command during scan
insertion.
2. Specify the set_current_mode command to indicate the type of pattern you are
generating (see “Stuck-at ATPG patterns” on page 81 and “Transition at-speed ATPG
patterns” on page 82).
In addition, the name you give to the generated ATPG pattern sets must differ from the
mode name you specify for import_scan_mode (that is, “edt_mode”).
3. Specify the write_patterns command to write out the Verilog testbenches and STIL
patterns.
4. Specify the write_tsdb_data command to save the flat model, fault list, PatDB and TCD
files into the TSDB.
For details about ATPG pattern generation, refer to “Running ATPG Patterns” in the
Tessent Scan and ATPG User’s Manual.
Examples
Stuck-at ATPG patterns
The following example generates stuck-at ATPG patterns as indicated by the set_current_mode
edt_stuck command. It shows that you have a choice between using the boundary scan chains
for capture during ATPG or using the primary pins of the chips (using the pads).

December 2017
set_context patterns -scan

read_cell_library ../library/memory/memory.lib
open_tsdb ../tsdb_rtl
read_design cpu_top -design_id gate
set_current_mode edt_stuck
import_scan_mode edt_mode
# To apply the patterns through the boundary scan chains and not through
the pads use:
# set_static_dft_signal_values int_ltest_en 1
# set_static_dft_signal_value output_pad_disable 1
# To allow the shift_capture_clock during capture phase on Scan Tested
Instruments:
set_static_dft_signal_value tck_occ_en 1
set_system_mode analysis
create_patterns
write_tsdb_data –replace
write_patterns patterns/cpu_top_stuck_parallel.v -verilog -parallel -
replace \
-scan -parameter_list {SIM_KEEP_PATH 1}
write_patterns patterns/cpu_top_stuck_serial.v -verilog -serial -replace \
-parameter_list {SIM_KEEP_PATH 1}
exit
Transition at-speed ATPG patterns

The following example generates transition at-speed patterns. The import_scan_mode
command uses the –fast_capture_mode switch to indicate that the OCC supplies the fast clock
during capture. The set_current_mode command indicates edt_transition, and the set_fault_type
command indicates transition faults.

read_cell_library ../library/memory/memory.lib
open_tsdb ../tsdb_rtl
read_design cpu_top -design_id gate
set_current_mode edt_transition
import_scan_mode edt_mode -fast_capture_mode on -verbose
set_static_dft_signal_values int_ltest_en 1
set_static_dft_signal_value output_pad_disable 1
set_fault_type transition
set_external_capture_options -pll_cycles 5 [lindex [get_timeplate_list] 0]
create_patterns
write_tsdb_data –replace
write_patterns patterns/cpu_top_transition_parallel.v -verilog -parallel
-replace \
-scan -parameter_list {SIM_KEEP_PATH 1}
write_patterns patterns/cpu_top_transition_serial.v -verilog -serial \
-replace -parameter_list {SIM_KEEP_PATH 1}
exit

December 2017
Considerations for Using Gate-Level Verilog Netlists
Considerations for Using Gate-Level Verilog

Netlists
In some cases, you may only have a gate-level Verilog netlist, not the RTL. You can use
Tessent Shell to perform the DFT insertion flow when you have a gate-level netlist. The flow is
similar to the RTL and scan DFT insertion flow. The main difference is that you must perform
synthesis after each DFT insertion pass.
Figure 4-12 shows the gate-level DFT insertion sequence in which you insert MemoryBIST and
boundary scan in the first insertion pass and then immediately run synthesis on these
instruments before inserting the logic test instruments for the second DFT insertion pass (EDT,
OCC, and so on). After inserting the logic test instruments, run synthesis a second time before
proceeding to scan chain insertion.
Figure 4-12. Two-Pass Insertion Flow for RTL, Gate-Level Designs
The following differences apply when using a gate-level Verilog netlist rather than RTL. Other
than these differences, plus performing synthesis after each DFT insertion pass, you can follow
the flow as described starting with “First DFT Insertion Pass: MemoryBIST and Boundary
Scan.”
• Prerequisites. You must have the Tessent cell library or the ATPG library for the
standard cells, in addition to the Tessent cell library for the IO pad cells.
• Load the design. During the first and second DFT insertion passes, ensure the following:
o Specify the set_context command with the -no_rtl option rather than the -rtl option.
o When setting the context, the recommended naming conventions for the design IDs
are “gate1” for the boundary scan/MemoryBIST insertion pass and “gate2” for the
EDT/OCC insertion pass. If you are following this convention, you would then use
design ID “gate3” for scan insertion.
o Use the read_cell_library command to read in the library files for both the standard
cells and pad IO macros that are instantiated in the design.

December 2017
Tessent Shell Flow for Hierarchical Designs
Tessent Shell Flow for Hierarchical Designs

Hierarchical design methodologies provide efficiencies for large designs. Rather than design at
the chip-level, chip designers break designs down into RTL blocks that allow design teams to
work on different functional blocks in parallel. This method streamlines the process and allows
RTL modifications, engineering change orders (ECOs) and other changes to be localized to
particular blocks.
Tessent Shell uses the same “divide and conquer” methodology for hierarchical DFT by
allowing you to perform RTL and scan DFT insertion at the sub-physical block level rather than
only at the chip level. Implementing DFT hierarchically in a bottom-up process starting with the
lowest level blocks not only helps to divide the task but also makes the task manageable.
This section builds on what you learned in “Tessent Shell Flow for Flat Designs” to describe the
pre-layout RTL and scan DFT insertion process for hierarchical designs.
Refer to the following testcase for a detailed usage example of the flow described in this
chapter:
tessent_example_hierarchical_flow_<software_version>.tgz
You can access this testcase by navigating to the following directory:
<software_release_tree>/share/UsageExamples/
Hierarchical DFT Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

How the DFT Insertion Flow Applies to Hierarchical Designs . . . . . . . . . . . . . . . . . . . . 88
RTL and Scan DFT Insertion Flow for Physical Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 89
RTL and Scan DFT Insertion Flow for the Top Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
RTL and Scan DFT Insertion Flow for Sub-Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

December 2017
Hierarchical DFT Terminology

Tessent Shell uses a particular set of terms related to working with blocks in a hierarchical
design. You must understand these terms to perform the RTL and scan DFT insertion process
on hierarchical designs.
Refer to “set_design_level” in the Tessent Shell Reference Manual for more information.
• Physical block. Physical blocks are logical entities that remain intact through tapeout.
They are synthesis and layout regions. Below the top level of a chip, these are blocks
that you can reuse, or instantiate, within a chip or across multiple chips. You perform
synthesis on these blocks independent of the rest of the chip design.
When performing DFT insertion on physical blocks, Tessent preserves the ports at the
root of the physical block. Instances of the physical block that exist below the current
physical block may not be preserved in the final layout when ungrouping is used.
In Tessent Shell, the hierarchical DFT insertion flow distinguishes between three types
of physical blocks: wrapped cores, unwrapped cores, and chip.
o Wrapped core. Wrapped cores contain wrapper cells that are used to isolate the
internal logic of the core. Wrapper cells are inserted when you perform scan chain
insertion. Wrapped cores are required to make the cores reusable through ATPG
pattern retargeting. Wrapped cores can contain sub-blocks. (See description below.)
o Unwrapped core. Unwrapped cores do not contain wrapper cells but can contain
sub-blocks.
For additional information, refer to “Unwrapped Cores Versus Wrapped Cores” in
the Tessent Scan and ATPG User’s Manual.
o Chip. The chip is the top-level physical block—that is, the entire design—in which
you typically find the pad IO macros and clock controllers. A chip may include
another physical block or sub-block. Physical blocks can be wrapped cores or
unwrapped cores. Unlike the other types of physical blocks, chips are layout regions.
• Sub-block. Sub-blocks are designs that exist within parent blocks and are synthesized
with their parent blocks, which could be wrapped cores, unwrapped cores or the top
level of the chip. Sub-blocks merge into their parent physical blocks during synthesis of
the parent block. Refer to set_design_level for a details.
Sub-blocks are not layout physical regions. After layout is performed on the post-layout
netlist, the sub-block module boundary may or may not be preserved. Sometimes the
same sub-block is instantiated at both the physical block level and the chip level as
shown below.

December 2017
Figure 4-13. Hierarchical Design Levels
You can insert DFT hardware such as MemoryBIST, EDT, and OCC into sub-blocks,
but you perform synthesis and scan insertion at the sub-block’s parent physical block
level (where the sub-block is instantiated). To learn about how you use sub-blocks
within the Tessent Shell flow, refer to “RTL and Scan DFT Insertion Flow for Sub-
Blocks.”
• ATPG (or scan) pattern retargeting. The process by which Tessent Shell preserves
the ATPG patterns associated with wrapped cores for purposes of reuse when testing the
logic at the parent instantiation level. This means you do not have to re-generate the
patterns when you process the top level of the chip. Instead, you retarget the wrapped
core ATPG patterns to the top level. Every instantiation of a wrapped core includes its
associated ATPG patterns.
For details, refer to “Scan Pattern Retargeting” in the Tessent Scan and ATPG User’s
Manual.
For purposes of ATPG pattern retargeting and graybox modeling (see description
below), Tessent Shell differentiates between a wrapped core’s internal circuitry and its
external circuitry.
o Internal mode. Internal mode is the view into the wrapped core from the wrapper
cells. That is, the logic completely internal to the core. Tessent Shell retargets
internal mode ATPG patterns during ATPG pattern generation for the chip-level
design.
o External mode. External mode indicates the view out of the wrapped core from the
wrapper cells. That is, the logic that connects the wrapped core to external logic.
Tessent Shell uses the external mode to build graybox models, which are used by the
internal modes of their parent physical blocks.

December 2017
• Graybox. Graybox models are wrapped core models that preserve only the core’s
external mode logic along with the portion of the IJTAG network needed for test setup
of the logic test modes. The purpose of graybox models in the bottom-up hierarchical
DFT process is to retain the minimum logic required to generate ATPG patterns for the
internal modes of the parent physical blocks. For details, refer to “Graybox Overview”
in the Tessent Scan and ATPG User’s Manual.

December 2017
How the DFT Insertion Flow Applies to Hierarchical Designs
How the DFT Insertion Flow Applies to Hierarchical

Designs
Performing RTL and scan DFT insertion on hierarchical designs assumes basic knowledge of
the RTL and scan insertion flow for flat designs. The process for hierarchical designs builds on
the process you would use for a flat design.
As described in “Overview of the RTL and Scan DFT Insertion Flow,” you perform a two-pass
pre-scan insertion process for flat designs. For hierarchical designs, the same flow applies
except that you perform the insertion process in a bottom-up manner for each core and sub-
block in the design. After you have inserted DFT into all the lower-level physical blocks, you
perform the same insertion into the parent blocks until you have reached the top level of the
chip.
The following considerations apply when performing DFT insertion on a hierarchical design as
opposed to a flat design:
• When performing hierarchical DFT, you must specify the hierarchical design level at
which you are performing the DFT insertion process. For flat designs, the
set_design_level command is always set to “chip.” For hierarchical designs, you can
also specify “physical_block” or “sub_block.”
• Inserting boundary scan during the first DFT insertion pass typically applies to the chip
design level. For hierarchical designs, this means that for cores and sub-blocks you
insert only MemoryBIST during the first DFT insertion pass unless you have cores with
embedded pad IO macros. If this is the case, then you need to insert boundary scan into
the pad IOs using the embedded boundary scan flow as described in the Tessent
Boundary Scan User’s Manual.
• Within the hierarchical flow, each physical block and sub-block has a unique design
name and, ideally, should have its own TSDB.
Tip
To facilitate data management, save each design (whether core, sub-block, or chip)
in its own TSDB directory. This is the recommended practice when using Tessent
Shell for DFT insertion. Using different directories ensures that you can run all sibling
physical and sub-blocks in parallel without causing read-write errors into the TSDB
directories between the parallel runs. Only when all the child physical and sub-blocks of
a given block are completed can you then implement the DFT into the given block.
Refer to “TSDB Data Flow for the Tessent Shell Flow” for more information.
• Perform ATPG pattern retargeting of core-level patterns when you process the parent
physical block of the wrapper cores, as shown in section “ATPG Pattern Generation
Example.”

December 2017
RTL and Scan DFT Insertion Flow for Physical Blocks
RTL and Scan DFT Insertion Flow for Physical

Blocks
For each wrapped core, perform a two-pass pre-scan DFT insertion process as you would for a
flat design except that in the first DFT insertion pass, do not insert boundary scan unless you
have embedded pad IO macros present inside the core. This section describes the flow details
that are unique to working with wrapped cores as opposed to flat designs.
Refer to “Tessent Shell Flow for Flat Designs” for overall flow details.
Note
This discussion assumes your design consists of wrapped cores as your lower level physical
blocks, and the wrapped cores do not contain embedded pad IOs.
Figure 4-14. Two-Pass Insertion Flow for RTL, Wrapped Cores
First DFT Insertion Pass: Performing Block-Level MemoryBIST. . . . . . . . . . . . . . . . . 89

Second DFT Insertion Pass: Block-Level EDT and OCC . . . . . . . . . . . . . . . . . . . . . . . . 92
Specify and Verify the DFT Requirements: DFT Signals for Wrapped Cores . . . . . . . 95
Perform Scan Chain Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Perform ATPG Pattern Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Run Recommended Validation Step for Pre-Layout Design Sign Off . . . . . . . . . . . . . . 104
First DFT Insertion Pass: Performing Block-Level

MemoryBIST
Because you are not inserting boundary scan at the same time as MemoryBIST (as in the flat
flow), you can follow the DFT insertion process for Tessent MemoryBIST.
Refer to “Getting Started” in the Tessent MemoryBIST User’s Manual.

December 2017
Note
on page 91
Procedure
1. Load the RTL design data. (See lines 1-22). The following steps are important for the
first DFT insertion pass for wrapped cores:
a. Set the set_context -design_id switch to “rtl1.”
All the data associated with MemoryBIST insertion for the wrapped core will be
stored under the ID “rtl1” in the wrapped core’s TSDB.
Note
“rtl1” is the recommended naming convention for the design ID for the first
insertion pass, but you can specify any name, as desired. Refer to “Load the
Design” for more information about setting the design ID.
b. Specify the read_verilog command with a list of the RTL file names and locations
for Tessent to read and compile for the design. For example:
../rtl/omsp_timerA_defines.v
../rtl/omsp_timerA_undefines.v
../rtl/omsp_timerA.v
../rtl/omsp_wakeup_cell.v
../rtl/omsp_watchdog.v
../rtl/openMSP430_defines.v
../rtl/openMSP430_undefines.v
../rtl/openMSP430.v
../rtl/processor_core.v
c. Set the design level to “physical_block” so that the layout of this core is maintained
as an independent logical entity through tapeout.
3. Generate the MemoryBIST hardware and extract the ICL (See line 29)
a. (Optional) To configure the functional pins so that they are shared as EDT channel
input and output pins, add the required logic using the AuxiliaryInput ports and
AuxiliaryOutput ports wrappers, respectively.
Tessent Shell allows for functional pins to be shared as EDT channel pins. You must
insert auxiliary input and output logic at the same time as you insert boundary scan
to avoid cascading two multiplexers along the functional output paths. For additional
information, refer to the AuxiliaryInputOutputPorts wrapper in the Tessent Shell
Reference Manual.

December 2017
Note
You can also share test_clock, scan_en and edt_update pins with functional pins.
The functional coverage is maintained when you use boundary scan during scan
test.
5. Create the input test patterns and simulation test benches. (See lines 38-41 of
Example 4-2.)
6. Run simulations to verify the design. (See lines 43-48 of Example 4-2.)
Examples
The following dofile example shows a typical command flow as detailed in the procedure listed
above.
Example 4-2. Dofile Example for MemoryBIST in Physical Blocks
1 # Set context to dft and indicate DFT insertion into an rtl-level design
2
3 set_context dft -rtl -design_id rtl1
4
5 # Set the TSDB directory location to be used
6
7 set_tsdb_output_directory ../tsdb_core
8
9 # Read in the memory library model
10 set_design_sources -format tcd_memory -y ../../../library/memory \
11 -extension tcd_memory
12
13 # Read in memory Verilog model
14 set_design_sources -format verilog -v {../../../library/memory/*.v }
15
16 # Read in the design
17 read_verilog -f rtl_file_list
18
19 set_current_design processor_core
20
21 # Set the design level as a physical_block
22 set_design_level physical_block
23
24 # Specify to insert memory test
25 set_dft_specification_requirements -memory_test on
26 add_clocks 0 dco_clk -period 3
28 report_memory_instances
29 set spec [create_dft_specification]
31
32 # Generate the memoryBIST hardware
34
35 # Create ICL for this design
36 extract_icl
37
38 # Generate testbenches

December 2017
39 create_pattern_specification
40 process_pattern_specification
41 set_simulation_library_sources -v ../../../library/verilog/adk.v
42
43 # Run simulations
45
46 # If simulation fails use the following command
47 //check_testbench_simulations
48 exit
Second DFT Insertion Pass: Block-Level EDT and OCC

In the second DFT insertion pass for wrapped cores, insert the EDT and OCC hardware. Unlike
flat designs, which use standard OCCs, for wrapped cores you have a choice between inserting
OCCs of type child or type standard.
Refer to “On-Chip Clock Controller Design Description” in the Tessent Scan and ATPG User’s
Manual for details.
If your physical design implementation does not support using a clock MUX in the clock path,
then you can use an OCC of type child. With the child type OCC, only clock chopping and
clock gating functions occur inside the wrapped core, and these functions are sufficient for
ATPG pattern retargeting (later in the flow) as long as at the chip-level you have included a
parent OCC or other hardware that can perform clock selection.
Clock selection is used to select between shift and capture clocks when generating ATPG
patterns for the internal mode of the core. Typically, scan chain shifting occurs at a significantly
slower speed than the capture clock, hence the need for the clock.
Most of the steps for the second DFT insertion pass for wrapped cores are the same as those you
would perform for a flat design. Refer to the applicable sections.
Note
The line numbers used in this procedure refer to the command flow dofile in Example 4-3.
Procedure
1. Load the Design. (See lines 1-10.)
2. Specify and Verify the DFT Requirements: DFT Signals for Wrapped Cores. (See lines
12-32.)
Note
Wrapped cores have their own DFT requirements for the clock signals
3. Create the DFT Specification. (See lines 34-38.)

4. Generate the EDT and OCC Hardware. (See lines 40-78.)

December 2017
5. Extract the ICL Module Description. (See lines 80-84.)

6. Generate IJTAG Patterns and Run Simulation. (See lines 86-95.)
Examples
The following dofile example shows that you set the design ID to “rtl2” for the second DFT
insertion pass, set the internal mode and external mode for the wrapped core, and have chosen to
specify an OCC of type child.
Example 4-3. Dofile for Second DFT Pass
1 # Set context to dft and specify design_id as rtl2

2 set_context dft -rtl -design_id rtl2
3
4 # Specify where the tsdb_outdir is to be located, default is at the
5 current working directory
7
8 # Use read_design with the design ID from the first DFT insertion pass
9 read_design processor_core -design_id rtl1
11
12 # No need to reset the design level, which remains "physical_block" from
13 # the first pass
14 # Add DFT signals for the wrapped core
15
16 # The following commands required for logic test
17 add_dft_signals ltest_en -create_with_tdr
18 add_dft_signals scan_en edt_update test_clock -source_node \
19 { scan_enable edt_update test_clock_u }
20 add_dft_signals edt_clock shift_capture_clock -create_from_other_signals
21
22 # Required for memories to be tested with multi-load ATPG patterns
23 add_dft_signals memory_bypass_en -create_with_tdr
24
25 # Required for STI network to be tested during logic test
26 add_dft_signals tck_occ_en -create_with_tdr
27
28 # Required for hierarchical DFT and will be used during scan insertion
29 # Specifying both the internal mode and the external mode
30 add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode
31
32 report_dft_signals
33
34 # Run pre-DFT DRC
35 set_dft_specification_requirements -logic_test on
36
38 set spec [create_dft_specification -sri_sib_list {edt occ} ]
39
40 # Use report_config_syntax DftSpecification/edt|occ to see full syntax
42 read_config_data -in $spec -from_string {

December 2017
43 OCC {
44 ijtag_host_interface : Sib(occ);
45 }
46 }
47 # The following is a generic way to populate the OCC
48 # The clock list is design specific and needs to be updated for the design
49 # To the OCC - scan_enable and shift_capture_clock gets connected
50 # automatically
51 # Modify the following to your design requirements
52 set id_clk_list [list \
53 dco_clk dco_clk\
54 ]
55
56 foreach {id clk} $id_clk_list {
57 set occ [add_config_element OCC/Controller($id) -in $spec]
58 set_config_value clock_intercept_node -in $occ $clk
59 }
61
62 ## To EDT controller, the edt_clock and edt_update get auto connected
63 ## The EDT controller is built-in with bypass
## Modify the following to your design requirements
64 read_config_data -in $spec -from_string {

65 EDT {
66 ijtag_host_interface : Sib(edt);
67 Controller (c1) {
68 longest_chain_range : 200, 300;
69 scan_chain_count : 60;
70 input_channel_count : 3;
71 output_channel_count : 2;
72 }
73 }
74 }
76 //display_spec
77 # Generate the hardware
79
80 # Extract the IJAG network and create ICL file for core level
81 extract_icl
82
83 # Write updated RTL into this new file to elaborate and synthesize later
84 write_design_import_script for_dc_synthesis.tcl -replace
85
86 # Generate testbench
87 create_pattern_specification
88 process_pattern_specification
89
90 set_simulation_library_sources -v ../../../library/verilog/adk.v
91
92 # Run Verilog simulation
94 # If simulation fails, use the command below to see which pattern failed
95 //check_testbench_simulations
96
97 exit

December 2017
Specify and Verify the DFT Requirements: DFT Signals

for Wrapped Cores
After loading the design data from the TSDB, define the DFT requirements for the EDT and
OCC hardware. This includes adding DFT signals and performing DRC.
Figure 4-15. Flow for Specifying and Verifying the DFT Requirements
Procedure
1. Specify the following command to set DFT requirements:
Note
The design level as specified by set_design_level remains “physical_block” from the
first DFT insertion pass, so you do not need to specify this command again.
2. Use the following procedure to define the DFT signals for wrapped cores in the second
DFT insertion pass:
a. Specify a global DFT signal to enter logic test mode. For example:
add_dft_signals ltest_en -create_with_tdr
b. Define the DFT signals. For example:

add_dft_signals scan_en edt_update test_clock -source_node \
{ scan_enable edt_update test_clock_u }
add_dft_signals edt_clock shift_capture_clock \

-create_from_other_signals
If these ports do not exist, the tool creates new ports.

c. Specify the following command to test with multi-load ATPG patterns in
MemoryBIST:
add_dft_signals memory_bypass_en -create_with_tdr

December 2017
d. Specify the following command to test an STI network during logic test.
add_dft_signals tck_occ_en -create_with_tdr
e. Specify both the internal mode and the external mode for hierarchical DFT. This is
required for scan insertion.
add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode
This command specifies that wrapped cores have both internal modes and external
modes, and that you must specify both. Differentiating between internal mode and
external mode allows Tessent to stitch the scan chains into internal chains and
external chains as described in “Perform Scan Chain Insertion.”
The internal and external modes are also required for proper ATPG pattern
retargeting and graybox modeling later in the insertion flow. Refer to “Hierarchical
DFT Terminology” for more information.
3. After defining the DFT signals, run DRC as in the flat design flow.
If the design includes clock gating that is implemented in RTL and not with an
integrated clock gating cell, you must specify their func_en and test_en ports using the
add_dft_clock_enable command. Tessent checks for proper clock and asynchronous set/
reset control-ability.
Results
Tessent Shell generates DFT_C errors for DRCs that are run. For details, refer to “Pre-DFT
Clock Rules (DFT_C Rules)” in the Tessent Shell Reference Manual.
Examples
To define the DFT signals, the following example shows the required DFT signals for wrapped
cores in the second DFT insertion pass:
# Required global DFT signal to enter logic test mode

# If these ports do not exist, new ports will be created

{ scan_enable edt_update test_clock_u }
add_dft_signals edt_clock shift_capture_clock -create_from_other_signals
# Required for MemoryBIST to be tested with multi-load ATPG patterns

add_dft_signals memory_bypass_en -create_with_tdr
# Required for STI network to be tested during logic test

# Required for hierarchical DFT and will be used during scan insertion
# Specifying both the internal mode and the external mode
add_dft_signals int_ltest_en ext_ltest_en int_mode ext_mode

December 2017

Scan chain insertion for wrapped cores includes a task for performing wrapper analysis, which
prepares the functional scannable sequential elements (or “flops”) for reuse as wrapper cells.
Specifically, these cells are called shared wrapper cells.
Note
Prior to scan chain insertion, perform synthesis as described in section “Perform Synthesis.”
Using shared wrapper cells reduces the number of flops required for isolating the internal test
modes from the primary input ports of the wrapper core. It also reduces the number of flops
required for isolating the external test modes from the internal logic. Tessent automatically
generates shared wrapper cells.
The analyze_wrapper_cells command performs wrapper analysis. In addition to preparing the

shared wrapper cells, the command infers dedicated wrapper cells for ports having a large
fanout or fanin. You can configure the size of the fanin and fanout using the
set_wrapper_analysis_options -input_fanout_flop_threshold and -output_fanin_flop_threshold
options. By default, Tessent infers dedicated wrapper cells on input ports fanning out to 32 or
more scannable flip-flops, and on output ports in the fanout of 32 or more scannable flip-flops.
Both shared wrapper cells and dedicated wrapper cells can coexist in the same wrapper chains,
which helps Tessent maintain wrapper chains of similar length. Scan insertion uses the DFT
signals int_ltest_en and ext_ltest_en along with the scan enable signal to control the wrapper
cell.
For information about scan chain insertion using Tessent Shell, refer to the “Internal Scan and
Test Circuitry Insertion” in the Tessent Scan and ATPG User’s Manual.
Note
on page 98.
Procedure
1. Specify the following command to set the DFT context:
set_context dft -scan -design_id gate
2. Load the synthesized netlist. For example:

read_verilog ../3.synthesis/processor_core_synthesized.vg
3. Specify the same output directory you used in the first and second DFT passes:
set_tsdb_output_directory ../tsdb_core

December 2017
4. Load the rtl2 design data for the DFT hardware you previously inserted. For example:
read_design processor_core -design_id rtl2 -no_hdl
5. Check the design rules:

check_design_rules
6. After running DRC, set up the wrapper cells as follows (see lines 25-35):
a. Specify the options for analyzing the wrapper cells.
b. Add dedicated wrappers, as necessary.
c. Analyze the wrapper cells with the analyze_wrapper_cells command.
d. Ensure that you exclude the EDT channel IO ports from wrapper analysis.
For details, refer to “Scan Insertion for Wrapped Core” in the Tessent Scan and ATPG
User’s Manual
7. Specify the add_scan_mode command to connect the scan chains to the EDT signals and
EDT hardware that you inserted during the second insertion pass. Scan insertion for
wrapper cells requires using multi-mode scan insertion as described in the Tessent Scan
and ATPG User’s Manual. Do the following (see lines 41-46):
a. Create one scan mode for the entire population of scan cells:
The entire population of scan cells are stitched into the first scan mode using the
add_scan_mode int_mode command to generate a scan mode consisting of all the
scan cells stitched together.
b. Create a second scan mode only for the shared and dedicated wrapper cells:
In the second DFT insertion pass, you had generated a DFT signal named
“int_mode” with the add_dft_signal command. This signal enables this scan mode.
You do not need to specify the add_scan_mode -enable_dft_signal switch when the
mode name matches the name of a DFT signal of type scan mode.
The add_scan_mode ext_mode command stitches the shared and dedicated wrapper
cells together. Likewise, you had previously generated a DFT signal named “ext_mode”
that enables this scan mode.
Examples
The following dofile shows a command flow for scan insertion. The highlighted statements
illustrate additional considerations for performing scan insertion for wrapper cores. For a
general overview, refer to “Perform Scan Chain Insertion” for a flat design.
Example 4-4. Scan Chain Insertion in Hierarchical Flow
1 set_context dft -scan -design_id gate

2

December 2017
3 # You must respecify the TSDB

5
6 # Read Tessent library
7 read_cell_library ../../../library/tessent/adk.tcelllib
8
9 # Read synthesized netlist
10 read_verilog ../3.synthesis/processor_core_synthesized.vg
11
12 # Use read_design to read in the DFT signals and other data from
13 # the second DFT insertion pass
14 read_design processor_core -design_id rtl2 -no_hdl
16
17 # If there are no ATPG models available for memories, use blackboxes
18 add_black_boxes -modules { \
19 SYNC_1RW_8Kx16 \
20 }
21
23
24 report_clocks
25 # Exclude the EDT channel in and out ports from wrapper chain analysis
26 # The ijtag_* edt_update ports are automatically excluded
27 set_wrapper_analysis_options \
28 -exclude_ports [ get_ports {*_edt_channels_*} ]
29
30 # To force insertion of dedicated wrapper cell use the following command
31 # set_dedicated_wrapper_cell_options on -ports {.... }
32
33 # Perform wrapper cell analysis
34 analyze_wrapper_cells
35 report_wrapper_cells -Verbose
36
37 # Find edt_instance
38 set edt_instance [get_instances -of_icl_instances \
39 [get_icl_instances -filter tessent_instrument_type==mentor::edt]]
40
41 # Specify different modes (internal and external) of the chains that need
42 # to be stitched
43 # The type internal/external and enable_dft_signal are inferred from the
44 # registered DFT signals(int_mode and ext_mode)
45 add_scan_mode int_mode -edt_instances $edt_instance
46 add_scan_mode ext_mode -chain_count 2
47
48 # Before scan insertion you can analyze the different scan modes and scan
# chains
49 analyze_scan_chains
50 report_scan_chains
51 //delete_scan_modes -all
52 # Insert scan chains and write the scan inserted design into the TSDB
53 insert_test_logic
54 report_scan_chains
55 report_scan_cells > scan_cells.list
56
57 exit

December 2017

Generating ATPG patterns for a wrapped core includes a step for generating a graybox model.
In addition, you must perform ATPG twice, once for the core’s external mode and once for the
core’s internal mode.
ATPG pattern generation at the core level involves the following four steps. Refer to “Perform
ATPG Pattern Generation” for flat designs for a general description.
Figure 4-16. ATPG Pattern Generation Flow for Wrapped Cores
As described in “Hierarchical DFT Terminology,” the graybox model excludes the internal
mode logic of the wrapped core, preserving only the external mode logic that needs to be tested
at the parent level. The IJTAG infrastructure is preserved in the graybox model also.
Specifically, Tessent preserves the external logic that is present between the primary input and
the input wrapper cells, plus any logic between the output wrapper cells and primary output.
The parent could be another wrapper core or the top level of the chip.
You can use external mode patterns, if generated, for calculating fault coverage for the entire
core (both internal and external mode). Use the internal mode ATPG patterns for ATPG pattern
retargeting when performing the RTL and scan DFT insertion process on the top level of the
chip.
Procedure
1. Generate graybox models (see Example 4-5 on page 102 for a command flow example):
a. Load in the design using the same design ID as you used for scan insertion to write
the graybox to the TSDB.
(Recommended) Use “gate” as the design ID if you inserted the MemoryBIST and
EDT logic at the RTL level and “gate3” if the logic was also inserted into the gate
level.
b. Specify the analyze_graybox command to generate graybox models.

December 2017
When working at the parent level, using the same design ID for the graybox model
as you used for scan insertion allows Tessent to access the full design view or the
graybox model with the same design ID.
2. Run ATPG on the external mode of the wrapped core. This ATPG pattern is only used
to calculate the entire core's fault coverage and cannot be reused from the chip-level. To
generate ATPG patterns for external mode, do the following:
a. Read in the graybox model of the design with the read_design command.
b. Use the set_current_mode command to specify a unique ATPG mode name that
represents the purpose of the pattern. The mode type is external.
c. Use the import_scan_mode command to retrieve the core’s external mode data.
Tessent uses the graybox model of the core. Using the import_scan_mode command
assumes that you used Tessent Scan to perform scan chain stitching.
d. After running DRC and generating the ATPG patterns, use the write_tsdb_data
command to store the TCD, flat model, fault list and PatDB files in the TSDB.
e. Use the write_patterns command to write out the testbench required to simulate the
generated ATPG patterns.
See Example 4-6 on page 102.
3. Run ATPG on the internal mode of the wrapped core. This results in the ATPG pattern
that you will retarget at the top level of the chip. To generate ATPG patterns for internal
mode, do the following:
a. Load in the graybox views for the wrapper cores that contain child wrapper cores.
b. Specify a unique ATPG mode name with the set_current_mode command. The
current mode type is internal. Typical mode names are scan_mode_name_sa or
scan_mode_name_tdf.
c. If you used Tessent Scan for scan insertion, specify import_scan_mode to import the
internal mode.
d. After running DRC and generating the ATPG patterns, store the TCD, flat model,
fault list and PatDB files in the TSDB using the write_tsdb_data command.
e. Use the read_faults command to merge the fault list from running external mode to
find the total overall fault coverage of the wrapped core.
See Example 4-7 on page 103.
4. Run Verilog simulation of the core-level ATPG patterns.
Performing this task ensures that the patterns will function as desired when they are
retargeted at the parent level. For parallel load patterns as specified by the write_patterns
-parallel command, simulate all the patterns. For serial load patterns, a handful of

December 2017
patterns are sufficient; the runtime for simulating gate-level serial load patterns is
significant.
Examples
Generate the Graybox Model
The following example creates a graybox model for a scan-inserted processor_core design and
saves the data under the “gate” design ID.
Example 4-5. Graybox Example
set_context patterns –scan –design_id gate

read_cell_library ../../../library/tessent/adk.tcelllib
## Reads in the scan inserted netlist/design

read_design processor_core -design_id gate -verbose
set_current_design processor_core
add_black_boxes -modules { \
SYNC_1RW_8Kx16 \
}
report_dft_signals
import_scan_mode ext_mode
check_design_rules
analyze_graybox
write_design -tsdb -graybox -verbose
exit
Run ATPG on the Core’s External Mode

The following example shows the command flow for running ATPG on the external mode of a
core.
Example 4-6. ATPG External Mode

# Read in the graybox model useing the -view switch

read_design processor_core -design_id gate -view graybox -verbose
# Use add_scan_mode to specify a different name than what was used during
scan insertion
set_current_mode edt_multi_SAF -type external
report_dft_signals

December 2017
# Extract the external mode specified during scan insertion

import_scan_mode ext_mode
report_core_instances
report_static_dft_signal_settings
# Run DRC, Tessent Shell prompts changes to Analysis

check_design_rules
report_clocks
set_xclock_handling x
# Generate ATPG patterns

create_patterns
# Store TCD, flat_model, fault list and PatDB files in the TSDB
write_tsdb_data -replace
write_patterns patterns/processor_core_ext_stuck_parallel.v -verilog \
-parallel -replace -parameter_list {SIM_KEEP_PATH 1}
set_pattern_filtering -sample_per_type 2
write_patterns patterns/processor_core_ext_stuck_serial.v \
-verilog -serial -replace -parameter_list {SIM_KEEP_PATH 1}
exit
Run ATPG on the Core’s Internal Mode

The following example shows the command flow for running ATPG on the internal mode of a
core.
Example 4-7. ATPG Internal Mode

# Read in the full scan-inserted netlist
read_design processor_core -design_id gate
# Use add_scan_mode to specify a different name than what was used during
scan insertion
set_current_mode int_mode_sa -type internal
report_dft_signals
# Extract the internal mode specified during scan insertion

import_scan_mode int_mode
# Run DRC
check_design_rules
report_clocks
add_fault -all
report_statistics -detail
# Generate ATPG patterns

create_patterns

December 2017
# Store TCD, flat_model, fault list and PatDB files in the TSDB
write_patterns patterns/processor_core_stuck_parallel.v -verilog \
write_patterns patterns/processor_core_stuck_serial.v \
-verilog -serial -replace -parameter_list {SIM_KEEP_PATH 1}
exit
# To view the coverage of the faults testable by internal mode, you must
# eliminate the undetected faults, which would be those generated in
# external mode. Do this by merging in the fault list generated from
# running the graybox in external mode
read_faults -mode ext_multi_SAF –fault_type stuck -merge
# Final coverage of the core that includes internal and external modes
exit
Run Recommended Validation Step for Pre-Layout

Design Sign Off
During the first pass of the hierarchical DFT insertion flow for a wrapped core, you insert and
simulate the MemoryBIST hardware, mostly at RTL level. To ensure that the MemoryBIST
simulation passes before the core is signed off as the pre-layout netlist, re-run MemoryBIST
simulation at gate level on the core’s scan-inserted netlist.
Procedure
1. Read in the scan-inserted netlist from the TSDB
Using the recommended naming conventions for the RTL and scan DFT insertion flow,
the design ID would be “gate” if you inserted the MemoryBIST and EDT logic at the
RTL level and “gate3” if the logic was also inserted into the gate level.
2. Elaborate the design and run DRC.
3. Create the input test patterns and simulation files.
4. Simulate the testbench.
Tessent Shell stores the generated testbench in the TSDB under the Patterns directory
using the design ID “gate”.
Examples
The following example shows how to validate the MemoryBIST patterns for a scan-inserted
netlist.

December 2017
set_context patterns –ijtag –design_id gate

##Reading the tessent cell library

## Reading the scan inserted netlist

read_design processor_core -design_id gate -verbose -view interface
add_black_boxes -modules { \
SYNC_1RW_8Kx16 \
}
check_design_rules
process_patterns_specification
set_simulation_library_sources -v ../../../library/memory/
SYNC_1RW_8Kx16.v -v ../../../library/verilog/adk.v
run_testbench_simulation
exit

December 2017
RTL and Scan DFT Insertion Flow for the Top Chip
After performing the RTL and scan DFT insertion flow for each wrapped core in your design,
you can perform the DFT insertion process for the top-level chip design.
Before implementing DFT at the top level of the chip, plan how you will test the wrapped cores
at the chip level. The planning for logic testing the wrapped cores is not automated, so you must
decide how you will allocate the resources and organize the test schedule (especially for ATPG
pattern retargeting) and specify your intent by using the add_dft_modal_connections command.
The RTL and scan DFT insertion flow for the top level of a chip follows the same basic process
you used for the cores, with the addition of a step for retargeting the ATPG patterns you
generated for the wrapped cores.
Figure 4-17. Two-Pass Insertion Flow for RTL, Top Level
In addition, processing at the chip level differs from wrapped cores in that you must insert a
Test Access Mechanism (TAM). A TAM is a mechanism that you use to carry the scan data in
and out of the chip for each group of wrapped cores you intend to run in parallel. It schedules
the tests for the wrapped cores at the top level, and it allows access to the chip level so that you
can run these tests.
During insertion and pattern generation, you will be opening the TSDBs that store the wrapped
core design data and reading in the designs for their graybox models. The DFT insertion flow
for the top level of the chip requires differentiating between three design views of the wrapped
cores.
• Full netlist view. All the logic for the core. This is the default view when you do not
explicitly specify a design view with the read_design command.

December 2017
• Graybox model. External mode logic for the core as described in “Hierarchical DFT
Terminology,” including its IJTAG interface. You use this view so that Tessent Shell
can connect the wrapped cores at the top level for logic testing of the chip.
• Interface view. The core’s ports only. Tessent auto-loads the interface view of any sub-
physical block for which you have not use read_design to load its view.
Top-Level DFT Insertion Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan . 109
Second DFT Insertion Pass: Top-Level EDT and OCC. . . . . . . . . . . . . . . . . . . . . . . . . . 112
Scan Chain Insertion Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
ATPG Pattern Generation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Performing Top-Level ATPG Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Top-Level DFT Insertion Example

To illustrate the RTL and scan DFT insertion flow for the top level of a chip, this section uses
two wrapped cores, processor_core and gps_baseband. The processor core has memory
instantiated within it, and the GPS baseband is a logic-only core that is instantiated twice.
The following figure shows the view at the top level before DFT insertion.
Figure 4-18. Top-Level Example, Before DFT Insertion

December 2017
After performing the RTL and scan DFT insertion process for the wrapped cores, the
architecture looks as follows. Each of the cores has an EDT controller and a child OCC. The
processor core has the memories with MemoryBIST already inserted.
Figure 4-19. Top-Level Example, After DFT Insertion for Wrapped Cores
After inserting DFT at the top level, the design includes a TAP controller along with boundary
scan, a top-level EDT controller, a parent OCC, and a simple TAM for purposes of retargeting
the wrapped cores (not shown in the picture below).
In this top-level example test case, the hierarchical core starts with RTL insertion, and in
addition, at the top level we would like to perform DFT at RTL as well. However, there is no
RTL logic at the top level that needs to be synthesized. The PLL and pad IOs are Verilog
macros. The only RTL that needs to be synthesized is the Tessent-generated RTL. Hence, this
test case uses design IDs “gate1” and “gate2” for the first two DFT insertion passes,
respectively.

December 2017
Figure 4-20. Top-Level Example, After DFT Insertion at the Top Level
First DFT Insertion Pass: Performing Top-Level

MemoryBIST and Boundary Scan
For the top level of a chip, insert boundary scan plus MemoryBIST for any memories that are
present at the top level. In addition, build the IJTAG network for the wrapped cores at the top
level and insert a TAP controller or reuse an existing TAP controller.
As with flat designs, the flow for inserting MemoryBIST and boundary scan together is the
same as inserting them separately. For details about this insertion pass flow, refer to:
• “Getting Started” in the Tessent MemoryBIST User’s Manual, or

• “Getting Started” in the Tessent BoundaryScan User’s Manual
For information about TAP controller reuse, refer to “create_dft_specification” in the Tessent
Shell Reference Manual.
Refer to “First DFT Insertion Pass: MemoryBIST and Boundary Scan” (for flat designs) for
general information and prerequisites. For example, as with flat designs, you can segment the
boundary scan chain into smaller chains that are used during logic testing with Tessent
TestKompress by using the max_segment_length_for_logictest command.
Note
This procedure is similar for flat designs as documented in “First DFT Insertion Pass:
MemoryBIST and Boundary Scan” on page 63.

December 2017
Procedure
1. Load the design.
Note
Use the open_tsdb command to open the TSDBs for all the lower-level cores.
Opening their TSDBs makes their design data available.
There is no need to specify the read_design command because, by default, Tessent will
read in the interface views of the wrapped cores, which is all that is required for DRC for
the first DFT insertion pass.
2. Set the design level to “chip” for the top level of the chip. When working with the
wrapped cores, you had set the design level to “physical_block.”
3. Create the DFT specification.
4. Specify enough auxiliary input and output ports for the largest retargeting wrapper core
group.
5. Generate the MemoryBIST hardware and extract the ICL.
6. Create the input test patterns and simulation test benches.
7. Run simulations to verify the design.
Examples
The following dofile example shows a typical command flow for inserting boundary scan. The
flow is the same as you would use for a flat design with the exception of the commands
highlighted in bold. Notice that the chip-level design data exists in its own TSDB. This is
recommended for the data flow as described in “TSDB Data Flow for the Tessent Shell Flow.”

December 2017
set_context dft -no_rtl -design_id gate1

set_tsdb_output_directory ../tsdb_outdir
# Open the TSDB of all the wrapped cores

open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir
# Read the Tessent cell library

read_cell_library ../../library/tessent/adk.tcelllib
# Read in PLL as a blackbox so that excluded in design list that you write
out for synthesis
read_verilog ../rtl/noncore_blocks/pll.v -blackbox
# Point to Verilog libraries for the pad IO macros

set_design_sources -format verilog -v ../rtl/noncore_blocks/
pad8_io_macro.v -v ../rtl/noncore_blocks/iopad_sel.v ../rtl/
noncore_blocks/iopad.v
read_verilog ../rtl/chip_top.v
set_current_design chip_top
set_design_level chip
# Specify and verify the DFT requirements

set_dft_specification_requirements -boundary_scan on -memory_bist on
# Identify the TAP pins

set_attribute_value TCK -name function -value tckset_attribute_value TDI \
-name function -value tdi
set_attribute_value TMS -name function -value tms
set_attribute_value TRST -name function -value trst
set_attribute_value TDO -name function -value tdo
# Some pins cannot add any boundary scan cells

set_boundary_scan_port_options TEST_CLOCK_top -cell_options dont_touch
set_boundary_scan_port_options EDT_UPDATE_top -cell_options dont_touch
set_boundary_scan_port_options SCAN_ENABLE -cell_options dont_touch
set_boundary_scan_port_options RESET_N -cell_options dont_touch
set_boundary_scan_port_options INCLK -cell_options dont_touch
# Add DFT signals

add_dft_signals scan_en -source_nodes SCAN_ENABLE
report_dft_signals
add_clocks PLL_1/pll_clock_0 -reference REF_CLK -FREQ_Multiplier 16
add_clock REF_CLK -period 48
check_design_rules
# Create a dft specification

set spec [create_dft_specification]
report_config_data $spec# Segment the boundary scan to be used during
logic test
set_config_value $spec/BoundaryScan/max_segment_length_for_logictest 80
# Equip these ports with auxiliary input/output muxes to be used by EDT

channel pins
read_config_data -in ${spec}/BoundaryScan -from_string {
AuxiliaryInputOutputPorts {
auxiliary_input_ports : GPIO1_0, GPIO1_1, GPIO1_2, GPIO1_3;
auxiliary_output_ports : GPIO2_0, GPIO2_1, GPIO2_2, GPIO2_3, GPIO1_0,

December 2017
GPIO1_1 ;
}
}
extract_icl
run_synthesis
process_pattern_specification
set_simulation_library_sources \
-v ../../library/verilog/*.v \
-v ../rtl/noncore_blocks/pll.v \
-v ../rtl/noncore_blocks/iopad.v \
-v ../../library/memory/SYNC_1RW_8Kx16.v
exit
Second DFT Insertion Pass: Top-Level EDT and OCC

For the top level of a chip, additional considerations for the second DFT insertion pass for EDT
and OCC include grayboxes, DFT signals for purposes of ATPG retargeting, and TAMs.
Note
This procedure follows a similar flow as flat designs as documented in “First DFT Insertion
Pass: MemoryBIST and Boundary Scan” on page 63. The unique operations are
documented in the steps below.
Procedure
1. Specify the open_tsdb command to open the TSDBs for the wrapped cores, as in the first
DFT insertion pass for the chip,
2. Specify the read_design command to read in the graybox models of the wrapped cores.
This allows Tessent to perform DRC on the wrapper chains in addition to the rest of the
top-level logic that will be logic tested.
3. Define a retargeting mode for each group of wrapped cores whose ATPG patterns you
will be retargeting to run in parallel.
For ATPG pattern retargeting purposes, Tessent requires you to include retargeting
mode DFT signals in addition to the DFT signals defined in section “DFT Signals.” The
retargetingX_mode signals along with the TAM specified with the
add_dft_modal_connections command ensure that ATPG pattern retargeting occurs
correctly. Optionally, you can register your own DFT signals to be used for retargeting
purposes.
Example 4-8 on page 113 shows demonstrates retargeting of two wrapped cores,
processor_core and gps_baseband.

December 2017
4. Apply the add_dft_modal_connections command to specify the TAM.

During the first insertion pass, you identified the functional pins to be shared with EDT
channel pins and added the required auxiliary input and auxiliary output logic. Now you
use the TAM to sensitize paths to and from the top-level EDT using the
set_config_value command.
In Example 4-8 on page 113, the functional input pin GPI01_0 is shared as an EDT
channel input pin. Similarly, the functional output pin GPI02_0 is shared as an EDT
channel output pin.
5. Combine with top-level EDT mode signal you defined by connecting the EDT channel
IOs of the wrapped cores to top-level pins via the TAM. Use the
add_dft_modal_connections command.
6. Apply the set_defaults_value command to specify that Tessent Shell simulate the
instruments within the wrapped cores in addition to the top-level instruments.
Examples
The following dofile example shows that the DFT insertion flow for inserting EDT and OCC
into the top level of a chip follows the same basic process as for flat designs as described in
“Second DFT Insertion Pass: EDT and OCC,” with the exception of the highlighted commands.
Example 4-8. Top-Level Second DFT Pass
set_context dft -no_rtl -design_id gate2

open_tsdb ../../wrapped_cores/processor_core/tsdb_outdir
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_outdir
set_design_sources -format verilog -v ../rtl/noncore_blocks/iopad_sel.v \
-v ../rtl/noncore_blocks/iopad.v
read_design chip_top -design_id rtl1 -verbose
read_design gps_baseband -design_id gate -view graybox -verbose

December 2017
# Add DFT Signals

# When using boundary scan in logic test without contacting inputs
add_dft_signals int_ltest_en output_pad_disable -create_with_tdr
# Needed for Scan Tested Instruments such as MemoryBIST and boundary scan
# When you are using logic test

# Used by top-level EDT

add_dft_signals edt_mode -create_with_tdr
# These are used for the top-level EDT

add_dft_signals test_clock edt_update \
-source_nodes {TEST_CLOCK_top EDT_UPDATE_top}
add_dft_signals shift_capture_clock edt_clock -create_from_other_signals
# Retargeting mode signals used for ATPG pattern retargeting

add_dft_signals retargeting1_mode retargeting2_mode retargeting3_mode \
retargeting4_mode
# Add simple TAM connections

# For chip-level EDT mode, the asterisk(*) means do not make connection to
the data inputs
add_dft_modal_connections -ports GPIO1_0 -input_data_destination_nodes * \
-enable_dft_signal edt_mode
add_dft_modal_connections -ports GPIO2_0 -output_data_source_nodes * \
-enable_dft_signal edt_mode
# Connect wrapped core EDT channel I/Os to top level for retargeting1_mode
signal
add_dft_modal_connections -ports GPIO1_2 -input_data_destination_nodes
PROCESSOR_1/processor_core_rtl2_controller_c1_edt_channels_in[0] \
-enable_dft_signal retargeting1_mode
add_dft_modal_connections -ports GPIO2_2 -output_data_source_nodes
PROCESSOR_1/processor_core_rtl2_controller_c1_edt_channels_out[0] \
# Connect wrapped core EDT channel I/Os to top level for retargeting2_mode
signal
GPS_1/gps_baseband_rtl1_controller_c1_edt_channels_in[0] \
GPS_2/gps_baseband_rtl1_controller_c1_edt_channels_in[0] \
...
add_dft_modal_connections -ports GPIO1_0 -output_data_source_nodes GPS_1/
gps_baseband_rtl1_controller_c1_edt_channels_out[0] \
-enable_dft_signal retargeting2_mode -pipeline_stages 1
add_dft_modal_connections -ports GPIO1_1 -output_data_source_nodes GPS_1/
gps_baseband_rtl1_controller_c1_edt_channels_out[1] \
-enable_dft_signal retargeting2_mode -pipeline_stages 1
...

December 2017
report_dft_modal_connections
set_dft_specification_requirements -logic_test On
add_clocks INCLK -period 10ns
check_design_rules
report_dft_control_points
# Create DFT specification
set spec [create_dft_specification -sri_sib_list {occ edt} ]
OCC {
ijtag_host_interface : Sib(occ);
}
}
set id_clk_list [list \
pll_clock_0 PLL_1/pll_clock_0 \
INCLK INCLK \
]
foreach {id clk} $id_clk_list {
set occ [add_config_element OCC/Controller($id) -in $spec]
set_config_value clock_intercept_node -in $occ $clk
}
EDT {
...
}
[get_single_name [get_auxiliary_pins GPIO1_0 -direction input]]
-in $spec/EDT/Controller(c1)/Connections/EdtChannelsOut(1)
[get_single_name [get_auxiliary_pins GPIO2_0 -direction output] ]
extract_icl
# By setting this value, all the lower level instruments in the wrapped
cores are simulated
set_defaults_value /PatternsSpecification/SignoffOptions/
simulate_instruments_in_lower_physical_instances on
process_pattern_specificationset_simulation_library_sources -v ../../
library/verilog/*.v \
...
exit

December 2017
Scan Chain Insertion Example

For the top level of the chip, additional considerations for scan chain insertion include opening
the TSDBs for the wrapped cores and reading in the wrapped core graybox models as you did
for the second DFT insertion pass.
Note
Prior to scan chain insertion, perform synthesis as described in section “Perform Synthesis.”
Logic that is present at the top-level needs to be scan stitched along with the wrapper chains
(external mode) of the cores.
Refer to “Perform Scan Chain Insertion” (for flat designs) for more information about scan
chain insertion. The following dofile example shows that Tessent Shell needs to access the
graybox models for each wrapped core.
set_context dft -scan -design_id gate

open_tsdb ../../wrapped_cores/processor_core/tsdb_core
open_tsdb ../../wrapped_cores/gps_baseband/tsdb_core
set_design_sources -format verilog -v ../rtl/noncore_blocks/iopad_sel.v -v ../rtl/
noncore_blocks/iopad.v
read_verilog ../Synthesis/chip_top_synthesized.vg
read_design chip_top -design_id rtl2 –no_hdl -verbose
check_design_rules
report_clocks
set edt_instance [get_name_list [get_instance -of_module [get_name [get_icl_module -

of_instances chip_top* -filter tessent_instrument_type==mentor::edt]]] ]
add_scan_mode edt_mode -edt_instance $edt_instance
analyze_scan_chains
report_scan_chains
insert_test_logic
exit
ATPG Pattern Generation Example

At the top level, Tessent Shell uses the scan-inserted design data for the chip. In the
recommended flow this equates to design ID “gate.” In addition, Tessent uses the graybox
models for the wrapped cores so that you can use the external mode of the wrapper chains to run
ATPG.

December 2017
Refer to “Perform ATPG Pattern Generation” (for flat designs) for information about generating
the ATPG patterns. The flow for the top level of a chip builds onto the process by adding in the
grayboxes and blackboxes. As with flat designs, you have a choice between using the boundary
scan chains for capture or using the primary pins of the chips (using the pads).
The following dofile example generates ATPG patterns at the top level using the stuck-at fault
model. The dofile shows that you can read in the stuck-at fault models for the wrapped cores to
calculate the total fault coverage for the chip.
set_context pattern -scan

set_tsdb_output_directory ../tsdb_top
# Read the Verilog

set_design_sources -format verilog -v ../rtl/noncore_blocks/iopad.v -v ../
rtl/noncore_blocks/iopad_sel.v
read_design chip_top -design_id gate

set_current_mode edt_top_stuck
import_scan_mode edt_mode
set_static_dft_signal_values tck_occ_en 1
add_fault –all
create_patterns
write_patterns patterns/chip_top_edt_parallel.v -verilog -parallel \

-replace -scan -parameter_list {SIM_KEEP_PATH 1}
write_patterns patterns/chip_top_edt_serial.v -verilog -serial -replace \
write_patterns patterns/chip_top_edt_stuck.stil -stil -replace
# Total fault coverage for stuck-at patterns at the chip-level including

the cores
read_faults -module processor_core –mode edt_int_stuck \
–fault_type stuck –merge -graybox
read_faults –module gps_baseband –module edt_int_stuck \
–fault_type stuck –merge -graybox
report_statistics –detail
exit

December 2017
Performing Top-Level ATPG Pattern Retargeting

For each wrapped core, retarget the internal ATPG patterns for all the modes you have specified
and all the fault types.
Note
This procedure is similar to “Perform ATPG Pattern Generation” on page 100.
Procedure
1. Specify the set_context patterns -retargeting command to retarget the ATPG patterns
generated for the wrapped cores.
2. Use the same TSDB for ATPG retargeting as you used for ATPG pattern generation.
3. Set the current mode to a unique mode name that, ideally, indicates the core name, the
fault type, and the retargeting mode DFT signal you had previously defined.
4. Specify which wrapped core ATPG patterns you are retargeting by enabling the correct
retargeting mode DFT signal. Set the set_static_dft_signal_values command to the
retargeting mode for this wrapped core.
5. Apply the add_core_instances command to specify the wrapped core whose internal
ATPG patterns you will be retargeting.
6. Apply the read_patterns command to read in the stuck-at ATPG patterns that you will be
retargeting.
Examples
The following dofile example shows how you would retarget the stuck-at ATPG patterns for the
wrapped core, processor_core.
Example 4-9. Retarget Stuck-At ATPG Patterns for the Top-Level
set_context pattern -scan_retargeting

set_design_sources -format verilog -v ../rtl/noncore_blocks/iopad.v \
-v ../rtl/noncore_blocks/iopad_sel.v
read_design chip_top -design_id gate

December 2017
# Retarget processor_core stuck-at patterns

set_current_mode retarget1_processor_stuck
set_static_dft_signal_values retargeting1_mode 1
set child_core_instance [get_attribute_value_list [get_icl_instance \
-filter tessent_design_level==physical_block] \
-name hierarchical_design_instance]
add_core_instances -instances {PROCESSOR_1} -core processor_core \
-mode edt_int_stuck
report_core_descriptions
import_clocks –verbose
report_clocks
# Read the patterns to be retargeted

read_patterns -module processor_core -fault_type stuck -mode edt_int_stuck
write_patterns patterns/processor_core_edt_stuck_retargeted.v -verilog \

-parallel -replace -begin 0 -end 7 -scan \
write_patterns patterns/processor_core_edt_stuck_retargeted_serial.v \
-verilog -serial -replace -Begin 0 -End 2 \
# Write out the STIL file that will used on the tester
write_patterns patterns/processor_core_edt_stuck_retargeted.stil \
-stil -replace
exit
The following dofile snippet shows how you would retarget at-speed transition ATPG patterns
for the wrapped core, gps_baseband. Commands that are not shown are the same as shown
above for processor_core.
Example 4-10. Retarget At-Speed Transition ATPG Patterns for the Top-Level
# Set the context and open TSDBs ...
# Read in cell libraries, PLL, macro IO pads, designs ...
# Set the current design ...
# Retarget gps_baseband transition patterns

set_current_mode retarget2_gps_transition
set_static_dft_signal_values retargeting2_mode 1
set child_core_instance [get_attribute_value_list [get_icl_instance \
-filter tessent_design_level==physical_block] \
-name hierarchical_design_instance]
add_core_instances -instances {GPS_1 GPS_2} -core gps_baseband \
-mode edt_int_transition
report_core_descriptions
import_clocks -verbose
report_clocks

December 2017
# Read the patterns to be retargeted
read_patterns -module gps_baseband -mode edt_int_transition \
-fault_type transition
write_patterns patterns/gps_edt_transition_retargeted.v -verilog \

-parallel -replace -begin 0 -end 7 -scan \
write_patterns patterns/gps_edt_transition_retargeted_serial.v \
-verilog -serial -replace -Begin 0 -End 2 \
# Write out the STIL file that will used on the tester
write_patterns patterns/gps_edt_transition_retargeted.stil -stil -replace
exit

December 2017
RTL and Scan DFT Insertion Flow for Sub-Blocks

When performing the DFT insertion flow with sub-blocks, you insert MemoryBIST and pre-
DFT DRCs at the sub-block level and then move up to the sub-block’s next parent physical
block level (where the sub-block is instantiated) to perform synthesis and scan insertion.
Refer to “Hierarchical DFT Terminology” for more information about sub-blocks.
You may want to use the sub-block flow for any of the following reasons.
• Multiple instantiations. You only need to perform the DFT insertion flow once for a sub-
block. Thereafter, every instantiation of the sub-block will include the inserted DFT
hardware.
• Small size. Most sub-blocks are not big enough to be considered their own physical
regions.
• Readiness. Sometimes the sub-block RTL is complete before the RTL for the physical
layout region, thus you can begin DFT insertion on the sub-block as soon as RTL is
ready.
DFT Insertion Flow for the Sub-Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
DFT Insertion Flow for the Next Parent Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
DFT Insertion Flow for the Sub-Block

The DFT insertion flow for sub-blocks is similar to the insertion flow for physical blocks with a
few exceptions.
The main differences between this flow and that for physical blocks as described in “RTL and
Scan DFT Insertion Flow for Physical Blocks” are:
• Do not perform synthesis or scan insertion at the sub-block level because the sub-block
netlist may not exist after synthesis.
• During the second DFT insertion pass, you will only be inserting pre-DFT DRCs.
Typically, you do not insert EDT controllers at the sub-block level because the logic
inside of the sub-block is too small and the sub-block module itself may not exist after
synthesis. You can insert an EDT controller at the next parent level that you dedicate to
testing the logic inside of a sub-block. In most cases, this EDT controller is active at the
same time as other EDT controllers that are present at the next parent level.
Note
The sub-block flow for inserting MemoryBIST and pre-DFT DRCs follows the same steps
as discussed in the “RTL and Scan DFT Insertion Flow for Physical Blocks,” with the
exception of generating the EDT and OCC hardware. There are slight variations, which are
described in the following procedure.

December 2017
Procedure
1. First DFT Insertion Pass: Performing Block-Level MemoryBIST. Ensure that you set
the design level to “sub_block” rather than “physical_block”.
set_design_level sub_block
2. Second DFT insertion pass: insert pre-DFT DRCs. Follow the steps for the “Second
DFT Insertion Pass: Block-Level EDT and OCC” procedure, excluding generating the
EDT and OCC hardware.
Since you specified that you were working at the sub_block level in the first DFT
insertion pass, you do not need to re-specify this information for the second insertion
pass.
After specifying and verifying the DFT requirements, Tessent Shell performs the
following tasks automatically:
• At the sub-block level, any static DFT signals you have added are implemented as
IJTAG ports rather than inserted via TDRs. Tessent Shell automatically connects the
IJTAG ports to the TDR at the next parent level.
• At the next parent level, adds DFT signals such as ltest_en and
async_set_reset_static_disable. Tessent Shell infers the add_dft_control_point
command on the sub-block pins if you have DFT DRCs that required fixing.
• At the next parent level, adds the tck_occ_en DFT signal if there is a STI-SIB
network inside the sub-block.
The following command performs pre-DFT DRC.
During ICL extraction, Tessent Shell generates the Synopsys Design Constraints (SDC)
for the sub-block.
Results
Proceed to performing the DFT insertion flow on the next parent level where this sub-block is
instantiated.
DFT Insertion Flow for the Next Parent Level

The next parent level where a sub-block is instantiated may be a physical layout block that is a
wrapped core or the physical layout region that is the chip. The following procedure describes
the flow when you have a sub-block instantiated at the chip-level.

December 2017
Prerequisites
• You have performed the DFT insertion flow as described in “DFT Insertion Flow for the
Sub-Block” for the sub-blocks instantiated at this parent level so that you have the
design after a clean pre-DFT DRC run.
Note
The following procedure follows the DFT insertion process described in “RTL and Scan
DFT Insertion Flow for the Top Chip”. When you have a sub-block inserted inside a
wrapped core, follow the steps described in “RTL and Scan DFT Insertion Flow for Physical
Blocks,” ensuring that you load the sub-block design as described below.
Procedure
1. First DFT Insertion Pass: Performing Top-Level MemoryBIST and Boundary Scan.
When you load the design, open the sub-block’s TSDB and load the design of the sub-
block that passed pre-DFT DRCs. See the example below.
2. Second DFT Insertion Pass: Top-Level EDT and OCC. When you load the design, open
the sub-block’s TSDB, load the full design for the sub-block, and load the design for the
top-level after the first DFT insertion pass. See the example below.
3. Synthesis. Synthesis of the chip-level RTL and the sub-block’s post-DFT inserted RTL
occur at the same time. Tessent Shell merges the sub-block into the parent-level logic.
Refer to “Timing Constraints (SDC)” to learn how the synthesis constraints from the
sub-block are merged at the next parent level.
4. Scan Chain Insertion. Tessent Shell performs scan chain insertion on the sub-block and
parent-level logic at the same time.
5. ATPG Pattern Generation.
Examples
Design Loading for the First DFT Insertion Pass
The following example shows opening the TSDB for the sub-block and using read_design to
read in the sub-block (processor_core) design.
# Set the context to insert DFT into RTL-level design

set_context dft -rtl -design_id rtl1
# Set the location of the TSDB. Default is the current working directory.
# Open the TSDBs for all the instantiated sub-blocks

open_tsdb ../../sub_block/tsdb_outdir
# Read the tessent cell library
# Read the design
read_verilog ../../rtl/chip_top.v

December 2017
# Explicitly load the sub-block netlist

read_design processor_core -design_id rtl2 -verbose
set_design_level chip
# Follow the rest of the flow for the first DFT insertion pass for a chip.
Design Loading for the Second DFT Insertion Pass

# Set the context to insert DFT. Define a new design ID
set_context dft -rtl -design_id rtl2
# Set the location of the TSDB. Default is the current working directory.
# Open the TSDBs for all the instantiated sub-blocks

open_tsdb ../../sub_block/tsdb_outdir
# Read the tessent cell libraryread_cell_library ../../library/tessent/

adk.tcelllib
# Read the verilogread_verilog ../../rtl/noncore_blocks/pll.v -

blackboxset_design_sources -format verilog -v ../../rtl/noncore_blocks/
iopad_sel.v -v ../../rtl/noncore_blocks/iopad.v
read_design chip_top -design_id rtl1 -verbose

# Explicitly load the sub-block netlist
read_design processor_core -design_id rtl2 -verbose
# Follow the rest of the flow for the second DFT insertion pass for a chip

December 2017
Tessent Shell Post-Layout Validation Flow
Tessent Shell Post-Layout Validation Flow

Performing physical place and route on pre-layout netlists results in post-layout netlists you
must validate before you proceeding to tape-out.
This flow assumes that you are familiar with the pre-layout flows as described in “Tessent Shell
Flow for Flat Designs” and “Tessent Shell Flow for Hierarchical Designs,” especially as related
to performing ATPG pattern generation.
Overview of the Post-Layout Validation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Soft Link TSDB and Post-Layout Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Verify MemoryBIST, Boundary Scan and IJTAG Patterns . . . . . . . . . . . . . . . . . . . . . . 127
Verify the Scan-Inserted ATPG Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic . . . . . . 129
Overview of the Post-Layout Validation Flow

You can validate the post-layout netlist for hierarchical core, hierarchical top and flat chip-level
designs.
As shown in the following figure, you must first generate a soft link in the TSDB that points to
the post-layout netlist. Then you verify the patterns for the MemoryBIST, boundary scan (if
any) and IJTAG network, followed by verifying the post-scan-inserted ATPG patterns.
Figure 4-21. Post_Layout Validation Flow
This flow assumes that within the post-layout netlist, modules exist for the IJTAG network and
inserted EDT and OCC instruments. That is, they remain distinct logical entities. Refer to “Post-
Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic” if you have
ungrouped (unpreserved) logic.

December 2017
Soft Link TSDB and Post-Layout Netlist
Soft Link TSDB and Post-Layout Netlist

The soft link allows Tessent Shell to access the post-layout netlist for validation purposes. You
are associating and linking the post-layout netlist (place-and-routed design) with all the pre-
layout data files such as the ICL, TCD, and PDL.
Prerequisites
• You have previously performed the pre-layout flow so that you have the post-scan
inserted DFT data files (ICL, PDL, TCD, and so on).
• You have post-layout netlist as a result of place and route.
Procedure
1. Load the design, including the post-layout netlist (lines 1-15). Ensure that you specify a
unique design ID, such as “post_layout”.
2. Add any black boxes, as applicable, and set the design level, which can be chip,
physical_block, or sub_block (lines 17-22).
3. Save the updated netlist (line 23). Ensure that you use the -softlink_netlist option with
the write_design command. Using this switch references the post-layout netlist rather
than copies it into the TSDB. This prevents duplication and allows the post-layout netlist
to be updated without the need to repeat this step.
Examples
The following example generates an updated netlist for a wrapped core named processor_core
that includes a soft link to the core’s post-layout netlist.
1 set_context patterns -ijtag -design_id post_layout

2
3 # Set the location of the TSDB
5
6 # Read the Tessent Cell Library
8
9 # Read the post-layout netlist and elaborate the design
10 read_verilog ../netlist/processor_core_layout.vg
11
12 # Read in the scan-inserted design data files generated during pre-layout
13 # The -no_hdl switch loads all relevant data except the original netlist
14 read_design processor_core -design_id gate -no_hdl -verbose
15
17
19 SYNC_1RW_8Kx16 \
20 }
21
22 # Specify the design level before writing out the softlink
23 set_design_level physical_block

December 2017
Verify MemoryBIST, Boundary Scan and IJTAG Patterns
24 write_design -tsdb -softlink_netlist -verbose

25 exit
Verify MemoryBIST, Boundary Scan and IJTAG

Patterns
Create and validate the MemoryBIST, boundary scan (if present), and IJTAG network patterns
by creating and processing a Patterns Specification with the create_patterns_specification and
process_patterns_specification commands.
Prerequisites
• You have generated a soft link in the TSDB that points to the post-layout netlist as
described in “Soft Link TSDB and Post-Layout Netlist.”
Procedure
1. Load the design by using read_design and pointing to the soft-linked post-layout netlist
(lines 1-9).
2. If needed, add black boxes, and then check the design rules (lines 11-14).
3. Create, simulate and check the testbenches (see lines 16-24). Refer to
create_patterns_specification and process_patterns_specification in the Tessent Shell
Reference Manual for details.
Examples
Verify the Patterns with a new Patterns Specification
The following example verifies the patterns for a hierarchical core, processor_core.
1 set_context patterns -ijtag -design_id post_layout

3
4 # Reading the tessent cell library
6
7 # Reading the soft-linked post-layout netlist from the tsdb_core
8 read_design processor_core -design_id post_layout –verbose
10
12 SYNC_1RW_8Kx16 \
13 }
15
16 create_patterns_specification
17 process_patterns_specification
18
19 set_simulation_library_sources -v ../../../library/memory/
SYNC_1RW_8Kx16.v
20 -v ../../../library/verilog/adk.v
21

December 2017
Verify the Scan-Inserted ATPG Patterns
22 # Disable clock monitoring when running simulation on post-layout netlist

23 run_testbench_simulations -simulation_macro_definitions
MGC_DISABLE_CLOCK_MONITOR
24 check_testbench_simulations -report_status
25 exit
Verify the Patterns with a Customized Patterns Specification from Pre-Layout Signoff
You may have customized a patterns specification during pre-layout signoff. You can read in
this patterns specification that was stored in the TSDB during pre-layout signoff. Use the
read_config_data command instead of the create_pattern_specification command.
The following example shows how to read in a customized patterns specification from pre-
layout netlist. The pre-layout patterns specification
“processor_core_gate.patterns_spec_signoff” was used to create the patterns on the gate-level
scan-inserted netlist.
set_context patterns –ijtag –design_id after_layout

# Reading the tessent cell library
# Read the soft-linked post-layout netlist and elaborate the design...
check_design_rules
read_config_data ../tsdb_core/patterns/ \
processor_core_gate.patterns_spec_signoff
process_patterns_specifcation
# Read in the required libraries and simulate
...
Verify the Scan-Inserted ATPG Patterns

Perform ATPG pattern generation on the post-layout netlist.
Prerequisites
• In the SDC that was created during ICL extraction for the pre-layout DFT insertion
flow, set the tessent_get_preserve_instances proc to add_core_instances when you do
not need grayboxes. For example, when you are working with flat designs.
For wrapped cores, set the tessent_get_preserve_instances proc to icl_extraction to
automatically include ICL instances in the grayboxes.
The SDC file is located in the TSDB directory under dft_inserted_designs. Refer to
“Timing Constraints (SDC)” for more information.
Procedure
1. Load the design (lines 1-9). Ensure that you set the context to patterns -scan and read in
the soft-linked post-layout netlist.
2. Set the current mode (lines 11-12). Specify a different name than that used during scan
insertion and used during pre-layout pattern generation.
3. Perform the remainder of the ATPG pattern generation flow (see lines 14-35).

December 2017
Post-Layout Validation When You Have Ungrouped IJTAG/OCC/EDT Logic
Examples
The following example shows how to verify scan-inserted ATPG patterns by using the patterns
-scan context and a post-layout netlist. This example shows the flow for a flat design. For
hierarchical designs, refer to “Perform ATPG Pattern Generation” for specifics related to
wrapped cores and “ATPG Pattern Generation Example” for a top-level example.
1 set_context patterns -scan

2 read_cell_library ../library/tessent/adk.tcelllib
3 read_cell_library ../library/mem_ver/memory.lib
4 # Point to the TSDB directory
5 set_tsdb_output_directory ../tsdb_rtl
6
7 # Reading the post-layout netlist
8 read_design cpu_top -design_id post_layout
9 set_current_design cpu_top
10
11 # Use a unique mode name
12 set_current_mode edt_stuck_final
13
15 # If Tessent Scan was used for scan insertion, can use the scan
configuration mode
16 import_scan_mode edt_mode
17 # Set the following DFT Signal values to use the boundary scan chain to
apply/capture values that would normally use the I/O pads
18 set_static_dft_signal_values int_ltest_en 1
19 set_static_dft_signal_values output_pad_disable 1
20 # Set the following DFT signal value to apply the shift_capture_clock to
the scan-tested network during capture phase of ATPG
21 set_static_dft_signal_value tck_occ_en 1
22 report_static_dft_signal_settings
23
24 set_system_mode analysis
25
26 # Generation of ATPG patterns
27 create_patterns
28 report_statistics -detailed_analysis
29 write_tsdb_data -replace
30
31 # Patterns written out for simulation
32 write_patterns patterns/cpu_top_stuck_parallel.v -verilog -parallel -
replace -scan -parameter_list {SIM_KEEP_PATH 1}
33 write_patterns patterns/cpu_top_stuck_serial.v -verilog -serial -replace -
parameter_list {SIM_KEEP_PATH 1}
34 # Writing the STIL pattern for tester
35 write_patterns patterns/cpu_top_stuck.stil -stil -replace
36 exit
Post-Layout Validation When You Have Ungrouped

IJTAG/OCC/EDT Logic
During layout, IJTAG, OCC, and EDT logic can become ungrouped, which means the hierarchy
around this logic is dissolved so that the gates that were inside of the ungrouped instances

December 2017
become part of the next higher instance. Ungrouped test logic during layout can cause some of
the automated setup for pattern generation to no longer operate seamlessly.
The automated flow relies on preservation of Tessent test logic’s hierarchical names. Use the
following post-layout validation flow to update the TSDB with the post-layout netlist and set up
the design for ATPG. The flow assumes knowledge of the ATPG pattern generation flow for
physical blocks as described in “Perform ATPG Pattern Generation”.
Figure 4-22. Post-Layout Validation Flow with Ungrouped IJTAG/OCC/EDT

Logic
The best way to avoid complications related to ungrouping in layout is to use the
tessent_get_preserve_instances procedures in the generated SDC file to identify which
instances must be preserved based on their intended uses. See the “Synthesis Helper Procs”
section in the Tessent Shell User’s Manual. To use the add_core_instances command during
ATPG or other post-layout steps, the hierarchy of the OCC and EDT logic must be preserved.
The IJTAG logic nodes only need to be preserved if you plan to rerun ICL extraction on the
post-layout netlist, but in most cases there is no need to do this.
Procedure
1. Soft link the post-layout netlist to the TSDB. Refer to “Soft Link TSDB and Post-Layout
Netlist” for more information.
2. Generate the graybox model. Graybox models are only needed for hierarchical cores,
not for hierarchical top or flat designs. (The line numbers in this step refer to the
example “Generate the Graybox Model” on page 132.)
a. When loading the design (line 4), specify the same design that you used to write the
post-layout netlist to the TSDB, for example “post_layout”.

December 2017
Using the same design ID for the graybox model that you used for the post-layout
netlist allows Tessent to access the full design view or the graybox model with the
same design ID.
b. Read the core description for external mode using the add_core_instances command
(line 9). Since you already ran the pre-layout ATPG step and saved the TCD file to
the TSDB, the add_core_instances command can read the existing TCD file and add
the core instances that are active in external mode.
c. Use analyze_graybox to generate the graybox (line 13). If the IJTAG network was
ungrouped in layout, the analyze_graybox command can automatically find and
preserve the IJTAG SRI network as long as the default names of the logic have not
changed.
3. If you are running in hierarchical mode, run ATPG on the core’s internal mode of the
wrapped core to generate the ATPG patterns that you will retarget at the top level of the
chip. If you are running in hierarchical top or in flat mode, run ATPG. (The line
numbers in this example refer to example “Run ATPG on the Core’s Internal Mode” on
page 132.)
a. Specify a unique ATPG mode name with the set_current_mode command (line 9).
Append the name with “_post_layout” or “_final” to clarify which mode to use for
silicon diagnosis. Set the current mode type to “internal”.
b. Add the core instances using the design ID and mode from the pre-layout step (line
14). This loads the TCD file that contains the information for the design’s core
instances without the need to match them to test logic instances that may have been
ungrouped during layout.
c. You can use the read_faults command to merge the fault list from running external
mode to find the total overall fault coverage of the wrapped core (line 36).
When you run ATPG in internal mode for transition patterns, note the following:
• Specify a unique name for the ATPG run with the set_current_mode command. For
example, edt_int_tdf_final.
• Use the add_core_instances command to read the transition mode TCD. For
example:
add_core_instance -current_design -design_id gate -mode
edt_int_transition
• Ensure that you set the correct fault type:


December 2017
• You can optimize the number of capture cycles used by the OCCs by specifying the
optional capture_window_size parameter. The following command specifies a
capture_window_size of 2:
set_core_instance_parameters -instrument_type occ
-parameter_values [list capture_window_size 2]
4. Run Verilog simulation of the core-level ATPG patterns.

Performing this task ensures that the patterns will function as desired when they are
retargeted at the parent level. For parallel load patterns, as specified by the
write_patterns -parallel command, simulate all the patterns. For serial load patterns, a
handful of patterns are sufficient; the runtime for simulating gate-level serial load
patterns is significant. The set_pattern_filtering command (line 27) is used to reduce the
number of serial patterns saved for the simulation.
Examples
Generate the Graybox Model
The following example creates a graybox model for a post-layout processor_core design and
saves the data under the same design ID.
Figure 4-23. Generate Graybox Example
1 set_context patterns -scan -design_id post_layout

2 set_tsdb_output_directory ../tsdb_outdir
3 read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
4 read_design processor_core -design_id post_layout -verbose
5 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v -interface_only
7 # Use the add_core_instances command to read the TCD file.
8 #import_scan_mode ext_mode
9 add_core_instances -current_design -design_id gate
11 report_scan_cells
12 # Create and write the updated graybox model to the TSDB.
13 analyze_graybox
14 write_design -tsdb -graybox -verbose
15 exit
Run ATPG on the Core’s Internal Mode

Figure 4-24. Run ATPG on the Core’s Internal Mode Example
1 set_context patterns -scan -design_id post_layout

2 set_tsdb_output_directory ../tsdb_outdirRun/adk.tcelllib
3 read_design processor_core -design_id post_layout -verbose
4 read_verilog ../../../library/memories/SYNC_1RW_8Kx16.v -interface_only
6 # Specify the current mode using a different name than what was used
7 # during scan insertion or pre-layout
8
9 set_current_mode edt_int_stuck_final -type internal
10

December 2017
11 # Use the -design_id and -mode from pre-layout to read in the TCD of that
12 # mode
13
14 add_core_instance -current_design -design_id gate -mode edt_int_stuck
16 add_fault -all
17 report_statistics -detail
18 create_patterns
20 # Store TCD, flat_model, fault list and patDB format files in the TSDB
21 # directory
22
24
25 # Write Verilog patterns for simulation
26 write_patterns patterns/processor_core_stuck_parallel.v -verilog -
parallel -replace -parameter_list {SIM_KEEP_PATH 1}
27 set_pattern_filtering -sample_per_type 2
28 write_patterns patterns/processor_core_stuck_serial.v -verilog -serial -
replace -parameter_list {SIM_KEEP_PATH 1}
29 # Optional Step - Can run in external mode and calculate the fault
30 # coverage of the core(both Internal and External) as described below.
31 # In order to understand the coverage of the faults testable by Internal
32 # mode it is necessary to eliminate the undetected faults that would
33 # otherwise be detected in External mode. This is done by merging the
34 # fault list from running the graybox in External mode with read_faults:
35
36 #read_faults -mode ext_multi_stuck -fault_type stuck -merge -verbose
37
38 # Final coverage of the core that includes both Internal and External
39 # modes
40 # report_statistics -detail
41 exit

December 2017
Running Multi-Load ATPG on Memories for Wrapped Cores with Built-In Self Repair
Running Multi-Load ATPG on Memories for

Wrapped Cores with Built-In Self Repair
If your design has wrapped cores that include repairable memories and you want to test the logic
around the memories at speed, then you use multi-load ATPG patterns.
Overview of Multi-Load ATPG on Memories for Wrapped Cores with Built-in Self Repair
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Performing Multi-Load ATPG Pattern Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Performing Multi-Load Top-Level ATPG Pattern Retargeting . . . . . . . . . . . . . . . . . . . 137
Overview of Multi-Load ATPG on Memories for

Wrapped Cores with Built-in Self Repair
When generating ATPG multi-load patterns for memories with Built-In Self Repair (BISR), the
memories inside the wrapped cores are tested first. If any memories need to be repaired due to
defects that are present inside the memory, then the BISR registers are programmed such that
the contents of these registers will vary based on the repair solution that is stored in the fuses at
the parent level.
To generate multi-load ATPG patterns, the BISR registers need to be excluded from
retargetable ATPG patterns that you created for the wrapped core. At the wrapped core level, a
test_setup_iCall will reset the BISR registers, resulting in all spare elements being unallocated
before ATPG is executed. Only the memory control ports and data ports participate in the
ATPG patterns; the memory repair ports are excluded. If memory defects are detected and
repaired via the BISR registers, the retargeted ATPG patterns will also pass.
Performing Multi-Load ATPG Pattern Generation

When you need to generate multi-load ATPG patterns when the memory is not bypassed but
used during ATPG there is no difference in the flow steps used for inserting DFT. You use this
procedure to bypass the memories.
The DFT insertion at the wrapped core level for memories with BISRs is similar to the two-pass
pre-scan DFT insertion process for wrapped cores with the primary difference being the ATPG
pattern generation. There are no changes to creating the graybox model, and running the
wrapped core in external mode for stuck and transition patterns by bypassing the memories.
There are no changes for running the wrapped core in internal mode for stuck and transition
patterns by bypassing the memories.
This discussion assumes that you are familiar with the two-pass pre-scan DFT insertion flow as
described in “RTL and Scan DFT Insertion Flow for Physical Blocks” on page 89, especially as
related to performing ATPG pattern generation. Figure 4-25 shows this flow.

December 2017
Figure 4-25. Two-Pass Insertion Flow for RTL, Wrapped Cores
Note that the init_bisr_chains iProc contains Tcl code you can use to initialize the BISR
registers at any level (core or chip-level) as follows:
• At the wrapped core level, the iProc performs an asynchronous clear of the BISR
registers.
• At the chip-level, the iProc will initiate a FuseBox controller power-up emulation.
The power-up emulation will clear the BISR registers if the fuse box has not been programmed,
or will initialize the BISR registers with the repair data if memory repair information was
programmed in the fuse box. See “Creating and Inserting the BISR Controller” in Tessent
MemoryBIST User's Manual.
Note
on page 136.
Prerequisites
• You have performed the “Two-Pass Insertion Flow for RTL, Wrapped Cores” on
page 89 up to the ATPG pattern generation step.
Procedure
1. Load the Tessent Cell Library for the memory. (See lines 1-9.)
2. Load the design. (See lines 11-13.)
3. Set the DFT Signal memory_bypass to 0, so memory is not bypassed. (See lines 24-26.)
4. Load the PDL for the Memory BISR chains, which has an iProc (init_bisr_chains) that is
called with set_test_setup_icall -non_retargetable. (See lines 28-35.)

December 2017
Note
Note that the init_bisr_chains iProc contains Tcl code you can use to initialize the
BISR registers at any level (core or chip-level) as follows: at the wrapped core level,
the iProc performs an asynchronous clear of the BISR registers; and at the chip-level,
the iProc will initiate a FuseBox controller power-up emulation.
5. Generate the multi-load ATPG patterns. (See lines 39-40.)

6. Write the design data and patterns to the TSDB. (See lines 42-44.)
7. Write out the Verilog test benches for simulation. (See lines 47-50.)
Results
At the wrapped core level, you inject a fault in the repairable memory, then run the multi-load
ATPG Pattern and it should fail. This check shows that if a repairable memory has defect and it
is not repaired then when you retarget the multi-load ATPG patterns from the top-level then it
will fail.
You must run the memoryBIST inside the wrapped core to determine if the memory is
repairable. If it is, then the repairable information from Built-In Redundancy Analysis (BIRA)
to BISR must be stored and the repair performed by storing the repairable contents using the
fusebox repair solution that you use at the top-level.
Examples
The following example for the repairable memory “MGC_SYNC_1RW_1024x8_C” generates
ATPG patterns that will be run by the memory.
Example 4-11. Multi-Load ATPG Pattern Generation for Memories with BISR
1 set_context patterns -scan

2
3 # Set the location of the TSDB. Default is the current working directory.
5
6 # Read Tessent Library
7 read_cell_library ../../../library/standard_cells/tessent/adk.tcelllib
8 # Read the Tessent Cell Library for the memory
9 read_cell_library ../../../library/memories/MGC_SYNC_1RW_1024x8_C.atpglib
10
11 # Read in the scan inserted netlist/design
12 read_design processor -design_id gate -verbose
13 set_current_design processor
14
15 # Specify the current mode using a different name than what was used
16 # with the add_scan_mode command
17 set_current_mode edt_int_multi_load_atpg -type internal
19
20 # Extract the scan chains using the internal mode specified during
21 # scan insertion with the add_scan_mode command
22 import_scan_mode int_mode -fast_capture_mode on

December 2017
Performing Multi-Load Top-Level ATPG Pattern Retargeting
23
24 # Memory is used during ATPG, by setting the DFTSignal memory_bypass
25 # to "0"
26 set_static_dft_signal_values memory_bypass_en 0
27
28 # Read in the PDL for the memory BISR
29 source \
30 ../tsdb_outdir/instruments/processor_rtl1_mbisr.instrument/\
31 processor_rtl1_tessent_mbisr.pdl
32
33 # Specify the iProc init_bisr_chains for the memory BISR as
34 # non_retargetable
35 set_test_setup_icall init_bisr_chains -non_retargetable
36
38 # Generate patterns
39 create_patterns
41
42 # Store TCD, flat_model, fault list and patDB format files in the TSDB
43 # directory
45
46 # Write test benches for Verilog simulation
47 write_patterns patterns/processor_multi_load_parallel.v \
48 -verilog -parallel -replace -parameter_list {SIM_KEEP_PATH 1}
49 write_patterns patterns/processor_multi_load_serial.v
50 -verilog -serial -replace -parameter_list {SIM_KEEP_PATH 1}
51 exit
At the wrapped core level, you inject a fault in the repairable memory, then run the multi-load
ATPG Pattern and it should fail. This check shows that if a repairable memory has defect and it
is not repaired then when you retarget the multi-load ATPG patterns from the top-level then it
will fail.
Performing Multi-Load Top-Level ATPG Pattern

Retargeting
When you have wrapped cores with repairable memories, then at the chip-top level you need to
insert a memory BISR controller. This can be done along with the TAP, boundary scan, and
MemoryBIST insertion if there are any memories present at the top-level.
This discussion assumes that you are familiar with the RTL and scan DFT fnsertion flow for the
top as described in “RTL and Scan DFT Insertion Flow for the Top Chip” on page 106,
especially as related to performing ATPG pattern retargeting. Figure 4-26 shows this flow.

December 2017
Figure 4-26. Two-Pass Insertion Flow for RTL, Top Level
For retargeting multi-load ATPG patterns where the memories are not bypassed from a lower
level wrapped core that has repairable memories, specify the correct retargeting mode signal.
Subsequently, use the add_core_instances command to load the specific core with the correct
ATPG mode that you want to retarget.
Finally, you need to source the PDL of the BISR chain with the iProc init_bisr_chains. This
PDL was created when the BISR controller RTL was generated at the chip-level. The iProc
detects the presence of the fuse box controller and initiates a PowerUpEmulation. When the
iProc is called and no fuse box controller is found, the iProc performs an asynchronous clear of
the BISR chains using the primary inputs (bisr_reset port).
Note
on page 139.
Prerequisites
• You have performed the “RTL and Scan DFT Insertion Flow for the Top Chip” on
page 106 up to the ATPG retargeting step.
Procedure
1. Set the context to pattern retargeting. (See lines 1-2.)
2. Specify the TSDB directory and open the TSDB. (See lines 4-8.)
3. Read the Tessent Cell Library. (See lines 10-11.)
4. Load the Verilog design. (See lines 13-15.)

December 2017
5. Set the retargeting from the lower-level patterns. (See lines 20-24.)
6. Read the PDL of the memoryBISR chains that has the iProc “init_bisr_chains”. This
PDL is different than the one created at the wrapped core level. (See lines 30-34.)
7. Change mode to analysis. (See line 36.)
Examples
The following example retargets the ATPG pattern from the lower level to the chip-level.
Example 4-12. ATPG Pattern Retargeting for Memories with BISR
1 # Set the context to retarget ATPG Patterns from lower level child cores
2 set_context pattern -scan_retargeting
3
4 # Point to the TSDB directory
6
7 # Open all the TSDB of the child cores
8 open_tsdb ../../wrapped_cores/processor/tsdb_outdir
9
10 # Read the tessent cell library
11 read_cell_library ../../library/standard_cells/tessent/adk.tcelllib
12
13 # Read the verilog
14 read_design chip_top -design_id gate
15 read_design processor -design_id gate -view graybox -verbose
16
17 set_current_design chip_top
18
19
20 # Retarget Transition patterns from processor
21 set_current_mode retarget1_processor_multi_load
22 set_static_dft_signal_values retargeting1_mode 1
23 add_core_instances -instances {processor_inst1 processor_inst2} \
24 -core processor -mode edt_int_multi_load_atpg
25
26 report_core_descriptions
27 import_clocks -verbose
28 report_clocks
29
30 # Read the PDL of the MBISR chains that has the iProc "init_bisr_chains"
31 # that needs to be called before running the ATPG pattern.
32 source ../tsdb_outdir/instruments/chip_top_rtl1_mbisr.instrument/\
33 chip_top_rtl1_tessent_mbisr.pdl
34 set_test_setup_icall init_bisr_chains -front
35
37 report_clocks
38
39 # write the TCD file for chip-level in the TSDB outdir
41 # Read the patterns to be retargeted
42 read_patterns -module processor -fault_type transition
43 set_external_capture_options -pll_cycles 5 [lindex [get_timeplate_list] 0]
44

December 2017
45
46 # Write Verilog patterns for simulation
47 write_patterns patterns/processor_edt_multi_load_retargeted.v -verilog \
48 -parallel -replace -begin 0 -end 7 -scan -parameter_list {SIM_KEEP_PATH 1}
49 write_patterns patterns/processor_edt_multi_load_retargeted_serial.v \
50 -verilog -serial -replace -Begin 0 -End 2 \
51 -parameter_list {SIM_KEEP_PATH 1}
52 exit

December 2017
Chapter 5
TSDB Data Flow for the Tessent Shell Flow
The Tessent Shell Database (TSDB) is a repository for all the files and directories that Tessent
Shell generates. The TSDB enhances flow automation by acting as the central location where
Tessent can access the data it requires for the current task, whether that task be reading in a
design, performing DRC, inserting logic test hardware, or performing ATPG pattern generation.
The TSDB structure aids data management between steps in a process even if you are not
performing these steps within the Tessent Shell platform. If the steps are performed within
Tessent Shell, then specifying the correct design ID automatically ensures that Tessent uses the
correct file inputs for the current task.
Refer to “Tessent Shell Database (TSDB)” in the Tessent Shell Reference Manual for details
about the TSDB directory structure and contents.
This chapter builds on the material discussed in the sections “Tessent Shell Flow for Flat
Designs” and “Tessent Shell Flow for Hierarchical Designs” regarding the RTL and scan DFT
insertion flow. During the RTL and scan DFT insertion process, Tessent Shell generates many
output files and directories that it accesses later in the flow as data inputs. This chapter
illustrates the data flow through each step of the RTL and scan DFT insertion flow.
Core-Level or Flat TSDB Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Top-Level TSDB Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Core-Level or Flat TSDB Data Flow

The core-level TSDB data flow applies to wrapped cores in a hierarchical DFT insertion flow.
In the bottom-up insertion process, you process the wrapped cores before the top-level chip.
Refer to “Tessent Shell Flow for Hierarchical Designs” for details.
With the addition of boundary scan in the first DFT insertion pass and the exclusion of graybox
modeling, this data flow also applies to flat and DFT-inserted designs unless the core includes
embedded pad IO macros that need boundary scan to be inserted as well. Refer to “Tessent
Shell Flow for Flat Designs” for details.

December 2017
Table 5-1. Core-Level TSDB Data Flow Inputs and Outputs

Task Input Output
DFT Insertion: • RTL netlist • Modified RTL + new RTL
First Pass • Libraries • ICL for IJTAG network
• Required DFT signals • TCD: clocks, DFT signals
Design ID for
output: rtl1 • MemoryBIST requirements • ICL for Memory + PDL
• For flat: boundary scan • For flat: boundary scan also
requirements also
DFT Insertion: • rtl1 design data • Modified RTL + new RTL
Second Pass • Libraries • ICL for IJTAG network
Design ID for
output: rtl2 • EDT and OCC requirements • ICL for OCC and EDT + PDL
Synthesis • Output from • Synthesized gate-level netlist

write_design_import_script
Third-party tool command (use rtl2 design data)
Scan Chain • Synthesized gate-level netlist • Scan-stitched gate-level netlist
Insertion • Scan modes • ICL, PDL
• TCD, ICL, PDL from rtl2 • TCD with scan modes
Design ID for
output: gate • Graybox model (not flat)
ATPG Pattern • gate scan-inserted design data • Flat model

Generation • ATPG run name • Fault list
• Scan mode • Patterns database
• TCD
During the first DFT insertion pass, provide the required files for your DFT implementation at
this stage. This can include the RTL netlist, libraries for MemoryBIST insertion and boundary
scan, and gate-level cells that require a Tessent cell library.
Tessent Shell generates the dft_inserted_designs, instruments, and patterns directories within
the TSDB you specified. By default, Tessent Shell generates the TSDB in the current working
directory if you do not specify a location. For details about these directories and the TSDB, refer
to “Tessent Shell Database (TSDB)” in the Tessent Shell Reference Manual.
Tessent modifies the RTL netlist for the design into which the first-pass instrument hardware
needs to be inserted. This hardware may include a MemoryBIST controller, BAP interface, and
IJTAG network. In the flat DFT implementation, it may also include boundary scan and a TAP
controller. Tessent Shell generates new RTL for the newly inserted DFT instruments.
In addition, Tessent Shell produces the TCD, ICL, and PDL for the design and the inserted
instruments. As shown in Figure 5-1, the design-level files and modified RTL are stored within

December 2017
the dft_inserted_designs subdirectory for this insertion pass (design ID “rtl1”). However, the
new RTL, TCD, ICL and PDL files for each inserted instrument are stored in subdirectories
within the instruments directory.
The patterns directory stores the patterns associated with the rtl1 design ID in an associated
subdirectory.
Tip
To facilitate data management, save each design (whether flat, core, sub-block, or chip) in
its own TSDB. This is the recommended practice when using Tessent Shell for DFT
insertion.
Figure 5-1. TSDB Data Flow, Core Level, First Insertion Pass
Figure 5-2 shows the data flow for the second DFT insertion pass. Tessent uses the design data
that was saved as rtl1 in the first pass as input for the second pass.
The relevant design RTL, TCD, ICL and PDL files from the first DFT insertion pass are
automatically read in when you specify the read_design command as described in “Load the
Design.” You only need to supply a library, if required, and any DFT input requirement for the
DFT instruments you are inserting during this pass.
The hardware you insert in this pass, such as EDT and OCC, is stored in the instruments
directory. Separate directories are created for each type of hardware inserted in each insertion
pass.
subdirectory.

December 2017
Figure 5-2. TSDB Data Flow, Core Level, Second Insertion Pass
Figure 5-3 shows the data flow for scan chain insertion. After synthesis, which you perform
using a third-party tool, you have a synthesized gate-level netlist. This netlist is the input for
scan chain insertion along with the design-level TCD, ICL, and PDL from the rtl2 design
generated during the second DFT insertion pass.
For wrapped cores, Tessent performs wrapper analysis along with scan chain insertion, whereas
for flat designs, Tessent performs scan chain replacement and stitching. For information about
using Tessent Scan for scan insertion, refer to “Internal Scan and Test Circuitry Insertion” in the
Scan insertion does not insert instruments, so the instruments and patterns directories are not
utilized in this step.

December 2017
Figure 5-3. TSDB Data Flow, Core Level, Scan Insertion
Figure 5-4 shows that the input to ATPG is the scan-inserted netlist and all the supporting files
such as TCD, ICL and PDL files that were stored in the TSDB during the scan insertion pass
(design_id “gate”). Tessent creates the logic_test_cores directory, which stores the output
pattern data for each ATPG run, which can include runs for various test types and associated
fault models as described in “Fault Modeling Overview” in the Tessent Scan and ATPG User’s
Manual.
Before generating patterns for wrapped cores, Tessent creates a graybox model of the core. This
model is stored using the same design ID as the one created during scan insertion (design ID
“gate”), so that at the top-level you can either use the full design view or graybox view of the
wrapped core. Refer to “Perform ATPG Pattern Generation” for more information.
Figure 5-4. TSDB Data Flow, Core Level, Pattern Generation

December 2017
Top-Level TSDB Data Flow

The top-level TSDB data flow discussion applies to the hierarchical RTL and scan DFT
insertion flow.
In the hierarchical DFT insertion flow, insert boundary scan—and MemoryBIST, if present—at
the top level of a chip during the first DFT insertion pass.
At the chip level, Tessent uses as inputs the core-level design data that was stored in the core-
level TSDBs for purposes of ATPG pattern retargeting. Refer to “RTL and Scan DFT Insertion
Flow for the Top Chip” for details.
Table 5-2. Top-Level TSDB Data Flow Inputs and Outputs
Task Input Output
DFT Insertion: • RTL netlist • Modified RTL + new RTL
First Pass • Libraries • ICL for IJTAG network
Design ID for
output: rtl1 • Boundary scan requirements • ICL for boundary scan + PDL
• TSDBs, lower core design data
DFT Insertion: • rtl1 design data • Modified RTL + new RTL
Second Pass • Libraries • ICL for IJTAG network
Design ID for
output: rtl2 • EDT and OCC requirements • ICL for OCC and EDT + PDL
Synthesis • Output from • Synthesized gate-level netlist

write_design_import_script
Third-party tool command (use rtl2 design data)
Scan Chain • Synthesized gate-level netlist • Scan-stitched gate-level netlist
Insertion • Scan modes • ICL, PDL
• TCD, ICL, PDL from rtl2 • TCD with scan modes
Design ID for
output: gate
ATPG Pattern • Gate scan-inserted design data • Flat model
• TCD
ATPG Pattern • Gate scan-inserted design data • Flat model
• Wrapped core ATPG pattern • TCD
data, retargeted

December 2017
Figure 5-5 shows the data flow for the first DFT insertion pass. Tessent modifies the RTL netlist
for the design and generates new RTL for the boundary scan and MemoryBIST (if inserted)
hardware. In addition, it produces the TCD, ICL, and PDL for the design and the inserted
instruments.
For integration at the top-level, Tessent uses as inputs the gate scan-inserted design data and
interface view from the wrapped cores. This is done by opening the core TSDB directories and
using the read_design command to read in the graybox model and TCD, ICL and PDL files.
subdirectory.
Tip
To facilitate data management, save each design (whether flat, core, sub-block, or chip) in
its own TSDB. This is the recommended practice when using Tessent Shell for DFT
insertion. The following discussion assumes that you have one TSDB per design.
Figure 5-5. TSDB Data Flow, Top Level, First Insertion Pass
Figure 5-6 shows the data flow for the second DFT insertion pass. In addition to the other input
requirements that you provide as shown in Table 5-2, Tessent uses the design data that was

December 2017
saved as rtl1 in the first pass, the gate scan-inserted design data, and graybox models from the
wrapped cores.
Tessent saves the output design data for the EDT and OCC hardware in their applicable
instruments subdirectories. The design-level TCD, ICL, PDL and modified RTL that includes
the EDT, OCC, and IJTAG network is placed in the dft_inserted_designs subdirectory for this
insertion pass (rtl2).
subdirectory.
Figure 5-6. TSDB Data Flow, Top Level, Second Insertion Pass
Figure 5-7 shows the data flow for scan chain insertion. Scan insertion does not insert
instruments, so the instruments and patterns directories are not utilized in this step.

December 2017
Figure 5-7. TSDB Data Flow, Top Level, Scan Insertion
Figure 5-8 shows that output from ATPG pattern generation gets stored in the logic_test_cores
directory. As inputs, Tessent uses the scan-inserted design data for the chip and for the cores.

December 2017
Figure 5-8. TSDB Data Flow, Top Level, ATPG Pattern Generation
As the final step for the top level in a hierarchical design, perform ATPG pattern retargeting of
the core ATPG patterns as shown in “ATPG Pattern Generation Example.” Figure 5-9 shows
that you read in the ATPG patterns from the logic_test_cores directory from each of the core
TSDB directories in addition to the scan-inserted design data for the chip and for the cores.

December 2017
Figure 5-9. TSDB Data Flow, Top Level, ATPG Pattern Generation with Pattern
Retargeting

December 2017

December 2017
Chapter 6
Tessent Examples and Solutions
This chapter contains Tessent solutions for specific DFT scenarios and problems. This includes
applications and flows that solve common, difficult issues encountered in DFT.
The solutions are organized in the following sections:
How to Handle Clocks Sourced by Embedded PLLs During Logic Test . . . . . . . . . . . . 153
How to Design Capture Windows for Hybrid TK/LBIST . . . . . . . . . . . . . . . . . . . . . . . . 159
How to Use Boundary Scan in a Wrapped Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
TAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Stand-alone TAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Compliance Enable TAP with IJTAG Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Daisychained TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Slave TAP Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Connecting to a Third-Party TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
How to Set Up Third-Party Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
How to Set Up Support for Third-Party OCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
How to Configure Files for Third-Party OCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Test Logic Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Pattern Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
How to Handle Clocks Sourced by Embedded

PLLs During Logic Test
Clocks sourced by an embedded PLL have local OCCs that are reused when testing parent
physical regions. The flow is different when the parent physical regions are themselves wrapped
cores.
Problem
For embedded PLLs, such as the one shown inside “corec” in Figure 6-1, the OCC inserted on
the VCO output of the PLL is used during the internal logic test modes of the core. It is also
reused during the internal test modes of its parent physical regions.

December 2017
How to Handle Clocks Sourced by Embedded PLLs During Logic Test
When the PLL is inside a wrapped core that is itself the child of another wrapped core, you must
take special steps to ensure that the OCC is still controllable by the scan chains when running
logic test modes of the top level.
Solution
Wrapped Core Only Used in the Top Level
If the PLL is embedded inside a wrapped core that is only used inside the top level physical
region, then you do not need to take any special steps. The standard flow handles this scenario
automatically, as described in “Tessent Shell Flow for Hierarchical Designs” on page 84.
Wrapped Cores Used Inside Other Wrapped Cores

You must use the following procedure when the wrapped core in which the embedded PLL is
located has another wrapped core above it, as shown in Figure 6-1.
1. Add an extra DFT signal when you process the wrapped core that embeds the PLL in
“Second DFT Insertion Pass: Top-Level EDT and OCC” on page 112 (for example,
when processing “corec” in Figure 6-1) as follows:
add_dft_signal promoted_cells_mode
2. Create a new scan mode when you process the wrapped core that embeds the PLL in the
“Scan Chain Insertion” step (for example, when processing “corec” in Figure 6-1) as
follows:
set promoted_instances \
[get_attributed_objects \
-attribute_name wrapper_type_from_clock_source \
-object_type instance]
if {[sizeof_collection $promoted_instances] > 0} {
add_scan_mode promoted_cells_mode \
-include_elements [get_scan_elements \
-of_instances $promoted_instances]
}
The new scan mode contains the control flip-flops of the OCCs that need to be
accessible from the top-level.
3. Modify the definition of the external scan mode when you process the parent wrapped
core in the scan chain insertion step of the flow (for example, when processing “corea”
in Figure 6-1).
set_attribute_value corea_i1 -name active_child_scan_mode \
-value promoted_cells_mode
set ext_scan_elements [add_to_collection \

[get_scan_elements -class wrapper] \
[get_scan_elements -child_modes promoted_cells_mode ]]
add_scan_mode ext_mode -chain_length 32 \

-include_elements $ext_scan_elements

December 2017
Modifying the external scan mode definition allows you to include the promoted scan
chains from the child wrapped cores in the external chain of the current wrapped core.
This step ensures that the control flip-flops of the embedded OCCs are accessible by the
test modes of the top level.
4. Depending on the hierarchy of your design, do one of the following:
o If your design only uses the wrapped core at the top level of the chip (such as
“corea” in Figure 6-1), then no further modifications are required for the standard
flow.
o If your design embeds the wrapped core inside another wrapped core (for example,
there was a layer of wrapped core between “corea” and “top” in Figure 6-1), you
need to again create the promoted scan mode at the current level.
This step provides access to the OCC control bits in its external scan mode. The
method shown in step 3 would then apply again to that parent wrapped core as
follows:
set_attribute_value corea_i1 -name active_child_scan_mode \
-value promoted_cells_modeadd_scan_mode promoted_cells_mode \
-include_elements [get_scan_elements \
-child_modes promoted_cells_mode]
Discussion
The example chip shown in the following figure illustrates functional clocking when a PLL is
embedded inside a child physical region.
Figure 6-1. Example Chip with PLL Embedded Inside Lower Core

December 2017
Figure 6-2 shows the location of the OCCs inserted inside “corec” and “coreb”. The two OCCs
inside “corec” are active during its internal test modes in order to inject the shift clock during
the shift cycles and to chop the functional clocks during capture cycles. The two OCCs inside
coreb are also active during its internal test modes for the same reasons.
Figure 6-2. Active OCCs During Internal Test Modes of corec and coreb
If you want to run the internal test modes of “corec” in parallel with those in “coreb”, you need
to provide a clock bypass path as shown in Figure 6-2, such that the free running output of the
PLL can continue to source the red clock of “coreb” when the OCC inside “corec” is active.
The bypass clock path is not required. The tool issues an error if you try to re-target an internal
test mode of “coreb” in parallel with an internal test mode of “corec” or “corea” and the bypass
path is not present. The reason for this check is that the OCC at the input of the red domain of
“coreb” expects and requires a free running clock when active. The red clock output of “corea”
is not a free running clock when the red OCC inside “corec” is active. Instead, it is alternating
between the shift clock and bursts of at-speed clock pulses.
If you provide the bypass clock path, you reduce the overall chip test time as you can
concurrently test “corec” or “corea” with “coreb”. If you want to insert the clock bypass path
within the DFT insertion process, use a process_dft_specification.post_insertion callback to
create the ports and make the connections. Use the intercept_connection command to insert the
multiplexer inside “coreb”. The best option to control the select input of the multiplexer is to
register and add a new DFT signal. See the register_static_dft_signal_names command for more
information.
The get_dft_signal command in the process_dft_specification.post_insertion callback gets the

connection point for the added DFT signal. If the bypass path is manually added in the golden
RTL, leave the select input of the multiplexer tied low and connect it to the DFT signal during

December 2017
the DFT process with the add_dft_control_points command. See “Example 1” of the
register_static_dft_signal_names command description section for an example.
When you move up to “corea”, another OCC is inserted at the base of the blue clock domain to
be used during its internal logic test modes, as shown in Figure 6-3.
Figure 6-3. Active OCCs During Internal Test Modes of corea and coreb
The OCC on the blue domain inside “corec” is kept inactive, as it is during the functional mode,
such that the clocking of the entire blue clock domain is controlled by the OCC located inside of
“corea” at the base of the clock tree. The red OCC inside “corec” is active during the internal
test mode of “corea” in order to control the scannable flip-flops on the red domain inside
“corea”, as well as the wrapper flops on the red domain inside “corec”. Because the
“fast_clock” input of that red OCC is not sourced by an input of “corec”, its scan chain is
automatically promoted to its wrapper chains. This allows it to be under ATPG control when
running the internal test mode of “corea”.
If “corec” was not embedded within another wrapped core (such as “coreb” that is directly
instantiated in the top level), the handling is completely automated and no deviation from the
standard flow, described under “Tessent Shell Flow for Hierarchical Designs” on page 84, is
necessary. However, when the wrapped core containing the embedded PLL is inside another
wrapped core, you must follow the steps described under “Solution” on page 154 to enable the
embedded OCC inside “corec” to be under ATPG control at the top level.
Extra DFT Signals

Figure 6-4 shows the active OCCs when running the logic test mode of the top level. As in the
previous case, the red OCC inside “corec” is active. This requires that the scan segment that
contains the control flip-flops of the red OCC must be accessible by the scan chains of the top

December 2017
level. For that reason, step 1 of the solution above shows how to add a new DFT signal called
“promoted_scan_mode” to use as the enable for that scan chain configuration.
Figure 6-4. Active OCCs During Test Modes of Top Level
New Scan Mode

Step 2 shows how to create the scan mode that contains the control flip-flops of the promoted
OCCs. The OCC instances that have their “fast_clock” input controlled by an internal source
have an attribute named “wrapper_type_from_clock_source” set on them automatically. The
get_attributed_objects command is used to find them and make them part of the special scan
mode.
Promoted Scan Chains

When you get to the “corea” level, you need to promote the special scan chain on “corec” into
the wrapper chain of “corea”, such that the control flip-flops of the red OCC are under ATPG
control from the top level. This task is described in step 3.
Step 4 provides instructions for when “corea” is not directly instantiated into the top level, but
instead is embedded within another wrapper core. In that case, you again need a special scan
mode to collect the embedded OCC chains such that they can again be included in the wrapper
chains of the parent wrapped core. Additionally, you again follow step 3 on the parent wrapped
core to include the promoted scan mode of “corea” within its wrapper chain.
The purple line in Figure 6-4 represents the promoted scan chain that contains the control
flip-flops of the red OCC. This scan segment is inserted in the “ext_mode” of “corea” in step 3
such that the OCC is part of the scan chains of the top level.

December 2017
How to Design Capture Windows for Hybrid TK/LBIST
Related Topics
On-Chip Clock Controller Design Description [Tessent Scan and ATPG User's Manual]
occ [Tessent Shell Reference Manual]
How to Design Capture Windows for Hybrid

TK/LBIST
A capture window is a group of capture cycles defined by one or more clocks. Test logic can be
configured to run a selected number of patterns for each capture window. This approach gives
full control over the patterns to optimize test coverage and test power consumption.
Problem
The fundamental objectives for LBIST are increased test coverage, decreased test time, and
lower power consumption for the test run. In a typical flow, the full set of data needed to
perform optimal insertion to meet these objectives is not available until the gate-level netlist is
ready. In practice, test circuitry is closely integrated into the design and the design suffers when
test is treated as an ad-hoc component or inserted later in the gate-level netlist.
To address these issues and achieve desired test coverage and performance, the Hybrid TK/
LBIST flow enables you to insert DFT logic at the RTL level, before the gate-level netlist is
ready. Capture windows enable the flexibility to add test logic in the RTL and test accurately.
Solution
The solution is provided in two parts:
• How to design capture windows (which clocks and how many pulses from each clock).
• How many patterns to run per capture domain to achieve the targeted coverage.
Define Capture Windows
If the clocking structure is known and determined during the insertion of the IP, then defining
the capture windows is a straight-forward process. To define capture windows for this flow,
follow the examples under “NCP Index Decoder” in the Hybrid TK/LBIST Flow User's Manual.
If the clocking structure is not yet defined or finalized, use the following procedure:
1. Create a gate-level netlist using quick synthesis.

2. Run ATPG with the following constraints:
a. Use the same setup and constraints used for LBIST.

December 2017
How to Design Capture Windows for Hybrid TK/LBIST
b. Set the number of random patterns:

set_random_pattern integer
where the integer argument is the number of patterns that are planned for use in
LBIST.
c. Run pattern simulation:
simulate_patterns –source random –store all
d. Report the test coverage per clock domain:

report_statistics –clock all
e. Report the generated patterns:

report_patterns
f. Design your capture windows using information from the ATPG run and the
report_statistics command.
• The ATPG run helps you identify the test clock domains in the design.
• The report_statistics command helps you identify the number of clock pulses per
clock domain
g. Determine how many patterns to run for each capture domain to achieve the targeted
coverage.
In the following example, you can identify that the design has three clock domains, with
possible interaction between CLK2 and CLK3. The highest faults per domain is at CLK2 at
78%, followed by CLK3 at 43%.
---------------------------------------------------------------
Clock Domain Summary % faults Test Coverage
(total) (total relevant)
--------------------------------------------------------------
CLK3_OCC 43.07% 99.13%
CLK2_OCC 78.80% 99.08%
CLK1_OCC 22.98% 98.17%
---------------------------------------------------------------
Patterns to Run per Capture Domain

For stuck-at-fault, try to use as many clock domains in the capture window as possible. This
saves test time. Use the “Define Capture Windows” procedure above to select the number of
patterns per capture window.
In the following example, to achieve the best coverage with the lowest number of patterns, a
two cycle capture window should be used for 20% of the patterns and more than 80% of
patterns should be used by a single CLK2_OCC/CLK1_OCC clock pulse capture window

December 2017
How to Use Boundary Scan in a Wrapped Core
pre-filtering
patt. # pattern # type cycles loads capture_clock_sequence
------- ------------- ---------------- ------ ----- ------------------
0 0 basic 1 1 [CLK1_OCC,*]
1 1 basic 1 1 [CLK2_OCC,*]
… … …
1 400 basic 1 1 [CLK2_OCC,*]
2 401 clock_sequential 2 1 [CLK2_OCC,*] [CLK3_OCC,*]
Note: [*] = "SHIFT_CLOCK", which is a pulse-in-capture clock.

You must perform a specific procedure if a wrapped core has embedded pads that require
boundary scan. Care must be taken during the insertion of the boundary scan and during ATPG.
Problem
Pads embedded inside a wrapped core must be identified such that boundary scan cells can be
added. The resulting boundary scan cells must also be made visible to the tool in order for them
to be included in scan chains and to apply scan patterns.
Solution
The solutions are given for wrapped core and chip-level flows.

December 2017
Wrapped Core Flow

The following figure shows the standard command flow for creating a wrapped core that
includes embedded boundary scan:
Figure 6-5. Wrapped Core Boundary Scan Flow
If the core contains pads and boundary scan, you must include the following commands in the
wrapped core flow shown in Figure 6-5 on page 162:
• Insert memory BIST and embedded boundary scan using during the
insert_mbist_ebscan step as follows:
a. Specify DFT requirements to insert memory test and embedded boundary scan:
set_dft_specification_requirements -memory_test on \
-boundary_scan on

December 2017
b. Insert embedded boundary scan cells and identify the pads:

set_boundary_scan_port_options \
-pad_io_ports [list taclk ta_cci0a ta_cci0b ta_cci1a ta_cci1b
ta_cci2a ta_cci2b ta_out0 ta_out1 ta_out2]
Note
The order specified is the order in which the boundary scan cells are inserted.
• Specify not to add any dedicated wrapper cells on embedded pad IO during the
insert_scan step:
set_dedicated_wrapper_cell_options off \
-ports {ta_out0 ta_out1 ta_out2}
set_dedicated_wrapper_cell_options off \
-ports {ta_cci0a taclk ta_cci0b ta_cci1a ta_cci1b ta_cci2a
ta_cci2b}
• Preserve the boundary scan instances in the graybox during the ATPG_patterns
(graybox generation) step.
set preserve_bscan {}
set preserve_bscan \
[get_instances -hier*_tessent_bscan_logical_group_*]
Chip-Level Flow
For boundary scan at the chip-level, follow the standard chip-level flow by inserting boundary
scan as the first step in the flow. There are no specific additions for embedded boundary scan at
this phase of the flow. The boundary scan segments from the wrapped core are picked up
automatically during chip-level boundary scan insertion.

December 2017
TAP Configuration
TAP Configuration
Tessent Shell typically relies on an IEEE 1149.1-based Test Access Port (TAP) as the primary
access mechanism to the DFT it inserts. When boundary scan is implemented, the Tessent TAP
fully complies with IEEE 1149.1 standard requirements, however many other possible
configurations are possible.
This section provides a quick reference to the various TAP insertion styles that are supported,
how to specify them, and what to expect from such implementations.
Stand-alone TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Compliance Enable TAP with IJTAG Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Daisychained TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Slave TAP Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Connecting to a Third-Party TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Stand-alone TAP
Insert a simple stand-alone TAP in a design.
Solution
1. Set the design level to “chip”.
2. Use the following dofile example:
set DFT [create_dft_specification]
read_config_data -in $DFT -from_string {
IjtagNetwork {
HostScanInterface(ijtag) {
Interface {
tck : tck;
}
Tap(single) {
}
}
}
}
The generated TAP connects to the trst, tck, tms, tdi, and tdo pads that were present in the pre-
DFT design.

December 2017
Stand-alone TAP
Discussion
If the TAP pins in the current design do not use the default names (trst, tck, tms, tdi, or tdo),
then they can be mapped using one of the following:
• The DftSpecification::IjtagNetwork::HostScanInterface::Interface wrapper.

• The following dofile command:
set_attribute_value portname -name function \
-value [trst | tck | tms | tdi | tdo]
The tool issues errors if the TAP pads are not yet present in the current design. If the design is
only temporary, you can specify the “set_design_level sub_block” command instead. Note that
many TAP-specific DRCs are not run in such a case and other side effects may result. You
should read an updated design that includes TAP pads as soon as possible.
The TAP generated in this example can be further enhanced with additional IR opcodes, IJTAG
host scan interfaces, and decoded outputs to enable downstream logic, such as another TAP.
The following is a schematic representation of this example:
Related Topics
TAP with IJTAG Host Scan Interface
Compliance Enable TAP with IJTAG Interface
Daisychained TAP
Master TAP Insertion
Slave TAP Insertion
Connecting to a Third-Party TAP

December 2017

Insert a TAP equipped with an IJTAG host scan interface. An IJTAG network can then be
connected to the TAP in a subsequent test insertion phase.
Solution
IjtagNetwork {
HostScanInterface(ijtag) {
Interface {
tck : tck;
}
Tap(single) {
HostIjtag(1) {
}
}
}
}
}
Discussion
The host scan interface on the generated TAP can be used to control any type of
IJTAG-compliant network.
The host scan interface provides a test_logic_reset output to reset downstream logic; it asserts
the host_hostname_to_sel output to 1 when accessing the client IJTAG network.
The capture_dr_en, shift_dr_en and update_dr_en outputs are consumed by the client IJTAG
network or instruments after qualification with the above host_hostname_to_sel port.

December 2017
Related Topics
Stand-alone TAP

Insert a TAP in a design with compliance enable (CE) decoding logic. The CE decoding logic
ensures that the TAP can only be accessed if all of the specified values are present on the
primary inputs.
The same scheme is also used when the TAP pins are shared with functional pins. The CE pins
ensure that the TAP are only be activated during intended test modes and not accidentally, for
example, while the functional pins toggle during normal operation.
Solution
2. Ensure that at least one primary input pad is set to 0 or 1 to enable the TAP logic.
set DFT [ create_dft_specification \
-active_low_compliance_enables {tap_en0} \
-active_high_compliance_enables {tap_en1} ]
read_config_data -in $DFT/IjtagNetwork/HostScanInterface(tap) \
-from_string {
Tap(CE_decoded) {
HostIjtag(1) {
}
}
} process_dft_specification

December 2017
Discussion
Note how the CE pins are specified as options to the create_dft_specification command.
The CE decoding module relies on the CE pin values to select the active TDO and TDO_EN
signals and route both to the primary TDO output pad.
The same CE module also gates the TMS signal such that when the proper values are not
present, the TMS input on the TAP is kept to 0. This normally has the effect of “parking” the
TAP in one of the stable FSM states (refer to the IEEE 1149.1 FSM state diagram for details).
Do not mix-up the CE decoding module input port names with expected CE values! For
instance, in the above diagram the “ce0” input is actually sourced by the CE pin driven at 1; the
“ce1” input is connected to the CE pin driven at 0. Potentially very confusing – so be aware.
The general rule is that if n CE inputs are specified, the CE decoding logic will be created with
input ports ranging from ce<n-1> down to ce0.
If internal CE nodes have to be used (i.e. when the pre-DFT design already contains decoding
logic and hookup points to connect the new TAP to), declare those hierarchical nodes in a new
DftSpecification::IjtagNetwork::HostScanInterface::Interface wrapper. The Tap(<name>)
wrapper then has to be put within the very same interface wrapper
Related Topics
Stand-alone TAP

December 2017
Daisychained TAP
Daisychained TAP
This example inserts a second TAP in series with an existing one. The TRST, TCK, and TMS
signals are shared between both TAPs, which implies that the complete JTAG chain (for
example, top-level TDI to TDO) always shifts through both TAPs.
Solution
IjtagNetwork {
HostScanInterface(tap) {
Interface {
tck : tck;
daisy_chain_with_existing_client : on;
}
Tap(2) {
HostIjtag(2) {
}
}
}
}
}
Discussion
The first TAP in this example has a name that starts with “top_rtl_”, while the second TAP
begins with “top_rtl1_”. These names are used because this step is typically done as a
subsequent insertion pass, such that the current design already contains at least one valid TAP.

December 2017
Related Topics
Stand-alone TAP

Insert a TAP in a design that does not currently contain a TAP. The generated TAP is used as a
master TAP that contains output(s) to enable or disable slave TAP(s) that are inserted in
subsequent insertion passes.
Solution
1. Set the design level to “chip”
2. Create one or several DataOut ports on the master TAP, such that a slave TAP is enabled
when the corresponding DataOut port is asserted.
IjtagNetwork {
Interface {
tck : tck;
}
Tap(master) {
HostIjtag(1) {
}
DataOutPorts {
count : 1;
}
}
}
}
}
Discussion
Other than the new user_ir_bits[0] output port that was created using the DataOutPorts wrapper,
this TAP is functionally identical to the stand-alone TAP with a host scan interface.
Note that the added DataOutPort ports are considered as TAP IR bits. If you need to create these
bits as DR bits, insert a TDR on the existing host scan interface using the following command:
create_dft_specification –existing_ijtag_host_scan_in hierarchical_pin

December 2017
Slave TAP Insertion
Related Topics
Stand-alone TAP
Slave TAP Insertion
Slave TAP Insertion

Generate a master TAP, a 2-to1 scan mux, and a slave TAP. By default, the master TAP is
enabled.
Solution
1. Set the design level to “chip”

December 2017
Slave TAP Insertion

IjtagNetwork {
Interface {
tck : tck;
}
Tap(master) {
HostIjtag(0) {
}
DataOutPorts {
count : 1 ;
}
}
ScanMux(1) {
select : Tap(master)/DataOut(0) ;
Input(1) {
Tap(slave) {
HostIjtag(1) {
}
}
}
}
}
}
}
Discussion
To trace through TAP slave implementations, it is easier to start from the TDO output and
gradually trace back toward the primary TDI input.
The inserted ScanMux selects the TDI input by default and routes it to its own mux_out output.
The mux_select input comes from the master TAP’s user_ir_bits[0] output. When this output
transitions to 1, the slave TAP is muxed in, such that the complete JTAG scan path goes through
both TAPs.

December 2017
Related Topics
Stand-alone TAP

Connecting an IJTAG network or instruments to a third-party TAP requires reading the Verilog
module of that TAP along with its ICL before setting the current design in Tessent Shell.
Solution
When creating the DFT specification, specify the -existing_ijtag_host_scan_in port option and
point to the ScanInPort on the third-party TAP that receives the scanned-out data from the
inserted IJTAG network or instruments. The DFT specification is then created accordingly.
Related Topics
Stand-alone TAP
How to Set Up Third-Party Synthesis

You must synthesize DFT logic generated in the Tessent Shell flow in order to perform scan
insertion, test pattern generation, and other processes.
Problem
You must define constraints in synthesis tools to enable accurate gate level representations of
the RTL. These constraints are primarily made up of clock definitions and timing constraints.

December 2017
Solution
Use the following procedures to set up constraints for Synopsys and Cadence synthesis tools
within the Tessent Shell flow.
Synopsys
The following procedure provides a high-level overview of the synthesis flow for Synopsys. For
complete details, refer to “Example Design Compiler Synthesis Script” on page 409 for an
example.
1. Source the SDC file generated by the tool.

The generated SDC file is located in the TSDB of the current design under the design ID
to which the DFT was inserted and the ICL was extracted.
2. Set and redefine the Tessent Tcl Variables.
The SDC file includes variables that need to be set in order for the script to operate
correctly. For example, the period of the TCK clock needs to be set. Depending on your
DFT flow, you may need to define additional variables. The variables that you must set
are easily identified in the SDC script file.
3. Verify the declaration of the functional clocks.
You must define all functional clocks. The tool automatically generates clock
definitions based on the information from your DFT insertion script. You must review
these definitions for accuracy.
4. Redefine other Tessent Tcl variables.
You must review and customize any additional variables. For example, a variable must
be set that defines the input delay for the primary pins. This setting is based on the pre-
defined TCK period and a custom multiplier value. The following is an example:
set tessent_input_delay [expr 0.3 * $tessent_tck_period]
5. Load the design into your synthesis tool.

The Tessent Shell tool automatically creates a script to import your design. The tool then
sources the generated script elaborates the design.
6. Apply the SDC constraints.
At this stage of the flow, the SDC constraints for the DFT logic are applied by sourcing
the appropriate procedure. The procedures are described under the extract_sdc command
of the Tessent Shell Reference Manual.
7. Prepare the DFT logic for synthesis.
You must set up the DFT logic by configuring synthesis tool settings to ensure proper
synthesis. For example, some instances need to be preserved during synthesis to ensure

December 2017
that the gate-level analysis functions correctly. The following statements are examples
of configuration settings:
set_app_var
compile_enable_constant_propagation_with_no_boundary_opt false
set preserve_instances [tessent_get_preserve_instances icl_extract]
set_boundary_optimization $preserve_instances false
set_ungroup $preserve_instances false
set_app_var compile_seqmap_propagate_high_effort false
set_app_var compile_delete_unloaded_sequential_cells false
set_boundary_optimization [tessent_get_optimize_instances] true
set_size_only -all_instances [tessent_get_size_only_instances]
8. Synthesize your design.

The synthesis script compiles the design to create a gate level representation of the RTL.
9. Write out the SDC and the final gate-level netlist.
The final SDC is a combination of the functional and the DFT constraints.
Cadence
For synthesis with the Cadence Encounter tool, follow the procedure for the Synopsys tool as
documented above, but ensure that you adjust steps 3 through 6 to match the script shown in
“Example Encounter Synthesis Script” on page 411. These specific steps are different because
the tools use different commands to run synthesis. Otherwise, the flow and results are the same.

December 2017
How to Set Up Support for Third-Party OCCs
How to Set Up Support for Third-Party OCCs

Tessent tools provide automation that enables you to insert Tessent OCCs as well as define and
configure them for ATPG. If the design contains third-party OCCs, Tessent tools can set up and
operate the OCC throughout the flow by reading and processing files that describe the operation
of the OCC.
The following topics describe the process for defining and configuring third-party OCCs.
How to Configure Files for Third-Party OCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Test Logic Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Scan Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Pattern Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
How to Configure Files for Third-Party OCCs

In order to automate the flow as much as possible, the following files set up and control how the
tool interacts with the OCC.
Solution
You must place the ICL and PDL files in the same directory as the Verilog of the OCC using the
same file base name. For this example, the OCC Verilog module is in a file named
third_party_occ.v.
Moving the ICL and PDL files into the same directory as the Verilog enables the tool to
automatically load them and carry the information throughout the flow.
You must prepare the following files as described:
• ICL — Provide an ICL file based on the IEEE 1687 IJTAG standard to describe the
ports on the OCC that need to be controlled by IJTAG during test. Name the file
third_party_occ.icl and place it in the same directory as the Verilog file.
• PDL — Provide a PDL file based on the IEEE 1687 IJTAG standard to describe the
procedures that configure the third-party OCC. Name the file third_party_occ.pdl and
place it in the same directory as the Verilog file.
• TCD Scan — Provide a TCD Scan file based on the Tessent Core description language
to describe the OCC’s programming shift register (chain segment) that needs to be
connected to the design’s scan chains during scan insertion.

December 2017
Test Logic Insertion
The following is an example TCD Scan file for a third-party OCC. The sub-chain port
information must be included in the ScanChain wrapper and the Clock and ScanEn
wrappers in order to define the polarity of each port.
Core(third_party_occ) {
Scan {
module_type : occ;
allow_scan_out_retiming : 0;
is_hard_module : 1;
traceable : 0;
pre_scan_drc_on_boundary_only : 1;
Clock(slow_clock) {
off_state : 1'b0;
}
ClockOut(clock_out_mux/y) {
slow_clock_input : slow_clock;
fast_clock_input : fast_clock;
}
ScanEn(scan_en) {
active_polarity : 1'b1;
}
ScanChain {
length : 4;
scan_in_port : scan_in;
scan_out_port : scan_out;
scan_in_clock : slow_clock;
scan_out_clock : ~slow_clock;
}
}
}
• Clock Control Definitions — Provide a test procedure file that contains Clock Control
Definitions (CCDs) for the OCC instances in the design. For details on the format of
CCDs, refer to “Clock Control Definition” on page 321.

During test logic insertion (for example, EDT), the tool reads and processes the ICL and PDL
files and includes this information in design files stored in the TSDB. Additionally, any OCC
ports described in the ICL file that need to be controlled by IJTAG are connected to the
generated IJTAG network such that the OCCs can be easily configured in subsequent steps.
See “How to Configure Files for Third-Party OCCs” on page 176 for instructions on setting up
the ICL and PDL files.
Solution
The following EDT example uses a post-insertion procedure to connect the slow_clock port of
the OCC to the newly-generated shift_capture_clock DFT signal. This enables the same clock
source to be used for the OCC and EDT logic. The post-insertion script is executed after the
process_dft_specification command creates all other logic defined in the DFT Specification.

December 2017
For detailed information on how to create and use a post-insertion procedure, refer to
“process_dft_specification.post_insertion” in the Tessent Shell Reference Manual.
set_context dft -rtl

# Read the design and OCC module. The ICL and PDL files with the
# same base name will be automatically read from the same directory
read_verilog ../rtl/RDS_process_with_occ.v
read_verilog ../rtl/third_party_occ.v
set_current_design RDS_process
set_design_level physical_block
# Define DFT Signals for EDT and scan test.

{scan_en_r edt_update test_clock_r}
add_dft_signals edt_clock shift_capture_clock -create_from_other_signals
add_clocks clock1 -period 3ns
add_clocks clock2 -period 4ns
check_design_rules
# Create the DFT Spec for adding EDT

set spec [create_dft_specification -sri_sib_list {edt} ]
EDT {
Controller (c1) {
}
}
}

December 2017
Scan Insertion
# Post-insertion procedure to change the existing connection to

# third-party OCC's slow_clock port and connect to the shift_capture_clock
# DFT Signal
proc process_dft_specification.post_insertion {RDS_process args} {
set occ_insts [get_instances -of_module third_party_occ -silent]
if {[sizeof_collection $occ_insts] > 0} {
set slow_clock_pins [get_pins slow_clock -of_instances $occ_insts]
foreach_in_collection occ_pin $slow_clock_pins {
delete_connection $occ_pin
create_connection [get_dft_signal shift_capture_clock] $occ_pin
}
}
}
extract_icl
# Create a synthesis script of all RTL (original and newly created)

write_design_import_script use_in_synthesis.tcl -use_relative_path_to . \
-replace
exit
Scan Insertion
You must configure the tool to read the OCC files before running scan insertion.
the OCC files.
Solution
When inserting scan into the post-synthesis netlist, specify the location of the TCD Scan file
using the set_design_sources command. The tool uses the description of the OCCs’ scan
segment to stitch them into the design’s scan chains.

December 2017
Pattern Generation
The following is an example:
set_context dft –scan

# Specify the location of the TCD Scan file that describes the OCC's scan
# segment
set_design_sources -format tcd_scan -Y ../rtl -extension tcd_scan
# Read the cell library and synthesized netlist from DC Shell

read_verilog ../2.synthesis/RDS_process_synthesized.vg
# Use read_design to read in information (DFT signals, etc.) performed in

# previous pass
read_design RDS_process -design_identifier rtl -no_hdl
# Add a scan mode and specify EDT instances to which scan chains should be
# connected
set edt_instance [get_instances -of_icl_instances [get_icl_instances \
-filter tessent_instrument_type==mentor::edt]]
add_scan_mode edt -edt_instance $edt_instance
analyze_scan_chains
insert_test_logic
exit
Pattern Generation
You must configure the tool to read the OCC files before generating patterns.
the OCC files.
Solution
For stuck-at ATPG, much of the setup is automatically imported using the import_scan_mode
command. Additional clock definitions and settings for the OCC should be provided for the
OCC’s asynchronous source clocks as well as the clocks on the output of the OCC instances.

# Read the cell library and design

read_design RDS_process -design_id gate
# Specify a test mode for stuck-at ATPG

set_current_mode edt_stuck
# Import scan, EDT, and clock configuration for ATPG

import_scan_mode edt

December 2017
Pattern Generation
# Define external and OCC clocks

set_clock_options test_clock_r -pulse_in_capture on
set occ_insts [get_instances -of_module third_party_occ* -silent]
foreach_in_collection occ_inst $occ_insts {
set inst_name [get_single_name $occ_inst]
add_clocks [get_pins ${inst_name}/clock_out_mux/y] -capture_only
# Execute iProc for third_party OCC to set default values (test_mode = 1)
set_test_setup_icall "${inst_name}.setup" -append
}
}
# Specify a procedure file containing clock control definition for the OCC
# instances
read_procfile third_party_occ_clock_controls.proc
create_patterns
write_patterns patterns/RDS_process_stuck_parallel.v -verilog -parallel \
-replace -parameter_list {SIM_KEEP_PATH 1}
write_patterns patterns/RDS_process_stuck_serial.v -verilog -serial \
–replace -parameter_list {SIM_KEEP_PATH 1}
In the ANALYSIS mode, specify a procedure file that contains the clock control definitions for
the OCC instances.
For transition fault ATPG, a number of changes to the dofile are highlighted in the following
example. Define any additional internal clocks that are needed for the third-party OCC, similar
to those defined in the example (for example, if the OCC internally gates the fast clock during
transition test).
Additionally, specify any parameters to the OCC’s iCalls that must be set to configure the OCC
for transition/fast-capture test.
Finally, you must constrain the design’s I/O which are not used for transition test.

# Read the cell library and design

read_design RDS_process -design_id gate
# Specify a test mode for transition ATPG

set_current_mode edt_transition
# Import scan, EDT, and clock configuration for ATPG

import_scan_mode edt
import_clocks

December 2017
Pattern Simulation
# Define external and OCC clocks

set_clock_options test_clock_r -pulse_in_capture on
set occ_insts [get_instances -of_module third_party_occ* -silent]
foreach_in_collection occ_inst $occ_insts {
set inst_name [get_single_name $occ_inst]
add_clocks [get_pins ${inst_name}/clock_out_mux/y] -capture_only
add_clocks \
[get_pins ${inst_name}/occ_control/cgc_SHIFT_REG_CLK/clkg] \
-pulse_in_capture
# Execute iProc for third_party OCC and enable fast capture mode for OCCs
set_test_setup_icall "${inst_name}.setup fast_capture_mode 1" \
-append
}
}
add_input_constraints -hold
add_output_masks -all
# Specify a procedure file containing clock control definition for the OCC
# instances
read_procfile third_party_occ_clock_controls.proc
create_patterns
write_patterns patterns/RDS_process_transition_parallel.v -verilog \
write_patterns patterns/RDS_process_transition_serial.v -verilog \
-serial –replace -parameter_list {SIM_KEEP_PATH 1}
Pattern Simulation
You must run a Verilog simulation of the generated patterns to ensure no mismatches are
reported and that the patterns function as expected during the tester application.
Solution
For parallel load patterns specified by the “write_patterns -parallel” command, simulate all the
patterns.
For serial load patterns, a handful of patterns are sufficient since the run time for simulating
serial load patterns can be significant.

December 2017
Chapter 7
DFTVisualizer
DFTVisualizer is the tool you use for viewing and debugging design and simulation data in
Tessent Shell.
DFTVisualizer Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
DFTVisualizer Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
DFTVisualizer Window Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
DFTVisualizer Quality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Performing Basic Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Searching for an Instance, Net, or Pin in the Active Window . . . . . . . . . . . . . . . . . . . . . . 190
Searching for an Instance, Net, or Pin in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Interruption of Operations from DFTVisualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Undocking and Docking Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Resizing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Repositioning Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Object Name Copied from a Popup Menu to the System Clipboard . . . . . . . . . . . . . . . . . 194
Adding Instances to the Current Display Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Cross-Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Selecting Multiple Objects in the Flat and Hierarchical Schematic Windows. . . . . . . . . . 196
Unselecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Customizing Marking Colors in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . . . 197
Marking and Unmarking Objects in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . 197
Copying and Pasting Object Names in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Compaction of Buffers and Inverters in Traced Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . 202
Tracing a Specific Signal Value to the Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Signal Path Tracing in the Hierarchical Schematic Window . . . . . . . . . . . . . . . . . . . . . . . 206
Tracing Up and Down the Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Annotation of Schematic Data in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . . 212
Adding User-Defined Annotations to Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Viewing K19 and K22 Simulation Data in the Schematic Windows . . . . . . . . . . . . . . . . . 215
Reporting Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Expansion of Library Instances in the Flat Schematic Window. . . . . . . . . . . . . . . . . . . . . 217
Display of Multiple Data Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

December 2017
DFTVisualizer
DFTVisualizer Overview
Working with Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Attributes in the Hierarchical and Flat Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . 219
Setting Global Attribute Display Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Setting Attribute Background Display Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Controlling the Display of Callouts in the Flat and Hierarchical Schematic Windows . . . 222
Working With Specifications in the Configuration Data Window . . . . . . . . . . . . . . . . . 225
Modifying the Contents of the Configuration Data Window . . . . . . . . . . . . . . . . . . . . . . . 225
Adding a Test Data Register to a SIB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Customizing the DFT Specification for EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
DFTVisualizer Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
DFTVisualizer Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Objects Added to DFTVisualizer Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Design Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Flat Schematic Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Console Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
DFTVisualizer Command Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
DFTVisualizer Overview
DFTVisualizer provides a visual means of browsing and troubleshooting designs in several
Tessent Shell contexts and subcontexts.
• dft -scan (Tessent Scan)
• dft -edt (Tessent TestKompress IP Creation)
• patterns -scan (Tessent FastScan, TestKompress Test Pattern Generation)
• patterns -scan_diagnosis (Tessent Diagnosis™®)
• patterns -scan_retargeting
• patterns -failure_mapping

December 2017
DFTVisualizer
DFTVisualizer Invocation
For more information on Tessent Shell contexts and subcontexts, see Contexts and System
Modes in the Tessent Shell User’s Manual.
DFTVisualizer Invocation
There are several ways to invoke DFTVisualizer, depending on the task you want to perform.
Procedure
1. Set a context using the set_context command.
2. Load a design using the read_verilog command.
3. Read a library using the read_cell_library command.
4. Set the current design using the set_current_design command.
Note
You can invoke DFTVisualizer without issuing these commands, but most of the
user interface will be disabled until you load a design, any required libraries and
specify the top level. You can also issue these commands from the DFT Visualizer
Console window after you have invoked the tool.
5. You can invoke DFTVisualizer using one of the following methods depending on the
task you want to perform.
• Invoke DFTVisualizer explicitly by issuing any command that provides a -Display
argument. For example:
open_visualizer -display flat_schematic hierarchical_schematic data
Note
DFT Visualizer will open the Design Browser and Console windows by default
if the -Display argument is not specified.
• Issue a command that requests information from the tool. In this case, the tool
invokes DFTVisualizer to analyze and then display the requested data. For example:
analyze_drc_violation c3-3
The analyze_drc_violation command opens DFTVisualizer with the appropriate

windows displaying a schematic of the parts of the design associated with the
specified DRC violation.
• Issue a command that opens the DFTVisualizer and displays DftSpecification
configuration data. For example, if you have already read a specification into
memory, issuing this command opens DFTVisualizer with the configuration data
loaded:
display_specification

December 2017
DFTVisualizer
DFTVisualizer Window Overview
DFTVisualizer Window Overview

DFTVisualizer contains windows for viewing and debugging design and simulation data. The
Design Browser and Console windows are opened by default. You can access all other windows
from the Windows pulldown menu.
• Design Browser Window — Displays tabs for accessing multiple windows:
o Instance tab — Displays the Instance Browser that Navigates the design hierarchy
and displays module names and child instances for hierarchical blocks.
o Library tab — Displays the Library Browser that provides statistics on the ATPG
library models used in a design. By default, consolidated data for each ATPG library
model displays. Each library model can be expanded to display statistics for the
individual instances of the model.
o Clock tab — Displays the Clock Browser that provides all of the clocks in the design
and their attributes. The Clock Browser allows you to navigate through the design
hierarchy and view the faults for each individual clock and analyze the distribution
of faults between clock domains.
o DRC Violations tab — Displays the DRC Violations Browser that provides DRC
and pattern data for specific instances and signals.
o Signals pane — A collapsible pane that displays ports and signals for instances
selected in the Instance, Library or Clock Browsers.
Note
Currently, the Clock Browser does not support the UDFM fault type.
• Data Window — Displays pins and signals for the instance selected in any tab of the
Design Browser window.
• Flat Schematic Window — Displays a flattened schematic representation of the design
as described in the input netlist. The schematic can be at the design or primitive level.
• Hierarchical Schematic Window — Displays a hierarchical schematic of the design as
described in the input netlist. Includes net names and hierarchical ports down to library-
level instances.
• Configuration Data Window — Provides you with a graphical interface to view
specifications and to modify the configuration tree elements and their options.
• Global Search Window — Allows you to search for any instance, net, or pin in the
active design.
• Test Structures Window — Displays graphical representation of the EDT logic inserted
by Tessent TestKompress.

December 2017
DFTVisualizer
DFTVisualizer Quality Agent
• Text Editor Window — Displays text files within DFTVisualizer and provides standard
text editor functions for viewing and editing them. You can create new test procedure
files and dofiles, or modify existing netlists, test procedure files, dofiles, and current
design files.
• Console Window — Displays notes, warnings, and errors applicable to the session.
• Wave Window — Provides a waveform representation of test_setup data and named
capture procedures (related to Data window).

When internal errors occur, it can be difficult for you to recall previous steps and recreate the
problem. To assist in these cases, DFTVisualizer produces an error transcript that usually
provides enough information to enable our Customer Support team to identify the problem.
The Quality Agent, shown in Figure 7-1, enables you to do the following:
• Automatically send transcripted error information to Mentor Graphics by clicking the

Send Report button.
You must enter information into the Steps field before you can successfully send the
report to Mentor Graphics. Providing this feedback ensures that the problem you
experienced is addressed as quickly as possible. This enables Mentor Graphics to
provide the highest product quality.
Note
Please be aware that when you send feedback, absolutely NO DESIGN DATA is
communicated to Mentor Graphics. To ensure your privacy, the transcripted error
information is sent as an email in a text format; it is also sent to any email address you
specify.
• Choose whether to be notified when the problem has been addressed.

December 2017
DFTVisualizer
Figure 7-1. DFTVisualizer Quality Agent

December 2017
DFTVisualizer
Performing Basic Tasks
Performing Basic Tasks

Typically, you open a number of windows as you explore the tool’s database, so developing
good window management and navigation technique is helpful.
Searching for an Instance, Net, or Pin in the Active Window . . . . . . . . . . . . . . . . . . . . . 190
Searching for an Instance, Net, or Pin in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Interruption of Operations from DFTVisualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Undocking and Docking Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Resizing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Repositioning Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Object Name Copied from a Popup Menu to the System Clipboard . . . . . . . . . . . . . . . 194
Adding Instances to the Current Display Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Cross-Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Selecting Multiple Objects in the Flat and Hierarchical Schematic Windows . . . . . . . 196
Unselecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Customizing Marking Colors in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . . 197
Marking and Unmarking Objects in the Schematic Windows . . . . . . . . . . . . . . . . . . . . 197
Copying and Pasting Object Names in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Compaction of Buffers and Inverters in Traced Circuitry . . . . . . . . . . . . . . . . . . . . . . . 202
Tracing a Specific Signal Value to the Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Signal Path Tracing in the Hierarchical Schematic Window . . . . . . . . . . . . . . . . . . . . . 206
Tracing Up and Down the Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Annotation of Schematic Data in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . . 212
Adding User-Defined Annotations to Schematics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Viewing K19 and K22 Simulation Data in the Schematic Windows. . . . . . . . . . . . . . . . 215
Reporting Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Expansion of Library Instances in the Flat Schematic Window . . . . . . . . . . . . . . . . . . . 217
Display of Multiple Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

December 2017
DFTVisualizer
Saving and Restoring Displays
Saving and Restoring Displays

When you have a set of window and data displays you want to use again later, you can save the
settings and then read them into a subsequent session of the tool. You restore the window and
data displays by entering a dofile command and specifying the saved dofile as an argument.
Procedure
1. Select the File > Create Dofile menu item. The Create Dofile dialog box displays.
2. Specify the name of the dofile and click OK.
Results
The tool writes out the specified dofile containing the commands needed to recreate the
instances and data sets currently displayed in DFTVisualizer windows.
Note
The commands in this dofile do not replicate the entire command sequence used in the tool
session. They simply add the instances and data sets that were present in the DFTVisualizer
windows when you wrote out the dofile.
Searching for an Instance, Net, or Pin in the Active

Window
You can search the active window for a specified instance, pin, or net using the Find field on the
toolbar.
Procedure
1. Enter a string in the Find text entry field to search on.

By default, the tool implicitly applies wildcards to the search string and selects all of the
design objects whose pathname includes that string in the active window. You can click
the Exact icon to search for the exact string without applying wildcard characters.
2. Click the icon to search for the specified string.
Note
You can also click the icon in this step. This opens the Global Search window and
the search is applied to the entire design. Refer to “Searching for an Instance, Net, or
Pin in the Design” for more information on using this window.
Results
The objects matching the specified string are selected in the active window.

December 2017
DFTVisualizer
Searching for an Instance, Net, or Pin in the Design
Searching for an Instance, Net, or Pin in the Design

You can search the entire design for a specified instance, pin, or net using the Global Search
window.
Procedure
1. Click the icon in the toolbar or select the Windows > Global Search menu item.
2. Enter a string in the Global Search text entry field to search on. The tool implicitly
applies wildcards to the search string and returns all of the design objects whose
pathnames include that string. You can click the Exact Search checkbox to search for the
exact string without applying wildcard characters.
3. Optionally, click Options in the Global Search window to specify a search depth, search
area, and an object type.
4. Click Search.
Results
The objects matching the specified string are listed in the Global Search window, or the tool
reports that no matching netlist instances are found.
Interruption of Operations from DFTVisualizer

You can interrupt some DFTVisualizer operations at any time by pressing Ctrl-C in the active
DFTVisualizer window.
Alternately, you can also interrupt the same operations by pressing the Stop icon.
The following operations can be interrupted/canceled:
• Data generation for faults, DRCs, gates and primitives in the Instance and DRC
Violations windows of the Design Browser
• Searching in the Global Search window
• Tracing forward/backward to endpoints for instances and pins in the Hierarchical
Schematic Window
• Tracing down in the Hierarchical Schematic Window
• Pattern creation
Undocking and Docking Windows

Each special purpose window can be undocked from the main window. When undocked, you
can move the window around on your desktop independent of the main window.

December 2017
DFTVisualizer
Resizing Windows
Prerequisites
• DFTVisualizer is invoked. For more information, see the “DFTVisualizer Invocation”
section in this chapter.
• At least one window is open.
Procedure
1. To undock a window, click the dock/undock button at the right of the window’s
header bar.
2. To dock a window, click the dock/undock button at the right of the window’s header
bar. The window will return to the location it occupied when it was undocked.
Resizing Windows
Each special purpose window can be modified to varying sizes within the DFTVisualizer
window. Each special purpose window, when undocked, can also be maximized using the
maximize button to completely occupy the operating system window.
Tip
You can maximize an undocked window by clicking the middle window control button at
the upper left-hand corner of the detached window. Click the button again to return the
window to its former position and size within the operating system window.
Prerequisites
• At least two windows are open.
Procedure
1. To resize an undocked window, position the cursor over any window separator bar. The
cursor can be at any point along the separator bar and will change to a double arrow
when it is located within an active region.
2. Press the left mouse button and simultaneously drag the separator bar to create the
desired window size. Release the left mouse button to set the window size.
Repositioning Windows
You can reposition windows in the DFTVisualizer session.

December 2017
DFTVisualizer
Accessing Popup Menus
Prerequisites
• At least two windows are open.
Procedure
1. Press the left mouse button over the icon in the center of the window's header bar
and simultaneously drag it to the new location. A dynamic outline of the window in the
new location appears when you have moved the mouse sufficiently for the tool to
successfully determine the desired location.
2. Release the mouse button.
Results
The window is anchored in the new location.
Accessing Popup Menus

You can access most of a tool’s available menu options from the window popup menu.
Prerequisites
• At least one window is open.
Procedure
1. Press the right mouse button in the display area of any window. The menu options on the
popup menu vary as follows.
• Flat and Hierarchical Schematic Window
If no objects are selected and the cursor is not positioned directly over an object, the
menu is a simple one for adding instances to the window’s display area. If an object
is selected or the cursor is positioned over an object, the popup menu displays
options needed for tracing and debugging.
• All windows except for the Flat and Hierarchical Schematic Window
The object the cursor is positioned over when you open the popup menu (press the
right mouse button) is automatically selected and the menu applies to it.
2. Select a menu option by moving the cursor over the menu item and releasing the right
mouse button.

December 2017
DFTVisualizer
Object Name Copied from a Popup Menu to the System Clipboard
Object Name Copied from a Popup Menu to the

System Clipboard
When you open a popup menu on a single selected object, the object’s pathname is listed as the
first menu option. If you choose the name from the menu, it is copied to the system clipboard.
You can then paste the name into other desktop locations, such as a shell window, text editor,
tool command line, or dialog entry box.
Adding Instances to the Current Display Window

You can add instances to the current window display by explicitly identifying the object or by
copying the instance from another window.
Prerequisites
• DFTVisualizer is invoked and at least one window is open. For more information, see
the “DFTVisualizer Invocation” section in this chapter.
Procedure
Add an instance to a window using one of the following methods:
If you want to... Do the following:

Explicitly identify an instance 1. Activate the window you want to add the instance to.
to add 2. Click the Add Instances icon on the toolbar.
You can use any number of asterisks (*) or question

marks(?) as wildcard characters to specify this string
enabling you to match many pathnames in the design.
Enter a command to specify the 1. Click the Console window to activate it.
instance to add 2. Specify an instance to add by using the
add_display_instances command.
For example, to display all top-level instances in the

Hierarchical Schematic Window, you would enter the
following command:
add_display_instances -display
hierarchical_schematic -down
Selecting Objects
You can select objects displayed in a window using several different methods.

December 2017
DFTVisualizer
Cross-Selecting Objects
Prerequisites
• DFTVisualizer is invoked and objects are displayed in one or more windows. For more
information, see Adding Instances to the Current Display Window.
Procedure
Select objects using one of the following methods:

Select a single object Move the cursor over the object and click the left mouse
button.
When selected, the object is highlighted in a different color.

You can customize the highlight color using the Edit >
Preferences menu item.
Select additional objects Press and hold the Ctrl key while selecting additional
without unselecting previously objects using the left mouse button.
selected objects
Select a range of objects Press and hold the Shift key while selecting the new object
between a currently selected using the left mouse button.
item(s) and a new object
This selects the objects without unselecting the previously
selected objects.
Select all displayed instances Select the Edit > Select All (Ctrl + A) menu item.
This action selects all objects in the window including nets.

Note, this method is only valid in the Flat or Hierarchical
Schematic, Data, Wave, or Text Editor windows. It is not
supported in the Design Browser window.
Cross-Selecting Objects
Cross-selection occurs when you select objects in one window and they are simultaneously
selected in all windows in which they are already displayed. Cross-selection is useful for
flagging an instance so you can identify it easily when viewing information about it in multiple
windows.
Prerequisites
information, see “Adding Instances to the Current Display Window.”
Procedure
1. Select the object(s) in the active window that you want to cross-select.

December 2017
DFTVisualizer
Selecting Multiple Objects in the Flat and Hierarchical Schematic Windows
2. Press the right mouse button anywhere in the window’s display area, and choose the
Cross Select option from the popup menu.
Tip
If you prefer to have cross-selection automatically occur by default whenever you
select an object, without requiring a menu pick, enable the Automatically Cross
Select In All Windows option in the Global Preferences Dialog Box. You can access the
dialog box by using the Edit > Preferences menu item.
Results
The selected object(s) is simultaneously selected in all windows in which it is already displayed.
Selecting Multiple Objects in the Flat and

Hierarchical Schematic Windows
You can select objects in any DFTVisualizer window using different methods.
See the possible methods available in “Selecting Objects” on page 194. There is an additional
way to select multiple objects (nets, pins, and/or instances) in the Flat and Hierarchical
Schematic Windows.
Prerequisites
Procedure
1. Press the left mouse button and drag the cursor so the bounding box contains all the
objects you want selected.
2. Release the left mouse button.
Results
This action selects all objects on the schematic within the area of the bounding box.
Unselecting Objects
You can unselect currently selected objects using either the mouse or the tool menu.
Prerequisites
• At least one object is selected in the active window.

December 2017
DFTVisualizer
Customizing Marking Colors in the Schematic Windows
Procedure
Click in a blank part of the display area of the window, or select the Edit > Undo menu item if
it is available for the window.
Results
All selected objects are unselected.
Customizing Marking Colors in the Schematic

Windows
You can specify the number of colors available to mark objects in the Flat or Hierarchical
Schematic, and Test Structures windows, and also to customize which colors are available.
Prerequisites
• DFTVisualizer is invoked.
Procedure
1. Choose Edit > Preferences and click the Colors tab.
2. Click the window name in the Windows List field for which you want to customize
colors. The window name becomes highlighted.
3. Click Marked in the Options List. The No. of Colors and Color Index buttons, which
are only related to marking, display.
4. Click the No. of Colors and select a number to choose the number of colors you want to
use when marking objects.
5. Click Color Index to select the number for which you want to assign a color and then
click the desired color from the Color Palette.
6. Click OK to save your selections.
Results
The colors you set with this procedure are now available on the cascading menus of the
specified window when you choose the Display > Marking (Ctrl + M) pulldown menu or
Marked popup (RMB) menu.
Marking and Unmarking Objects in the Schematic

Windows
You can mark and unmark objects in the Flat Schematic, Hierarchical Schematic, and Test
Structures windows using multiple colors.

December 2017
DFTVisualizer
Viewing Instances in Other Windows
Prerequisites
• DFTVisualizer is invoked, the Flat Schematic, Hierarchical Schematic, or Test
Structures window is active, and at least one object is displayed in the active window.
For more information, see Adding Instances to the Current Display Window.
Procedure
1. Select the objects you want to mark.
2. Press and hold down the Ctrl key; press M. A colored rectangle shows the active mark
color in the upper left-hand corner of the window. Repeatedly press M until the
rectangle shows the color you want to mark the selected objects with or shows gray to
unmark the instance; release the Ctrl key.
Note
You can also mark or unmark objects using the following methods: (1) by selecting
Display > Marking (Ctrl + M) from the pulldown menu or Marking (Ctrl + M)
from the popup (RMB) menu, and (2) by using the mark_display_instances and
unmark_display_instances commands.
3. Click the cursor in the active window to deselect the selected objects and display the
objects as marked.
Tip
You can select Display > Zoom > Marked to reposition the schematic view to show
marked objects.
Results
The selected objects display in the marked color.

You can view an instance that is visible in one window in a different window as listed in the
following table. This can save time when you are viewing an instance in one window and the
kind of data you want to see for the instance requires a different window.
Table 7-1. Windows Between Which You Can View Instances

Source Window Destination Windows
Flat Schematic Window Data/Wave, Hierarchical Schematic, Design Browser
Instance and Library tabs, Text Editor (Definition), and
Text Editor (Instantiation)
Hierarchical Schematic Data/Wave, Flat Schematic, Text Editor (Definition),
Window and Text Editor (Instantiation)

December 2017
DFTVisualizer
Table 7-1. Windows Between Which You Can View Instances (cont.)
Source Window Destination Windows
Design Browser, Hierarchy Data/Wave, Flat/Hierarchical Schematic, Design
tab, see the “Usage Notes for Browser Library tab, Text Editor (Definition), and Text
the Instance Browser” section Editor (Instantiation)
in Design Browser Window
Design Browser, Library tab, Data/Wave, Flat/Hierarchical Schematic, Design
see the “Usage Notes for the Browser Instance tab, Text Editor (Definition), and
Library Browser” section in Text Editor (Instantiation)
Design Browser Window
Design Browser, Clock tab, see Data/Wave, Flat/Hierarchical Schematic, Text Editor
the “Usage Notes for the Clock (Instantiation)
Browser” in Design Browser
Window
Design Browser Window Data/Wave, Flat/Hierarchical Schematic,
Data Window Flat/Hierarchical Schematic, Text Editor (Definition),
and Text Editor (Instantiation)
Wave Window Flat/Hierarchical Schematic, Text Editor (Definition),
and Text Editor (Instantiation)
Global Search Window Data/Wave, Flat/Hierarchical Schematic, Design
Browser Instance and Library tabs, Text Editor
(Definition), and Text Editor (Instantiation)
Prerequisites
• Instances you wish to view in another window must display in the source window.
Procedure
Use one of the following methods to view an instance that is in one window (source) in another
window (destination).

Use the Right Mouse (Popup) 1. Move the cursor over an instance in the source window.
Menu 2. Press the right mouse button and select the View In
option on the popup menu to specify the destination.
Tip: To view multiple instances, first select them, then move
the cursor over one of the selected instances and press the
right mouse button to access the popup menu.

December 2017
DFTVisualizer
Copying and Pasting Object Names in the Design

Use the Main Pulldown Menu 1. Select one or more instances in the source window, then
choose the Edit > Copy menu item.
2. Paste the selection into the destination window:
a. Click on the window header bar of the target window
and choose the Edit > Paste menu item, or press the
right mouse button in the destination window and
select Add from the popup menu. The Make Additions
to the Display dialog box displays.
b. Move the cursor over the entry box, press the right
mouse button, and select Paste.
c. Click the Add button and OK the dialog box.
Results
The selected objects are visible in the destination window.
Related Topics
Adding Instances to the Current Display Window
Copying and Pasting Object Names in the Design

Use this procedure in a DFTVisualizer window to select and copy an object’s hierarchical
pathname to a buffer which you can then paste into DFTVisualizer or any other application.
When you select more than one object, the selected object names are copied into a list
surrounded by brackets and delimited by spaces as shown here: {obj_name1 obj_name2 ...}. If
you select a single object whose name does not contain any special characters, the object name
is copied into the buffer but is not surrounded by brackets.
Prerequisites
the “DFTVisualizer Invocation” section in this chapter.
• Object(s) whose name you wish to copy must display in the source window.
Procedure
1. Select the objects whose names you want to copy. Note, you can use the Shift key to
select more than one object.
Tip
If you are copying only one object name, you can position your cursor over the
object, without selecting it, and click the right mouse button.

December 2017
DFTVisualizer
Trace Options
2. Click the right mouse button in the display area of the window and select the
“<object_name(s)> (click to copy)” item at the top of the popup menu.
3. To paste the object(s) in DFTVisualizer, click the right mouse button in the location you
want to paste and select Edit > Paste from the popup menu or type Ctrl-V.
Trace Options
The following table summarizes the trace options available in the Flat Schematic Window (or
within the same hierarchical level in the Hierarchical Schematic Window).
When you click the diamond on a pin, rather than using the right mouse popup menu, you get
the default trace behavior. You can change the forward trace default in the Preferences dialog
box.
Table 7-2. Trace Options
Option Selected Trace Behavior
Trace Backward (default) Pin Trace backward one instance.
Instance Trace backward one instance from each input pin.
Trace Backward Endpoint Pin Trace backward to endpoints, showing all
circuitry in between.1
Instance Trace from each input pin backward to endpoints
and show all circuitry in between.1
Trace Forward One (default) Pin Trace forward one instance.
Instance Trace forward one instance from each output pin.
Trace Forward Fanout Pin Trace forward one instance on each fanout.
Instance Trace forward from each output pin one instance
on each fanout.
Trace Forward Endpoint Pin Trace forward to endpoints, showing all circuitry
in between.1
Instance Trace from each output pin forward to endpoints
and show all circuitry in between.1
Trace Backward Value Pin Traces the value on a selected pin back to its
source. The trace continues back from the
selected pin until either the origin cannot be
distinguished due to a complex path, or the origin
is found.
1. An endpoint is defined as a primary input, primary output, scan cell, tie gate, or black box. RAMs and
ROMs are also endpoints.

December 2017
DFTVisualizer
Compaction of Buffers and Inverters in Traced Circuitry
Compaction of Buffers and Inverters in Traced

Circuitry
You can globally enable and disable compaction. Compaction applies only to those parts of the
net that you have traced/added to the window. By default, compaction of buffers and inverters is
enabled.
You enable and disable compaction in the Schematics Preferences Dialog Box which you
access from the Edit > Preferences menu. When the global compaction option is enabled, you
can selectively expand/collapse buffers/inverters on a per net basis. Compaction/un-compaction
traverses from the symbol in all directions until a non-collapsible instance is reached.
Compaction symbols display on individual nets indicating whether buffers/inverters are

expanded or collapsed on that net. You can view the number of inverters/buffers collapsed on a
particular net by positioning your cursor over the compaction symbol and viewing the popup
text; the number of inverters/buffers reported reflects only the section of the net that is visible in
the current view even though there may be more buffers or inverters on that net.
Note
Be aware that compaction behavior may change if you trace additional parts of the net. For
example, if you add a branch between two inverters that were compacted, those inverters
may no longer be compacted after the branch is added, which results in the compaction markers
disappearing from that net.
When global compaction is enabled, compaction symbols have the following meaning on
individual nets:
• Compacted symbol (plus sign symbol) — indicates the existence of collapsed buffers
and/or inverters on the net. Clicking on the symbol expands the buffers and/or inverters
and toggles the symbol. Positioning your cursor over the symbol, displays the number of
inverters/buffers collapsed on the net.
• Uncompacted symbol (minus sign symbol) — indicates that buffers and/or inverters are
expanded on that net. Clicking on the symbol collapses the buffers and/or inverters and
toggles the symbol.
• No Compacted or Uncompacted symbol — indicates that no buffers or inverters exist on
the net.
When global compaction is enabled, the following is true:
• Buffers are not displayed. When you trace from an instance connected to a buffer, you
trace to the next non-buffer instance. You can click the Compacted symbol to turn off
compaction for the individual net and view the expanded objects.

December 2017
DFTVisualizer
Tracing Signal Paths on a Schematic
• If an even number of inverters exists, zero inverters are displayed. If an odd number of
inverters is compacted, a single inverter displays. When you trace from one instance
connected to an inverter, you trace to the next non-inverter instance.
Note
If you explicitly add a buffer or an inverter using the add_display_instances
command, the buffer/inverter displays on the net to which it is added, irrespective of
whether compaction is enabled or disabled.
The maximum number of gates that can be inserted before requiring a confirmation
includes the inverter buffer count. If you are displaying a large portion of circuitry with
a lot of compaction, you might see the warning that the threshold has been exceeded
even though what ends up being displayed is less than the maximum number of gates.

You can often learn more about a circuit’s behavior by displaying instances along a specific
signal path (tracing).
When one or more instances are visible in the Flat or Hierarchical Schematic Window, you can
trace from the instances. As shown in Figure 7-2, a diamond symbol on a pin or net indicates
circuitry is connected there, is not yet displayed, and so can be traced. The table in the
Procedure section summarizes the available trace options.
Figure 7-2. Trace Symbols

December 2017
DFTVisualizer
When tracing, be aware of the following:
• In the Flat Schematic Window, buffers and certain inverters are not displayed by default
in order to reduce screen clutter. See Compaction of Buffers and Inverters in Traced
Circuitry for more information.
• In the schematic windows, you can include annotated data. This is controlled by the
set_gate_report command. See Annotation of Schematic Data in the Schematic
Windows for more information.
• Instances added by the most recent trace are highlighted. You can control the highlight
color using the Colors tab of the Preferences dialog box available from the Edit >
Preferences menu.
Prerequisites
• DFTVisualizer is invoked and the Flat or Hierarchical Schematic Window is open. For
more information, see the “DFTVisualizer Invocation” section in this chapter.
• One or more instances must be visible in the Flat or Hierarchical Schematic Window. To
add instances to a window, see Adding Instances to the Current Display Window.
Procedure
Use one of the following methods to trace forward or backward:

Use the left mouse button Move the cursor over the diamond on a pin and click the left
mouse button.
Select a pin and use the Trace 1. Move the cursor over a pin (between the diamond and
menu the instance) and click the left mouse button to select the
pin. To select more than one pin, press the Shift key
while simultaneously selecting the pins.
For a single pin, move the cursor over the pin (anywhere,
including the diamond) and press the right mouse button:
this selects the pin and opens a popup menu.
2. Use the Trace menu or the popup menu to choose a trace
option and initiate the trace. The trace will occur
simultaneously from each selected pin.

December 2017
DFTVisualizer
Tracing a Specific Signal Value to the Source

Select an instance and use the 1. Move the cursor over an instance and click the left
Trace menu mouse button to select it. To select more than one
instance, press the Shift key while simultaneously
selecting the instances.
2. Use the Trace menu or the right mouse popup menu to
select a trace option and initiate the trace. The trace will
occur simultaneously from all applicable input or output
pins on the selected instances.
Tip: When you open the popup menu for a single output pin
(not instance), the total number of fanouts is in parentheses
at the end of the “Trace Forward Fanout” choice.
Enter a command 1. Click the Console window to activate it.
2. Specify a path to trace by entering the
add_display_instances command and specifying a
beginning and ending gate using the -Path switch as
shown here:
add_display_instances -path start_gate
end_gate
Results
In the Hierarchical Schematic Window, the tool attempts to trace the path in one direction
beginning at start_gate; the tool returns an error if end_gate is not found.
In the Flat Schematic Window, the tool first attempts to trace the path in the direction specified
by the user. If that path is not found, the tool then attempts to trace the path in the opposite
direction. If that path in not found, the tool returns an error message.
Related Topics
Signal Path Tracing in the Hierarchical Schematic Window
Trace Options
Compaction of Buffers and Inverters in Traced Circuitry
Tracing a Specific Signal Value to the Source

You can automatically trace a value on a selected pin to its source.
Prerequisites
• DFTVisualizer is invoked and the Flat Schematic Window is open. For more
information, see the “DFTVisualizer Invocation” section in this chapter.
• One or more instances is visible in the Flat Schematic Window. See Adding Instances to
the Current Display Window.

December 2017
DFTVisualizer
Signal Path Tracing in the Hierarchical Schematic Window
• Pin data is displayed. If needed, select an option from the Data menu to display pin data.
Procedure
1. Right click on the pin displaying the value you want to trace. A popup menu displays.
2. Select Trace Backward Value. A pop menu displays all the values on the pin. The left-
most value on the pin displays at the top of the menu.
3. Select a value to trace.
Results
The value is automatically traced back from the selected pin either until a point is reached where
the origin cannot be distinguished due to a complex path, or the origin is found.
Signal Path Tracing in the Hierarchical Schematic

Window
The Hierarchical Schematic Window allows you to view and trace through the hierarchy in a
multi-level design.
You can use the following methods for viewing and tracing a hierarchical design:
• Add the top level instance (/) by using any of the methods described in “Adding
Instances to the Current Display Window” on page 194.
• When you add an instance, it is shown with all pins. Hierarchical modules added as a
result of tracing, however, are shown with only the pins that are connected to other
displayed instances. This allows you to trace up and down the hierarchy, displaying only
pins from or through which you are tracing.
To show all pins, move the cursor onto the instance, then press the right mouse button
and choose Show Hidden (#) Pins from the popup menu. (The number in parentheses is
the number of pins that are currently hidden.)
To hide pins for which there are no connections currently displayed, choose Hide
Unconnected Pins from the popup menu.
• Double-click on a hierarchical instance to display all instances inside it. The number of
instances inside is shown in parentheses next to the name of the submodule.
To hide all instances currently displayed inside a hierarchical instance, select it, then
press the right mouse button and choose Collapse from the popup menu.
• To clean up the schematic, select an instance and choose the Remove Other Instances
item from the right mouse button menu. Everything is deleted except the selected
instance. If the selected instance is a submodule displaying instances inside it, they are
kept.

December 2017
DFTVisualizer
Tracing Up and Down the Design Hierarchy

The Hierarchical Schematic Window allows you to trace through the design hierarchy in a
multi-level design.
Prerequisites
• DFTVisualizer is invoked and the Hierarchical Schematic Window is open. For more
information, see DFTVisualizer Invocation.
• One or more instances must be visible in the Hierarchical Schematic Window. If you
need to add an instance, see Adding Instances to the Current Display Window.
Procedure
Use one of the following methods to trace up or down the design hierarchy:

Double-click Double-click a hierarchical pin or hierarchical instance to
trace down.
Use the Trace Down Fanout or Select a hierarchical instance or a pin on a hierarchical
Trace Up popup menu option instance, then use the Trace Down Fanout or Trace Up
option from the right mouse popup menu.
Use the Trace Up One or Select a hierarchical instance, then use the Trace Up One or
Trace Down popup menu Trace Down option from the right mouse popup menu.
option
Examples
The following example shows the result of selecting a pin and tracing down one hierarchical
level and then up a level.

December 2017
DFTVisualizer
Figure 7-3. Tracing Down One Hierarchical Level from a Selected Pin

December 2017
DFTVisualizer
Figure 7-4. Tracing Up One Hierarchical Level from a Selected Pin

December 2017
DFTVisualizer
Bundling Nets
In some cases, you may not want to see all the nets that are connected between instances. For
instances at higher levels of the hierarchy, where you typically have fewer instances with a large
number of pins, you may be more interested in seeing between which blocks there are
connections, than in seeing all the connections themselves.
To gather signals between instances into bundles represented by single thick lines, select the
Display > Net Bundle > On menu item. The effect of net bundling is seen in the difference
between Figure 7-5 and Figure 7-6.

December 2017
DFTVisualizer
Figure 7-5. Hierarchical Schematic Window Display with Net Bundling Off
Figure 7-6. Same Display with Net Bundling On

December 2017
DFTVisualizer
Annotation of Schematic Data in the Schematic Windows
Annotation of Schematic Data in the Schematic

Windows
Data is automatically annotated to the schematic in the schematic windows based on the current
setting of the set_gate_report command which also controls the report_gates data output.
Most of the set_gate_report options are available through the Data menu and the most
commonly used ones have buttons on the tool bar. The Data menu and tool bar are context
sensitive: options shown might change depending on the availability of the associated data or
procedure.
You can clean up the schematic by selecting an instance and choosing the Remove Other
Instances item from the right mouse button menu. Everything is deleted except the selected
instance. If the selected instance is a submodule displaying instances inside it, they are kept.
Note
If you select the right mouse button Remove Other Primitives menu item on a primitive
gate inside an already expanded instance, all other primitives inside that instance are
removed from the display but all design level instances remain.
Some commands, such as analyze_drc_violation will automatically issue a set_gate_report

command, so you do not have to manually enter the command or use the Data menu.
Adding User-Defined Annotations to Schematics

Callout boxes containing user-defined text can be created and selectively displayed on design
objects in the desired schematic window.
The specified design object will be automatically displayed if it is not already shown in the
schematic. If a callout box already exists for the object, the user-defined text will be appended
into that callout box. User-defined text is displayed with a golden background color to
distinguish it from other callout box text that may be displayed. The callout box is associated
with the specified object or object type and will move with the object and print with the
schematic.
Callout boxes containing user-defined text can be used to easily identify a particular object, or
even a collection of objects using the introspection (get_*) commands, as shown in this
procedure.You can also add callout box annotation definitions to a dofile so that the desired text
is displayed when the tool invokes.
The add_display_callout command is used to add callout boxes, and the delete_display_callout
command is used to remove them. For more information on how to manage the display
characteristics of the callout boxes, refer to “Working with Attributes” on page 219. This
procedure will provide several methods to add and remove callout boxes containing user-
defined text.

December 2017
DFTVisualizer
Prerequisites
• Tessent Shell is invoked and a design netlist is loaded. Running add_display_callout
will automatically invoke DFTVisualizer if it is not already open.
For more information, see the “DFTVisualizer Invocation” section in this chapter.
Procedure
1. To add a user-defined callout box on a single design object, the add_display_callout
command is used as shown below:
add_display_callout core_inst1/blockA_clka_i2/mem4 \
-string “power domain v1p8” -display hierarchical_schematic
The instance and callout will be displayed in the Hierarchical Schematic window:
If a callout box already exists on this instance, the user-defined callout would be

December 2017
DFTVisualizer
appended to it and display as shown:
2. To remove the user-defined callout box that was added in the prior step, the
delete_display_callout command would be used:
delete_display_callout core_inst1/blockA_clka_i2/mem4 -display
hierarchical_schematic
The user-defined text in the callout box will be removed and the callout box will be
removed if no other attributes are displayed. The design object will not be removed from
the schematic.
3. To add user-defined callout boxes on multiple design objects, Tcl lists and wildcards can
be used to define a collection. The example below will add the callout box to the mem1
instance in blockA_clka_i1, and to all mem2 instances found in this block and all sibling
blocks with the same name prefix:
add_display_callout {core_inst1/blockA_clka_i1/mem1
core_inst1/blockA_clka_i*/mem2} \
-string “power domain v1p8” -display hierarchical_schematic
4. To add user-defined callout boxes on multiple design objects, a Tcl object returned by
an introspection command (get_*) can be implemented. The example below shows how
the get_instances command can be used to add callout boxes and display all instances
that use the library module “SYNC_2R2W_12x8” in the design:
add_display_callout [get_instances -of_modules SYNC_2R2W_12x8] \
-string “v1p8” -display hierarchical_schematic

December 2017
DFTVisualizer
Viewing K19 and K22 Simulation Data in the Schematic Windows
5. To remove the user-defined text within blockA_clka_i2 added in the prior step, but
leaving the other callout boxes, introspection commands can be used with
delete_display_callout:
delete_display_callout [get_instances -below_instances core_inst1/blockA_clka_i2
-of_modules SYNC_2R2W_12x8] \
-string “v1p8” -display hierarchical_schematic
The user-defined text in the callout boxes of these specific instances will be removed
and the callout boxes will be removed if no other attributes are displayed. The design
objects will not be removed from the schematic.
Viewing K19 and K22 Simulation Data in the

Schematic Windows
K19 and K22 simulation data is available in the schematic windows for all simulation gates by
using the Data > K19 and K22 menu items. By default, the tool displays load, shift, and capture
procedures for K19 and K22 DRCs.
You can specify the number of characters of simulation data to be displayed at those gates by
editing your preferences. The tool displays a [Pass] or [Fail] label at each monitor point
indicating that the simulation for that monitor point has passed or failed. The tool displays a
[Not sim] label for gates that are not simulated by the DRC.
For complete information on monitor points, see “Resolving DRC Issues” in the Tessent
TestKompress User’s Manual.

December 2017
DFTVisualizer
Viewing K19 and K22 Simulation Data in the Schematic Windows
Prerequisites
• DFTVisualizer is invoked and a schematic window contains the design you are
debugging. For more information, see DFTVisualizer Invocation.
Procedure
1. Optionally, specify the number of characters of simulation data that you want to be
displayed by selecting the Edit > Preferences menu, selecting the Schematics tab,
clicking the Flat or Hierarchical option, and entering a number in the “Show the First #
Characters of Simulation Data” field; by default, the tool displays up to 32 characters of
simulation data.
2. Issue the set_gate_report command or select the Data > K22 menu item to instruct the
tool to display the simulation data you want to see. For example, the following
command instructs the tool to show five cycles of shift data for each gate. As a result of
issuing this command, the following data is displayed in the schematic window:
set_gate_report k22 shift 1 5
3. Display the full simulation results for a gate by selecting the gate and entering Ctrl-R.
The simulation data is displayed in the Console window as seen in this example:
SETUP> set_gate_report k22 shift 1 5
SETUP> // command: report_gates /tiny1_3/edt_i/edt_compactor_i/
decoder1/ix5
// /tiny1_3/edt_i/edt_compactor_i/decoder1/ix5 and02
// A0 I /tiny1_3/edt_i/edt_compactor_i/ix111/Q
// A1 I /tiny1_3/edt_i/edt_compactor_i/ix91/Q
// Y O /tiny1_3/edt_i/edt_compactor_i/ix3/A0
//
// Proc: shi 1 sh 2 sh 3 sh 4 sh 5 cap
// ----- ----- ---- ---- ---- ---- ---
// Time: i 123 123 123 123 123 o o
// n0000 0000 0000 0000 0000 fXf
// ----- ----- ---- ---- ---- ---- ---
// Sim: 00000 0000 0000 0000 0000 000
// Emu: --1-- -1-- -1-- -1-- -1-- ---
// Mism: * * * * *
// Monitor: Block "tiny_1_of_3_cells" EDT decoded masking signal 2.
//
// Inputs:
// A0 11111 1111 1111 1111 1111 111
// A1 00000 0000 0000 0000 0000 000
//

December 2017
DFTVisualizer
Reporting Gates
4. Examine the simulation data that displays in the schematic window and trace back to
find the origins of the simulation failures.
Related Topics
Trace Options
Reporting Gates
Reporting Gates
You can report gate information (netlist and simulation data) for selected objects from the
Design Browser, Hierarchical Schematic, Flat Schematic, Test Structures, Data, Wave, and
Global Search windows.
Prerequisites
DFTVisualizer Invocation.
Procedure
1. Select the object(s) to be reported on. You can use the Shift key together with the left
mouse button to select multiple objects. For more information, see “Selecting Objects.”
2. Press Ctrl + R, click the Report Gates icon, or press the right mouse button and
select Commands > Report_Gates (Ctrl + R).
Results
The report_gates command executes and outputs data to the Console window. For more specific
information on using the report_gates command to troubleshoot violations, see
“How to Report Gate Data” and report_gates.
Expansion of Library Instances in the Flat

Schematic Window
You can view the library primitives of a specific instance in the Flat Schematic Window from
design level by double-clicking on the instance. The instance expands to show the library
primitives and is surrounded by a bounding box. Note, the progress bar in the lower-left of the
Flat Schematic Window indicates the progress of the expand operation. Double-clicking on the
bounding box returns you to the instance view.
Display of Multiple Data Sets

The Data window provides simultaneous access to the several types of information controlled
by the set_gate_report command. This is in contrast to the schematic windows and the

December 2017
DFTVisualizer
Display of Multiple Data Sets
command line where you can report only the data corresponding to the current setting of the
set_gate_report command.
For example, you can display simulation data for the load_unload and shift procedures for a
particular pattern. The options are available through the Data menu and the buttons on the tool
bar.

December 2017
DFTVisualizer
Working with Attributes
Working with Attributes

An attribute is visible in the DFTVisualizer Hierarchical and Flat Schematic Windows if you
have enabled the global display option for that particular attribute. By default, attributes do not
display in DFTVisualizer windows.
Attributes in the Hierarchical and Flat Schematic Windows . . . . . . . . . . . . . . . . . . . . . 219
Setting Global Attribute Display Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Setting Attribute Background Display Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Controlling the Display of Callouts in the Flat and Hierarchical Schematic Windows 222
Attributes in the Hierarchical and Flat Schematic

Windows
When you globally enable the display of an attribute, the attribute displays in a callout box on
the schematic. A callout box is a text box associated with a specific object that contains
information about that object such as its attributes.
You can enable/disable the global display of individual attributes using the Attributes
Preferences dialog box, which you access from the Edit > Preferences menu or by clicking the
toolbar icon. You can also enable/disable the display of attributes by using the
set_attribute_options command with appropriate switches.
Figure 7-7 shows a callout box. Note, in order to view attributes on the schematic, callout boxes
must be showing.

December 2017
DFTVisualizer
Attributes in the Hierarchical and Flat Schematic Windows
Figure 7-7. Attributes in DFTVisualizer
Note
For information on how to add user-defined annotations to schematic callouts boxes, see
“Adding User-Defined Annotations to Schematics.”
Table 7-3 lists the icons you can use in the Hierarchical and Flat Schematic Windows to manage
attributes.
Table 7-3. Icons for Managing Attributes and Callouts
Icon Description
Toggles between collapsing and expanding all callout boxes on the schematic.
Callout markers indicate the location of collapsed callout boxes.
Hides all callout markers in the Design and Flat Schematic Windows.
Displays the DFTVisualizer Preferences dialog box, Attributes tab.
DFTVisualizer displays attributes in the Hierarchical and Flat Schematic Windows as follows:
• Only attributes with a value different than their default value display — regardless of
whether you have globally set the attribute to display.

December 2017
DFTVisualizer
Setting Global Attribute Display Options
• Attributes with a type of Boolean display as a name only — no value is shown.

• Attributes registered on nets display; attributes inherited from ports/pins do not display
because the attributes already show up on the ports/pins to which the net is connected.
• Attributes display with the background color assigned to them by the Color Index on the
Attributes tab of the DFTVisualizer Preferences dialog box.
Related Topics
Attribute Preferences Dialog Box
Flat Schematic Window
Controlling the Display of Callouts in the Flat and Hierarchical Schematic Windows
Setting Attribute Background Display Colors

You can specify which attributes are visible in DFTVisualizer. Note, only attributes with a
value different than their default value display, regardless of whether you globally set the
attribute to display.
Note
This procedure manages the display of attributes using the DFTVisualizer user interface.
You can perform equivalent steps using set_attribute_options from the command line. For
more information, see set_attribute_options in the Tessent Shell Reference Manual.
Prerequisites
• DFTVisualizer is invoked. For more information, see “DFTVisualizer Invocation”.
Procedure
1. Display the Attributes tab of the DFTVisualizer Preferences dialog box by doing one of
the following:
• Select Edit > Preferences and click the Attributes tab.
• Activate either the Hierarchical or Flat Schematic Window, and click the icon.
2. Select an attribute in the left-hand column of the DFTVisualizer Preferences dialog box.
3. Click the button to move the selected attribute into the Displayed Attributes column.

December 2017
DFTVisualizer
Note
By default, the attribute inherits the background color currently showing on the
Color Index button. See “Setting Attribute Background Display Colors” to change
this color.
4. Click OK.

You can specify the background color of attributes displayed in DFTVisualizer.
Prerequisites
• DFTVisualizer is invoked. For more information, see the DFTVisualizer Invocation.
Procedure
1. Display the Attributes tab of the DFTVisualizer Preferences dialog box by doing one of
the following:
• Select Edit > Preferences and click the Attributes tab.
• Activate either the Hierarchical or Flat Schematic Window, and click the icon.
2. Select the attribute in the Displayed Attributes (right-hand) column whose background
color you want to modify.
3. Click the Color Index button to display the color map and select the desired color.
4. Click OK.
Results
The background color of the specified attribute is set.
Controlling the Display of Callouts in the Flat and

Hierarchical Schematic Windows
You can control the display of callout boxes and markers in the Flat and Hierarchical Schematic
Windows. Attributes are displayed in callout boxes.
Prerequisites
• DFTVisualizer is invoked and a schematic window is active. For more information, see
DFTVisualizer Invocation.

December 2017
DFTVisualizer
Controlling the Display of Callouts in the Flat and Hierarchical Schematic Windows
Procedure
Use one of the following icons to control the display of callout boxes and markers.
Click To...
Toggle between collapsing and expanding all callout boxes on the schematic.
Hide all callout markers on the schematic.

December 2017
DFTVisualizer

To access: select Edit > Preferences and click the Attributes tab, or activate either the
Hierarchical or Flat Schematic Window and click the toolbar icon.
The DFTVisualizer Preferences (Attributes tab) dialog box allows you to set preferences
associated with the display of attributes in the Hierarchical and Flat Schematic Windows.
Objects
Table 7-4. DFTVisualizer Preferences Dialog Box, Attributes Tab
Field Description
Object Type Specifies the object type to which the attributes listed in the left column
of the dialog box are registered.
Object Attributes Specifies the attributes defined for the selected Object Type. The
(left column) attributes are divided into two groups: user-defined attributes (listed
first) and predefined attributes (listed below the ---- divider). 1
Displayed Attributes Specifies the attributes that are visible in DFTVisualizer.2An object
(right column) selected in this column displays in red text. Note, only attributes with a
value different than their default value display on the schematic,
regardless of whether you have globally set the attribute to display.
Color Index Specifies the background color to use when displaying the selected
attribute in schematic windows.3DFTVisualizer provides ten
background colors.
1. These attributes use the following option: set_attribute_options -display_in_gui OFF.
2. These attributes use the following option: set_attribute_options -display_in_gui ON.
3. Attribute background color is specified by: set_attribute_options -gui_marking_index <index>.
Usage Notes
• Add and remove attributes from the Displayed Attributes column by clicking the
and arrow buttons or by double-clicking on the column entry.
• Select multiple entries from a list using the Ctrl or Shift key together with the select
mouse button.
• Set/change the background color of the attribute using the button.
Related Topics

December 2017
DFTVisualizer
Working With Specifications in the Configuration Data Window
Working With Specifications in the

Configuration Data Window
The Configuration Data window allows you to view specifications and to modify the
configuration tree elements and their properties using a graphical interface.
Modifying the Contents of the Configuration Data Window . . . . . . . . . . . . . . . . . . . . . 225
Adding a Test Data Register to a SIB Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Customizing the DFT Specification for EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Modifying the Contents of the Configuration Data

Window
You use the Configuration Data window to view and modify specifications.
Prerequisites
• Tessent Shell is invoked.
Procedure
1. Open the Configuration Data window by issuing the display_specification command to
view and modify a DftSpecification that was read in using the read_config_data
command, or issue the “display_specification -create” command to create one from
scratch using the graphical interface.
The Configuration Data window opens and displays the existing configuration data as
shown in this example.
Figure 7-8. Configuration Data Window
2. Select an element from the Configuration Tree, click the right mouse button, and select
one of the Add > menu items to add.
The Add > menu displays a context-sensitive list of elements that shows the type of
elements you can add based on the type of element you selected.

December 2017
DFTVisualizer
Adding a Test Data Register to a SIB Example
3. Specify the parameters of the newly added element in the Configuration Options panel:
• Enter the values of the element’s listed properties; you can use the icon to select
from pre-defined values for that object.
• Click to define parameters of the element’s interface.
• Click and to define the number of ports on the element,

their names, and connections.
• Click to define arbitrary attributes on the element’s ICL module.
4. Click Apply to update the specification.

5. When you have created and fully defined all of the elements that you want to add, click
the icon to validate the current specification and look for errors. You can also issue
the “process_dft_specification -validate_only” command which is an equivalent action.
6. After you have validated the specification and resolved all errors, click the icon to
execute the specification. You can also issue the process_dft_specification command
which is an equivalent action.
Results
You have created and defined new elements in your specification. You have validated the
correctness of these changes, and created the specified elements by executing the specification.
Related Topics
Adding a Multiplexer to a SIB Example

You can add a Test Data Register (TDR) to a SIB using the graphical interface of the
Configuration Data window.
Prerequisites
Procedure
1. Open the Configuration Data window from either the Tessent Shell command line or
from DFTVisualizer.
2. Select the SIB to which you want to add the TDR.

December 2017
DFTVisualizer
3. Click the right mouse button and select Add > Tdr.
You can change its position using the Move Up and Move Down menu items.
4. In the Configuration Options panel, enter a name in the id field. You can specify the
desired value of any of the other displayed fields.
5. Click and and modify the value of the “count” property in
each to change the number of ports on the TDR.
6. Click Apply to update the specification.
Results
You have added a TDR to a SIB and defined the number of ports on the TDR.
Related Topics
Modifying the Contents of the Configuration Data Window

You can add a ScanMux to a SIB using the graphical interface of the Configuration Data
window.
Prerequisites
Procedure
1. Open the Configuration Data window from either the Tessent Shell command line or
from DFTVisualizer.
2. Add a ScanMux by selecting the SIB to which you want to add the ScanMux, clicking
the right mouse button, and then selecting Add > ScanMux.
You can change its position using the Move Up and Move Down menu items.
a. Name the ScanMux by entering a name in the id field of the Configuration Options
panel. You can specify the desired value of any of the other displayed fields.
b. Define the ScanMux connections by clicking and entering the connection
for the Mux select line. If a TDR is defined, you may use any TDR data output port
to control the mux select signal.
c. Click Apply to update.
3. Add the first input port to the new ScanMux by positioning your cursor on the new
ScanMux, clicking the right mouse button, and selecting Add > Input.

December 2017
DFTVisualizer
Customizing the DFT Specification for EDT
a. Select the new input port and enter a number in the int field of the Configuration
Options panel.
b. Click Apply to update.
c. Add a TDR that will be accessed when this mux input port is selected by positioning
the cursor on the Input port, clicking the right mouse button, and selecting Add >
Tdr.
i. Name the TDR by selecting the TDR and entering a name in the id field of the
Configuration Options panel.
ii. Connect the TDR to the design by:
a. Clicking the left mouse button on the button, clicking
, and then clicking the plus sign . Enter the range that
matches the design instance data bus size into the range field (for example
“7:0”), and enter the pathname to the design instance in the pin_name field.
b. Clicking the left mouse button on the button, clicking
, and then clicking the plus sign . Enter the range that
matches the design instance data bus size into the range field, and enter the
pathname to the design instance in the pin_name field.
4. Define the connections for the second input port of the ScanMux using the instructions
in Step 3.
Results
You have created a ScanMux and defined the select signal. You have added two Input wrappers
to the ScanMux, each of which have a TDR defined.
Related Topics

In the pre-scan DFT insertion flow, you create a DFT specification for inserting the EDT
hardware. You may need to customize the DFT specification that Tessent Shell generates to suit
your design requirements. You can edit the DFT specification from the Configuration Data
window.
Prerequisites
• You have created a DFT specification for inserting EDT. This procedure assumes that
you specified the create_dft_specification command with the -sri_sib_list option.

December 2017
DFTVisualizer

Procedure
1. Open a DFT specification in the Configuration Data window by specifying the
display_specification command.
2. In the Configuration Tree pane, right-click the DftSpecification wrapper and then select
Add > EDT.
3. In the ijtag_host_interface field, enter Sib(edt), and then click Apply.
4. Right-click the EDT wrapper, and then select Add > Controller.
5. Select the Controller wrapper, and then in the Configuration Options pane, in the id
field, enter the name of the controller.
6. In the Configuration Options pane, fill in the following fields to configure how you
want Tessent Shell to create the EDT controller hardware, and then click Apply.
a. longest_chain_range (two number fields to be entered)
b. scan_chain_count
c. input_channel_count
d. output_channel_count
7. If you are inserting EDT at the chip level (design_level chip), do the following:
a. Click the plus sign next to the Controller wrapper, right-click the Connections
wrapper, and then select Add > EdtChannelsIn and Add > EdtChannelsOut as
many times as required for the EDT controller.
b. Within the Connection wrapper, select one of the input or output channels you
created, and in the Configuration Options pane, in the port_pin_name field, enter
the pin name for the selected channel. Click Apply.
c. Repeat the process in the previous step to name all the input and output channels you
created.
8. Optionally, view the edited DFT specification by specifying the report_config_data
command, and then specify the read_config_data command to add the edited DFT
specification to a dofile for later re-use in an automated flow.
Results
To view the modified DFT specification, specify the report_config_data command. For
example:

December 2017
DFTVisualizer
DftSpecification(cpu_top,rtl2) +{
IjtagNetwork +{
HostScanInterface(sri) +{
Interface {
design_instance : cpu_top_rtl_tessent_sib_sti_inst;
scan_interface : client;
}
Sib(sri) +{
Attributes {
tessent_dft_function : scan_resource_instrument_host;
}
Tdr(sri_ctrl) {
Attributes {
tessent_dft_function : scan_resource_instrument_dft_control;
}
}
Sib(occ) {
}
Sib(edt) {
}
}
}
}
EDT +{
Controller(c1) +{
Connections +{
EdtChannelsIn(1) {
port_pin_name : edt_channels_in[0];
}
EdtChannelsIn(2) {
}
EdtChannelsOut(1) {
port_pin_name : edt_channels_out[0];
}
EdtChannelsIn(3) {
}
EdtChannelsOut(2) {
}
EdtChannelsOut(3) {
}
}
}
}
}

December 2017
DFTVisualizer
Examples
Use the read_config_data command to save the modifications to the DFT specification into a
dofile for re-use.

EDT {
Controller (c1) {
Connections +{
EdtChannelsIn(1) {
}
EdtChannelsOut(1) {
}
EdtChannelsIn(3) {
}
EdtChannelsOut(2) {
}
EdtChannelsOut(3) {
}
}
}
}
}

December 2017
DFTVisualizer
DFTVisualizer Preferences
DFTVisualizer Preferences
DFTVisualizer allows you to customize your display and editing preferences.
Setting DFTVisualizer Preferences

You can customize the DFTVisualizer session in various ways according to your taste. You can
also save your preferences for use in subsequent sessions or to a special file that can be loaded
after DFTVisualizer is invoked.
You can do the following:
• Specify colors for display components.

• Add/remove toolbar components.
• Control text/data display.
• Specify editing behavior.
Prerequisites
Procedure
1. Select Edit > Preferences. The Global Preferences Dialog Box displays. Specify the
desired global session attributes.
2. Click the Colors tab. The Colors Preferences Dialog Box displays. Specify the desired
object colors.
3. Click the Schematics window tab. The Schematics Preferences Dialog Box displays.
Specify the desired attributes for the Flat Schematic Window, the Hierarchical
Schematic Window, or both.
4. Click the Attributes window tab. The Attributes Preferences Dialog Box displays.
Specify the desired object attributes to be displayed in the Flat Schematic Window and
Hierarchical Schematic Window.
5. Click the Browser Window tab. The Browser Window Preferences Dialog Box displays.
Specify the desired attributes for the Browser window.
6. Click the Data Window tab. The Data Window Preferences Dialog Box displays.
Specify the desired attributes for the Data window.

December 2017
DFTVisualizer
Saving/Loading Session Preferences
7. Click the Text Editor window tab. The Text Editor Window Preferences Dialog Box
displays. Specify the desired attributes for the Text Editor window.
8. When you have set the desired preferences, click OK.
Results
The specified settings take effect and remain persistent for the current DFT tool session only.
Related Topics

You can save specified DFTVisualizer preferences as the default settings used by all subsequent
DFT tool sessions or to a specified file that can be loaded by other users or as alternate set of
preferences. You can also use this procedure to set your preferences back to the system defaults.
Prerequisites
• New session preferences are selected. See Setting DFTVisualizer Preferences.
Procedure
1. Select Edit > Preferences. The Global Preferences Dialog Box displays.
2. Do one of the following:
Click... To...
Write Preferences Save the current settings as default.
Save Preference File Save the current settings to a specified file in the current
working directory. In the dialog box, specify a filename and
click OK.
Reset to System Defaults Change all preferences back to the systems defaults.
Related Topics
Setting DFTVisualizer Preferences

December 2017
DFTVisualizer
DFTVisualizer Preferences Dialog Box

The DFTVisualizer Preferences dialog box provides a series of tabs that allows you to set global
and color preferences as well as preferences for schematics, attributes, the browser and data
windows, and the text editor.
Global Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Colors Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Schematics Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Attributes Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Browser Window Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Data Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Text Editor Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

December 2017
DFTVisualizer
Global Preferences Dialog Box

To access: Select Edit > Preferences and click the Global tab.
The DFTVisualizer Preferences (Global tab) dialog box allows you to set preferences associated
with all display windows.

December 2017
DFTVisualizer
Fields
Field Description
Save Current Window Determines if window size and location are saved on exit and
Positioning (after writing used for the next DFTVisualizer session.
preferences)
Word Wrap Transcript Text Determines if words wrap to the next line approximately every
70 characters.
Automatically Cross Select Determines if objects you select are automatically cross selected
In All Windows in all windows in which they are already displayed. See Cross-
Selecting Objects for more information.
Toolbar Options Specifies which tool icons are available from the toolbar on the
top of the display.
Show Full Names Displays complete hierarchical pathname for each instance
when the instance is clicked with the right mouse button. Default
setting.
Show Partial Names By Specifies how many design levels display as part of instance
Only Showing The names. You can specify how many of the first or last design
(Levels): levels are omitted. By default, full names display.
Show Partial Names By Specifies how many characters display in instance names when
Only Showing The the instance is clicked with the right mouse button. By default,
(Characters): full names display.
Zoom Factor Specifies by what percentage a window magnifies when the
zoom option is used.
Load Preference File Loads settings from a specified preference file into the current
session.
Save Preference File Saves the current preference settings to a specified file.
Write Preferences Saves the current preference settings to a file named
.DftVisualizerrc in your home directory. Preferences for
subsequent tool sessions are read from this file by default.
Reset to System Defaults Resets all preference settings to the factory default settings.

December 2017
DFTVisualizer
Colors Preferences Dialog Box

To access: Select Edit > Preferences and click the Colors tab.
The DFTVisualizer Preferences (Colors tab) dialog box allows you to set color preferences for
backgrounds and graphical objects displayed in windows.

December 2017
DFTVisualizer
Fields
Field Description
Windows List Determines the window to which the Options List applies.
Options List Displays a list of graphical window elements that you can select
and specify a color for.
Color Palette Palette that indicates the current color selection for the object
type selected in the Windows List and Options List.
No. of Colors Specifies the number of colors that can be used to mark objects
in schematic windows (Flat and Hierarchical). This item is only
available when Marked is selected in the Options List.
Color Index Specifies a color to be used when marking objects. You can set
as many colors as are specified by the No. of Colors field. By
default, the following colors are used for marking:
• Mark color 1: Green
• Mark color 2: Blue
• Mark color 3: Orange
• Mark color 4: Yellow
• Mark color 5: Red
This item is only available when Marked is selected in the
Options List. For more information, see “Customizing Marking
Colors in the Schematic Windows” and “Marking and
Unmarking Objects in the Schematic Windows.”
Preview Area Displays the current display color settings for instances,
primitives (solid fill), marked objects, highlighted objects, and
selected objects.
Copy Colors To All Applies the colors currently defined for the selected window to
Windows all other windows.
Reset Colors To System Resets the color preferences for the currently selected window
Defaults to system defaults.

December 2017
DFTVisualizer
Schematics Preferences Dialog Box

To access: Select Edit > Preferences and click the Schematics tab.
The DFTVisualizer Preferences (Schematics tab) dialog box allows you to set preferences
associated with the Flat and Hierarchical Schematic Windows.

December 2017
DFTVisualizer
Objects
Field Window Description

Windows Flat/Hierarchical Indicates whether the changes specified in the
Schematic dialog box will be applied to the Flat Schematic
Window, Hierarchical Schematic Window, or to
both Flat and Hierarchical Schematic Windows.
Compact Inverters Flat/Hierarchical Global option that specifies whether buffers/
And Buffers Schematic inverters are collapsed (minus sign symbol) or
expanded (plus sign symbol). When enabled,
redundant buffers/inverters are collapsed and
omitted from the display; the next non-buffer/
non-inverter instance displays. It you see no
symbols, then no buffers or converters exist on
the net.
Require Confirmation Flat/Hierarchical Prompts for confirmation before a Delete All
Before Doing “Delete Schematic command is executed.
All”
Display Ports In Same Flat/Hierarchical Connects and displays ports exactly as specified
Order As Report Gate Schematic in the design netlist. By default, port
connections are flipped/manipulated when
possible to reduce clutter and optimize viewing.
“Highlight” Gates Flat/Hierarchical Determines whether gates added in trace mode
Added During Schematic display highlighted.
Tracing
Display Thick Lines Flat/Hierarchical Specifies to display all nets and instances on the
Schematic schematic with thick lines to improve visibility.
Enable Auto Panning Flat/Hierarchical During tracing as new objects are added outside
Schematic the window boundary, specifies to automatically
bring the new objects into view and, if possible,
also keep the original object in view.
Display Message On Flat/Hierarchical Enables/disables the echoing of
Marking Schematic mark_display_instances commands, initiated
through the graphical user interface, to the
transcript. By default, this option is enabled.
Maximum Number Of Flat/Hierarchical Specifies the maximum number of gates that can
Gates That Can Be Schematic added before prompting for confirmation.
Inserted Before Default is 500.
Requiring A
Confirmation
Number Of Undo/ Flat/Hierarchical Specifies how many levels of Undo/Redo can be
Redo Levels To Schematic recalled from memory. Default is 20.
Maintain

December 2017
DFTVisualizer
Field Window Description

Forward Trace All Pin Flat/Hierarchical Displays all levels of pin fanouts when a fanout
Fanouts Schematic marker is clicked.
Forward Trace One Flat/Hierarchical Displays one level of pin fanout when a fanout
Pin Fanout Schematic marker is clicked.
Show Instance Names Flat/Hierarchical Determines whether instance names are
Schematic displayed for each instance.
Show Full Names Flat/Hierarchical Displays complete hierarchical pathname for
Schematic each instance when the instance is clicked with
the right mouse button. Default setting.
Show Partial Names Flat/Hierarchical Specifies how many characters display in
By Only Showing Schematic instance names when the instance is clicked with
The: (Characters) the right mouse button. By default, full names
display.
Show Partial Names Flat Schematic Specifies how many design levels display as part
By Only Showing of instance names. You can specify how many
The: (Levels) of the first or last design levels are omitted. By
default, full names display.
Automatic Net Hierarchical Determines how many nets display during
Connection Schematic tracing. You can choose to display only
explicitly traced nets, a set number of nets, or all
nets.
Split Schematic Into Flat Schematic Determines whether the schematic is split into
Multiple Pages pages that display one at a time or displayed in
its entirety. By default, the schematic displays in
its entirety.
Show The First <32> Flat/Hierarchical Specifies the number of characters of simulation
Characters Of Schematic data that are to be displayed in the Flat
Simulation Data (0 to Schematic Window. Maximum number of
252) characters that can be displayed is 252. Default
is 32.
Display All Hierarchical Determines whether pins display when
Hierarchical Schematic hierarchical submodules are added to the
Submodule Pins schematic.
Except When Tracing
Display Net Names Hierarchical Determines whether net names display on the
On The Schematic Schematic schematic.

December 2017
DFTVisualizer
Attributes Preferences Dialog Box

To access: Select Edit > Preferences and click the Attributes tab.
The DFTVisualizer Preferences (Attributes tab) dialog box allows you to set display
preferences for object attributes in the Flat and Hierarchical Schematic Windows.

December 2017
DFTVisualizer
Fields
Field Description
Object Type Specifies the object type for which the registered attributes
are shown in the left list box. Object types available are:
• Module
• Instance
• Pin
• Net
• Gate_pin
• Port
Moves the selected attribute in the left list box to the
Displayed Attributes list box on the right. The attributes
listed in the Displayed Attributes list box will be displayed if
they are enabled globally. For more information, see
Working with Attributes.
Removes the selected attribute in the Displayed Attributes
list box on the right and places it back into the right list box.
The removed attribute will no longer be displayed.
Color Index Specifies the background color that will be used to highlight
the attribute currently selected in the Displayed Attributes
list box. The attributes shown in the Displayed Attributes list
box are displayed with the default or selected background
colors. Ten different background colors are available and
displayed with the Color Index value.

December 2017
DFTVisualizer
Browser Window Preferences Dialog Box

To access: Select Edit > Preferences and click the Browser Window tab.
The DFTVisualizer Preferences (Browser Window tab) dialog box allows you to set preferences
associated with the Design Browser Window.

December 2017
DFTVisualizer
Objects
Field Description
Show Primitives Determines if primitives can be displayed.
Show Hierarchical Data For Determines if the Library, Hierarchy, and Clock tabs of
Library Models the Browser window display the fault data beneath library
instances. When the fault data is shown as “Hidden” in the
Browser window, you can show the fault data by clicking
the right mouse button on the library instance and selecting
Show Hierarchical Data from the popup menu. Note that
the additional data may impact performance on large
designs. Similarly, you can use the right mouse button
option Hide Hierarchical Data to reduce the displayed data
and improve performance.
Display Unlisted Faults Specifies to include or exclude faults statistics for graybox
instances that are not in the netlist (unlisted faults) from the
statistical display of Browser data. Excluding unlisted faults
from fault statistic calculations updates coverage
calculations for both the graybox and all higher levels in the
hierarchy whose statistics would normally include the
graybox’s statistics.
Color The Cell When The Determines whether the part of the selection indicator in a
Right Mouse Button Is Pressed data column cell displays highlighted when selected with a
right mouse button press.
Display Coverage Data Determines whether test/fault coverage data displays as a
bar graph (graphically) or as text number.
Show Coverage Data above Determines the display color for test coverage, fault
nn % in Green coverage, and ATPG effectiveness columns. Values above
the specified percentage display in green, and values equal
to or below the specified percentage display in red. Note,
this setting does not affect the display of the Test Coverage
Loss column which always displays in red.
Display Faults Determines whether fault data displays as a bar graph
(graphically) and a text number or text number only.
Align Instance Names Determines whether the instance names display left or right
justified.
Align Data Determines whether data associated with instance names
display left or right justified in the columns.
Data Column Width Specifies the number of characters visible in the data
columns. By default 50 characters display.

December 2017
DFTVisualizer
Data Window Preferences Dialog Box

To access: Select Edit > Preferences and click the Data Window tab.
The DFTVisualizer Preferences (Data Window tab) dialog box allows you to set preferences
associated with the Data window.

December 2017
DFTVisualizer
Objects
Field Description
Align Names Determines whether the names display left or right justified.
Align Data Determines whether data associated with names display left or
right justified in their columns.
Data Column Width Specifies the number of characters visible in the data columns.
By default 50 characters display.

December 2017
DFTVisualizer
Text Editor Window Preferences Dialog Box

To access: Select Edit > Preferences and click the Text Editor Window tab.
The DFTVisualizer Preferences (Text Editor Window tab) dialog box allows you to set
preferences associated with the Text Editor window.

December 2017
DFTVisualizer
Objects
Field Description
Key Stroke Mode Determines whether key strokes are interpreted to be Vi,
Emacs, or Design Pad commands.
Font Size Specifies the font size used to display the contents of the
window:
• Small — 10
• Medium — 13
• Large — 16
• X-Large — 19
Window State Specifies how windows display in the DFTVisualizer main
window:
• Tabbed — Windows align side by side and are accessed
using a Tab at the bottom of the window. This is the
default.
• Cascaded — Windows stack with the top portion of each
window visible.
Maximum Number of Design Specifies the maximum number of files that will be opened in
Files to Open at a Time the Text Editor window when File > Open > Current Design
Files is selected.
Write Preferences Saves the current preference settings to a file named
.DftVisualizerrc in your home directory. Preferences for
subsequent tool sessions are read from this file by default.

December 2017
DFTVisualizer
DFTVisualizer Windows
DFTVisualizer Windows
DFTVisualizer consists of many windows that you use for specific tasks, such as browsing the
design or performing global searches.
DFTVisualizer remembers the current window configuration when you exit the tool. The last
view of the tool is remembered and restored when the tool is re-invoked. Changes to the
configuration such as the addition of a new window are automatically added to the
configuration and remembered when the tool is next invoked.
Objects Added to DFTVisualizer Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Design Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Flat Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Console Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Objects Added to DFTVisualizer Windows

When you add an object to the Flat/Hierarchical Schematic or Data window, you can refer to the
object by either the hierarchical name (such as the port of a submodule, a net name, etc.) or the
flattened model name.
The following table shows what will be added when you add a particular type of object to these
windows.
Table 7-5. What is Added to the Flat/Hierarchical Schematic and Data
Windows
Type of Object Flat Schematic Hierarchical Data Window
Window Schematic Window
Library level instance Instance Instance All pins on instance
Pin on library Instance Instance Specified instance pin
instance
Bus on library Instance Instance Specified bus
instance

December 2017
DFTVisualizer
Objects Added to DFTVisualizer Windows
Table 7-5. What is Added to the Flat/Hierarchical Schematic and Data

Windows (cont.)
Type of Object Flat Schematic Hierarchical Data Window
Window Schematic Window
Primitive (gate ID) Primitive (if gate Instance the primitive All pins on primitive
level set to primitive) is a part of
Design level instance
the primitive is a part
of (if gate level set to
design)
Pin on Primitive Primitive (if gate Instance the primitive Pin on primitive
level set to primitive) is a part of
Design level instance
the primitive is a part
of (if gate level set to
design)
Hierarchical instance Not supported Hierarchical instance All ports on the
(submodule) hierarchical instance
Port on hierarchical Library level instance Hierarchical instance Port on hierarchical
instance driven by the port instance
(like report_gates)
Bus port on Library level instance Hierarchical instance Bus on hierarchical
hierarchical instance driven by all members instance
of the bus
Net (wire) Library level instance Instance driving the Net
driving the net (like net (hierarchical)
report_gates)
Bus (wire) Library level instance Instance driving the Bus
driving the bus bus (hierarchical)

December 2017
DFTVisualizer

To access: The Design Browser window is opened by default when DFTVisualizer is invoked.
The Design Browser window provides access to the Instance, Library, Clock, and DRC
Violations tabs, as well as the Signal pane. The Design Browser with the Library tab selected
and the Signals pane collapsed is shown in the following figure.
Figure 7-9. Design Browser Tabbed Window
Description
These windows provide the following capabilities:
• Instance tab— Enables you to navigate through the design hierarchy and view coverage
and fault statistics.
• Library tab — Displays statistics for the ATPG library models used in a design.
• Clock tab — Displays all of the clocks in the design and their attributes in a descending
order of test coverage. Clocks and their attributes are displayed from all modes. The
Clock Browser allows you to navigate the design hierarchy and view the faults for each
individual clock and analyze the distribution of faults between clock domains.
• DRC Violations tab — Displays DRC Violations in a tree format, separating DRC
violations by severity, ID and instance. Double clicking the instance level of the DRC
violation invokes analyze_drc_violation and displays the instance in the Flat Schematic
window for further investigation.

December 2017
DFTVisualizer
• Signals pane — Displays ports and fault data for instances selected in the Instance,
Library or Clock Browsers.
Objects
The table below lists the icons used in the Browser window to represent different instance types:
Table 7-6. Design Browser Window Instance Type Icons
Symbol Means the Instance is a...
Clock
Submodule (instance of a Verilog module)
Netlist/Verilog primitive
Library level instance
Library model (Library tab only)
Graybox, parent
Graybox, instances in netlist
Graybox, instances not in netlist
Library level instance containing one or more RAMs/ROMs
Library level instance containing one or more scan cells
Blackboxed instance
Primitive
Usage Notes for the Design Browser Window

Add additional data columns to the Instance, Library, and Clock Browsers using the
add_browser_data command, the Data pulldown menu and/or the toolbar buttons that are
described in the following table. Menu options are disabled (grayed-out) if corresponding data
is unavailable.
Table 7-7. Design Browser Window Data Menu Choices
Button Data Menu Description
Gates Total number of library level instances, including
submodules.
Primitives Total number of primitives, including
submodules.
Total Faults Total number and percentage of faults, including
submodules.

December 2017
DFTVisualizer
Table 7-7. Design Browser Window Data Menu Choices (cont.)

Faults > Add All | Delete All Number of faults for each available class; adds a
column for each class.
N/A Faults > <type> Number of faults for a specific class. Each class
can be expanded to display columns for each of
its subclasses. For information on fault
subclasses, see the set_relevant_coverage
command in the Tessent Shell Reference Manual.
Coverage Data > Test Test coverage for each submodule. In the Library
Coverage Browser, test coverage data includes two
subcolumns:
• Max: highest test coverage achieved for any
instance of the library model.
• Avg: average test coverage achieved for all
instances of the library model.
Coverage Data > Relevant Test coverage for each submodule after untestable
Test Coverage faults have been added/deleted from test coverage
calculations. For more information, see the
set_relevant_coverage and report_statistics
commands in the Tessent Shell Reference
Manual.
Coverage Data > Test Test coverage loss is the undetected faults in an
Coverage Loss instance displayed as a percentage of the testable
faults in the entire design.
Coverage Data > Fault Fault coverage for each submodule. In the Library
Coverage Browser, fault coverage data includes two
subcolumns:
• Max: highest fault coverage achieved for any
instance of the library model.
• Avg: average fault coverage achieved for all
instances of the library model.
Coverage Data > ATPG ATPG effectiveness for each submodule.
Effectiveness
Clock Attributes Clock attributes such as off state, constraints, and
internal/external clock.

December 2017
DFTVisualizer
Table 7-7. Design Browser Window Data Menu Choices (cont.)

N/A Optimized NCPs (Named Capture Procedures)
display in the Wave window. To see unoptimized
NCPs, click the UOP icon.
Note: This icon is only available after you have
selected a NCP to view using the Data > Named
Capture menu; only NCPs defined in the test
procedure file are available from this menu.
N/A Unoptimized NCPs display in the Wave window.
To see optimized named capture procedures, click
the OP icon.
Note: This icon is only available after you have
selected a NCP to view using the Data > Named
Capture menu.
• The features are summarized as follows:
o View subclasses of faults by clicking in the column header of the fault type. A
new column is added for each subclass. For undetected fault classes (AU, UC, and
UO), percentage numbers displayed in the column represent the percentage of the
design not tested as a result of the fault.
o Report or write all faults for a particular instance by selecting the instance, clicking
the right mouse button, and selecting Commands > Report_Faults | Write_Faults
from the popup menu. Note, you can report/write unlisted faults for graybox
instances separately by clicking on the graybox instance, or you can select the parent
instance and report/write all listed and unlisted faults together.
o Use File > Save As or click to save a text, comma separated value (CSV), or
graphical version (screen capture) of the displayed contents of the Browser window
to a file.
o Statistics data displays only for submodules, not library level instances or primitives.
Be aware that when you display data, there is some processing time overhead
(progress of which you can check in the progress bar).
o If the data in a column becomes invalid due to the state of the tool, that column
becomes unavailable and the Refresh Data menu item on the Data menu is enabled.
For example, if test coverage data is displayed and you create additional patterns, the
test coverage column will no longer be available. Pushing the refresh button
regenerates the data. The data will always match what is reported by commands like
report_statistics and report_drc_rules.
o To make the display easier to read when viewing statistics, you can group all library
level instances into the artificial level of hierarchy called $$Gates$$. To enable
instance grouping, select the Display > Group Instances > On menu item.

December 2017
DFTVisualizer
o The Instance, Library and Clock tabs of the Design Browser work together with the
Signal Browser, allowing you to browse, select ports and examine fault data for the
instance selected in the Design Browser.
o Copy an object’s hierarchical pathname into a buffer which you can then paste into
another location by selecting the object(s) and choosing “<object_name(s)> (click to
copy)” from the popup menu. For more information, see “Copying and Pasting
Object Names in the Design.”
Usage Notes for the Instance Browser
• From the DFTVisualizer Design Brower, click the Instance tab. By default, the Instance
Browser displays the following columns:
o Instance — The name of the instance in the netlist. Instances of primitives include
their gate ID. Instance types are shown with the icons listed in Table 4-7.
o Module — The name of the Verilog module, ATPG library model, or primitive type
that the instance is instantiated from.
o Child Instances — Number of instances at this level of hierarchy. Does not include
the number of instances within each submodule.
• In the Instance Browser:
o Click the plus sign (+) next to an instance to display the gates and primitives for that
individual instance.
o Double-click on any instance to automatically expand/collapse it.
o Click the right mouse button and use the View In popup menu option to add an
object to another window.
o Click the right mouse button over an object in hierarchy and use the View in Text
Editor popup menu option to view the Verilog definition or instantiation for the
instance in a Text Editor.
graphical version (screen capture) of the Instance Browser contents to a file.
Usage Notes for the Library Browser
• From the DFTVisualizer Design Brower, click the Library tab. By default, the Library
Browser displays the following columns:
o Library Model — Cell library models used in the design.
o Number of Instances — Number of instances in the design that use this library
model.
• In the Library Browser:
o Click on the (+) next to a library model to display statistics for the individual
instances of the model in the design.

December 2017
DFTVisualizer
o Click the right mouse button over an object and use the View In popup menu option
to add an object to another window.
o Click the right mouse button over an object and use the View in > Text Editor
(Definition) popup menu option to view the Verilog definition for the instance in a
Text Editor.
graphical version (screen capture) of the displayed contents of the Library Browser
to a file.
Figure 7-10. Design Browser Window with Library Tab Active
Usage Notes for the Clock Browser

• From the DFTVisualizer Design Brower, click the Clock tab. By default, the Clock Browser
displays the Clock column. The description of this column, and other columns that can be
displayed in the Clock Browser are as follows:
o Clock — The name of a clock in the design. Instance types are shown with the icons
listed in Table 4-7. This column is displayed by default.
o Attributes — The attributes of each individual clock as reported by the report_clocks
command. Specifically, the subcolumns Off State, Constraint, and Internal are
displayed. The Attributes column can be displayed by selecting Data > Clock
Attributes from the menu, or by clicking the icon.
o Fault Types — The faults from each fault type for each clock domain in the design
can be displayed by selecting Data > Faults > Add All from the menu, or by

December 2017
DFTVisualizer
clicking the icon. Specific fault types can be displayed by selecting them from the
Data > Faults menu.
o Faults — The total of all fault types, expressed as a number and a percentage of the
design total, for each clock domain in the design. The Faults column can be
displayed by selecting Data > Total Faults from the menu, or by clicking the
icon.
Note
If a fault is in multiple clock domains, the fault is attributed to each clock
domain. Because of this, it is possible that the sum of all fault percentages (faults
in a clock domain as a percent of the total faults in the design) can exceed 100%.
o Test Coverage — Percentage of all testable faults detected by a pattern set for a
particular clock domain. The Test Coverage column is displayed by selecting Data >
Coverage_Data > Test Coverage from the menu, or by clicking the icon.
o TC Loss — Test coverage loss is the undetected faults for a clock domain displayed
as a percentage of the testable faults in the entire design. The TC Loss column is
displayed by selecting Data > Coverage_Data > TC_Loss from the menu, or by
clicking the icon.
o Fault Coverage — Percentage of fault coverage for each clock domain. The Fault
Coverage column is displayed by selecting Data > Coverage_Data > Fault
Coverage from the menu, or by clicking the icon.
o ATPG Eff — ATPG effectiveness for each clock domain instance. The ATPG Eff
column is displayed by selecting Data > Coverage_Data > ATPG_ Eff. from the
menu, or by clicking the icon.
• In the Clock Browser:

o Click on the (+) next to a clock to display statistics of the individual instances for
each clock in the design. Only instances with faults in the expanded clock domain
are displayed.
o Click the right mouse popup menu and use the View In option to add an object to
another window.
o Click the right mouse button over an object in the clock’s hierarchy and use the
View in Text Editor popup menu option to view the Verilog definition of the
instance in a Text Editor.
graphical version (screen capture) of the displayed contents of the Clock Browser to
a file.

December 2017
DFTVisualizer
Usage Notes for the DRC Violations Browser

The displaying of DRC Violations can be grouped and filtered as needed to isolate information
of interest.
• Grouping of DRC Violations
DRC violation grouping can be selected using the Group By dropdown list as shown in the
figure below.
Figure 7-11. DRC Violation Browser
The grouping selections available are as follows:

o Severity — Lists DRC violations sorted by severity, such as “warning” and “error”.
o Rule — Lists DRC violations sorted by which rule was violated, such as “T3” or
“A6”.
o Instance — Lists DRC violations sorted by design instances where violations were
detected.
o Module — Lists DRC violations sorted by design modules where violations were
detected.
o File — Lists DRC violations sorted by the library files where violations were
detected.
• Filtering of DRC Violations
DRC violations can be filtered to further isolate the items of interest in the displayed list.
The Filter dialog box and In dropdown list, as shown in Figure 7-11, are used to specify the
filtering that is to be applied.
The Filter dialog box requires glob-compatible case-sensitive patterns to be entered. Zero
or more characters are matched with “*”, and single characters are matched with “?”. For
example, entering Filter C? In Rule will match all occurrences of rule violations that start
with “C” and are followed by any character. Exact matches can be entered as well, for
example entering Filter T3 In Rule will match all T3 rule violations.
The In dropdown list specifies to which reported fields the filter will be applied. Available
selections are as follows:
o Rule — The type of rule that was violated, for example T3 or T5.

December 2017
DFTVisualizer
o Rule Description — The generic description field for the rule.

o Severity — warning or error.
o Violation ID — The sequential identifier field of a rule violation type, for example
T3-1 or T5-1.
o Violation Message — The specific description field for the rule violation.
Usage Notes for the Signals Browser
From the DFTVisualizer Design Brower, click at the top of the Signals pane to open the
Signals Browser. To close the Signals Browser, click at the top of the Signals Browser pane.
• The Signals Browser displays the following columns:
o Name — Displays the pin names of the instance selected in the Instance, Library or
Clock Browsers. No data will be displayed if multiple instances are selected.
o Fault Class — Displays any fault data associated with the pin listed in the Name
column. Fault types of stuck, transition and toggle are displayed. The checkbox in
the Fault Class column header will hide/unhide the fault data in the Signal Browser.
• In the Signals Browser:
o Show the names of individual bus pins by clicking the plus sign (+) next to the bus’s
name. To remove the names of individual bus pins, click the minus sign (-) next to
the bus’s name. As an alternative, double-clicking a bus name will alternate between
expanding and collapsing the list of individual bus pin names.
o Click the right mouse button over a pin name and use the View In popup menu
option to add the instance to another window.
o Click the right mouse button over a pin name and use the Cross Select popup menu
option to select the pin in other windows
o Click the right mouse button over a pin name and select Commands >
report_faults to do report_faults on the selected pin.
o Double-click, or click the right mouse button over a fault data row and select
Commands > analyze_faults to do analyze_fault on the selected fault data row.
Related Topics
Data Window
Hierarchical Schematic Window
write_window_contents [Tessent Shell Reference Manual]

December 2017
DFTVisualizer
Data Window
Data Window
To access: Choose the Windows > Data menu item or click the icon.
The Data window provides a tabular presentation of the report_gates command output that
allows you to see data for multiple instances and multiple data sets at the same time.
Figure 7-12. Data Window
Characteristics
• Add any type of instance (submodule, library level instance, primitive) or signal (submodule
port, instance port, wire) to the Data window using any of the following methods:
o Select an instance from another window and use the View In option on the right
mouse button menu.
o Use a command that adds named instances to the display (add_display_instances for
example).
o Click the Add Instances icon on the tool bar. The Make Additions to the Display
dialog box displays. You can use any number of asterisks (*) or question marks(?) as
wildcard characters to specify the string enabling you to match many pathnames in
the design.
• Delete instances or signals from the Data window by first selecting them and then using any
of the following methods:
o Select the Display > Delete menu item.
o Select Delete from the right mouse button popup menu in the window’s display area.
o Click the Delete Selected icon or the Delete All icon.
o Press the Delete key.

December 2017
DFTVisualizer
Data Window
• The following features are available:

o Display data in the Data window by using the Data pulldown menu, the
corresponding buttons on the tool bar, or a command that adds data to the display
(add_display_data for example).
o Display NCP data in the Data window by using the Data > Capture Procedure
pulldown menu item, or by executing the add_display_data capture_procedure
command from the console window.
o Remove data from the Data window by moving the cursor over the column header
you want to delete and selecting the column to delete from the right mouse button
popup menu.
o Re-add data you have removed from the Data window by moving the cursor over
any column header and selecting the column to re-add from the right mouse button
popup menu.
o View the data for cycles that are out of view in a long test_setup procedure by using
the Display > Test_Setup menu item (or Test_Setup from the right mouse popup
menu in the window’s display area) to display the Display Test Setup Data dialog
box.
Tip
To maintain the usefulness of the displayed data, the tool intentionally displays a
maximum of 10 cycles in the Data window regardless of the number of cycles
entered into the From/To fields. If you need to see more than 10 cycles, you should
view the data in the Wave window.
o Display scan test patterns or chain test patterns by using the Data > Pattern Index
menu item to display the Display Pattern Index Data dialog box. Note, the Chain
Test option is only available after you have saved the scan test patterns.

December 2017
DFTVisualizer
Data Window
o Open the Test_end procedure in a text editor by selecting Data > Test-End to
display the drc test_end column; then, click the left mouse button on the column
header.
o Display stable value data by selecting one of the Data > Stable menu items. This
action executes the set_gate_report command with one of the STABLE_After_setup
| STABLE_Capture | STABLE_Load_unload | STABLE_Shift options enabled or
disabled. You can also access stable value data by clicking the following toolbar
icons: Stable After Test_Setup , Stable During Capture , Stable During
Load_Unload , and Stable During Shift .
o Copy an object’s hierarchical pathname into a buffer which you can then paste into
copy)” from the popup menu. For more information, see “Copying and Pasting
Object Names in the Design.”
o If the Data window is detached from and hidden behind the main window, click the
icon to bring the window back to the front.
graphical version (screen capture) of the displayed contents of the Data window to a
file. If you specify Text format, the contents of the Data window including the
column headers are output to a .txt file.
Related Topics

December 2017
DFTVisualizer

To access: Choose the Windows > Flat Schematic menu item or click the icon.
The Flat Schematic window displays a schematic representation of the flattened design as well
as simulation data. For more information about flattening, refer to the .
Figure 7-13. Flat Schematic Window
Objects
The Flat Schematic window contains the following objects:
Objects Location Description
Progress Bar Status bar Shows the percentage of the design that has been
loaded.
Selected Instance Status bar Shows the type of the selected instance (submodule or
design level gate) and its path and name.
Number of Status bar Shows the number of instances in the display and, of
Instances those, the number selected.
Displayed
(Selected)

December 2017
DFTVisualizer
Objects Location Description

Gate Level Setting Status bar Indicates the gate level setting. The schematic is
presented at design level by default but can be shown
at primitive level (controlled by Display > Gate Level
or Ctrl + L). See “How to Set the Level of Gate Data”
Sheet Number Status bar Enables you to navigate to a specific sheet by entering
Entry Box the new sheet number in the entry-box. Also displays
the current sheet number and the total sheet count.
Reporting Status Status bar Shows the current gate report setting.
Solid-filled Object Schematic Indicates a primitive.
area
Unfilled Instance Schematic Indicates a library instance that can be expanded in
area place (by double-clicking) to show its primitives.
Callout Schematic Indicates an expandable marker on the schematic
area associated with a specific instance. The marker
expands into a text box that displays information about
the object that helps in debugging issues such as DRC
violations and simulation mismatches. For information
about annotation of schematic data, see “Annotation of
Schematic Data in the Schematic Windows”.
Off Page Connector Schematic Enables you to trace between sheets when the
area schematic is split into multiple sheets. Double-click the
connector on the net at the very right or very left of the
schematic.
Usage Notes
• Add instances to the Flat Schematic Window using any of the methods described in
“Adding Instances to the Current Display Window.”
• Select objects in the Flat Schematic Window using any of the methods described in
“Selecting Multiple Objects in the Flat and Hierarchical Schematic Windows.”
• View the library primitives of a specific instance in the Flat Schematic Window from
design level by double-clicking on the instance. The instance expands to show the
library primitives and is surrounded by a bounding box. Note, the progress bar in the
lower-left of the Flat Schematic Window indicates the progress of the expand operation.
Double-click on the bounding box, to return to the instance view. Selecting Display >
Gate Level > Primitive displays the primitives of the whole schematic sheet.

December 2017
DFTVisualizer
• Toggle the display of debugging information utilizing callout markers on

schematic objects as follows:
o View the information in a callout (without expanding it) by hovering the mouse over
the callout marker.
o Expand a callout by clicking the callout marker using the left mouse button.
o Move a callout box by pressing the Shift key and using the right mouse button to
drag the box to a new location.
o Close a callout by clicking the in the upper right corner of the callout box using
the left mouse button.
• View additional data in the Flat Schematic Window by using the following options:
o View Test_end data by selecting Data > Test-End. This action executes the
set_gate_report command with the test_end option enabled or disabled.
o Toggle the display of false paths on or off by clicking the Timing Exceptions
icon or selecting Data > Timing Exceptions On | Off. These actions execute the
set_gate_report command with the -timing_exceptions option enabled or disabled.
o Display faults by entering the add_faults command.
o Display timing-aware data by selecting Data > Delay Data.
o Display K19 and K22 simulation data by selecting Data > K19 | K22. This action
executes the set_gate_report command with the K19 or K22 option enabled.
o Display Named Capture Procedure simulation values by selecting Data > Capture
Procedure or by executing the set_gate_report capture_procedure command from
the console window; both methods report the value on each pin implied by the
forced and conditional assignments defined in the specified named capture
procedure (NCP).
o Display simulation values for a specific simulation context by selecting Data >
Simulation Context or by executing the “set_gate_report simulation_context”
command from the console window; both methods report the simulated values for
the current simulation context.
o Display stable value data by selecting one of the Data > Stable menu items. This
action executes the set_gate_report command with one of the STABLE_After_setup
| STABLE_Capture | STABLE_Load_unload | STABLE_Shift options enabled or
disabled. You can also access stable value data by clicking the following toolbar
icons: Stable After Test_Setup , Stable During Capture , Stable During
Load_Unload , and Stable During Shift .

December 2017
DFTVisualizer
o Display scan test patterns or chain test patterns, by selecting Data > Pattern Index
to display the Display Pattern Index Data dialog box. Note, the Chain Test option is
only available after you have saved the scan test patterns.
o Display additional types of available data by selecting the Data pulldown menu, the
corresponding buttons on the tool bar, or the set_gate_report command.
• Copy an object’s hierarchical pathname into a buffer which you can then paste into
copy)” from the popup menu. For more information, see “Copying and Pasting Object
Names in the Design.”
• Access information about navigating schematics in the Flat Schematic Window by
referring to Tracing Signal Paths on a Schematic. In addition to tracing methods, this
section also covers:
o Compaction of Buffers and Inverters in Traced Circuitry
o Annotation of Schematic Data in the Schematic Windows
• To help improve performance, the schematic is automatically divided into multiple
sheets when too many instances are visible. To navigate to a specific sheet enter its
number in the sheet number entry box. To continue a trace to another sheet, double-click
the marker on the net at the very right or very left of the schematic.
• In Tessent Diagnosis, use the Tools > Diagnosis Report menu item to display diagnosis
suspects on a schematic. Refer to “Displaying Suspects in the Schematic View” in the
Tessent Diagnosis User’s Manual for complete information.
• If the Flat Schematic Window is detached from and hidden behind the main window,
click the icon to bring the window back to the front.
Related Topics
Data Window

December 2017
DFTVisualizer

To access: Choose the Windows > Design menu item or click the icon.
The Hierarchical Schematic Window displays a hierarchical schematic of the design as
described in the input netlist. The display includes net names and hierarchical ports displayed
down to library level instances, and at every hierarchical boundary it shows the number of
instances inside each hierarchical instance. The display also shows the connections of
individual bus bits.
Note
When using this window, `celldefines are not visible.
Figure 7-14. Hierarchical Schematic Window
Objects
The status bar below the Hierarchical Schematic Window contains the following contents:
Window Area Description
Selected Instance Shows the type of a selected instance (submodule or design level
gate) and its name.
Number of Instances Shows the number of instances being displayed (and how many
Displayed (Selected) of that number are currently selected).

December 2017
DFTVisualizer

Net Bundling Status Shows whether net bundling (displaying nets connected between
the same instances as single thick lines) is enabled. Controlled by
Display > Net Bundle menu item.
Sheet Number Entry Box The Hierarchical Schematic supports a single schematic sheet
and will display “1 of 1”. The multiple sheet feature is used by
the Flat Schematic.
Usage Notes
• Add instances to the Hierarchical Schematic Window using any of the methods
described in Adding Instances to the Current Display Window.
Note
From the Design Browser, you can add all top-level instances to the Hierarchical
Schematic Window using the popup View In > Hierarchical Schematic menu item
on the design’s top hierarchy. This issues the “add_display_instances / -display
hierarchical_schematic -down” command which displays all top-level instances of the
design and their interconnecting nets; the top-level ports are represented by port
symbols. If you want to only see the top-level port symbols instead of the expanded top-
level design, you can do this by using the “add_display_instances / -display
hierarchical_schematic” command.
• Select objects in the Hierarchical Schematic Window using any of the methods
described in Selecting Multiple Objects in the Flat and Hierarchical Schematic
Windows.
• Expand an instance in the Hierarchical Schematic Window by double-clicking on the
instance. The instance expands to show the lower-level instances and is surrounded by a
bounding box. Double-click on the bounding box, to return to the instance view.
• Access information about navigating a schematic in the Hierarchical Schematic Window
by referring to:
o Tracing Signal Paths on a Schematic
o Signal Path Tracing in the Hierarchical Schematic Window
• To help improve performance, the schematic is automatically divided into multiple
sheets when too many instances are visible. To navigate to a specific sheet enter its
number in the sheet number entry box. To continue a trace to another sheet, double-click
the marker on the net at the very right or very left of the schematic.

December 2017
DFTVisualizer
• If the Hierarchical Schematic Window is detached from and hidden behind the main
window, click the icon to bring the window back to the front.
Related Topics
Data Window

December 2017
DFTVisualizer

To access:
• From DFTVisualizer, choose Windows > Configuration Data from the pulldown
menu or click the icon.
• From the command line within a tool session, enter the following command:
• open_visualizer -display configuration_data
• To automatically load existing configuration data from the command line within a tool
session, enter the following command:
• read_config_data <configuration_file_name>
display_configuration
The Configuration Data window provides you with a graphical interface to view specifications
and to modify the configuration tree elements and their options.
Figure 7-15. Configuration Data Window
Objects
• The Configuration Data window provides the following capabilities:
o Configuration Tree — Enables navigation and modification of the entire
specification hierarchy. Displays a tab for each defined specification. You perform
most operations in this panel by clicking the right mouse button and selecting from
the available menu options as described in Table 7-8.
o Configuration Options — Displays options for the element selected in the
Configuration Tree panel. The content of the Configuration Options tab is specific to
the element selected in the Configuration Tree panel. The options displayed in this
panel are defined for the element type in the DftSpecification. For example, the
options displayed in this panel for the Sib are defined in the Sib wrapper of the
DftSpecification; the options available for the interface of the Sib are defined in
the Sib/Interface wrapper of the DftSpecification.

December 2017
DFTVisualizer
The Configuration Data window uses the following toolbar icons:

Table 7-8. Configuration Data Window Icons
Icon Description
Validates the current specification and reports any errors. This icon
skips Dft element generation and insertion. This action is equivalent to
issuing the “process_dft_specification -validate_only” command.
Executes the current specification by generating the Dft components
such as the RTL and the ICL description, and inserting them into the
design. This action is equivalent to issuing the
process_dft_specification command.
Usage Notes for the Configuration Tree
You can access the following options in the Configuration Tree by clicking the right mouse
button and selecting a menu item:
Menu Item Description
Move Up | Move Down Moves the selected element up or down within the configuration
tree.
Cut | Copy | Paste Cuts or copies a selected element, or pastes a previously cut or
copied element. This is a time-saving feature that allows you to
create new elements faster by using existing elements as a
starting point. Once you copy and paste a new element in the
Configuration Tree, you can customize it in the Configuration
Options panel.
Expand | Collapse Expands or collapses the selected tree hierarchy.
Add | Delete Creates a new element or deletes existing ones. The Add sub-
menu is a context-sensitive list of elements that can be legally
added under the selected element. For example, several
elements such as a SIB, TDR, ScanMux, or design element can
be added to an existing SIB but only Inputs can be added to a
ScanMux. The tool only lists the valid elements based on the
selected element.
Config Options Displays the Configuration Options panel if it is not visible.
Close Tab Closes the current tab in the Configuration Tree. Closing the tab
does not delete the specification or in any way modify it in tool
memory; it simply removes it from display.
Usage Notes for the Configuration Options
The options displayed in the Configuration Options panel are defined for the element type in the
DftSpecification. For example, the options displayed in the Configuration Options panel for the
Sib are defined in the Sib wrapper of the DftSpecification; the options available for the interface
of the Sib are defined in the Sib/Interface wrapper of the DftSpecification.

December 2017
DFTVisualizer
• Specify the parameters of the newly added element in the Configuration Options panel as
follows:
o When entering the values of the element’s listed options, use the icon to select
from pre-defined values for that element.
o Click to define parameters of the element’s interface.
o Click and to define the number of ports on the element,

their names, and connections.
o Click to define arbitrary attributes on the element’s ICL module.
• In the Configuration Options panel:

o Default option values are shown in gray text.
o User-defined option values display in black text.
o Changes you make to the options are not saved until you click the Apply button. If
you make changes and do not click the Apply button before leaving the panel, the
tool displays a dialog box to confirm whether you want to save or discard the
changes.
Related Topics

December 2017
DFTVisualizer
Global Search Window

To access: Choose Windows > Global Search or click the Search icon .
Use the Global Search window to search for any instance, net, or pin in the design.
Note
You can use the Find icon on the menu bar to specify a search that is limited to the active
window.
Figure 7-16. Global Search Window
Characteristics
• The following features are available:
o Enter a string in the Global Search text entry box to search for any occurrence of that
string. No wildcards are needed. The tool returns every instance of that string in any
pathname of the active design as shown in Figure 7-16. Alternatively, you can
enable the Exact Search field to disable the use of implicit wildcards and only search
for the exact string.
o Click the icon next to the search field to display a search history.
o Click the Options button to toggle the display of additional search parameters as
shown on the right of Figure 7-16.
o Click on a result to copy it to the copy/paste buffer.

December 2017
DFTVisualizer
Note
You can cancel the search operation by clicking Cancel in the Global Search
dialog box. The Cancel button displays when the search operation starts to
display results; you may not see the button unless the Limit Displayed Matches To:
field is set to a large number.
o Select an object(s) and choose the View In > menu item from the popup menu to
view objects in one or more other windows. You can select multiple objects by
holding down the Shift key while clicking on the objects you want to select; when
you release the Shift key, the set of objects you clicked on remains selected and
available to View in another window.
o If the Global Search window is detached from and hidden behind the main window,
graphical version (screen capture) of the Global Search window contents to a file.

December 2017
DFTVisualizer
Test Structures Window

To access:
• From DFTVisualizer, choose Windows > Test Structures from the DFTVisualizer
pulldown menu or click the icon.
• From the command line within a tool session, enter the following command:
• open_visualizer -display test_structures
The Test Structures window allows you to visualize and debug EDT logic.
Characteristics
• You can use the Test Structures window to do the following:
o Browse a virtual graphical representation of the EDT logic as shown in Figure 7-17.
To display actual net and pin mapping information graphically, you must add the
EDT component to the Flat or Hierarchical Schematic Window.
o Display textual information about components within the EDT logic.
o Debug DRC violations related to the EDT logic.
Note
You must first run set_edt_finder on a design to gather EDT logic information
before you can view it in the Test Structures window. You can then view EDT
logic in the Test Structures window at any time prior to test pattern generation; EDT
Finder data is not preserved during ATPG.
Figure 7-17. Test Structures Window
Usage Notes
• Double-click graphic blocks to descend down and display internal components.
• Click on graphic objects to display information about the object in the text pane.

December 2017
DFTVisualizer
• Click callout boxes on graphic objects to toggle the display of DRC analysis
information. Press the Shift key and use the right mouse button to move the callout box
markers.
• Click on the plus sign preceding a device in the text pane to expand text to include
device pin information.
• Double-click on a device in the text pane to display it in the Hierarchical Schematic
Window.
• Search/Filter the contents of the text pane as follows: Click in the top of a text pane
column, type a term to search/filter on, and click on the binoculars. The contents of the
column is filtered so the specified term displays at the top. Click the magnifying glass at
the top of the first column to clear all filter entries.
another location, by selecting the object(s) and choosing “<object_name(s)> (click to
• If the Test Structures window is detached from and hidden behind the main window,

December 2017
DFTVisualizer
Text Editor Window
Text Editor Window

To access, do one of the following.
• Choose Windows > Text Editor from the DFTVisualizer pulldown menu.
• Execute the following command from the tool command line:
open_visualizer -display text_editor
• Click the right mouse button (RMB) on an instance in any of the following
DFTVisualizer windows: Flat/Hierarchical Schematic, Data, Wave, Browser, or Global
Search. Choose one of the View in Text Editor > Defining Text | Instantiating Text
menu items.
• Click on a hyperlink (pink underlined text) in the Console window.
The Text Editor window allows you to view and edit text files.
Objects
• Use the Text Editor window to do the following:
o View currently loaded design files: netlists, ATPG library, test procedure files,
startup files, and dofiles.
o View the definition and instantiation of instances in a Verilog netlist or ATPG
library.
o Create, edit, and save test procedure files, dofiles, and startup files.
o Troubleshoot test procedure files.
o Locate and debug test procedure file errors during DRC.
o Use built-in Verilog, VHDL, and test procedure file templates for making on-the-fly
changes.
Note
DFTVisualizer supports all of these operations for compressed netlist and ATPG
library files with any of the following file extensions: “.Z”, “.gz”, “.gzip”, and
“.zip”.

December 2017
DFTVisualizer
Text Editor Window
Figure 7-18. Text Editor Window
Usage Notes
The Text Editor contains standard text editor functions. You access these functions from the
File and Edit menus and by clicking the right mouse button (RMB) to display the popup menu.
You can specify the type of syntax highlighting to be applied to the contents of the Text Editor
by selecting the Display > Syntax Highlighting menu and choosing from the following
syntaxes: Verilog, VHDL, ATPG Library, Test Procedure, or Dofile. By default, the Text Editor
highlights text using Verilog syntax.
The Text Editor also provides:
• Access to any design files currently loaded in DFTVisualizer. To view currently loaded
Verilog netlist files, dofiles (including startup files), the ATPG library, and the test
procedure file, choose File > Open > Current Design Files or click the icon and
select the file you want to open.
o To open all currently loaded design files, choose All. Be aware that if the tool is
invoked on a flat model, the netlist, ATPG library, and test procedure file are not
opened. If a dofile or startup file is specified, it is opened using this option.
o To open any subset of the currently loaded design files, choose from the individual
files listed under the submenus: Netlist | ATPG Library | Dofiles.
• Display options such as window positioning options, font sizes, and line numbers. To set
display options, choose the Display > Windows | Font | Line Number menu items.

December 2017
DFTVisualizer
Text Editor Window
• Search and replace operations using ASCII text or regular expressions. To search and/or
replace, choose Edit > Search | Replace. To use regular expressions, click More and
enable the Regular Expression option.
• Support for vi and emacs text editor key bindings. To access, choose Display > Key
Stroke Mode.
• Support for viewing and modifying compressed netlist and ATPG library files. To open
a ZIP file, choose File > Open > Other or click the icon, select the compressed file
to open from the Open File dialog box, and click OK. Each compressed file you open
displays as a tab in the Text Editor.
Note
DFTVisualizer supports all of these operations for compressed netlist and ATPG
library files with any of the following file extensions: “.Z”, “.gz”, “.gzip”, and
“.zip”.
• Cross-highlighting between a selected instance and its description. To display a selected

instance in the Flat/Hierarchical Schematic, Data, Wave, Browser, or Global Search
window, choose one of the View In Text Editor > Defining Text | Instantiating Text
menu items:
o Defining Text — displays the Verilog module definition for gate instances or the
ATPG library model for library instances and primitives.
o Instantiating Text — displays the Verilog instantiation in the netlist.
If the tool is invoked on a flat model, the View in Text Editor option is disabled.
Note
Some designs contain multiple definitions of library models or Verilog modules in
the ATPG library and netlist files. The Text Editor will only display the definition
that is in use by the tool; this is determined by the priority used when the library and
Verilog files are parsed at tool invocation.
• Templates for DFT-specific operations. To access the templates, choose Display >
Show Template and click a specific template item to insert the template into the
currently-opened file.

December 2017
DFTVisualizer
Console Window
Console Window
When DFTVisualizer is invoked, the Console window will be displayed and restored to the last
view when you exited the tool. The Console window allows you to enter commands and interact
with tool output and can be used as an alternative to the shell window.
Figure 7-19. Console Window
Objects
• Use the Console window to do the following:
o Enter and execute tool commands.
o View color-coded log file information.
o View notes, warnings, and errors applicable to the current session.
Usage Notes
• All tool commands can be executed in the Console window. Tool responses are
displayed in the Console window as well as in the shell window. Tool responses are
color-coded for better readability and easy identification of important messages.
• A dofile of commands executed in the Console window can be created. To write a dofile
of the commands shown in the Console window, choose the File > Create Dofile menu
item. Specify the name of the dofile to create in the Selection field of the Create Dofile
dialog box. All of the commands output by the Display > Filter > Command menu
item are saved to the dofile with the exception of comment characters “// command:”
which are omitted.
Note
The dofile is saved to the path specified in the Selection field. If you do not specify
an absolute path, the dofile is saved in the current directory.
• The contents of the Console window can be filtered. To filter the contents of the Console
window, choose one of the Display > Filter menu items described in Table 7-9.
Table 7-9. Console Window Contents
Filter Description
Error Only errors are displayed in the Console window. Errors display
in red font.

December 2017
DFTVisualizer
Console Window
Table 7-9. Console Window Contents (cont.)

Filter Description
Warning Only warnings are displayed in the Consolse window. Warnings
display in green font.
Command Only commands are displayed in the Console window.
Commands display in black font.
Show All All errors, warnings, and commands are displayed in the
Console window and each displays in their respective font
color. Report output is also displayed in blue font.
• You can quickly view the contents of the Console window by clicking and holding down
the middle mouse button while moving the mouse up and down to view the desired text.
• The Console window can be expanded or collapsed using the button at the top-right
corner of the window.

December 2017
DFTVisualizer
Wave Window
Wave Window
To access: Choose the Windows > Wave menu item or click the icon.
The Wave window displays a waveform representation of the simulation results for the
test_setup procedure, test_end, VCD, and named capture procedures.
Figure 7-20. Wave Window
Objects
The Wave window contains the following contents:
Instance Pane Shows the same instances as the Data window.
Waveform Pane Shows a waveform representation of the same test_setup
procedure data shown in the Data window.
Usage Notes
• To use the Wave window, first add instances and the test_setup column to the Data
window using the Data > Test-Setup menu item; then, open the Wave window.
• To specify to display a specific time range in the Wave window, activate the Wave
window and select Data > VCD from the pulldown menu.
• To view Test_end data in the Wave window, select the Data > Test-End menu item.

December 2017
DFTVisualizer
DFTVisualizer Command Quick Reference
• To view Named Capture Procedure (NCP) data in the Wave window, select the Data >
Named Capture menu item which executes the report_procedures command for the
specified NCP.
• To copy an object’s hierarchical pathname into a buffer which you can then paste into
another location, select the object(s) and choose “<object_name(s)> (click to copy)”
from the popup menu. For more information, see “Copying and Pasting Object Names in
the Design.”
• If the Wave window is detached from and hidden behind the main window, click the
icon to bring the window back to the front.
Note
Tip: The Wave window works together with Data window, automatically showing
the same instances and test_setup data as the Data window, but showing the data as a
waveform with timing information.
Related Topics
Data Window

Tessent Shell provides many commands that are specifically designed for operating
DFTVisualizer.
Table 7-10. Command Summary

Command Description
add_browser_data Adds data columns to the active tab of the Browser window
of DFTVisualizer.
add_display_data Adds data columns to the Data window of DFTVisualizer.
add_display_instances Displays instances in DFTVisualizer and enables you to
trace visually through the design using the Flat or
analyze_drc_violation Generates a netlist of the portion of the design involved with
the specified rule violation number.
close_visualizer Closes the DFTVisualizer window.
delete_browser_data Removes data columns from the Browser window of
DFTVisualizer.
delete_display_data Removes a data column from the Data window of
DFTVisualizer.

December 2017
DFTVisualizer
Table 7-10. Command Summary (cont.)

Command Description
delete_display_instances Removes the specified instances from a DFTVisualizer
display window.
display_diagnosis_report Opens a diagnosis report in which you can click symptoms
and suspect locations to add related gates to the
DFTVisualizer Flat Schematic Window.
mark_display_instances Changes the color of the specified instances in the Flat/
open_visualizer Opens the DFTVisualizer main window.
read_visualizer_preferences Reads a DFTVisualizer preferences file and sets current
preferences as described in the file.
report_display_instances Lists netlist information for specified instances displayed in
the Flat Schematic Window.
select_display_instances Selects the specified objects in the Flat and/or Hierarchical
Schematic Window.
set_visualizer_logging Writes the commands entered into the Console window to
the file specified by the enhanced_dofile argument.
set_visualizer_preferences Controls a subset of DFTVisualizer preferences for the Flat/
Hierarchical and Design, Browser, and Data windows.
unmark_display_instances Removes color highlighting and/or marking from instances
in the Flat Schematic Window.
unselect_display_instances Unselects the specified objects in the Flat and/or
write_visualizer_dofile Writes a dofile containing commands needed to recreate
current instance and data displays.
write_visualizer_preferences Writes the current DFTVisualizer preference settings to a
file.
write_window_contents Saves a screen capture of a DFTVisualizer window.

December 2017
DFTVisualizer

December 2017
Chapter 8
Test Procedure File
Test procedure files specify how the scan circuitry within a design operates. The scan circuitry
operation is specified using previously-defined scan clocks and other control signals. To operate
the scan circuitry in your design, you must define the scan circuitry and provide a test procedure
file to describe its operation. The design rules checking (DRC) process, which occurs when you
exit setup mode, performs extensive checking to ensure the scan circuitry operates correctly.
Test Procedure File Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Test Procedure File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Test Procedure File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
#include Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Set Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Alias Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Timing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Timeplate Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Multiple-Pulse Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Always Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Procedure Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Clock Control Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
The Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Test_Setup (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Shift (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Alternate Shift Procedure (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Master_Observe (Sometimes Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Shadow_Observe (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Clock (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Skew_Load (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Capture Procedures (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Sub_procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

December 2017
Test Procedure File
Test Procedure File Creation
Additional Support for Test Procedure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Creating Test Procedure Files for End Measure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Serial Register Load and Unload for LogicBIST and ATPG . . . . . . . . . . . . . . . . . . . . . 367
Static Versus Dynamic Register Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Dofile Modifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Serial Load and Unload DRC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Notes About Using the stil2mgc Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Extraction of Strobe Timing Information from STIL (SPF). . . . . . . . . . . . . . . . . . . . . . . . 380
Test Procedure File Commands and Output Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Test Procedure File Creation

You insert scan circuitry and create test procedure files for ATPG operations using the “patterns
-scan” context of Tessent Shell. If your design already contains scan circuitry, you will need to
create a test procedure file to describe its operation either by hand or with Tessent Shell.
You can specify a test procedure file in setup mode using the add_scan_groups command. The
tools can also read in procedure files by using the read_procfile command or the write_patterns
command when not in setup mode. When you load more than one test procedure file, the tool
merges the timing and procedure data.
You can also have the stil2mgc tool translate a STIL Procedure File (SPF) into a dofile and test
procedure file. This tool produces a dofile that defines clocks, scan chains, scan groups, and pin
constraints. This tool also creates test procedure files with a timeplate and the following
standard scan procedures: test_setup, load_unload, and shift. For more information about
stil2mgc, refer to “Notes About Using the stil2mgc Tool” on page 380.
The following subsections describe the syntax and rules of test procedure files, give examples
for the various types of scan architectures, and outline the checking that determines whether the
circuitry is operating correctly.
Test Procedure File Syntax

The test procedure file uses common syntactical conventions such as bold and italic fonts, and
reserved characters. The file supports Tcl conditional statements.
Syntax Conventions
The following syntax conventions are used in this chapter:
• Bold — Indicates a keyword. Enter the keyword exactly as shown.

December 2017
Test Procedure File
• Italic — Indicates lexical elements such as identifiers, strings, or numbers. Replace the
italicized word with the appropriate name or integer.
• | — A vertical bar or pipe character indicates a logical “OR” as in “select foo OR
foo_not”.
• [ ] — Square brackets indicate optional elements. Do not include the brackets.
• … — An ellipsis indicates a repeatable item or set.
Reserved Characters
If you have a pin or pathname that uses a reserved punctuation character, you must enclose that
name in double quotes. See Table 8-1 for a list of reserved punctuation characters.
For example, the following statement is illegal because it uses the exclamation point outside of
double quotes.
force /inst_my_adder_1/xclk_header!x1!x1/op1[9] 1
The signal name contains a reserved punctuation character, the exclamation point (!), so it must
be enclosed inside double quotes. The correct syntax would be:
force "/inst_my_adder_1/xclk_header!x1!x1/op1[9]" 1
Table 8-1. Reserved Punctuation Characters

Name Character
Ampersand/AND &
Caret/Circumflex/XOR ^
Comma ,
Equals =
Exclamation mark !
Left/Opening brace {
Left/Opening parenthesis (
Right/Closing brace }
Right/Closing parenthesis )
Semicolon ;
Vertical bar/OR |
Throughout this chapter, value = 0, 1, X, or Z.

December 2017
Test Procedure File
Using Tcl in the Test Procedure File

Procedure files support the Tcl conditional statements “if”, “else”, and “elseif” using the
following syntax:
if { tcl_expr } {
procedure file statements
}
elseif { tcl_expr } {
}
else {
}
Where a “tcl_expr” is any Boolean Tcl expression that uses Tcl variables, dofile variables, or
environment variables. Just as when doing variable substitution in the procedure file, other Tcl
statements and defining Tcl variables are not supported. All variables must be defined in the
dofile or from the shell as environment variables.
The body of these Tcl conditional statements should contain only legal procedure file syntax,
not any other Tcl statements. The Tcl conditional statements are treated as preprocessor
statements in the procedure file parser. They are not preserved in the tool after parsing is
finished; only the procedure file code selected by the evaluation of the Tcl “if” expression is
stored in the tool. Therefore, when using write_procfile to write out the procedure file, none of
the Tcl conditional statements are present, and the procedure file code not used is also not
present. For more information refer to “The Tessent Tcl Interface” on page 417.
Introductory Test Procedure File Example

The following is an example of a simple test procedure file.

December 2017
Test Procedure File
// Comments use “//” characters

//
// Set the base time increment for use in all timeplates
set time scale 1.0 ns;
// Define the strobe time for the measure statements

set strobe_window time 1;
// This design uses a single timeplate, named “tp1”, for all

// vectors.
timeplate tp1 =
force_pi 0;
measure_po 1;
pulse CLK0_7 2 1;
pulse CLK8_15 2 1;
period 4;
end;
// The shift and load_unload procedures define how the design

// must be configured to allow shifting data through the scan
// chains. The procedures define the timeplate that will be
// used and the scan group that it will reference.
procedure shift =
scan_group grp1;
timeplate tp1;
cycle =
force_sci;
measure_sco;
pulse CLK8_15;
pulse CLK0_7;
end;
end;
procedure load_unload =
scan_group grp1;
timeplate tp1;
cycle=
force CLEAR 0;
force CLK0_7 0;
force CLK8_15 0;
force scen1 1;
end;
apply shift 8;
end;
// The capture procedure is a "non-scan" procedure. This

// procedure describes the timeplate that will be used for the
// capture cycle. It also defines the number of cycles that
// will be used in the capture cycle. In this example there is
// just one cycle.
procedure capture =
timeplate tp1;
cycle =
force_pi;
measure_po;

December 2017
Test Procedure File
pulse_capture_clock;
end;
end;

December 2017
Test Procedure File
Test Procedure File Structure
Test Procedure File Structure

The test procedure file consists of many structural elements that display in a specific order,
starting with #include statements. Some of these elements are required and others are optional.
#include “<file_name>”;
[set_statement ...]
[alias_definition ...]
[timing_variables ...]
timeplate_definition // includes pulse clock statements
always_block
procedure_definition
clock control definition
#include Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Set Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Alias Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Timing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Timeplate Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Multiple-Pulse Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Always Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Procedure Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Clock Control Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
#include Statement
The “#include” statement specifies that the tool read test procedure data from a specified file.
The following rules apply to #include statements and files:
• The “#include” statement can occur anywhere in the file, and multiple “#include”
statements can occur in one file. For example:
#include "foo.proc";
• The file name to be included must be enclosed in double quotes, and the statement must
be followed by a semicolon.
• All timeplates and procedure rules apply to the statements placed in #include files.
• Included files can use the “#include” statement to include other files, up to a maximum
include depth of 512. If you later use the write_procfile command write out procedure
data, the “#include” statements are not preserved, and the tool writes all procedure data
to a single file.

December 2017
Test Procedure File
Set Statement
Set Statement
The Set statements define specific parameters used throughout the test procedure file.
The following statements are available:
set time scale tscale;

set strobe_window time window_width;
set default_timeplate timeplate_name;
set autoforce off;
set time scale Statement

Defines the time scale and unit. The “set time scale” statement must be at the beginning of the
procedure file, before any timeplate or procedure definition. If you do not specify the time scale,
the default value is 1 ns.
The tool applies the time scale and unit to the test procedure file and timeplates. The tscale you
specify can be any real number. Time values in the timeplate, however, must be integers,
representing whole time scale units. If you find you are specifying fractional times in the
timeplate, you must reduce the time scale unit so you can specify integer time values in the
timeplate. For example, the following would result in a syntax error:
set time scale 1 ns ;

set strobe_window time 1 ;
timeplate fast_clk_tp =
force_pi 0 ;
measure_po 0.500 ;
pulse CLKA 0.750 1.50 ;
pulse CLKB 0.750 1.50 ;
period 3.000 ;
end ;
To correct the syntax, you could change the time scale to picoseconds, and adjust the time value
to meet the scale as follows:
set time scale 10 ps ;

timeplate fast_clk_tp =
force_pi 0 ;
measure_po 50 ;
pulse CLKA 75 150 ;
pulse CLKB 75 150 ;
period 300 ;
end ;
The units supported are ms, us, ns, ps, and fs.
The tool translates the time scale in the procedure file into a Verilog ‘timescale directive in the
Verilog testbench when writing patterns in Verilog format.

December 2017
Test Procedure File
Set Statement
If the time scale number you specify in the test procedure file is 1 or larger, the resulting Verilog
‘timescale directive has the same time unit (resolution) and time precision. For example, “set
time scale 1 ns ;” would result in this Verilog directive:
‘timescale 1ns / 1ns
If you want the testbench to have smaller precision than resolution, there are several ways to
designate this:
• Specify a time scale number of less than 1 in the procedure file. For example,
“set time scale 0.5 ns ;” produces this Verilog directive:
‘timescale 1ns / 100ps
• Add non-zero significant bits to the time scale in the procedure file. For example,
“set time scale 10.05 ns ;” produces this Verilog directive:
• Add trailing zeros as significant bits for an asynchronous clock period or pattern_set
period (when creating IJTAG patterns). For example, an “add_clocks -period 10.00ns”
command produces this Verilog directive:
• Use the SIM_PRECISION parameter file keyword. For example,

“SIM_PRECISION 0.5ns;” produces this Verilog directive:
The precision in the Verilog testbench can originate from any of the previous sources, and the
tool uses the smallest specified precision when writing out the Verilog testbench.
The resolution in the Verilog testbench originates from the procedure file. When you use
multiple procedure files, the various “set time scale” statements can specify different values,
and the tool uses the smallest specified resolution when writing the Verilog testbench.
set strobe_window time Statement

Defines the strobe-window width. The “set strobe_window time” statement must be at the
beginning of the procedure file, before any timeplate or procedure definition. If you do not
specify the strobe_window time, it will default to the maximum allowable size. For example, if
you look at a timeplate, and if there is a 10 ns window between the measure_po event and the
next event (or end of timeplate), then that is what the strobe window will be. If there are
multiple timeplates, then the smallest strobe window from the timeplates is the maximum
allowable strobe window.
Some tester formats measure primary outputs (POs) at the exact time that you specify with the
measure_po statement in the timeplate. However, other tester formats, such as STIL, require

December 2017
Test Procedure File
Set Statement
that output measurements occur during a specified window of time (window_width). For WGL,
this statement changes the strobe window in the output file.
A strobe window can only stretch from the measure_po time to the end of the cycle or the next
force or pulse event. For example, if you issue a measure_po at time 10 and the rising edge of a
pulse at time 30, the strobe window can only be a maximum of 20. Strobe_window lets you
know that, starting at the measure_po time, the primary output should be stable for the time
specified by the strobe window.
Note
Strobe_window only affects the following formats: STIL, TSTL2, and WGL.
set default_timeplate Statement

Specifies a timeplate that can be used for any procedure definition that does not explicitly
specify a timeplate. The referenced timeplate_name must be defined prior to the Set
Default_timeplate statement in the procedure file.
set autoforce Statement

An optional statement that controls the behavior for automatically adding force events. If
included, this statement must appear at the beginning of the procedure file, prior to any
procedures.
By default (without this statement), if a constrained pin is not forced to the constrained value in
the test_setup procedure, a force event is automatically added to the first cycle of the test_setup
procedure. If the test_setup procedure starts with a call to a subprocedure, then the force event is
added to the first cycle following the subprocedure. If a force event already exists in the
test_setup procedure for a constrained pin, then no additional force event will be added for that
pin.
When you include the “set autoforce off” statement, the tool will not add any force events on the
constrained pins to the test setup procedure.
Including the “set autoforce off” statement also prevents the tool from forcing clock pins to the
inactive state at the beginning of the load_unload procedure. The statement also disables
copying the last value forced on an input port in test_setup and prevents it from becoming a
force at the start of the load_unload procedure.
The “set autoforce off;” statement also turns off auto forcing Z values on bidis in the
load_unload procedure—see Load_Unload (Required).

December 2017
Test Procedure File
Alias Definition
Alias Definition
The Alias definition groups multiple signal names or cell paths into a single alias name. Signal
Alias statements are useful in procedures or timeplates where multiple signals need to be
assigned to the same value at the same time.
Cell Alias statements are used to group cell paths into a single alias name. You must define
aliases before using them. The definition can occur at any place in the procedure file outside of
a timeplate or procedure definition.
Note
When saving STIL2005, CTL, or Structural_STIL patterns, all aliases defined in the
procedure file will be defined as SignalGroups in the resulting STIL file.
There is a predefined alias available for specifying all bidirectional pins. The “_ALL_BIDI”
keyword may be useful for forcing all bidirectional pins to a specified value without having to
identify each individual pin. For example:
force _ALL_BIDI Z;
In using a cell Alias statement to group cell paths from condition statements into a single alias
name, it is possible to override a condition statement in a named capture procedure with a
subsequent condition statement that occurs in the same place (global condition, or local to a
specific cycle). A condition statement can only override a previous condition if the first
condition is specified using an alias name, and if the second condition is specified without using
an Alias statement.
Tip
When using multiple named capture procedures where each procedure requires many
condition statements, it is helpful to group cells into a common name and apply the
condition statement once to the entire group of cells, and then override specific cells that need a
different value than what was applied to the group. This frees you from having to enter
numerous condition statements for each named capture procedure, while only a handful of the
cells require different values for each procedure.
The Alias definition has the following format:
alias alias_name = pin_name [, pin_name ...];
or
alias alias_name = cell_name [, cell_name ...];
• alias_name
A string that specifies the name of the alias.

December 2017
Test Procedure File
Alias Definition
• pin_name
A repeatable string that specifies the pin name to associate with the alias name.
• cell_name
A repeatable string that specifies the cell name to associate with the alias name.
Alias Examples
This example groups two signal names into a single alias name.
alias my_group = T, U;
This next example shows how a named capture procedure should look when using an Alias
statement for condition cells. The example sets each of four cells to a value of 0, and then the
fourth cell (/inst_3/blockb/reg_2/Q) is overridden with a value of 1.
alias cond_cells = "/inst_0/blocka/reg_1/Q", "/inst_1/blocka/reg_1/Q",

"/inst_2/blocka/reg_1/Q", "/inst_3/blockb/reg_2/Q";
timeplate tp1 =
force_pi 0;
measure_po 10;
pulse ref_clk 50 50;
period 100;
end;
procedure capture capture1 =
timeplate tp1;
condition cond_cells 0;
condition /inst_3/blockb/reg_2/Q 1;
// overrides condition in previous statement
cycle =
force scan_en 0;
force ctrl_a 1;
force_pi;
pulse ref_clk;
end;
cycle =
force_pi;
measure_po;
pulse ref_clk;
end;
end;
This example shows how to define a user-defined bus in a procedure file:
alias wdata = "D[0]", "D[1]", "D[2]", "D[3]";

December 2017
Test Procedure File
Timing Variables
And this shows how to assign a value to that user-defined bus:
procedure sub_procedure subpro1 =

scan_group grp1 ;
timeplate shift_tp ;
cycle =
force wdata 0010 ;
pulse ref_clk ;
end;
end;
Timing Variables
Two timing variable block definitions allow a procedure file to express timing using variables
and equations, and to have this equation-based timing preserved in the tool and reproduced in
the correct syntax in pattern output files.
Test data languages such as WGL and STIL have the ability to express time values in the timing
blocks as numerical values or as equations based on variables. Using equation-based timing
allows one value to be specified for a global attribute, such as the test cycle period, while other
values are derived from this using equations.
The two timing block definitions are called “timing_variables” and “variables”. In the
“timing_variables” block, variables can be defined and assigned timing values. These values
will be expressed in the time scale which is already specified by the Set Time Scale statement.
The “timing_variables” block must be defined before the timeplate definitions.
The “variables” block is used to define variables that are not time values and have no units
associated with them. These variables can only be assigned integer numbers, and can be used as
scaling multipliers in the timing equations.
The variables in the “timing_variables” block can also be assigned timing equations instead of
time values. These equations are simple mathematical equations which can use either timing
values or previously defined variables or timing variables as operands.
Note
The event statements in the timeplate definition block accept timing values and timing
variables.
When saving patterns in the Verilog, WGL, and STIL supported formats, the waveform tables
in these formats will be written using the equations and variables, and the variables will be
defined in the appropriate definition blocks which exist in each format. When saving patterns in
formats that don’t support equation-based timing, the equations will be computed and the
timing information will be specified as the resulting numeric values in the pattern file. Setting
the ALL_FLATTEN_TIMING parameter file keyword to 1 will cause Verilog, WGL, and STIL
outputs to compute the timing equations and use only the resulting numeric values in the output

December 2017
Test Procedure File
Timing Variables
files. Any equation that does not compute to an integer value will be rounded to the nearest
integer value.
The “timing_variables” block has the following syntax:
variables =
variable_name = integer;
[variable_name = integer; ...]
end;
timing_variables =
variable_name = time_or_equation;
[variable_name = time_or_equation; ...]
end;
Note that time_or_equation can either be an integer time value or a time equation. A time
equation is expressed using operators and operands. An operator is one of +, -, *, or /. An
operand can be a time value or a variable name (time or scaling variable). The multiplication
and division operators (* and /) take precedence over the addition and subtraction operators (+
and -). You can use parenthesis to group operations for precedence.
Note
In the timeplate definitions, any place where a time value can be used, a timing variable is
also allowed. A scaling variable from the “variables” block cannot be used in a timeplate
definition. These can only be used in time equations.
Variable names can be any identifier except for reserved keywords used in the procedure file
syntax (such as “period” and “force_pi”). The variable names must conform to the rules that
apply to all identifiers used in the procedure file (alpha numeric string, starting with an alpha
character, and no reserved punctuation marks). If reserved characters or reserved words are used
in a variable name, the name must be enclosed in quotes.
Equation-Based Timing Example

The following is a partial example of using equation-based timing.

December 2017
Test Procedure File
Timing Variables
set time scale 1.0 ns;

variables =
v_scale = 1;
end;
timing_variables =
t_period = 100;
t_force = 0;
t_meas = ((t_period * 0.1) * v_scale );
t_rise = ((t_period / 2) * v_scale );
t_width = ((t_period * 0.2) * v_scale);
end;
timeplate tp1 =
force_pi t_force;
measure_po t_meas;
pulse ref_clk t_rise t_width;
period t_period;
end;
This is how the timing example above would be represented in the STIL output:
Spec STUCK_spec {
Category STUCK_cat {
v_scale = ’1’;
t_period = ’100ns’;
t_force = ’0ns’;
t_meas = ’(t_period*0.1)*v_scale’;
t_rise = ’(t_period/2)*v_scale’;
t_width = ’(t_period*0.2)*v_scale;
}
}
Timing STUCK_timing {
WaveformTable tset_tp1 {
Period ’t_period’;
Waveforms {
input_time_gen_0 { 01 { ’t_force’ D/U; }}
input_time_gen_1 { 01 { ’0ns’ D; ’t_rise’ D/U;
’t_rise+t_width’ D;}}
_po_ { LHX { ’0ns’ X; ’t_meas’ l/h/x; ’t_rise’ X;}}
}
}
}

December 2017
Test Procedure File
Timeplate Definition
This is how the timing example would be represented in the WGL output:
equationsheet STUCK_sheet
exprset STUCK_set
v_scale := 1.0;
t_period := 100nS;
t_force := 0nS;
t_meas := (t_period * 0.1) * v_scale;
t_rise := (t_period / 2) * v_scale;
t_width := (t_period * 0.2) * v_scale;
_tp1_fall_1 := t_rise + t_width;
end
end
timeplate tp1 period t_period

"input_a" := input [t_force:S];
...
"output_z" := output[0nS:X, t_meas:Q, t_rise:X];
...
"refclk" := input[0nS:D, t_rise:S, _tp1_fall_1:D];
end
The timeplate definition describes a single tester cycle and specifies where in that cycle all
event edges are placed.
You must define all timeplates before they are referenced. A procedure file must have at least
one timeplate definition. All clocks must be defined in the timeplate definition. The timeplate
definition has the following format:
timeplate timeplate_name =
timeplate_statement
[timeplate_statement ...]
period time;
end;
The following list contains available timeplate_statement statements. The timeplate definition
should contain at least the force_pi and measure_po statements. You are not required to include
pulse statements for the clocks. But if you do not “pulse” any of the clocks, the tool uses two
cycles to pulse a clock, resulting in larger patterns.
Note that the tool uses the pulse_clock statement rather than individual pulse statements when
generating default procedures.

December 2017
Test Procedure File
timeplate_statement:
offstate pin_name off_state;
force_pi time;
bidi_force_pi time;
measure_po time;
bidi_measure_po time;
force pin_name time;
measure pin_name time;
pulse pin_name time width [, time width];
pulse_clock time width [, time width];
Note
In “timeplate_statement” definitions, you can use timing variables instead of time values.
For more information, refer to “Timing Variables” on page 299.
The following is a list of statements in the timeplate definition:
• timeplate_name
A string that specifies the name of the timeplate.
• offstate pin_name off_state
A literal and double string that specifies the inactive, off-state value (0 or 1) for a
specific named primary input pin that will be pulsed within this timeplate but is not
defined as a clock pin by the add_clocks command. The complex timeplates are most
useful in the shift procedure where a non-clock pin must be pulsed while still
maintaining a single cycle in the shift procedure.
This statement must occur before all other timeplate_statement statements. This
statement is required for any pin that is not defined as a clock pin by the add_clocks
command but will be pulsed within this timeplate.
Note
An “offstate” statement does not automatically force pin_name to its off state at time
0. For that to occur, you must force or pulse pin_name appropriately in a procedure.
• force_pi time
A literal and integer pair that specifies the force time for all primary inputs.
• bidi_force_pi time
A literal and integer pair that specifies the force time for all bidirectional pins. This
statement allows the bi-directional pins to be forced after applying the tri-state control
signal, so the system avoids bus contention. This statement overrides “force_pi” and
“measure_po”.
• measure_po time

December 2017
Test Procedure File
A literal and integer pair that specifies the time at which the tool measures (or strobes)
the primary outputs.
• bidi_measure_po time
A literal and integer pair that specifies the time at which the tool measures (or strobes)
the bidirectional pins. This statement overrides “force_pi” and “measure_po”.
• force pin_name time
A literal, string, and integer that specifies the force time for a specific named pin.
Note
This force time overrides the force time specified in force_pi for this specific pin.
• measure pin_name time

A literal, string, and integer that specifies the measure time for a specific named pin.
You can use a “measure” statement in timeplates only to specify a measure time for a
pin.
Note
This measure time overrides the measure time specified in measure_po for this
specific pin.
• pulse pin_name time width [, time width]…

A literal, string, and repeatable integer set that specifies the pulse timing for a specific
named pin.
pin_name — String that refers to a pin in the design. Valid pins must meet one of the
following conditions:
Defined as a clock pin using the add_clocks command.
Not defined as a clock pin, but has a pulse signal and an offstate specified by the
“offstate” statement.
time — Integer that defines the offset from time 0 to the leading edge of the pulse.
width — Integer that defines the width of the pulse.
To define a multiple-pulse waveform, include multiple time and width pairs separated
by a comma.
All pulses must occur within the tester cycle period. You define this period using the
“period” keyword.

December 2017
Test Procedure File
Note
Multiple pulses are only supported for the following output formats: Verilog, WGL,
STIL, STIL2005, CTL, FJTDL, MITDL, and TSTL2. Additionally, the TSTL2
output format does not support more than two pulses.
For MITDL format there is restriction that multiple pulse timing must be a cyclical
repetition of the first pulse. Consequently, multi-pulse and double-pulse timing in the
procedure file only works in the MITDL output without an error if the timing fits the
restrictions of the MITDL syntax.
• pulse_clock time width [, time width ]…
A literal and integer set that specifies the pulse timing for all signals defined as clocks,
unless another statement such as a “force” or “pulse” exists for a particular clock signal.
This is similar to the force_pi statement, which specifies the timing for ports that are not
explicitly overridden by a force statement for those specific ports.
time — Integer that defines the offset from time 0 to the leading edge of the pulse for the
first pulse. For subsequent edges in a multi pulse clock, time equals the time of the
previous leading edge plus the period of the clock.
width — Integer that defines the width of the pulse.
You can use the pulse_clock statement to ensure that any added clocks (especially
internal clocks) automatically have defined timing.
You may have multiple pulse_clock statements within a timeplate definition, as long as
each statement has a different number of offset and width pairs. If two pulse_clock
statements in the timeplate definition have the same number of offset and width pairs,
the tool issues an error.
For more information on multiple-pulse clocks, see “Multiple-Pulse Clocks.”
All pulses must occur within the tester cycle period. You define this period using the
“period” keyword.
For example (1x pulse_clock):
timing_variables =
tester_period = 10;
strobe_1 = (0.96 * tester_period);
t_time = (0.25 * tester_period);
t_width = (0.5 * tester_period);
end;
timeplate tessent_ijtag =
force_pi 0 ;
measure_po strobe_1;
force tck 0;
pulse_clock t_time t_width;
period tester_period;
end;

December 2017
Test Procedure File
• period time
A literal and integer pair that defines the period of a tester cycle. This statement ensures
that the cycle contains sufficient time, after the last force event, for the circuit to
stabilize. The time you specify should be greater than or equal to the final event time.
Example 1
timeplate tp1 =
force_pi 0;
pulse T 30 30;
pulse R 30 30;
measure_po 90;
period 100;
end;
Example 2
The following example shows a shift procedure that pulses b_clk with an off-state value of 0.
The timeplate tp_shift defines the off-state for pin b_clk. The b_clk pin is not declared as a
clock in the ATPG tool.
timeplate tp_shift =
offstate b_clk 0;
force_pi 0;
measure_po 10;
pulse clk 50 30;
pulse b_clk 140 50;
period 200;
end;
procedure shift =
timeplate tp_shift;
cycle =
force_sci;
measure_sco;
pulse clk;
pulse b_clk;
end;
end;
Example 3
In the following example, the pin b_clk is not declared as a clock in the ATPG tool. However, in
the shift procedure, the user needs the pin to be pulsed twice with an offstate of 0.

December 2017
Test Procedure File
timeplate tp_shift =
offstate b_clk 0;
force_pi 0;
measure_po 10;
pulse clk 50 30;
pulse b_clk 40 50, 140 50;
period 200;
end;
procedure shift =
timeplate tp_shift;
cycle =
force_sci;
measure_sco;
pulse clk;
pulse b_clk;
end;
end;

December 2017
Test Procedure File
Multiple-Pulse Clocks
You can use the pulse_clock statement to handle multiple-pulse clock timing and still use a
single generic timeplate template definition in various flows. The pulse_clock statement
handles multiple-pulse timing definitions in the same manner as the pulse statement.
The pulse_clock Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Inferred Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Differences Between Default add_clock and 1x Multiplier Clock. . . . . . . . . . . . . . . . . . 310
The pulse_clock Statement

In a timeplate statement, each pulse_clock statement has a different number of integer pairs for
the offset and width of the clocks. The different statements represent 1x, 2x, 3x, and so on, pulse
timing for clocks. The frequency multiplier that you specify for the clocks identifies the
appropriate pulse timing that will be used for them.
When you specify a multiplier for a clock and no pulse_clock statement exists for that clock,
the tool creates inferred timing for the clock using the timeplate period. The tool issues an error
when a port-specific pulse or force statement exists for the clock and the timing in the statement
does not specify the correct number of pulse statements to match the frequency multiplier of the
clock.
The following example has multiple pulse_clock statements. It is a timeplate that includes both
a port specific pulse statement for a clock and the generic pulse_clock statements for all other
clocks. The first pulse_clock statement sets the default clock timing for this timeplate and
contains a single pair of numbers (offset and width). Clocks other than “SlowClockA” that do
not have frequency multipliers use this timing. Clocks with 2x multipliers use the second
pulse_clock statement, and clocks with 4x multipliers use the third pulse_clock statement. The
tool uses inferred timing for clocks specified with any other frequency multiplier and issues an
error if "SlowClockA" has a frequency multiplier of 2x or more.
timeplate tp1 =
force_pi 0;
measure_po 95;
pulse SlowClockA 20 50;
pulse_clock 30 30;
pulse_clock 13 25, 63 25;
pulse_clock 6 12, 31 12, 56 12, 81,12;
period 100;
end;
The following example shows a timeplate with one port-specific pulse and one pulse_clock
statement for 4x multiplier timing. Clocks other than “ClockA” that do not have a frequency
multiplier use force_pi timing. Inferred timing only occurs when clocks have frequency
multipliers, which means other clocks still use NRZ timing when you use multiple cycles to
create the clock pulse.

December 2017
Test Procedure File
timeplate tp1 =
force_pi 0;
measure_po 95;
pulse ClockA 20 50;
pulse_clock 6 12, 31 12, 56 12, 81, 12;
period 100;
end;
Inferred Timing
Based on the period of the timeplate, the tool creates inferred timing for frequency multiplied
clocks when there are no pulse_clock statements in the timeplate with the correct number of
clock edges for the clock.
The total period of a clock pulse is the period of the timeplate divided by the frequency
multiplier of the clock. The offset for the leading edge of the first clock pulse is one-fourth of
the period of the clock. For example, the inferred timing for a 4x clock in a timeplate with a
period of 200 is equivalent to the following pulse_clock definition:
pulse_clock 13 25, 63 25, 113 25, 163 25
Figure 8-1. 200ns Timing Waveform
The first edge is one-fourth the period of the clock rounded to the nearest integer, and the width
of the pulse is one-half the period of the clock. Each subsequent edge is the previous leading
edge plus the period of the clock.
The tool bases the inferred timing for a 1x frequency-multiplied clock on any other clock timing
found for a single pulse clock; otherwise, it will use the inferred timing formula.
When you specify a timeplate period and a clock frequency multiplier that combine to create
inferred timing that is too small to be integer timing, the tool automatically reduces the
procedure file timescale and scales all timing numbers to larger values.
For example, suppose the timescale for the procedure file is 1ns, the period of the timeplate is 5,
and the clock frequency multiplier is 10. The tool automatically adjusts the timescale to 100ps
and the period of the timeplate becomes 50. It adjusts all of the other numbers accordingly. In
this case, the tool multiplies them by 10.

December 2017
Test Procedure File
Always Block
Differences Between Default add_clock and 1x Multiplier

Clock
Default add_clock clocks use the time specified by pulse_clock statements with one pulse or
by pin-specific pulse statements. However, frequency-multiplied clocks use the timing
specified for them only if they match the number of pulses. If this is not the case, the tool uses
inferred timing and issues an error if there are mismatches.
Clocks specified with a frequency multiplier of one behave differently than default clocks. For
this reason, you must specify the timing for a 1x frequency-multiplied clock with a single clock
pulse. The tool does not use NRZ timing with multiple cycles or forced timing edges, and it
issues an error if the timeplate specifies a double-pulse or multiple-pulse timing for the 1x
clock.
Always Block
This optional block definition specifies events that happen in all cycles of all procedures.
Because the always block specifies events for all cycles, it will be used with all timeplates and
does not require a timeplate to be referenced in the block. Also, any signal that is pulsed in the
always block must have a pulse waveform in all timeplate definitions.
If you defined any pulse-always clocks using the add_clocks command, an always block is
automatically created in the procedure file, if one does not already exist, and a pulse statement
added for each clock. Similarly, if you pulse a clock signal in the always block, the signal is
automatically defined as a pulse-always clock. For more information, refer to the add_clocks
description in the Tessent Shell Reference Manual.
Note
Pulse-always clocks are not automatically pulsed in a named capture procedure. The clocks
must be pulsed explicitly.
All events specified in the always block will be subject to rules checks that apply to each
procedure. In other words, the events in the always block will be added to each cycle of each
procedure, and all DRC rules still apply to these events.
When saving patterns that preserve the structure of the procedures as macros (such as the CTL
pattern file, or structural STIL pattern file), the events in the always block will be placed in the
cycles of each procedure. The always block will not be present in the structural pattern file as a
macro or procedure.
Always Block Syntax

The always block has the following syntax.

December 2017
Test Procedure File
Procedure Definition
always =
always_statement ;
[always_statement ; ... ]
end ;
The always_statement is defined as one of the following.
pulse pin_name ;
force pin_name value ;
Always Block Example

The following is a partial example of an always block.
set time scale 1,0 ns ;
timeplate tp1 =
force_pi 0 ;
measure_po 10 ;
pulse ref_clk 20 20, 60 20 ;
pulse shift_clk 50 20 ;
period 100 ;
end ;
always =
pulse ref_clk ;
end ;
procedure shift =
timeplate tp1 ;
cycle =
force_sci ;
measure_sco ;
pulse shift_clk ;
end ;
end ;
The procedure definition is the heart of the procedure file. The procedure defines precisely how
the scan circuitry operates.
All procedure definitions contain one or more cycle definitions. Each cycle definition in the
procedure specifies a vector; each statement in the cycle specifies which events occur in that
vector. The timeplate being used specifies any timing associated with that vector. The following
is a list of rules for writing procedure definitions:
• If more than one timeplate is defined, you can assign a specific timeplate for each
procedure definition or for each cycle within the procedure definitions. You must assign
a timeplate at some point within a procedure definition.
• You must group all procedure statements, except scan_group, timeplate, apply, and
loop, into cycle statements.

December 2017
Test Procedure File
• You cannot specify time values in cycle statements.

• You cannot specify loop statements within cycle statements.
• The order of events within a cycle definition does not matter. The assigned timeplate
specifies the order.
• Within a procedure definition, you can specify a scan group.
• Each scan group needs a unique test procedure file. You associate the test procedure file
with the scan group when you specify the add_scan_groups command.
• Text following “//” is a comment and is ignored.
• You can include blank lines.
• You define a procedure type for a particular scan group (with the exception of the
seq_transparent and clock procedures) only once in a test procedure file.
• You can only have a single test_setup procedure, even if you define multiple scan
groups for your design.
The procedure definition has the following general format, but note that certain statements are
restricted to certain procedures.

December 2017
Test Procedure File
procedure procedure_type [proc_name] =

[scan_group scan_group_name;]
proc_statement [proc_statement ...]
end;
proc_statement:
[timeplate timeplate_name;]
cycle =
cycle_statement [cycle_statement ...]
end;
annotate “quoted string”;
apply proc_name #times;
loop loop_count =
cycle =
cycle_statement [ cycle_statement ...]
end;
end;
cycle_statement:
force_pi;
bidi_force_pi;
force_sci;
force_sci_equiv;
measure_po;
bidi_measure_po;
measure_sco;
restore_pi;
restore_bidi;
bidi_force_off;
pulse_capture_clock;
force_capture_clock_on ;
force_capture_clock_off ;
pulse_read_clock;
pulse_write_clock;
force pin_name value;
expect pin_name value;
condition cell_name value;
measure pin_name;
initialize instance_name [value];
pulse pin_name;
timeplate timeplate_name;
annotate “quoted string”;
• procedure_type
A string that specifies the type of procedure that follows. The following list contains
valid procedures types:
• test_setup • capture • seq_transparent
• shift • clock_po • test_end
• load_unload • ram_sequential • clock
• shadow_control • ram_passthru • sequential
• master_observe • clock_sequential • skew_load

December 2017
Test Procedure File
• shadow_observe • init_force • sub_procedure

For more information, refer to “The Procedures” on page 330.
• proc_name
An optional string that specifies the user-defined name of the procedure. Since you can
specify multiple seq_transparent and clock procedures in a test procedure file, these
procedure types require explicit procedure names, proc_name, for each procedure that
you define.
• scan_group scan_group_name
A literal and string pair that specifies a scan group within a scan procedure. Since some
of the scan procedures are scan group specific, you can specify scan groups within scan
procedures. This makes it possible to define the scan procedures (shift, load_unload) for
multiple scan groups within the same procedure file. You can then specify this file on
the add_scan_groups command for each scan group in this file. If you use the
read_procfile command to read a procedure file, you must include this statement.
However, if you use the add_scan_groups command, this statement is optional since the
group is specified on the command line. When the tool writes out a procedure file, it
produces the scan_group statement.
Note
The scan_group_name argument is case-sensitive if the netlist used is case-sensitive.
• timeplate timeplate_name
A literal and string pair that specifies the name of the timeplate the procedure uses.
A timeplate statement at the beginning of the procedure, outside of the cycle definitions,
is the timeplate used by the entire procedure, if no other timeplates are referenced.
A timeplate statement within a cycle is the timeplate used for that cycle and all other
subsequent cycles until another timeplate statement is encountered. For more
information about timeplates, refer to “Timeplate Definition” on page 302.
• annotate “ quoted string ”;
A literal and string pair that reports the Verilog testbench annotations during simulation.
The annotate statement is optional and must always include a quoted string. All
procedures can be annotated, including sub-procedures. The annotate statement can
occur inside or outside of cycle blocks, including before the first cycle or after the last
cycle.

December 2017
Test Procedure File
This example shows the annotate statement in the beginning of a cycle along with the
cycle timeplate statement, before any event statements:
CYCLE =
[ TIMEPLATE tp_name ; ]
[ ANNOTATE “quoted string” ; ]
event_statement;
…
END ;
The following is an example of using the annotate statement outside of a cycle block:
procedure test_setup =
timeplate tp1 ;
annotate "Before first cycle" ;
cycle =
...
end;
annotate "start sub procedure" ;
apply mySub 1 ;
...
end;
The following is an example of an annotate statement used in a test_setup procedure,

and how this will appear in a STIL pattern file.
Procedure test_setup =
timeplate tp1;
cycle =
annotate “first cycle in test_setup” ;
force reset 1;
force clock 0;
end;
cycle =
annotate “next annotation” ;
force reset 0;
end;
…
This is a segment of the resulting STIL pattern file:

W tset_tp1;
V { _pi_ = 0X11XXX;
_po_ = XXXX;
}
Ann {* Begin chain test *}
Ann {* first cycle in test_setup *}
V { …
}
Ann {* next annotation *}
V { …
}
• label “ quoted_string” ;

December 2017
Test Procedure File
A literal and string pair for including pattern labels in saved patterns. As with the
annotation statement, you can have one label statement per cycle in a procedure
definition. The quoted_string becomes a pattern label for the vector that corresponds to
that procedure cycle.
Only the STIL and WGL pattern formats support a pattern label statement. For pattern
file formats that don't support a pattern label, the label is present as an annotation
statement that has the string “label:” added at the beginning of the label string.
For the simulation testbench, the label is also present as an annotation that has the string
“label:” added at the beginning, and the annotation is echoed when the patterns are
simulated. You can use the existing parameter file keyword SIM_ANNOTATE_QUIET
to turn off echoing the annotations and labels while simulating.
Each pattern label is a unique identifier, with its vector count appended to the end of the
label string.
This statement can be used at the start of any cycle, just like an annotation statement. A
cycle cannot contain both a label and an annotation statement.
The following example shows how to use the label statement within the test_setup
procedure:
timeplate my_tp;
cycle =
force my_sig 0;
end;
cycle =
label "end of test_setup" ;
force my_sig 1;
end;
end;
The previous example produces the following STIL vectors:
V { _pi_ = …;
}
"end of test_setup_1": V { _pi_ = …;
}
• apply proc_name #times

A literal and double-argument string that tells the tool to apply the specified procedure
the specified number of times. You must use the apply shift statement at least once in the
load_unload procedure. For the apply shift statement, you should enter a proper #times
parameter, otherwise you will get a warning message.
If required, you must enter the apply shadow_control statement immediately after the
apply shift procedure statement, and you must set the #times argument to 1. The apply
statement is only valid outside of the cycle blocks because it specifies another group of
cycles within another procedure to be added at that point.
• loop loop_count

December 2017
Test Procedure File
A literal and integer pair that specifies the loop count and is followed by a block of
statements. The loop procedure statement takes the loop count and causes all cycles
within the loop block to be repeated by the number of times specified by the count. For
example, the following test procedure file excerpt specifies 3 cycles within the loop that
are each repeated 20 times:
timeplate tp1 ;
cycle =
force_pi;
measure_po;
end;
loop 20 =
cycle =
end;
cycle =
pulse tck;
end;
cycle =
end;
end; // end loop
end;
Nesting loops within other loops is permitted. For example, the following test procedure
file excerpt causes tck to be pulsed 20 times and clk_a to be pulsed 100 times:
timeplate tp1 ;
cycle =
force_pi;
measure_po;
end;
loop 20 =
cycle =
end;
cycle =
pulse tck;
end;
loop 5 =
cycle =
pulse clk_a;
end;
end; // end inside loop
cycle =
end;
end; // end outside loop
end;
This statement can be used in procedures but must be specified outside of the cycle
statement.
The loop statement is preserved in the flat model when the tool writes the model and is
also present in the TCD files.

December 2017
Test Procedure File
When writing out the patterns in tester pattern formats, the loops are preserved where
possible, and unrolled if the syntax of the pattern file does not support loops. Specifying
the ALL_NO_LOOP parameter keyword unrolls loops in the pattern files in similar
fashion to sub procedures that are applied more than once. Using the loop statement to
repeat a certain number of cycles N times is exactly equivalent to putting those cycles
within a sub procedure, then applying that procedure N times.
• cycle_statement
The following list describes valid cycle_statement keywords. Cycle_statements cannot
contain time values.
o force_pi
A literal that specifies for the tool to force all primary inputs.
o bidi_force_pi
A literal that specifies for the tool to force all bidirectional pins.
o force_sci
A literal that specifies for the tool, in the shift procedure, to place values on the scan
chain inputs, thus implementing scan cell controllability.
o force_sci_equiv
A literal that acts the same as the force_sci statement, except that it also forces all
pins equivalent to the scan input pins. Using this statement places the complement
value on the associated differential pin of a scan input during scan loading. This
statement is necessary because the test procedures do not consider pin equivalence
relationships (those specified with add_input_constraints -equivalent).
o measure_po
A literal that specifies for the tool to measure or strobe the primary outputs.
o bidi_measure_po
A literal that specifies for the tool to measure or strobe the bidirectional pins.
o measure_sco
A literal that specifies for the tool, in the shift procedure, to measure scan output
values, thus implementing scan cell observability. In End Measure Mode (refer to
“Creating Test Procedure Files for End Measure Mode” on page 363), measure_sco
is also used in the load_unload procedure.
o restore_pi
A literal that returns primary inputs to their original states (prior to this procedure’s
execution). You use the restore_pi statement at the end of a seq_transparent
procedure.

December 2017
Test Procedure File
o restore_bidi
A literal that returns bidirectional pins to their original states (prior to this
procedure’s execution). You use the restore_bidi statement at the end of a “clock”
procedure.
o bidi_force_off
A literal that specifies for the tool to force all unconstrained bidirectional pins off.
o pulse_capture_clock
A literal that specifies for the tool to pulse the capture clock.
o force_capture_clock_on
A literal that specifies the cycle when the capture clock goes active. This statement
and the force_capture_clock_off statement can be used in place of the
pulse_capture_clock statement.
The “_on” refers to the active state of the clock, which is not necessarily the high
binary value. This statement is used only with the non-scan procedures and cannot
be mixed with the following statements in the same procedure:
• pulse_capture_clock
• pulse_write_clock
o force_capture_clock_off
A literal that specifies the cycle when the capture clock goes inactive. This statement
and the force_capture_clock_on statement can be used in place of the
pulse_capture_clock statement.
The “_off” refers to the inactive state of the clock, which is not necessarily the low
binary value. This statement is used only with the non-scan procedures and cannot
be mixed with the following statements in the same procedure:
• pulse_capture_clock
• pulse_read_clock
o pulse_read_clock
A literal that specifies for the tool to pulse the RAM read clock.
o pulse_write_clock
A literal that specifies for the tool to pulse the RAM write clock.
o force pin_name value

December 2017
Test Procedure File
A literal and double string that forces the specified value of 0, 1, X, or Z on the
specified pin. The pin names you specify must be valid pin pathnames for primary
inputs.
o expect name value
A literal and double string that causes the tool to expect the specified value of 0, 1,
X, or Z on the specified internal pin or port. The default value is X. You can use
“expect” statements only in the test_setup and test_end procedure. Internal pins are
checked by DRC and are compared in the testbench. For ports, the tool validates the
values in the testbench, the DRCs, and in the tester pattern formats.
o condition cell_name value
A literal and double string that you use at the beginning of a seq_transparent
procedure to identify the necessary scan cell states (conditions) to establish
transparency in non-scan cells. You identify the scan cell by the pin pathname
associated with the output of its state element. The path from the defined pin to the
scan cell must only contain buffers and inverters. The value argument sets the value
at the specified pin pathname, which may be inverted relative to the associated scan
cell value.
o measure pin_name
A literal and string pair that specifies for the tool to measure the value of the named
pin. You can use a “measure” statement in the capture procedure only to specify a
measure on a pin in a different cycle than the measure_po event.
o initialize instance_name value
A literal and string pair that initializes the named memory element to the value
given. This statement is particularly useful for initializing the finite state machine in
the TAP controller of boundary scan circuitry, when the TAP does not contain the
TRST signal. Once set to a binary state, the TCK and TMS pins can place the finite
state machine in a desired state. If not set, these pins remain at X.
If you do not specify a value, the tool chooses a random value to assign to all latches
and flip-flops with the specified instance name.
o pulse pin_name
A literal and string pair that specifies for the tool to pulse the named clock pin.
o observe_method value
A literal and string pair set to a value of master, slave, or shadow, to specify for a
specific observe method to be defined for each named capture procedure.

December 2017
Test Procedure File
Clock Control Definition
The following example shows how to use a cycle_statement to force scan inputs and
measure scan outputs:
procedure shift =
scan_group grp1;
timeplate tp1;
cycle =
force_sci;
measure_sco;
pulse T;
end;
end;

You can manually create clock control definitions in the test procedure file.
For complete information about when you use this definition, refer to “Support for Internal
Clock Control” in the Tessent Scan and ATPG User’s Manual.
ATPG Restrictions
The following restrictions apply to ATPG when clock control definitions are enabled:
• Clock_PO patterns are disabled.

• In undefined cycles, the internal clock is assumed to be off, even if the source clock
pulses.
• Source clocks are pulsed regardless of clock restrictions. Any false paths should be
explicitly defined with DC or the add_false_paths command.
• External clocks without clock control definitions are controlled through top-level pins.
• Clock control definitions applied to a clock defined as equivalent also applies to all
associated equivalent clocks.
• Timeplate definitions apply only to external clocks.
• If you use the set_clock_restriction -same_clocks_between_loads command, you must
use one of the following definitions to pulse the controlled clock:
o {ATPG_SEQUENCE, END}
o {ATPG_SEQUENCE <N> <M>, END} with N starting from 0. The generated test
pattern includes M+1 capture cycles between the scan loading operation and the scan
unloading operation.
o <ATPG_CYCLE <i>, END} with i=0 defined

December 2017
Test Procedure File
If none of these statements are present a warning displays during ATPG about clock
controls that cannot be applied due to clock restrictions.
Rules for Clock Control Definitions

The following rules apply to the clock control definitions in the test procedure file:
• Global control conditions and source clocks defined for equivalent clocks must be the
same.
• When a clock is forced off, it cannot be used as a source in the same definition.
• A FORCE statement cannot force a clock pin to an on state.
• Clock control cannot be applied to an asynchronous free-running clock.
• Condition statements cannot be applied to non-scan state elements.
• You must specify a condition to turn on the internal clock; otherwise, it is assumed to be
off.
• When multiple sequence clock control definitions are defined for the same clock, they
must use mutually exclusive pulse conditions as follows:
o The clock control condition to pulse a clock in sequence mode must be mutually
exclusive with the clock control condition for the same clock in per-cycle mode.
o The condition to pulse a clock in sequence mode must be mutually exclusive with
the condition to pulse the same clock by using another sequence mode.
Keywords
The following is a list of keywords used in clock control statement:
• ATPG_CYCLE cycle_number
A literal and integer that specifies a test pattern capture cycle to map the clock control
to. The specified capture cycle values start from 0, which corresponds to the first capture
cycle after scan loading.
Multiple ATPG_CYCLE definitions can be declared to pulse the internal clock at the
same capture cycle with different sets of conditions.
Use a FORCE statement to turn the clock off, or the clock continues to pulse when the
conditions are satisfied.
The specified and actual capture cycles may to differ—see “Capture Cycle
Determination” in the Tessent Scan and ATPG User’s Manual.
• ATPG_SEQUENCE N M

December 2017
Test Procedure File
A literal and an integer pair that specify a range of capture cycles for clock pulsing from
N to M consecutively.
Define the condition to pulse the clock continuously from capture cycle N (N>=0) to
capture cycle M (M>=N) right after scan loading. If N is greater than 0, the clock is
automatically set to off state from the first capture cycle right after scan loading to the
capture cycle N -1. When the generated test pattern includes more than M capture cycles
after scan loading, the clock is set to off state from the M +1 capture cycle to the last
capture cycle.
Multiple ATPG_SEQUENCE definitions can be declared as necessary.
• ATPG_SEQUENCE
A literal that specifies clock pulsing. When a condition list is provided, the controlled
clock pulses in all capture cycles in the pattern when the conditions are met. When
checking the off conditions for cycles outside the capture window, the conditions listed
in this special atpg_sequence will be ignored.
When there is no condition list, the controlled clock pulses unconditionally in every
capture cycle between scan loading.
Multiple ATPG_SEQUENCE definitions can be declared as necessary.
• CLOCK_CONTROL pin_pathname
A literal and string value that specifies the pin pathname of the PI for the internal clock.
The specified pin must be an existing clock. Internal clocks must also be defined with
the add_clocks command.
• CONDITION cell_name value
An optional literal and double string that specifies necessary scan cell states
(conditions). The scan cell is specified by the pin pathname associated with the output of
its state element. The value argument specifies the value loaded into the scan cell at the
end of shift.

December 2017
Test Procedure File
• FORCE pin_pathname value

A literal and double string that forces a value of 0, 1, or Z on a specified pin. The
specified pin names must be valid pin pathnames for primary inputs. This keyword is
used to force necessary pins off during capture cycles when the controlled clock is
pulsed.
• SOURCE_CLOCK pin_pathname...
A literal and repeatable string that specifies one or more source clocks to drive the
internal clock logic to pulse in the specified capture cycle(s). If no source clock is
specified, the source clock is assumed to be an always-capture clock that pulses in every
capture cycle.
• END
Required literal the specifies the end of an ATPG_CYCLE or ATPG_SEQUENCE
block, or at the end of the clock control definition.
Global Condition Statements

Global conditions are CONDITION statements that are accessible in every scope of a clock
control definition. You can use global conditions to define default conditions within a clock
control definition.
For example, you can specify a CONDITION statement for all ATPG_CYCLE/
ATPG_SEQUENCE blocks within a definition. Then you can define a CONDITION statement
within individual ATPG_CYCLE/ATPG_SEQUENCE blocks to override the global
CONDITION variable when necessary.
The following example uses local conditions (italicized) to define some of the control bits
necessary for each scan cell to pulse the clock. The global conditions define other conditions
that must be satisfied for all clock cycles.
CLOCK_CONTROL /clk_ctrl/int_clk1 =
SOURCE_CLOCK ref_clk;
CONDITION /clk_ctrl/enable_1/q 0;
ATPG_CYCLE 0 =
CONDITION /clk_ctrl/F0/q 1;
END;
ATPG_CYCLE 1 =
END;
ATPG_CYCLE 2 =
END;
ATPG_CYCLE 3 =
END
END;

December 2017
Test Procedure File
The previous example is equivalent to the following:
ATPG_CYCLE 0 =
END;
ATPG_CYCLE 1 =
END;
ATPG_CYCLE 2 =
END;
ATPG_CYCLE 3 =
END
END;
The previous example demonstrates the importance of ensuring that global conditions do not
conflict with local conditions. To further illustrate this point, consider the following incorrect
definition of global conditions:
// Example of incorrect definition of global conditions

ATPG_CYCLE 0 =
END;
ATPG_CYCLE 1 =
END;
ATPG_CYCLE 2 =
END;
ATPG_CYCLE 3 =
END
END;

December 2017
Test Procedure File
On the surface, it may seem correct that the condition in ATPG_CYCLE 0 will override the
global condition while the other cycles can still be satisfied. However, after the global condition
is expanded to all cycles, the clock control definition looks like this:
// Example of incorrect definition of global conditions

ATPG_CYCLE 0 =
END;
ATPG_CYCLE 1 =
END;
ATPG_CYCLE 2 =
END;
ATPG_CYCLE 3 =
END
END;
You can now see that it would not be possible to pulse the clock in ATPG_CYCLE 0 while also
pulsing it in any other cycle. The tool can load only one value into /clk_ctrl/F0, so it can either
pulse the clock in cycle 0 by loading a 1 or pulse it in another cycle by loading a 0.
Per-Cycle Clock Control Definition Example

The following example defines per-cycle clock control for two internal clocks (/top/core1/clk1
and /top/core1/clk2):
CLOCK_CONTROL /top/core1/clk1 =
ATPG_CYCLE 0 =
CONDITION /pll_ctl/cell_0/Q 1;
END;
ATPG_CYCLE 1 =
//both conditions must be satisfied for clock to pulse in
//capture cycle 1
END;
END;
ATPG_CYCLE 0 =
END;
ATPG_CYCLE 1 =
END;
END;

December 2017
Test Procedure File
Sequence Clock Control Definition Example

The following example defines sequence clock control for two internal clocks (/top/core/clk1
and /top/core1/clk2) derived from the source clock clk_src:
SOURCE_CLOCK clk_src;
ATPG_SEQUENCE 0 1 =
// Pulses 2 consecutive cycles if the scan cell
// is loaded with 1, and the source clock is pulsed.
END;
END;
ATPG_SEQUENCE 0 1=
END;
END;
The following example defines sequence clock control for two internal clocks (/top/core/clk1
and /top/core1/clk2) derived from the source clock clk_src. The clock pulses in all capture
cycles when the conditions are met.
ATPG_SEQUENCE =
// Pulse clock in all capture cycles if the scan cell
// is loaded with 1, and the source clock is pulsed.
END;
END;
ATPG_SEQUENCE =
END;
END;
The following example pulses clock /top/core1/clk1 unconditionally in every capture cycle
between scan loading:
ATPG_SEQUENCE =
// empty body
END;
END;

December 2017
Test Procedure File
The following example defines a multi-sequence clock control definition:
CLOCK_CONTROL /top/core/clk1_int =
SOURCE_CLOCK /clk1;
ATPG_SEQUENCE 0 2 =
CONDITION /pll/ctl_1/Q 1;
FORCE ENABLE_1 1;
END;
ATPG_SEQUENCE 3 4 =
CONDITION /pll/ctl_1/Q 0;
FORCE ENABLE_1 1;
END;
END;
Exclusive conditions ensure that only one sequence block is applied per capture cycle
(otherwise, no sequence is applied). If no cycle numbers are specified for sequence clock
control, the clock pulses in every capture cycle when conditions are loaded.
Multiple Sets of Conditions for the Same Cycle Example

The following example shows that if a clock can be pulsed in a particular cycle or sequence of
cycles when there are multiple sets of conditions where any one set can activate the clock for
that cycle, the same cycle can be defined multiple times:
ATPG_CYCLE 0 =
END;
ATPG_CYCLE 0 =
END;
END;
The previous example shows that /top/core1/clk1 can be pulsed in ATPG_CYCLE 0 when any
set of the specified conditions are met. This demonstrates the case where loading a '1' into either
/pll_ctl/cell_1 or /pll_ctl_cell_2 pulses the clock in cycle 0.
Similarly, the following example defines multiple sets of conditions for the same sequence of
cycles, which can overlap. The sequence of cycles must have mutually exclusive conditions to
ensure conditions for each ATPG_SEQUENCE can be satisfied without conflicting with other
sequences.

December 2017
Test Procedure File
ATPG_SEQUENCE 0 2 =
END;
ATPG_SEQUENCE 0 3 =
END;
ATPG_SEQUENCE 1 4 =
END;
END;
Source Clocks with Different Frequencies Example

The following example defines source clocks that have different frequencies when using clock
control definitions:
timeplate _default_WFT_ =
force_pi 0 ;
measure_po 40 ;
pulse clk1 45 10;
pulse ref_clock 15 5, 40 5, 65 5, 90 5;
pulse clocks_02/my_controller/U2/Z 45 10;
period 100 ;
end;
procedure capture =
timeplate _default_WFT_;
cycle =
force_pi ;
measure_po ;
pulse_capture_clock ;
end;
end;
In this example, for one pulse of clk1, there are 4 pulses of ref_clock, specifically the ref_clock
frequency is 4 times the frequency of clk1.

December 2017
Test Procedure File
The Procedures
The Procedures
The test procedure file contains scan and clock procedures, and non-scan procedures. The scan
and clock-related procedures inform the tool how to operate the scan chain and pulse clocks.
The non-scan procedures can represent any type of pattern that the tool produces.
You can use the non-scan procedures to specify in which cycles of the procedure “potential
events” happen. A potential event is an event that the ATPG engine may or may not have
created to cover a certain fault.
To avoid DRC violations, each non-scan procedure must contain the proper statements in the
correct order with the timing from the timeplate. The statements in a non-scan procedure can be
spread over any number of cycles using a different timeplate for each cycle if needed.
A basic pattern consists of loading the scan chains, a default capture procedure, followed by
unloading the scan chains; however, you do not specify the loading and unloading of scan
chains in non-scan procedures. The following shows the basic pattern for non-scan procedures.
All example procedures shown in this section use one of the following two timeplates, unless
otherwise stated:
timeplate tp1 =
force_pi 0;
measure_po 10;
pulse scan_clk 30 10;
pulse sys_clk 30 10;
period 50;
end;
timeplate tp2 =
force_pi 0;
measure_po 10;
pulse scan_mclk 15 10;
pulse scan_sclk 30 10;
period 50;
end;
Test_Setup (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Shift (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Alternate Shift Procedure (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

December 2017
Test Procedure File
Test_Setup (Optional)
Master_Observe (Sometimes Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

Shadow_Observe (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Clock (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Skew_Load (Optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Capture Procedures (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Sub_procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
This optional procedure, which can only contain force, pulse, init, and expect event statements,
sets non-scan elements to the desired states for the load_unload procedure. You may use this
procedure only once for all scan groups, and it appears only once at the beginning of the test
pattern set.
This procedure is particularly useful for initializing boundary scan circuitry. For an example
using this procedure to set up boundary scan circuitry, refer to “Pattern Generation for a
Boundary Scan Circuit” in the Tessent Scan and ATPG User’s Manual.
Bidirectional Scan Out Pins

The value of all bidirectional scan out pins must be forced to the Z state (indicating it is
operating in “output” mode) to properly sensitize the scan chain. When reading in a test
procedure file, the tool automatically adds force events to the beginning of the load_unload
procedure to force all bidi pins to Z.
Bidi pins that are clocks or constrained pins are not forced to a Z, as they were already forced to
the off-state or the constrained values. Bidi scan-in pins are also not forced to a Z. Any bidi pin
already forced later in the load_unload procedure will not be forced to a Z. Any bidi forced to a
specific value in the test_setup procedure will instead be forced to this value instead of a Z.
Like previous automatic force values, these can be disabled by putting the “set autoforce off;”
statement at the beginning of the procedure file.

December 2017
Test Procedure File
Pin Constraints
If you use the add_input_constraints command to set pin constraints, be aware this command
only forces pins during capture. To constrain these pins during test_setup, you should include
the same pin constraints in the test_setup procedure. This will ensure the pins are in the same
state for loading the first pattern as for loading all subsequent patterns.
If you do not properly constrain the pins prior to the end of the test_setup procedure, the tool
automatically constrains them by inserting a cycle statement in the test_setup procedure.
However, this automatic handling may not insert the events with the timing you want. Also, the
automatic handling is not included in DRC.
If you have defined input constraints but have not provided a test_setup procedure, the tool will
automatically generate a test_setup procedure to force those pins to their constrained values.
You can use both the write_procfile and the report_procedures commands to see the contents of
the test_setup procedure the tool has generated. The write_procfile command writes existing
procedure and timing data to a specified file. The report_procedures command writes the
information to the screen.
Example 1
The following is an example using a sub_procedure. In this example, the signal named C will
retain its value of 1 during the test unless it is forced to a different value in a later cycle, by
another procedure, or it is overwritten by WGL patterns.
procedure sub_procedure initialize =

template soc_timeplate ;
cycle =
force C 1;
end;
end;
The following example shows how to apply the previous sub_procedure. For more information,
see “Sub_procedure” on page 360.
timeplate soc_timeplate;
cycle =
force test_en 1; // force test_en 1
force chip_en 0; // force chip_en to 0
end;
apply initialize 10 ; // force C to 1 for 10 cycles
end;
Example 2
The following example shows a way to apply initialization cycles to a memory. The RST signal
is active for the first 128 cycles, then it is deactivated in the next cycle (cycle 129).

December 2017
Test Procedure File
procedure sub_procedure reset_mem =

timeplate soc_timeplate ;
cycle =
force RST 1;
end;
end;
apply reset_mem 128;
cycle =
force RST 0; // deactivate RST
end;
end;
Example 3
The following example shows a way to use an expect statement in a test_setup procedure. The
output signal (DFT) is expected to 1 in the first cycle and X in the remaining cycle. Please note
that “expect” statements do not work the same as a force or pulse statement. When none is
present, it is assumed to mean do not measure.
cycle =
expect DFT 1 ;
end;
end;
Example 4
This example shows a way to start pulsing a clock in a test_setup procedure. The SYSCLK
starts pulsing at cycle number 2 until the end of test.
timeplate soc_timeplate =
force pi;
measure_po 90;
pulse SYSCLK 50 50;
period 100;
end;
cycle =
force RST_L 0;
end;
cycle =
pulse SYSCLK;
end;
end;

December 2017
Test Procedure File
Shift (Required)
Shift (Required)
This required procedure describes how to shift data one position down the scan chain by forcing
the scan input, toggling the clock(s), and strobing the scan output.
Figure 8-2 shows the data flow process for the shift procedure.
Figure 8-2. Shift Procedure
Within this procedure, you must use the force_sci, or force_sci_equiv, and the measure_sco
event statements. You can also use the force and pulse event statements. A shift procedure can
contain more than one cycle, although not all pattern formats can support multiple cycles and
parallel load. Pattern formats that do not support multiple cycles are any parallel format other
than STIL and Verilog. If you use write_patterns to write out one of these other parallel formats
with a multicycle shift procedure, the command generates an AG11 error.
The times at which the timeplate used by the shift procedure applies the force_sci and
measure_sco commands must allow proper operation of the load_unload procedure. The
measure_sco will occur at the measure_po time specified in the timeplate. The force_sci will
occur at the force_pi time specified in the timeplate.
The following are examples of the shift procedure for both mux-DFF and LSSD architectures.
Mux-DFF Example
procedure shift =
timeplate tp1;
cycle =
// force scan chain input
force_sci;
// measure scan chain output
measure_sco;
// pulse the scan clock
pulse scan_clk;
end;
end;

December 2017
Test Procedure File
Shift (Required)
LSSD Example
procedure shift =
timeplate tp2;
cycle =
// force scan chain input
force_sci;
// measure scan chain output
measure_sco;
// pulse master clock
pulse scan_mclk;
// pulse slave clock
pulse scan_sclk;
end;
end;
Figure 8-3 graphically displays the waveforms for the clock pin, the scan-in pin, and the scan-
out pin derived from the Mux-DFF shift procedure example. This timing diagram shows one
scan chain shift cycle, assuming the time unit is 1ns.
Figure 8-3. Timing Diagram for Shift Procedure
The procedure contains four scan events: forces scan input values at 0ns, strobes (or measures)
scan output values at 10ns, pulses the scan clock scan_clk (turning it on at 30ns and off at 40ns),
and holds the state of the last event until the procedure finishes at 50ns.
A timing clock monitors when each significant event occurs. If the timing clock is at X when
the shift procedure begins, the timing clock assigns those four events with time values X, X+10,
X+30, and X+40. When the shift procedure finishes, the timing clock advances to X+50. The
shift cycle ending time becomes the starting time for the next shift cycle.

December 2017
Test Procedure File
Alternate Shift Procedure (Optional)
Alternate Shift Procedure (Optional)

When using on-chip clock generators, such as programmable PLLs, it is sometimes necessary to
change values on input (control) signals to the clock generator a cycle or two before the change
in generated clocking schemes is realized. When the shift clocks for a scan chain are also
provided by the on-chip clock generator, it is sometimes not possible to reprogram the clock
generator near the end of the scan chain shifting in order to stop the shift clock and prepare for
the capture clocks. To accomplish this you might want to use an alternative shift procedure.
Alternate shift procedures have names, as described in the following paragraph. Alternate shift
procedures can only be used for single shifts (a pre shift or a post shift), and there must be one
un-named normal shift (shift) as the main shift in the required load_unload procedure. See
Load_Unload (Required).
The shift procedure allows for an optional name following the shift procedure type. For each
scan group, one shift procedure must be defined that has the default name of shift. For each scan
group, additional alternate shift procedures can be defined as long as each has a unique name.
Each shift procedure is required to contain a force_sci or force_sci_equiv statement and a

measure_sco statement.
Syntax
procedure shift [ procedure_name ] =

...
end ;
Example
The following is a partial example of how the alternate shift procedure might be used in a
procedure file for a scan chain with a length of 100.

December 2017
Test Procedure File
Load_Unload (Required)
timeplate tp1 =
force_pi 0;
measure_po 10;
period 100;
end;
procedure shift =
timeplate tp1;
scan_group grp1;
cycle =
force ctrl_a 1;
force_sci;
measure_sco;
pulse ref_clk;
end;
end;
procedure shift shift_last =
timeplate tp1;
scan_group grp1;
cycle =
force ctrl_a 0;
force_sci;
measure_sco;
pulse ref_clk;
end;
end;
timeplate tp1;
scan_group grp1;
cycle =
force ref_clk 0;
force scan_en 1;
force ctrl_a 1;
end;
apply shift 98;
apply shift_last 1;
apply shift_last 1;
end;
This required procedure describes how to load and unload the scan chains in the scan group. To
load the scan chain, you must force the circuit into the appropriate state for the start of the shift
sequence. This includes forcing clocks, resets, RAM write control signals, and any other signals
that need to be at their off states for scan chain loading. Also, if a reset signal is defined as a
clock, and pin constrained to its off state in the dofile, it needs to again be forced to its off state
in the load_unload and named capture procedures in order to avoid a P34 DRC.
Offstate for clock pins, constrained pin values, and other pins that have values forced in the
test_setup procedure are automatically added as force statements to the beginning of the
load_unload procedure (if not present); this helps reduce DRC failures.
Figure 8-4 shows the data flow for the load_unload procedure.

December 2017
Test Procedure File
Figure 8-4. Load_Unload Procedure
If the scan out pin is bidirectional, you must force its value to the Z state (indicating it is
operating in “output” mode) to properly sensitize the scan chain. If there is a scan enable signal,
you must force it on to enable the scan chain prior to the shift. You then use the apply shift
statement to specify the number of shift cycles (which equals the number of scan elements in the
chain). If you have optionally included the shadow_control procedure (which if used,
immediately follows the shift procedure), you must also include the apply command.
The following list includes the basic statements in the load_unload procedure:
Mux-DFF Example
timeplate tp1;
cycle =
// force clocks off
force RST 0;
force CLK 0;
// activate scanning mode
force scan_en 1;
end;
// shift data thru each of 7 cells
apply shift 7;
end;
LSSD Example
timeplate tp2;
cycle =
// force all clocks off
force RST 0;
force CLK 0;
force scan_sclk 0;
force scan_mclk 0;
end;
// apply shift procedure 7 times
apply shift 7;
end;
The timing for the load_unload procedure is generally straightforward. The load_unload
procedure contains the apply statement. Therefore, the total time for a load_unload procedure

December 2017
Test Procedure File
includes the time specified by the timeplate being used plus the time required to execute the
apply cycles.
For example, examine the following load_unload procedure, using the example shift procedure
in the previous section.
timeplate tp1;
cycle =
force RST 0;
force CLK 0;
force scan_en 1;
end;
apply shift 1;
end;
The timeplate of the load_unload procedure specifies the period is 50ns. However, the
load_unload procedure includes an apply statement that executes one shift procedure. The shift
procedure requires an additional 50ns. Thus, the load_unload procedure actually requires a total
time of 100ns, as shown in Figure 8-5.
Figure 8-5. Timing Diagram for Load_Unload Procedure
Within the load_unload procedure, after the completion of the cycle block, the shift procedure
starts at 50ns, executes for 50ns, and ends at 100ns. Thus, the load_unload procedure also ends
at 100ns.
As with the shift procedure, the timing clock determines the event times for the load_unload
procedure. If the timing clock is at Y when the load_unload procedure begins, the first three
events happen at time Y. When the apply cycle executes, the timing clock advances to Y+50,
which is when the shift procedure begins. As mentioned previously, the shift procedure requires
50 time units. Therefore, when the apply cycle finishes, the timing clock reads Y+100.
Because it is the last event in the load_unload procedure, the end of the apply cycle determines
the end of the load_unload procedure.

December 2017
Test Procedure File
Shadow_Control (Optional)
Shadow_Control (Optional)
The optional shadow_control procedure, which may only contain force and pulse event
statements, describes how to load the contents of a scan cell into the associated shadow.
If you use this procedure, you must also apply the shadow_control command in the load_unload
procedure. This procedure must not disturb the contents of any of the scan cells. Figure 8-6
shows the data flow for the shadow_control procedure.
Figure 8-6. Shadow_Control Procedure
Master_Observe (Sometimes Required)

The master_observe procedure, which may only contain force and pulse event statements,
describes how to place the contents of a master into the output of its scan cell, where you can
observe it by using the unload operation.
Figure 8-7 shows the data flow for the master_observe procedure.
Figure 8-7. Master_Observe Procedure

December 2017
Test Procedure File
Shadow_Observe (Optional)
You do not need to use this procedure if the master element’s output is the output of the scan
cell. The D1 rule ensures this procedure does not disturb master memory element’s contents.
You can override this requirement by changing the D1 rule handling. The following example
shows a master_observe procedure for the LSSD architecture:
// LSSD architecture example

procedure master_observe =
timeplate tp1;
cycle =
// Force all clocks off
force scan_sclk 0;
force scan_mclk 0;
force rst 0;
force clk 0;
// Pulse the slave clock
pulse scan_sclk;
end;
end;
Shadow_Observe (Optional)
The optional shadow_observe procedure, which may only contain force and pulse event
statements, describes how to place the contents of a shadow into the output of its scan cell,
assuming the circuitry of the scan cell allows the transfer of data in this way. Once the data is at
the scan cell output, you can observe it by applying the unload command. This procedure allows
the shadow to be used as an observation point in the design.
Figure 8-8 shows the data flow of the shadow_observe procedure.
Figure 8-8. Shadow_Observe Procedure

December 2017
Test Procedure File
Seq_Transparent (Optional)
Seq_Transparent (Optional)
The seq_transparent procedure (optional for “patterns -scan” context) identifies how to make
non-scan cells and RAM read ports functionally behave transparently. This procedure activates
the clock inputs of non-scan cell inputs, thus pulsing data through the cells “transparently.”
All clocks must be at their off-states and constrained pins at their constrained states before
applying the seq_transparent procedure. The procedure must immediately follow a force of all
the primary inputs. For more information on the sequential transparent operation, refer to
“Sequential Transparent Patterns” in the Tessent Scan and ATPG User’s Manual.
You can use multiple clock cycles to create the sequential transparent conditions. You may
define up to 32 different seq_transparent procedures within a procedure file. When simulation
mode is set to RAM_sequential, each force_all statement in the pattern file can use any of the
possible seq_transparent procedure choices. In “patterns -scan” context, the tool treats non-scan
state elements that cannot use the sequential transparent procedures as tie-X gates.
There may be occasions when you would want to use seq_transparent procedures when the
design contains no scan chains. In this case, you would use the add_scan_groups command,
specifying the name “dummy” for the group name; the tool would expect the specified test
procedure file to contain only the timeplate and seq_transparent procedure. For more
information, refer to the add_scan_groups command reference page in the Tessent Shell
Reference Manual. Figure 8-9 shows some circuitry that could benefit from a seq_transparent
procedure.
Figure 8-9. Sequential Transparent Circuitry Example
The following example shows the seq_transparent procedure for Figure 8-9.

December 2017
Test Procedure File
Clock (Optional)
timeplate tp1=
force_pi 0;
measure_po 0;
pulse clock1 30 10;
pulse clock2 30 10;
period 50;
end;
procedure seq_transparent tran1=

timeplate tp1;
cycle=
force clock1 0;
force clock2 0;
force reset 1;
end;
cycle=
pulse clock2;
end;
cycle=
restore_pi;
end;
end;
The basic stimuli necessary to create transparent behavior for the non-scan flip-flop shown in
Figure 8-9 are:
• Force all clocks off

• Pulse non-scan cell clock Clock2
• Restore primary inputs to original values
In more complex situations, you may need to set primary inputs to certain values, place
conditions on scan cells, pulse multiple clocks, and so on.
You can use the report_seq_transparent_procedures command to display data defined by the
seq_transparent procedures. For more information, refer to the
report_seq_transparent_procedures description in the Tessent Shell Reference Manual.
Clock (Optional)
The clock procedure (optional in “patterns -scan” context) provides flexible clock handling
during the test procedures. Using clock procedures, instead of pulsing a single clock during a
capture cycle, you can serially exercise multiple clocks and force non-clock pins that do not
affect captured data.

December 2017
Test Procedure File
Skew_Load (Optional)
The following example shows a clock procedure used to operate two clocks in sequence:
procedure clock clock_proc1 =

timeplate tp3;
cycle =
pulse clk1; // Pulse first clock
end;
cycle =
pulse clk2; // Pulse second clock
end;
end;
Clock procedures must abide by the following rules:
• The procedure must activate at least one clock.

• If you define multiple clock procedures, only one of these procedures can activate a
specific clock.
• The procedure events cannot violate pin constraints or equivalence conditions.
• The procedure can only force non-clock pins, if they do not affect data captured into
state elements, whose clocks may activate later in the procedure.
• Multiple clocks that activate serially cannot logically interact.
• The procedure must follow all standard rules for both clock and non-clock pin usage.
• Each clock procedure must have a unique name.
• If a state element can change state during the procedure, the element must be stable
when all clocks are off and pins are constrained.
• Transparent_capturecells are stable state elements that can capture data during the
procedure and whose new data can affect other state elements later in the procedure.
Design rule D10 ensures that these cells do not connect to state elements that capture old
data or propagate data to primary outputs.
• The procedure must set all bidirectional pins to their input mode prior to executing the
restore_bidis statement.
If a clock procedure contains a restore_bidis statement, the tool cannot use sequential ATPG.
This may cause a problem if you set the tool for multiple clock compression because multiple
clock compression uses sequential ATPG.
The optional skew_load procedure propagates the output value of the preceding scan cell into
the master memory element of the current cell without changing the slave, for all scan cells.
Using only force and pulse event statements, this procedure defines how to apply an additional
pulse of the master shift clock after the scan chains are loaded.

December 2017
Test Procedure File
Figure 8-10 shows the data flow of the skew_load procedure.
Figure 8-10. Skew_Load Procedure
Figure 8-11 shows where you apply the skew_load procedure and the master_observe procedure
within the basic scan pattern events.

December 2017
Test Procedure File
Clock_run (Optional)
Figure 8-11. Skew_load applied within Pattern
For every controller, or concurrent controller group, you can write a clock_run procedure, if
needed. The clock_run procedure has both an internal mode as well as an external mode.
You can specify only one clock_run procedure per controller or concurrent group; however, you
do not need to specify a separate procedure for each controller instance. The same procedure
can be used for multiple controllers. You need to specify a separate procedure for a controller
instance only if it maps to a different set of internal clocks.
In case of controllers running concurrently, and some of these controllers clocks are driven by
PLL internal clocks, the clock_run procedure is required per concurrent group. It is not required
for every BIST controller participating in the group to have its clock driven by a PLL internal
clock. For some controllers, their clocks can be driven by a PLL reference clock or even by a
system clock.

December 2017
Test Procedure File
The tool relies on you to control the PLL control signal. This can be achieved by forcing the
PLL control signal to a proper value in a test_setup procedure and in external mode of
clock_run procedure as well (it depends on the PLL model behavior).
A clock_run procedure has to have a N-to-1 or 1-to-N ratio between internal and external
cycles; that is, either the internal mode has to have only one cycle, or the external mode has to
have only one cycle. You cannot have, for example, two external cycles and three internal
cycles.
Example
In this example, consider a PLL model that has two clocks: a reference clock and an internal
clock. Based on the PLL control signal:
• The internal clock is 2X faster than the reference clock when PLL control is 0.
• The internal clock is 4X faster than the reference clock when PLL control is 1.
If you wanted a PLL internal clock to drive the BIST controller clock, use the following
MBISTArchitect commands in your BIST insertion dofile to define the clocks and make the
proper connection.
add clocks 0 PLL/int_clk add clocks 0 topPLLclk add pin

mapping /PLL/int_clk /controller/bist_clk
The PLL control is set to 0 using a test_setup procedure as follows:
cycle =
force PLL_Control 0 ;
pulse topPLLclk;
end;
end;
The following snippet has a clock_run procedure that describes the PLL model behavior
assuming that the PLL_Control is set to 0 as described in the previous test_setup procedure.

December 2017
Test Procedure File
timeplate timeplate_internal =
force_pi 0 ;
measure_po 90 ;
pulse PLL/int_clk 5 50 ; // speed is 2X
period 100 ;
end ;
timeplate timeplate_external =
force_pi 0 ;
measure_po 180 ;
pulse topPLLclk 5 100 ;
period 200 ;
end ;
procedure clock_run pll_clk=
mode internal =
timeplate timeplate_internal ;
cycle =
pulse PLL/int_clk ;
end ;
cycle =
pulse PLL/int_clk ;
end ;
end ;
mode external =
timeplate timeplate_external ;
cycle =
pulse topPLLclk ; // connected to reference clock
end ;
end ;
end ;

December 2017
Test Procedure File
Capture Procedures (Optional)

There are three types of capture procedures. These procedures are optional in the
“patterns -scan” context.
• The default capture procedure is an optional capture procedure, without a name, that
provides information on how the series of capture events are broken into cycles and
which timeplates these cycles use. The default capture procedure is defined in the
procfile as part of the scan group definition or internally derived by the tool when you do
not define one. If you need to create or edit a default capture procedure, see “Clock_po
(Optional)” in this chapter.
• The named capture procedure is an optional capture procedure, with a name, that is used
to define explicit clock cycles. You can create multiple named capture procedures, each
with a unique name, using the create_capture_procedures command. If you need to
manually create or edit named capture procedures, see “Rules for Creating and Editing
Named Capture Procedures” in this chapter. For information on using named capture
procedures to create at-speed test patterns, see “At-Speed Test With Named Capture
Procedures” in the Tessent Scan and ATPG User’s Manual.
• The external_capture procedure is an optional capture procedure used for all capture
cycles between each scan load, even when the pattern is a multi-load pattern.
External_capture procedures are used by the “set_external_capture_options
-capture_procedure” command. External_capture procedures that are used with this
command have several restrictions:
o The procedure can only have one force_pi statement and no measure_po statements.
This is because in order to use the “set_external_capture_options
-capture_procedure” switch, the patterns to be saved must be hold_pi and mask_po
patterns. The statements in the capture procedure must match up to this.
o Unlike named capture procedures, the external_capture procedure cannot have any
load_cycles as it is meant to be used between each scan load of a pattern. The
external_capture cannot contain any events on internal signals.
o When using the -capture_procedure switch with set_external_capture_options, all
clocks in the design that are internally connected (don't trace to just a cut point),
must be controlled. In addition, the clocks must either be constrained, always-
capture, controlled by a clock_control definition, or the clock must have an event in
the external_capture procedure.
Rules for Creating and Editing a Default Capture Procedure . . . . . . . . . . . . . . . . . . . . 350
Rules for Creating and Editing Named Capture Procedures . . . . . . . . . . . . . . . . . . . . . 350
Slow and Load Types in the Cycle Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
launch_capture_pair Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Viewing Optimized Named Capture Procedures (NCPs) . . . . . . . . . . . . . . . . . . . . . . . . 354

December 2017
Test Procedure File
Rules for Creating and Editing a Default Capture

Procedure
There are several issues to consider when working with default capture procedures.
• The default procedure may only contain force_pi, measure_po, pulse_capture_clock,
bidir_force, bidi_force_pi, bidi_force_off, and bidi_measure_po event statements that
represent the non-scan activity for a normal pattern. There is no overlap between the
capture procedure and the existing clock procedure.
• Use the pulse_capture_clock statement in the default capture procedure to indicate in
which cycle one or more capture clocks should be pulsed.
• Do not specify any complex clocking that needs to be described for capture clocks or
other clocks in the default capture procedure; specify it in the clock procedure or by
using a named capture procedure.
• Do not specify any type of pin or ATPG constraint in the default capture procedure. For
example, specifying that a certain pin is to be held at a certain state in the default capture
procedure does not restrict the ATPG engine from applying different values to that pin.
However, you can use the bidi_force and bidi_force_pi statements in the default capture
procedure to force all bidirectional pins off in one cycle and force the ATPG values on
the bidirectional pins in the next cycle.
Rules for Creating and Editing Named Capture

Procedures
There are several issues to consider when working with named capture procedures.
• A named capture procedure may only contain force_pi, measure_po, observe_method,
pulse (named clock), and condition statements.
• If you use mode definitions, all cycles in a procedure must be defined within mode
definitions. Use the keyword “mode” with two mode blocks: “internal” and “external”.
Use the mode_internal definition to describe what happens on the internal side of the on-
chip PLL. Use the mode_external definition to describe what happens on the external
side of the on-chip PLL.
• All events in a named capture procedure that use modes must be duplicated in both
modes. The only difference is that the internal mode uses only internal clocks and the
external mode uses only external clocks. The number of cycles and timeplates used can
be different as long as the total period of both modes is the same.
• Signal events used in both internal and external modes must happen at the same time.
Examples of these events are force_pi, measure_po, and other signal forces, but also
include clocks that can be used in both modes.

December 2017
Test Procedure File
o If a measure_po statement is used, it can only appear in the last cycle of the internal
mode and must occur before the last clock pulse. If no measure_po statement is used,
the tool issues a warning that the primary outputs will not be observed.
o The cumulative time from the start of the first cycle to the measure_po must be the
same in both modes.
o The external mode cannot pulse any internal clocks or force any internal control
signals.
o A force_pi statement needs to appear in the first cycle of both modes and occur
before the first pulse of a clock.
o If an external clock goes to the PLL and to other internal circuitry, a C2 DRC
violation is issued.
o At-speed cycles need to be continuous; that is, a named capture procedure cannot
have more than one at-speed clocking subsequence.
o All defined real clocks (excluding internal clocks) must be forced to off state first in
the mode_internal definition.
For more information, see “Internal and External Modes Definition” in the Tessent Scan
• Do not use the pulse_capture_clock statement in a named capture procedure. The clocks
used are explicitly pulsed.
• If you want to specify the internal conditions that need to be met at certain scan cells in
order to enable a clock sequence, use the condition statement at the beginning of the
cycle statement in the named capture procedure.
• If you want to define a specific observe method for each named capture procedure, use
the observe_method statement in the named capture procedure; otherwise, the ATPG
engine automatically selects master, slave, or shadow observation.
Note
The write_patterns command allows you to save internal or external clock patterns.
Internal clock patterns can be used to simulate the DUT without having the PLL
modeled, while the external patterns only exercise the PLL external clocks and control
signals. Internal patterns are the default for ASCII and binary formats, and external
patterns are the default for tester formats.
• If you generate patterns using a named capture procedure that has both internal and
external modes and you save them in STIL or WGL format, you must use the
write_patterns command’s “internal” option to read them back into the tool (for
example, to use in diagnosis). For more information and for information about special
considerations that apply to LBIST mode in the TK/LBIST Hybrid flow, refer to the
-Mode_internal and -Mode_external switches for the write_patterns command in the
Tessent Shell Reference Manual.

December 2017
Test Procedure File
DRC rules W20 through W36 check named capture procedures. If a DRC error prevents use of
a capture procedure, the run aborts.
Slow and Load Types in the Cycle Statement

Optionally, you can add a “slow” or a “load” type to the cycle definition.
For example:
cycle slow =
...
end;
• The slow cycle indicates that at-speed faults cannot be launched or captured. The tool
must know which at-speed cycles are slow in order to get accurate at-speed fault
coverage simulation numbers; therefore, be sure to include “slow” when defining cycles
that are not at-speed cycles in an at-speed capture procedure.
Note
At-speed cycles need to be continuous; that is, a named capture procedure cannot
have more than one at-speed clocking subsequence.
• The load cycle indicates that the cycle is always preceded by an extra scan load. The
first cycle in a named capture procedure is always a load (with or without the load type
designation), so you typically apply “load” to subsequent cycles. An at-speed launch
cycle can be a load cycle; however, none of the cycles that follow in the at-speed
sequence, up to and including the capture cycle, can be load cycles.
Note
To get extra loads, you must enable the tool’s multiple load and clock sequential
capabilities by issuing the set_pattern_type command with “-multiple load on” and
“-sequential <2 or greater>”. For more information, see “Multiple Load Patterns” in the

December 2017
Test Procedure File
The following example illustrates the “slow” and “load” attributes:
procedure capture multi_load_example =

timeplate tp1;
// first cycle is always a load, with or without load type designation
cycle slow =
force_pi;
force wr_enable 1;
pulse int_clk1;
end;
cycle slow load =
pulse int_clk1;
end;
cycle =
force re_enable 1;
pulse int_clk1; // launch clock
end;
cycle =
pulse int_clk1; // capture clock
end;
end; // end of capture procedure
launch_capture_pair Statement
Optionally, you can add one or more “launch_capture_pair” statements to the beginning of a
named capture procedure. This statement defines legal at-speed launch and capture points in
non-adjacent cycles. If you do not use the launch_capture_pair statement, the tool will launch
and capture only in adjacent cycles. If at least one launch and capture clock pair is defined, the
launch and capture points are derived from the defined launch and capture clock pairs.
Note
This statement is only supported when using a named capture procedure to perform test
generation.
The syntax of the launch_capture_pair statement is as follows:
launch_capture_pair <launch_clock_pin_name> <capture_clock_pin_name>;
Where:
• launch_clock_pin_name is the clock used to launch the transition.

• capture_clock_pin_name is the clock used to capture the transition.
The launch clock cycle is used to check the transition condition. The capture clock cycle is used
to capture the transition fault effect. The cycles between the launch clock and capture clock
must be at-speed cycles. They cannot include any slow cycles between them. The faults to be
tested by the named capture procedure with the defined launch and capture clock pair are the
faults that can be launched by the launch clock and captured by the capture clock defined in the
launch_capture_pair statement.

December 2017
Test Procedure File
The following is an example of the launch_capture_pair statement:
procedure capture c1_c1 =

launch_capture_pair c1 c1;
cycle = // cycle 1
force_pi;
force c1 0;
force c2 0;
force c3 0;
pulse c1;
end;
cycle = // cycle 2
pulse c2;
end;
cycle = // cycle 3
pulse c1;
pulse c3;
end;
end; // end of capture procedure
In this example, a valid launch can happen in cycle 1. A valid capture can happen in cycle 3
only with c1 as the capture clock. A launch in cycle 1 and a capture in cycle 2 is not used for
fault detection. The faults to be tested by this named capture procedure are the faults that can be
launched and captured by clock c1.
Viewing Optimized Named Capture Procedures (NCPs)

Use this procedure when creating or debugging NCPs in order to view optimized information
for an individual NCP. For more information on the optimizing process, see the
report_capture_procedures command in the Tessent Shell Reference Manual.
Prerequisites
• DFTVisualizer is invoked and the Wave window is open and active.
• At least one NCP is defined in the test procedure file.
Procedure
1. Choose Windows > Data to open the Data window.
2. Choose Windows > Wave window to open the Wave window.
3. Select the Data > Named Capture menu item and choose the NCP you want to view.
4. Click the icon to view the optimized NCPs; click the icon to return to viewing
unoptimized NCPs.

December 2017
Test Procedure File
Clock_po (Optional)
Clock_po (Optional)
The clock_po procedure (optional in “patterns -scan” context), which can contain only force_pi,
measure_po, bidi_force_pi, and bidi_force_off event statements, represents the non-scan
activity for a clock PO pattern. Use this procedure instead of the capture procedure.
Note that with this procedure, you must use a timeplate that does not pulse the clocks.
The following shows the pattern for the clock_po procedure pattern.
Ram_sequential (Optional)
The ram_sequential procedure (optional for “patterns -scan” context), which may only contain
force_pi, pulse_write_clock, pulse_read_clock, bidi_force_pi, and bidi_force_off event
statements, represents the RAM sequential events in a RAM sequential pattern. Use this
procedure with the capture procedure.
The following illustrates the basic ram_sequential procedure pattern format.
Figure 8-12 shows an entire RAM sequential pattern, which illustrates where the
ram_sequential and capture procedures are used.

December 2017
Test Procedure File
Ram_passthru (Optional)
Figure 8-12. Full Ram Sequential Pattern
Ram_passthru (Optional)
The ram_passthru procedure (optional in “patterns -scan” context), which may only contain
force_pi, measure_po, pulse_write_clock, pulse_capture_clock, bidi_force_pi, bidi_force_off,
and bidi_measure_po event statements, represents the non-scan activity for a RAM passthrough
pattern. Use this procedure instead of the capture procedure.
The following shows the ram_passthru procedure pattern.

December 2017
Test Procedure File
Clock_sequential (Optional)
Clock_sequential (Optional)
The clock_sequential procedure (optional for “patterns -scan” context), which may only contain
force_pi, pulse_write_clock, pulse_read_clock, pulse_capture_clock, bidi_force_pi, and
bidi_force_off event statements, represents the clock sequential events in a clock sequential
pattern. Use this procedure with the capture procedure.
The following shows the clock_sequential procedure pattern.
Figure 8-13 shows an entire clock sequential pattern, which illustrates where the
clock_sequential and capture procedures are used.
Figure 8-13. Full Clock Sequential Pattern

December 2017
Test Procedure File
Init_force (Optional)
Init_force (Optional)
The init_force procedure (optional for “patterns -scan” context), which may only contain
force_pi event statements, represents the force cycle that is used in an ATPG pattern that targets
a transition fault. The transition must be launched off of the last scan chain shift. This procedure
is used when the fault type is set to transition fault and either the depth is set to 2 or less or the
ATPG engines fail to find a sequential pattern that can cover this transition fault. Use this
procedure with the capture procedure.
The following illustrates the format of the init_force procedure pattern.
Figure 8-14 shows the pattern which uses the init_force procedure.
Figure 8-14. Init_force Procedure Usage
Test_end (Optional, all ATPG tools)

The optional test_end procedure is used to add a sequence of events to the end of a test pattern
set.
The test_end procedure may only contain force and pulse event statements (see the following
exception), and can only be defined once for all scan groups. When saving patterns, the test_end
procedure will be applied to the end of each pattern set saved.
The following shows the general pattern for the test_end procedure pattern.

December 2017
Test Procedure File
Test_end (Optional, all ATPG tools)
Example 1: Using test_end in a Procedure File

The following is a partial example of how the test_end procedure might be used in a procedure
file:
timeplate tp1 =
force_pi 0;
measure_po 10;
period 100;
end;
procedure test_end =
timeplate tp1;
cycle =
force ctrl_a 1;
force tms 0;
pulse ref_clk;
end;
end;

December 2017
Test Procedure File
Sub_procedure
Example 2: Test_end Procedure with Timeplate

The following is an example test_end procedure with its corresponding timeplate:
timeplate tp4 =
force_pi 0;
pulse TCK 10 10;
measure_po 30;
period 40;
end;
procedure test_end =
timeplate tp4;
cycle =
// TMS = 1, change to select-DR state
force TDI 1;
force TMS 1;
pulse TCK;
end;
cycle =
// TMS = 0, change to capture-DR state
...
cycle =
// Scan out signature (MISR has length of 4)
force TDI 1;
force TMS 0;
pulse TCK;
end;
cycle =
force TDI 1;
force TMS 0;
pulse TCK ;
end;
...
end;
Sub_procedure
The sub_procedure procedure eliminates the need to insert duplicate actions within a procedure.
Once you have defined a sub_procedure, you can specify this procedure within other procedures
using the apply statement.
You can also set the tool to reissue the sub_procedure as many times as needed by specifying
the repeat_count. Because the repeat_count is required when using apply sub_procedure, you
must enter a minimum of 1 for this parameter.
Sub_procedure Looping
Sub_procedure looping is used to reduce the size of pattern files. The default behavior of the
sub_procedure is to use “loops” or “repeats” in all applicable pattern formats to repeat the
contents of the sub_procedure N times, where N is greater than 1.

December 2017
Test Procedure File
Sub_procedure
Disabling Sub_procedure Looping

If you want the event data in a sub_procedure to be expanded and represented as N sets of
vectors in the pattern file, where N is the number of times the sub_procedure is applied, use the
“ALL_NO_LOOP 1” parameter file keyword to disable the use of “loop” or “repeat”
statements.
For example, if the test_setup procedure has the following statement:
apply pulse_bclock 1000;
The vector data for the sub_procedure “pulse_bclock” would be expanded to be 1000 vectors.
The default for the ALL_NO_LOOP keyword is off (0).
Sub_procedure Definition Format

The sub_procedure definition has the following format.
procedure sub_procedure my_subprocedure =

timeplate tp1;
cycle =
force_pi;
measure_po;
end;
end;
Using the Sub_procedure in a Procedure

The following is an example of how to use the sub_procedure in a procedure.
procedure shift =
scan_group grp1;
timeplate tp1;
apply my_subprocedure 4;
cycle =
force_sci;
measure_sco;
pulse T;
end;
end;
Note
You must first define a sub_procedure before using it in a procedure. Next, you can apply a
sub_procedure within any procedure type. Also, you cannot use a sub_procedure within the
“cycle =” and “end;” statements.

December 2017
Test Procedure File
Additional Support for Test Procedure Files
Additional Support for Test Procedure Files

Tessent Shell provides additional support so that you can use environmental variable, merge,
default template capabilities with your test procedure files.
Tcl Variables Used for Substitution and Conditional Selection

The procfile is allowed to include Tcl variables to provide parameterized values within the
procfile statements. The Tcl variables must be set in the global Tcl namespace. If you are setting
the variables within a proc, make sure to use :: as a prefix to the variable name such that it is set
in the global namespace. For example, use "set ::my_period 4" such that $period exits when
processing the proc files.
The Tcl variable can also be used to evaluate the condition of a Tcl if command located inside
the procfile. The element of a list of ports in the procfile must be separated by commas. If the
port names are escaped identifiers, they must be enclosed in quotes. Use the method shown in
the following example to convert a list of port names into a quoted comma-separated list needed
in the proc file:
Command invoked in the dofile:
set ::add_clocks_timing 1
set ::edges "25 75"
set ::port_list [get_name_list [get_clocks -type sync_source]
set ::all_clocks [string cat {"} [join $port_list {", "}] {"}]
set_procfile_name ./myproc
Given the content of the ./myproc is:
alias all_clocks = $all_clocks;

timeplate mytimeplate =
if {$add_clocks_timing} {
pulse all_clocks $edges;
}
end;
The report_procedures command will show:
alias all_clocks = "clk1", "clk2", clk3";

timeplate mytimeplate =
pulse all_clocks 25 75;
end;
Merging Procedure Files

It is possible to specify more than one procedure file for a design. You can specify a procedure
file with the add_scan_groups command or with the read_procfile command. You need to
supply (to the ATPG tool) a minimum set of information in the procedure file with the
add_scan_groups command. You must supply all event information for the scan procedures.

December 2017
Test Procedure File
Creating Test Procedure Files for End Measure Mode
However, after leaving setup mode, it is possible to specify non-scan procedures, timeplates,
and new timing for the scan procedures by reading in an additional procedure file with the
read_procfile command. Specifying new information for the same design, from more than one
procedure file, is known as “merging the procedure files.” To properly merge the information
from multiple procedure files, the Vector Interfaces code follows these rules:
• All scan procedures that you will use must be specified in the procedure file that you
load with the add_scan_groups command.
• If you load a procedure that contains nothing but the procedure name, a timeplate name,
and an optional scan group, it is a template procedure. If a procedure already exists by
that name for that scan group (if it is a group-specific procedure), then the timeplate is
mapped onto the existing procedure. If no procedure already exists with that name, the
tool stores the template procedure for future use.
• If you load a new complete procedure (not a template) and a procedure already exists by
that name for the specified scan group (if applicable), the new procedure overwrites the
existing one.
• In both cases, when a procedure overwrites an existing one, or if a new timeplate is
mapped to an old procedure, the tool checks the procedures to make sure that the
sequence of events in the new procedure does not differ from the old procedure.
Default Information Provided by the Tool

When you issue the write_patterns command, the tool checks to make sure that all procedures
and timeplates needed to save the patterns in the specified format are present.
If there are any missing non-scan procedures, the tool creates default procedures and issues a
warning. For example, in cases where there are ram_sequential patterns that need to be saved
and no ram_sequential procedure was supplied, the tool automatically creates a default
procedure.
For any procedures that are created or that do not have a timeplate specified, the default
timeplate is mapped to these procedures, if it is set. You can set the default timeplate by using
the set default_timeplate statement previously described in the “Set Statement” section. If you
use this statement, the timeplate specified when creating default procedures is used. If the
default procedure needs to be created and no default timeplate has been set, then the first
timeplate specified is used. If no timeplates are specified, a default timeplate is created as well.
Creating Test Procedure Files for End Measure

Mode
You can create test procedure files that enable end measure mode. End measure mode refers to
the special handling that the Vector Interfaces code needs to move the measure to the end of the
shift and capture cycle.

December 2017
Test Procedure File
Prerequisites
• A test procedure file.
Procedure
1. Create a new timeplate that measures the outputs after the clock pulse.
2. Change the timeplate for the shift and load_unload to point to the new timeplate.
3. Add the measure_sco statement to the load_unload procedure.
4. Make sure all shift procedures have the measure_sco statement after the shift clock.
When end measure mode is enabled, the measure_sco statement measures the next value
from the output of the scan chain. The very first value for the output of the scan chain is
measured by a measure_sco statement in the load_unload procedure.
5. Change the timeplate for the capture cycle by breaking it into two cycles. Move the
capture clock to the second cycle of the capture procedure to allow the measure at the
end. In the first cycle, the force_pi and measure_po are performed. In the second cycle,
the capture clock is pulsed. When using end measure mode, a measure cannot be
performed after the capture clock.

December 2017
Test Procedure File
Examples
set time scale 1.000000 ns ;
timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse clk 20 10;
pulse edt_clock 20 10;
pulse ramclk 20 10;
period 40 ;
end;
// CREATE A NEW TIMEPLATE THAT MEASURES AFTER THE CLOCK PULSE
timeplate gen_tp2 =
force_pi 0 ;
// measure_po 10 ;
pulse clk 20 10;
pulse edt_clock 20 10;
pulse ramclk 20 10;
measure_po 35 ; // <<== NEW MEASURE STATEMENT
period 40 ;
end;
// FOR CAPTURE SPLIT INTO TWO CYCLES
procedure capture =
timeplate gen_tp1 ;
cycle =
force_pi ;
measure_po ;
end ;
cycle =
pulse_capture_clock ;
end;
end;
// FOR THE SHIFT AND LOAD_UNLOAD, USE THE NEW TIMEPLATE
procedure shift =
scan_group grp1 ;
timeplate gen_tp2 ; //<<=== NEW TIMEPLATE
cycle =
force_sci ;
force edt_update 0 ;
measure_sco ;
pulse clk ;
pulse edt_clock ;
end;
end;
// ADD A MEASURE_SCO TO THE LOAD_UNLOAD PROCEDURE
scan_group grp1 ;
timeplate gen_tp2 ; //<<=== NEW TIMEPLATE
cycle =
force clk 0 ;
force edt_bypass 0 ;
force edt_clock 0 ;
force edt_update 1 ;
force ramclk 0 ;
force scan_en 1 ;
pulse edt_clock ;
measure_sco; //<<=== NEW MEASURE STATEMENT

December 2017
Test Procedure File
end ;
apply shift 39;
end;
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
end;
end;

December 2017
Test Procedure File
Serial Register Load and Unload for LogicBIST and ATPG
Serial Register Load and Unload for LogicBIST

and ATPG
You can use the test_setup or test_end test procedure file procedures to serially load or unload
control registers in the circuit under test. Additionally, this section discusses the commands you
must add to your dofile to use this functionality.
Serial register load and unload targets the following flows:
• Logic BIST — Used to serially unload certain registers (for example, MISRs) using the
test_end procedure.
• Low Pin Count Test — Used to serially load registers with test information through a
serial access port such as a JTAG TAP controller.
Static Versus Dynamic Register Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Dofile Modifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Serial Load and Unload DRC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Register Load and Unload Use Models

Using serial register load and unload allows you to identify a load/unload register variable value
in the test procedure file and define this variable, either static or dynamic, using commands in
your Tessent dofile. By using this functionality, you can load control registers by using a type of
load procedure where the data value for the register can be passed as a string of values, and the
load register uses a shift mechanism to show how this string of data values is shifted into the
register.
To serially load/unload register value variables, you must make modifications to your test
procedure file and your Tessent dofile.
The register value variable is used in the test procedure file to load the value into a register
through the data input pin, or unload a value from a register through the data output pin. The
load/unload procedures support pin inversions, but you must explicitly specify this.
The registers to be loaded/unloaded can be cascaded such that one load or unload operation
loads or unloads multiple values, for example PRPG/MISR values.
Static Versus Dynamic Register Variables

You can define both static and dynamic register value variables.

December 2017
Test Procedure File
Test Procedure File Modifications
• Static variable — A specific register value variable string you specify during setup
mode. Once set, you cannot change this variable.
• Dynamic variable — A register value variable string that you can define or change later,
and can use tool-specific switches.
Static Variable
A static register variable is one where the value is assigned to the variable when the variable is
defined (using the add_register_value), and this value then cannot be changed. This static value
is used by DRC when simulating the procedures. A static variable cannot be set using tool
specific switches to link the variable to tool computed values, as these may change.
Dynamic Variable
A dynamic register value variable uses tool-specific switches and arguments to link the variable
to a value computed by the tool. If you use a dynamic variable, then you must specify the
register’s width unless the tool knows this value at the time DRC is run (for example, PRPG
size).
This method is used for defining a variable that has a tool-specific computed value that is
available when patterns are saved and needs to be loaded or unloaded by the test_setup or
test_end procedures. The value defaults to all X bits, and you can specify the actual value can
non-Setup mode by using the set_register_value command.
If no value is specified the first time DRC is invoked after adding a register value variable, the
tool considers the variable to be dynamic for DRC and any future invocation of DRC.

In the test procedure file, the load_unload_registers Procedure and shift Keyword are used.
load_unload_registers Procedure
The load_unload_registers procedure is a named procedure; consequently, you can have
multiple occurrences of this procedure, corresponding to multiple groups of registers that need
to be loaded and/or unloaded. The load_unload_registers procedure can only be called from the
following procedures:
• test_setup
• test_end
The load_unload_registers procedure can load, unload, or both. Additionally, one application of
the procedure can load/unload multiple cascaded registers.

December 2017
Test Procedure File
When the test procedure file explicitly calls the load_unload_registers procedure from either the
test_setup or test_end procedures, the values to load or unload are passed to the procedure using
the string of binary values (value hard-coded in the procedure application) or the register value
variables.
shift Keyword
The load_unload_registers procedure uses the shift keyword to define a block of events that
result in one shift operation. This is similar to the IEEE STIL syntax where the shift keyword
defines a shift block within a load or unload procedure. It is analogous to embedding the shift
procedure into the load_unload procedure.
Apply Statement Extension

The apply statement in the procedure file syntax is extended in order to accept a statement that
associates a set of string values or register value variables with a particular input pin, output pin,
or alias. This pin or alias must then be used within the shift statement and have a “#” character
associated with it. This character is a placeholder for the values that will be loaded or unloaded
using the string of values passed to the procedure, or the internally generated values associated
with the value name.

The following illustrates using the load_unload_registers procedure and shift keyword:
procedure load_unload_registers procedure_name =

...
[ cycle blocks ]
shift =
cycle blocks
end ;
[ cycle blocks ]
end ;
The load_unload_registers procedure must have a shift block defined, which has one or more
cycles used to shift the data into the data input pin or the data out of the data output pin. The
procedure can also optionally have cycles which precede or follow the shift block, to be used to
put the circuit into shift mode or finish the shift mode when done, similar to how a load_unload
procedure is used.
Event Statements
Within a shift block, at least one event statements in a load_unload_registers procedure must
use the “#” character to denote where the shift data passed into the procedure is used.
The event statement must be either a “force” event or an “expect” event. An event statement
with the “#” character can also occur in the cycles preceding or following the “shift” block in

December 2017
Test Procedure File
order to express pre-shifts and post-shifts for loading the register. This event statement has the
following syntax:
<force | expect > pin_or_alias_name # ;
The apply statement which is currently used to call shift and sub_procedure procedures and also
calls the load_unload_registers procedure. When calling these procedures, however, the number
of times argument in the apply statement is replaced with one or more value assignments to the
data in and/or data out pins.
apply procedure_name [ #times | shift_data_assignment

[ , shift_data_assignment ...] ] ;
A shift_data_assignment has the following syntax:
identifier = < value_string | register_value_variable >

[<value_string | register_value_variable>...]
where identifier is either a pin name or an alias name.
The identifier used in the shift_data_assignment must match an identifier used within the
procedure in one of the event statements with the “#” character.
Register Value Strings

A register value string (value_string) is one of the following:
• A binary string of 0’s, 1’s or X’s, where the length of the string determines the number
of shifts to load the register.
• A string of a different radix as long as the Verilog syntax of identifying the radix and
width are used, such as “32’h” for a 32 bit hexadecimal value.
If a register_value_variable is used in the shift_data_assignment, then a value computed by the
tool for that register_value_variable (as bound within the dofile) or hard-coded in the dofile is
loaded or unloaded at that time and the shift length is also provided by the tool. It is possible for
more than one value_string or register_value_variable to be assigned to an identifier in one
shift_data_assignment. In this case, the extra values are separated by spaces. This allows
multiple shorter values to be shifted into one register group.
The typical usage is that each register_value_variable corresponds to one register being loaded,
and the specification of multiple variables is used when those registers are cascaded and loaded/
unload on after another.
Alias Names
It is possible to use an alias name in the procedure type for loading shift data, even if that alias
name refers to multiple pins. If this is the case, the number of bits assigned by the “#” character

December 2017
Test Procedure File
Dofile Modifications
for each shift is equal to the width of the alias being used. The length of the value string being
passed to the procedure must be a multiple of the width of the alias.
Loading or unloading an alias can be used if performing parallel load/unload and no shift is
required. For example, if each MISR bit is connected to a separate primary output. Even if no
shifting is required, the functionality is still useful to bind the expected values to the signature
computed by the tool.
If multiple shift_data_assignments are passed to a procedure, then all of them must have the
same shift length such that each pin being loaded/unloaded requires the same number of cycles
to load/unload all the data. No padding is performed by the tool.
If a “measure” event is used in one of these procedures to unload a register, then these measure
values can be compared in the final patterns and the Verilog testbench.
You define register value variables using commands you issue to the tool interactively or in a
dofile. The value variables are subsequently referenced in the procedure file.
You use the following commands to perform these operations:
• add_register_value
• set_register_value
• delete_register_value
• report_register_value
Addition of a Register Value Variable

The add_register_value command defines the register value variables. You can define the
variables as either static value variables or dynamic value variables.
You can only use this command in setup mode. You must define the register value variables in
the dofile before the variables are used in a test procedure file to load values into the registers.
Static Value Variables

You specify a static value variable by stating a specific value string. This value variable then
has this value string as a constant value.
You must specify this value in setup mode; the value is considered to be static by default, and
the value is present when simulating procedures in DRC.
add_register_value value_name {value_string [-Radix {Binary | Decimal |

Octal | hexadecimal} -Width integer]} optional_arguments

December 2017
Test Procedure File
The value_name is a user-specified identifier, and the value_string is a state string in a

particular radix. The default is binary radix.
If the –Radix switch is used to change this to a different radix, then a register width must also be
specified using the –Width switch.
Dynamic Value Variables

You specify a dynamic value variable using the following variation of the command:
add_register_value value_name value_string -Dynamic -Width integer

optional_arguments
The value_string is optional and defaults to all X bits if not specified.
You can subsequently enter the actual value once you have exited setup mode using the
set_register_value command. If no value is specified the first time DRC is invoked after adding
a register value variable, it will be considered as dynamic in this and any future invocation of
DRC.
Data Pin Inversions

When using either a static or dynamic variable, you can optionally specify inversions on the
input and output data pins by using the -INput_pin_inversion and -OUtput_pin_inversion
switches, respectively.
These are optional switches you use to specify that the data value in this variable should be
inverted before it is loaded into the register through the load_unload_register procedure.
Definition of a Dynamic Register Value Variable

You can define a dynamic register value variable by using tool-specific switches and arguments
to link the variable to a value computed by the tool. These variables are dynamic, and the width
must be specified unless the width is known to the tool at the time DRC is run.
This method is used for defining a variable that has a tool-specific computed value that will be
available when patterns are saved and needs to be loaded or unloaded by the test_setup or
test_end procedures.
In this case, you use the add_register_value command with the -Width switch and omit the
value while in setup mode. Once you have exited setup mode, you can use the
set_register_value command to set the variable:
set_register_value value_name value_string [-RAdix {BInary | HEx | OCtal |

Decimal}]
The name of the register value and its width are known prior to parsing the procedure file and
running DRCs. The value will be all X bits for DRC.

December 2017
Test Procedure File
This command can only be used for a register value that was defined without a value string, and
the width of the value string must match the width specified in the add_register_value
command.
If the value overflows the width specified, an error is issued.
By default, the bits extracted by force/measure “#” in the procedure are from MSB to LSB. If
the value specified should be shifted in/out in the opposite order, with the LSB bits applied/
measured first, use the “-LSB_shifted_first” optional switch.
Deletion of a Register Value Variable

The delete_register_value command deletes all or a specified register value variable. You can
only use this command in setup mode.
Register Value Variable Reports

The report_register_value command provides a detailed report of the register value variables to
stdout or, optionally, a file.

December 2017
Test Procedure File
Serial Load and Unload DRC Rules

The P13 and P54, P66, and W5 DRC rules are applied to the procedures and syntax in the
section “Procedure Examples.”
The P1 “syntax error” message will be used to catch many potential issues, such as specifying a
“#times” value for applying a load_unload_registers procedure instead of the
shift_data_assignment.
P13 and P54 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

P66 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
W5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Procedure Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
P13 and P54

The P13 and P54 rules are used to check the shift assignment statements when calling a
load_unload_registers procedure.
If the shift assignment uses a value string that is not properly formatted or contains illegal
characters for that radix, then a P13 is issued.
Error: Invalid state value state string. (P13)
If the shift assignment references an undefined register value variable name, a P54 is issued.
Error: Undefined identifier identifier_string referenced by signal_name.

(P54)
P66
The P66 rule is used to check for missing statements within a load_unload_registers procedure.
For example, if no Shift block is specified, or if an event statement using the “#’ character is not
present for each shift_assignment passed to the load_unload_registers procedure, then a P66 is
issued.
Error: Procedure procedure_name is missing required statement_string

statement. (P66)
The following examples illustrate the types of P66 DRC errors you could encounter.

December 2017
Test Procedure File
Example 1
In the following example, the tool issues this error if there is no shift block within the
load_unload registers procedure:
Error: Procedure procedure_name is missing required shift statement.

(P66)
Example 2
In the following example, the tool issues this error if there are no events in the
load_unload_register procedure that use the “#’ substitute character.
Error: Procedure procedure_name is missing required substitute event

statement. (P66)
Example 3
In the following example, the tool issues this error if an apply statement that uses a
load_unload_registers procedure has a shift data assignment that uses a signal that does not
appear in the load_unload_registers procedure with the substitute character “#’.
Error: Procedure procedure_name is missing event using shift assign

signal_name statement. (P66)
W5
The W5 DRC error is used to flag any extra events or statements in a load_unload_registers
procedure, or any events that are not legal.
For example, if an event type other than Force or Expect is used with the “#’ substitute
character, then a W05 rule will be issued. If the load_unload_registers procedure contains more
than one shift block, this rule will be issued. If there is a Force or Expect statement using a “#’
character for a signal name that is not being passed to the procedure as a shift assignment, this
rule will be issued. The W05 rule is used when shift assignments for a particular Apply
statement do not all have the same length.
Error: Procedure procedure_name has an illegal event statement or event

order (event_statement_string) (W5)
Example 1
The following error is issued if an event in the load_unload_register procedure uses the “#’
substitute character, but no shift data for this signal is passed into the procedure when it is called
“extra shift block”:
<force | measure> signal_name # without matching shift assign data

December 2017
Test Procedure File
Example 2
The following error is issued if there is more than one shift block in the load_unload_registers
procedure.
“extra shift block”
Example 3
The following error is issued if more than one event of the same type in the shift block uses the
same signal name with the “#’ substitute character.
“too many events using shift assign signal_name”
Example 4
The following error is issued for an apply statement that uses a load_unload_registers procedure
but has no shift data assignments in the apply statement.
“apply with no shift data assignment”
Example 5
The following error is issued for an apply statement that uses a load_unload_registers procedure
and has more than one shift assignment, however, the target of the shift assignments are aliases
and they are not the same width.
“unmatched shift assign signal width”
Example 6
This is issued for an apply statement that uses a load_unload_registers procedure and has more
than one shift assignment and the assignments have different shift lengths.
“unmatched shift lengths”
Procedure Examples
The definition of the load_unload_registers procedure would look as follows. Notice how this
procedure uses the “shift =” statement and the “force tdi #” statement to denote the shifting and
where the string of data is applied, one bit at a time.

December 2017
Test Procedure File
procedure load_unload_registers load_prpg1 =

timeplate tp1 ;
cycle =
force prpg_select 1 ;
... // setup tap controller to load prpg
end;
shift =
cycle =
force tdi # ;
pulse tck ;
end;
end;
end;
This procedure could then be applied in the test_setup procedure to initialize the PRPG,
specifying the string of bits to apply to “tdi” during shifting.
timeplate tp1 ;
cycle =
force clk1 0 ;
force clk2 1 ;
force tck 0 ;
...
end;
apply load_prpg1 tdi = 000000000000000000000001 ;
cycle =
...
end;
end;
For loading a register with the shift length during test_setup, using the values computed by the
tool, the procedure definition would look the same, but how the procedure is called is slightly
different. The following example both loads and unloads the register, as this same procedure
could be used in a test_end procedure to unload the shift length value. The dofile for this
example contains the following command:
add_register_value length_val -shift_length -width 16

December 2017
Test Procedure File
The procedure file would contain the following:
procedure load_unload_registers load_unload_length =

timeplate tp1 ;
cycle =
force clk1 0 ;
...
end;
shift =
cycle =
force tdi # ;
expect tdo # ;
pulse tck ;
end;
end;
end;
timeplate tp1 ;
cycle =
...
end;
apply load_unload_length tdi = length_val, tdo = XXXXXXXXXXXXXXXX;
cycle =
...
end;
end;
This next example uses an alias to group three tdi signals into one alias, and also adds a post
shift cycle to the load_unload_registers procedure. When this procedure is called, the data
passed to it will be consumed three bits at a time, with each bit being shifted into tdi1, tdi2, and
tdi3 in order. The total number of shifts applied in the “shift” block will be the total length of the
value string divided by three, and then minus one for the post shift. Each shift will consumes
three bits, and the final cycle adds a post shift which will assign the last three bits. The length of
the value string being passed to this procedure must be a multiple of three.
alias TDI_GRP = tdi1, tdi2, tdi3 ;

procedure load_unload_registers load_reg1 =
timeplate tp1 ;
cycle =
force clk1 0 ;
...
end;
shift =
cycle =
force TDI_GRP # ;
pulse tck ;
end;
end;
cycle =
force TDI_GRP # ;
pulse tck;
end;
end;

December 2017
Test Procedure File
This final example shows how to use a dofile commands to setup a user-defined register value
that will be used to store total number of scan patterns when the final patterns are saved.
add_register_value scan_pat_count -pattern_count scan_test -width 24

December 2017
Test Procedure File
Notes About Using the stil2mgc Tool
Notes About Using the stil2mgc Tool

You can use the stil2mgc tool to create a dofile and procedure file. The stil2mgc tool reads a
STIL Procedure File (SPF) and then creates a dofile and test procedure file.
The dofile defines clocks, scan chains, scan groups, and pin constraints. The test procedure file
contains a timeplate and the following standard scan procedures: test_setup, load_unload, and
shift. For more information about this tool, refer to the stil2mgc command description in the
Tessent Shell Reference Manual.
Extraction of Strobe Timing Information from STIL (SPF) . . . . . . . . . . . . . . . . . . . . . . 380

Extraction of Strobe Timing Information from STIL

(SPF)
In the STIL WaveformTable, strobe window and edge strobe are indicated by which event
characters are used for the measure timing. Using the ‘H’ and ‘L’ characters indicates that the
measure is an edge strobe, while using the ‘h’ and ‘l’ character indicates a window strobe with
the length of the strobe window being determined by the following X event in the event list for
that WaveformCharacter.
If the window strobe events (‘h’ or ‘l’) are used for a measure event, then the strobe window is
calculated taking into account the strobe window indicated by these events. The shortest strobe
window calculated is the one used for the procedure file.
If “-edge_strobe_processing on” is specified to the tool, and the edge strobe events (‘H’ or ‘L’)
are used for a measure event, then the strobe window is set to 0 in the procedure file to indicate
edge strobe timing.
If the “-edge_strobe_processing” option is not used or is set to off, and edge strobe events (‘H’
and ‘L’) are used for a measure event, then the existing behavior is maintained where the strobe
window is calculated based on the next force event or the period of the Waveform table. The
strobe window is not set to 0.
The STIL ClockStructures Block

When parsing STIL Procedure Files (SPF), stil2mgc recognizes the Synopsys-defined
ClockStructures block and uses this information to create clock_control definitions. The
Latency statement within the ClockStructures block is used to control the
“set_external_capture_options” statement in the generated dofile.

December 2017
Test Procedure File
Test Procedure File Commands and Output Formats
Test Procedure File Commands and Output

Formats
The test procedure file is supported by a set of commands and a set of output formats.
Test Procedure File Tool Commands

The following table provides a summary of the tool commands that support the use of test
procedure files. For a detailed description of each command, refer to the corresponding
command reference page in the Tessent Shell Reference Manual.
Table 8-2. Procedure File Tool Command Summary
Command Description
add_scan_groups Adds a scan group using the scan procedures in the named
procedure file.
read_procfile Reads a new procedure file in non-setup mode. Merges new
procedure and timing data with existing data loaded from
previous procedure files.
write_procfile Writes out existing procedure and timing data as the named
procedure file.
write_patterns Loads a cycle before saving patterns and merges the new data
with the existing data.
report_procedures Reports (displays) a named procedure to the screen. The -All
switch displays all procedures to the screen.
report_timeplate Reports (displays) a named timeplate to the screen. The -All
switch displays all timeplates to the screen.
Test Procedure File Output Formats

The test procedure file format supports the following output formats:
• Fujitsu TDL
• Mitsubishi TDL
• STIL
• TI TDL
• WGL
• TSTL2
• VERILOG

December 2017
Test Procedure File
Test Procedure File Commands and Output Formats
The -PROcfile switch causes the write_patterns command to get its timing information from the
procedure file. For more information, refer to the write_patterns command in the Tessent Shell
Reference Manual.

December 2017
Chapter 9
Timing Constraints (SDC)
This chapter describes the Synopsys Design Constraints (SDC) generated by the Tessent Shell
tool, and how you use it to constrain the test mode of the Embedded Test hardware generated by
the tool.
Generating and Using SDC for Tessent Shell Embedded Test IP. . . . . . . . . . . . . . . . . . 384
SDC File Generation with Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
SDC Design Synthesis with Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Preparation Step 2: Setting and Redefining Tessent Tcl Variables . . . . . . . . . . . . . . . . . . 386
Preparation Step 3: Verifying the Declaration of Functional Clocks . . . . . . . . . . . . . . . . . 387
Preparation Step 4: Redefining Other Tessent Tcl Variables . . . . . . . . . . . . . . . . . . . . . . . 388
Synthesis Step 1: Loading the Design Into Your Synthesis Tool. . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 2: Applying the SDC Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 3: Preparing the DFT Logic for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 5: Writing Out Your Final SDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Synthesis Step 6: Writing Out Your Final Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
SDC for Modal Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Checking Your Functional Logic Alone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
VHDL and Mixed Language Designs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
VHDL Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
SDC File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
tessent_constrain_<design_name>_non_modal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
LOGICTEST Instruments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
BoundaryScan Instrument. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

December 2017
Generating and Using SDC for Tessent Shell Embedded Test IP
Generating and Using SDC for Tessent Shell

Embedded Test IP
We guide you through an example SDC flow, from generation of the Tessent SDC file, through
adjusting the variables used within the file, to using it in your design synthesis.
First, you learn how to generate an SDC file for your design, which may be at the chip or the
physical block level. SDCs for sub blocks are automatically merged by Tessent with the
constraints of their parent physical block.
Then we show you how to adjust variables in the SDC file to match your particular synthesis
setup or requirements. There is no need however, to ever directly edit the generated SDC files.
Next, you see how to use the generated SDC file in a step-by-step example synthesis flow,
followed by additional notes on Static Timing Analysis (STA), mixed-language and VHDL
specific issues.
Key SDC procs are then explained. These procedures are used by Tessent instruments (like
MBIST or OCC) or maybe useful to use in your own synthesis scripts.
The appendices show full examples of using and adjusting Tessent SDC files in the Synopsys
Design Compiler and Cadence Encounter synthesis environments, respectively. Also a
complete example for using Tessent SDC files for STA is given in “Example PrimeTime STA
Script” on page 413.
Note: The SDC described in this manual is to be used in conjunction with your functional SDC
for the synthesis of your design after Tessent Shell RTL insertion and the static timing analysis
of your design after synthesis. The Tessent Shell gate insertion flow uses a different set of SDC
constraints during the run_synthesis command, but the generated SDC should still be used for
layout.
SDC File Generation with Tessent Shell

You generate your design SDC file using Tessent Shell.
In the standard Tessent Shell flow, the tool creates the SDC for the current design when you
execute the extract_icl command, which does the following:
• Stores the SDC in Tcl procs

• Writes the SDC to a single file named design_name.sdc, where design_name is the name
of the current design loaded in Tessent Shell

December 2017
SDC File Generation with Tessent Shell
The SDC file is located next to the extracted ICL, which is typically in the dft_inserted_designs
directory as follows:
${tsdb}/dft_inserted_designs/
${design_name}_
${design_id}.dft_inserted_design
Every instrument type (for example, MBIST, IJTAG, OCC) of the current design and all sub-
blocks that provide SDC constraints are represented by a separate proc in the SDC file.
There is no need to call each instrument’s individual SDC proc. Tessent Shell provides user
procs, which are customized to call all relevant SDC procs for your design.
If you encounter a problem with SDC generation preventing ICL extraction, you can
temporarily skip SDC generation by using the following command options:
extract_icl -skip_sdc_extraction
To re-generate your SDC file for a given design and to take advantage of changes in the SDC
constraints in a newer version that does not reflect a hardware change, you can extract the SDC
of your design without running ICL extraction by loading the desired design’s full view and
executing the Tessent Shell extract_sdc command. You should load the interface view of all
physical blocks of your design. For example:
read_design design_name -design_identifier design_id -view full

extract_sdc
When it is time to use the SDC, locating your SDC file requires the following:
• Your latest TSDB location for the design you wish to synthesize/analyze.
• Your design’s name.
• The design_id of the latest insertion pass of your design.
For example, if your design “myChip” used only a single TSDB directory, the default
“tsdb_outdir”, then your SDC files would be located in the following places:
• For the processed DftSpecification(myChip,rtl1):

tsdb_outdir/dft_inserted_designs/myChip_rtl1.dft_inserted_design/myChip.sdc
• For the processed DftSpecification(myChip,rtl2):

tsdb_outdir/dft_inserted_designs/myChip_rtl2.dft_inserted_design/myChip.sdc
Note
The latest SDC file is always a superset of the previous one. If you use a two-pass flow, you
only need to load the latest file.

December 2017
SDC Design Synthesis with Tessent Shell
SDC Design Synthesis with Tessent Shell

What follows is a list of steps you must follow during your synthesis flow to properly handle
Tessent Embedded Test IP. We use a non-modal approach to constrain the inserted test logic.
This means that we let both functional and test clocks through muxes and we do not set any
constant anywhere. This lets the synthesis tools optimize both the functional and test timing
paths simultaneously.
These steps do not describe the entire flow, but, rather, only highlight typical steps affected by
the presence of Tessent IP. Design Compiler commands are used as an example: see “Example
Design Compiler Synthesis Script” on page 409 and “Example Encounter Synthesis Script” on
page 411 for complete example scripts.

Preparation Step 2: Setting and Redefining Tessent Tcl Variables . . . . . . . . . . . . . . . . 386
Preparation Step 3: Verifying the Declaration of Functional Clocks . . . . . . . . . . . . . . . 387
Preparation Step 4: Redefining Other Tessent Tcl Variables . . . . . . . . . . . . . . . . . . . . . 388
Synthesis Step 1: Loading the Design Into Your Synthesis Tool. . . . . . . . . . . . . . . . . . . 389
Synthesis Step 2: Applying the SDC Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 3: Preparing the DFT Logic for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . 389
Synthesis Step 5: Writing Out Your Final SDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Synthesis Step 6: Writing Out Your Final Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Preparation Step 1: Sourcing SDC File

The first step is to source the Tessent Shell tool-generated SDC file, associated to the last
insertion pass, from within your synthesis script. We suggest creating central variables for the
TSDB location and design name:
set design_name myChip
set tsdb ../../../golden_repo/${design_name}_tsdb
set design_id rtl2
source \
${tsdb}/dft_inserted_designs/${design_name}_${design_id}.dft_inserted_design \
/${design_name}.sdc
Preparation Step 2: Setting and Redefining Tessent

Tcl Variables
The Tessent Shell tool-generated SDC file makes extensive use of Tcl variables. This section
discusses the redefinition of those variables

December 2017
Preparation Step 3: Verifying the Declaration of Functional Clocks
Their definitions are contained in the proc tessent_set_default_variables. You must call this
procedure to set all Tessent variables to their design dependent default value. All other Tessent
SDC-related procs make use of these variables. This procedure call is mandatory:
tessent_set_default_variables
Tessent SDC variables can and should be redefined to better suit your setup and design. For
example, you can change the TCK period from the default of 100.0ns to any value by redefining
the variable tessent_tck_period.
set tessent_tck_period 80.0
It is important to understand that you do not need to edit the Tessent Shell-generated SDC file,
but simply use the ‘set’ command in your synthesis script to overwrite the value of the Tessent
Shell tool-specific SDC variable tessent_tck_period. Refer to “Example Design Compiler
Synthesis Script” on page 409 and “Example Encounter Synthesis Script” on page 411 for a full
synthesis script examples.
Another key variable to possibly overwrite is the tessent_clock_mapping array explained in the
next section. Other, much less frequently used variables are discussed in “Preparation Step 4:
Redefining Other Tessent Tcl Variables” on page 388.
Preparation Step 3: Verifying the Declaration of

Functional Clocks
In the Tessent Shell tool’s system mode ‘setup’, you may have specified asynchronous clocks,
reference clocks and/or branch clocks. Some might be functional clock domain bases of some
instruments, namely MemoryBist. They could be used in some timing constraints.
This information is stored in the array tessent_clock_mapping. It is defined in the generated
SDC file, within the proc tessent_set_default_variables. It has the following form:
array set tessent_clock_mapping {

<TessentShell ClockLabel> <FunctionalSDC ClockLabel>
[…]
}
This array is used by the Tessent Shell tool-generated SDC constraints to refer to your
functional clocks. They do so only through a remapped “tessent_clock_mapping(<TessentShell
ClockLabel>)” array element. By default, in tessent_set_default_variables, <TessentShell
ClockLabel> and <FunctionalSDC ClockLabel> are identical.
Note
It is imperative that you examine this array and look for cases where this default mapping
must be updated. Overriding names will not be necessary if you have used the “-label”
option of the add_clocks command in Tessent Shell to match the “-name” value in the SDC.

December 2017
Preparation Step 4: Redefining Other Tessent Tcl Variables
If you need to update one of the tessent_clock_mapping() array values, please do so in your
main synthesis script, right below the call to the tessent_set_default_variables proc. For
example, if you had a clock defined with a label "CK25" in Tessent Shell, but in your SDC
constraints the same clock is defined with a name "PIN_CK25", you need to specify:
set tessent_clock_mapping(CK25) PIN_CK25
The new definition of tessent_clock_mapping(CK25) will override the default one contained in
tessent_set_default_variables.
It is important to understand that you do not need to edit the Tessent-generated SDC file, but
simply use the ‘set’ command in your synthesis script to overwrite the value of the Tessent SDC
variable array element you want to change. Alternatively, if many of your Tessent defined
clocks and respective SDC clocks have different names, you might want to redefine a block of
the array:
set tessent_clock_mapping(CLK25) pCLK25

set tessnet_clock_mapping(CLK_PLL_REF) pCLK100
OR

CLK25 pCLK25
CLK_PLL_REF pCLK100
}
IMPORTANT: You do not need to define tessent_clock_mapping() entries for clocks that you
have not specified in Tessent Shell. Those will not be used in the timing constraints.
Preparation Step 4: Redefining Other Tessent Tcl

Variables
The tessent_tck_period and tessent_clock_mapping array variables are the most important
Tessent SDC variables you should double check and overwrite as needed. Tessent SDC uses a
number of additional variables that are all defined and set to a default value in the
tessent_set_default_variables proc.
For example, you can independently change the input and output delay (from the default, 25%
of the tessent_tck_period) or change the hierarchy separator character. Please see the header of
the generated SDC file and the embedded comments in the tessent_set_default_variables proc,
explaining each such variable. Within the synthesis tool, you can use the TCL command “info
body tessent_set_default_variables” to see what variables are being defined.

December 2017
Synthesis Step 1: Loading the Design Into Your Synthesis Tool
Synthesis Step 1: Loading the Design Into Your

Synthesis Tool
The most effective way of loading a design, which was edited by Tessent Shell with embedded
Tessent test logic, into the synthesis tool is to use Tessent Shell-generated supporting files.
If you are using Design Compiler to synthesize your design, you can use the Tessent Shell
command write_design_import_script. This command will write out a single file containing
analyze commands to read in every file which was read for the current design in memory in the
right order of dependency, and from the right location, i.e either your golden source file or the
Tessent edited file from the TSDB. You can use this command right after the extract_icl
command of your last RTL insertion pass or simply load the latest design view with the
command read_design and then use it.
You can then set the current design using:
source ${design_name}.dc_shell_import_script
elaborate [...]
Synthesis Step 2: Applying the SDC Constraints

If you use Design Compiler, you need to set the variable
“timing_enable_multiple_clocks_per_reg” to true. This is needed to properly constrain
MemoryBIST in the presence of MemoryBIST clock muxing.
set_app_var timing_enable_multiple_clocks_per_reg true
To apply the Tessent Shell-generated SDC constraints, run the merged non_modal proc:
tessent_constrain_${design_name}_non_modal
This Tessent SDC proc will in turn call all instrument non-modal procs as needed by your
design and its sub-blocks. There is nothing else for you to do than call this one proc to apply all
non-modal SDC constraints.
Synthesis Step 3: Preparing the DFT Logic for

Synthesis
Once your design is loaded, you need to make sure to preserve instances of Tessent Shell-
inserted “persistent” cells and possibly instrument instances, depending on your downstream
needs.
Refer to “Synthesis Helper Procs” on page 406 for more information on the different options.
Persistent cells should not be optimized as Tessent Shell SDC uses them as anchor points for
layout and STA, and different instances need to be preserved depending on if you will do scan

December 2017
Synthesis Step 4: Synthesizing Your Design
insertion with Tessent Shell or more dft insertion. Procs are provided in the .sdc file to generate
a list of all instances that need to be preserved in different ways:
tessent_get_preserve_instances, tessent_get_optimize_instances and
tessent_get_size_only_instances.
First you need to prevent boundary optimization of DFT objects using the proc
tessent_get_preserve_instances:
set_app_var compile_enable_constant_propagation_with_no_boundary_opt false

set preserve_instances [tessent_get_preserve_instances scan_insertion]
Then, since boundary optimization applies hierarchically, you re-enable boundary optimization
of the child instances of DFT objects using tessent_get_optimize_instances:
Cells from your provided Tessent Cell Library instantiated in Tessent Shell must also be
preserved but can be resized to allow critical data path timing optimization during synthesis.
You can get them using tessent_get_size_only_instances:
Tool Limitation: set_size_only does not have the desired effect in Cadence tools. See “Example
Encounter Synthesis Script” on page 411 for an example of the suggested procedure.
Synthesis Step 4: Synthesizing Your Design

You can now proceed with the compilation of your design:
link
check_design
compile -boundary_optimization [...]
Synthesis Step 5: Writing Out Your Final SDC

Use the write_sdc command after this step to export the merged SDC (Functional and Tessent
Shell) for use with your layout tool:
write_sdc ${design_name}.merged_sdc
Synthesis Step 6: Writing Out Your Final Netlist

You can now proceed with writing out your synthesized netlist.

December 2017
Synthesis Step 6: Writing Out Your Final Netlist
write -format verilog -output ${design_name}.vg ${design_name} -hier

December 2017
SDC for Modal Static Timing Analysis
SDC for Modal Static Timing Analysis

Below are guidelines to help you perform static timing analysis of the embedded test hardware
that was inserted by Tessent Shell.
Checking Your Functional Logic Alone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Checking Your Functional Logic Alone

If you want to only focus on functional logic and completely disable all Tessent Shell embedded
test IP, include the following steps in your master functional STA script.
First, if flops in your cell library do not propagate constant settings through their set or reset pin
to their data output pin, you need to set a PrimeTime variable:
set case_analysis_sequential_propagation always
This will allow disabling all embedded test modes with just a few asserts of the TAP’s reset
port.
For example:
-------------------------------------------------------------------------
... loading your functional constraints ....
# Hold the DFT in reset and kill TCK to make sure only functional logic is
# active.
set_case_analysis TRST 0
set_case_analysis TCK 0
-------------------------------------------------------------------------
Checking Your Embedded Test Logic

You can find a self-documenting example script of how to run STA using Tessent Shell
generated hardware.
Refer to “Example PrimeTime STA Script” on page 413. Carefully read the instructions in this
script before proceeding.
The script executes the following:
• Loads the generated SDC file and initializes some Tcl variables used by Tessent Shell
SDC constraints.
• Sets some Primetime control variables to their required value.

December 2017
Checking Your Embedded Test Logic
• Sources user input files if present in the same directory as follows:

o user_timing_data.tcl
o user_remapping_procs.tcl
o load_design.pt
• Loads your final netlist.
• Sequentially runs all EmbeddedTest modes present in your design, each separated by a
“reset_design” command.
• Runs an example “report_constraints” command for each mode and redirects its output
to a file.

December 2017
VHDL and Mixed Language Designs
VHDL and Mixed Language Designs

Synthesis tools have similar but sometimes different internal representations of elaborated
designs. Here are some instructions on how to deal with those differences to be able to use the
SDC constraints generated by Tessent Shell.
VHDL Generate Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
VHDL Generate Blocks

Required tool settings and other mixed-language issues.
Synopsys Design Compiler

Constraints applying to cells and pins in VHDL generate loops are problematic to apply in
dc_shell. The default naming scheme of the internally synthesized design is different for
Verilog and VHDL. To illustrate, here is a Verilog path of an instance within 2 nested generate
for loops: blk[0].jblk[0].i0. The equivalent configuration in VHDL would be changed during
dc_shell’s GTECH pre-synthesis and would be named i0_0_0. Since Tessent Shell’s SDC does
not “flatten” generate loops, if you have VHDL generate loops in your design, you must use the
following setting in dc_shell to restore the loop naming:
set_app_var hdlin_enable_upf_compatible_naming true
This variable will restore VHDL generate loop naming to follow Verilog style: blk(0)/jblk(0)/i0
Cadence Encounter and Genus

There are no special steps for these two synthesis tools to be able to apply Tessent Shell
generated SDC constraints to a mixed language design.
Dealing with Unrolled VHDL Generate for Loops

Tessent Shell tries to minimize unrolling of generate loops. If VHDL generate loops are
unrolled then one “if-generate” block is generated for each loop iteration. The trailing closing
square brace, that would normally be changed to an underscore, has to be truncated because of
VHDL language restrictions. This means that functional SDC constraints pointing to cells or
pins within those generate blocks will not match even if special characters are mapped to
wildcards. Ex: the instance path blk[0].i0 which would need to be unrolled would be written out
as blk_0.i0.
For this reason, we recommend using the provided procs tessent_get_pins and tessent_get_cells,
they will be able to match your functional instance path “blk[0].i0” to blk_0.i0 using a caching
algorithm that searches for generate blocks in the path and tries to match with our unrolling
strategy if the path does not match outright. Refer to the “Cell and Pin Mapping Procs” on
page 406 to see the procs’ description.

December 2017
SDC File Contents
SDC File Contents

For your convenience and information, here is a description of the procs contained in the
generated SDC file. Note that many of these procs are called automatically by other procs in the
file. You do not need to call all of these procs.
tessent_constrain_<design_name>_non_modal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
LOGICTEST Instruments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
BoundaryScan Instrument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
This proc defines the initial/default value of all global variables used in all procs of the sdc file.
The variables contained in this proc are there for you to customize the constraints without
having to edit the constraints themselves. A good example of this would be the variable
“tessent_tck_period”. It currently defaults to 100.0 (nanoseconds). If your TCK clock has a
different period than 100ns, you can overwrite the value of this variable after having called the
proc tessent_set_default_variables but before calling the constraint procs.
This proc must always be the first proc to be run.
tessent_create_functional_clocks
This proc is generated for your convenience. It contains the sdc create_clock and
create_generated_clock commands to define the various functional clocks needed by the
instruments constrained by the sdc procs. Typically, your functional clocks would already be
defined by your functional SDC. If that is the case, you should override the default values of the
tessent_clock_mapping array to match the clock names you used in the definition of your
clocks.
This proc would typically not be called in your synthesis SDC.
Required clocks are determined with ICL tracing. create_clock constraints are added for all
clock sources like top level ClockPort ports and source ToClockPort ports (embedded
crystals).create_generated_clock constraints are added for all generated clocks (add_clocks -
reference), branch clocks and unidentified ICL ToClockPort ports (typically PLL's).If your

December 2017
tessent_<design_name>_set_dft_signals
design contains an ICL instrument with a ToClockPort that should not require a new generated
clock, please set the exclude_from_sdc attribute on the port.
tessent_<design_name>_set_dft_signals
This procedure forces all your specified static dft_signal sources to either reset or get their
default value during all_test, depending on the proc's argument.
argument mode :== reset | logic_off
• logic_off — Recommended argument for running non-logictest STA modes such as

memoryBIST.
• reset — Disables all DFT-inserted logic.
If you are using functional-only mode, the you could optionally call the proc with the “reset”
argument under one of the following circumstances:
1. Many static dft signals come from top-level ports;

2. Although all static dft signals sourced by Mentor's IJTAG Test Data Registers (TDR)
reset when the ijtag reset port is asserted, the timing tool would not propagate that assert
through the TDR flops. That may happen in Synopsys Primetime when the control
variable “case_analysis_sequential_propagation” is set to “never”.
tessent_constrain_<design_name>_non_modal
This proc contains calls to the non_modal procs of all constrained instruments. They are
documented below. For synthesis, this is the only constraint proc you need to call.
IJTAG Instrument
Tessent IJTAG provides a single proc:
• tessent_constrain_<design_name>_mentor_ijtag_non_modal
o This proc would typically not be called directly in your synthesis script, it is called
as part of tessent_constrain_<design_name>_non_modal.
This proc contains the clock creation for your TCK clock and configurable input and output
delays for created ports at the sub_block and physical_block design levels.
It also creates an asynchronous clock group with all TCK clocks. It is used to prevent synthesis
from balancing paths between TCK and functional clocks. This clock group could be recreated
with additional clocks if your design contains Tessent BoundaryScan and/or Tessent OCC
hardware. This is managed via the “tessent_tck_clock_list” global variable. This variable is
built from different procs (ijtag & jtag_bscan) and used to create an asynchronous clock group.

December 2017
LOGICTEST Instruments
If you have your own TCK generated clocks that are not used in the Tessent Shell SDC
constraints, we suggest adding their name to this list right after calling
tessent_set_default_variables.
lappend tessent_tck_clocks_list
my_tck_generate_clock
At the sub-block and physical block levels, constraints are added to reflect the timing of the
IJTAG protocol. The IJTAG reset port is declared a false path and the IJTAG select port’s hold
paths are declared false and its setup paths are given two cycles with a muticycle_path
constraint.
The logictest-based procs are as follows:
• tessent_constrain_<design_name>_mentor_ltest_create_clocks
Called by many ltest procs below.
• tessent_constrain_<design_name>_mentor_ltest_modal_bypass_shift for STA
This proc must be called in your STA to constrain the EDT in bypass shift mode.
• tessent_constrain_<design_name>_mentor_ltest_modal_edt_fast_capture for STA
This proc must be called in your STA to constrain the EDT in fast capture mode.
• tessent_constrain_<design_name>_mentor_ltest_modal_edt_shift for STA
This proc must be called in your STA to constrain the EDT in shift mode.
• tessent_constrain_<design_name>_mentor_ltest_modal_single_bypass_chain_shift for
STA
This proc must be called in your STA to constrain the EDT in single chain bypass shift
mode.
• tessent_constrain_<design_name>_mentor_ltest_modal_edt_slow_capture for STA
This proc must be called in your STA to constrain the EDT in slow capture mode.
• tessent_constrain_<design_name>_mentor_ltest_non_modal
For chip synthesis and non-modal layout constraints. Merges the following old procs:
o tessent_constrain_<design_name>_mentor_edt_non_modal
o tessent_constrain_<design_name>_mentor_occ_non_modal
• tessent_constrain_<design_name>_mentor_ltest_set_pin_delays
Called by many ltest procs below.

December 2017
constrain_<design_name>_mentor_ltest_create_clocks
Tessent OCC provides the following proc:
• tessent_constrain_<design_name>_mentor_occ_non_modal for chip synthesis

This proc would typically not be called directly in your synthesis script, it is called as
part of tessent_constrain_<design_name>_non_modal.
It contains some constraints for test inputs and to disable the timing of clock muxes that switch
statically within the OCC.
It also creates some clocks:
• tessent_edt_clock — This clock is generated from the test_clock and is used to time the
shift paths of the EDT logic.
• tessent_shift_capture_clock — This clock is also generated from the test_clock and is

used to time the shift paths and the slow capture paths through the OCC.
• tessent_virtual_slow_clock — A virtual slow clock of the same frequency as your scan

or edt shift clock, used to time all top-level ports that directly interface with your edt
controllers and your scan chains, through the “set_input_delay” and “set_output_delay”
constraints.
• tessent_test_clock — This is a DFT signal in Tessent Shell. It should be your tester’s

synchronous clock and is used to create the OCC’s shift_capture_clock and the
edt_clock.

December 2017
Figure 9-1. tessent_test_clock and tessent_shift_capture_clock Creation
This proc is also called by every SDC proc that propagates the edt_clock and/or shift clocks,
specifically:
• tessent_constrain_<design_name>_ltest_modal_edt_shift
• tessent_constrain_<design_name>_ltest_modal_bypass_shift
• tessent_constrain_<design_name>_ltest_modal_single_bypass_chain_shift
• tessent_constrain_<design_name>_ltest_modal_slow_capture

December 2017
The following example illustrates the use of the proc:
proc tessent_constrain_myDesign_mentor_ltest_create_clocks {} {
#
# Constraints for instrument mentor::ltest
#
global test_clock_source_name tessent_slow_clock_period \

tessent_slow_clock_waveform
# test_clock:
create_clock [get_ports test_clock] \
-add -period [expr $tessent_slow_clock_period] \
-name tessent_test_clock \
-waveform $tessent_slow_clock_waveform
# edt clock:
create_clock [get_ports edt_clock] \
-period [expr $tessent_slow_clock_period] -add \
-name tessent_edt_clock
# Virtual slow clock, for use with input/output delay constraints in

# scan or edt mode:
create_clock \
-period $tessent_slow_clock_period \
-name tessent_virtual_slow_clock
}
tessent_constrain_<design_name>_mentor_ltest_set_pin_delays
This procedure assigns the clock “tessent_virtual_slow_clock” to your top-level ports that
directly interface with your EDT controllers or your scan chains during scan or EDT mode,
using the “set_input_delay” and “set_output_delay” timing constraints.
This proc is called by every SDC proc which propagate the edt and/or shift clocks, that is:
• tessent_constrain_<design_name>_ltest_modal_edt_shift
• tessent_constrain_<design_name>_ltest_modal_bypass_shift
• tessent_constrain_<design_name>_ltest_modal_single_bypass_chain_shift
• tessent_constrain_<design_name>_ltest_modal_slow_capture

December 2017
Input/Output Pin Delay Constraints

Input and output delay constraints are declared for the EDT control and channel pins. For
example:
# channel_input:
set_input_delay $tessent_scan_input_delay \
-clock tessent_virtual_slow_clock \
[get_ports {my_edt_channels_in[0]}]
# channel_output:
set_output_delay $tessent_scan_output_delay \
[get_ports {my_edt_channels_out[0]}]
# edt_update:
set_input_delay $tessent_scan_input_delay \
[get_ports edt_update]
DFT Signals Handling in ltest STA Procs

All EDT-related modal STA procs below force the following dft signals, when present, to their
active value:
• all_test (active in all tests)

• ltest_en (active in logictest only)
• edt_mode (selects the edt mode)
For example:
set_case_analysis 1 [get_ports all_test]

set_case_analysis 1 [get_ports ltest_en]
The same procs will leave all other logictest-related dft signals toggling, and will add a
false_path constraint if they come from a primary port. For example:
set_false_path -from [get_ports async_set_reset_static_disable]

set_false_path -from [get_ports control_test_point_en]
set_false_path -from [get_ports ext_ltest_en]
set_false_path -from [get_ports ext_mode]
Procedure "tessent_constrains_<module_name>_mentor_ltest_edt_fast_capture", on the other

hand, will optionally assert some of these dft_signals, under control of a user-declared variable.

December 2017
MemoryBIST Instrument
Those are the signals that optionally enable some capture paths. Users may choose to leave
these signals toggle, or force them enabled or disabled. For example:
# Define each variable below to match your final ATPG settings in fast
# capture mode.
# By default, all possible capture paths are covered.
global observe_test_point_en_value
if {[info exists observe_test_point_en_value]} {
set_case_analysis $observe_test_point_en_value [get_ports \
observe_test_point_en]
}
global mcp_bounding_enable_value
if {[info exists mcp_bounding_enable_value]} {
set_case_analysis $mcp_bounding_enable_value [get_ports \
my_mcp_bounding_enable]
}
tessent_constrain_<design_name>_mentor_ltest_non_modal
This procedure provides SDC timing constraints to add to your combined functional-dft non-
modal timing scripts for one-pass synthesis or layout.
The procedure calls the previously described procs:
• constrain_<design_name>_mentor_ltest_create_clocks
• tessent_constrain_<design_name>_mentor_ltest_set_pin_delays
It also:
• Defines a specific clock group (using 'set_clock_groups') for all logictest slow clocks,
isolating them from your declared functional clocks.
• Adds 'set_false_path' constraints from each of your primary ports assigned to a static dft
signals such as 'all_test', 'ltest_en' 'edt_mode'.
• Provides constraints to prevent “tck” and your functional clocks to propagate to
unwanted paths inside your mentor OCCs, as well as constraints that prevent false
timing violations on the select pin of clock muxes inside that OCC.
• Adds an optional set_multicycle_path constraint from your primary 'scan_en' port.
Tessent MemoryBIST provides the following procs:
• tessent_constrain_<design_name>_mentor_memory_bist_non_modal for chip synthesis
o This proc would typically not be called in your synthesis script, it is called as part of
tessent_constrain_<design_name>_non_modal.
• tessent_constrain_<design_name>_mentor_memory_bist_modal for STA

December 2017
o This proc must be called in your STA script if you want to constrain the MemoryBist
mode.
• tessent_aes_top_set_dft_signals logic_off
Specify this call if your design also feature logictest-based dft signals that need to be
turned off in membist STA mode.
They contain many multicycle path constraints to and from controller registers aiming to
minimize the impact of the MemoryBIST DFT on your timing closure.
Multi-Clock Memories
Additional timing exceptions were added for synthesis if you have multi-port memories
functionally driven by multiple clocks. A mux is inserted in the memory interface to allow both
clock ports of the memory to be driven using a single clock during the Memory BIST mode.
The insertion of this clock multiplexer adds different timing modes between functional and test
modes which must be described correctly in the SDC file.
Note
If you wish to skip the memoryBIST constraints of clock muxing (creating the generated
clock and false paths) for multi-clock memories, set the variable
tessent_apply_mbist_mux_constraints to “0” in the tessent_set_default_variable proc.
This variable should be set to “0” in two cases:
• For synthesis: When the BIST clock used by the MemoryBIST tests is declared as false
path with the memory’s functional clock in the user’s SDC script.
• For STA: When verifying the timing of the scan modes.
In the following, we explain key points of the MemoryBist constraints to handle these modes
harmoniously. Suppose the situation where CLKA and CLKB are two of your functional clocks
that drive two clock ports of a single memory. The MemoryBIST logic will be inserted and will
run on CLKA. CLKA will be multiplexed onto the CLKB branch of the memory during tests.

December 2017
Figure 9-2. Generated Clock Muxed Multi-Clock Memories
First, we need to create a generated clock on the input of the clock mux. In our example, this
clock is called mbist1_m0_mux0.
create_generated_clock [tessent_get_pins
$tessent_memory_bist_mapping(mbist1_m3)/tessent_persistent_cell_MUX1/b] \
-name mbist1_m0_mux0 \
-source [get_ports CLKA] \
-add -master_clock $tessent_clock_mapping(CLKA) \
-divide_by 1
Creating this clock at the input of the clock mux (instead of the output) allows all input clocks to
propagate through the mux and times the following interactions precisely:
• Timing paths between the memory BIST logic and the memory
• Timing paths between the functional flops and the memory
With the mbist1_m0_mux0 defined, we can now define clock-based exceptions to declare as
false any interaction between CLKB and the memory BIST flops, and between

December 2017
BoundaryScan Instrument
mbist1_m0_mux0 and the functional flops on CLKB. Those false paths are described using the
following SDC commands:
set nonMBISTclocks [remove_from_collection [all_clocks] [get_clocks

"$tessent_clock_mapping(CLKA) mbist1_m0_mux0 "]]
set_false_path -from [get_clocks mbist1_m0_mux0] \
-to $nonMBISTclocks
set_false_path -from $nonMBISTclocks \
-to [get_clocks mbist1_m0_mux0]
set_false_path -from [get_clocks $tessent_clock_mapping(CLKB)] \
-to [tessent_get_cells [concat \
$tessent_memory_bist_mapping(mbist1_m3)/SCAN_OBS_FLOPS* \
$tessent_memory_bist_mapping(mbist1_m3)/MBISTPG_STATUS/GO_ID_REG* \
$tessent_memory_bist_mapping(mbist1_m3)/FREEZE_STOP_ERROR*]]
set_false_path -from [tessent_get_cells [concat \
$tessent_memory_bist_mapping(mbist1_m3)/Q1_SCAN_IN* \
$tessent_memory_bist_mapping(mbist1_m3)/Q2_SCAN_IN* \
$tessent_memory_bist_mapping(mbist1_m3)/BIST_INPUT_SELECT*]] \
-to [get_clocks $tessent_clock_mapping(CLKB)]
set_false_path -from [tessent_get_cells [concat \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_PORT_COUNTER/PORT_COUNTER* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_FSM/STATE* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_POINTER_CNTRL/
EXECUTE_OP_SELECT_CMD** \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_SIGNAL_GEN/JCNT* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_SIGNAL_GEN/OPSET_SELECT_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_DATA_GEN/WDATA_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_DATA_GEN/X_ADDR_BIT_SEL_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_DATA_GEN/Y_ADDR_BIT_SEL_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_ADD_GEN/AX_ADD_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_ADD_GEN/AY_ADD_REG* \
$tessent_memory_bist_mapping(mbist1)/MBISTPG_OPTION/BIST_EN_RETIME2* \
$tessent_memory_bist_mapping(mbist1)/MEM_SELECT_REG*]] \
-to [get_clocks $tessent_clock_mapping(CLKB)]
By making these timing exceptions, we are precisely timing the memory BIST interaction with
the memory using CLKA reaching the two-clock ports of the memory and the functional logic
to memory interaction using the CLKB reaching the memory clock port. The added logic is
precisely timed to simplify timing closure. These constraints will make physical design tools
aware of the mux on the clock port of the memory and they will place the mux in a location
where it does not affect timing.
BoundaryScan Instrument
Tessent BoundaryScan provides the following proc:
• tessent_constrain_<design_name>_mentor_jtag_bscan_non_modal
o This proc would typically not be called directly in your synthesis script, it is called
as part of tessent_constrain_<design_name>_non_modal.
It creates generated clocks from each BoundaryScan interface and relaxes the timing between
them.

December 2017
Cell and Pin Mapping Procs
Cell and Pin Mapping Procs

Since the Tessent SDC constraints are made to be usable pre- and post-synthesis, a certain
mapping needs to be done in order to find all pins and cells with the pre-synthesis instance path.
It is done with the following procs:
• tessent_get_pins
• tessent_get_cells
• tessent_get_flops
• tessent_map_to_verilog
• tessent_remap_vhdl_path_list
tessent_get_pins and tessent_get_cells are wrapper procs of the original SDC commands
get_pins and get_cells, they are used throughout the Tessent SDC. They both use
tessent_map_to_verilog and tessent_remap_vhdl_path_list procs as needed. You can and should
use the tessent_get_pins and tessent_get_cells procs (as opposed to get_pins and get_cells) in
your functional SDC if you have a design with unrolled VHDL generate loops and you have
problems applying your functional SDC on the RTL. See “Dealing with Unrolled VHDL
Generate for Loops” on page 394 for more information.
The tessent_get_flops proc runs the tessent_get_cells proc and then filters the result collection
for sequential elements. The proc uses a filtering method appropriate for the current tool.
The tessent_map_to_verilog proc adds wildcarding to pre-synthesis instance paths to match

post-synthesis instance paths for layout and STA. For example, the instance path core_inst/
my_reg[0] would return the pattern core_inst/my_reg?0?. This is to be able to match both the
RTL instance path and the post-synthesis path core_inst/my_reg_0_ even if “change_names -
rules Verilog” was used. It also maps the slash (/) coming from Tessent Shell instance paths to
any user-defined “tessent_hierarchy_separator”. This proc is called by tessent_get_cells and
tessent_get_pins. You should not need to call this proc directly.
The tessent_remap_vhdl_path_list proc is used when the instance path cannot be found with the
simple mapping. It should only be needed when Tessent Shell has unrolled some VHDL
generate loops to do uniquified insertion in the instances within them. See “Dealing with
Unrolled VHDL Generate for Loops” on page 394 for more information. This proc is called by
tessent_get_cells and tessent_get_pins if needed. You should not need to call this proc directly.
Synthesis Helper Procs

To be able to apply Tessent Shell SDC constraints on your post-synthesis netlist, some steps are
required to preserve the boundary of certain instruments as well as to preserve certain
“persistent” cells, which must not be optimized away.

December 2017
Three procs are provided to return the design instances which need to be boundary preserved,
shall be optimized or must be entirely preserved:
• tessent_get_preserve_instances preservation_intent
• tessent_get_optimize_instances
• tessent_get_size_only_instances
tessent_get_preserve_instances preservation_intent returns a collection of instances whose
boundaries must be preserved. It must be provided an argument to establish the future use of the
netlist and determine which instances need to be preserved. The “select” value you need to
choose depends on if you intend on using your post-synthesis netlist with our tools. Here are the
allowed values of the “select” argument, they are in increasing order of inclusiveness:
• add_core_instances
This usage selection returns instances that need to be preserved for applying SDC
constraints for STA to your post-synthesis design, and instances required for the TCD
automation flow with ATPG.
• scan_insertion
This usage selection returns all instances of the previous selection, plus any instance of
modules having existing scan segments described in a TCD scan file. This selection is
required if you intend to use Tessent Shell to do scan insertion on your design.
• icl_extract
This usage selection returns all instances of the two previous selections, plus any
instance of modules providing an ICL definition. This context is needed if you intent to
go through the DftSpecification flow again, this time with your gate level netlist. ICL
extraction requires that all ICL instances be present and traceable in the design.
The tessent_get_optimize_instances proc returns a collection of child instances within Tessent
instruments whose boundaries are allowed to be optimized. This should be used when your
synthesis tools propagates boundary optimization attributes downward hierarchically.
The tessent_get_size_only_instances proc returns a collection of instances of all persistent cells.

These cells are required to be intact to apply SDC constraints for layout and STA. However, the
synthesis tool is allowed to change the size of the driving stage as needed.

December 2017

December 2017
Appendix A
Example Scripts
This section provides example scripts for use when using Tessent Shell tool-generated SDC.
Example Design Compiler Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Example Encounter Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Example PrimeTime STA Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Example Design Compiler Synthesis Script

The following is an example synthesis script to use with Design Compiler.

December 2017
Example Scripts
Example Design Compiler Synthesis Script
# Preparation Step 1: Sourcing SDC File

set design_name top
set tsdb ../tsdb_outdir
source \
${tsdb}/dft_inserted_designs/${design_name}_rtl.dft_inserted_design/ \
${design_name}.sdc
# Preparation Step 2: Setting and Redefining Tessent Tcl Variables

# Uncomment the following line if you wish to skip the memoryBIST

# constraints of clock muxing for multi-clock memories:
#set tessent_apply_mbist_mux_constraints 0
# Preparation Step 3: Verifying the Declaration of Functional Clocks

# Define functional clocks
create_clock [get_ports pCLK25] –name pCLK25 –period 25.0

# Set clock names in mapping array
CLK25 pCLK25
CLK_PLL_REF pCLK100
}
# Preparation Step 4: Redefining Other Tessent Tcl Variables
# set tessent_input_delay [expr 0.3 * $tessent_tck_period]
# Synthesis Step 1: Loading the Design Into Your Synthesis Tool

source ${design_name}.dc_shell_import_script
elaborate $design_name
# Synthesis Step 2: Applying the SDC Constraints

set_app_var timing_enable_multiple_clocks_per_reg true
# Synthesis Step 3: Preparing the DFT Logic for Synthesis

set_app_var compile_enable_constant_propagation_with_no_boundary_opt false
set preserve_instances [tessent_get_preserve_instances icl_extract]
# Synthesis Step 4: Synthesizing Your Design

link
check_design
compile -boundary_optimization
# Synthesis Step 5: Writing Out Your Final SDC

write_sdc ${design_name}.merged_sdc
# Synthesis Step 6: Writing Out Your Final Netlist

December 2017
Example Scripts
Example Encounter Synthesis Script
write -format verilog -output ${design_name}.vg ${design_name} -hier

This section provides an example synthesis script to use with Encounter.

December 2017
Example Scripts
# Preparation Step 1
set design_name top
set tsdb ../tsdb_outdir
source
source ${tsdb}/dft_inserted_designs/${design_name}_rtl.dft_inserted_design/ \
${design_name}.sdc
# Uncomment the following line if you wish to skip the memoryBIST

# constraints of clock muxing for multi-clock memories:
#set tessent_apply_mbist_mux_constraints 0
# Define functional clocks
# Set clock names in mapping array
CLK25 pCLK25
CLK_PLL_REF pCLK100
}
# set tessent_input_delay [expr 0.3 * $tessent_tck_period]
# Synthesis Step 1
source ${design_name}.encounter_import_script
elaborate
cd designs/${design_name}
# Synthesis Step 2
# Synthesis Step 3
proc do_set_boundary_optimization { instance_collection state } {
set C {}
# Find sub-instances because 'boundary_opto' attribute is not inherited
# downward (unlike 'dc_shell')
set instancesCollection {}
foreach_in_collection inst $instance_collection {
if { [sizeof_collection [set subInstancesCollection [find . -instance \
[vname $inst]]]]> 0 } {
append_to_collection instancesCollection $subInstancesCollection
}
}
# In 'encounter', a collection is really just a list...

set instancesCollection [lsort -unique $instancesCollection]
# Boundary optimization can only be applied to subdesign.

# Build a list of the subdesign names for each instance.
foreach_in_collection inst $instancesCollection {
if { [set moduleName [get_attribute module $inst]] eq "" } { continue }
lappend C $moduleName

December 2017
Example Scripts
Example PrimeTime STA Script
if { [llength $C] == 0 } { return }
# Apply boundary optimization

set C [lsort -unique $C]
puts "Setting boundary optimization '$state' on modules:\n "
puts [join $C "\n "]
set_attribute boundary_opto -quiet $state $C
# Preserve the footprint of DFT objects

# when boundary optimization is not set.
if { !$state } {
puts "Preserve footprint on pins of:\n "
puts [join $instancesCollection "\n "]
foreach_in_collection inst $instancesCollection {
set_attribute preserve true [find $inst -pin *]
}
}
return $C
}
set preserveInstances [tessent_get_preserve_instances icl_extract]

do_set_boundary_optimization $preserveInstances false
set optimizeInstances [tessent_get_optimize_instances]

do_set_boundary_optimization $optimizeInstances true
set set_size_only_collection [tessent_get_size_only_instances]

if { [sizeof_collection $set_size_only_collection] != 0 } {
foreach {preserveValue isSequential} [list map_size_ok true size_ok false] {
set instancesListFiltered [filter sequential $isSequential $set_size_only_collection]
if { [llength $instancesListFiltered] == 0 } { continue }
puts "Setting preserve attribute '$preserveValue' to '$isSequential' on:\n "
puts [join [lsort $instancesListFiltered] "\n "]
set_attribute preserve $preserveValue $instancesListFiltered
}
}
# Synthesis Step 4
synthesize -to_mapped
# Synthesis Step 5
redirect ${design_name}.merged_sdc { write_sdc $design_name }
# Synthesis Step 6
redirect ${design_name}.vg { write_hdl $design_name }

The following section provides an example STA script to use with PrimeTime.

December 2017
Example Scripts
#########################################################################
#
# REQUIRED USER EDITS
#
#########################################################################
# You need to edit some of the lines below before you can run this script.
# Once you’re done, you can source the script directly
# from Primetime.
#========================= Start Edits Here =============================
#------------------------------------------------------------------------
# Edit #1- set a few variables:
# Update the "tsdb" variable below to reflect the path between the
# design’s latest TSDB directory and the directory where you perform the
# analysis.
set tsdb ./tsdb_outdir
# Update the "design_name" variable below to provide your top level design
# name.
set design_name top
# Update the "design_id" variable below to specify the latest
set design_id rtl
# Update the "netlist" variable below to point to your gate level
# netlist file.
# If your netlist requires more than a simple read_verilog command, create
# a file load_design.pt and it will be sourced further in this script
set netlist ${design_name}.vg
#------------------------------------------------------------------------
# Edit #2- Provide a back-annotation procedure to the script.
# If you run STA on a post-layout netlist, you must provide the proper
# back-annotation command(s) inside the procedure below.
# If you don't want back-annotation, leave that procedure empty.
proc LoadBackAnnotationData {} {
echo "Loading back-annotation file"
}
#========================== End Edits Here =============================
##################################################################
# Initialization
##################################################################
# "Creating a clock on internal pin ..."
suppress_message UITE-130
# "Creating a clock on a hierarchical pin ..."
# "Creating a generated clock on a hierarchical pin ..."
# "Creating a clock source on inout port ..."
# "Some timing arcs have been disabled for ..."
suppress_message PTE-003
#------------------------------------------------------------------------
# RunAndReport
#
# You can modify the RunAndReport procedure to your taste by defining it
# inside your user_timing_data.tcl file. See below for more details.
#

December 2017
Example Scripts
proc RunAndReport { mode } {

update_timing
redirect violations_${mode}.report {report_constraint -all_violators}
}
#------------------------------------------------------------------------
# Allow asserts on flop reset pins to propagate to their Q output.
# Disable timing through the enable side of clock gating cells,

# so as to prevent clock reconverging paths.
set timing_clock_gating_propagate_enable false
# Source Tessent Shell generated sdc file and set default variables
source \
${tsdb}/dft_inserted_designs/${design_name}_${design_id}.dft_inserted_design \
/${design_name}.sdc
# Change your hierarchy separator variable if not appropriate

set tessent_hierarchy_separator "/"
# Override data in above "tessent_set_default_variables" by creating your

# own timing data file and placing it at the same level as this script.
if {[file exists user_timing_data.tcl]} {
source user_timing_data.tcl
}
# You can provide your own path remapping procedures file

# (tessent_get_xxx). You only need to copy and edit the procedures you
# want to change and put them in file ./user_remapping_procs.tcl.
if {[file exists user_remapping_procs.tcl]} {
source user_remapping_procs.tcl
}
# If you have fake cells or cells that are not part of your library
# you can provide this file to load them.
if {[file exists load_lib_cells.tcl]} {
source load_lib_cells.tcl
}
# Create the script "load_design.pt" only if you need to load your design
# with a different command than the simple "read_verilog" below. Leave
# that file in the current directly and the lines below will pick it up
# automatically. That will save you from having to edit this script every
# time after you ran rulea-timinggen.
if {[file exists load_design.pt]} {
source load_design.pt
} else {
read_verilog $netlist
}
current_design $design_name
link_design
########################################################################
#
# EmbeddedTest Mode
#
########################################################################
echo "\n\n\nAnalysis in EmbeddedTest Mode ************************ \n" ;

December 2017
Example Scripts
reset_design
LoadBackAnnotationData
# Apply constraints for STA.

tessent_create_functional_clocks
tessent_constrain_${design_name}_mentor_ijtag_non_modal
if {[info procs tessent_constrain_${design_name}_mentor_memory_bist_modal] ne ""} {
tessent_constrain_${design_name}_mentor_memory_bist_modal
}
if {[info procs tessent_constrain_${design_name}_mentor_memory_bisr_non_modal] ne ""} {

tessent_constrain_${design_name}_mentor_memory_bisr_non_modal
}
if {[info procs tessent_constrain_${design_name}_mentor_jtag_bscan_non_modal] ne ""} {

tessent_constrain_${design_name}_mentor_jtag_bscan_non_modal
}
if {[info procs tessent_constrain_${design_name}_mentor_occ_non_modal] ne ""} {

tessent_constrain_${design_name}_mentor_occ_non_modal
}
RunAndReport ETMODE

December 2017
Appendix B
The Tessent Tcl Interface
The Tessent Shell tool provides a Tcl-based command interface.

General Tcl Guidelines in Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Guidelines for Modifying Existing Dofiles for Use with Tcl . . . . . . . . . . . . . . . . . . . . . . 420
Special Tcl Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Custom Tcl Packages in Tessent Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Tcl Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
General Tcl Guidelines in Tessent Shell

If Tcl procedures are available in separate files, you can source these files from within the tool
or dofiles. You can also place Tcl procedures in a .tool_startup file so that they are available for
use. Tcl file input/output is also supported.
You should be aware of the following guidelines and behaviors when using Tcl in Tessent
Shell:
• You can use Tcl variables interchangeably with legacy Tessent tool variables and
environment variables.
• You should use Tcl syntax for setting and referencing variables, including using
$env(ENVARNAME) for accessing environment variables.
For example, if the value of environment variable “foo” equals “mode1”
($foo = mode1), you can compare this value to a Tcl variable value using the following
syntax:
set bar mode2
if {$env(foo) == $bar} {puts Match} else {puts "No match"}

December 2017
If you want the output of any tool command returned as a Tcl result, you must use the
return_output command. The following example uses return_output in a dofile:
set resultA [return_output {report_gate /gate3} -tee ]
// /gate3 nor02
// A0 I /gate2/Y
// A1 I /ff2/Q
// Y O /ff5/D ff4/D ff3/D /gate6b/E
puts $resultA
// /gate3 nor02
// A0 I /gate2/Y
// A1 I /ff2/Q
// Y O /ff5/D ff4/D ff3/D /gate6b/E
Note
Use Tcl namespaces to avoid creating procedures that conflict with existing tool or
Tcl commands.
• When processing comments within a dofile, the tool does not write comments preceded
with “//” characters to the transcript. However, the tool does write comments that are
preceded with a pound sign (#) (the Tcl comment delimiter) to the transcript.
• If a variable can contain a command string or be empty, attempting to execute by
referencing $variable results in an error if the variable is empty.
• When a tool command error occurs, the command interpreter prints the error message
and does not return anything.
• You can use the catch_output command to issue a specified tool command line and
prevent command errors from aborting an enclosing dofile or Tcl proc. The
catch_output command can optionally capture the output of a command or the returned
result.
• When a command error occurs nested inside a Tcl construct or Tcl proc, you can obtain
additional information about the error by issuing the following command:
> set errorInfo
This command prints the value of the $errorInfo Tcl variable, which may contain a
traceback of the nested Tcl calls so that you can determine the root cause of the error.
Difference Between the Dofile Command and the Tcl Source Command
You normally use the tool's dofile command to execute a file of tool commands. The Tcl
“source” command also executes a file of commands, but you should only use it to load Tcl
procs, set Tcl variables, or do other strictly Tcl commands.

December 2017
You should use the dofile command to execute a command file containing tool commands for
the following reasons:
• The dofile command is affected by the set_dofile_abort command which provides you
with the ability to specify whether the tool aborts when an error condition is detected.
The Tcl “source” command is not affected by the set_dofile_abort command.
• The dofile command transcripts the commands to the shell and logfile. The Tcl “source”
command always stops execution if any command in the file encounters an error.
Example 1
In this example, the add_scan_chains command defines every scan chain in the design. This
command is sometimes used hundreds of times and makes the dofile very long. Using Tcl, you
can shorten the dofile substantially by using a loop construct as shown here:
for {set xx 1} {$xx < 257} {incr xx} {

add_scan_chains int chain$xx group1 /top/edt_si$xx /top/edt_so$xx
}
For the values of xx from 1 up to 256, the tool executes a separate add_scan_chains command
for each value. The transcript and logfile will contain all 256 add_scan_chains commands
(preceded with “// subcommand: ”).
Example 2
The following example controls the flow of creating test patterns and uses a variable to execute
different commands based on the variable’s value:
if {$mode == stuck} {
set_fault_type stuck
. . .
} elseif {$mode == transition} {
set_pattern_type -sequential 2
. . .
}
Example 3
This example places the output from a report command in a variable for subsequent processing:
> set chain_report [return_output {report_scan_chain}]

> puts $chain_report
chain = chain1 group = grp1 input = /scan_in1 output = /scan_out1 length = unknown
...
chain = chain256 group = grp1 input = /scan_in256 output = /scan_out256 length = unknown

December 2017
Guidelines for Modifying Existing Dofiles for Use with Tcl
Guidelines for Modifying Existing Dofiles for

Use with Tcl
When using an existing dofile with the Tcl interface, you should evaluate the dofile for issues
that could cause incorrect evaluation by the Tessent Tcl interpreter.
Table B-1 provides guidance for correcting common dofile issues.
The most common issues you can run across with an existing dofile is accounting for Tcl special
characters. For more information, refer to Table B-2 on page 422, which provides a list of
typically-used Tcl special characters.
Table B-1. Common Dofile Issues and Solutions
Dofile Issue Solution
Stopping dofile execution at a Use the native Tcl “error” command to stop execution of a
specific point dofile at any point. The “error” command requires a
message string which the tool outputs. But to avoid any
message you can use an empty string:
error ""
Escaping Tcl special characters Use the following techniques to escape Tcl special
characters:
• Double quotes (" ") group tokens but allow $variable and
[command] evaluations.
• Braces ({}) also group tokens and disable $variable and
[command] evaluations.
• Brackets ([ ]) implement command substitution and are
used to nest or embed commands.
• A backslash (\) escapes the next character. Use this to
tame a Tcl special character such as $, [, {, or ".
Using dollar signs in pathnames A dollar sign ($) specifies variable substitution. In some
netlists, pathnames (for example, foo/pin$p7) can contain
the dollar sign. When using pathnames with dollar signs,
enclose the pathname with braces ({ }) to prevent the tool
from substituting the value as shown in the following
example:
report_gates {foo/pin$p7}

December 2017
Special Tcl Characters
Table B-1. Common Dofile Issues and Solutions (cont.)

Dofile Issue Solution
Escaping quotation marks In Tcl, quotation marks (" ") instruct the Tcl interpreter to
treat the enclosed words as a single argument. For example:
puts " Hello World "
If embedded quotes are required, you must use backslashes (

\ ) to escape the embedded double quotes. For example:
puts " Hello \"World\" "
Otherwise, the tool issues an error message.

Using brackets Brackets ([ ]) implement command substitution and are used
to nest or embed commands. A command and its arguments
enclosed in square brackets is evaluated and its result
inserted in place in the enclosing command.
Optional single quotes Optional single quotes (' ') are no longer valid for Tessent
commands. For example, the following produces an error:
set_design_sources '-v MODB.v -v MODC.v'
Correct this by using no quotes, double quotes, or braces:

set_design_sources -v MODB.v -v MODC.v
set_design_sources "-v MODB.v -v MODC.v"
set_design_sources {-v MODB.v -v MODC.v}
Environment variables You should use Tcl syntax for setting and referencing
variables, including using $env(ENVARNAME) for
accessing environment variables. For example, if the value
of environment variable “foo” equals “mode1” ($foo =
mode1), you can compare this value to a Tcl variable value
using the following syntax:
set bar mode2
if {$env(foo) == $bar}
{puts "Match"}
else
{puts "No match"}

In Tcl scripts, you often see characters used for special purposes. For a complete list of special
characters, you should consult a Tcl resource.
Table B-2 lists and describes the more common special characters you can encounter when
reading the examples in this manual. See the additional resources described in “Tcl Resources”
on page 424.

December 2017
Table B-2. Common Tcl Characters

Character Description
; The semicolon terminates the previous command, allowing you to place more
than one command on the same line.
\ Used at the end of a line, the backslash continues a command on the following
line.
\$ The backslash with other special characters, like a dollar sign, instructs the Tcl
interpreter to treat the character literally.
\n The backslash with the letter “n” instructs the Tcl interpreter to create a new line.
$ The dollar sign in front of a variable name instructs the Tcl interpreter to access
the value stored in the variable.
[] Square brackets group a command and its arguments, instructing the Tcl
interpreter to treat everything within the brackets as a single syntactical object.
You use square brackets to write nested commands. For example:
set chain_report [report_scan_chains -subchains -verbose]
{} Curly braces instruct the Tcl interpreter to treat the enclosed words as a single
string. The Tcl interpreter accepts the string as is, without performing any variable
substitution or evaluation. For example, to create a string that contains special
characters such as $ or \:
set my_string {This book costs $25.98.}
"" Quotes instruct the Tcl interpreter to treat the enclosed words as a single string.
However, when the Tcl interpreter encounters variables or commands within
string in quotes, it evaluates the variables and commands to generate a string. For
example, to create a string that displays a final cost calculated by adding two
numbers:
set my_string “This book costs \$[expr $price + $tax]”

December 2017
Table B-2. Common Tcl Characters (cont.)

Character Description
# The pound sign (#) indicates a comment and directs the Tcl compiler to not
evaluate the rest of the line. When using the pound sign, you must use it where a
command starts, and at the beginning of a command, not within a command.
• Tricky Point 1: Evaluate does not equal parse. Despite the pound sign, the
comment below gives an error because Tcl detects an open lexical clause.
# if (some condition) {
if { new text condition } {
...
}
• Tricky Point 2: The apparent beginning of a line is not always the beginning
of a command:
# This is a comment
In the following code snippet, the line beginning with “# -type” is not a comment,
because the line right above it has a line continuation character (\). In fact, the “#”
confuses the Tcl interpreter, resulting in an error when it attempts to create the
tk_messageBox.
tk_messageBox -message "The diagnosis report was successfully

written."\
# -type ok
# and this is also a comment. This one will span \

multiple lines, even without the # at the beginning \
of the second and third lines.
In general, it is good practice to begin all comment lines with a #.

• Tricky Point 3: The beginning of a command is not always at the beginning
of a line:
Usually, you begin new commands at the beginning of a line. That is, the first
non-space character is the first character of the command name. However, you
can combine multiple commands into one line using the semicolon “;” to
designate the end of the previous command:
set myname “John Doe” ; set this_string “next command”

set yourname “Ted Smith” ; # this is a comment

December 2017
Custom Tcl Packages in Tessent Shell
Custom Tcl Packages in Tessent Shell

Tessent Shell supports several standard techniques for adding your own Tcl packages with the
Tcl “package require” command, which you can issue from Tessent Shell.
You can use any of the following ways to specify directory locations of Tcl packages. Any
directory that contains a Tcl package must also contain a pkgIndex.tcl file within its hierarchy.
The following methods are listed in order of the precedence in effect if there is more than one
package with the same name:
• Default location for Tessent Shell Tcl packages. You can place your package underneath
a directory named tessent_plugin/packages that is located at the top of your Tessent
install tree. When Tessent Shell finds a package in this directory upon invocation, it
appends the directory path to tessent_plugin/packages to the auto_path Tcl global
variable, if it exists.
• TESSENT_PLUGIN_PATH environment variable. You can set this variable to a colon-
separated list of directory paths that contain Tcl packages in a packages subdirectory.
When Tessent Shell finds a package, it appends the directory path to packages to the
auto_path Tcl global variable, if it exists.
• auto_path Tcl global variable. You can issue the following command in Tessent Shell to
specify a package location:
> lappend auto_path pathToTclPackageDir
• TCLLIBPATH environment variable. You can set this variable to a space-separated list
of directory paths that contain Tcl packages. Note that a packages subdirectory is not
required under any of the paths.
Note
Tessent Shell ignores the TCL_LIBRARY environment variable.
Tcl Resources
The following website is a place to start in your search for the reference material that works best
for you. It is not an endorsement of any book or website.
http://www.tcl.tk/

December 2017
Appendix C
Transitioning from the Classic Point Tools
This appendix provides information to help you make the optional transition from the classic
Tessent point tools to Tessent Shell. The point tool application commands are forward-
compatible, so your dofiles work properly in Tessent Shell with only minor modifications. The
main differences involved in using Tessent Shell is that you have to set the context before doing
anything else, and then you must load the netlist and library.
Note that the classic Tessent point tools are available in the current release, so all of your
existing dofiles and startup scripts continue to work as before. However, Mentor Graphics
recommends that you start planning your transition now because each release of Tessent Shell
contains additional features not available in the classic point tools, and future releases of
Tessent Shell will continue to add new features that are not available in the classic point tools.
For information about specific point tools refer to the following sections:
Transitioning from the Classic FastScan Point Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

Transitioning from the Classic TestKompress Point Tool. . . . . . . . . . . . . . . . . . . . . . . . 426
Transitioning from the Classic DFTAdvisor Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Transitioning from the Classic Diagnosis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Transitioning from the Classic FastScan Point

Tool
Beginning with the v2012.3 release, you can optionally transition from the classic FastScan
point tool to Tessent Shell. Tessent Shell provides all of the commands available in the classic
FastScan point tools (invoked with the “fastscan” shell command) plus additional features.

December 2017
Transitioning from the Classic TestKompress Point Tool
If you are already familiar with classic FastScan, the main differences involved in using Tessent
Shell is that you have to set the context before doing anything else, and then you must load the
Verilog netlist and library:

read_verilog netlist_name
read_cell_library library_name
set_current_design
Another difference with using Tessent Shell is that several system modes used with classic
FastScan (atpg, good, fault) have been replaced with a single system mode (called analysis).
This means that “set_system_mode atpg” invocations (as well as transitions to good or fault
modes) are replaced by “set_system_mode analysis.” To facilitate your transition to Tessent
Shell, the set_system_mode command continues to accept the atpg/good/fault arguments, but
the tool actually switches to analysis mode.
Also, it is highly recommended for any simulation to replace the old “set_pattern_source
external” and “run” commands with the new read_patterns and simulate_patterns commands.
Unlike the “run” command, which has slightly different behavior in the good/fault/atpg system
modes, the simulate_patterns command allows you to explicitly control which pattern set to
simulate and which patterns (if any) to store in the internal pattern set.
Transitioning from the Classic TestKompress

Point Tool
Beginning with the v2012.3 release, you can optionally transition from the classic
TestKompress point tool to Tessent Shell. Tessent Shell provides all of the commands available
in the classic point tool (invoked with the “testkompress” shell command) for EDT IP creation
and test pattern generation plus additional features.
The following list describes how Tessent Shell is different from the classic TestKompress tool
for creating EDT IP:
• Before issuing any commands, set the context to “dft -edt”:

set_context dft -edt
Once you have set the context, all commands in setup mode of classic TestKompress are
available in the setup mode of Tessent Shell. All commands available in atpg mode of
classic TestKompress (IP creation phase) are available in analysis mode of Tessent
Shell.

December 2017
Transitioning from the Classic DFTAdvisor Tool
• Use the existing write_edt_files command to generate all EDT files, including RTL,
dofiles, the test procedure file, and synthesis and timing verification scripts. You can
issue this command only when in analysis mode. Note that the write_edt_files command
does not write out the EDT IP netlist, so you must do this with the write_design
command.
• For internal IP location flow-based EDT insertion with classic TestKompress, the tool
writes out all EDT files, inserts EDT IP into the design, and automatically changes to
insertion mode. You then have the ability to further edit the netlist, but you must
explicitly save changes with the write_design command.
Unlike classic TestKompress, Tessent Shell does not automatically exit after executing a
write_edt_files command, so you must explicitly exit when ready. This is so that after IP
insertion into the design, you can perform further design editing before writing out the
design, or configure how to write out the design using the write_design command. Also
note that Tessent Shell does not write out the netlist as part of the write_edt_files
command, so you must write out the netlist using the write_design command.
• The classic TestKompress command write_edt_files has a switch named
“-insertion tk.” In Tessent Shell, this switch is renamed “-insertion ts.”
The following list describes how Tessent Shell is different from the classic TestKompress tool
for generating patterns:
• Before generating compressed patterns, set the context to “patterns -scan”:

Once you’ve set the context, all commands in the setup mode of classic TestKompress
are available in setup mode of Tessent Shell. And all commands available in the atpg
mode of classic TestKompress (Test Pattern Generation phase) are available in the
analysis mode of Tessent Shell.
Transitioning from the Classic DFTAdvisor

Tool
Beginning with the v2012.3 release, you can optionally transition from the classic DFTAdvisor
point tool to Tessent Shell. Tessent Shell and Tessent Scan provide all of the commands
available in the classic DFTAdvisor tool (invoked with the “dftadvisor” shell command), plus
additional features.

December 2017
Transitioning from the Classic Diagnosis Tool
The following lists the differences between the classic DFTAdvisor tool and Tessent Scan:
• You no longer need to use the “run” command. Analysis that was previously done using
the “run” command is now done automatically after DRC or as part of the
analyze_wrapper_cells and insert_test_logic commands.
• After issuing insert_test_logic in analysis mode, the tool updates the design and then
changes to insertion mode. This allows you to optionally perform further design editing
before writing out the netlist with the write_design command.
• There is no longer a system mode called Dft. Use analysis mode instead.
• Before you issue any of the classic DFTAdvisor commands, you must first set the
context:
set_context dft -scan
Transitioning from the Classic Diagnosis Tool

Beginning with the v2012.3 release, you can optionally transition from the classic Diagnosis
point tool to Tessent Shell. Tessent Shell provides all of the commands available in the classic
Diagnosis tool (invoked with the “tessent -diagnosis” shell command), plus additional features.
Note that the classic Tessent point tools is available in the current release, so all of your existing
dofiles and startup scripts continue to work as before. However, Mentor Graphics recommends
that you start planning your transition now because each release of Tessent Shell contains
additional features not available in the classic point tools, and future releases of Tessent Shell
will continue to add new features that are not available in the classic point tools.
After invoking Tessent Shell with the “tessent -shell” command, at a minimum, you must
perform the following operations in sequence to enable scan diagnosis in Tessent Shell:
1. Set the context before doing anything else:

set_context patterns -scan_diagnosis
2. Read the flat model of your design:

read_flat_model flat_model_name
Previously, you specified the flattened design with the “tessent -diagnosis” command.
Now you must use the read_flat_model command.

December 2017
Appendix D
Formal Verification
Tessent Shell-based products currently do not generate scripts for use with Synopsys Formality.
You can, however, set constraints in your design that are used with Formality.
Constraints for Formality Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Constraints for Formality Scripts

The following guidance is provided to aid you in manually creating a script for with Formality.
Golden RTL Versus DFT Inserted RTL

Set the following:
• Set the circuit in functional mode. This is basically holding the IJTAG network and/or
TAP in reset.
• If you are at the chip level, set a constant 0 on TRST. If you are at the sub_block/
physical_block level, set a constant 1 on the ijtag_reset port(s).
• In both design levels, if your design has DftSignals coming from ports, they need to be
set constant to their reset values. DftSignals from the TDR will automatically be handled
by the reset.
• If you are at the sub_block or physical_block level, prevent the verification of ports
created by Tessent Shell or they will report violations.
• Find all the instruments and SIBs that the Tessent tools inserted and assert the ijtag_reset
pins to their active value.
• Since the ICL network may already be present our SIBs could result in mismatches on
the ICL network scan path. The SIB scan in/outs would probably have to be set as “don't
verify points”.
Pre-Layout Versus Post-Layout

You want to make sure the layout did not break DFT functionality as well. The only thing to
ignore is if you have done scan insertion; scan chain re-ordering will report violations. The
scan_en signal needs to be set to a constant low. Nothing else should be constrained on the
inserted DFT.

December 2017
Formal Verification
Constraints for Formality Scripts
EDT
Constraining scan_en to 0 (the same as requirement for scan insertion) is sufficient to proceed
with equivalence checking. The formal verification tool will report some unmatched nodes like
the newly-added EDT pins (clock/update/bypass/low_power/channel) and registers inside the
EDT logic.
OCC
If the OCC has an IjtagInterface, or if the test_mode pin of the OCC is connected to an
IjtagNetwork, then keeping the ijtag network in reset state is sufficient for OCC. Otherwise (that
is, the test_mode port is connected to a top-level port), this port needs to be constrained to 0.

December 2017
Appendix E
Getting Help
There are several ways to get help when setting up and using Tessent software tools. Depending
on your need, help is available from documentation, online command help, and Mentor
Graphics Support.
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Mentor Support Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
The Tessent Documentation System

At the center of the documentation system is the InfoHub that supports both PDF and HTML
content. From the InfoHub, you can access all locally installed product documentation, system
administration documentation, videos, and tutorials. For users who want to use PDF, you have a
PDF bookcase file that provides access to all the installed PDF files.
For information on defining default HTML browsers, setting up browser options, and setting the
default PDF viewer, refer to the “Documentation Options” in the Mentor Documentation
System manual.
You can access the documentation in the following ways:
• Shell Command — On Linux platforms, enter mgcdocs at the shell prompt or invoke a
Tessent tool with the -manual invocation switch.
• File System — Access the Tessent InfoHub or PDF bookcase directly from your file
system, without invoking a Tessent tool. For example:
HTML:
firefox $MGC_DFT/docs/infohubs/index.html
PDF
acroread $MGC_DFT/docs/pdfdocs/_bk_tessent.pdf
• Application Online Help — ou can get contextual online help within most Tessent
tools by using the “help -manual” tool command. For example:
> help dofile -manual
This command opens the appropriate reference manual at the “dofile” command
description.

December 2017
Getting Help
Mentor Support Services
Mentor Support Services

Mentor provides a range of industry-leading support services that keep design teams productive
and up-to-date with Mentor products.
A Mentor support contract includes the following:
• Software Updates — Get the latest releases and product enhancements to keep your
environment current.
• Mentor Graphics Support Center — Access our online knowledge base, personalized
to your Mentor products.
• Support Forums — Learn, share, and connect with other Mentor users.
• Technical Support — Collaborate with Mentor support engineers to solve complex

design challenges.
• Regular Communications — Receive the latest knowledge base articles and

announcements for your Mentor products.
• Mentor Ideas — Share ideas and vote for your favorites to shape future products.
More information is available here:
https://support.mentor.com
If your site is under a current support contract, but you do not have a Support Center login,
register today:
https://support.mentor.com/register

December 2017
Index
Command Quick Reference, 284

Index
— Symbols — overview, 184

#include statement, 293 windows, 186
—A— —E—
Alias statements, 297 EMPTY, 344, 345
Always block, 310 Environment Variables
Always block example, 311 TESSENT_LICENSE_ORDER, 26
Always block statements Environment variables
always_statement, 311 application-specific, 26
force, 311 MGCDFT_STARTUP, 26
pulse, 311 external capture procedure, 349
Always block syntax, 311
—I—
—C— Include statement, 293
Clock procedure, 343
Clock_run procedure, 346 —N—
Cycle statements Named capture procedure, 349
bidi_force_off, 319
bidi_force_pi, 318 —P—
bidi_measure_po, 318 Procedure statements
condition, 320 apply, 316
expect, 320 cycle, 311
force, 320 label, 316
force_pi, 318 scan_group, 314
force_sci, 318 timeplate, 314
force_sci_equiv, 318 —S—
initialize, 320 Sequential_transparent procedure, 342
measure, 320 Set statement, 294
measure_po, 318 Set statements
measure_sco, 318 default_timeplate, 296
observe_method, 320 strobe_window time, 295
pulse, 320 time scale, 294
pulse_capture_clock, 319 Shift procedure, 334
pulse_read_clock, 319 alternate, 336
pulse_write_clock, 319 Sub_procedure, 360
restore_bidi, 319
restore_pi, 318 —T—
Test procedure file
—D— defined, 288
DFTVisualizer DRC checking, 288

December 2017
statements, 294
timing variables, 299
Test procedures
capture, 349
clock_po, 355
clock_sequential, 357
init_force, 358
load_unload, 337
master_observe, 340
ram_passthru, 356
ram_sequential, 355
shadow_control, 340
shadow_observe, 341
shift, 334
skew_load, 344
sub_procedure, 360
test_end, 358
test_setup, 331
Test_end procedure, 358
Time scale
setting, 294
Timeplate statements
bidi_force_pi, 303
bidi_measure_po, 304
force, 304
force_pi, 303
measure, 304
measure_po, 304
offstate, 303
period, 306
pulse, 304
pulse_clock, 305
Transparent_capture cells, 344
tscale, 294

December 2017
Third-Party Information
For information about third-party software included with this release of Tessent products, refer to the Third-Party Software for
Tessent Products.
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.
1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.
3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.
4. RESTRICTIONS ON USE.
4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.
4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.
4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.
4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.
4.5. The provisions of this Section 4 shall survive the termination of this Agreement.
5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.
6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
(including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in
compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
9. THIRD PARTY CLAIMS.
9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.
9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.
9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.
10. INFRINGEMENT.
10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.
10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
11. TERMINATION AND EFFECT OF TERMINATION.
11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.
11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.
12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.
13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.
14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.
16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be
incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including for
example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The United
Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.
18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.
Rev. 170330, Part No. 270941

Tshell User

Uploaded by

Copyright:

Available Formats

Tshell User

Uploaded by

Document Information

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

Tshell User

Uploaded by

Copyright:

Available Formats

Tessent® Shell User’s Manual

Software Version 2017.4

© 2012-2017 Mentor Graphics Corporation

Mentor Graphics Corporation

Send Feedback on Documentation: support.mentor.com/doc_feedback_form

Revision Changes Status/

Tessent® Shell User’s Manual, v2017.4

Tessent® Shell User’s Manual, v2017.4 5

6 Tessent® Shell User’s Manual, v2017.4

Tessent® Shell User’s Manual, v2017.4 7

Marking and Unmarking Objects in the Schematic Windows . . . . . . . . . . . . . . . . . . . . . . 197

8 Tessent® Shell User’s Manual, v2017.4

DFTVisualizer Command Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Tessent® Shell User’s Manual, v2017.4 9

Static Versus Dynamic Register Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

10 Tessent® Shell User’s Manual, v2017.4

Example Encounter Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Tessent® Shell User’s Manual, v2017.4 11

12 Tessent® Shell User’s Manual, v2017.4

Figure 2-1. Hierarchical Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Tessent® Shell User’s Manual, v2017.4 13

14 Tessent® Shell User’s Manual, v2017.4

Table 1-1. Tessent Shell Command Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Tessent® Shell User’s Manual, v2017.4 15

16 Tessent® Shell User’s Manual, v2017.4

What Is Tessent Shell?

Tessent® Shell User’s Manual, v2017.4 17

What Can You Do With Tessent Shell?

18 Tessent® Shell User’s Manual, v2017.4

Tessent® Shell User’s Manual, v2017.4 19

Tessent Shell Tcl Interface

> help get_*

Table 1-1. Tessent Shell Command Conventions

20 Tessent® Shell User’s Manual, v2017.4

Table 1-1. Tessent Shell Command Conventions (cont.)

command_name command_options command_option_values

set_config_value -in_wrapper /TopBuilder(CHIP)

Command Name Tab Completion

SETUP> g_a_l <tab>

Tessent® Shell User’s Manual, v2017.4 21

Command Option Name Tab Completion

SETUP> get_config_value -m<tab>

Command Option Value Tab Completion

• Configuration data path

SETUP> set_config_value -in_wrapper /TopB<tab>

Enum Value Example

SETUP> get_config_value -time_unit <tab>

22 Tessent® Shell User’s Manual, v2017.4

Tcl Command Registration

Tessent® Shell User’s Manual, v2017.4 23

24 Tessent® Shell User’s Manual, v2017.4

Tessent® Shell User’s Manual, v2017.4 25

Tessent Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Tessent Startup File

Tessent Shell Environment Variables

26 Tessent® Shell User’s Manual, v2017.4

Table 2-1. Application-Specific Environment Variables (cont.)

Tessent® Shell User’s Manual, v2017.4 27

Contexts and System Modes

28 Tessent® Shell User’s Manual, v2017.4