Edt GD 1

SIEMENS EDA
Tessent™ TestKompress™
User’s Manual
Software Version 2021.3
Document Revision 22
Unpublished work. © 2021 Siemens
This material contains trade secrets or otherwise confidential information owned by Siemens Industry Software, Inc.,
its subsidiaries or its affiliates (collectively, "Siemens"), or its licensors. Access to and use of this information is
strictly limited as set forth in Customer's applicable agreement with Siemens. This material may not be copied,
distributed, or otherwise disclosed outside of Customer's facilities without the express written permission of
Siemens, and may not be used in any way not expressly authorized by Siemens.
This document is for information and instruction purposes. Siemens 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 Siemens to determine whether any changes have been made. Siemens disclaims all warranties with
respect to this document including, without limitation, the implied warranties of merchantability, fitness for a
particular purpose, and non-infringement of intellectual property.
The terms and conditions governing the sale and licensing of Siemens products are set forth in written agreements
between Siemens and its customers. Siemens' End User License Agreement may be viewed at:
www.plm.automation.siemens.com/global/en/legal/online-terms/index.html.
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 Siemens whatsoever.
TRADEMARKS: The trademarks, logos, and service marks ("Marks") used herein are the property of Siemens or
other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the owner of
the Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a source of a
product, but is intended to indicate a product from, or associated with, a particular third party. A list of Siemens'
trademarks may be viewed at: www.plm.automation.siemens.com/global/en/legal/trademarks.html. 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.
Support Center: support.sw.siemens.com

Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form
Revision History ISO-26262
Revision Changes Status/

Date
22 Modifications to improve the readability and comprehension of Released
the content. Approved by Lucille Woo. Sep 2021
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. Jun 2021
the content. Approved by Lucille Woo. Mar 2021
the content. Approved by Lucille Woo. Dec 2020
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 Siemens
documentation source. For specific topic authors, contact the Siemens Digital Industries
Software documentation department.
Revision History: Released documents include a revision history of up to four revisions. For
earlier revision history, refer to earlier releases of documentation on Support Center.
Tessent™ TestKompress™ User’s Manual, v2021.3
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
4 Tessent™ TestKompress™ User’s Manual, v2021.3
Table of Contents
Revision History ISO-26262
Chapter 1
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Tessent TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
EDT Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Scan Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Structure and Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
TestKompress Compression Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
TestKompress Usage Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
EDT IP Creation and Pattern Generation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Pre-Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Tessent Core Description (TCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
EDT IP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
EDT Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
EDT Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Using TCD-Based Flow With Flattened EDT Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tessent Shell User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Chapter 2
The Compressed Pattern Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Top-Down Design Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
The Compressed Pattern Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Design Requirements for a Compressed Pattern Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Compressed Pattern External Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Compressed Pattern Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Chapter 3
Scan Chain Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Design Preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Scan Chain Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
OCC Sub-Chain Stitching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
ATPG Baseline Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 4
Creation of the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Compression Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Analyzing Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Preparation for EDT Logic Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Parameter Specification for the EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Dual Compression Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Tessent™ TestKompress™ User’s Manual, v2021.3 5

Table of Contents
Defining Dual Compression Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Asymmetric Input and Output Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Bypass Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Latch-Based EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Compactor Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Pipeline Stages in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Pipeline Stages Added to the Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Longest Scan Chain Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
EDT Logic Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
EDT Architecture Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Specifying Hard Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Pulse EDT Clock Before Scan Shift Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Reporting of the EDT Logic Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
EDT Control and Channel Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
EDT Control and Channel Pin Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Functional/EDT Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Shared Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Connections for EDT Pins (Internal Flow Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Internally Driven EDT Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Structure of the Bypass Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Decompressor and Compactor Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
IJTAG and the EDT IP TCD Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Design Rule Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Creation of EDT Logic Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
The EDT Logic Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
IJTAG and EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Specification of Module/Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
EDT Logic Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Inserting EDT Logic During Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Creation of a Reduced Netlist for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Chapter 5
Synthesizing the EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
The EDT Logic Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Synthesis and External EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Synthesis and Internal EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
SDC Timing File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
SDC Timing File Generation Using extract_sdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
SDC Timing File Generation Using write_edt_files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
EDT Logic/Core Interface Timing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Scan Chain and ATPG Timing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Chapter 6
Generating and Verifying Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Preparation for Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
EDT Pattern Generation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
IJTAG Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Scan Chain Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Table of Contents
Core Instance Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Used Input Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Pattern Generation With Internal Chain Masking Hardware . . . . . . . . . . . . . . . . . . . . . . . 146
Updating Scan Pins for Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Verification of the EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Design Rules Checking (DRC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
EDT Logic and Chain Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Reducing Serial EDT Chain Test Simulation Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Generating Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Compression Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Saving of the Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Post-Processing of EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Simulation of the Generated Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Chapter 7
Modular Compressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
The Modular Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Understanding Modular Compressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Development of a Block-Level Compression Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Balancing Scan Chains Between Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Sharing Input Scan Channels on Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Channel Sharing for Non-Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Overview of Channel Sharing Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Compression Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
EDT IP Creation With Separate Control and Data Input Channels . . . . . . . . . . . . . . . . . 172
Rules for Connecting Input Channels from Cores to Top . . . . . . . . . . . . . . . . . . . . . . . . 175
Channel Sharing Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Channel Sharing Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Mixing Channel Sharing for Non-Identical EDT Blocks and Channel Broadcasting for
Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Generating Modular EDT Logic for a Fully Integrated Design . . . . . . . . . . . . . . . . . . . . . 179
Estimating Test Coverage/Pattern Count for EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 180
Legacy ATPG Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Chapter 8
Compressed ATPG Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Low-Power Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Low-Power Shift. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Setting Up Low-Power Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Low Pin Count Test Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
LPCT Controller Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Test Mode Clock Multiplexer Requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Sharing of the LPCT Clock and a Top-Level Scan Clock . . . . . . . . . . . . . . . . . . . . . . . . 200
Shift Clock Control for LPCT Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Type 1 LPCT Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Table of Contents
Tessent OCC and LPCT Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

LPCT Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
LPCT Controller Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Type 1 - LPCT Controller With Top-level Scan Enable . . . . . . . . . . . . . . . . . . . . . . . . . 213
Type 2 - LPCT Controller With a TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Type 3 - LPCT Controller-Generated Scan Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
LPCT Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Type 1 Controller Generation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Type 3 Controller Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Type 1 Controller LPCT Clock Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Type 2 Controller Scan Shift Clock Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Compression Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Structure of the Bypass Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Generating EDT Logic When Bypass Logic Is Defined in the Netlist. . . . . . . . . . . . . . . . 234
Dual Bypass Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Generation of Identical EDT and Bypass Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Use of Bypass Patterns in Uncompressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Creating Bypass Test Patterns in Uncompressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Uncompressed ATPG (External Flow) and Boundary Scan . . . . . . . . . . . . . . . . . . . . . . . . . 243
Boundary Scan Coexisting With EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Drive Compressed ATPG With the TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Use of Pipeline Stages in the Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Use of Pipeline Stages Between Pads and Channel Inputs or Outputs . . . . . . . . . . . . . . . . . 250
Channel Output Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Clocks for Channel Input Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Clocks for Channel Output Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Input Channel Pipelines Must Hold Their Value During Capture . . . . . . . . . . . . . . . . . . . 253
DRC for Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
DRC for Channel Output Pipelining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Input/Output Pipeline Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Change Edge Behavior in Bypass and EDT Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Understanding Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Lockup Cell Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Lockup Cell Analysis for Bypass Lockup Cells Not Included as Part of the EDT Chains 259
Lockups Between Decompressor and Scan Chain Inputs . . . . . . . . . . . . . . . . . . . . . . . . 259
Lockups Between Scan Chain Outputs and Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . 261
Lockups in the Bypass Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Lockup Cell Analysis for Bypass Lockup Cells Included as Part of the EDT Chains . . . . 267
EDT Lockup and Scan Chain Boundary Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Differences Based on Inclusion/Exclusion of Bypass Lockup Cells in EDT Chains . . . 269
Lockup Cell Functionality Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Comparison of Bypass Lockup Cell Insertion Results. . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Lockups Between Channel Outputs and Output Pipeline Stages . . . . . . . . . . . . . . . . . . . . 275
Compression Performance Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Establishing a Point of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Performance Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Performance Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Table of Contents
Variance in the Number of Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Variance in the Number of Scan Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Determining the Limits of Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Speed up the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Understanding Compactor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Understanding Scan Chain Masking in the Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Fault Aliasing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
About Reordering Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Handling of Last Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
EDT Aborted Fault Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Chapter 9
Integrating Compression at the RTL Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
IP Generation and Insertion Using EDT Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Basic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Pipeline Stage Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Bused EDT Channel Input and Output Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Lockup Cells on the Input Side of the EDT Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Lockup Cells on the Output Side of the EDT Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Lockup Cells Clock Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
EDT Specification Wrapper Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Validating the EDT Specification and Creating the EDT IP . . . . . . . . . . . . . . . . . . . . . . . 300
Legacy Skeleton RTL Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Skeleton Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Skeleton Design Input and Interface Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Skeleton Design Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Skeleton Design Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Creation of the EDT Logic for a Skeleton Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Longest Scan Chain Range Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Integration of the EDT Logic Into the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Skeleton Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Global Customer Support and Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Appendix B
EDT Logic Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
EDT Logic With Basic Compactor and Bypass Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
EDT Logic With Xpress Compactor and Bypass Module. . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Decompressor Module With Basic Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Decompressor Module With Xpress Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Input Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Compactor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Output Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Single Chain Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Table of Contents
Basic Compactor Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Xpress Compactor Controller Masking Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Dual Compression Configuration Input Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Dual Compression Configuration Output Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
EDT Logic With Power Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Appendix C
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Debugging Simulation Mismatches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Resolving DRC Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
K19 Through K22 DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Debugging Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Understanding K19 Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Incorrect Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Inverted Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Incorrect EDT Channel Signal Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Incorrect Scan Chain Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
X Generated by EDT Decompressor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Using “set_gate_report drc_pattern K19” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Understanding K22 Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Inverted Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Incorrect Scan Chain Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Masking Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Incorrect References in Synthesized Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Limiting Observable Xs for a Compact Pattern Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Applying Uncompressable Patterns With Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 365
If Compression Is Less Than Expected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
If Test Coverage Is Less Than Expected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
If There Are EDT Aborted Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Internal Scan Chain Pins Incorrectly Shared With Functional Pins . . . . . . . . . . . . . . . . . . 367
Masking Broken Scan Chains in the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Appendix D
Dofile-Based Legacy IP Creation and Pattern Generation Flow . . . . . . . . . . . . . . . . . . . . 369
EDT IP Generation Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Test Pattern Generation Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
EDT Bypass Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
EDT Pattern Generation Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Generated Bypass Dofile and Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Creation of Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Low Pin Count Test Controller Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Type 1 Controller Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

Table of Contents
Index
Third-Party Information

Table of Contents

List of Figures
Figure 1-1. EDT as Seen From the Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 1-2. Tester Connected to a Design With EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 1-3. EDT Logic Located Outside the Core (External Flow) . . . . . . . . . . . . . . . . . . . 24
Figure 1-4. EDT Logic Located Within the Core (Internal Flow). . . . . . . . . . . . . . . . . . . . . 24
Figure 1-5. Post-Synthesis EDT IP Creation and EDT Pattern Generation Flow . . . . . . . . . 30
Figure 1-6. Pre-Synthesis EDT IP Creation & EDT Pattern Generation TCD Flow . . . . . . 32
Figure 2-1. Top-Down Design Flow - External. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 2-2. Top-Down Design Flow - Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 2-3. Compressed Pattern External Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 2-4. Compressed Pattern Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 3-1. Bad Specified Bit Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3-2. Better Specified Bit Alignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 3-3. Best Specified Bit Alignment (Few Cells) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 3-4. Best Specified Bit Alignment (Many Cells) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 4-1. Default EDT Logic Pin Configuration With Two Channels. . . . . . . . . . . . . . . . 86
Figure 4-2. Example of a Basic EDT Pin Configuration (Internal EDT Logic) . . . . . . . . . . 87
Figure 4-3. Example With Pin Sharing Shown in (External EDT Logic) . . . . . . . . . . . . . . . 92
Figure 4-4. Internally Driven edt_update Control Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 4-5. Contents of the Top-Level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 4-6. Contents of the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 4-7. Design Netlist With Internal Connection Nodes. . . . . . . . . . . . . . . . . . . . . . . . . 120
Figure 5-1. Contents of Boundary Scan Top-Level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 6-1. Sample EDT Test Procedure Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Figure 6-2. Used Input Channels Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Figure 6-3. Example Decoder Circuitry for Six Scan Chains and One Channel. . . . . . . . . . 151
Figure 7-1. Modular Design With Five EDT blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Figure 7-2. Non-Separated Control Data Input Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Figure 7-3. Separated Control Data Input Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Figure 7-4. Channel Sharing Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure 7-5. Non-Channel Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Figure 7-6. Channel Sharing Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Figure 7-7. Channel Sharing Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Figure 7-8. Mixing Channel Sharing and Channel Broadcasting — Case 1 . . . . . . . . . . . . . 177
Figure 7-9. Mixing Channel Sharing and Channel Broadcasting — Case 2 . . . . . . . . . . . . . 178
Figure 7-10. Mixing Channel Sharing and Channel Broadcasting — Case 3 . . . . . . . . . . . . 179
Figure 7-11. Netlist With Two Cores Sharing EDT Control Signals . . . . . . . . . . . . . . . . . . 182
Figure 8-1. Low Power Controller Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 8-2. LPCT Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Figure 8-3. LPCT Controller Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 8-4. Clock Gater for Sharing LPCT Clock With Top-Level Scan Clock. . . . . . . . . . 201

List of Figures
Figure 8-5. -shift_control Option: clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Figure 8-6. -shift_control Option: enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Figure 8-7. shift_control Option: enable With Tessent OCC . . . . . . . . . . . . . . . . . . . . . . . . 204
Figure 8-8. Shift Clock Option: none . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Figure 8-9. Type 1 LPCT Controller Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Figure 8-10. Type 2 LPCT Controller Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Figure 8-11. Type 3 LPCT Controller Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Figure 8-12. Type 1 LPCT Controller Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Figure 8-13. Signal Waveforms for Type 1 LPCT Controller. . . . . . . . . . . . . . . . . . . . . . . . 215
Figure 8-14. LPCT Controller With TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Figure 8-15. Signal Waveforms for TAP-Based LPCT Controller . . . . . . . . . . . . . . . . . . . . 218
Figure 8-16. Before and After EDT and LPCT Controller Logic . . . . . . . . . . . . . . . . . . . . . 219
Figure 8-17. Scan Test Pattern Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Figure 8-18. Chain Test Pattern Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Figure 8-19. Type 2 LPCT Design Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Figure 8-20. Bypass Mode Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Figure 8-21. Channel Outputs and Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Figure 8-22. Scan Chain and Bypass Lockup Cells Not in the EDT Scan Chain . . . . . . . . . 270
Figure 8-23. Scan Chain and Bypass Lockup Cells in the EDT Scan Chain . . . . . . . . . . . . 271
Figure 8-24. TE CLK to TE CLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Figure 8-25. LE Clk to TE Clk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Figure 8-26. LE Clk1 to LE Clk2 Overlapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Figure 8-27. LE ClkS to TE ClkD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Figure 8-28. ClkS to ClkD, Both Clocks Later Than EDT Clock . . . . . . . . . . . . . . . . . . . . . 275
Figure 8-29. Evaluation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Figure 8-30. Basic Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Figure 8-31. Xpress Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Figure 8-32. X-Blocking in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Figure 8-33. X Substitution for Unmeasurable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Figure 8-34. Example of Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Figure 8-35. Handling of Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Figure 8-36. Example of Fault Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Figure 8-37. Using Masked Patterns to Detect Aliased Faults . . . . . . . . . . . . . . . . . . . . . . . 289
Figure 8-38. Handling Scan Chains of Different Length. . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Figure 9-1. Lockup Cell EDT Controller Input Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Figure 9-2. Lockup Cells on EDT Controller Output Side . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Figure 9-3. EDT IP Creation RTL Stage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Figure 9-4. create_skeleton_design Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Figure 9-5. Skeleton Design Input File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Figure 9-6. Skeleton Design Input File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Figure C-1. Flow for Debugging Simulation Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Figure C-2. Order of Diagnostic Checks by the K19 DRC . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Figure C-3. Order of Diagnostic Checks by the K22 DRC . . . . . . . . . . . . . . . . . . . . . . . . . . 355

List of Tables
Table 1-1. Supported Scan Architecture Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Table 4-1. Example Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 4-2. Default EDT Pin Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Table 5-1. Timing File Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Table 6-1. Core Instance Parameters and Values by Instrument . . . . . . . . . . . . . . . . . . . . . 140
Table 7-1. Modular Flow Stage Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Table 7-2. Modular Compressed ATPG Command Summary . . . . . . . . . . . . . . . . . . . . . . . 184
Table 8-1. LPCT Controller Type 1 Commands and Switches . . . . . . . . . . . . . . . . . . . . . . 206
Table 8-4. Lockup Cells Between Decompressor and Scan Chain Inputs . . . . . . . . . . . . . . 260
Table 8-5. Lockup Cells Between Scan Chain Outputs and Compactor . . . . . . . . . . . . . . . 261
Table 8-6. Bypass Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Table 8-7. EDT Lockup and Scan Chain Boundary Lockup Cells . . . . . . . . . . . . . . . . . . . . 267
Table 8-8. Lockup Insertion Between Channel Outputs and Output Pipeline . . . . . . . . . . . 276
Table 8-9. Summary of Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

List of Tables

Chapter 1
Getting Started
This manual describes how to integrate Tessent ™ TestKompress™ into your design process.
More information can be found in the following manuals:
• Tessent Shell Reference Manual — Contains information on Tessent TestKompress

commands and information for all DRCs including the Tessent TestKompress-specific
EDT Rules.
• Tessent Shell User’s Manual — Contains information about the Tessent Shell
environment in which you use Tessent TestKompress.
For a complete list of Tessent-specific terms, including Tessent TestKompress-specific terms,
refer to the Tessent Glossary.
Tessent TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
EDT Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Scan Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
TestKompress Compression Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
TestKompress Usage Flow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
EDT IP Creation and Pattern Generation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Pre-Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
EDT Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Using TCD-Based Flow With Flattened EDT Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tessent Shell User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Tessent TestKompress
Tessent TestKompress is a Design-for-Test (DFT) product that creates test patterns and
implements compression for the testing of manufactured ICs. Advanced compression reduces
ATE memory and channel requirements and reduced data volume results in shorter test
application times and higher tester throughput than with traditional ATPG. TestKompress also
supports traditional ATPG.
Getting Started
Tessent TestKompress creates and embeds compression logic (EDT logic) and generates
compressed test patterns as follows:
• Test patterns — Tessent TestKompress generates compressed test patterns and loads
them onto the Automatic Test Equipment (ATE).
• Embedded logic — Tessent TestKompress generates EDT logic and embeds it in the IC
to:
a. Receive the compressed test patterns from the ATE and decompress them.
b. Deliver the uncompressed test patterns to the core design for testing.
c. Receive and compress the test results and return them to the ATE.
Tessent TestKompress is command-line driven from Tessent Shell:
• The IP Creation phase of Tessent TestKompress runs in the Tessent Shell “dft -edt”
context.
• The Pattern Generation phase of Tessent TestKompress runs in the Tessent Shell
“patterns -scan” context.
Supported Test Patterns

Tessent TestKompress supports most types of test patterns except the following:
• Random pattern generation.

• Tessent FastScan™ MacroTest. You can only apply MacroTest patterns to a design with
Tessent TestKompress by accessing the scan chains directly, bypassing the EDT logic.
Supported Scan Architectures
Tessent TestKompress logic supports mux-DFF and LSSD or a mixture of the scan
architectures as listed in Table 1-1.
Table 1-1. Supported Scan Architecture Combinations
EDT Logic Supported Scan Architectures
DFF-based LSSD, Mux-DFF, and mixed
Latch-based LSSD
Tessent TestKompress Inputs

You need the following components to use Tessent TestKompress:
• Scan-inserted gate-level Verilog netlist.

• Synthesis tool.
Getting Started
• Compatible Tessent cell library of the models used for your design scan circuitry. If
necessary, you can convert Verilog libraries to a compatible Tessent cell library format
with the LibComp utility. For more information, see “Create Tessent Simulation Models
Using LibComp” in the Tessent Cell Library Manual.
• Timing simulator such as Questa™ SIM.
Potential Affects of Tessent TestKompress on the Design
Depending on the configuration and placement of the EDT logic, your design may be affected
as follows:
• Extra Level of Hierarchy — If you place the EDT logic outside the core design, you
must add a boundary scan wrapper which adds a level of hierarchy.
• Minimal Physical Space — The size of the EDT logic is roughly about 25 gates per
internal scan chain. The following examples can be used as guidelines to roughly
estimate the size of the EDT logic for a design:
o For a one million gate design with 200 scan chains, the logic BIST controller
including PRPG, MISR and the BIST controller, is 1.25 times the size of the EDT
logic for 16 channels.
o For a one million gate design configured into 200 internal scan chains, the EDT
logic including decompressor, compactor, and bypass circuitry with lockup cells
requires less than 20 gates per chain. The logic occupies an estimated 0.35% of the
area. The size of the EDT logic does not vary significantly based on the size of the
design.
o For 8 scan channels and 100 internal scan chains, the EDT logic was found to be
twice as large as a TAP controller, and 19% larger than the MBIST controller for a
1k x 8-bit memory.
Getting Started
EDT Technology
EDT Technology
Embedded Deterministic Testing (EDT) is the technology used by Tessent TestKompress. EDT
technology is based on traditional, deterministic ATPG and uses the same fault models to obtain
similar test coverage using a familiar flow. EDT extends ATPG with improved compression of
scan test data and a reduction in test time.
Tessent TestKompress achieves compression of scan test data by controlling a large number of
internal scan chains using a small number of scan channels. Scan channels can be thought of as
virtual scan chains because, from the point of view of the tester, they operate exactly the same
as traditional scan chains. Therefore, any tester that can apply traditional scan patterns can apply
compressed patterns as described in the following topics:
Scan Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Scan Channels
With Tessent TestKompress, the number of internal scan chains is significantly larger than the
number of external virtual scan chains the EDT logic presents to the tester.
Figure 1-1 illustrates conceptually how the tester considers a design tested with EDT
technology compared to the same design tested using conventional scan and ATPG.
Figure 1-1. EDT as Seen From the Tester
Getting Started
Structure and Function
Under EDT methodology, the virtual scan chains are called “scan channels” to distinguish them
from the scan chains inside the core. Their number is significantly less than the number of
internal scan chains. Two parameters determine the amount of compression:
• Number of scan chains in the design core

• Number of scan channels presented to the tester
For more information on establishing a compression target for your application, see “Effective
Compression” on page 27 and “Compression Analysis” on page 66.
Structure and Function

EDT technology consists of logic embedded on-chip, EDT-specific DRCs, and a deterministic
pattern generation technique.
The embedded logic includes a decompressor located between the external scan channel inputs
and the internal scan chain inputs, and a compactor located between the internal scan chain
outputs and the external scan channel outputs. See Figure 1-2.
Figure 1-2. Tester Connected to a Design With EDT
You have the option of including bypass circuitry for which the tool adds a third block (not
shown). It inserts no additional logic (test points or X-bounding logic) into the core of the
design. Therefore, EDT logic affects only scan channel inputs and outputs, and thus has no
effect on functional paths.
Figure 1-2 shows an example design with two scan channels and 20 short internal scan chains.
From the point of view of the ATE, the design appears to have two scan chains, each as long as
the internal scan chains. Each compressed test pattern has a small number of additional shift
Getting Started
Test Patterns
cycles, so the total number of shifts per pattern would be slightly more than the number of scan
cells in each chain.
Note
The term “additional shift cycles” refers to the sum of the initialization cycles, masking bits
(when using Xpress), low-power bits (when using a low-power decompressor), and user-
defined pipeline bits.
You can use the following equation to predict the number of initialization cycles the tool adds to
each pattern load. In this equation, <ceil> indicates the ceiling function that rounds a fraction to
the next highest integer. This equation applies except when you have very few channels, in
which case there are four extra cycles per scan load. This equation does not factor in additional
shift cycles added to support masking and low power.
For example, if a design has 16 scan channels, 1250 scan cells per chain, and a 50-bit
decompressor, we can calculate the number of initialization cycles as 4 by using the above
formula. Because each chain has 1,250 scan cells and each compressed pattern requires four
initialization cycles, the tester sees a design with 16 chains requiring 1,254 shifts per pattern.
Note
The EDT IP creation phase and ATPG generation phase may report a different number of
initialization cycles depending on whether low power is enabled. Enabling low power
increases the number of initialization cycles in the EDT IP creation phase.
Test Patterns
Tessent Shell generates compressed test patterns specifically for on-chip processing by the EDT
logic. For a given testable fault, a compressed test pattern satisfies ATPG constraints and avoids
bus contention, similar to conventional ATPG.
The ATE stores a set of compressed test patterns and each test pattern applies data to the inputs
of the decompressor and holds the responses observed on the outputs of the compactor. The
ATE applies the compressed test patterns to the circuit through the decompressor, which lies
between the scan channel pins and the internal scan chains. From the perspective of the tester,
there are relatively few scan chains present in the design.
The compressed test patterns, after passing through the decompressor, create the necessary
values in the scan chains to guarantee fault detection. The functional input and output pins are
directly controlled (forced) and observed (measured) by the tester, same as in a conventional
test. On the output side of the internal scan chains, hardware compactors reduce the number of
internal scan chains to feed the smaller number of external channels. The compactor compresses
Getting Started
TestKompress Compression Logic
the response captured in the scan cells and the tester compares the compressed response. The
compactor ensures faults are not masked and X-states do not corrupt the response.
You define parameters, such as the number of scan channels and the insertion of lockup cells,
which are also part of the RTL code. The tool automatically determines the internal structure of
the EDT hardware based on the parameters you specify, the number of internal scan chains, the
length of the longest scan chain, and the clocking of the first and last scan cell in each chain.
Test patterns include parallel and serial test benches for Verilog as well as parallel and serial
WGL, and most other formats supported formats.

Tessent TestKompress generates hardware in blocks in VHDL or Verilog RTL. You integrate
the compression logic (EDT logic) into your design by using Tessent Shell with the core level of
the design. The tool then generates the following three components:
• Decompressor — Feeds a large number of scan chains in your core design from a small
number of scan channels, and decompresses EDT scan patterns as they are shifted in.
The decompressor resides between the channel inputs (connected to the tester) and the
scan chain inputs of the core. Its main parts are a Linear Feedback Shift Machine
(LFSM) and a phase shifter.
• Compactor — Compacts the test responses from the scan chains in your core design
into a small number of scan output channels as they are shifted out.
The compactor resides between the core scan chain outputs and the channel outputs
connected to the tester. It primarily consists of spatial compactor(s) and gating logic.
• Bypass Module (Optional) — Bypasses the EDT logic by using multiplexers (and
lockup cells if necessary) to concatenate the internal scan chains into fewer, longer
chains. Enables you to access the internal scan chains directly through the channel pins.
Generated by default.
If you choose to implement bypass circuitry, the tool includes bypass multiplexers in the
EDT logic. See “Compression Bypass Logic” on page 233 for a discussion of bypass
mode. You can also insert the bypass logic in the netlist at scan insertion time to
facilitate design routing. For more information, see “Insertion of Bypass Chains in the
Netlist” on page 56.
The EDT logic block contains all of these three components that, by default, a top-level
“wrapper” module instantiates. The top-level wrapper also instantiates the design core.
Figure 1-3 illustrates this conceptually.
You insert pads and I/O cells on this new top level. Because the EDT logic is outside the core
design (that is, outside the netlist used in Tessent Shell), the tool flow you use to implement this
configuration is referred to as the external EDT logic location flow, or simply the “external
flow.”
Getting Started
Figure 1-3. EDT Logic Located Outside the Core (External Flow)
Alternatively, you can invoke Tessent Shell and use a design that already contains I/O pads. For
these designs, the tool enables you to insert the EDT logic block in the existing top level within
the original design. Figure 1-4 shows this conceptually. Because the EDT logic is instantiated
within the netlist used in Tessent Shell, this configuration is referred to as the internal EDT
logic location flow or simply the “internal flow.”
Figure 1-4. EDT Logic Located Within the Core (Internal Flow)
Getting Started
By default, the tool automatically inserts lockup cells as needed in the EDT logic. They are
placed within the EDT logic, between the EDT logic and the design core, and in the bypass
circuitry that concatenates the scan chains. “Understanding Lockup Cells” on page 257
describes in detail how the tool determines where to insert lockup cells.
DRC Rules
Tessent TestKompress performs the same ATPG design rules checking (DRC) after design
flattening that Tessent FastScan performs. A detailed discussion of DRC appears in “ATPG
Design Rules Checking” in the Tessent Scan and ATPG User’s Manual.
In addition, Tessent TestKompress also runs a set of DRCs specifically for EDT. For more
information, see “Design Rule Checks” on page 97.”
Internal Control
In many cases, it is preferable to use internal controllers (JTAG or test registers) to control EDT
signals, such as edt_bypass, edt_update, scan_en, and to turn off the edt_clock in functional
mode. For detailed information about how to do this with boundary scan, refer to
“Uncompressed ATPG (External Flow) and Boundary Scan” on page 243.
Logic Clocking
The default EDT logic contains combinational logic and flip-flops. All the flip-flops, except
lockup cells, are positive edge-triggered and clocked by a dedicated clock signal that is different
from the scan clock. There is no clock gating within the EDT logic, so it does not interfere with
the system clock(s) in any way.
You can set up the clock to be a dedicated pin (named edt_clock by default) or you can share the
clock with a functional non-clock pin. Such sharing may cause a decrease in test coverage
because the tool constrains the clock pin during test pattern generation. You must not share the
edt_clock with another clock or RAM control pin for several reasons:
• If shared with a scan clock, the scan cells may be disturbed when the load_unload
procedure pulses the edt_clk during pattern generation.
• If shared with RAM control signals, RAM sequential patterns and multiple load patterns
may not be applicable.
• If shared with a non-scan clock, test coverage may decline because the edt_clk is
constrained to its off-state during the capture cycle.
Because the clock used in the EDT logic is different than the scan clock, lockup cells can be
inserted automatically between the EDT logic and the scan chains as needed. The tool inserts
lockup cells as part of the EDT logic and never modifies the design core.
Getting Started
Note
You can set the EDT clock to pulse before the scan chain shift clocks and avoid having
lockup cells inserted. For more information, see “Pulse EDT Clock Before Scan Shift
Clocks” on page 83.
Latch-based EDT logic uses two clocks (a primary and a remote clock) to drive the logic. For
reasons similar to those listed above for DFF-based logic, you must not share the primary EDT
clock with the system primary clock. You can, however, share the remote EDT clock with the
system remote clock.
Note
During the capture cycle, the system remote clock, which is shared with the remote EDT
clock, is pulsed. This does not affect the EDT logic because the values in the primary
latches do not change. Similarly, in the load_unload cycle, although the remote EDT clock is
pulsed, the value at the outputs of the system remote latches is unchanged because the remote
latches capture old values.
In a skew load procedure, when a primary clock is only pulsed at the end of the shift cycle (so
different values can be loaded in the primary and remote latches), the EDT logic is unaffected
because the primary EDT clock is not shared.
ASCII and Binary Patterns

Compressed ATPG test patterns can be written out in ASCII and binary formats, and can also be
read back into the tool. As with uncompressed patterns, you use these formats primarily for
debugging simulation mismatches and archiving. However, there are some differences with
compressed and uncompressed patterns as follows:
• Compressed and uncompressed ASCII patterns are different in several ways. When you
create patterns with compression, the tool stores the captured data with respect to the
internal scan chains and stores the load data with respect to the external scan channels.
The load data in the pattern file is in compressed format—the same form in which the
tool feeds it to the decompressor.
• With the simulation of compressed patterns, Xs may not be due to capture; they may
result from the emulation of the compactor. For a detailed discussion of this effect and
how masking occurs with compressed patterns, refer to “Understanding Scan Chain
Masking in the Compactor” on page 285.
Fault Models and Test Patterns
For compression, the tool uses fault-model independent and pattern-type independent
compression algorithms. The compression technology supports all fault models (stuck-at,
transition, Iddq, and path delay) and deterministic pattern types (combinational, RAM
sequential, clock-sequential, and multiple loads) supported or generated by uncompressed
ATPG.
Getting Started
To summarize, the compression technology:
• Accepts the same fault models as uncompressed ATPG.

• Accepts the same deterministic pattern types as uncompressed ATPG with the exception
of MacroTest, which is not supported.
• Produces the same test coverage as uncompressed ATPG.
Effective Compression
“Effective compression” is the actual compression achieved for a specific test application. The
effective compression is determined by balancing the EDT compression characteristics with the
test environment/design needs.
Many parameters limit the effective compression, including the following:
• Number of scan chains in your design core

• Number of scan channels presented to the tester
Use the following ratio to determine the chain to channel ratio for an application:
The effective compression achieved for a design is always less than the chain to channel ratio
because the EDT technology generates more test patterns than traditional ATPG. With EDT
technology, compression occurs through reducing the amount of data per test pattern and not
through reducing the number of test patterns generated. Consequently, additional test patterns
require additional shift cycles that reduce the overall compression.
Note
The term “additional shift cycles” refers to the sum of the initialization cycles, masking bits
(when using Xpress), and low-power bits (when using a low-power decompressor).
It is also important to balance the compression target with the testing resources and design
needs. Using an unnecessarily large compression target may have an adverse affect on
compression, testing quality, and design layout as follows:
• Lower Test Coverage — Higher compression ratios increase the compression per test
pattern but also increase the possibility of generating test patterns that cannot be
compressed and can lead to lower test coverage.
• Decrease in Overall Compression — Higher compression ratios also decrease the
number of faults that dynamic compaction can fit into a test pattern. This can increase
the total number of test patterns and, therefore, decrease overall compression.
Getting Started
• Routing Congestion — There is no limit to the number of internal scan chains,

however, routing constraints may limit the compression ratio. Most practical
configurations do not exceed the compression capacity.
For more information on determining the right compression for your design, see “Compression
Analysis” on page 66.
Getting Started
TestKompress Usage Flow Overview
TestKompress Usage Flow Overview

This section describes the default Tessent TestKompress flow by briefly introducing the steps
required to incorporate EDT into a gate-level Verilog netlist.
EDT IP Creation and Pattern Generation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Pre-Synthesis Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
EDT Logic Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Using TCD-Based Flow With Flattened EDT Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . 36
EDT IP Creation and Pattern Generation Flow

The post-synthesis EDT IP creation and pattern generation flow enables you to generate the
EDT logic and subsequently create patterns for the logic.
Figure 1-5 illustrates this flow.
Getting Started
EDT IP Creation and Pattern Generation Flow
Figure 1-5. Post-Synthesis EDT IP Creation and EDT Pattern Generation Flow
Getting Started
Pre-Synthesis Flow
This flow consists of the following stages:
• EDT IP Creation — Use Tessent Shell in EDT IP generation and insertion context (dft
-edt) to create the EDT IP and write the EDT logic and the TCD file. Refer to “Creation
of EDT Logic Files” on page 98.
• EDT Pattern Generation — Use a design with inserted EDT IP and Tessent Shell in
test pattern generation context (patterns -scan) to generate patterns. See “EDT Pattern
Generation Overview” on page 138.
Pre-Synthesis Flow
When using the pre-synthesis flow, the tool extracts the EDT IP during the pattern generation
phase and configures the tool to use the extracted IP.
Getting Started
Pre-Synthesis Flow
Figure 1-6. Pre-Synthesis EDT IP Creation & EDT Pattern Generation TCD Flow
Getting Started
Tessent Core Description (TCD)
Tessent Core Description (TCD)

The Tessent Core Description (TCD) is a single file that contains the EDT IP core description
and eliminates the use of multiple dofiles and test procedure files for pattern generation. Use of
a TCD file supersedes the EDT mapping functionality for automating ATPG setup of the EDT
IP.
The write_edt_files command generates the TCD file, along with the other EDT logic files,
during EDT IP generation. The TCD file contains the description of the generated EDT IP.
With a TCD file, Tessent Shell can automatically extract the connectivity between the EDT IP
and the chip, apply any needed adjustment to test procedures, and enable pattern generation.
Refer to “Creation of EDT Logic Files” on page 98 for more information.
Note
The EDT IP TCD file describes the configuration of the EDT IP. You should never modify
the TCD file.
If your EDT IP can operate in multiple configurations (for example, low power, bypass, and so
on), then a single TCD file contains all the configurations in contrast to the multiple EDT IP
dofile usage. During pattern generation, you can specify how you want those parameters of the
EDT IP configured for that ATPG mode.
If you are using a Low Pin Count Test (LPCT) controller, the tool also creates a LPCT-specific
TCD file that you use for pattern generation—see “Low Pin Count Test Controller” on
page 198.
EDT IP Generation
The following steps demonstrate the basic EDT post-synthesis IP creation flow.
Procedure
1. Invoke Tessent Shell.
<Tessent_Tree_Path>/bin/tessent -shell -dofile edt_ip_creation.do \
-logfile ../transcripts/edt_ip_creation.log -replace
2. Provide Tessent Shell commands. For example:
Tip
The following commands can be located in the dofile used for invocation in Step 1.
Getting Started
EDT Logic Synthesis
// Set context, read library,

read and set current design
SETUP> set_context dft -edt
SETUP> read_verilog gatelevel_netlist.v
SETUP> read_cell_library atpg.lib
SETUP> set_current_design top
// Setup Scan Chains and Clocks
SETUP> add_scan_groups grp1 ../generated/atpg.testproc
SETUP> add_scan_chains chain1 grp1 edt_si1 edt_so1
...
SETUP> analyze_control_signals -auto_fix
// Specify the number of scan channels.
SETUP> set_edt_options -channels 1
// Flatten the design, run DRCs.
SETUP> set_system_mode analysis
// Verify the EDT configuration is as expected.
ANALYSIS> report_edt_configurations -verbose
// Generate the RTL EDT logic and save it.
ANALYSIS> write_edt_files created -verilog -replace
// The write_edt_files command also creates a
// Tessent Core Description file
// At this point, you can optionally create patterns
//(without saving them)
// to get an estimate of the potential test coverage.
ANALYSIS> create_patterns
// Create reports
ANALYSIS> report_statistics
ANALYSIS> report_scan_volume
// Close the session and exit.
ANALYSIS> exit
EDT Logic Synthesis

You must synthesize the design before you generate EDT patterns.
Procedure
Run Design Compiler.
Note
The Design Compiler synthesis script referenced in the following invocation line is
output from the “write_edt_files” command in Step 2 of “EDT IP Generation” on
page 33.
dc_shell -f ../created_dc_script.scr |& tee ../transcripts/

dc_edt.log
EDT Pattern Generation

The following steps demonstrate the basic EDT pattern generation flow.
Getting Started
EDT Pattern Generation
Procedure
1. Invoke Tessent Shell.
Note
The netlist created_edt_top_gate.v referenced in the following invocation line is
output from Design Compiler—see EDT Logic Synthesis.
<Tessent_Tree_Path>/bin/tessent -shell -logfile

../transcripts/edt_pattern_gen.log -replace

// Set context, read library, read and set current design
SETUP> set_context patterns -scan
SETUP> read_verilog created_edt_top_gate.v
// Read the TCD file for EDT IP using the read_core_description command.
// For example:
SETUP> read_core_description created_cpu_edt.tcd
// Define parameter values to automatically configure the EDT logic using the
// add_core_instances command. For example:
SETUP> add_core_instances -core cpu_edt -modules cpu_edt -parameter_values \
{edt_bypass off}
//Add top-level clocks driving the scan changes using the add_clocks command.
//Provide the top-level test procedure file using the set_procfile_name command.
// For example:
SETUP> set_procfile_name created_cpu_edt.testproc
// Change the system mode to Analysis using the set_system_mode
// command as follows:
// Verify the EDT configuration.
ANALYSIS> report_edt_configurations
// Generate patterns.
// Create reports.
ANALYSIS> report_statistics
ANALYSIS> report_scan_volume
Getting Started
Using TCD-Based Flow With Flattened EDT Hierarchy
// Save the patterns in ASCII format.

ANALYSIS> write_patterns ../generated/patterns_edt.ascii -ascii -replace
// Save the patterns in parallel and serial Verilog format.
ANALYSIS> write_patterns ../generated/patterns_edt_p.v -verilog -replace -parallel
ANALYSIS> write_patterns ../generated/patterns_edt_s.v -verilog -replace -serial \
-sample 2
// Save the patterns in tester format; WGL for example.
ANALYSIS> write_patterns ../generated/test_patterns.wgl -wgl -replace
// Optionally write out the core description corresponding to
// the current chip level using the write_core_description command.
// For example:
ANALYSIS> write_core_description cpu_core_final.tcd -replace
// Close the session and exit.
ANALYSIS> exit
Using TCD-Based Flow With Flattened EDT

Hierarchy
This procedure describes using the TCD-based flow with a flattened EDT hierarchy.
In certain flows and design styles, the synthesis or layout process flattens the top-level hierarchy
of the EDT IP. In this case, there may not be an instance that can be associated with the core
description in the TCD file of the EDT IP mapping flow. This is needed for ATPG and any
mode when the EDT IP needs to be used.
In this situation, you need to create module-level TCD files for various modes of operation prior
to flattening the hierarchy as follows:
Procedure
1. Setup the core with each mode, for example ATPG for a particular fault model.
2. Run DRC using this command:
set_system_mode analysis
3. Use the write_core_description command to save the TCD file to be used with the
design that does not have hierarchy for the EDT IP.
Results
With the completion of these steps, the information for the core instance is ready for you to use
in other procedures, such as ATPG for a particular mode.
Getting Started
Tessent Shell User Interface
You can use the add_core_instances command before or after flattening to define the core
instance for other uses:
add_core_instances ... -current_design
Note
If you store the flat model after core instances have been added, you do not need to provide
TCD files externally before reading the flat model back; the core instance data is stored in
the flat model.

Tessent Shell is a command line driven tool that provides access to Tessent FastScan for
uncompressed ATPG and to Tessent TestKompress for compressed ATPG.
Invocation
You can invoke Tessent Shell from the command line by entering the tessent command. For
example:
prompt> <Tessent_Tree_Path>/bin/tessent -shell -dofile edt_ip_creation.do \

-logfile ../transcripts/edt_ip_creation.log -replace
To exit Tessent Shell and return to the operating system, type “exit” at the command line:
prompt> exit
For more information on invoking Tessent Shell, see the tessent command in the Tessent Shell
Reference Manual.
Uncompressed and Compressed ATPG

For uncompressed ATPG, you use Tessent Shell in the “patterns -scan” context.
For compressed ATPG, you use Tessent Shell in the “dft -edt” context to create the EDT logic,
and in the “patterns -scan” context to generate compressed test patterns.
EDT must be on whenever you are creating test patterns or EDT logic. You can use the
report_environment command to check the tool status. You can use the set_edt_options
command to enable compression.
For more information about Tessent Shell and contexts, see “Tessent Shell Introduction” in the
Tessent Shell User’s Manual.
Supported Design Format

For pattern generation, you can read in a scan-inserted gate-level Verilog netlist and a
compatible Tessent cell library of the models used for the scan circuitry.
Getting Started
For more information on the Tessent cell library, see “Create Tessent Simulation Models Using
LibComp” in the Tessent Cell Library Manual.
Batch Mode
You can run Tessent Shell in batch mode by using a dofile to pipe commands into the
application. Dofiles let you automatically control the operations of the tool. The dofile is a text
file you create that contains a list of application commands that you want to run, but without
entering them individually. If you have a large number of commands, or a common set of
commands you use frequently, you can save time by placing these commands in a dofile.
If you place all commands, including the exit command, in a dofile, you can run the entire
session as a batch process from the command line. Once you generate a dofile, you can run it at
invocation.
For example, to run a dofile as a batch process using the commands contained in the dofile
my_dofile.do, enter:
<Tessent_Tree_Path>/bin/tessent -shell -dofile my_dofile.do
The following shows an example Tessent Shell dofile:
// my_dofile.do
//
// Dofile for EDT logic Creation Phase.
// Run setup script from Tessent Scan.

dofile edt_ip_creation.do
// Set up EDT.
set_edt_options -channels 2
// Run DRC.
// Report and write EDT logic.

report_edt_configurations
report_edt_pins
write_edt_files created -verilog -replace
// Exit.
exit
By default, if the tool encounters an error when running one of the commands in the dofile, it
stops dofile execution. However, you can turn this setting off or specify to exit to the shell
prompt by using the set_dofile_abort command.
Log Files
Log files provide a useful way to examine the operation of the tool, especially when you run the
tool in batch mode using a dofile. If errors occur, you can examine the log file to see exactly
Getting Started
what happened. The log file contains all DFT application operations and any notes, warnings, or
error messages that occur during the session.
You can generate log files by using the -Logfile switch when you invoke the tool. When setting
up a log file, you can instruct Tessent Shell to generate a new log file, replace an existing log
file, or append information to a log file that already exists.
You can also use the set_logfile_handling command to generate a log file during a tool session.
Note
A log file created during a tool session only contains notes, warnings, and error messages
that occur after you issue the set_logfile_handling command. Therefore, you should enter it
as one of the first commands in the session.
System Commands
You can run operating system commands within Tessent Shell by using the “system” command.
For example, the following command runs the operating system command date within a
Tessent Shell session:
prompt> system date
Getting Started
Chapter 2
The Compressed Pattern Flows
The compressed internal and external pattern flows compare the basic steps and tools used for
an uncompressed ATPG top-down design flow with the steps and tools used to incorporate
compressed patterns in both an external and an internal flow. These flows primarily show the
typical top-down design process flow using a structured compression strategy.
Figures 2-1 and 2-2 illustrate the steps in the APTG flow (shown in grey); it also mentions
certain aspects of other design steps, where applicable. For more information on the ATPG
flow, see the Tessent Scan and ATPG User’s Manual.
Figure 2-1. Top-Down Design Flow - External
Figure 2-2. Top-Down Design Flow - Internal
Top-Down Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

The Compressed Pattern Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Design Requirements for a Compressed Pattern Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Top-Down Design Flows
Compressed Pattern External Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Compressed Pattern Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

The first task in any design flow is to create the initial register transfer level (RTL) design, using
whatever means you choose. If your design is in Verilog format and contains memory models,
you can add built-in self-test (BIST) circuitry to your RTL design. You then choose to use either
an uncompressed or a compressed pattern flow.
Uncompressed ATPG Flow

Commonly, in an ATPG flow that does not use compression, you would next insert and verify I/
O pads and boundary scan circuitry. Then, you would synthesize and optimize the design using
the Synopsys Design Compiler tool or another synthesis tool, followed by a timing verification
with a static timing analyzer such as PrimeTime.
After synthesis, you are ready to insert internal scan circuitry into your design using Tessent
Scan. In the uncompressed ATPG flow, after you insert scan, you could optionally re-verify the
timing because you added scan circuitry. Once you were sure the design is functioning as
needed, you would generate test patterns using Tessent FastScan and generate a test pattern set
in the appropriate format.
Compressed Pattern Flows

Compared to an uncompressed ATPG flow, a compressed pattern flow can take one of two
paths:
• External Flow (External Logic Location Flow) — Differs from the uncompressed
ATPG flow in that you do not insert I/O pads and boundary scan until after you run
Tessent Shell with the scan-inserted core to insert the EDT logic. The EDT logic is
located external to the design netlist.
• Internal Flow (Internal Logic Location Flow) — Similar to an uncompressed ATPG
flow, you may insert and verify I/O pads and boundary scan circuitry before you
synthesize and optimize the design. The EDT logic is instantiated in the top level of the
design netlist, permitting the logic to be connected to internal nodes (I/O pad cells or an
internal test controller block, for example) or to the top level of the design. Typically,
the EDT logic is connected to the internal nodes of the pad cells used for channel and
control signals. You run Tessent Shell with the scan-inserted core that includes I/O pads
and boundary scan.
Choosing a Compressed Pattern Flow
You should choose between the external and internal flows based on whether the EDT logic
signals need to be connected to nodes internal to the design netlist read into the tool (internal
nodes of I/O pads, for example), or whether the EDT logic can be connected to the design using
a wrapper.
In the external flow, after you insert scan circuitry the next step is to insert the EDT logic.
Following that, you insert and verify boundary scan circuitry if needed. Only then do you add I/
O pads. Then, you incrementally synthesize and optimize the design using either Design
Compiler or another synthesis tool.
In the internal flow, you can integrate I/O pads and boundary scan into the design before the
scan insertion step. Then, after you create and insert the EDT logic, use Design Compiler with
the script created by Tessent Shell to synthesize the EDT logic.
In either flow, once you are sure the design is functioning as needed, you generate compressed
test patterns. In this step, the tool performs extensive DRC that, among other things, verifies the
synthesized EDT logic.
You should also verify that the design and patterns still function correctly with the proper
timing information applied. You can use Questa SIM or another simulator to achieve this goal.
You may then have to perform a few additional steps required by your ASIC vendor before
handing off the design for manufacture and testing.
Note
It is important to check with your vendor early in your design process for requirements and
restrictions that may affect your compression strategy. Specifically, you should determine
the limitations of the vendor's test equipment. To plan effectively for using EDT, you must
know the number of channels available on the tester and its memory limits.

The compressed pattern flow requires the design file format is Verilog, that the design permits
access to all clock pins through primary inputs, and special I/O pad considerations based upon
internal and external patterns.
Note
Tessent Shell supports mux-DFF and LSSD scan architectures, or a mixture of the two,
within the same design. The tool creates DFF-based EDT logic by default. You can direct
the tool to create latch-based IP for pure LSSD designs. However, Tessent ScanPro does not
support the insertion of LSSD scan chains. Table 1-1 on page 18 summarizes the supported scan
architecture combinations.
Design Requirements for a Compressed Pattern Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Compressed Pattern External Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Compressed Pattern Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Design Requirements for a Compressed Pattern

Flow
Before you begin a compressed pattern flow, you must ensure that your design satisfies a set of
prerequisites.
The prerequisites are
• Format — Your design input must be in gate-level Verilog. The logic created by
Tessent TestKompress is in Verilog or VHDL RTL.
• Pin Access — The design needs to permit access to all clock pins through primary input
pins. There is no restriction on the number of clocks.
• I/O Pads— I/O pad requirements for the external and internal flows are quite different.
o External Flow — The tool creates the EDT logic as a collar around the circuit (see
Figure 1-3). Therefore, the core design ready for logic insertion must consist of only
the core without I/O pads. In this flow, the tool cannot insert the logic between scan
chains and I/O pads already in the design.
Note
Add the I/O pads around the collar after its creation but before logic synthesis.
The same applies to boundary scan cells: add them after you include the EDT
logic in the design.
Compressed Pattern External Flow
The design may or may not have I/O pads when you generate test patterns. To
determine the expected test coverage, you can perform a test pattern generation trial
run on the core when the EDT logic is created before inserting I/O pads.
Note
You should not save the test patterns generated during creation of the EDT logic;
these patterns do not account for how I/O pads are integrated into the final
synthesized design.
When producing the final patterns for a whole chip, run Tessent Shell on the
synthesized design after inserting the I/O pads. For more information, refer to the
procedure for managing pre-existing I/O pads in “Preparation for the External Flow”
on page 53.
o Internal Flow — The core design, ready for EDT logic insertion, may include I/O
pad cells for all the I/Os you inserted before or during initial synthesis. The I/O pads,
when included, can be present at any level of the design hierarchy and do not
necessarily have to be at the top level. If the netlist includes I/O pads, there should
also be some pad cells reserved for EDT control and channel pins that are not going
to be shared with functional pins. See “Functional/EDT Pin Sharing” on page 87 for
more information about pin sharing.
Note
The design may have I/O pads; it is not a requirement. When you insert EDT
logic in the netlist, you can connect it to any internal design nodes or to the top
level of the design netlist.

The compressed pattern external flow focuses on EDT logic creation and EDT pattern
generation.
Figure 2-3 expands the steps shown in grey in Figure 2-1, and shows the files used in the tool’s
external flow. The basic steps in the flow are summarized in the following list.
1. Prepare and synthesize the RTL design.

2. Insert an appropriately large number of scan chains using Tessent Scan or a third-party
tool. For information on how to do this using Tessent Scan, refer to “Internal Scan and
Test Circuitry,” in the Tessent Scan and ATPG User’s Manual.
3. Optionally, perform an ATPG run on the scan-inserted design without EDT. Use this run
to ensure there are no basic issues such as simulation mismatches caused by an incorrect
library. If you want, you can run Tessent Shell in “patterns -scan” context to perform
this step.
4. Optionally, simulate the patterns created in step 3.
5. EDT Logic Creation Phase: Invoke Tessent Shell with the scan-inserted gate-level
description of the core without I/O pads or boundary scan. Create the RTL description of
the EDT logic.
6. Insert I/O pads and boundary scan (optional).
7. Incrementally synthesize the I/O pads, boundary scan, and EDT logic.
8. EDT Pattern Generation Phase: After you insert I/O pads and boundary scan, and
synthesize all the added circuitry (including the EDT logic), invoke Tessent Shell with
the synthesized top-level Verilog netlist and generate the EDT test patterns. You can
write test patterns in a variety of formats including Verilog and WGL.
9. Simulate the compressed test patterns that you created in the preceding step 8. As for
regular ATPG, the typical practice is to simulate all parallel patterns and a sample of
serial patterns.
Figure 2-3. Compressed Pattern External Flow
Compressed Pattern Internal Flow

The compressed pattern internal flow focuses on EDT logic creation and EDT pattern
generation.
Figure 2-4 details the steps shown in gray in Figure 2-2, and shows the files used in the tool’s
internal flow. The basic steps in the flow are summarized in the following list.
1. Prepare and synthesize the RTL design, including boundary scan and I/O pads cells for
all I/Os. Provide I/O pad cells for any EDT control and channel pins that are not shared
with functional pins.
Note
In this step, you must know how many EDT control and channel pins are needed, so
you can provide the necessary I/O pads.
2. Insert an appropriately large number of scan chains using Tessent Scan or a third-party
tool. Be sure to add new primary input and output pins for the scan chains to the top
level of the design. These new pins are only temporary; the signals to which they
connect become internal nodes and the pins are removed when you insert the EDT logic
into the design and connect it to the scan chains. For information on how to insert scan
chains using Tessent Scan, refer to “Internal Scan and Test Circuitry,” in the Tessent
Scan and ATPG User’s Manual.
Note
As the new scan I/Os at the top level are only temporary, take care not to insert I/O
pads on them.
3. Perform an ATPG run on the scan-inserted design without EDT (optional). Use this run
to ensure there are no basic issues such as simulation mismatches caused by an incorrect
library.
4. Simulate the patterns created in step 3. (optional).
5. EDT logic Creation Phase: Invoke Tessent Shell with the scan-inserted gate-level
description of the core. Create the RTL description of the EDT logic. The tool creates
the EDT logic, inserts it into the design, and generates a Design Compiler script to
synthesize the EDT logic inside the design.
6. Run the Design Compiler script to incrementally synthesize the EDT logic.
7. EDT Pattern Generation Phase: After you insert the EDT logic, invoke Tessent Shell
with the synthesized top-level Verilog netlist and generate the EDT test patterns. You
can write test patterns in a variety of formats including Verilog and WGL.
8. Simulate the compressed test patterns that you created in the preceding step. As for
regular ATPG, the typical practice is to simulate all parallel patterns and a sample of
serial patterns.
Figure 2-4. Compressed Pattern Internal Flow
Chapter 3
Scan Chain Synthesis
For ATEs with scan options, the number of channels is usually fixed and the only variable
parameter is the number of scan chains. In some cases, the chip package rather than the tester
may limit the number of channels. Therefore, scan insertion and synthesis is an important part
of the compressed ATPG flow.
You can use Tessent Scan or another scan insertion product to insert scan chain circuitry in your
design before generating EDT logic. You can also generate the EDT logic before scan chain
insertion. For more information, see “Integrating Compression at the RTL Stage” on page 293.
Design Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Scan Chain Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
OCC Sub-Chain Stitching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
ATPG Baseline Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Design Preparation
Before you insert test structures into your design there are EDT-specific issues you need to
consider.
It is recommended that before in insert test structures into your design, you understand the
information in “Internal Scan and Test Circuitry Insertion” in the Tessent Scan and ATPG
User’s Manual.
Preparation for the External Flow

• Managing Pre-existing I/O Pads
Because the synthesized hardware is added as a collar around the core design, the core
should not have I/O pads when you create the EDT logic. If the design has I/O pads, you
need to extract the core or remove the I/O pads.
Note
If you must insert I/O pads prior to or during initial synthesis, consider using the
internal flow, which does not require you to perform the steps a through e.
If the core and the I/O pads are in separate blocks, removing the I/O pads is simple to do
as described here:
a. Invoke Tessent Shell and read in the design.
Design Preparation
b. Set the current design to the core module using the set_current_design command.
c. Write out the core using the write_design command.
d. Insert scan into the core and synthesize the EDT logic around it.
e. Reinsert the EDT logic/core combination into the original circuit in place of the core
you extracted, such that it is connected to the I/O pads.
If your design flow dictates that the I/O pads be inserted prior to scan insertion, you can
create a blackbox as a place holder that corresponds to the EDT block. You can then
stitch the I/O pads and, subsequently, the scan chains to this block. Once the RTL model
of the block is created, you use the RTL model as the new architecture or definition of
the blackbox placeholder. The port names of the EDT block must match those of the
blackbox already in the design, so only the architectures need to be swapped.
• Managing Pre-existing Boundary Scan
If your design requires boundary scan, you must add the boundary scan circuitry outside
the top-level wrapper created by Tessent Shell. The EDT logic is typically controlled by
primary input pins and not by the boundary scan circuitry. In test mode, the boundary
scan circuitry just needs to be reset.
Note
If you must insert boundary scan prior to or during initial synthesis, consider using
the internal flow, which is intended for pre-existing boundary scan or I/O pads.
If the design already includes boundary scan, you need to extract the core or remove the
boundary scan. This is the same requirement, described in Managing Pre-existing I/O
Pads. Use the procedure for managing pre-existing I/O pads in “Preparation for the
External Flow” on page 53.
Note
Boundary scan adds a level of hierarchy outside the EDT wrapper and requires you
to make certain modifications to the generated dofile and test procedure file that you
use for the test pattern generation.
For more complete information about including boundary scan, refer to “Boundary
Scan” on page 124.
• Synthesizing a Gate-level Version of the Design — As a prerequisite to starting the
compressed ATPG flow, you need a synthesized gate-level netlist of the core design
without scan. The described in the Compressed Pattern Flows section in Uncompressed
ATPG Flow, the design must not have boundary scan or I/O pads. You can synthesize
the netlist using any synthesis tool and any technology.
Scan Chain Insertion
Preparation For the Internal Flow

The EDT logic is connected between the I/O pads and the core so the core should have I/O pad
cells in place for all the design I/Os. You must also add I/O pads for any EDT control and
channel pins that you do not want to share with the design’s functional pins.
There are three mandatory EDT control pins: edt_clock, edt_update, and edt_bypass unless you
turn off bypass circuitry during setup. There are 2<n> channel I/Os where <n> is the number of
external channels for the netlist. See “EDT Control and Channel Pins” on page 85 for detailed
information about EDT control and channel pins.

You should insert an appropriately large number of scan chains. For testers with the scan option,
the number of channels is usually fixed, and the variable is the number of chains.
Note
Scan configuration is an important part of the compressed ATPG flow. Refer to
“Determining How Many Scan Chains to Use” on page 56 for more information.
The scan chains can be connected to dedicated top-level scan pins. In designs that implement
hierarchical scan insertion, the scan chains can be defined at internal pins on the block
instances. In such a case, there is no need to bring these block scan chains to dedicated scan pins
at the top level. For more information, see “Scan Chain Pins” on page 57.
The following limitations exist for the insertion of scan chains:
• Only scan using the mux-DFF or LSSD scan cell type (or a mixture of the two) is
supported. The tool creates DFF-based EDT logic by default; however, you can direct it
to create latch-based logic for pure LSSD designs. Table 1-1 on page 18 summarizes the
EDT logic/scan architecture combinations the tool supports. For information about
specific scan cell types, refer to “Scan Architectures” in the Tessent Scan and ATPG
User’s Manual.
• Both prefixed and bused scan input and output pins are permitted; however, the buses
for bused pins must be in either ascending or descending order (not in random order).
• Unlike uncompressed ATPG, placeholder scan chains are not supported in compressed
ATPG. This is because EDT logic is dependent on the scan configuration, particularly
the number of scan chains. Uncompressed ATPG performance is independent of the
scan configuration and you can assume that all scan cells are configured into a single
scan chain when placeholder scan chains are used.
Insertion of Bypass Chains in the Netlist

Tessent Shell can generate EDT logic for netlists that contain two sets of pre-defined scan
chains. This enables you to insert both the bypass chains for bypass mode and the core scan
chains for compression mode into the netlist with a scan-insertion tool before the EDT logic is
generated.
You can use any scan insertion tool, but you must adhere to the following rules when defining
the scan chains:
• Scan chains and bypass chains must use the same I/O pins.
• If the control pin used to select bypass or compression mode is shared with the
edt_bypass pin, the bypass chains must be active when the edt_bypass pin is at 1, and the
scan chains must be active when the edt_bypass pin is at 0.
• Test procedure file for the EDT logic must set up the mux select, so the shortened
internal scan chains can be traced.
Inserting bypass chains with a scan insertion tool ensures that lockup cells and multiplexers
used for bypass mode operation are fully integrated into the design netlist to enable more
effective design routing.
For more information, see “Compression Bypass Logic” on page 233.
Inclusion of Uncompressed Scan Chains

Uncompressed scan chains (scan chains not driven by or observed through EDT logic) are
permitted in a design that also uses EDT logic. You can insert and synthesize them like any
other scan chains, but you do not define them when creating the EDT logic.
You must define the uncompressed scan chain during test pattern generation using the
add_scan_chains command without the -Internal switch.
You can set up uncompressed scan chains to share top-level pins by defining existing top-level
pins as equivalent or physically defining multiple scan chains with the same top-level pin. For
more information, see the add_scan_chains command in the Tessent Shell Reference Manual.
Determining How Many Scan Chains to Use

Although you generally determine the number of scan chains based on the number of scan
channels and the compression required, routing congestion can create a practical limitation on
the number of scan chains a design can have. With a very large number of scan chains (usually
more than a thousand), you can run into problems similar to those for RAMs, where routing can
be a problem if several hundred scan chains start at the decompressor and end at the compactor.
Other reasons to decrease the number of scan chains might be to limit the number of
incompressible patterns, reduce the pattern count, or both. For more information, see “Effective
Compression” on page 27.
For testers with a scan option, the number of channels is usually fixed and the variable you
modify is the number of chains. Because the effective compression is slightly less than the ratio
between the two numbers (the chain-to-channel ratio), in most cases it is sufficient to do an
approximate configuration by using slightly more chains than indicated by the chain-to-channel
ratio. How many more depends on the specific design and on your experience with the tool. For
example, if the number of scan channels is 16 and you need five times (5X) effective
compression, you can configure the design with 100 chains (20 more than indicated by the
chain-to-channel ratio). This typically results in 4.5X to 6X compression.
Scan Groups
EDT supports the use of exactly one scan group. A scan group is a grouping of scan chains
based on operation. For more information, see “Scan Groups” in the Tessent Scan and ATPG
User’s Manual.
Scan Chain Pins

When you perform scan insertion, you must not share any scan chain pins with functional pins.
You can connect the inserted scan chains to dedicated pins you create for them at the top level.
If you use the external flow, these dedicated pins become internal nodes when the tool creates
the additional wrapper. If you use the internal flow, the dedicated pins are removed when the
EDT logic is instantiated in the design and connected. Therefore, using dedicated pins does not
increase the number of pins needed for the chip package.
You can also leave the scan chains anchored to internal scan pins instead of connecting them to
the top level.
Note
You can share functional pins with the external decompressor scan channel pins.
Remember, these channels become the new “virtual” scan chains seen by the tester. You
specify the number of channels, as well as any pin sharing, in a later step when you set up
Tessent Shell for inserting the EDT logic. See “EDT Control and Channel Pins” on page 85 for
more information.
Note
If a scan cell drives a functional output, avoid using that output as the scan pin. If that scan
cell is the last cell in the chain, you must add a dedicated scan output.
About Reordered Scan Chains

The EDT logic (including bypass circuitry) depends on the clocking of the design. When
necessary to prevent clock skew problems, the tool automatically includes lockup cells in the
EDT logic. If, after you create the EDT logic, you reorder the scan chains incorrectly, the
automatically inserted lockup cells can no longer behave correctly. The following are potential
problem areas:
• Between the decompressor and the scan chains (between the EDT clock and the scan
clock(s))
• Between the scan chain output and the compactor when there are pipeline stages
(between the scan clock(s) and the EDT clock)
• In the bypass circuitry where the internal scan chains are concatenated (between
different scan clocks)
You can avoid regenerating the EDT logic by ensuring the following are true after you reorder
the scan chains:
• The first and last scan cell of each chain have the same clock and phase.
To satisfy this condition, you should reorder within each chain and within each clock
domain. If both leading edge (LE) triggered and trailing edge (TE) triggered cells exist
in the same chain, do not move these two domains relative to each other. After
reordering, the first and last cell in a chain do not have to be precisely the same cells that
occupied those positions before reordering, but you do need to have the same clock
domains (clock pin and clock phase) at the beginning and end of the scan chain, that you
had during IP creation.
• If you use a lockup cell at the end of each scan chain and if all scan cells are LE
triggered, you do not have to preserve the clock domains at the beginning and end of
each scan chain.
When all scan cells in the design are LE triggered, the lockup cell at the end of each
chain enables you to reorder however you want. You can move clock domains and you
can reorder across chains. But if there are both LE and TE triggered flip-flops, you must
maintain the clock and edge at the beginning and end of each chain. Therefore, the
effectiveness and need of the lockup cell at the end of each chain depends on the
reordering flow, and whether you are using both edges of the clock.
For flows where re-creating the EDT logic is unnecessary, you still must regenerate patterns
(just as for a regular ATPG flow). You should also perform serial simulation of the chain test
and a few patterns to ensure there are no problems. If you include bypass circuitry in the EDT
logic (the default), you should also create and serially simulate the bypass mode chain test and a
few patterns.
Scan Insertion Dofile Example

The scan chains must have dedicated pins. The following is an example dofile for inserting scan
chains with Tessent Scan.
// tscan.do
//
// Tessent Scan dofile to insert scan chains for EDT.
// Set context, read library, read and set current design, and so on.
...
// Set up control signals.

add_clocks 0 clk1 clk2 clk3 clk4 ramclk
// Define test logic for lockup cells.

add_cell_models inv02 -type inv
add_cell_models latch -type dlat CLK D -active high
set_scan_insertion_options –enable_retiming on
// Set up Test Control Pins.

set_scan_signals -sen scan_en
set_scan_signals -ten test_en
// Set up scan chain naming.

Add_scan_mode –si_port_format edt_si%s%d –so_port_format \
edt_so%s%d -port_index_start_value 1 –port_scalar_index_modifier 1
// Flatten design, run DRCs, and identify scan cells.

report_statistics
run
// Insert scan chains and test logic.

Add_scan_mode unwrapped –type unwrapped –chain_count 16 \
–single_clock_domain off –single_clock_edge off
// Report information.
report_scan_chains
report_test_logic
// Write output files.

write_design my_gate_scan.v -verilog -replace
write_atpg_setup my_atpg -replace
exit
You should obtain the following outputs from Tessent Scan:
• Scan-inserted gate-level netlist of the design

• Test procedure file that describes how to operate the scan chains
• Dofile that contains the circuit setup and test structure information
OCC Sub-Chain Stitching

OCCs have a short sub-chain that you need to incorporate into the overall scan chain
configuration to enable ATPG to program the OCC.
For EDT compression, any time you must specify a particular value to any of the sequential
elements, encoding capacity is reduced. For example, when you use a clock control definition to
force bits to a particular value or when you constrain a scan cell to a certain value. Adding such
controls or constraints requires encoding impacts the number of patterns or pattern generation.
Clustering issues occur when the required encoding exceeds the encoding capacity of the
decompressor.
The impact of specified bits increases dramatically if they are aligned in the same shift cycle.
A design may have a large number of clocks, each having an OCC containing four bits. Because
all four OCC bits need to be specified to generate the required capture sequence, you must be
careful when stitching them into the scan chains in order to avoid clustering issues. The basic
recommendation is to add the OCC scan chain segments as part of the compressed scan chains.
Figure 3-1 shows, highlighted in red, groups of four bits representing OCC bits in different scan
segments.
This is a poor alignment for the added OCC scan chain segments, because they are aligned so
that most of these bits are in the same shift position in the scan chain. Such a positioning of
these scan segments creates a potential clustering issue, because these bits must be encoded to
specific values on the decompressor input.
Figure 3-1. Bad Specified Bit Alignment
Figure 3-2 shows that the segments are spread throughout the configuration, avoiding the
alignment of bits that may lead to clustering. This is a better alignment of the bits, however the
scan insertion tool cannot guarantee such a configuration.
Figure 3-2. Better Specified Bit Alignment
There are two OCC sub-chain stitching recommendations:
• If there are few OCC bits (roughly 25% or less of the longest chain). Stitch OCC bits
into a single compressed chain. Place them in one chain, as shown highlighted in red in
Figure 3-3, to avoid the alignment of bits in the same shift cycle. This is automated in
Tessent Scan. The impact to encoding capacity should be small.
Figure 3-3. Best Specified Bit Alignment (Few Cells)
• If the OCC bits add up to more that one chain or could fill approximately 75% of a
chain. Use an uncompressed chain for OCC bits as shown in Figure 3-4. Before doing
this, however, first run ATPG to determine if you have a clustering issue, because using
compressed chains is preferred over uncompressed chains. Note that for every core that
needs an uncompressed chain you need two additional pins at the chip level.
Add any remaining bits into a compressed chain, similar to the case where there are few
OCC bits.
Figure 3-4. Best Specified Bit Alignment (Many Cells)
ATPG Baseline Generation
OCC sub-chains may be part of wrapper chains to enable access in internal and external modes,
or they can be part of internal chains if only used in internal mode. Tessent Scan understands
this and decides whether or not they should be part of wrapper chains.
For wrapper chains, Tessent Scan uses the global scan-enable for OCC cells and use a gate’s
scan-enable for non-OCC cells.

You can generate an ATPG baseline after scan chain insertion.
An ATPG baseline can be used to
• Estimate the final test coverage early in the flow, before you insert the EDT logic.
• Obtain the scan data volume for the test patterns pre-compression. You can then
compare the scan data volume for test patterns before and after compression to evaluate
the effects of compression.
Note
Directly comparing pattern counts is not meaningful because EDT patterns are much
smaller than ATPG patterns. This is because the relatively short scan chains used in
EDT require many fewer shift cycles per scan pattern.
• Provide additional help for debugging. You can simulate the patterns you generate in
this step to verify that the non-EDT patterns simulate without problems.
• Find other problems, such as library errors or timing issues in the core, before you create
the EDT logic.
Note
If you include bypass circuitry, you also can run regular ATPG after you insert the
EDT logic.
This run is like any ATPG run and does not have any special settings; the key is using the same
settings (pattern types, constraints, and so on) used to create the compressed test patterns.
The test procedure file used for this ATPG run can be identical to the one generated by scan
insertion. However, it should be modified to include the same timing, specified by the tester,
that is used to generate the compressed test patterns. By using the same timing information, you
ensure simulation comparisons are realistic. To avoid DRC violations when you save test
patterns, update the test procedure file with information for RAM clocks and for non-scan-
related procedures.
Use the report_scan_volume command to report test data before and after compression and
compare the data to evaluate the effect of compression.
Save the patterns if you want to simulate them. You can use any Verilog timing simulator.
Note
This ATPG run is intended to provide test coverage and pattern volume information for
traditional ATPG. Save the patterns if you want to simulate them, but be aware that they
have no other purpose. The final compressed test patterns are generated and saved after the EDT
logic is inserted and synthesized.
Chapter 4
Creation of the EDT Logic
You can create and insert EDT logic into a scan-inserted design.
For more information on specific commands, see the Tessent Shell Reference Manual.
Compression Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Analyzing Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Preparation for EDT Logic Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Parameter Specification for the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Asymmetric Input and Output Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Bypass Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Compactor Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Pipeline Stages in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
EDT Logic Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Pulse EDT Clock Before Scan Shift Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Reporting of the EDT Logic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
EDT Control and Channel Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
EDT Control and Channel Pin Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Functional/EDT Pin Sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Connections for EDT Pins (Internal Flow Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Structure of the Bypass Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Decompressor and Compactor Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
IJTAG and the EDT IP TCD Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Design Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Creation of EDT Logic Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
The EDT Logic Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
EDT Logic Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Compression Analysis
Inserting EDT Logic During Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Creation of a Reduced Netlist for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
You need to determine a scan chain to scan channel ratio (chain:channel ratio) for your
application before you create the EDT logic. The chain:channel ratio determines the
compression for an application.
Usually the number of scan channels are dictated by hardware resources such as test channels
on the ATE and the top-level design pins available for test. However, you can usually vary the
number of scan chains to optimize the compression for an application.
You can determine the optimal chain:channel ratio for an application by varying the number of
scan channels or scan chains and then generating test patterns and evaluating the following
elements:
• Test Coverage — Determine if the test effectiveness is adequate for the application.
• Data Volume — Determine how much test pattern data is generated after compression
and whether it is within the test hardware limitations.
• ATPG Baseline (optional) — Compare the test data statistics for the ATPG baseline
with the compressed test pattern statistics. See “ATPG Baseline Generation” on
page 63.
You can use the analyze_compression command to explore the effects of different
chain:channel ratios on test data without making modifications to your design. For more
information, see “Effective Compression” on page 27 and “Analyzing Compression” on
page 66.
Related Topics
Analyzing Compression
Use compression analysis to explore chain:channel ratios, test coverage, and test data volume
for an EDT application. You can perform this procedure before or after the EDT logic is created
and on block-level or chip-level architecture designs.
Note
This procedure is used for analysis only and does not permanently alter design
configurations or produce any test patterns.
Prerequisites
• Scan-inserted gate-level netlist. Can be any scan chain configuration. The tool
disregards the configuration if other settings are specified for the analysis. For more
information, see the analyze_compression command.
• It is recommended to use the reset_state command to discard existing test patterns and
restore the fault population before analyzing the design.
Procedure
1. Invoke Tessent Shell on your design. The tool invokes in setup mode. For more
information, see “Supported Design Format” on page 37.
<Tessent_Tree_Path>/bin/tessent -shell

set_context patterns -scan
read_verilog my_gate_scan.v
read_cell_library my_lib.aptg
set_current_design top
3. Define scan chains and add clocks using the add_scan_chains and add_clocks
commands.
4. Analyze the design to determine the maximum chain:channel configurations that can be
used for your design. Use this step to analyze both chip-level and block-level designs.
For example:
set_fault_type stuck
set_fault_sampling 5
analyze_compression
The tool analyzes the design and returns a range of chain:channel ratio values beginning
with the ratio where a negligible drop in fault coverage occurs and ending with the ratio
where a 1% drop in fault coverage occurs as follows:
// For stuck-at_faults
//
// Chain:Channel Ratio Predicted Fault Coverage Drop
// ------------------- ------------------------------
// 153 negligible fault coverage drop
// 154 0.01 % - 0.05 % drop
// 160 0.10 %
// 168 0.15 %
// 171 0.20 %
…
// CPU time is 155 seconds.
The tool analyzes the design for the fault type specified by the set_fault_type command
before it runs analyze_compression command. The analyze_compression command uses
the current fault population. If no faults are added, the tool operates on all faults or a
subset of sampled faults that are determined by the fault sampling rate specified by the
“set_fault_sampling <rate>” command.
For example, if you want to analyze transition faults with a 10% fault sampling rate, you
would use the following commands:
set_fault_type transition
analyze_compression
For more information, see the analyze_compression command.

5. Select a chain:channel ratio from the list and calculate how many scan chains and scan
channels to use for your first trial run. For more information, see “Compression
Analysis” on page 66.
6. Depending on the chip architecture, specify the chain:channel ratios, emulate the EDT
logic, and generate test patterns as follows:
• Emulating a virtual single block EDT configuration
set_fault_type stuck
analyze_compression -chains 270 -channels 9
• Emulating a virtual modular EDT configuration

If you are analyzing compression for a block-level design, you may need to
manually determine how to allocate chains and channels across blocks to achieve the
selected chain:channel ratio before you perform this step. For example:
analyze_compression -Edt_block BLK1 \
-CHAINs 400 - CHANNELs 8 -Edt_block BLK2 -CHAINs 200 \
-CHANNELs 4 -ENAble_edt_power_controller \
-MIN_Switching_threshold_percentage 20
The tool emulates the EDT logic with the specified sampling rate, fault type, and
chain:channel ratio, generates temporary test patterns, and displays a statistics report
similar to the following:
Statistics Report
Stuck-at Faults
----------------------------------------------
Fault Classes #faults
(total)
---------------------------- ----------------
FU (full) 2173901
-------------------------- ----------------
UC (uncontrolled) 729 ( 0.03%)
UO (unobserved) 17523 ( 0.81%)
DS (det_simulation) 1696097 (78.02%)
DI (det_implication) 342047 (15.73%)
PU (posdet_untestable) 1099 ( 0.05%)
PT (posdet_testable) 633 ( 0.03%)
UU (unused) 12547 ( 0.58%)
TI (tied) 25920 ( 1.19%)
BL (blocked) 18120 ( 0.83%)
RE (redundant) 29870 ( 1.37%)
AU (atpg_untestable) 29316 ( 1.35%)
----------------------------------------------
Untested Faults
--------------------------
AU (atpg_untestable)
PC (pin_constraints) 186 ( 0.01%)
Unclassified 29130 ( 1.34%)
UC+UO
AAB (atpg_abort) 6619 ( 0.30%)
UNS (unsuccess) 11633 ( 0.54%)
----------------------------------------------
Coverage
--------------------------
test_coverage 97.68%
fault_coverage 93.79%
atpg_effectiveness 99.15%
----------------------------------------------
#test_patterns 2285
#basic_patterns 2108
#clock_po_patterns 3
#clock_sequential_patterns 174
#simulated_patterns 4544
CPU_time (secs) 4755.1
----------------------------------------------
Note: The reported statistics are based on a 80% fault sample.
// CPU time to analyze_compression is 4751 seconds.

//
// -----------------------------------------------------------
// Scan volume report.
// -------------------
// channels : 12
// shift cycles : 145
// -----------------------------------------------------------
Preparation for EDT Logic Creation
// pattern # test # scan volume

// type patterns loads (cell loads or unloads)
// ---------------- -------- ------ -----------------------
// setup_pattern 2 2 3480
// chain_test 71 71 123540
// basic 2108 2108 3667920
// clock_po 3 3 5220
// clock_sequential 174 174 302760
// ---------------- -------- ------ -----------------------
// total 2358 2358 4102920 (4.1M)
//
Power Metrics Min. Average Max.
-------------------------- ------ ------- ------
WSA 0.08% 27.39% 46.28%
State Element Transitions 0.00% 30.48% 50.67%
-------------------------- ------ ------- ------
Peak Cycle
--------------------------
WSA 0.08% 28.26% 46.28%
State Element Transitions 0.00% 31.55% 50.67%
-------------------------- ------ ------- ------
Load Shift Transitions 7.32% 15.97% 19.91%
Response Shift Transitions 9.85% 33.69% 50.51%
7. Review the statistics report to determine whether the chain:channel ratio is adequate as
follows:
• If the chain:channel ratio yields adequate results, insert the scan chains and create
the EDT logic. See “Scan Chain Synthesis” on page 53 and “Preparation for EDT
Logic Creation” on page 70.
• If the data volume or test coverage is unacceptable, repeat steps 3, 4, and 5 until you
determine the optimal chain:channel ratio to use for your application.
Related Topics
If Compression Is Less Than Expected
If Test Coverage Is Less Than Expected

Depending on your application, there are certain tasks you must perform to prepare for creating/
inserting EDT logic into your design. The tasks include setting up EDT context and defining
clocks and scan chains.
You can create the EDT logic immediately after you insert scan chains, or you can run
traditional ATPG and simulate the resulting patterns first, as described in the “ATPG Baseline
Generation” on page 63. EDT must be on whenever you are creating test patterns or EDT logic.
Note
You can use the report_environment command to check the tool status. You can use the
set_edt_options command to enable compression.
Scan Chain Definition

You must define the clocks and scan chain information. You can include these commands in a
dofile or invoke the dofile that Tessent Scan generates to define clocks and scan chains. For
example:
dofile my_atpg.dofile
The following shows an example setup dofile generated by Tessent Scan:
add_scan_groups grp1 my_atpg_setup.testproc

add_scan_chains chain1 grp1 edt_si1 edt_so1
...
add_write_controls 0 ramclk
add_read_controls 0 ramclk
add_clocks 0 clk
These commands are explained in “Scan Data Definition” in the Tessent Scan and ATPG User’s
Manual.
Internal Scan Chains in Tessent Shell IP Creation

You can add internal scan chains in the EDT IP creation phase (dft -edt context). Internal scan
chains are scan chains where the scan input and output signals are not brought to the top level of
the design and connected to top-level pins. This supports the hierarchical scan insertion flow
and removes the requirement to bring core-level scan pins to the top level.
You use the add_scan_chains -internal command to define internal scan chains during IP
creation as shown in the following example. Note, the K4, K9, and K10 IP creation DRCs do
not apply to internal scan pins and are skipped. The tool still runs these DRCs for top-level scan
pins.
Note
TestKompress not invoked from Tessent Shell still requires top-level scan pins during IP
creation.
This example shows IP creation in a design with three EDT blocks: cpu and alu have internal
scan chains, whereas TOP has top-level scan chains. Note, the scan pins for the cpu and alu
blocks are defined at the respective instance pins and not brought to the top level. The scan pins
for the TOP block are defined at the top level.
set_context dft -edt

add_clock 0 clk
add_scan_group grp1 scan_setup.testproc
set_edt_options -location internal
//
// EDT block: cpu
add_edt_block cpu
add_scan_chains -internal cpu_chain1 grp1 /cpu/scan_in1 /cpu/scan_out1
…
add_scan_chains -internal cpu_chain100 grp1 /cpu/scan_in100 \
/cpu/scan_out100
set_edt_options -channel 5
//
// EDT block: alu
add_edt_block alu
add_scan_chains -internal alu_chain1 grp1 /alu/scan_in1 /alu/scan_out1
…
add_scan_chains -internal alu_chain60 grp1 /alu/scan_in60 /alu/scan_out60
//
// EDT block: TOP
add_edt_block TOP
add_scan_chains TOP_chain1 grp1 scan_in1 scan_out1
…
add_scan_chains TOP_chain20 grp1 scan_in20 scan_out20
//
//System mode transition - perform DRC
Tessent Shell (dft -edt) supports internal scan chains during IP creation. However, non-Tessent
Shell TestKompress does not. If you were to define internal scan chains during IP Creation
using the following dofile commands in non-Tessent Shell TestKompress:

add_scan_chains -internal chain1 grp1 /u1/scan_in1 /u1/scan_out1
add_scan_chains -internal chain2 grp1 /u1/scan_in2 /u1/scan_out2
…
set_system_mode atpg
The tool would infer the Pattern Generation phase and would possibly fail with pattern
generation DRCs like those shown here:
// ---------------------------------------------------------------------/
/ Begin EDT setup and rules checking.
// ---------------------------------------------------------------------/
/ Running EDT Pattern Generation Phase.
// Error: Defined pin "edt_clock" for EDT clock signal is not in design.
// Violation safe to ignore, correct operation verified by subsequent
// DRCs. (K5-1)
// Error: Defined pin "edt_update" for EDT update signal is not in design.
// Violation safe to ignore, correct operation verified by subsequent
// DRCs. (K5-2)
// Error: Defined pin "edt_channels_in1" for channel input 1 signal is not
// in design. (K5-3)
// Error: Defined pin "edt_channels_out1" for channel output 1 signal is
// not in design. (K5-4)
// Error: Defined pin "edt_channels_in2" for channel input 2 signal is not
// in design. (K5-5)
// Error: Defined pin "edt_channels_out2" for channel output 2 signal is
// not in design. (K5-6)
// Error: 6 defined EDT pin(s) not in design. (K5)
// EDT setup and rules checking aborted, CPU time=0.00 sec.
// Error: Rules checking unsuccessful, cannot exit SETUP mode.
Parameter Specification for the EDT Logic
Parameter Specification for the EDT Logic

You use the set_edt_options command to set parameters for the EDT logic. The two most
important parameters are the position of the EDT logic, internal or external to the design core,
and the number of scan channels.
For a basic run to create external EDT logic (the default), you only need to specify the number
of channels. For example, the following command sets up external EDT logic with two input
channels and two output channels:
There are other parameters for the “set_edt_options” command to specify whether to create
DFF-based or latch-based EDT logic and whether to include bypass circuitry in any of the EDT
logic, lockup cells in the decompressor, and pipeline stages in the compactor.
By default, Tessent Shell generates
• EDT logic external to the design core

• DFF-based EDT logic
• Lockup cells in the decompressor, compactor, and bypass logic
• An Xpress compactor without pipeline stages
• Bypass logic
For more information, see the set_edt_options command in the Tessent Shell Reference Manual.

Asymmetric Input and Output Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Bypass Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Compactor Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Pipeline Stages in the Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
EDT Logic Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Pulse EDT Clock Before Scan Shift Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Dual Compression Configurations

Using two compression configurations when setting up the EDT logic enables you to easily set
up and reuse the EDT logic for two different test phases. For example, wafer test versus package
test.
When two distinct configurations are defined, an additional EDT pin is generated to select the
active configuration: edt_configuration. For more information on EDT pins, see “EDT Control
and Channel Pins” on page 85.
Separate ATPG dofiles and procedure files are created for each configuration. A single dofile
and test procedure file is generated for the bypass mode. These ATPG files are then used to
generate test patterns for each configuration separately as you would with a single compression
configuration.
In the modular flow, you should coordinate compression configuration usage between design
groups to ensure the compression configurations are defined and set up properly for each block
as follows:
• A maximum of two compression configurations can be defined for the entire design,
across all EDT blocks, although the configuration parameters can be different for
different EDT blocks belonging to that design.
• Channel parameters for each of the two configurations can vary from block to block.
In the following example, blocks b1 and b2 have the same config_high configuration
name but have different parameters: in b1, config_high has two input channels and four
output channels parameters and, in b2, config_high has one input and one output
channel:
set_current_edt_block b1
set_current_edt_configuration config_high
set_edt_options –input 2 –output 4
set_current_edt_configuration config_low
set_current_edt_block b2
• The configuration with the highest compression ratio must always have the highest
compression ratio for each of the EDT blocks.
• To create a single compression configuration for a block, only define parameters for one
of the compression configurations.
• The control and data input channels can be separated using the “set_edt_options
-separate_control_data_channels on” command. For more information see the “Separate
Control and Data Channels and Dual Compression Configuration” section.
Limitations
• A configuration with a higher number of input channels than the other configuration
must also have an equal or higher number of output channels than the other
configuration. For example:
The following configurations are valid because in each case the configuration with a
higher input channel count also has an equal or higher number of output channels than
the other configuration:
Config1 = 4 input channels and 2 output channels
Config2 = 2 input channels and 1 output channel

The following configurations are not valid because in each case the configuration with a
higher input channel count has a lower output channel count than the other
configuration:
Config1 = 4 input channels and 1 output channel

Config2 = 4 input channels and 1 output channel.
• The channels for the high compression configuration cannot be explicitly specified. By
default, the high-compression configuration uses the first channels defined for the low-
compression configuration. This applies to both input and output channels.
• Bypass mode is supported for the lowest-compression configuration only. You can
define the number of bypass chains in either of the configurations as long as the
specified number does not exceed the number of input/output channels of the lowest-
compression configuration. For example,
Configuration 1 = 2 input channels and 2 output channels
Configuration 2 = 4 input channels and 4 output channels
The maximum number of bypass chains = 4
For more information on bypass mode, see “Compression Bypass Logic” on page 233.
• You cannot generate test patterns during EDT logic creation to determine the test
coverage. The analyze_compression command does not support dual compression
configurations.
• The Basic compactor does not support more than one configuration. By default the tool
generates logic that contains the Xpress compactor. For more information on
compactors, see “Understanding Compactor Options” on page 282.
• There are no DRCs specific to dual compression configurations, so you must run DRC
on each configuration in the test pattern generation phase. For more information, see
“Test Pattern Generation” on page 155.
Defining Dual Compression Configurations

You can create EDT logic with two compression configurations for a single design block.
Prerequisites
• Scan chains must be defined. For more information, see “Scan Chain Definition” on
page 71.
Procedure
1. Invoke Tessent Shell. For example:
Tessent Shell invokes in setup mode.

3. Define the first compression configuration. For example:

add_edt_configurations config1
set_edt_options -input_channels 6 -output_channels 5
4. Define the second configuration. For example:

add_edt_configurations config2
To create a single compression configuration for a block, only define parameters for one
of the compression configurations.
5. Define the remaining parameters for the EDT logic. See “Parameter Specification for
the EDT Logic” on page 74.
6. Run DRC and fix any violations. See “Design Rule Checks” on page 97. You must run
DRC on each configuration.
7. Generate the EDT logic. For more information, see “Creation of EDT Logic Files” on
page 98. A separate dofile and procedure file is created for each configuration. The
configuration name is appended to the prefix specified with the write_edt_files
command:
<filename_prefix>_<configuration_name>_edt.dofile
<filename_prefix>_<configuration_name>_edt.testproc
Examples
The following example uses a dofile to create dual compression configurations for a single
block.

// edt_ip_creation.do
//
// Dofile for EDT logic Creation Phase
// Run setup script from Tessent Scan
dofile scan_chain_setup.dofile
// Set up EDT configurations

add_edt_configurations my_pkg_test_config
add_edt_configurations my_wafer_test_config
// Set bypass pin

set_edt_pins bypass my_bypass_pin
//set_edt_options configuration pin

set_edt_pins configuration my_configuration_pin
// Report and write EDT logic.

report_edt_configurations -all //reports configurations for all blocks.
report_edt_pins //reports all pins including compression configuration
// specific pins.
write_edt_files created -verilog -replace //Create dofiles and
//
testproc files for both the
//
configs and bypass mode
The following example shows a dofile that sets up modular EDT blocks with dual compression
configurations at the top-level.
// Set up dual compression configurations

add_edt_configuration manufacturing_test
add_edt_blocks B1
set_edt_options -pipe 2 -channels 4
add_edt_blocks B2
add_edt_blocks B3
add edt configuration system_test

set_current_edt_block B1
// Set up top-level clocks and channel pins for each block
add_clocks 0 clk
add_clocks 0 reset
dofile scan/atpg1.dofile_top
set_edt_pins in 1 coreA_channel_in1
set_edt_pins out 1 coreA_channel_out1
dofile scan/atpg2.dofile2
set_edt_pins in 1 coreB_channel_in1
set_edt_pins out 1 coreB_channel_out1
dofile scan/atpg3.dofile3
set_edt_pins in 1 coreC_channel_in1
set_edt_pins out 1 coreC_channel_out1
set_edt_pins in 2 coreC_channel_in2
set_edt_pins out 2 coreC_channel_out
//Run DRC
//Report EDT configuration and generate EDT logic

report_edt_configurations –all -verbose
write_edt_files ./edt_ip/created1_core_top -verilog -synth dc_shell \

-replace -rtl_prefix chip_level
exit -force
Asymmetric Input and Output Channels
Asymmetric Input and Output Channels

You can specify a different number of input versus output channels for the EDT logic with the -
Input_channels and -Output_channels switches of the set_edt_options command.
Bypass Scan Chains

You can use the set_edt_options -bypass_chains integer to specify how many bypass chains the
EDT logic is configured to support. By default, the number of bypass chains created equals the
number of input/output channels. If the number of input and output channels differ, the smaller
number is used.
You can only specify a number of bypass chains equal to or less than the number of bypass
chains created by default. For dual configuration applications, you can only specify the bypass
chains after both configurations are defined.
For more information on bypass mode, see “Compression Bypass Logic” on page 233.
Latch-Based EDT Logic

Tessent Shell supports mux-DFF and LSSD scan architectures, or a mixture of the two, within
the same design.
The tool creates DFF-based EDT logic by default. If you have a pure LSSD design and prefer
the logic to be latch-based, you can use the -Clocking switch to get the tool to create latch-based
EDT logic.
Note
Tessent does not support the insertion of LSSD based scan chains.
Compactor Type
Use the -COMpactor_type switch to specify which compactor is used in the generated EDT
logic.
By default, the Xpress compactor is used. For more information, see “Understanding
Compactor Options” on page 282.
Pipeline Stages in the Compactor

The EDT logic can be set up to include pipeline stages between logic levels within the
compactor.
Pipeline Stages Added to the Channel
The “set_edt_options -PIpeline_logic_levels_in_compactor” command enables you to specify a

maximum number of logic levels (XOR gates) in a compactor before pipeline stages are
inserted. By default, no pipeline stages are inserted. For more information on inserting pipeline
stages, see “Use of Pipeline Stages in the Compactor” on page 248.
Pipeline Stages Added to the Channel

When generating the EDT IP, if you plan to add output channel pipeline stages later, you must
specify “set_edt_pins -change_edge_at_compactor_output trailing_edge” to ensure that the
compactor output changes consistently on the trailing edge of the EDT clock. Output channel
pipeline stages should then start with leading-edge sequential elements.
Longest Scan Chain Range

Sometimes, you may need to change the length of the scan chains in your design after
generating the EDT logic. Ordinarily, you must regenerate the EDT logic when such a change
alters the length of the longest scan chain.
During setup, before you generate the EDT logic, you can optionally specify a length range for
the longest scan chain using the -Longest_chain_range switch. As long as any subsequent scan
chain modifications do not result in the longest scan chain exceeding the boundaries of this
range, you do not have to regenerate the EDT logic because of a shortening or lengthening of
the longest chain.
Note
This applies only to scan chain length. Other scan chain changes, such as reordering the scan
chains may require EDT logic regeneration. For more information, see “About Reordered
Scan Chains” on page 58.
EDT Logic Reset

While in most case it is not needed, if you have a design requirement that all the sequential
elements in a design are resettable, you can provide an asynchronous reset signal (edt_reset) for
the EDT logic.
Use “-reset_signal asynchronous” with the set_edt_options command if you want the EDT logic
to include this signal. If you choose to include the reset, the hardware also includes a dedicated
control pin for it (named “edt_reset” by default).
EDT Architecture Version

To ensure backward compatibility between older EDT logic architectures (created with older
versions of the tool) and pattern generation in the current version of the tool, use the -Ip_version
Specifying Hard Macros
switch, which enables you to specify the version of the EDT architecture the tool should expect
in the design.
In the EDT logic creation phase, the tool writes a dofile containing EDT-specific commands
used for ATPG. Any set_edt_options commands included in this dofile also use this switch to
specify the EDT architecture version; therefore, you usually do not need to explicitly specify
this switch.
Note
The logic version is incremented only when the hardware architecture changes. If the
software is updated, but the logic generated is still functionally the same, only the software
version changes.
You can generate test patterns for the older EDT logic architectures, but by default, the EDT
logic version is assumed to be the currently supported version.
Specifying Hard Macros

You can specify the hard macros in a design so the tool recognizes and avoids modifying them
while tracing clock paths for EDT logic bypass mode.
When one of the specified hard macros are encountered, the tool uses tap points identified from
the boundary of the macro cells to drive the bypass lockup cell clocks.
In cases where localized clock gaters are used, a tap point identified for one scan cell may not be
appropriate for another scan cell even when they use the same top-level clocks. So, in cases
where localized clock gaters are involved, the tool routes the clock pin of each scan cell
involved with bypass lockup cells to the EDT logic to avoid clock skew.
For more information on EDT logic bypass mode, see “Compression Bypass Logic” on
page 233.
Note
This functionality does not effect the type or quantity of lockup cells inserted for bypass
mode.
Note
Compression must be used to insert the EDT logic in the design core before synthesis.
Prerequisites
• Tessent Shell is invoked with a design netlist containing hard macros.
Pulse EDT Clock Before Scan Shift Clocks
Procedure
1. Set up the EDT logic to be inserted internal to the design core. For example:
add_clocks 0 pll/clk1
add_clocks 0 pll/clk2
set_edt_options –location internal
add_scan_chains chain1 grp1 scan_in1 scan_out1
2. Set up any additional EDT logic requirements for your test application.
3. Identify each hard macro inside the design. For example:
set_attribute_value SCBcg1 SCBcg2 -name is_hard_module -value true
4. Run DRC and fix any errors. For example:

5. Create the EDT logic RTL and insert it in the design core netlist. For example:
write_edt_files created -replace
Related Topics
Pulse EDT Clock Before Scan Shift Clocks

You can set up the EDT clock to pulse before the scan chain shift clocks with the -
pulse_edt_before_shift_clocks switch of the set_edt_options command.
By default, the EDT and scan chain shift clocks are pulsed simultaneously. Setting the EDT
logic to pulse before the scan shift clocks makes it independent of the scan chain clocking and
provides the following benefits:
• Makes creating EDT logic for a design in the RTL stage easier because scan chain
clocking information is not required. For more information on creating EDT logic at the
RTL stage, see “Integrating Compression at the RTL Stage” on page 293.
• Removes the need for lockup cells between scan chains and the EDT logic because
correct timing is ensured by the clock sequence. Only a single lockup cell between pairs
of bypass scan chains is necessary. For more information, see “Understanding Lockup
Cells” on page 257.
• Simplifies clock routing because the lockup cells used for bypass scan chains are driven
by the EDT clock instead of a system clock. This eliminates the need to route system
clocks to the EDT logic.
To use this functionality, the shift speed must be able to support two independent clock pulses
in one shift cycle, which may increase test time.
Reporting of the EDT Logic Configuration
Reporting of the EDT Logic Configuration

You can report the current EDT logic configuration with the report_edt_configurations
command. This command lists configuration details including the number of scan channels and
logic version.
For example:
// IP version:2
// External scan channels:2
// Longest chain range:600 - 700
// Bypass logic:On
// Lockup cells:On
// Clocking:edge-sensitive
Note
Because the report_edt_configurations command needs a flat model and DRC results to
produce the most useful information, you usually use this command in analysis or insertion
mode. For an example of the command’s output when issued after DRC, see “DRC When EDT
Pins are Shared With Functional Pins” on page 98.
EDT Control and Channel Pins
EDT Control and Channel Pins

EDT logic includes both control and channel pins. The control pins, such as the edt_clock,
edt_update, and edt_bypass, control the functionality of the EDT. The channel pins, such as
edt_channels_in and edt_channels_out are the scan channels.
EDT Control and Channel Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Functional/EDT Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Connections for EDT Pins (Internal Flow Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Structure of the Bypass Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Decompressor and Compactor Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
IJTAG and the EDT IP TCD Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
EDT Control and Channel Pin Configuration

The configuration of the EDT control and channel pins varies on its use.
EDT logic includes the following pins:
• Scan channel input pins

• Scan channel output pins
• EDT clock
• EDT update
• Scan-enable (optional—included when any scan channel output pins are shared with
functional pins)
• Bypass mode control
• Reset control (optional—included when you specify an asynchronous reset for the EDT
logic)
• EDT_configuration (optional—included when you specify multiple configurations)
Figure 4-1 shows the basic configuration of these pins for an example design when the EDT
logic is instantiated externally and configured with bypass circuitry and two scan channels.
External EDT logic is always instantiated in a top-level EDT wrapper.
EDT Control and Channel Pin Configuration
Figure 4-1. Default EDT Logic Pin Configuration With Two Channels
The default configuration consists of pins for the EDT clock, update, and bypass inputs. There
are also two additional pins (one input and one output) for each scan channel. If you do not
rename an EDT pin or share it with a functional pin, as described in “Functional/EDT Pin
Sharing” on page 87, the tool assigns the default EDT pin names shown.
To see the names of the EDT pins, issue the report_edt_pins command:
report_edt_pins
// Pin description Pin name Inversion
// --------------- -------- ---------
// Clock edt_clock -
// Update edt_update -
// Bypass mode edt_bypass -
// Scan channel 1 input edt_channels_in1 -
// " " " output edt_channels_out1 -
Figure 4-2 shows how the preceding pin configuration looks if the EDT logic is inserted into a
design netlist that includes I/O pads (internal EDT logic location). Notice that the EDT control
and channel I/O pins are now connected to internal nodes of I/O pads that are part of the core
design. You set up these connections by specifying an internal node for each EDT control and
Functional/EDT Pin Sharing
channel I/O pin. For more information, see “Connections for EDT Pins (Internal Flow Only)”
on page 92.
Figure 4-2. Example of a Basic EDT Pin Configuration (Internal EDT Logic)

EDT pins can be shared with functional pins, with a few restrictions. You use the set_edt_pins
command to specify sharing of an EDT pin with a functional pin and to specify whether a signal
is inverted in the I/O pad for the pin. For more information, see the set_edt_pins command.
When you share a channel output pin with a functional pin, the tool inserts a multiplexer before
the output pin. This multiplexer is controlled by the scan_enable signal, and you must define the
scan_enable signal with the set_edt_pins command. If you do not define the scan_enable signal,
the tool defaults to “scan_en”, and adds this pin if it does not exist. During DRC, all added pins
are reported with K13 DRC messages. You can report the exact names of added pins using the
report_drc_rules command.
For channel input pins and control pins, you use the -Inv switch to specify (on a per pin basis) if
a signal inversion occurs between the chip input pin and the input to the EDT logic. For
example, if an I/O pad you intend to use for a channel pin inverts the signal, you must specify
the inversion when creating the EDT logic. The tool requires the pin inversion information, so
the generated test procedure file operates correctly with the full netlist for test pattern
generation.
If bypass circuitry is implemented, you need to force the bypass control signal to enable or turn
off bypass mode. When you generate compressed EDT patterns, you turn off bypass mode by
setting the control signal to the off state. When you generate regular ATPG patterns for
example, you must enable the bypass mode by setting the bypass control signal to the on state.
The logic level associated with the on or off state depends on whether you specify to invert the
signal. The bypass control pin is forced in the automatically generated test procedure.
In all cases, EDT pins shared with bidirectional pins must have the output enable signal
configured so that the pin has the correct direction during scan. The following list describes the
circumstances under which the EDT pins can be shared.
• Scan channel input pin — No restrictions.

• Scan channel output pin — Cannot be shared with a pin that is bidirectional or tri-state
at the core level. This is because the tool includes a multiplexer between the compactor
and the output pad when a channel output pin is shared, and tri-state values cannot pass
through the multiplexer. A scan channel output pin that later will be connected to a pad
and is bidirectional at the top level is permitted.
Note
Scan channel output pins that are bidirectional need to be forced to Z at the
beginning of the load_unload procedure. Otherwise, the tool is likely to issue a K20
or K22 rule violation during DRC, without indicating the reason.
• EDT clock — Must be defined as a clock and constrained to its defined off state. If
shared with a bit of a bus, problems can occur during synthesis. For example, Design
Compiler (DC) does not accept a bit of a bus being a clock. The EDT clock pin must
only be shared with a non-clock pin that does not disturb scan cells; otherwise, the scan
cells are disturbed during the load_unload procedure when the EDT clock is pulsed.
This restriction might cause some reduced coverage. You should use a dedicated pin for
the EDT clock or share the EDT clock pin only with a functional pin that controls a
small amount of logic. If any loss of coverage is not acceptable, then you must use a
dedicated pin.
• EDT reset— Should be defined as a clock and constrained to its defined off state. If
shared with a bit of a bus, problems can occur during synthesis. For example, DC does
not accept a bit of a bus being a clock. The EDT reset pin must only be shared with a
non-clock pin that does not disturb scan cells. This restriction might cause some reduced
coverage. You should use a dedicated pin for the EDT reset, or share the EDT reset pin
only with a functional pin that controls a small amount of logic. If any loss of coverage
is not acceptable, then you must use a dedicated pin.
• EDT update — Can be shared with any non-clock pin. Because the EDT update pin is
not constrained, sharing it has no impact on test coverage.
Shared Pin Configuration
• Scan enable — As for regular ATPG, this pin must be dedicated in test mode;
otherwise, there are no additional limitations. EDT only uses it when you share channel
output pins. Because it is not constrained, sharing it has no impact on test coverage.
• Bypass (optional) — Must be forced during scan (forced on in the bypass test
procedures and forced off in the EDT test procedures). It is not constrained, so sharing it
has no impact on test coverage. For more information on bypass mode, see
“Compression Bypass Logic” on page 233.
• Edt_configuration (optional) — The value corresponding with the selected
configuration must be forced on during scan chain shifting.
Note
RTL generation permits sharing of control pins. The restrictions for EDT pin sharing
ensure the EDT logic operates correctly and with only negligible loss, if any, of test
coverage.

The synthesis methodology does not change when you specify pin sharing. You do, however,
need to add a step to the EDT logic creation phase. In this extra step, you define how pins are
shared.
For example, you are using the external flow with two scan channels and you want to share
three of the channel pins, as well as the EDT update and EDT clock pins, with functional pins.
Assume the functional pins have the names shown in Table 4-1.
Table 4-1. Example Pin Sharing
EDT Pin Description Functional Pin Name
Input 1 (Channel 1 input) portain[7]
Output 1 (Channel 1 output) edt_channels_out1 (new pin, default name)
Input 2 (Channel 2 input) portain[6]
Output 2 (Channel 2 output) q2
Update portain[5]
Clock a1
Bypass my_bypass (new pin, non-default name)
You can see the names of the EDT pins, prior to setting up the shared pins, by issuing the
report_edt_pins command:
report_edt_pins

// --------------- -------- ---------
// Bypass mode edt_bypass -
You can use the set_edt_pins command to specify the functional pin to share with each EDT
pin. With this command, you can specify to tap an EDT pin from an existing core pin. You can
also use the command to change the name of the new pin the tool creates for each dedicated
EDT pin. Figure 4-3 on page 92 illustrates both of these cases conceptually.
Note
In the external flow, the specified pin sharing is implemented in the wrapper generated
when the EDT logic is created. The “Top-level Wrapper” section contains additional
information about this wrapper. In the internal flow, the pin sharing is implemented when you
create and insert the EDT logic into the design before synthesis.
If a specified pin already exists in the core, the tool shares the EDT signal with that pin.
Figure 4-3 shows an example of this for the EDT clock signal. The command “set_edt_options
clock a1” causes the tool to share the EDT clock with the a1 pin instead of creating a dedicated
pin for the EDT clock. If you specify a pin name that does not exist in the core, a dedicated EDT
pin with the specified name is created. For example, “set_edt_pins bypass my_bypass” causes
the tool to create the new pin my_bypass and connect it to the EDT bypass pin.
For each EDT pin you do not share or rename using the set_edt_pins command, if its default
name is unique, the tool creates a dedicated pin with the default name. If the default name is the
same as a core pin name, the tool automatically shares the EDT pin with that core pin. Table 4-2
lists the default EDT pin names.
Table 4-2. Default EDT Pin Names
EDT Pin Description Default Name
Clock edt_clock
If “edt_clock” DFT signal is defined then its value is used as the
default name.
Reset edt_reset
Update edt_update
If “edt_update” DFT signal is defined then its value is used as the
default name.
Scan Enable scan_en
If “scan_en” DFT signal is defined then its value is used as the
default name.
Table 4-2. Default EDT Pin Names (cont.)

EDT Pin Description Default Name
Bypass mode edt_bypass
Scan Channel Input “edt_channels_in” followed by the index number of the channel
Scan Channel Output “edt_channels_out” followed by the index number of the channel
EDT configuration select edt_configuration
When you share a pin between an EDT channel output and a core output, the tool includes a
multiplexer in the circuit together with the EDT logic, but in a separate module at the top level.
An example is shown in red in Figure 4-3 for the shared EDT channel output 2 signal, and the
core output signal q2. As previously mentioned, the multiplexer is controlled by the defined
scan enable pin. If a scan enable pin is not defined, the tool adds one with the EDT default
name, “scan_en.” Here are the commands that would establish the example pin sharing shown
in Table 4-1:
set_edt_pins input 1 portain[7]

set_edt_pins input 2 portain[6]
set_edt_pins output 2 q2
set_edt_pins update portain[5]
set_edt_pins clock a1
set_edt_pins bypass my_bypass
If you report the EDT pins using the “report_edt_pins” command after issuing the preceding
commands, the report shows that the shared EDT pins have the same name as the functional
core pins. It also shows, for each pin, whether the pin’s signal was specified as inverted. The
following example also illustrates how the listing now includes the scan enable pin because of
the shared EDT output pin:
report_edt_pins
// --------------- -------- ---------
// Clock a1 -
// Update portain[5] -
// Scan enable scan_enable -
// Bypass mode my_bypass -
// Scan channel 1 input portain[7] -
// Scan channel 2 input portain[6] -
// " " " output q2 -
Connections for EDT Pins (Internal Flow Only)
Figure 4-3. Example With Pin Sharing Shown in (External EDT Logic)
After DRC, you can use the “report_drc_rules k13” command to report the pins added to the top
level of the design to implement the EDT logic.
report_drc_rules k13
// Pin my_bypass will be added to the EDT wrapper. (K13-2)
// Pin edt_channels_out1 will be added to the EDT wrapper.
// (K13-3)
Connections for EDT Pins (Internal Flow Only)

For the internal flow, you must specify the name of each internal node (instance pin name) to
connect each EDT control and channel pin.
Note
Before specifying internal nodes, you must specify internal logic placement with the
“set_edt_options -location” internal command.
Internally Driven EDT Pins
For every EDT pin, you should provide the name of a design pin and the corresponding instance
pin name for the internal node that corresponds to it. The latter is the input (or output) of an I/O
pad cell where you want the tool to connect the output (or input) of the EDT logic. For example:
set_edt_pins clock pi_edt_clock edt_clock_pad/po_edt_clock
The first argument “clock” is the description of the EDT pin; in this case the EDT clock pin.
The second argument “pi_edt_clock” is the name of the top-level design pin on the I/O pad
instance. The last argument is the instance pin name of the internal node of the pad. The pad
instance is “edt_clock_pad” and the internal pin on that instance is “po_edt_clock.”
If you specify only one of the pin names, the tool treats it as the I/O pad pin name. If you specify
an I/O pad pin name, but not a corresponding internal node name, the EDT logic is connected
directly to the top-level pin, ignoring the pad. This may result in undesirable behavior.
If you do not specify either pin name, and the tool does not find a pin at the top level by the
default name, it adds a new port for the EDT pin at the top level of the design. You must add a
pad later that corresponds to that port.
For the internal flow, the report_edt_pins command lists the names of the internal nodes to
which the EDT pins are connected. For example (note that the pin inversion column is omitted
for clarity):
report_edt_pins
//
// Pin description Pin name Internal connection
// --------------- -------- -------------------
// Clock edt_clock edt_clock_pad/Z
// Update edt_update edt_update_pad/Z
// Bypass mode edt_bypass edt_bypass_pad/Z
// Scan ch... 1 input edt_ch..._in1 channels_in1_pad/Z
// " " " output edt_ch..._out1 channels_out1_pad/Z
// Scan ch... 2 input edt_ch..._in2 channels_in2_pad/Z
// " " " output edt_ch..._out2 channels_out2_pad/Z
//
Related Topics
set_edt_pins [Tessent Shell Reference Manual]

When an EDT control or channel pin is driven internally (by JTAG or other control registers for
control pins, or by some test access mechanism for channel pins), you should use the
set_edt_pins command to specify that no corresponding top-level pin exists for the EDT control
or channel pin. The following figure shows an example of an internally driven control pin.
Figure 4-4. Internally Driven edt_update Control Pin
Specifying these types of pins prevents false K5 DRC violations. You should specify internally
driven pins in one of the following ways:
• EDT logic creation

a. Specify the internal node that drives the control pin during logic creation. For
example:
set_edt_pins update - JTAG/update_ctrl
write_edt_files my_design -verilog -replace
Where <JTAG/update_ctrl> is the internal node driving the “update” control pin.
b. Edit the test procedure file to include any procedures or pin constraints needed to
drive the specified internal node (<JTAG/update_ctrl>) to the correct value.
• Pattern generation
Structure of the Bypass Chains
a. Specify the internally driven control pin has no top-level pin during test pattern
generation. For example:
set_edt_pins update -
add_faults /my_design
create_patterns
Note
All input and output channels must have a corresponding top-level pin.
b. You cannot specify internally driven channel pins during test pattern generation. Use
the TCD mapping flow in this case.

When bypass logic is generated, the connections for each bypass chain are automatically
configured. These interconnections are fine for most designs.
However, you can specify custom chain connections with the set_bypass_chains command. For
more information, see “Compression Bypass Logic” on page 233.
Decompressor and Compactor Connections

After you specify the number of scan channels in the EDT logic, the tool automatically
determines which scan chain outputs to compact into each channel output.
For more information on specifying the number of scan channels, see “Parameter Specification
for the EDT Logic” on page 74.
You can modify the tool’s default connections using one of the following methods:
Note
Redefining compactor connections for a channel that has already been defined overwrites
the previous settings for that channel.
• Reorder the add_scan_chains Commands — When generating the EDT IP, the tool
uses the sequence of add_scan_chains commands to connect the EDT hardware to the
scan chains. You can change the order of the add_scan_chains commands in your dofile
to change how they are connected to the decompressor and compactor. Note, this
method changes both the decompressor and compactor connections for a particular
chain.
• Specify New Connections Using the set_compactor_connections Command — You
can use the set_compactor_connections command to override the tool’s default
connections and explicitly define the connections between scan chains and compactor.
IJTAG and the EDT IP TCD Flow
This method enables you to change the compactor connections without changing the
default decompressor connections to those chains.
If you have dual configurations, you can still define the compactor connections using the
set_compactor_connections command but only for the configuration that uses all scan
channels as shown in the following example. (set_compactor_connections is not tied to
a specific configuration because you only need to define connections once for each
channel.)
set_compactor_connections –channel 1 –chains ...

IJTAG and the EDT IP TCD Flow

To fully benefit from the use of the EDT IP TCD flow, you can use IJTAG. With the use of
IJTAG, you only need to provide the EDT IP parameters (low power, bypass, and so on); the
setup of the configuration is fully automated.
Using IJTAG to configure the EDT IP’s static control signals enables the tool to automatically
generate the required test_setup sequence through more complex connections such as a TAP
and TDRs. Also, when you use IJTAG as part of test_setup for a core, that configuration is
automatically carried up the hierarchy as the core is used in a higher level of the design. It is
recommended that you extract an ICL description for the design such that IJTAG can be used to
configure the EDT IP.
Without IJTAG, you must provide the complete test_setup at most levels of the hierarchy.
When IJTAG is not used, you must provide a complete test_setup to configure the EDT static
control signals unless those signals are connected directly to the boundary of the design. In this
case, the tool automatically maps them. Additionally, IJTAG usage must be explicitly turned off
using the “set_procedure_retargeting_options -ijtag off” command, otherwise the tool expects
to find an ICL description for the design.
Note
The use of IJTAG does not require changing the access mechanism to the EDT IP. Direct
connections and any 1149.1 network are IJTAG-compatible.
For the EDT IP TCD flow, IJTAG is the default. Refer to “IJTAG Mapping” on page 138.
Design Rule Checks
Design Rule Checks

A design rule check (DRC) a rule that checks whether or not a design or design element meets a
tool criteria. They indicate that there may a design issue that prevents the tool from creating a
usable test pattern. DRC runs automatically when you leave setup mode by issuing the
“set_system_mode analysis” command.
Tessent Shell provides a class of EDT?specific “K” rules. See “EDT Rules (K Rules)” in the
Tessent Shell Reference Manual for reference information on each EDT-specific rule.
Notice the DRC message describing the EDT rules in the following example transcript. This
transcript is for the design with two scan channels shown in Figure 4-1 on page 86, in which
none of the EDT pins are shared with functional pins:
// ------------------------------------------------------
// Begin EDT rules checking.
// ------------------------------------------------------
// Running EDT logic Creation Phase.
// 7 pin(s) will be added to the EDT wrapper. (K13)
// EDT rules checking completed, CPU time=0.01 sec.
// All scan input pins were forced to TIE-X.
// All scan output pins were masked.
// ----------------------------------------------------------
These messages indicate the tool will add seven pins, which include scan channel pins, to the
top level of the design. The last two messages refer to pins at both ends of the core-level scan
chains. Because these pins are not connected to the top-level wrapper (external flow) or the top
level of the design (internal flow), the tool does not directly control or observe them in the
capture cycle when generating test patterns.
To ensure values are not assigned to the internal scan input pins during the capture cycle, the
tool automatically constrains all internal scan chain inputs to X (hence, the “TIE-X” message).
Similarly, the tool masks faults that propagate to the scan chain output nodes. This ensures a
fault is not counted as observed until it propagates through the compactor logic. The tool only
adds constraints on scan chain inputs and outputs added within the tool as PIs and POs.
Note
To properly configure the internal scan chain inputs and outputs so that the tool can
constrain them as needed, you must use the -Internal switch with the add_scan_chains
command when setting up for pattern generation in the Pattern Generation phase.
Creation of EDT Logic Files
DRC When EDT Pins are Shared With Functional Pins

If you specified to share any EDT pin with a functional pin, DRC includes messages for K rules
affected by the sharing. Here is DRC output for the design shown in Figure 4-1 on page 86, after
it is re-configured to share certain EDT pins with functional pins, as illustrated in Figure 4-3:
// ----------------------------------------------------------
// Begin EDT rules checking.
// ----------------------------------------------------------
// Running EDT logic Creation Phase.
// Warning: 1 EDT clock pin(s) drive functional logic. May
// lower test coverage when pin(s) are constrained. (K12)
// 2 pin(s) will be added to the EDT wrapper. (K13)
// EDT rules checking completed, CPU time=0.00 sec.
// All scan input pins were forced to TIE-X.
// All scan output pins were masked.
// ----------------------------------------------------------
Notice only two EDT pins are added, as opposed to seven pins before pin sharing. Shared pins
can create a test situation in which a pin constraint might reduce test coverage. The K12
warning about the shared EDT clock pin points this out to you. For details, refer to “Functional/
EDT Pin Sharing” on page 87.
If you report the current configuration with the report_edt_configurations command after DRC,
the report provides more useful information. For example:
// IP version: 1
// Shift cycles: 381, 373 (internal scan length)
// + 8 (additional cycles)
// External scan channels: 2
// Internal scan chains: 16
// Masking registers: 1
// Decompressor size: 32
// Scan cells: 5970
// Bypass logic: On
// Lockup Cells: On
// Clocking: edge-sensitive
// Compactor pipelining: Off
Notice that the number of shift cycles (381 in this example) is more than the length of the
longest chain. This is because the EDT logic requires additional cycles to set up the
decompressor for each EDT pattern (eight in this example). The number of extra cycles is
dependent on the EDT logic and the scan configuration.

By default, the tool writes out the RTL files in the same format as the original netlist. You can
use either the EDT pre-synthesis flow or the post-synthesis flow to generate the EDT IP and
create the TCD file, which you use during EDT pattern generation instead of the traditional
dofiles.
Adapt and use this procedure to generate the EDT IP core and create the TCD file. The
procedure illustrated in this section is the modified version of the post-synthesis flow. See also
“Tessent Core Description (TCD)” on page 33.
Prerequisites
• You must satisfy all requirements for EDT logic generation.
Procedure
1. Invoke Tessent Shell from a shell using the following syntax:
% tessent -shell
The tool’s system mode defaults to Setup mode after invocation.

2. With the set_context command, change the context to EDT IP generation and insertion
(dft -edt) as follows:
SETUP> set_context dft -edt
3. Read the design with scan cells using the read_verilog command. For example:
SETUP> read_verilog cpu_scan.v
4. Read the library using the read_cell_library command. For example:

SETUP> read_cell_library adk.tcelllib
5. Designate the current design using the set_current_design command. For example:
SETUP> set_current_design
6. Depending on your design, you must specify additional parameters such as setting up
scan chains and defining clocks and constraints—see “Parameter Specification for the
EDT Logic” on page 74.
7. Define the EDT logic configuration using the set_edt_options command. For example:
SETUP> set_edt_options -input_channels 2 -output_channels 2 -location internal
8. Change the system mode to Analysis using the set_system_mode command as follows:
The mode change runs the design rule checks and performs the analysis.
9. Use the write_edt_files command to create the files that make up the EDT logic and the
TCD file. For example:
ANALYSIS> write_edt_files created -verilog -replace
10. Exit Tessent Shell.

ANALYSIS> exit
Results
In addition to the EDT logic files that are normally created, the tool writes out the TCD. For
example: created_edt_top.tcd
Once you have specified the EDT logic parameters, you use the write_edt_files command to
create the files that make up the EDT logic. For example:
Where “created” is the name string prepended to the files and “-replace” is a switch that enables
the tool to overwrite any existing files with the same name.
The TCD file is created during EDT IP core generation by issuing the write_edt_files command.
The procedure in this section provides the minimal set of Tessent Shell commands needed to
generate and insert the EDT IP core and create the TCD file. The tool also generates the ICL
and PDL files even if you did not specify the -ijtag option; the TCD-based flow is designed to
take advantage of the automation IJTAG provides in updating test_setup to configure the EDT
IP.
The EDT Logic Files
The EDT Logic Files

The write_edt_files command generates all of the necessary EDT logic files and the design’s
TCD file.
Depending on the EDT logic placement, the following EDT logic files are created:
• created_edt_top.tcd — The design TCD file. You use this file as input to the tool
during EDT pattern creation. See “Generating and Verifying Test Patterns” on page 135.
• created_edt_top.v (external EDT logic only) — Top-level wrapper that instantiates the
core, EDT logic circuitry, and channel output sharing multiplexers.
• created_edt_top_rtl.v (internal EDT logic only) — Core netlist with an instance of the
EDT logic connected between I/O pads and internal scan chains but without a gate-level
description of the EDT logic.
• created_edt.v — EDT logic description in RTL.
• created_edt.icl — EDT logic ICL.
• created_edt.pdl — EDT logic PDL.
• created_core_blackbox.v (external EDT logic only) — Blackbox description of the
core for synthesis.
• created_dc_script.scr — DC synthesis script for the EDT logic.
• created_rtlc_script.scr — RTL Compiler synthesis script for the EDT logic.
The tool also writes out the following dofiles for the legacy flows that do not use the TCD to
pass information from IP creation to pattern generation (see “Dofile-Based Legacy IP Creation
and Pattern Generation Flow” on page 369):
• created_edt.dofile — Dofile for test pattern generation.

• created_edt.testproc — Test procedure file for test pattern generation.
• created_bypass.dofile — Dofile for uncompressed test patterns (bypass mode)
• created_bypass.testproc — Test procedure file for uncompressed test patterns (bypass
mode)
EDT Logic Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
IJTAG and EDT Logic
IJTAG and EDT Logic

By default, the write_edt_files command creates IJTAG files that describe the static
configuration inputs of the TestKompress IP.
These static configuration inputs set, enable, or turn off certain features of the TestKompress IP:
EDT bypass, single chain bypass, low power, and EDT configuration. For details on how to use
the IJTAG files for TestKompress ATPG, see “EDT IP Setup for IJTAG Integration” in the
Tessent IJTAG User’s Manual.
Specification of Module/Instance Names

By default, the tool prepends the name of the top module in the associated netlist to the names
of modules/instances in the generated EDT logic files. This ensures that internal names are
unique, as long as all module names are unique.
If necessary, you can specify the prefix used for internal modules/instance names in the EDT
logic with the “write_edt_files -rtl_prefix <prefix_string>” command. For example:
write_edt_files... -rtl_prefix core1
All internal module/instance names are prepended with “core1” instead of the top module name.
Note
The specified string must follow the standard rules for Verilog or VHDL identifiers.
EDT Logic Description

The structure of the logic described in the tool-generated files depends on many variables.
These variables include the following:
• Location of the EDT logic (internal or external with respect to the design netlist)
• Number of external scan channels
• Number of internal scan chains and the length of the longest chain
• Clocking of the first and last scan cell in every chain (if lockup cells are inserted)
• Names of the pins
Except for the clocking of the scan chain boundaries, which affects the insertion of lockup cells,
nothing in the EDT logic is dependent on the functionality of the core logic.
Note
Generally, you must regenerate the EDT logic if you reorder the scan chains and the
clocking of the first and last scan cell or the scan chain length is affected. See “About
Reordered Scan Chains” on page 58.
Top-level Wrapper
Figure 4-5 illustrates the contents of the new top-level netlist file, created_edt_top.v. The tool
generates this file only if you are using the external flow.
Figure 4-5. Contents of the Top-Level Wrapper
This netlist contains a module, “edt_top”, that instantiates your original core netlist and an “edt”
module that instantiates the EDT logic circuitry. If any EDT pins are shared with functional
pins, “edt_top” instantiates an additional module called “edt_pinshare_logic” (shown as the
optional block in Figure 4-5). The EDT pins and all functional pins in the core are connected to
the wrapper. Scan chain pins are not connected because they are driven and observed by the
EDT block.
Because scan chain pins in the core are only connected to the “edt” block, these pins must not be
shared with functional pins. For more information, refer to “Scan Chain Pins” on page 57. Scan
channel pin sharing (or renaming) that you specified using the set_edt_pins command is
implemented in the top-level wrapper. This is discussed in detail in “Functional/EDT Pin
Sharing” on page 87.
EDT Logic Circuitry

Figure 4-6 shows a conceptual view of the contents of the EDT logic file, created_edt.v.
Figure 4-6. Contents of the EDT Logic
The EDT logic file contains the top-level module and three main blocks:
• Decompressor — Connected between the scan channel input pins and the internal scan
chain inputs
• Compactor — Connected between the internal scan chain outputs and the scan channel
output pins
• Bypass Logic — Connected between the EDT logic and the design core. Bypass logic is
optional but generated by default.
Core
Generated only when the EDT logic is inserted external to the design core, the file
created_core_blackbox.v contains a black-box description of the core netlist. This can be used
when synthesizing the EDT block so the entire core netlist does not need to be loaded into the
synthesis tool.
Note
Loading the entire design is advantageous in some cases as it helps optimize the timing
during synthesis.
Design Compiler Synthesis Script External Flow

The tool generates a Design Compiler (DC) synthesis script, created_dc_script.scr. By default,
the script is in Tool Command Language (TCL), but you can get the tool to write it in DC
command language (dcsh) by including a -synthesis_script dc_shell argument with the
write_edt_files command.
The following is an example script, in the default TCL format, for a core design that contains a
top-level Verilog module named “cpu”:
#************************************************************************
# Synopsys Design Compiler synthesis script for created_edt_top.v
#
#************************************************************************
# Read input design files

read_file -f verilog created_core_blackbox.v
read_file -f verilog created_edt.v
read_file -f verilog created_edt_top.v
current_design cpu_edt_top
# Check design for inconsistencies

check_design
# Timing specification
create_clock -period 10 -waveform {0 5} edt_clock
# Avoid clock buffering during synthesis. However, remember

# to perform clock tree synthesis later for edt_clock
set_clock_transition 0.0 edt_clock
set_dont_touch_network edt_clock
# Avoid assign statements in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants
# Compile design
uniquify
set_dont_touch cpu
compile -map_effort medium
# Report design results for EDT logic

report_area > created_dc_script_report.out
report_constraint -all_violators -verbose >> created_dc_script_report.out
report_timing -path full -delay max >> created_dc_script_report.out
report_reference >> created_dc_script_report.out
# Remove top-level module

remove_design cpu
# Read in the original core netlist

read_file -f verilog gate_scan.v
current_design cpu_edt_top
link
# Write output netlist

write -f verilog -hierarchy -o created_edt_top_gate.v
Design Compiler Synthesis Script for Internal Flow

The tool generates a Design Compiler (DC) synthesis script created_dc_script.scr that
synthesizes the EDT logic in the core netlist for the internal flow as shown in the following
example.
#************************************************************************
# Synopsys Design Compiler synthesis script for config1_edt.v
# Tessent TestKompress version: v8.2009_3.10-prerelease
# Date: Thu Aug 6 01:44:15 2009
#************************************************************************
# Bus naming style for Verilog

set bus_naming_style {%s[%d]}

read_file -f verilog results/config1_edt.v
# Synthesize EDT IP
current_design circle_edt

check_design


# Compile design
uniquify
# Report design results for EDT IP

report_area > results/config1_dc_script_report.out
report_constraint -all_violators -verbose >> results/
config1_dc_script_report.out
report_timing -path full -delay max >> results/
config1_dc_script_report.out
report_reference >> results/config1_dc_script_report.out
write -f verilog -hierarchy -o results/config1_circle_edt_gate.v

exec cat results/config1_circle_edt_gate.v results/config1_edt_top_rtl.v
> results/config1_edt_top_gate.v
RTL Compiler Synthesis Script External Flow

The tool generates an RTL Compiler synthesis script created_rtlc_script.scr when the
-synthesis_script rtl_compiler option is used with the write_edt_files command as shown:
write_edt_files created -synthesis_script rtl_compiler
This script synthesizes the EDT logic and the top-level wrapper that instantiates the core design
and EDT logic for the external flow as shown in the following example.
#************************************************************************
# Cadence RTL Compiler synthesis script for created_edt_top.vhd
# Tessent TestKompress version: v9.1-snapshot_2010.08.19_05.02
# Date: Thu Aug 19 14:07:25 2010
#************************************************************************
# Set RTL Compiler attributes

set_attribute hdl_auto_async_set_reset true

read_hdl -vhdl created_core_blackbox.vhd
read_hdl -vhdl created_edt.vhd
read_hdl -vhdl created_edt_top.vhd
# Elaborate design
set_attribute hdl_infer_unresolved_from_logic_abstract true /
elaborate
cd /designs/core_edt_top

check_design
define_clock -period 10000 -rise 0 -fall 50 edt_clock

# set_attribute ideal_network true edt_clock
# Avoid reset signal buffering during synthesis.However, remember

# to perform reset tree synthesis later for edt_reset
set_attribute ideal_network true edt_reset

set_attribute remove_assigns true core_edt_top
set_remove_assign_options -preserve_dangling_nets
-respect_boundary_optimization -verbose -design core_edt_top
# Compile design
edit_netlist uniquify core_edt_top
synthesize -to_mapped -effort medium
change_names -verilog

report_area > created_rtlc_script_report.out
report_design_rules >> created_rtlc_script_report.out
report_timing >> created_rtlc_script_report.out
report_gates >> created_rtlc_script_report.out
# Read in the original core netlist

read_hdl -v1995 m8051_scan.v
elaborate

write_hdl > created_edt_top_gate.v
RTL Compiler Synthesis Script for Internal Flow

The tool generates an RTL Compiler synthesis script created_rtlc_script.scr when the
-synthesis_script rtl_compiler option is used with the write_edt_files command as shown:
write_edt_files created -synthesis_script rtl_compiler
This script synthesizes the EDT logic in the core netlist for the internal flow as shown in the
following example.
#************************************************************************
# Cadence RTL Compiler synthesis script for created_edt.v
# Tessent TestKompress version: v9.1-snapshot_2010.08.19_05.02
# Date: Thu Aug 19 14:10:04 2010
#************************************************************************
# Bus naming style for Verilog

set_attribute bus_naming_style {%s[%d]}

read_hdl -v1995 created_edt.v
# Elaborate design
set_attribute hdl_infer_unresolved_from_logic_abstract true /
elaborate
# Synthesize EDT IP
cd /designs/B1_edt

check_design

set_attribute ideal_network true edt_clock

set_attribute remove_assigns true B1_edt
-respect_boundary_optimization -verbose -design B1_edt
# Compile design
edit_netlist uniquify B1_edt

report area > created_rtlc_script_report.out
report design_rules >> created_rtlc_script_report.out
report timing >> created_rtlc_script_report.out
write_hdl > created_B1_edt_gate.v
cd /designs/B2_edt

check_design

set_attribute ideal_network true edt_clock
set_attribute remove_assigns true B2_edt

-respect_boundary_optimization -verbose -design B2_edt
# Compile design
edit_netlist uniquify B2_edt

report area >> created_rtlc_script_report.out
report design_rules >> created_rtlc_script_report.out
write_hdl > created_B2_edt_gate.v
# Synthesize EDT multiplexor

cd /designs/core_edt_mux_2_to_1

check_design
# Compile design
# Report design results for EDT mux

report area >> created_rtlc_script_report.out
write_hdl > created_core_edt_mux_2_to_1_gate.v

exec cat created_core_edt_mux_2_to_1_gate.v created_B2_edt_gate.v
created_B1_edt_gate.v created_edt_top_rtl.v >
created_edt_top_gate.v
# Remove all temporary files

exec rm created_core_edt_mux_2_to_1_gate.v created_B2_edt_gate.v
created_B1_edt_gate.v
Bypass Mode Files

By default, the EDT logic includes bypass circuitry. If your EDT IP can operate in multiple
configurations (for example, low power, bypass, and so on), then a single TCD file contains all
the configurations. During pattern generation, you can specify how you want those parameters
of the EDT IP configured for that ATPG mode. See “Generating and Verifying Test Patterns”
on page 135.
To turn off the generation of bypass logic, see the set_edt_options command.
For improved design routing, the bypass logic can be inserted into the netlist instead of the EDT
logic. For more information, see “Generating EDT Logic When Bypass Logic Is Defined in the
Inserting EDT Logic During Synthesis

When you place EDT logic internal to the design core, the tool writes a core netlist with an
instance of the EDT logic connected between I/O pads and internal scan chains without the
gate-level description of the EDT logic.
Alternatively, you can use this procedure to create a DC synthesis script that both inserts and
synthesizes the EDT logic inside the core netlist with the “write_edt_files -insertion dc” option.
This DC script is more complex because it includes additional commands that help instantiate
the EDT logic within the design core and requires that the entire design be loaded into the
synthesis tool so the necessary connections can be specified.
Note
The order of the gate-level EDT logic modules in the resulting design is different than that
written when the tool inserts the EDT logic before synthesis.
Prerequisites
• Gate-level netlist.
Procedure
1. Invoke Tessent Shell and configure the EDT logic parameters. See “Creation of the EDT
Logic” on page 65. You must set up the EDT logic insertion to be internal to the design
core with the set_edt_options command.
2. Run DRC and correct any errors. See “Design Rule Checks” on page 97.
3. Examine test coverage and data volume estimates and adjust EDT configurations if
necessary. See “Generating and Verifying Test Patterns” on page 135.
4. Create the EDT logic files. For example:
write_edt_files created -insertion dc
The following files are created:

• created_edt.v — EDT logic description in RTL.
• created_dc_script.scr — DC synthesis script for the EDT logic.
• created_edt.dofile — Dofile for test pattern generation.
• created_edt.testproc — Test procedure file for test pattern generation.
• created_bypass.dofile — Dofile for uncompressed test patterns (bypass mode).
• created_bypass.testproc — Test procedure file for uncompressed test patterns
(bypass mode).
5. Synthesize the EDT logic. See “Synthesizing the EDT Logic” on page 123.
6. Generate test patterns. See “Generating and Verifying Test Patterns” on page 135.
Examples
The following DC synthesis script is an example of the script generated when the
“write_edt_files -insertion dc” option is used.
#************************************************************************
# Synopsys Design Compiler script for EDT logic insertion
#
#************************************************************************
# Initialize DC variables
set bus_naming_style {%s[%d]}
set compile_seqmap_honor_sync_set_reset true

read_file -f verilog results/created_edt.v
read_file -f verilog netlists/gate_scan_sco.v
# Current design is the top-most level.

current_design retimetest
# Create an instantiation of EDT logic within the top-level of the design.

create_cell retimetest_edt_i [find design retimetest_edt]
# Create instantiation(s) of an EDT mux to support sharing of output

channel and core pins.
create_cell retimetest_edt_mux_2_to_1_i1 [find design
retimetest_edt_mux_2_to_1]
# Connect core scan inputs to EDT logic scan inputs.

set scan_inputs { "edt_si1" "edt_si2" "edt_si3" \
"edt_si4" "edt_si5" "edt_si6" \
"edt_si16" }
set count 0
foreach i $scan_inputs {
set temp_net [all_connected [find port $i]]
disconnect_net $temp_net [find port $i]
set temp "retimetest_edt_i/edt_scan_in[$count]"
connect_net $temp_net [find pin $temp]
query_objects [all_connected [find net $temp_net]]
incr count
}
# Remove scan input ports from top-level.

set scan_inputs_to_delete { "edt_si1" "edt_si2" "edt_si3" \
"edt_si16" }
foreach i $scan_inputs_to_delete {
remove_port [find port $i]
}
# Connect core scan outputs to EDT logic scan outputs.

set scan_outputs { "edt_so1" "edt_so2" "edt_so3" \
"edt_so4" "edt_so5" "edt_so6" \
"edt_so16" }
set count 0
foreach i $scan_outputs {
set temp_net [all_connected [find port $i]]
disconnect_net $temp_net [find port $i]
set temp "retimetest_edt_i/edt_scan_out[$count]"
connect_net $temp_net [find pin $temp]
incr count
}
# Remove scan output ports from top-level.

set scan_outputs_to_delete { "edt_so1" "edt_so2" "edt_so3" \
"edt_so16" }
foreach i $scan_outputs_to_delete {
remove_port [find port $i]
}
# Connect EDT control pins to the top-level.
# Route pin edt_clk_buf/Z to the EDT control pin retimetest_edt_i/

edt_clock.
set temp_net [all_connected [find pin edt_clk_buf/Z]]
connect_net $temp_net [find pin retimetest_edt_i/edt_clock]
# Route pin edt_update to the EDT control pin retimetest_edt_i/edt_update.

create_port edt_update -direction in
create_net retimetest_edt_update_net
connect_net retimetest_edt_update_net [find port edt_update]
connect_net retimetest_edt_update_net [find pin retimetest_edt_i/
edt_update]
query_objects [all_connected [find net retimetest_edt_update_net]]
# Route pin edt_bypass to the EDT control pin retimetest_edt_i/edt_bypass.

create_port edt_bypass -direction in
create_net retimetest_edt_bypass_net
connect_net retimetest_edt_bypass_net [find port edt_bypass]
connect_net retimetest_edt_bypass_net [find pin retimetest_edt_i/
edt_bypass]
query_objects [all_connected [find net retimetest_edt_bypass_net]]
# Connect EDT input channel pins to the top-level.
# Route pin edt_channels_in1 to the EDT channel input pin

retimetest_edt_i/edt_channels_in[0].
create_port edt_channels_in1 -direction in
create_net retimetest_edt_channels_in0_net
connect_net retimetest_edt_channels_in0_net [find port edt_channels_in1]
connect_net retimetest_edt_channels_in0_net [find pin retimetest_edt_i/
edt_channels_in[0]]
query_objects [all_connected [find net retimetest_edt_channels_in0_net]]
# Route pin edt_channels_in2 to the EDT channel input pin
retimetest_edt_i/edt_channels_in[1].
create_port edt_channels_in2 -direction in
create_net retimetest_edt_channels_in1_net
connect_net retimetest_edt_channels_in1_net [find port edt_channels_in2]
connect_net retimetest_edt_channels_in1_net [find pin retimetest_edt_i/
edt_channels_in[1]]
query_objects [all_connected [find net retimetest_edt_channels_in1_net]]
# Connect EDT output channel pins to the top-level.
# Route EDT channel output pin retimetest_edt_i/edt_channels_out[0] to

left/rcmd_fc_l_fromCore.
set temp_net [all_connected [find pin left/rcmd_fc_l_fromCore]]
disconnect_net $temp_net [find pin left/rcmd_fc_l_fromCore]
connect_net $temp_net [find pin retimetest_edt_mux_2_to_1_i1/a_in]
create_net retimetest_edt_channels_out0_top_net
connect_net retimetest_edt_channels_out0_top_net [find pin
retimetest_edt_mux_2_to_1_i1/b_in]
connect_net retimetest_edt_channels_out0_top_net [find pin
retimetest_edt_i/edt_channels_out[0]]
create_net retimetest_edt_mux_2_to_1_i1_out_net
connect_net retimetest_edt_mux_2_to_1_i1_out_net [find pin
retimetest_edt_mux_2_to_1_i1/z_out]
connect_net retimetest_edt_mux_2_to_1_i1_out_net [find pin left/
rcmd_fc_l_fromCore]
set temp_net [all_connected [find pin scanen_buf/scan_en_out]]
connect_net $temp_net [find pin retimetest_edt_mux_2_to_1_i1/sel]
# Route EDT channel output pin retimetest_edt_i/edt_channels_out[1] to

edt_channels_out2_buf/A.
create_net retimetest_edt_channels_out1_net
connect_net retimetest_edt_channels_out1_net [find pin
edt_channels_out2_buf/A]
connect_net retimetest_edt_channels_out1_net [find pin retimetest_edt_i/
edt_channels_out[1]]
query_objects [all_connected [find net retimetest_edt_channels_out1_net]]
# Connect system clocks to the EDT logic bypass logic.
# Route clock output clk2 to bypass logic.

set temp_net [all_connected [find port clk2]]
connect_net $temp_net [find pin retimetest_edt_i/clk2]
# Synthesize EDT logic

current_design retimetest_edt

check_design


# Compile design
uniquify
# Report design results for EDT logic

report_area > results/created_dc_script_report.out
report_constraint -all_violators -verbose >> results/
created_dc_script_report.out
report_reference >> results/created_dc_script_report.out
# Synthesize EDT multiplexor

current_design retimetest_edt_mux_2_to_1

check_design
# Compile design
# Report design results for EDT mux

report_area >> results/created_dc_script_report.out

current_design retimetest
write -f verilog -hierarchy -o results/created_edt_top_gate.v
The preceding script performs the following EDT logic insertion and synthesis steps:
1. Fixing the Bus Naming Style — Because bus signals can be expressed in either bus
form (for example, foo[0] or foo(0)), or bit expanded form (foo_0), this command fixes
the bus style to the bus form. This is particularly necessary during logic insertion
because the script looks for the EDT logic bus signals to be connected to the scan chains.
2. Read Input Files — Next, the input gate-level netlist for the core and the RTL
description of the EDT logic are read.
3. Set Current Design — The current design is set to the top-most level of the input
netlist.
4. Instantiate the EDT Logic and 2x1 Multiplexer Module — The EDT logic is
instantiated within the top-level of the design. If there is sharing between EDT channel
outputs and functional pins, a 2x1 multiplexer module (the description is included in the
created_edt.v file) is also instantiated.
5. Connect Scan Chain Inputs — Scan chain inputs should be connected to the top level
without any I/O pads associated with them. This part of the script disconnects the nets
that are connected to the scan chain input ports and connects them to the EDT logic.
6. Remove Scan Chain Input Ports — Remove the dangling scan chain input ports that
are not connected to any logic after completing step 5.
7. Connect Scan Chain Outputs — Same as step 5, except that now the scan chain
outputs are connected to the EDT logic.
8. Remove Scan Chain Output Ports — Scan chain output ports, which are left dangling
after step 7, are removed from the top level.
9. Connect EDT Control Pins — The EDT control pins are connected to the output of
pre-existing pads. This is done only if you specified an internal node pin to which to
connect the EDT control signal. If not, a new port is created, and the EDT control pin is
connected to the new port. The script shows the connection for only the edt_clock
signal. Similar commands are necessary to connect each of the other EDT control pins.
10. Connect EDT Channel Input Pins — The next set of commands create a new port for
the input channel pin and connect the EDT input channel pin to the newly created port.
This has to be repeated for each input channel pin. This is done only when no internal
node name was specified for the EDT pin. If an internal node name was specified, the
script would be the same as in step 9.
Note
Be aware you need to add an I/O pad later for each new port that is created.
11. Connect EDT Channel Output Pin to a Specified Internal Node (or a Top-Level
Pin) that is Driven by Functional Logic — The output channel pin in this case is
shared with a functional pin. Whenever the node is shared with functional logic or is
connected to TIE-X (a blackbox is assumed in such cases), a multiplexer is inserted.
However, if the specified internal node is connected to a constant signal value, the net is
disconnected and connected to the EDT channel output pin. This section of the script
inserts a multiplexer and connects the inputs from the EDT logic and the functional net
to the multiplexer inputs. The output of the multiplexer is connected to the input of the I/
O pad cell.
Note
The select input of the multiplexer is connected to the existing scan enable signal, as
the functional or scan chain output can be propagated through the multiplexer
depending on the shift and capture modes of the scan operation.
You should specify the name of the scan enable signal. If a name is not specified and a
pin with a default name (scan_en) does not exist at the top level, a new scan_en pin is
created.
Creation of a Reduced Netlist for Synthesis
12. Connect EDT Channel Output Pin to a Non-Shared Specified Internal Node (Or A
Top-Level Pin) — In this case, the specified internal node is not shared with any
functional logic. The tool removes any net that is connected to the internal node. It
creates a new net and connects it to the channel output pin.
13. Connect System Clocks to EDT Logic — For the bypass mode, scan chains are
concatenated so that the EDT logic can be bypassed and normal ATPG scan patterns can
be applied to the circuit. During scan chain concatenation, lockup cells are often needed
(especially if the clocks are different or the clock edges are different) to guarantee
proper scan shifting. These “bypass” lockup cells are driven by the clocks that drive the
source or the destination scan cells. As a result, some system clocks have to be routed to
the bypass module of the EDT logic. Clock lines are tapped right before they fan out to
multiple modules or scan cells and are brought up to the topmost level and connected to
the EDT logic.
14. Synthesis of RTL Code — At this point, the insertion of the EDT logic within the top-
level of the original core is complete. The subsequent parts of the script are mainly for
synthesizing the logic. This part of the script is almost the same as that of the external
flow, with the following exceptions: the EDT logic is synthesized first followed by the
EDT multiplexer(s). In both cases, the synthesis is local to the RTL blocks and does not
affect the core, which is already at the gate level.
15. Write Out Final Netlist — Once the synthesis step is completed, DC writes out a gate-
level netlist that contains the original core, the EDT logic, and any multiplexers the tool
added to facilitate sharing of output pins.
Related Topics
The EDT Logic Files

In the internal flow, the EDT logic is instantiated within an existing pad-inserted netlist and
connections must be made from the pad terminals to the EDT logic pins.
When using DC to insert and synthesize the EDT logic as described in “Inserting EDT Logic
During Synthesis,” the entire netlist must be read into the synthesis tool, so that the proper
connections can be specified.
Input netlists can be huge and it may take a lot of time or perhaps not even be possible to run the
synthesis tool. If your netlist is in this category, you can use the tool to write out a reduced-size
netlist especially for the synthesis run with the write_edt_files -reduced_netlist command. The
reduced netlist includes only the modules required for the synthesis tool to make the necessary
connections between the pad terminals and EDT logic pins.
You provide this smaller file to the synthesis tool instead of providing the entire input netlist.
The tool writes the rest of the input netlist into a second netlist file that excludes the modules
written out in the synthesisonly file but includes everything else. You then use the output netlist
from the synthesis run along with the second netlist as inputs for ATPG.
Note
Another option is to use the tool to insert the EDT logic into the core netlist before
synthesis. This is the default behavior for the internal flow.
Figure 4-7 is a conceptual example of an input netlist. Each box represents an instance with the
instance_name/module_names shown. The small rectangles shaded with dots represent
instances of technology library cells. The black circles represent four internal EDT logic
connection nodes.
Figure 4-7. Design Netlist With Internal Connection Nodes
When writing out the compression files with the -Reduced_netlist switch, the modules are
distributed between the two netlists as follows:
• <prefix>_reduced_netlist.v(for synthesis) — TOP, A, ASUB, clkctrl

• <prefix>_rest_of_netlist.v(rest of the netlist for ATPG) — ASUB1, ASUB2, A_B, C,
C1, C3, ACONT, D
Note
The reduced netlist for synthesis does not include the technology library cells that
have EDT logic connection nodes because the port list is sufficient for making these
connections.
Chapter 5
Synthesizing the EDT Logic
After you create the EDT logic, as discussed in “Creation of the EDT Logic”, the next step is to
synthesize it. The tool creates a basic Design Compiler (DC) synthesis script, in either dcsh or
TCL format, that you can use as a starting point. Running the synthesis script is a separate step
in which you exit the tool and use DC to synthesize the EDT logic. You can use any synthesis
tool; the generated DC script provides a template for developing a custom script for any
synthesis tool.
The EDT Logic Synthesis Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Synthesis and External EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Synthesis and Internal EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
SDC Timing File Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
The EDT Logic Synthesis Script

If you use DC to synthesize the netlist, you should examine the .synopsys_dc.setup file and
verify that it points to the correct libraries. Also, examine the DC synthesis script generated by
the tool and make any needed modifications.
Note
You should preserve the pin names in the EDT logic hierarchy. Preserving pin names
ensures that pins resolve when test patterns are created and increases the usefulness of the
debug information returned during DRC.
Note
When using the external flow and boundary scan, you must modify this script to read in the
RTL description of the boundary scan circuitry. Refer to “Preparation for Synthesis of
Boundary Scan and EDT Logic” on page 243 for an example DC synthesis script with
modifications for boundary scan.
The following DC commands are included in the synthesis scripts created by the tool:
• set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants
Synthesis and External EDT Logic
This command prevents DC from including “assign” statements in the Verilog gate-
level netlist to prevent problems later in the design flow.
• set_clock_transition 0.0 edt_clock set_dont_touch_network edt_clock
These commands prevent buffering of the EDT clock during synthesis and preserves the
EDT clock network. However, you must perform clock tree synthesis later for the EDT
clock.
After you run DC to synthesize the netlist without any errors, verify the tri-state buffers were
correctly synthesized. In some cases, DC may insert incorrect references to “\**TSGEN**”.
For information on correcting these references, see “Incorrect References in Synthesized
For more information, see “The EDT Logic Files” on page 101.
Related Topics
The EDT Logic Files

Once the EDT logic is created but before you synthesize it, you should insert I/O pads and
(optionally) boundary scan. For designs that require boundary scan, you should insert the
boundary scan first, followed by I/O pads. Then, synthesize the I/O pads and boundary scan
together with the EDT logic.
Note
You can add boundary scan and I/O pads simultaneously with a boundary scan tool.
Boundary Scan
Boundary scan cells cannot be present in your design before the EDT logic is inserted. To
include boundary scan, you perform an additional step after the EDT logic is created. In this
step, you can use any tool to insert boundary scan. As shown in Figure 5-1, the circuitry should
include the boundary scan register, TAP controller, and (optionally) I/O pads.
Figure 5-1. Contents of Boundary Scan Top-Level Wrapper
I/O Pad Insertion

You can use any method to insert I/O pads after boundary scan insertion and EDT logic
creation. If you need to integrate EDT logic after the I/O pads are inserted, see “Managing Pre-
existing I/O Pads”.
If the core and pads are separated as described in “Managing Pre-existing I/O Pads”, you should
reinsert the EDT logic-core combination into the original circuit in place of the extracted core.
When you reinsert it, ensure the EDT logic-core combination is connected to the I/O pads. Add
pads for any new EDT pins not shared with existing core pins.
If you need to insert I/O pads before scan insertion and you used the architecture swapping
solution described in the “Managing Pre-existing I/O Pads” section, then I/O pads are already
included in your scan-inserted design and you can proceed to insert boundary scan.
Related Topics
Synthesis and Internal EDT Logic
Synthesis and Internal EDT Logic

The tool inserts and connects an instance of the EDT logic into the design netlist and creates a
DC script to synthesize the EDT logic.
You may be able to run the script without modification if the following are true:
• DC is the synthesis tool.

• The default clock definitions are acceptable.
• Technology library files are set up correctly in the .synopsys_dc.setup file.
Note
The syntax of the .synopsys_dc.setup file and the DC synthesis script differ
depending on which format, dcsh or TCL, they support. If the .synopsys_dc.setup
file does not exist, you must add the library file references to the synthesis script.
Optionally, you can insert the EDT logic into the core during synthesis. See “Inserting EDT
Logic During Synthesis” on page 112.
SDC Timing File Generation
SDC Timing File Generation

You can use the tool to generate Synopsys Design Constraint (SDC) timing files for the static
timing analysis of the test logic. There are two methods for generating SDC timing files, using
the “extract_sdc” and the “write_edt_files -timing_constraints” commands.
The SDC generated with the extract_sdc method is suitable for the DftSpecification flow with
the process_dft_specification command where DFT signals for logictest clocks and signals such
as “scan_enable” are defined. This method can provide logictest timing constraints right from
the RTL context, which can be merged with user-defined timing constraints into a “single-
mode” set of constraints that apply to the whole design, for running global pre-layout synthesis,
or even some phases of layout. The extract_sdc command also generates modal STA procs for
pre or post-layout signoff.
The SDC generated with the “write_edt_files -timing_constraints” method is suitable when
generating EDT logic on gate level scan inserted designs, or when using the Legacy Skeleton
RTL flow. This method uses port names used during EDT insertion for clocks and control
signals instead of DFT signals.

SDC Timing File Generation Using extract_sdc

The Synopsys Design Constraint (SDC) timing file can be generated using the extract_sdc
command.
The “write_edt_files -timing_constraints method” generates timing tool driver files and Tcl
procedures for different modes to be used in static timing analysis. It targets gate level design.
The extract_sdc method generates timing constraints for both RTL-to-gate synthesis and for pre
or post-layout STA.
The EDT SDC can be generated on a design without IjtagNetwork where ICL extraction can
still be performed on the design. An example of this usage is when the static control signals of
the EDT controller are brought up to ports at the current_design level.
Both the “process_dft_specification” RTL flow and the “write_edt_files -tsdb” gate flow can
use extract_sdc to generate SDC timing files. The “extract_sdc” flow is the only supported
method for “write_edt_files -tsdb” flow, that is the flow where the EDT IP is generated in the
gate level after scan insertion. For this method, the “extract_sdc” flow has the same
requirements as the DftSpecification flow, specifically knowledge of DFT signals.
For more information, see “Timing Constraints (SDC)” in the Tessent Shell User’s Manual.
SDC Timing File Generation Using write_edt_files

The write_edt_files command can be used to generate SDC timing files.
Separate SDC files provide timing constraints for the EDT logic and the ATPG setups as
described in the following topics:
Note
The SDC files are generated from the timing specified in the test procedure file. The
generated SDC files should be used as templates and employed for static timing analysis
only after appropriate values are inserted to correspond with actual timing information.
The timing files are formatted in the TCL programming language with multiple sections. This
enables you to select one or all sections depending on your needs.
You can also set variables before the timing files are loaded to specify values in the timing files
as described in Table 5-1.
Table 5-1. Timing File Variables
Description Variables
Parameters for system clocks system_clock_latency_min
system_clock_latency_max
system_clock_uncertainty_setup
system_clock_uncertainty_hold
Parameters for EDT clocks edt_clock_latency_min
edt_clock_latency_max
edt_clock_uncertainty_setup
edt_clock_uncertainty_hold
I/O delay for EDT pins edt_pins_input_delay
edt_pins_output_delay
EDT Logic/Core Interface Timing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Scan Chain and ATPG Timing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
EDT Logic/Core Interface Timing Files

You can output timing files specific to the EDT logic and design core interface with the
“write_edt_files -Timing_constraints” command.
Depending on the application, the tool writes out these timing files:
• filename_prefix_edt_shift_sdc.tcl — Specifies constraints for the EDT shift mode.
• filename_prefix_bypass_shift_sdc.tcl — Specifies constraints for the EDT bypass

shift mode. This file is written for applications that include a bypass configuration. By
default, the tool outputs an EDT bypass configuration.
• filename_prefix_slow_capture_sdc.tcl — Specifies constraints for slow-capture mode.
This file is only written when stuck-at patterns or launch-off-shift capture patterns are
used.
• filename_prefix_fast_capture_sdc.tcl —Specifies constraints for fast-capture mode.
This file is only written when launch-off capture transition patterns are used.
Timing files can also be generated for EDT logic with dual compression configurations. When
test patterns are applied, only one of the configurations is active at any time. So, the paths
originating at edt_configuration are declared as multi-cycle paths to avoid the need to verify
each of the individual configurations separately. For more information on dual configurations,
see “Dual Compression Configurations” on page 75.
Note
When the EDT logic is placed inside the design and a top-level pin name is not specified for
a control pin, then the specified internal connection name is used for synthesis and in the
constraints. For more information, see the set_edt_pins command.
EDT Shift Mode Clock Constraints

During shift, the EDT logic is clocked along with all the scan cells as new data is loaded and the
captured data is unloaded from the scan chains. Therefore, the tool declares the edt_clock and
all the shift clocks:
• create_clock — Declares all clocks used for scan chain shifting at the very beginning of
the file. For example:
create_clock –name edt_clock –period 100 -waveform {50 90}
[get_ports edt_clock]
• set_clock_latency —Describes the clock network latency for all clocks used during
shift. Clock latency for both the minimum and maximum operating conditions is
specified. Because the tool has no timing information, a default value of 0 is used for the
latencies. These default values can be changed to reflect the actual values as necessary.
For example:
set_clock_latency –min 0 [get_clocks edt_clock]
set_clock_latency –max 0 [get_clocks edt_clock]
• set_clock_uncertainty — Describes the uncertainty (skew) related to the setup and hold
times for the flops driven by specified shift clocks. For example:
set_clock_uncertainty –setup <def_value> [get_clocks edt_clock]
set_clock_uncertainty –hold <def_value> [get_clocks edt_clocks]
EDT Shift Mode Input/Output Pin Delay Constraints

During shift mode, the input and output delays for the EDT control and channel pins are
declared. For the edt_channel pins, the input delay is measured with respect to the force_pi and
measure_po events in the test procedure. Default values can be changed to reflect the actual
values as necessary. For example:
• set_input_delay — Specifies the arrival time of the signals relative to when the clock
edge appears. For example:
set_input_delay <def_value> –clock force_pi [get_ports
edt_channel_in]
• set_output_delay — Specifies the departure time of the signals relative to when the
clock edge appears. For example:
set_output_delay <def_value> –clock measure_po [get_ports
edt_channel_out]
EDT Shift Mode Static Constraints

During EDT shift mode, static values for certain EDT-specific signals are declared as follows:
• EDT bypass mode signal — edt_bypass signal is constrained to 0 (off), when EDT
mode is enabled. For example:
set_case_analysis 0 edt_bypass
• EDT reset signal — edt_reset signal is constrained to 0 (off). For example:

set_case_analysis 0 edt_reset
• Scanenable (SEN) signal — scan_en signal controls the select input of the muxes when
channel output pins are shared with functional pins. For example:
set_case_analysis <on_state> scan_en
• Dual configuration signal — edt_configuration signal is set to either a 1 or 0 value by

the test patterns depending on the configuration being used. Instead of constraining the
edt_configuration signal, all paths originating from the pin are declared as multi-cycle
paths. For example:
set_multicycle_path <path_multiplier> –from edt_configuration
EDT Shift Mode Timing Exceptions

• False and multi-cycle paths — During shift, all paths in the EDT logic are exercised,
so no false or multi-cycle paths are declared except as follows:
o Hold timing exception added from masks_hold_reg through EDT channel output
when there are no pipeline or lockup cells used uniformly for all scan chains in that
channel.
o Hold timing exception from the low-power hold register on the scan chain input
side. See “Static Timing Analysis and Hold Violations From Low-Power Hold
Registers” for complete information.
For example:
global reg_suffix
set rsfx [expr {[info exists reg_suffix] ? $reg_suffix : "_reg"}]
# Relax min_delay(hold) check from low power hold registers to scan cells,
# because scan clocks are OFF when low power hold registers are updated
set_multicycle_path -hold 1 -from [get_cells piccpu_edt_i/

piccpu_edt_controller_i/low_power_shift_controller_i/
low_power_hold_reg_*$rsfx*]
# Relax min_delay(hold) check from mask hold registers through edt

# channel output, because scan clocks are OFF when the mask hold registers
# are updated

piccpu_edt_controller_i/masks_hold_reg*$rsfx*] -through [get_pins
piccpu_edt_i/edt_channels_out?0?]

piccpu_edt_controller_i/masks_hold_reg*$rsfx*] -through [get_pins
piccpu_edt_i/edt_channels_out?1?]
In the example, reg_suffix defaults to “_reg” that matches how Design Compiler names
registers from RTL net names. When using an skeleton flow, you may need to update the EDT
instance path based on the final design.
Bypass Shift Mode Constraints

In bypass shift mode, the EDT decompressor, compactor, and masking logic are completely
bypassed and the scan chains behave as uncompressed chains that operate with regular ATPG
patterns. The timing constraints for bypass shift mode are similar to those for regular scan
operation except as follows:
• EDT bypass signal — edt_bypass signal is constrained to 1 (on). For example:

set_case_analysis 1 edt_bypass
• Scan enable (SEN) signal — scan_en signal is asserted to its on state when an EDT
channel output pin is shared with a functional output pin. The set_edt_pins command
specifies the scan_en pin. For example:
set_case_analysis <on_state> scan_en
• Clock constraints — All clocks used during bypass shift mode are declared using the
same commands as for EDT shift mode. See “EDT Shift Mode Clock Constraints” on
page 129.
• Input and output delays — The input and output delays should be described for all
scan chain I/Os. The input and output delay constraints for bypass shift are declared with
the same commands as for EDT shift. See “EDT Shift Mode Input/Output Pin Delay
Constraints” on page 130.
• EDT logic – In the bypass mode, the EDT logic is completely bypassed, and therefore,
any paths originating and ending in the EDT logic are declared as false paths as follows:
set_false_path –from edt_clock
set_false_path –to edt_clock
Bypass/EDT Capture Mode Constraints

In the capture mode, the primary objective is to mimic the functional operation of the design,
but only timing constraints related to the test logic are written. Constraints related to the
functional mode of operation should be specified by the functional timing constraints file for the
design. Specifically, some of the timing constraints are as follows:
• Clock constraints — All clocks used during capture mode are declared using the same
commands as for EDT shift. See “EDT Shift Mode Clock Constraints” on page 129.
• Input and output delays — The input and output delays are declared for all scan chain
I/Os using the same commands as for EDT shift. See “EDT Shift Mode Input/Output Pin
Delay Constraints” on page 130.
• Static constraints — The edt_reset signal is constrained to its off (0) state during
capture. For example:
set_case_analysis 0 edt_reset
Note
edt_bypass, edt_update, and edt_configuration could potentially be shared with
functional pins set by ATPG, so they are not constrained. During capture, the EDT
clock is not pulsed, so the values on these pins do not interfere with the EDT logic.
• Inactive paths — The edt_clock is not pulsed during capture, so the following paths are
unused and need to be declared as false paths:
o Between the mask_shift_reg and mask_hold_reg.
o Between the mask_hold_reg and the output channels, pipeline cells, or lockup cells
(if they exist).
o Between the lockup cells at the output of the decompressor and the input of the scan
chains.
o Between the pipeline stages at the compactor and the EDT channel output pins.
False paths are declared for all these cases by declaring all paths originating from state
elements clocked by edt_clock as false paths. For example:
• Paths between the scan chain outputs and the compactor — The scan chain outputs
feeding the compactor are not active during capture. Therefore, all paths from the
decompressor outputs to the edt_channel_output or the lockup cells in front of the
pipeline stages inside the compactor are declared as false paths.
If no pipeline stages or lockup cells exist, then the following constraints declare all EDT
channels as false paths. For example:
set_false_path –to <edt_channel_output>
If pipeline stages or lockup cells do exist, then all paths originating from state elements
clocked by edt_clock are declared as false paths. For example:
• Slow and fast capture modes — The slow capture mode corresponds to stuck-at and
launch-off-shift patterns, and fast capture mode corresponds to launch-off-capture
(broadside) patterns.
o Slow capture mode — The scan_enable pin is unconstrained, so the scan path could
potentially be used by ATPG. For bypass patterns, the bypass chain concatenation
path through edt_bypass_logic is unconstrained. For the EDT capture mode this path
is not used, but it is unconstrained so that both bypass and EDT capture can share the
same timing constraints.
o Fast capture mode — The bypass chain concatenation path through the
edt_bypass_logic is not used and is declared a false path. For example:
create clock –period 100 { edt_i/sysclk }
set_false_path –to edt_i/sysclk
set_case_analysis 0 edt_i/edt_bypass
Scan Chain and ATPG Timing Files

You can output timing files specific to the scan path and ATPG setup in the core with the
“write_core_timing_constraints <filename_prefix>” command. Depending on the application,
the following timing files are written out.
• filename_prefix_core_shift_sdc.tcl — Specifies shift mode constraints.
• filename_prefix_slow_capture_sdc.tcl — Specifies slow-capture mode constraints.
This file is only written when stuck-at or launch-off-shift capture patterns are used.
• filename_prefix_fast_capture_sdc.tcl — Specifies fast-capture mode constraints. This
file is only written when launch-off capture transition patterns are used.
Scan Chain and ATPG Core Constraints

The scan chain and ATPG constraints associated with the core are determined as follows:
• For scan shift mode, the scan_en signal is constrained to its active value, so paths from
scan cell outputs to the functional logic are declared as false paths. This is done by
forcing the values found in the shift procedure.
• For capture mode, all shift paths between successive scan cells are declared as false
paths, unless launch-off-shift (LOS) transition patterns are in effect. This is done by
forcing pin constraint values.
• For at-speed testing, the hold_pi and mask_po constraints are translated into timing
constraints. A warning message is issued when writing out the fast capture mode timing
constraints if hold_pi and mask_po are not specified.
• Cell constraints specified for an ATPG run are declared during the capture mode.
Constraints specified using a form other than pin_pathname are converted into
structurally reachable pins at the boundary of library cells that contain the target
sequential element. This includes all non-clock input pins for “set_false_path -to” and
all output pins for “set_false_path -from” and set_case_analysis.
Constraints specified using –clock and –chain are translated into individual sequential
elements. All constraints except TX are translated to “set_false_path -from” and
“set_false_path -to”.
Chapter 6
Generating and Verifying Test Patterns
This chapter describes how to generate compressed test patterns. In this part of the flow, you
generate and verify the final set of test patterns for the design.
After you insert I/O pads and boundary scan and synthesize the EDT logic, invoke Tessent Shell
with the synthesized top-level netlist and generate compressed test patterns.
Note
You can write test patterns in a variety of formats including Verilog and WGL.
Preparation for Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

EDT Pattern Generation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
IJTAG Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Scan Chain Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Core Instance Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Pattern Generation With Internal Chain Masking Hardware . . . . . . . . . . . . . . . . . . . . . . . 146
Updating Scan Pins for Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Verification of the EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Design Rules Checking (DRC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Reducing Serial EDT Chain Test Simulation Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Post-Processing of EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Simulation of the Generated Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Preparation for Test Pattern Generation

To prepare for EDT pattern generation, check that EDT is on, and configure the tool the same as
when you created the EDT logic. For example, if you create the EDT logic with one scan
channel, you must generate test patterns for circuitry with one channel.
Note
You can reuse uncompressed ATPG dofiles, with the addition of some EDT-specific
commands, to generate compressed patterns with the same test coverage as the original
uncompressed patterns. You cannot directly reuse pre-computed existing ATPG patterns.
DRC violations occur if you attempt to generate patterns for a different number of scan channels
than what the EDT logic is configured for.
You must also add scan chains in the same order they were added to the EDT logic—see “Scan
Chain Handling” on page 139 and “IJTAG Mapping” on page 138.
The report_scan_chains command lists the scan chains in the same order they were added
originally.
Compared to when you generated uncompressed test patterns with the scan-inserted core design
(see “ATPG Baseline Generation” on page 63), there are certain differences in the tool setup.
One of the differences arises because in the Pattern Generation phase you need to set up the
patterns to operate the EDT logic. This is done by exercising the EDT clock, update and bypass
(if present) control signals as illustrated in Figure 6-1.
Figure 6-1. Sample EDT Test Procedure Waveforms
This figure illustrates how the tool creates the EDT events automatically. Prior to each scan
load, the EDT logic needs to be reset. This is done by pulsing the EDT clock once while EDT
update is high.
During shifting, the EDT clock should be pulsed together with the scan clock(s). In Figure 6-1,
both scan enable and EDT update are shown as 0 during the capture cycle. These two signals
can have any value during capture; they do not have to be constrained. On the other hand, the
EDT clock must be 0 during the capture cycle.
On the command line or in a dofile, you must do the following:
• Identify the EDT clock signal as a clock and constrain it to the off-state (0) during the
capture cycle. This ensures the tool does not pulse it during the capture cycle.
• Use the -Internal option with the add_scan_chains command to define the compressed
scan chains as internal, as opposed to external channels. This definition is different from
the definition you used to create the EDT logic because the scan chains are now
connected to internal nodes of the design and not to primary inputs and outputs. Also,
scan_in and scan_out are internal nodes, not primary inputs or outputs.
• Uncompressed scan chains are chains not defined with the add_scan_chains command
when setting up the EDT logic and whose scan inputs and outputs are primary inputs and
outputs. If your design includes uncompressed scan chains, you must define each
uncompressed scan chain using the add_scan_chains command without the -Internal
switch during test pattern generation.
• If you add levels of hierarchy (due, for example, to boundary scan or I/O pads), revise
the pathnames to the internal scan pins listed in the generated dofile. An example dofile
with this modification is shown “Modification of the Dofile and Procedure File for
Boundary Scan” on page 245.
EDT Pattern Generation Overview
EDT Pattern Generation Overview

After the EDT IP core is generated and embedded in the design, you use the TCD file to
perform connectivity extraction and pattern generation.
The following sections discuss best practices and usage considerations for EDT pattern
generation:
IJTAG Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Scan Chain Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
IJTAG Mapping
By default when using an EDT IP TCD file to configure EDT, Tessent Shell uses IJTAG to
configure the EDT IP static signals such as edt_bypass. IJTAG mapping uses the IJTAG
infrastructure to retarget setup values through any IJTAG network.
The EDT static signals are those that need to be configured only once at the start of the session
and are then held constant. In contrast, EDT signals such as edt_update change per pattern and
consequently must be controlled directly from a port.
If you provide the top-level ICL and PDL (EDT core) files, the tool maps and configures the
EDT IP during test setup. Using IJTAG provides the most automation, but is not mandatory if
you setup the EDT IP manually for each mode. IJTAG also provides the ability to map all the
way to the top through the TAP controller and TDRs.
IJTAG mapping is used under the following circumstances:
• The ICL for the current design is available. This is checked by R10 DRC rule.
• The ICL includes an ICL module matching the EDT IP instrument the tools is
configuring. This is checked by R11 DRC rule.
• The EDT IP instrument “setup” iProc is available. This is checked by R13 DRC rule.
The ICL module name must match the instrument name stored in the TCD file.
You can turn off IJTAG by running the following command in Tessent Shell:
set_procedure_retargeting_options -ijtag off
If you turn off IJTAG-based mapping of static signals, then either those static signals need to be
driven directly by ports, or you must provide a test_setup procedure that configures the static
signals to the correct values. For more information, refer to the Tessent IJTAG User’s Manual.
Scan Chain Handling
Scan Chain Handling

The EDT pattern generation flow with a TCD file automates scan chain handling.
If you do not specify any EDT instrument instance scan chains, then the tool automatically adds
all the required EDT instrument instance scan chains. In other words, you can avoid explicitly
adding the compressed scan chains using the add_scan_chains command. In this case, Tessent
Shell automatically adds the scan chain definitions for the EDT IP instances when the tool
transitions from Setup to Analysis system mode.
In some cases, however, scan chains may need to be added during setup mode if there are other
setup-mode commands that need to reference the scan chain by name. In this case, the tool
automatically matches (binds) the scan chains with the EDT IP instance(s) to which they are
connected, and, by extension, no longer adds scan chain definitions for EDT IP instances for
which you have defined scan chains. You can specify scan chains manually, but you must
specify all of the scan chains needed and add all of the chains for the EDT controller. See
“Manual Scan Chain Definition” below.
Automated Scan Chain Definition

By default, you are not required to add scan chains. After you have loaded the EDT IP core-
inserted design and the TCD file, Tessent Shell automatically adds scan chains based on the
EDT IP configuration.
Manual Scan Chain Definition

You can manually provide internal scan chains. The tool detects which scan chains can be used
for instrument binding by assuming the first <N> scan chains (number defined during IP
creation) are correctly assigned to the EDT block. In contrast to the dofile-based flow, the
automated scan chains binding does not require the chains to be in the correct order as the tool
fixes the order once the proper binding is determined.
Top-Level Test Procedure File

At a minimum, a test procedure file that contains load_unload and shift procedures for the scan
chains is needed. If top-level uncompressed scan chains area used, then you must define these
using the add_scan_groups and add_scan_chains commands.
If there are no top-level chains, then you must set the test procedure file using with
set_procfile_name command because no test procedure file has been specified with the
add_scan_group command.
Core Instance Parameters

When using a TCD file in the EDT pattern generation context in Tessent Shell, you can define
core instance parameter values to automatically configure the EDT logic. These parameters are
a superset of the EDT IP setup PDL procedure and can be changed for an EDT IP instance after
the hardware has been created. These parameters are used in EDT, LPCT, and OCC.
To modify these parameters, use the following option to the add_core_instances command:
add_core_instances -core <core_name> ... -parameter_values {<parameter_list>}
where the <parameter_list> can include parameters from Table 6-1.

Table 6-1. Core Instance Parameters and Values by Instrument
Instrument Parameter Value Description
Type
EDT edt_bypass on | off Defines whether the EDT is
The default is off. used in bypass mode. See
Compression Bypass Logic
for more information on the
parameter and bypass in
general.
edt_configuration A string that is the Defines which compression
name of the configuration is used by the
configuration specified EDT. See Dual
during IP Compression
creation.When used Configurations for more
with the information on compression
DFTSpecification flow configurations.
and the
HighCompressionConfi
guration wrapper, there
are only two valid
values:
low_compression |
high_compression
The default is
low_compression
edt_low_power_shift_en on | off Defines whether the EDT is
The default value is used in low power shift
based on the EDT IP mode. See Power Controller
generation time user- Logic for more information
defined power on
controller status. edt_low_power_shift_en.
Table 6-1. Core Instance Parameters and Values by Instrument (cont.)

Type
EDT (cont.) edt_single_bypass_chain on | off Defines whether the EDT is
The default is off. used in single bypass mode.
See Dual Bypass
Configurations for more
information on
edt_single_bypass_chain.
used_input_channels integer Defines how many input
The default value is the channels should be used by
maximum available the EDT. See the
input channels. description for
used_input_channels in the
set_edt_options command
arguments in the Tessent
Shell Reference Manual.
tessent_chain_masking on | off | auto Defines if Hybrid TK/
The default is auto. LBIST chain masking
should be used. The default
value of “auto” is on for
LBIST and off for EDT. See
Pattern Generation With
Internal Chain Masking
Hardware for more
information.

Type
OCC capture_window_size integer Specifies the maximum
integer The default value is the number of clock pulses
maximum size during capture cycle. This
supported by the OCC value must not exceed the
instance. registers created during IP
creation.
By default, the tool creates
OCC able to pulse up to
four times between scan
loads, but you may not need
to use them all. For example
you are generating
transition patterns and have
minimal non-scan logic
such that you only need to
pulse clocks twice. Set this
parameter to 2. This cuts the
number of OCC cells in half
and therefore the number of
bits that need to be encoded
during pattern generation.
When the OCC chains are
driven by EDT, you free up
encoding capacity to be
used for the generated tests
and may reduce pattern
count.
fast_capture_mode on | off Defines whether the fast
The default is off. capture clock is used during
capture. See Clock Control
Operation Modes in the
Tessent Scan and ATPG
User’s Manual for
information on this
parameter.
parent_mode on | off Defines whether the OCC is
The default is off. used in parent mode.When
the default off is used, the
OCC is used in standard
mode. See The Parent OCC
section in the Tessent Scan
and ATPG User’s Manual
for more information on this
parameter.
Used Input Channels

Type
LPCT reset_control on | off Controls the value being
The default is off. loaded into the LPCT
Type-3 reset control cell.
See Type 3 - LPCT
Controller-Generated Scan
Enable.
scan_en_control on | off Controls the value being
The default is off. loaded into the LPCT
Type-3 scan enable control
cell. See Type 3 - LPCT
Controller-Generated Scan
Enable.
A given parameter is only available for an EDT IP instance if that EDT IP module was created
with the capability set by the parameter. For example, an EDT IP instance only has the
edt_configuration parameter available if it was created to support dual EDT configurations.
You must specify these parameters before going to Analysis mode and generating any patterns.

Pattern Generation With Internal Chain Masking Hardware . . . . . . . . . . . . . . . . . . . . 146
Used Input Channels

You can configure the EDT IP to use a subset of the input channels. For example, you might
generate the EDT IP to support some number of input channels, but then when the IP or core is
embedded into the design, only a subset of the channels can be driven due to scan port
limitations. This is especially useful for channel sharing.
To configure the input channels, you use the used_input_channels EDT parameter. This
parameter enables you to indicate to the tool that the unused channels have been tied off. The
used_input_channels EDT parameter specifies the number of input channels to the EDT IP that
can be used during pattern generation. The remaining channels, which must be data-only, must
be tied off to 0 by user-created hardware. Data-only input channels are channels that do not
include any control data such as Xpress masking or low-power control bits. When the EDT IP is
created with the set_edt_options -separate_control_data_channels on command or with the
basic compactor, some or all of the channels are data-only.
You can specify a value for this parameter using either of the following commands:
• add_core_instances — Used to define an instance of the EDT IP that has been

instantiated in the design and needs to be used in the current mode.
Used Input Channels
• set_core_instance_parameters — Used to change parameters of a core instance that has

already been defined using the add_core_instances command.
The following usage conditions apply:
• To use this switch, you must set the following in the IP Creation Phase:
set_edt_options -separate_control_data_channel ON
The only exception is if you are using the basic compactor and no low-power controller.
• Only data channels with highest channel indexes can become unused. For example, an
EDT block has one control channel (channel1) and three data channels (channel2,
channel3, channel4). If you want to only use 3 input channels, you can only tie channel4
to “0”. If you want to only use 2 input channels, you can only tie both channel 3 and
channel4 to “0”. You must have at least one data channel.
• If the unused input channels are connected to top-level primary inputs, patterns at these
pins must hold at “0”s. This can be accomplished by constraining the unused input
channels using the add_input_constraints command:
add_input_constraints XXX -C0
or
add_input_constraints XXX -C1 (if there is an inversion between the tied pinand
the EDT channel input)
Otherwise, the tool issues DRC violations during system mode transition.
• If the unused input channels are driven by internal signals, these channels must be tied
off to “0” to ensure that “0”s are injected into the decompressor from these unused
channels.
Figure 6-2 shows an EDT IP logic block with four input channels nested within a higher-level
block. In the EDT flow using TCD files, you can tie these used input channels to 0 (zero) and
reduce the number of input channels.
Used Input Channels
Figure 6-2. Used Input Channels Example
Example 1
Report all of the EDT parameters and their values that were specified when the core instance
was added:
SETUP> report_core_instance_parameters -mod piccpu_maxlen16_1_edt

Core instance 'core_1/piccpu_maxlen16_1_edt_i' (core
'piccpu_maxlen16_1_edt', instrument type 'edt')
----------------------------------------------
Parameter Name Parameter Value Legal Override Values

------------------------- --------------- ---------------------
edt_bypass off off, on
edt_configuration low high, low
edt_low_power_shift_en on off, on
used_input_channels 4 2..4
Example 2
Reports the parameters available for an EDT IP module, but not specific to how a given instance
of this module was configured
SETUP> report_core_parameters -cores piccpu_maxlen16_1_edt
Pattern Generation With Internal Chain Masking Hardware
Core 'piccpu_maxlen16_1_edt' (instrument type 'edt')

----------------------------
Parameter Name Default Value Legal Values

------------------------- ------------- ------------
edt_bypass off off, on
edt_configuration high, low
edt_low_power_shift_en on off, on
used_input_channels 4 2..4
Pattern Generation With Internal Chain Masking

Hardware
In this mode the masking hardware is provided within the Hybrid TK/LBIST controller.
The internal masking logic is capable of masking scan chains with constant unload value of “0”
(zero). Consequently, there is no need for you to manually provide the scan chain definitions.
You must, however, enable the internal masking by setting the EDT IP parameter
tessent_chain_masking to “on” for EDT. (The default “auto” value for tessent_chain_masking
is on for LBIST and off for EDT.) You must also specify which chains should be masked by
using the add_chain_masks command with the -instance switch. Additionally, you must provide
the block chain index of the chains and whether the chains should be traced by specifying
-used_chains ON or -used_chains OFF to the add_core_instances command.
Regardless of the tracing mode, the specified chains are masked with a constant unload value of
0.
Example
add_core_instances -core piccpu_maxlen16_3 \
-instances my_core/edt_logic_top_1 \
-parameter_values {tessent_chain_masking on}
add_chain_masks -instances my_core/edt_logic_top_1\

-block_chain_index_list {1} -used_chains on
// chain is masked and tool traces it
add_chain_masks -instances my_core/edt_logic_top_1 \

-block_chain_index_list {2} -used_chains off
// chain is masked and tool does not trace it
Updating Scan Pins for Test Pattern

Generation
EDT Finder automatically finds EDT logic and updated scan pin information for test pattern
generation. EDT Finder identifies the EDT logic contained in the gate-level netlist and updates
the I/O pins associated with the scan chains.
Updating Scan Pins for Test Pattern Generation
Note
EDT Finder is enabled by default (“set_edt_finder on”). If you have turned off EDT Finder,
you must manually update the scan pin information that has changed since the EDT logic
was generated.
Prerequisites
• Gate-level Verilog netlist or flat model containing EDT logic.
Note
EDT Finder must be enabled before any internal scan chains are added and saved to
the flat model. Otherwise, the flat model cannot be used with the EDT Finder in
subsequent sessions.
Procedure

read_cell_library my_lib.atpg
3. Set up for test pattern generation as needed. For more information, see “Preparation for
Test Pattern Generation” on page 135.
4. Read the core-level TCD files using the read_core_descriptions command.
5. Identify the core instances using the add_core_instances command.
6. Specify compressed and uncompressed chains, if any.
7. Exit setup mode. For example:
The EDT logic and internal scan chain inputs are identified, scan chains are traced, and
DRC is run.
8. Correct any DRC violations.
For information on DRCs related to the EDT Finder command, see EDT Finder (F
Rules) in the Tessent Shell Reference Manual.
9. Report the EDT Finder results. For example:
report_edt_finder -decompressors
// id #bits #inputs #chains EDT block type

// ------------------------------------------
// 1 16 4 28 m1_28x16 active
// 2 16 4 4 m2_4x32 active
// 3 16 4 50 m3_50x187 active
// 4 10 1 8 m4_8x16 active
All active decompressors are reported. For more information on reporting EDT Finder
results, see the report_edt_finder command.
10. Generate and save test patterns. For more information, see “Generating Patterns” on
page 155.
Examples
The following example demonstrates a modular design. After you have generated a TCD file for
each of the cores in your design using the write_core_description command, you map the cores
to the chip level using the core TCD files, add any additional scan logic, and finally generate
patterns for the entire design.
# Set the proper context for TCD flow and subsequent ATPG
set_context pattern -scan
# Read cell library (library file)

read_cell_library technology.tcelllib
# Read the top-level netlist and all core-level netlists

read_verilog generated_1_edt_top_gate.vg generated_2_edt_top_gate.vg \
generated_top_edt_top_gate.vg
# Specify the top level of design for all subsequent commands

set_current_design
# Read all core description files

read_core_descriptions piccpu_1.tcd
read_core_descriptions piccpu_2.tcd
read_core_descriptions small_core.tcd
# Bind core descriptions to core instances

add_core_instances -instance core1_inst -core piccpu_1
add_core_instances -instance core2_inst -core piccpu_2
add_core_instances -instance core3_inst -core small_core
# Specify top-level compressed chains and EDT

dofile generated_top_edt.dofile
# Specify top-level uncompressed chains

add_scan_chains top_chain_1 grp1 top_scan_in_3 top_scan_out_3
add_scan_chains top_chain_2 grp1 top_scan_in_4 top_scan_out_4
# Report instance bindings

report_core_instances
# Change to analysis mode

# Create patterns
create_patterns
# Write patterns
write_patterns top_patts.stil -stil -replace
# Report procedures used to map the core to the top level (optional)
report_procedures
Verification of the EDT Logic
Verification of the EDT Logic

Two mechanisms are used to verify that the EDT logic works properly: design rules checking
(DRC) and enhanced chain and EDT logic (chain+EDT logic) test.
Design Rules Checking (DRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Reducing Serial EDT Chain Test Simulation Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Design Rules Checking (DRC)

Several K DRCs verify that the EDT logic operates correctly. F rules also verify the EDT logic
(unless you have turned off EDT Finder).
The tool provides the most complete information about violations of these rules when you have
preserved the EDT logic structure through synthesis. Following is a brief summary of just the K
rules that verify operation of the EDT logic:
• K19 — Simulates the decompressor netlist and performs diagnostic checks if a

simulation-emulation mismatch occurs.
• K20 — Identifies the number of pipeline stages within the compactors, based on
simulation.
• K22 — Simulates the compactor netlist and performs diagnostic checks if a simulation-
emulation mismatch occurs.
For detailed descriptions of all of the EDT design rules (K and F rules) that are checked during
DRC, refer to “Design Rule Checking” in the Tessent Shell Reference Manual.
EDT Logic and Chain Testing

In addition to performing DRC verification of the EDT logic, the tool saves, as part of the
pattern set, an EDT logic and chain test. This test consists of several scan patterns that verify
correct operation of the EDT logic and the scan chains when faults are added on the core or on
the entire design. This test is necessary because the EDT logic is not the standard scan-based
circuitry that traditional chain test patterns are designed for. The EDT logic and chain test helps
in debugging simulation mismatches and guarantees very high test coverage of the EDT logic.
You can use the following equation to predict the number of additional chain test patterns the
tool generates to test the EDT logic. (In this equation, ceil indicates the ceiling function that
rounds a fraction to the next highest integer.) Note, this equation provides a lower bound; the
actual number may be higher.
How it Works
To better understand the enhanced chain test, you need to understand how the masking logic in
the compactor works. Included in every EDT pattern are mask codes that are uncompressed and
shifted into a mask shift register as the pattern data is shifted into the scan chains. Once a
pattern’s mask codes are in the mask shift register, they are parallel loaded into a hold register
that places the bit values on the inputs to a decoder. Figure 6-3 shows a conceptual view of the
decoder circuitry for a six chains/one channel configuration.
The decoder basically has a classic binary decoder within it and some OR gates. The classic
decoder decodes its n inputs to one-hot out of 2n outputs. The 2n outputs fall into one of two
groups: the “used” group or the “unused” group. (Unless the number of scan chains exactly
equals 2n, there is always at least one unused output.)
Figure 6-3. Example Decoder Circuitry for Six Scan Chains and One Channel
Each output in the used group is AND’d with one scan chain output. For a masked pattern, the
decoder typically places a high on one of the used outputs, enabling one AND gate to pass its
chain’s output for observation.
The decoder also has a single bit control input provided by the edt_mask signal. Unused outputs
of the classic decoder are OR’d together and the result is OR’d with this control bit. If any of the
OR’d signals is high, the output of the OR function is high and indicates the pattern is a non-
masking pattern. This OR output is OR’d with each “used” output, so that, for a non-masking
pattern, all the AND gates pass their chain’s outputs for observation.
The code scanned into the mask shift register for each channel of a multiple channel design
determines the chain(s) observed for each channel. If the code scanned in for a channel is a non-
masking code, that channel’s chains are all observed. If a channel’s code is a masking code,
usually only one of the chains for that channel is observed. The chain test essentially tests for all
possible codes plus the edt_mask control bit.
The following example illustrates EDT logic and chain test for a 10X configuration. The default
behavior is to generate 1-hot masking patterns and non-masking patterns. You can control this
with the “set_chain_test -type” command and switch.
The tool can potentially produce four types of masking and non-masking patterns:
• Masking patterns, with control bit set to 1, where only one chain is observed per
channel, due to “used” codes for each channel (1-hot masking patterns). (Produced by
default.)
• Masking patterns, with control bit set to 1, where all chains are observed due to
“unused” codes.
• Non-masking patterns, with control bit set to 0, that observe all chains. (Produced by
default.)
• XOR masking patterns, with control bit set to 0, that observe a set of chains.
You can clearly see the pattern types in the ASCII patterns. For a masking pattern, if the
scanned-in code corresponding to a channel is a “used” code, only one of that channel’s chains
has binary expected values. All other chains in that channel have X expected values. To see an
example of a masked ASCII pattern, refer to “Understanding Scan Chain Masking in the
Compactor” on page 285.
So, depending on which chain test is failing, it is possible to deduce which chain might be
causing problems. If a failure occurred for any of the 1-hot masking patterns, you could
immediately map it back to the failing chain and, based on the cycle information, to a failing
cell. If only a non-masking pattern or a masking pattern with “unused” codes failed, then
mapping is trickier. But in this case, most likely masking patterns would fail as well.
Optionally, you can shift in custom chain sequences to the current chain test by specifying the
“set_chain_test -sequence” command. For more information, see the set_chain_test command
in the Tessent Shell Reference Manual.
Controlling the edt_update Signal for Load_Unload

When the tool generates chain test patterns, it adds an extra cycle to the end of the shift cycles
before the load_unload procedure when neither the edt_clock or system clock is pulsed. This
Reducing Serial EDT Chain Test Simulation Runtime
“dead” cycle guarantees the edt_update signal goes high during load_unload regardless of how
you choose to control the edt_update signal.
For example, if you do not explicitly force edt_update high during load_unload because it has a
C1 pin constraint, the STIL pattern file keeps edt_update low during load_unload unless the
extra cycle is specified.
You can choose to remove this cycle from the pattern file using “set_chain_test
-suppress_capture_cycle on”. However, you should use CAUTION when using this command
option. If you remove the extra cycle and do not explicitly force edt_update high in the
load_unload procedure, the pattern file is incorrect and edt_update is low during load_unload.
Coverage for EDT Logic and Chain Test

Experiments performed by Tessent engineers using sequential fault simulation demonstrate that
test coverage for the EDT logic with the enhanced chain test is nearly 100% when the EDT
logic does not include bypass logic (essentially multiplexers that bypass the decompressor and
compactor). Test coverage declines to just above 94% when the EDT logic includes bypass
logic. This is because the EDT chain test does not test the bypass mode input of each bypass
multiplexer (edt_bypass is kept constant in EDT mode during the chain test).
Note
99+% coverage can be achieved in any event by including a bypass mode chain test (the
standard chain test).
The size of the chain test pattern set depends on the configuration of the EDT logic and the
specific design. Typically, about 18 chain test patterns are required when you approach 10X
compression.
Reducing Serial EDT Chain Test Simulation

Runtime
You can simulate a small subset of the chain test patterns serially.
If you are not using and enabling the low-power decompressor, you can simply save one non-
masking pattern as shown here:
set_chain_test -type nomask

write_patterns pattern_filename -pattern_sets chain -serial -end 0
If you are using a low-power decompressor, it is safest to run all non-masking patterns (which is
still a small subset of all chain patterns) as shown here:
set_chain_test -type nomask

write_patterns pattern_filename -pattern_sets chain -serial
Reducing Serial EDT Chain Test Simulation Runtime
For more information, see the set_chain_test command in the Tessent Shell Reference Manual.
Adding Faults on the Core Only is Recommended

When you generate patterns, if you add faults on the entire design, the tool tries to target faults
in the EDT logic. Traditional scan patterns can probably detect most EDT logic faults. But
because EDT logic fault detection cannot be serially simulated, the tool conservatively does not
give credit for them. This results in a relatively high number of undetected faults in the EDT
logic being included in the calculation of test coverage. You, therefore, see a lower reported test
coverage than is actually the case.
The EDT logic and chain test targets faults in the EDT logic. The tool always performs the this
test, so adding faults on the entire design is not necessary in order to get EDT logic test
coverage. To avoid false test coverage reports, the best practice is to add faults on the core only.
Test Pattern Generation

The compression technology supports all of the pattern functionality in uncompressed ATPG,
with the exception of MacroTest and random patterns. This includes combinational, clock-
sequential (including patterns with multiple scan loads), and RAM sequential patterns. It also
includes all the fault types.
See “EDT Aborted Fault Analysis” on page 291 for additional considerations.

Generating Patterns
Use this procedure to load the design information including the TCD and generate patterns.
Prerequisites
The design containing the EDT IP core must be synthesized.
Procedure
1. Invoke Tessent Shell from a Linux shell using the following syntax:
% tessent -shell
The tool’s system mode defaults to Setup mode after invocation.

2. With the set_context command, change the context to test pattern generation (patterns
-scan) as follows:
3. Read the design containing the EDT IP using the read_verilog command. For example:
SETUP> read_verilog created_cpu_edt.v
4. Read the library using the read_cell_library command. For example:

SETUP> read_cell_library adk.tcelllib
5. Designate the current design using the set_current_design command. For example:
SETUP> set_current_design
6. Read the TCD file for EDT IP using the read_core_descriptions command. For example:
Compression Optimization
7. Define parameter values to automatically configure the EDT logic using the
add_core_instances command. For example:
SETUP> add_core_instances -core cpu_edt -modules cpu_edt \

-parameter_values {edt_bypass off}
8. Add top-level clocks driving the scan changes using the add_clocks command.
9. Provide the top-level test procedure file using the set_procfile_name command. For
example:
Refer to “Scan Chain Handling” on page 139 for more information.

10. Change the system mode to Analysis using the set_system_mode command as follows:
The mode change runs the design rule checks.

11. Create the EDT patterns using the create_patterns command as follows:
12. Optionally write out the core description corresponding to the current chip level using
the write_core_description command. For example:
ANALYSIS> write_core_description cpu_core_final.tcd -replace
13. Save the patterns using the write_patterns command:

ANALYSIS> write_patterns core_level_patterns.v -verilog
14. Exit Tessent Shell.

ANALYSIS> exit
Results
The tool writes the patterns to the file you specified with the write_patterns command.
Compression Optimization
You can do a number of things to ensure maximum compression: limit observable Xs and use
dynamic compaction.
Using Dynamic Compaction

You should use dynamic compaction during ATPG if your primary objective is a compact
pattern set. Dynamic compaction helps achieve a significantly more compact pattern set, which
is the ultimate goal of using EDT. Because the two compression methods are largely
independent of each other, you can use dynamic compaction and EDT concurrently. Try to use
Saving of the Patterns
create_patterns for the smallest pattern set, as it runs a good ATPG compression flow that is
optimal for most situations.
Note
For circuits where dynamic compaction is very time-consuming, you may prefer to generate
patterns without dynamic compaction. The test set that is generated is not the most compact,
but it is typically more compact than the test set generated by traditional ATPG with dynamic
compaction. And it is usually generated in much less time.
Saving of the Patterns

Save EDT test patterns in the same way you do in uncompressed ATPG.
For complete information about saving patterns, refer to the write_patterns command in the
Tessent Shell Reference Manual.
Serial Patterns
One important restriction on EDT serial patterns is that the patterns must not be reordered after
they are written. Because the padding data for the shorter scan chains is derived from the scan-
in data of the next pattern, reordering the patterns may invalidate the computed scan-out data.
For more detailed information on pattern reordering, refer to “About Reordering Patterns” on
page 290.
Parallel Patterns
Because parallel simulation patterns force and observe the uncompressed data directly on the
scan cells, they have to be written by the EDT technology that understands and emulates the
EDT logic.
Some ASIC vendors write out parallel WGL patterns, and then convert them to parallel
simulation patterns using their own tools. This is not possible with default EDT patterns, as they
provide only scan channel data, not scan chain data. To convert these patterns to parallel
simulation patterns, a tool must understand and emulate the EDT logic.
There is an optional switch, -Edt_internal, you can use with the write_patterns command to
write parallel EDT patterns with respect to the core scan chains. You can write these patterns in
tester or ASCII format and use them to produce parallel simulation patterns as described in the
next section.
EDT Internal Patterns

The optional -Edt_internal switch to the write_patterns command enables you to save parallel
patterns as EDT internal patterns. These are tester or ASCII formatted EDT patterns that the
tool writes with respect to the core scan chains instead of with respect to the top-level scan
channel PIs and POs. These patterns contain the core scan chain force and observe data with the
Post-Processing of EDT Patterns
exception that they have X expected values for cells that would not be observed on the output of
the spatial compactor due to X blocking or scan chain masking. X blocking and scan chain
masking are explained in “Understanding Scan Chain Masking in the Compactor” on page 285.
Also, of course, the scan chain force and observe points are internal nodes, not top-level PIs and
POs. Because they provide data with respect to the core scan chains, EDT internal patterns can
be converted into parallel simulation patterns.
Note
The number of scan chain inputs and outputs in EDT internal patterns corresponds to the
number of scan chains in the design core, not the number of top-level scan channels. Also,
the apparent length of the chains, as measured by the number of shifts required to load each
pattern, is shorter because the extra shift cycles that occur in normal EDT patterns for the EDT
circuitry are unnecessary.
Post-Processing of EDT Patterns

Sometimes there is a need to process patterns after they are written to a file. Post-processing
might be needed, for example, to control on-chip phase-locked loops (PLLs). Scan pattern post-
processing requires access to the uncompressed patterns. The tool, however, writes patterns in
EDT-compressed format, at which point it is too late to make any changes. Traditional post-
processing, therefore, is not feasible with EDT patterns.
Note
An exception is parallel tester or ASCII patterns you write out as EDT internal patterns.
Using your own post-processing tools, you can convert these patterns into parallel
simulation patterns. See “Parallel Patterns” on page 157 for more information.
The compressed ATPG engine must set or constrain any scan cells prior to compressing the
pattern. So it is essential you identify the type of post-processing you typically need and then
translate it into functionality you can specify in the tool as part of your setup for pattern
generation. The compressed ATPG engine can then include it when generating EDT patterns.
Simulation of the Generated Test Patterns

You can verify the test patterns using parallel and serial test benches the same way you would
for normal scan and ATPG. When you simulate serial simulation patterns, you can verify the
correctness of the captured data for the pattern, the chain integrity, and the EDT logic (both the
decompressor and the compactor blocks). When simulation mismatches occur, you can still use
the parallel test bench to debug mismatches that occur during capture. You can use the serial
test bench to debug mismatches related to scan chain integrity and the EDT logic.
To verify that the test patterns and the EDT circuitry operate correctly, you need to serially
simulate the test patterns with full timing. Typically, you would simulate all patterns in parallel
and a sample of the patterns serially. Only the serial patterns exercise the EDT circuitry.
Because simulating patterns serially takes a long time for loading and unloading the scan
chains, be sure to use the “?Sample” switch when you write_patterns for serial simulation. This
is true even though serial patterns simulate faster with EDT than with traditional ATPG due to
the fewer number of shift cycles needed for the shorter internal scan chains. “Design Simulation
With Timing” in the Tessent Scan and ATPG User’s Manual provides useful background
information on the use of this switch. Refer to the write_patterns command description in the
Tessent Shell Reference Manual for usage information.
Note
You must use Tessent Shell to generate parallel simulation patterns. You cannot use a third
party tool to convert parallel WGL patterns to the required format, as you can for traditional
ATPG. This is because parallel simulation patterns for EDT are uncompressed versions of the
compressed EDT patterns applied by the tester to the scan channel inputs. They also contain
EDT-specific modifications to emulate the effect of the compactor.
HDL Simulation Setup

First, set up a work directory for Questa SIM.
../questasim/<platform>/vlib work
Then, compile the simulation library, the scan-inserted netlist, and the simulation test patterns.
Notice that both the parallel and serial patterns are compiled:
../questasim/<platform>/vlog my_parallel_pat.v my_serial_pat.v \

../created_edt_top_gate.v -y my_sim_lib
This compiles the netlist, all necessary library parts, and both the serial and parallel patterns.
Later, if you need to recompile just the patterns, you can use the following command:
../questasim/<platform>/vlog pat_p_edt.v pat_s_edt.v

Running the Simulation
After you have compiled the netlist and the patterns, you can simulate the patterns using the
following commands:
../questasim/<platform>/vsim edt_top_pat_p_edt_v_ctl -do "run -all" \

-l sim_p_edt.log ?c
../questasim/<platform>/vsim edt_top_pat_s_edt_v_ctl -do "run -all" \
-l sim_s_edt.log -c
The “-c” runs the Questa SIM simulator in non-GUI mode.
Chapter 7
Modular Compressed ATPG
Modular Compressed ATPG is the process used to integrate compression into the block-level
design flow. Integrating compression at the block-level is similar to integrating compression at
the top-level, except you create/insert EDT logic into each design block and then, integrate the
blocks into a top-level design and generate test patterns.
Note
In this chapter, an EDT block refers to a design block that contains a full complement of
EDT logic controlling all the scan chains associated with the block.
The modular flow includes one or more of the top-level compressed pattern flows. For
information on these top-level flows, see, “The Compressed Pattern Flows” on page 41 of this
manual.
The Modular Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Understanding Modular Compressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Development of a Block-Level Compression Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Sharing Input Scan Channels on Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Channel Sharing for Non-Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Generating Modular EDT Logic for a Fully Integrated Design . . . . . . . . . . . . . . . . . . . . . 179
Estimating Test Coverage/Pattern Count for EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 180
Legacy ATPG Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
The Modular Flow

The modular flow has five distinct stages and requirements for them.
Requirements
The requirements for the modular flow are:
• Block-level compression strategy

• Gate-level or RTL netlist for each block in the design
• Tessent Scan or other scan insertion tool (optional)
The Modular Flow
• Tessent cell library

• Design Compiler or other synthesis tool
• Questa SIM or other timing simulator
Modular Flow Diagram
Understanding Modular Compressed ATPG
Flow Stage Descriptions
Table 7-1. Modular Flow Stage Descriptions

Stage Description
Integrate EDT logic EDT logic can be integrated into each design block using any of
into each Design the top-level methods described in this document. For more
Block information, see the following sections of this document:
• “Integrating Compression at the RTL Stage” on page 293
• “The Compressed Pattern Flows” on page 41
The first step to using compression in your design flow is
developing a compression strategy. For more information, see
“Generation of Top-Level Test Patterns” on
page 181“Development of a Block-Level Compression Strategy”
on page 165.
Generate Test Test patterns are set up and generated using the top-level netlist,
Patterns test procedure file, and dofile. For more information, see
“Generation of Top-Level Test Patterns” on page 181.
You should also create bypass test patterns for the top-level netlist
at this point. For more information, see “Compression Bypass
Logic” on page 233.

The EDT logic inserted in a design block controls all scan chains within the block.
Figure 7-1 shows an example of a modular design with four EDT blocks. Each EDT block
consists of a design block with integrated EDT logic. The design also contains a separate EDT
block for the top-level glue logic. The top-level glue logic can be tested with EDT logic as
shown or with bypass logic as described in “Compression Bypass Logic” on page 233.
Figure 7-1. Modular Design With Five EDT blocks
Each EDT block has a discrete netlist, dofile, and test procedure file that are integrated together
to form top-level files for test pattern generation.
Development of a Block-Level Compression Strategy
Development of a Block-Level Compression

Strategy
You can create and insert EDT logic into design blocks with any of the methods outlined in this
manual. You can also mix and match methods between blocks.
Reference the following rules and guidelines while developing your compression strategy for
the modular flow:
• Scan Chain Lengths Should Be Balanced — Balanced scan chains yield optimal
compression. Plan the lengths of scan chains inside all blocks in advance so that top-
level (inter-block) scan chain lengths are relatively equal. See “Balancing Scan Chains
Between Blocks” on page 166.
• EDT Logic Names Must Be Unique — When multiple EDT blocks are integrated into
a top-level netlist, all of the EDT logic file names and internal module/instance names
must be unique. See “Creation of EDT Logic Files” on page 98.
• Each EDT Block Must Have a Discrete Set of Scan Chains — Scan chains cannot be
shared between blocks.
• Uncompressed Scan Chains Must be Connected to Top-Level Pins —
Uncompressed scan chains are scan chains not driven by or observed through the EDT
logic. Uncompressed scan chains are supported if the inputs and outputs are connected
directly to top-level pins. Uncompressed scan chains can also share top-level pins. See
“Inclusion of Uncompressed Scan Chains” on page 56.
• Only Certain Control Pins can be Shared with Functional Pins — These pins can be
shared within the same EDT block. See “Functional/EDT Pin Sharing” on page 87.
• Control Signals can be Shared by EDT Blocks — Control signals such as edt_update,
edt_clock, edt_reset, scan_enable and test_en may be shared between EDT blocks; for
example, the edt_update signals from different blocks could be connected to the same
top-level pin.
• Scan Channels Must Have Dedicated Top-Level pins — Only input scan channels
between identical EDT blocks can share top-level pins. See “Sharing Input Scan
Channels on Identical EDT Blocks” on page 166.
• Block-Level Signals Must be Connected in the Top-Level Netlist — This includes
connecting EDT logic signals to I/O pads and inserting any multiplexers needed for
channel output signals shared with functional signals.
• EDT Logic Must be Synthesized and Verified for Each Block — See “Synthesizing
the EDT Logic” on page 123 and “Generating and Verifying Test Patterns” on page 135.
Sharing Input Scan Channels on Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 166
Balancing Scan Chains Between Blocks
Channel Sharing for Non-Identical EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Overview of Channel Sharing Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Compression Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
EDT IP Creation With Separate Control and Data Input Channels . . . . . . . . . . . . . . . . . . 172
Rules for Connecting Input Channels from Cores to Top . . . . . . . . . . . . . . . . . . . . . . . . . 175
Channel Sharing Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Channel Sharing Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Identical EDT Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Generating Modular EDT Logic for a Fully Integrated Design . . . . . . . . . . . . . . . . . . . 179
Estimating Test Coverage/Pattern Count for EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . 180
Legacy ATPG Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Design blocks may contain a large amount of hardware with many internal blocks and many
scan chains, so scan chain balance is very important for generating efficient test patterns. You
should carefully plan the lengths of scan chains inside each design block so that all blocks have
approximately the same scan chain length.
You should target the same compression for every block and apportion available tester channels
according to the relative share of the overall design gate count contained in each block. Use the
following two equations to calculate balanced scan chain lengths across multiple blocks:
Tip
Because different designers may perform scan insertion for different design blocks, it is
important to work together to select a scan chain length target that works for all blocks.
Sharing Input Scan Channels on Identical EDT

Blocks
You can set up identical EDT blocks to share input scan channels and top-level pins when
integrating modular design blocks into a top-level netlist.
Sharing Input Scan Channels on Identical EDT Blocks
When EDT blocks share input scan channels, test patterns are broadcast via shared top-level
pins to all the identical EDT blocks simultaneously. This functionality reduces top-level pin
requirements and increases the compression ratio for the input side of the EDT logic.
The Compression Analyzer in Tessent TestKompress fully supports channel broadcasting and
can be used to assess the effectiveness of channel broadcasting in combination with other
channel configurations. You run compression analysis with channel broadcasting at the top
level of a design that has multiple identical EDT blocks, using the analyze_compression
command.
The following switch has a special meaning for channel broadcasting:
• -Broadcast_all_channels_to_identical_blocks [block1 block2 …] — defines the channel

broadcasting group.
Where [block1 block2 …] must be pre-existing identical EDT blocks.
Requirements
• EDT blocks must be identical as follows:
o Number of input channels and output channels must match
o Input, output, and compactor pipeline stages must match
o Order of scan chains and the number of scan cells in each must match
o Input channel/top-level pin inversions must match
• All corresponding input channels on identical EDT blocks must be shared in the
corresponding order. For example the following channels can be shared:
o input channel 1 of block1
o input channel 1 of block2
o input channel 1 of block3 and so on
Top-Level Dofile Modifications
You need to set up the input channel sharing when the block-level dofiles are integrated into a
top-level dofile. Depending on the application, you can set up the input channel sharing in one
of two ways:
• Make top-level pins equivalent
Sharing Input Scan Channels on Identical EDT Blocks
Use this method when a top-level pin exists for each input channel by defining the pins
for the corresponding input channels on each block as equivalent. For example:
add_edt_blocks core1
set_edt_pins input 1 core1_edt_channels_in1
add_input_constraints -eq core1_edt_channels_in1 \
core2_edt_channels_in1
add_input_constraints -eq core1_edt_channels_in2 \
core2_edt_channels_in2
• Physically share top-level pins

Use this method when top-level pins need to be shared between input channels by
explicitly specifying the top-level pins to be same. For example:
set_edt_pins input 1 edt_channels_in1
During DRC, the blocks that share input channels are reported. As long as the EDT blocks are
identical and the channel sharing is set up properly, EDT DRCs should pass.
Use the report_edt_configurations -All command to display information on the EDT blocks set
up to share input channels.
Channel Sharing for Non-Identical EDT Blocks

This section contains the following information:
Overview of Channel Sharing Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Compression Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
EDT IP Creation With Separate Control and Data Input Channels . . . . . . . . . . . . . . . 172
Rules for Connecting Input Channels from Cores to Top . . . . . . . . . . . . . . . . . . . . . . . . 175
Channel Sharing Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Channel Sharing Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Overview of Channel Sharing Functionality

Identical EDT blocks have exactly the same scan chain and EDT structures. Therefore, you can
generate scan patterns for one block and broadcast the pattern stimuli to the inputs of all
identical blocks.
Tessent tools support pattern stimuli broadcast to identical blocks as described in “Sharing Input
Scan Channels on Identical EDT Blocks” on page 166.
Non-identical EDT blocks cannot share all input channels. Tessent tools also provide support
for using the same channel to drive multiple non-identical EDT blocks.
Channel sharing between non-identical EDT blocks enables you to improve data and time
compression results for most designs that use a modular EDT approach. Specifically, the
following scenarios can gain greater benefits from this feature:
• Designs with a limited number of top-level ports available for scan channel I/O
• Designs with a large pattern increase when comparing a single EDT block at the top
level with multiple EDT blocks across the design
• Designs with a large number of EDT aborted faults due to high chain-to-channel ratios
within individual EDT blocks
Support for channel sharing between non-identical EDT blocks does not have any impact on the
output channels. The EDT hardware created for channel sharing uses existing functionality that
uses dedicated (not shared) output channels.
Channel sharing between non-identical EDT blocks is supported by the compression analysis,
and the standard EDT reporting capability.
You implement channel sharing across non-identical EDT blocks by separating the control and
data input channels when creating the EDT IP. This enables the data channels to be shared
across multiple non-identical blocks.
The default EDT hardware creates control data registers for Xpress compactor masking bits and
low-power control bits (if they exist) in front of each EDT input channel. The diagram in
Figure 7-2 shows how test data (D) loaded into an EDT block is followed by control data for
compactor masking (C) and low-power (LP) data.
Note that the low-power registers always exist when you use the “set_edt_power_controller
Shift Enabled | Disabled” command and switches. There is no low-power register created if you
use the “set_edt_power_controller Shift None” command and switches.
Figure 7-2. Non-Separated Control Data Input Channels
You can create EDT hardware that separates control input channels from data input channels.
The resulting hardware includes several input channels that only load scan test data into each
EDT block, as illustrated in Figure 7-3. By separating the control data that is specific to each
block into dedicated input channels, the scan test data (D) input channels can be shared across
multiple non-identical blocks. (With this option, an EDT block can no longer have only one
input channel; it must have at least one control channel and one data channel.)
Figure 7-3. Separated Control Data Input Channels
Because the broadcast is only permitted to go to multiple non-control input channels, normally
at least one dedicated control channel for each EDT block is still required, except for the special
case in which an EDT block has a basic compactor but does not have a low-power controller.
In order to get the most benefit from input channel sharing, the number of input channels in
each core should be maximized so that you share as many input channels as possible among
multiple non-identical cores and take full advantage of all available top-level data input
channels.
Channel sharing also results in a reduction in overall shift cycles. As shown in Figure 7-3, by
moving the control data to a dedicated channel that is loaded with scan data, no extra shift
cycles are added only for the purpose of masking or low-power control bits. This provides an
additional increase in overall compression of test data and application time.
Also, as shown in Figure 7-3, the input control channels can also load scan test data (D) if the
number of control bits (LPs and Cs) is smaller than the length of the longest scan chain.
Similarly, if a design requires many control bits, the EDT block may require more than one
control channel. The tool determines the appropriate number of control channels based on the
number of masking and low-power control bits and the length of the longest scan chain.
The Compression Analyzer in Tessent TestKompress fully supports channel sharing and can be
used to assess the effectiveness of channel sharing in combination with other channel
configurations.
You run compression analysis with channel sharing at the top level of a design using the
analyze_compression command. The following switches have special meaning for channel
sharing:
• -INPut_channels — Defines the total number of control and data channels for each
block.
• -SHARE_data_channels[block1 block2 …] — Defines the channel sharing group.
• -DATA_and_control_channels[int] — Defines the total number of input channels,
across all blocks, that can be shared among that group.
Optionally, you can direct this command to calculate the required number of input channels by
using it without specifying the total number of input channels.
For example, you can emulate the displayed configuration shown in Figure 7-4 using the
analyze_compression command with the -input_channels and the -share_data_channels
-data_and_control_channel switches.
Figure 7-4. Channel Sharing Example
analyze_compression -edt_block \
Block1 -input_channels 3 -output_channels 1 \
-edt_block Block2 -input_channels 3 -output_channels 1 \
-edt_block Block3 -input_channels 5 -output_channels 1 \
-share_data_channels Block1 Block2 Block3 \
-data_and_control_channels 7
All other analyze_compression command options are also supported, and you can use them to
run various experiments.
EDT IP Creation With Separate Control and Data Input

Channels
The only change you need to make to the EDT IP creation step is to separate the control and
data input channels.
You can create the hardware that supports separate control and data input channels by using the
“set_edt_options -separate_control_data_channels ON” command in setup mode as shown here:
SETUP> set_edt_options -separate_control_data_channels ON
By default, the -separate_control_data_channels is set to OFf. When enabled, the

“-separate_control_data_channels ON” switch also modifies the generated EDT setup dofile to
include information about the separate control and data channels.
Typically, each EDT block needs to have at least one dedicated channel that cannot be shared,
while all others can be shared. The dofiles generated in the EDT IP creation step contain all of
the information needed to fully describe the EDT hardware at each block. You do not need to
make any changes to the pattern generation step.
For an EDT block with at least one of an Xpress compactor or a low-power controller, you must
have at least one dedicated control channel, and none of its control channels can be shared with
other EDT blocks. The only exception to this requirement is an EDT block that has a basic
compactor and does not have a low-power controller; in this case, the block is not required to
have a control channel. The broadcast to shared channels is only permitted for data channels
with no control bits.
Maximizing Block-Level Channels

In order to maximize the benefits of channel sharing, you should maximize the number of input
channels at the core level to take full advantage of all available top-level input channels. For
example, in Figure 7-5, the design has two EDT blocks, each block has four input channels with
mixed control and data on each channel. Clearly, without channel sharing, the design requires
eight input channels at the top-level.
Figure 7-5. Non-Channel Sharing
With channel sharing implemented, as shown in Figure 7-6, the design requires only five input
channels at the top-level, and each block still has four input channels (three data channels are
shared by each core). This implementation mitigates the pin-limitation problem at the top-level,
while maintaining the same bandwidth at the core-level.
Figure 7-6. Channel Sharing Scenario 1
You can optimize input channel sharing by maintaining the same input pin count at the
top-level, while increasing the number of input channels in each core to maximize the number
of input channels shared among multiple non-identical cores.
In this channel sharing configuration, the design still has eight input channels at the top-level, as
shown in Figure 7-7, but each block now has seven input channels (six data channels are shared
by each core); this can improve their bandwidth for each core, and thereby improve encoding
efficiency and reduce the number of patterns.
Figure 7-7. Channel Sharing Scenario 2
Design Rule Checks for Channel Sharing

The K15 DRC verifies that all scan channels and control pins have the proper top-level pins.
Each scan input channel requires a dedicated top-level pin, except for blocks (identical and non-
identical) set up for input channel sharing. The K15 enables one top-level input port to
broadcast to multiple EDT blocks.
For more information on the specific checks performed, see “K15” in the Tessent Shell
Reference Manual.
Separate Control and Data Channels and Dual Compression Configuration

When you use the “set_edt_options -separate_control_data_channels on” command, the tool
attempts to apply the setting to both high and low compression configurations.
If the high compression configuration does not have enough input channels to permit separate
control and data channels, but the low compression configuration does, the tool separates the
control and data channels for the low compression configuration, but not for the high
compression configuration. In this case, the tool issues a warning. For example:
add_edt_block block1
set_edt_options -separate_control_data_channels on
add_edt_configurations high_comp
add_edt_configurations low_comp
// Warning: In configuration 'high_comp', the number of input channels (1)

// is smaller than the required number of control and data
// channels (1 control + 1 data).
// The '-separate_control_data_channels' option has been
// set to 'off' for this configuration.
// Configuration 'low_comp' has separate control and data
// input channels.
If both the high and low compression configurations lack sufficient input channels to provide
separated control and data channels, the tool does not separate the channels for either of the
configurations. For example:
add_edt_block block1
set_edt_options -separate_control_data_channels on
add_edt_configurations high_comp
add_edt_configurations low_comp
// Warning: In configurations 'high_comp' and 'low_comp', of
// EDT block ‘block1’ the numbers of input channels
// (1 and 2 respectively) are smaller than the required
// number of control and data channels (2 control + 1 data).
// The '-separate_control_data_channels' option has been
// set to 'off' for both configurations.
Rules for Connecting Input Channels from Cores to Top

For the non-core mapping for ATPG flow, during EDT IP creation, the control and data
channels for each core are connected to the top-level ports with the command
“set_edt_pins input_channel index [pin_name]”. For the shared data channels, you use the same
port names.
In the core mapping for ATPG flow, you need to integrate the cores to the top level. In either
case, data input channels should be connected based on the following rules:
• Data input channels should be shared so that top-level input channels are broadcast to
EDT blocks.
• The same top-level input channel should not drive data into multiple channels on the
same EDT block.
• Each top-level data input channel is NOT required to drive data into every EDT block.
Different blocks may have a different number of data input channels.
Channel sharing has no impact on how output channels are connected.
Channel Sharing Reporting

The input channels to EDT decompressor can be divided into two categories: control channels
that deliver control data, and data channels that deliver tests. (Note that the control channel may
also be used to deliver a test if it is shorter than the data channels.) When broadcasting to non-
identical blocks, the data channels can share the same inputs, but control channels cannot.
When channel sharing is used, it is desirable to report the channel sharing information. The tool
provides the report_edt_configurations and the “report_edt_pins -Group_by_pin_name”
commands to enable you to report channel sharing information. You can use these commands in
the EDT IP Creation phase and also in the Pattern Generation phase when in either insertion or
analysis mode.
Refer to the examples on the report_edt_configurations command reference page for an

example of how channel sharing information is reported.
Channel Sharing Limitations

The channel sharing functionality has the following limitations:
• Channel sharing is not permitted between EDT input channels and uncompressed chains
inputs.
• Mapping compressed EDT patterns to bypass patterns is not permitted. That is, the
write_patterns -edt_bypass and -edt_single_bypass_chain options are unavailable for
channel sharing.
• All core-level shared channels driven by the same top-level channel port must have the
same number of external pipelining stages and the same input pin inversions.
• The non-overlapping clock setting should be the same for all blocks that are sharing
input pins. That is, the “set_edt_options -pulse_edt_before_shift_clocks” option must be
set the same for all blocks that are sharing input pins.
• When generating bypass uncompressed patterns, the generated patterns mimic Illinois
scan patterns, because the existing hardware is used for bypass patterns, which may
cause coverage drop compared to the normal bypass patterns.
Mixing Channel Sharing for Non-Identical EDT Blocks and Channel Broadcasting for Identical EDT
Mixing Channel Sharing for Non-Identical EDT

Blocks and Channel Broadcasting for Identical EDT
Blocks
You can mix channel sharing and channel broadcasting. The only sharing restriction is that each
non-identical block must have its own dedicated control channel(s). The following sections
present examples of different configurations of channel sharing and channel broadcasting
between non-identical and identical EDT block.
Case 1: Identical Blocks Share Input Channels and Non-Identical Blocks

Have Dedicated Control Channels
In the figure below, two identical blocks (instance 1 and instance 2 of Module A) share all input
channels, and non-identical blocks (instance 1 of Module B and instance 1 of Module C) have
their own dedicated control channels, but can share data channels with all other blocks. In this
configuration, ATPG can run on the top-level of the design.
Figure 7-8. Mixing Channel Sharing and Channel Broadcasting — Case 1
Case 2: Multiple EDT Blocks (Whether Identical or Non-Identical) Inside One

or More Identical Core Instances
It is common to have multiple EDT blocks (whether identical or non-identical) inside a core
instance. You can use channel sharing and channel broadcasting inside this core instance to
optimize access to the blocks in it. At the next level up, you may have multiple instances of
those same cores and may want to broadcast channels to those identical core instances.
The following figure illustrates the general case of channel sharing across non-identical blocks
and channel broadcasting between identical blocks in two identical instances of Core X. You
may only have either channel sharing or channel broadcasting within a single core instance.
Mixing Channel Sharing for Non-Identical EDT Blocks and Channel Broadcasting for Identical EDT
The tool supports both top-level ATPG and pattern retargeting in this case. However, if you are
doing pattern retargeting, you must generate patterns for one core instance and broadcast those
patterns to the multiple identical core instances.
Case 3: Multiple EDT Blocks (Whether Identical or Non-Identical) Inside

Non-Identical Core Instances
The previous figure illustrates channel sharing across non-identical blocks and channel
broadcasting between identical blocks in two identical instances of Core X.
Channel sharing and broadcasting are also permitted across non-identical cores as illustrated in
the following figure. Core X and Core Y are non-identical cores because an instance of Module
B is included in Core X but not included in Core Y. In this case, the tool still supports ATPG at
the top-level. However, pattern retargeting is not permitted because it only supports channel
broadcasting to identical core instances as enforced by the R3 DRC.
Generating Modular EDT Logic for a Fully Integrated Design
Generating Modular EDT Logic for a Fully

Integrated Design
Use this procedure to simultaneously generate modular EDT logic for all blocks within a fully
integrated design. The resulting EDT logic can be set up as multiple instances within the design.
If the integrated design shares top-level channels or requires any form of test scheduling, you
must generate modular EDT logic one block at a time.
The files generated by this procedure support the same capabilities as the block by block
modular flow.
Prerequisites
• The integrated design must be complete and fully functional.
• Each block must have dedicated input and output channels.
Estimating Test Coverage/Pattern Count for EDT Blocks
Procedure
1. Add each EDT block, one at a time, using the add_edt_blocks command.
2. Once an EDT block is added, set up the EDT logic for it with a set_edt_options
command. The set_edt_options command only applies to the current EDT block. EDT
control signals can be shared among blocks.
3. Once all the design blocks are added and set up, enter analysis mode. For more
information, see the set_system_mode command.
4. Enter a write_edt_files command. A composite set of files is created including an RTL
file, a synthesis script, a dofile/testproc file, and a bypass dofile/testproc file. All block-
level EDT pins are automatically connected to the top level.
5. Use this composite set of files to synthesize EDT logic and generate test patterns.
Estimating Test Coverage/Pattern Count for EDT

Blocks
After you create EDT logic for a block, you should use this procedure to get a more realistic
coverage estimate before synthesis.
See “Analyzing Compression” on page 66.
Test coverage reported may be higher than when the EDT block is embedded in the design
because the tool has direct access to the block-level inputs and outputs at this point.
Procedure
1. Constrain all functional inputs to X. For example:
add_input_constraints my_func_in -cx
Where the functional input my_func_in is constrained to X.

2. Mask all functional outputs. For example:
add_output_masks my_func_out1 my_func_out2
Where the two primary outputs my_func_out1 and my_func_out2 are masked.
Note
Constraining inputs to X and masking the outputs produces very conservative
estimates that negatively affect compression because all inputs become X sources
when the CX constraints are added to the pins.
Note
Because final test patterns are generated at the top-level of the design and are
affected by all cores, the final test coverage and pattern count may vary.
Legacy ATPG Flow
Legacy ATPG Flow

This section describes the legacy functionality that enables you to integrate EDT blocks into the
top level and generate top-level test patterns for them. This methodology requires that you
manually generate chip-level test procedures.
You can use the Core Mapping for ATPG functionality that replaces this functionality, and
automatically generates chip-level test procedures for you. For complete information, see “Core
Mapping for ATPG Process Overview” in the Tessent Scan and ATPG User’s Manual.
Note
If you are using the set_edt_mapping command in your dofiles, you should use this legacy
functionality. The set_edt_mapping command and the EDT Mapping functionality have
been superseded by the Core Mapping for ATPG functionality.
Generation of Top-Level Test Patterns

Generating test patterns for the top-level of a modular design is similar to creating test patterns
in the standard flow except that you set one block up at a time.
Note
To generate top-level patterns, you must have a top-level design netlist, dofile and test
procedure file.
You use the following commands to generate test patterns for the top-level of a modular design:
• set_current_edt_block— Applies EDT-specific commands and the add_scan_chains

command to a particular EDT block. Restricting commands in this way enables you to
re-specify the characteristics of an individual block without affecting other parts of the
design.
• report_edt_blocks— Reports on EDT blocks currently defined in Tessent Shell memory.
• delete_edt_blocks— Deletes EDT blocks from Tessent Shell memory.
A few reporting commands also operate on the current EDT block by default, but provide an
-All_blocks switch that enables you to report on the entire design. All other commands
(set_system_mode, create_patterns and report_statistics for example) operate only on the entire
design.
Example
This example demonstrates the commands used to integrate EDT blocks and generate test
patterns. As shown in Figure 7-11, EDT control signals are shared at the top level; each EDT
block is created with the EDT logic and the scan-inserted core inside of a wrapper.
Legacy ATPG Flow
Figure 7-11. Netlist With Two Cores Sharing EDT Control Signals
1. Invoke Tessent Shell, set the context, and read in the design and library.
2. Perform necessary setup and then define scan chains, clocks and EDT logic for the first
block. For example:
// Perform setup.
set_current_design edt_block1
...
// Define scan chains, clocks, and EDT hardware.

add_scan_groups grp1 group1.testproc
...
add_clocks clk1 0
Legacy ATPG Flow
3. Create EDT logic with unique module names based on the core module name for the
first block. For example:
// Create EDT hardware with unique module names.
write_edt_files created1 -replace
4. Delete the design using the delete_design command.

5. Return to setup mode using the set_system_mode command.
6. Read in the second block and repeat steps 2 and 3.
7. Using the DC script output during the EDT logic creation, synthesize the EDT logic for
each block.
8. Verify that the EDT logic is instantiated properly by generating and simulating test
patterns for each of the resultant gate-level netlists. This is done using the test bench
created during test pattern generation and a timing-based simulator.
9. Verify that the block-level scan chains are balanced.
10. Create the top-level netlist, dofile, and test procedure files. The following example
shows the top-level dofile. For more information, see Generation of Top-Level Test
Patterns.
Commands and options specific to modular compressed ATPG are shown in bold font.
Legacy ATPG Flow
// Define the top-level test procedure file to be used by all

// blocks.
add_scan_groups grp1 top_level.testproc
// Define top-level clocks and pin constraints here.

add_clocks...
add_read_controls...
add_write_controls...
add_input_constraints...
...
// Activate automatic mapping of commands from the block-level

// dofiles.
set_edt_mapping on
// Define the block tag (this is an arbitrary name) for an EDT block
// and automatically set it as the current EDT block.
add_edt_blocks cpu1
// Define the block by executing the commands in its block-level

// dofile.
dofile cpu1_edt.dofile
// Repeat the preceding procedure for another block.

add_edt_blocks cpu2
dofile cpu2_edt.dofile
// Once all EDT blocks are defined, create_patterns that use all the
// blocks simultaneously and generate patterns that target faults in
// the entire design.
// Flatten the design, run DRCs.

// Verify the EDT configuration.

report_edt_configurations -all_blocks
// Generate patterns.
create_patterns
// Create reports.
report_statistics
report_scan_volume
write_patterns...
exit
Modular Flow Command Reference

Modular Compressed ATPG Command Summary describes commands used for the modular
design flow.
Table 7-2. Modular Compressed ATPG Command Summary
Command Description
add_edt_blocks Creates a name identifier for an EDT block instantiated in a
netlist.
Legacy ATPG Flow
Table 7-2. Modular Compressed ATPG Command Summary (cont.)

Command Description
delete_edt_blocks Removes the specified EDT block(s) from the internal database.
report_edt_blocks Displays current user-defined EDT block names.
report_edt_configurations Displays the configuration of the EDT logic.
report_edt_instances Displays the instance pathnames of the top-level EDT logic,
decompressor, and compactor.
set_current_edt_block Directs the tool to apply subsequent commands only to a
particular EDT block, not globally.
set_edt_instances Specifies the instance name or instance pathname of the design
block that contains the EDT logic for DRC.
set_edt_mapping Enables the automatic mapping necessary for block-level dofiles
to be reused for top-level pattern creation.
write_design If the design has been modified after executing the
write_edt_files, you must update the netlist using this command.
write_edt_files Writes all the EDT logic files required to implement the EDT
technology in a design.
Legacy ATPG Flow
Chapter 8
Compressed ATPG Advanced Features
Additional advanced features are available for compressed ATPG.
Low-Power Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Low-Power Shift. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Low Pin Count Test Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
LPCT Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
LPCT Controller Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Compression Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Generating EDT Logic When Bypass Logic Is Defined in the Netlist. . . . . . . . . . . . . . . . 234
Generation of Identical EDT and Bypass Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Use of Bypass Patterns in Uncompressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Creating Bypass Test Patterns in Uncompressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Uncompressed ATPG (External Flow) and Boundary Scan . . . . . . . . . . . . . . . . . . . . . . 243
Boundary Scan Coexisting With EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Drive Compressed ATPG With the TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Use of Pipeline Stages in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Use of Pipeline Stages Between Pads and Channel Inputs or Outputs. . . . . . . . . . . . . . 250
Clocks for Channel Output Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Input Channel Pipelines Must Hold Their Value During Capture . . . . . . . . . . . . . . . . . . . 253
DRC for Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
DRC for Channel Output Pipelining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Input/Output Pipeline Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Change Edge Behavior in Bypass and EDT Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Understanding Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Lockup Cell Analysis for Bypass Lockup Cells Not Included as Part of the EDT Chains 259
Lockup Cell Analysis for Bypass Lockup Cells Included as Part of the EDT Chains . . . . 267
Lockups Between Channel Outputs and Output Pipeline Stages . . . . . . . . . . . . . . . . . . . . 275

Compression Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Establishing a Point of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Performance Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Understanding Compactor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Understanding Scan Chain Masking in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . 285
Fault Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
About Reordering Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Handling of Last Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
EDT Aborted Fault Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Low-Power Test
Low-Power Test
Compressed ATPG with EDT can be configured to use low power during capture cycle, shift
cycles, or both. When configured for low power, both EDT mode and bypass modes are
affected.
A low-power shift application is based on the fact that test patterns typically contain only a
small fraction of test-specific bits and the remaining scan cells or “don’t care” bits are randomly
filled with 0s and 1s; so, there are only a few scan chains with specified bits. In a low-power
application, scan chains without any specified bits are filled with a constant value (0) to
minimize needless switching as the test patterns are shifted through the core. For more
information, see “Low-Power Shift.”
A low-power capture application is based on the existing clock gaters in a design. In this case,
clock gaters controlling untargeted portions of the design are turned off, while clock gaters
controlling targeted portions are turned on. Power is controlled most effectively in designs that
employ clock gaters, especially multiple levels of clock gaters (hierarchy), to control a majority
of the state elements. Configuring low-power capture affects only the test patterns and is
enabled with the set_power_control command during ATPG.
Note
Low-power constraints are directly related to the number of test patterns generated in a low-
power application. For example, using stricter low-power constraints results in more test
patterns.
Low-Power Shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Low-Power Shift
Low-power shift is when you configure the low-power scheme to control the switching activity
during “shift” to reduce power consumption. Setting up low-power shift includes two phases.
1. Inserting power controller logic — The power controller logic is configured/inserted
during EDT logic creation based on the -MIN_Switching_threshold_percentage
<value> specified with the set_edt_power_controller Shift command. This <value>
must fall into one of the three threshold ranges described in “Low-Power Shift and
Switching Thresholds” on page 190.
For example: To enforce a 20% switching threshold for shift (assume a worst-case
switching activity of 50% for scan chains driven by the decompressor), configure the
power controller to drive up to 40% of the scan chains, as shown here:
20% = 50% (max % scan chains to switch of total scan chains)
20% = 50%(40%)
Low-Power Shift
The remaining scan chains (minimum of 60%) are loaded with a constant zero (0) value.
So, in a case in which you have 300 scan chains, the maximum percentage of scan
chains that can switch is 120, which is 40% of 300.
For more information, see “Power Controller Logic” on page 192 and “Low-Power Shift
and Switching Thresholds” on page 190.
2. Creating low-power test patterns — When you generate test patterns, you must enable
the power controller and specify the low-power switching threshold used during scan
chain shifting with the set_power_control and set_edt_power_controller Shift
commands. The specified switching threshold should not exceed the power controller
hardware capabilities; out-of-range thresholds are supported but generate a warning.
For example, if you configure the power controller hardware for a minimum switching
threshold of 20%, you cannot set the test patterns to use a switching threshold of less
than 12% or more than 24%, as described in “Low-Power Shift and Switching
Thresholds” on page 190.
In EDT bypass mode, the tool bypasses the EDT logic and power controller, and the
low-power test patterns use a repeat-fill heuristic to load constant values into the “don’t
care” bits as they shift through the core. The repeat-fill heuristic minimizes needless
transitions during bypass testing. This feature is only available in uncompressed ATPG
or in the bypass mode of compressed ATPG.
Low-Power Shift and Switching Thresholds

Determine the configuration/capability of the power controller hardware with the
-MIN_Switching_threshold_percentage value specified with the set_edt_power_controller
command during EDT logic creation.
The switching threshold percentage is a percentage of the overall scan chain switching during
shift. The minimum switching threshold percentage then represents the minimum switching
threshold the power controller hardware can accommodate in a low-power application and
determines the switching threshold percentage that test pattern generation can use.
Use the following three threshold ranges to set up a low-power shift application. The threshold
range you specify determines the bias value setting:
• < 12% (bias 2)

• >= 12% to < 25% (bias 1)
• >= 25% (bias 0)
Note
The term bias refers to “biased signal probability,” with a higher bias corresponding
to an increase in the size of the power controller hardware.
Low-Power Shift
If you specify a -MIN_Switching_threshold_percentage <value> that falls within one of these

ranges, the tool generates a low-power controller that can generate shift patterns with low-
power switching thresholds of the upper and lower bounds of the range. For example, if you
specify a minimum threshold of 14, the tool generates a low-power controller that is capable of
generating shift patterns with a low-power switching threshold of 12 to 24.
Both switching thresholds—the one for the power controller hardware and the one for low-
power test patterns—must fall into the same switching threshold range. Low-power applications
where power controller and test pattern thresholds fall in different ranges are not supported and
may result in a higher test pattern count and decreased shift power control.
Note
If reaching the specified threshold causes a drop in test coverage, the tool violates the
threshold to maintain coverage. Use the set_power_control -rejection_threshold switch to
specify a hard limit on the switching activity and disregard the test coverage impact.
Pattern Generation and Switching Thresholds

During pattern generation, use the set_power_control command to do the following:
• Enable the low-power logic

• Set the low-power switching threshold to be used during scan chain shifting.
The switching threshold you specify cannot exceed the power controller hardware capabilities.
The switching thresholds for both the power controller hardware and the low-power test
patterns must fall into the same switching threshold range. The tool reports a warning message
when a mismatch occurs between the software switching threshold and the power controller
hardware threshold. The following example is a sample warning message that reports a
mismatch between the switching percentage threshold specified for shift and that specified for
pattern generation:
// command: set_power_control shift on -switching_threshold_percentage 7

// Warning: Specified software switching threshold [7] is not consistent
// with the switching threshold used to generate the shift power control
// hardware [30] in block odd.
// The software and hardware thresholds should be in the same bias range
// (except for the full control case). The following are the valid bias
// ranges: [0-11], [12-24], [25-50].
Note
Low-power applications where power controller and test pattern thresholds fall into
different ranges are not supported and may result in a higher test pattern count and
decreased shift power control.
Low-Power Shift
Low-Power Shift and Test Patterns

The tool adds an additional test pattern (edt_setup) before every test pattern set. This test pattern
sets up the low-power mask registers before the load of the very first real test pattern. Similarly,
the first real test pattern carries the low-power mask setup for the second pattern, and so on. The
unload values of the edt_setup pattern are not observed.
Power Controller Logic

The power controller loads constant values into the “don’t care” bits within scan chains as the
test patterns are uncompressed and shifted into the core.
You must enable the power controller in both the EDT logic hardware and the test pattern
generation software to use low-power ATPG. The default state of the power controller is
“enabled.” For more information, see set_edt_power_controller. If you are not sure whether you
need to use the low-power feature, you can insert a controller without enabling it and later
enable it if you need to lower power consumption. If you change the controller setting during
pattern generation, modify the generated test procedure file to force the shift_const_en signal to
the appropriate value.
Note
Low-power ATPG adds additional shift cycles to each test pattern, so you should turn off
the power controller to prevent unnecessary cycles when you do not need it.
The edt_low_power_shift_en signal shown in Figure 8-1 controls the low-power controller as
follows:
• When you assert edt_low_power_shift_en, it enables the power controller and the
pipeline stages generate a control code at the channel inputs. The control code is loaded
into a hold register and applied to the decoder to control whether to enable the biasing
AND gates. If the control code is 1, the AND gate is enabled and the decompressor
drives the scan chain; if the control code is a 0, the AND gate is turned off and the 0
logic source drives the scan chain.
• When you force the edt_low_power_shift_en signal off, it turns off the power controller,
bypasses the input pipeline stages, and fills the hold register with 1s, and the
decompressor drives all the scan chains. For information on turning off the power
controller, see set_edt_power_controller.
For information on defining a signal for the power controller, see set_edt_pins.
Low-Power Shift
Figure 8-1. Low Power Controller Logic
Static Timing Analysis and Hold Violations From Low-Power Hold Registers
The tool inserts lockup cells on paths between the EDT decompressor and the scan cells to
avoid clock skew issues. However, lockup cells are not required in the path between the low-
power hold register and the first scan cell of each chain. This is because this path does not
operate as a shift register due to the following:
• The low-power hold register only updates in the load_unload cycle, and the scan cells
are not clocked in the load_unload cycle.
• The low-power hold register does not change during the shift cycle when the scan cells
are clocked.
When you verify shift mode timing, the tool pulses both the edt_clock and the scan cell clocks;
this means that a static timing analysis (STA) tool searches for and reports violations in the
paths between low-power hold registers and the scan cells. Prevent these violations from being
reported by adding timing exceptions to your STA tool, directing it to ignore violations on these
paths. The following is an example of setting a timing exception:
set_multicycle_path -hold 1\
-from [get_cells edt_i/edt_contr_i/low_power_shift_contr_i/low_power_hold_reg_*_reg*]
Setting Up Low-Power Test
Related Topics
EDT Logic With Power Controller

You can configure EDT logic with an enabled power controller, and programs the power
controller for the level of shift control you want during test pattern generation. This also enables
the low-power capture feature of the test patterns.
Prerequisites
• RTL or a gate-level netlist with scan chains inserted.
• DFT compression strategy for your design. A compression strategy helps define the
most effective testing process for your design.
Procedure
1. Invoke Tessent Shell to perform EDT logic creation. For example:

2. Set up for EDT logic creation. For example:
dofile edt_ip_creation.do
3. Define an enabled power controller with a minimum switching threshold. For example:
set_edt_power_controller shift enabled -min_switching_threshold_percentage 20
An enabled power controller with 20% minimum switching threshold is set up. If no
minimum threshold is specified, 15% is used. For more information, see “Low-Power
Shift and Switching Thresholds” on page 190.
You can use the set_edt_pins command to define a signal for the power controller.
Note
You can configure the power controller as either enabled or turned off when
generating the EDT controller. Whether it is enabled or turned off has an impact
during pattern generation. If low power was enabled during IP generation and you want
to generate patterns with low power turned off, you must issue the
“set_edt_power_controller shift disabled” command in Setup mode. Similarly, if low
power was turned off during IP generation and you want to generate low power patterns,
you must enable it using the “set_edt_power_controller shift enabled” command in
Setup mode. For complete information, see the set_edt_power_controller command.
4. Define the remaining EDT logic parameters. For more information, see “Parameter
Specification for the EDT Logic” on page 74.
5. Exit setup mode and run DRC. For example:

7. Create the EDT logic. For example:
write_edt_files ../generated/low_power_enabled_edt -replace
8. Exit Tessent Shell. For example:

exit
9. Synthesize the EDT logic. For more information, see “Synthesizing the EDT Logic” on
page 123.
10. Invoke Tessent Shell in setup mode and then set context to perform test pattern
generation.
11. If you had generated the EDT controller with “set_edt_power_controller shift disabled,”
you would need to enable the low power mode using the following command:
set_edt_power_controller shift enabled
12. Program the power controller switching threshold. For example:

set_power_control shift on -switching_threshold_percentage 20 \
-rejection_threshold_percentage 25
The switching during scan chain loading is minimized to 20% and any test patterns that
exceed a 25% rejection threshold are discarded. For information on switching threshold
constraints, see “Low-Power Shift and Switching Thresholds” on page 190.
By default, the switching threshold for ATPG is set to match the threshold used for the
power controller hardware. For modular applications, the highest individual switching
threshold is used.
13. Report the power controller and switching threshold status. For example:
report_edt_configurations -all
// IP version: 4
// External scan channels: 2
// Compactor type: Xpress
// Bypass logic: On
// Lockup cells: On
// Clocking: edge-sensitive
// Low power shift controller:
// Enabled and active
// Min switching threshold:
// 20%
Bold text indicates the output relevant to the power controller.

14. Turn on low-power capture. For example:
set_power_control capture on -switching_threshold_percentage 30 \
-rejection_threshold_percentage 35
Switching during the capture cycle is minimized to 30% and any test patterns that
exceed a 35% rejection threshold are discarded.
15. Exit setup mode and run DRC. For example:

17. Create test patterns. For example:
create_patterns
Test patterns are generated and the test pattern statistics and power metrics display.
Note
If you had generated the IP logic with low power turned off, and now wanted to
generate low power patterns, you would need to first enable low power using the
“set_edt_power_controller shift enabled.”
18. Analyze reports, and adjust power and test pattern settings until power and test coverage
goals are met. You can use the report_power_metrics command to report the capture and
shift power usage associated with a specific instance or set of modules.
19. Save test patterns. For example:
write_patterns ../generated/patterns_edt_p.stil -stil -replace
Related Topics
set_edt_power_controller [Tessent Shell Reference Manual]
set_power_control [Tessent Shell Reference Manual]
Low-Power Test
Low Pin Count Test Controller
Low Pin Count Test Controller

The Low Pin Count Test (LPCT) controller minimizes the top-level pins required for the EDT
application. The LPCT controller generates the control signals needed to operate the EDT logic
and test the design core thereby making control signals from top-level pins unnecessary.
The LPCT controller is configured and embedded in the design along with the EDT logic
according to the design process shown in Figure 8-2.
Figure 8-2. LPCT Design Process

LPCT Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
LPCT Controller Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
LPCT Controller Decision Tree

You can implement an LPCT controller using one of three configuration types: Type 1, Type 2,
or Type 3.
The three LPCT configuration types, Type 1, Type 2, and Type 3, are described in this section.
Figure 8-3 illustrates the decision-making process for choosing which LPCT controller
configuration fits your design constraints.
Figure 8-3. LPCT Controller Decision Tree
Note
Be aware that the Type 3 LPCT controller requires on-chip clock controller (OCC) logic in
the design. Additionally, the OCC logic must be capable of turning off the clocks for
capture, which is necessary for ATPG to detect reset faults. OCC logic is supported for Type 1
and Type 2 LPCT controllers as well, but is not a requirement.
Test Mode Clock Multiplexer Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Sharing of the LPCT Clock and a Top-Level Scan Clock . . . . . . . . . . . . . . . . . . . . . . . . 200
Shift Clock Control for LPCT Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Type 1 LPCT Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Tessent OCC and LPCT Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Test Mode Clock Multiplexer Requirement

You need a multiplexer to choose between the clock controller output used during test and the
original system functional clock source such as the output of a PLL. This is referred to as the
test mode clock multiplexer.
Note
The test mode clock multiplexer is different than the test clock multiplexer, which selects
between the shift and capture clocks.
• Internal capture clocks — If you are using an internal capture clock such as the output
of a programmable clock controller with any of the LPCT controller types, the tool does
not add this multiplexer because the tool only knows the test clock source (that is, clock
controller output) and not the functional clock source (that is, PLL output). Therefore,
you must add a test mode clock multiplexer for all internal capture clocks for all three
types of LPCT controller and the tool assumes this multiplexer already exists in the
design.
• Shared LPCT and design clock — The test mode clock multiplexer is also needed
when the LPCT clock is shared with the scan shift clock. In this case, in order to avoid
breaking the functional clock path, you must provide the tool with the connection point
to the test mode clock multiplexer. You do this using the “set_lpct_pins
test_clock_connection” command.
Figure 8-4 on page 201 shows an example of how the test mode clock multiplexer can be
inserted and connected in the design prior to LPCT logic generation and insertion.
Sharing of the LPCT Clock and a Top-Level Scan Clock

The Type 3 LPCT controller requires a dedicated LPCT clock that is different from other top-
level scan clocks. The Type 1 and Type 2 LPCT controllers can use a top-level scan clock that is
used for both shift and capture cycles as the LPCT clock.
When an internal scan clock is used, the tool inserts a clock mux to choose between the
controller-generated shift clock during shift and the original internal clock during capture. For
top-level clocks, the tool does not insert a mux because the clock can be controlled as needed
during both shift and capture.
When a top-level scan clock is used as the LPCT clock and the -shift_control option is set to
“clock”, the tool adds a clock gater for Type 1 and Type 2 controllers as shown in Figure 8-4.
The clock gater is not added when it generates a shift enable signal. This clock gater is enabled
for all shift and capture cycles, but turned off during the pre-shift and post-shift cycles.
The clock input of the clock gater is connected to the top-level clock, so ATPG has full control
of the scan clock during capture. This enables ATPG to turn off the capture clock, for example
when detecting asynchronous reset faults. Reusing a top-level scan clock as the LPCT clock is
inferred when the defined LPCT clock is pulsed during shift in the incoming logic creation test
procedure file.
Figure 8-4. Clock Gater for Sharing LPCT Clock With Top-Level Scan Clock
Shift Clock Control for LPCT Controllers

All LPCT controller types have the ability to generate and control the shift clocks.
Use the “set_lpct_controller -shift_control” option to specify how the LPCT controller
generates the shift clock control signal. The following are the -shift_control options:
• Enable — The LPCT controller generates the lpct_shift_en enable signal to generate the
shift clock. You can use this enable signal to create the shift clock for the design by
gating it with a pulse-always clock. In this case, you must define the connections from
the enable signal to the clock control logic. This is the default setting.
• Clock — The LPCT controller generates the shift clock. All necessary connections and
gating are added so that shift clocks are controlled and driven from the LPCT controller.
In the case of internal capture clocks, when the LPCT clock is shared with the scan clock
and this option is used, the tool adds a clock gater in the clock path. In this case, the
LPCT clock is used as both a shift clock and a capture clock.
• None — No signal is generated. You should use this option when shift clocks are
available at the top level.
All LPCT controller types use the following signals:
• lpct_clock_mux_select — The select signal of a multiplexer that chooses between the

shift clock and capture clock. This signal should be connected to the select signal of the
existing multiplexer in the clock path.
• lpct_shift_en — An enable signal that can be used as a gating enable with a
pulse-always clock to generate the shift clock.
• lpct_capture_en — An enable signal that indicates the tool is in capture mode. This
signal can be used as a trigger to generate capture clock waveforms.
Use Cases for LPCT-Generated Clocks

You should specify the shift clock control option that is compatible with your design
configuration. There are three -shift_control options for set_lpct_controller command, enable,
clock, and none. There is a use case for each of three design configurations that describes the
required criteria for a shift clock control option and illustrates the implementation of that option.
Use Case for “set_lpct_controller -shift_control clock”

If your design meets the following criteria:
• Contains an OCC, and the test clock multiplexer is outside of the OCC.
• The shift clock is a top-level clock.
• An additional pin is not available for the lpct_clock signal.
• No shift clock gater exists in the design.
And, you want to the eliminate the top-level shift clock pin and have the tool automatically
insert the shift clock gater, you use the “set_lpct_controller -shift_control clock” option.
Additionally, if you have a test clock multiplexer already present in the design, you must use the
“set_lpct_pins -shift_clock” command to connect the LPCT-generated shift clock to the input of
the multiplexer. In this case, specify the top-level shift_clock as “lpct_clock”, which eliminates
the need for a separate lpct_clock pin.
If you have internal clocks (that pulse during shift) in your design and the shift clock connection
is not specified, the tool inserts a multiplexer to select between the defined internal clocks and
the LPCT-generated shift clock as illustrated in Figure 8-5.
Figure 8-5. -shift_control Option: clock
Note
Top-level capture clocks are not affected because they can be controlled with a test
procedure during capture.
Use Case for “set_lpct_controller -shift_control enable”

If your design meets the following configuration criteria:
• Contains an OCC, and the test clock multiplexer and clock gater are inside the OCC.
• The shift clock is a top-level clock.
• An additional pin is not available for the lpct_clock signal.
• A shift clock gater exists in the design.
And, you want to eliminate the top-level shift clock pin and have the tool connect a control
signal to the existing clock gater, you use the “set_lpct_controller -shift_control enable” option.
Additionally, you can use the lpct_clock_mux_select signal to drive the select input of the
existing clock multiplexer as shown in Figure 8-6. The design contains the clock gater (ICG)
and the test clock multiplexer. In this case, the enable signal is generated from the LPCT
controller. You must specify the connection point of the shift_enable signal.
Figure 8-6. -shift_control Option: enable
If you are using the Tessent OCC, you must specify the “-shift_control enable” option. You
must also specify the connections of the LPCT-generated shift enable and LPCT-generated
capture enable signals to the Tessent OCC as illustrated in Figure 8-7.
Figure 8-7. shift_control Option: enable With Tessent OCC
Note
When the “-shift_control enable” option is specified, the tool does not add a clock
multiplexer.
Use Case for “set_lpct_controller -shift_control none”

If your design meets the following configuration criteria:
Either:
• The design is incomplete at the time of IP creation.

• The OCC multiplexers, test clock multiplexers, or both are not available at the time of
LPCT generation.
Or:
• Clock structures are already in the design, all clocks are controllable from the top level,
or both.
Use the “set_lpct_controller -shift_control none” option to indicate that no clock generation is
required from the tool. In this case, you are responsible for ensuring that the shift and capture
clocks are correctly connected in the design prior to pattern generation as shown in Figure 8-8.
Figure 8-8. Shift Clock Option: none
Type 1 LPCT Controller

If your design has a top-level scan enable pin, you can implement the Type 1 LPCT controller.
• Configuration — Uses a top-level scan enable pin to generate the dynamic EDT signals
edt_update and edt_clock.
• Requirements — A top-level scan_en signal and a top-level lpct_clock signal.
LPCT Controller Required Inputs Generated Outputs
Configuration
Type 1 scan_en edt_clock
lpct_clock edt_update
lpct_capture_en
lpct_shift_clock OR
lpct_shift_en
lpct_clock_mux_select
• Description — If your design has a top-level scan enable pin, you can implement the
Type 1 LPCT controller to generate the dynamic test signals edt_clock, edt_update, and
shift clock from the scan_en and lpct_clock signals. All other static EDT-specific test
signals (edt_bypass, edt_low_power_shift_en, and so on) are assumed to be available
either from the top level or through user-provided test logic. You can choose to control
them by some internal test data register. This LPCT controller does not generate any
hardware to control any of these static signals.
Note
OCC logic is optional for the Type 1 LPCT controller.
Figure 8-9 shows the configuration of the Type 1 LPCT controller. For an in-depth
description, see “Type 1 - LPCT Controller With Top-level Scan Enable”.
Figure 8-9. Type 1 LPCT Controller Configuration
• Hardware area — The LPCT controller logic is approximately equal to 14 NAND

gates and is independent of design size or test application.
• Command — To generate a Type 1 controller, use the following command:
set_lpct_controller on -generate_scan_enable off -tap_controller_interface off
Table 8-1 contains additional commands and switches that apply to the Type 1
controller.
Table 8-1. LPCT Controller Type 1 Commands and Switches
To generate a Type 1 LPCT set_lpct_controller set_lpct_pins set_lpct_
Controller, use: condition
_bits
set_lpct_controller -shift_control clock None
-generate_scan_enable Off input_scan_en (input)
-tap_controller_interface Off
clock_mux_select (output)
capture_en (output)
shift_en (output)
shift_clock (output)
test_clock_connection
(output)
Note
When EDT channel outputs are shared with functional output pins, the tool adds an
output channel sharing mux. The select signal of this mux is the scan enable signal
specified using the “set_edt_pins scan_en” command. If you do not specify the scan
enable signal for the Type-1 LPCT controller using the set_edt_pins command, the tool
uses the specified LPCT input scan enable pin as the select signal for the mux.

If your design uses an 1149.1 JTAG TAP controller at the top level to run compression, you can
implement the Type 2 controller.
• Configuration — Uses a TAP state machine to generate scan_enable and the dynamic
EDT signals edt_update and edt_clock.
• Requirement — 1149.1 JTAG TAP controller that is compliant with the IEEE 1687
standard:
Configuration
Type 2 tck scan_en
test_mode edt_clock
test_logic_reset edt_update
update_dr lpct_capture_en
shift_dr lpct_shift_clock OR
capture_dr lpct_shift_en
lpct_clock_mux_select
Note
For the Type 2 LPCT controller, the top-level scan enable pin is removed and the
internally-generated scan enable pin is used.
• Description — If your design uses a 1149.1 JTAG TAP controller at the top level to run
compression, you can implement the Type 2 controller to generate scan_en, edt_update
and edt_clock on chip. All other static test signals can be controlled by the TAP
controller. The LPCT controller only uses the shift_dr, capture_dr, update_dr,
test_logic_reset and test_mode signals from the TAP controller. All other EDT-specific
static signals (edt_bypass, edt_low_power_shift_en, and so on) are assumed to be
available at the top level or are part of a user-defined data register in the JTAG TAP
controller. This LPCT controller does not generate any hardware to control any of these
static signals.
description, see “Type 2 - LPCT Controller With a TAP” on page 216.

gates and is independent of design size or test application.
• Command: To generate a Type 2 controller, use the following command:
set_lpct_controller on -generate_scan_enable on -tap_controller_interface on
controller.
To generate a Type 2 set_lpct_contro set_lpct_pins set_lpct_condition
LPCT Controller, use: ller _bits
set_lpct_controller -shift_control clock (input) None
-generate_scan_enable On test_mode (input)
-tap_controller_interface
On capture_dr (input)
shift_dr (input)
update_dr (input)
tms (input)
reset (input)
clock_mux_select
(output)
capture_en (output)
shift_en (output)
output_scan_en (output)
test_clock_connection
(output)

The Type 3 LPCT controller internally generates the scan enable signal and all EDT-specific
control signals.
• Configuration — Scan enable signal and all other EDT-specific static and dynamic
signals are generated by the LPCT controller.
• Requirements — Generate all EDT-specific signals on chip including scan_en.
Configuration
Type 3 lpct_clock edt_update
lpct_data_in edt_clock
(edt_channels_in1) scan_en
edt_bypass
edt_low_power_shift_en
lpct_shift_clock OR
lpct_shift_en
lpct_capture_en
edt_configuration
Note
For Type 3 controllers, the top-level scan enable pin is removed and the internally-
generated scan enable pin is used.
Note
OCC logic is required to detect reset faults for the design with a Type 3 LPCT
controller.
• Description — The LPCT controller internally generates the scan enable signal and all
EDT-specific control signals; this includes the dynamic signals edt_update, edt_clock,
and scan_en and the static signals edt_bypass, edt_low_power_shift_en, and
edt_configuration. If a design shift clock is not available at the top level, the LPCT
controller can generate the shift clock from the LPCT clock.
description, see “Type 3 - LPCT Controller-Generated Scan Enable” on page 218.
gate equivalent and is independent of design size or test application.
• Command — To generate a Type 3 controller, use the following command:
set_lpct_controller on -generate_scan_enable on -tap_controller_interface off
controller.
To generate a Type 3 set_lpct_controller set_lpct_pins set_lpct_condition
LPCT Controller, use: _bits
set_lpct_controller -max_shift_cycles clock (input) -condition reset
-generate_scan_enable -max_capture_cycles reset (input) -condition scan_en
On
-tap_controller_interface -max_scan_patterns data_in(input)
Off -max_chain_patterns test_mode (input)
-test_mode_detect clock_mux_select
-shift_control (output)
-load_unload_cycles capture_en (output)
shift_en (output)
output_scan_en
(output)
reset_out (output)
test_end (output)
For an in-depth description of this configuration, see “Type 3 - LPCT Controller-

Generated Scan Enable” on page 218.
LPCT Limitations
Tessent OCC and LPCT Usage

Tessent On-Chip Clock Controllers (OCCs) support Type 1, Type 2, and Type 3 LPCT
controllers.

When using a Type 3 LPCT controller, there are two possible cases depending on when you
added the Tessent OCC as follows:
• OCC Core Instances Added During IP Creation — In this case, the LPCT controller
includes any TDR bits for the controller OCC static signals.
• OCC Core Instances Not Added — An example is the EDT skeleton flow. In this
case, you must use the “-tessent_occ switch to the set_lpct_controller command to
specify the OCC.
Refer to “Tessent OCC Overview” in the Tessent Scan and ATPG Manual for complete
information.
LPCT Limitations
Be aware that the LPCT has certain limitations. There are design flow and hardware limitations,
test pattern limitations (Type 3 LPCT), and a single shared LPCT controller for all EDT design
blocks.
Design Flow/Hardware Limitations

The LPCT controller has the following design flow limitations:
• Compression logic inserted external to the design core within a top-level wrapper is not
supported.
• LSSD architecture is not supported.
• The scan_en signal must be constrained to “0” during capture for the Type 1 LPCT
controller.
• The number of pre-shift and post-shift cycles cannot be changed for any type controller
during pattern generation. However the Type 3 controller permits changing of these
cycles during IP creation.
• Pulsing edt_clock before shift is not supported because edt_clock and shift_clock are
derived from the same clock source.
• When scan_en is available at the top level, the EDT static control signals such as
edt_bypass and edt_low_power_shift_en are implemented as top-level pins. You are
LPCT Limitations
responsible for connecting these pins to some internal test logic to avoid having them
assigned as top-level pins.
Test Pattern Limitations When Using a Type 3 Controller
When using an LPCT controller-generated scan enable configuration, the controller has the
following test pattern limitation:
• Multiple load type test patterns are not supported.

Single Shared LPCT Controller for All EDT Design Blocks
If you define all EDT blocks at the same time during IP creation (top-down), the tool correctly
generates only one LPCT controller and drives all EDT blocks from this controller. In a design
with multiple power domains, you should ensure that the LPCT controller is placed in an
always-ON power domain. The EDT blocks can still be placed on the same power domain as
the block level logic. You can use the set_lpct_instances command to control where the LPCT
controller is instantiated.
If you use the integration flow (bottom-up), do not create LPCT logic along with block-level
EDT logic. During the top-level integration, the tool can generate the LPCT controller while
also making the connections for the block level EDT signals. In a design with multiple power
domains, you should also ensure that the LPCT controller is placed in an always-ON power
domain using the set_lpct_instances command.
LPCT Controller Types

This describes the three LPCT controller types, Type 1, Type 2, and Type 3, and their
differences.
Note
All three LPCT controller types apply to scan and EDT control pins only and do not limit
the number of EDT channels that can be used.
Type 1 - LPCT Controller With Top-level Scan Enable . . . . . . . . . . . . . . . . . . . . . . . . . 213

Type 2 - LPCT Controller With a TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Type 3 - LPCT Controller-Generated Scan Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Type 1 - LPCT Controller With Top-level Scan Enable

When you implement an LPCT controller using a top-level scan_en pin, the LPCT controller
generates the edt_update and edt_clock signals. However, it does not generate any of the EDT
static control signals such as edt_bypass, edt_low_power_shift_en, and so on. To avoid having
these signals assigned as top-level pins, you must connect them to some internal test logic.
When implementing the LPCT controller with a top-level scan enable signal (Type 1), the
design must have a top-level clock. The clock can be a pulse-always reference clock or a tester-
controllable top-level clock pin as shown in Figure 8-12. If this clock is also a shift clock, and
the shift control is set to “clock”, a clock gater is automatically inserted in this clock path to
enable this clock to be used during shift and capture
Figure 8-12 shows the controller logic. In this configuration, the scan_en signal is constrained
to 0 in the capture cycle and set to 1 during the shift cycle, but is set to 0 during the post-shift
cycles.
Figure 8-12. Type 1 LPCT Controller Operation
The Type 1 LPCT controller does not have a finite state machine or counters to track the test
procedure states. The start of the load_unload procedure is inferred when the scan_en signal
transitions from 0 to 1.
• For scan test patterns, the pin constraint on scan_en provides the initial 0 value for the
transition.
• For chain test patterns, there are no capture cycles when using pulse-always clocks; the
post-shift cycles in load_unload provide the initial 0 value for the transition.
Figure 8-13 shows the waveforms generated by Figure 8-12.
Figure 8-13. Signal Waveforms for Type 1 LPCT Controller
Two pre-shift and post-shift cycles are added to the load_unload procedures when using the
Type 1 LPCT controller. These two cycles separate the transition between the shift clock, the
capture clock, lpct_capture_en, and the lpct_clock_mux_select signals when transitioning from
capture to shift and from shift to capture.
• Pre-Shift Cycles — At the beginning of the pre-shift cycles, the scan enable signal
transitions from 0 (during capture) to 1, which enables the edt_update output from the
LPCT controller to be asserted immediately. The edt_clock signal is generated one cycle
later. However, the shift clock begins to pulse two cycles after the transition of the
scan_en signal.
• Post-Shift Cycles — At the end of scan chain shifting, the scan_en signal is deasserted
(transitions from 1 to 0). The signal scan_en is deasserted for both post-shift cycles and
the clocks to the design are expected to be turned off as shown in the waveforms in
Figure 8-13. The lpct_clock_mux_select signal is deasserted at the negedge of the clock
in the first post-shift cycle. The lpct_capture_en signal transitions one cycle later—on
the negedge of the second post-shift cycle. The capture pulses can only be generated in
the cycle after the lpct_capture_en signal is asserted (after the 2nd post-shift cycle).
During each of these cycles, only one of the signals, lpct_clk_mux_select and
lpct_capture_en, transition at a time.
Type 2 - LPCT Controller With a TAP

When you implement an LPCT controller with a TAP, the LPCT controller generates the scan
enable, edt_update, and edt_clock signals based on the output of the TAP controller. However,
it does not generate any of the EDT static control signals such as edt_bypass and
edt_low_power_shift_en. To avoid having these signals assigned as top-level pins, you must
connect them to some internal test logic.
When implementing a Type 2 LPCT controller, the dynamic test control signals are generated
based on the TAP controller state machine. In addition to the clock (tck) and test mode signal
(tms), the enable signals corresponding to capture_dr, test_logic_reset, shift_dr, and update_dr
are used as inputs to the controller. The shift_dr and capture_dr signals are assumed to change at
the rising edge of the tck signal. These signals can be connected either to combinational tap
output pins, or registered at the negedge of TCK in the TAP controller.
The update_dr signal is assumed to change at the falling edge of the tck signal. This signal can
be connected either to a combinational tap output pin, or registered early at the prior posedge of
TCK in the TAP controller.
These signal change edges are consistent with the IEEE 1149.1 standard.
Figure 8-14 shows the controller logic of the LPCT controller when using a TAP.
Figure 8-14. LPCT Controller With TAP
The TAP controller must provide an enable signal (test_mode) that signals the LPCT controller
to enter test mode. This test_mode signal can be generated using a JTAG user-defined
instruction.
The test_mode signal indicates whether the instruction corresponding to scan test is currently
loaded in the instruction register. The signal test_logic_reset is used to asynchronously reset the
flip-flops driving scan_en and capture_en because the design is required to go to a functional
mode of operation immediately on reset of the TAP controller. The scan_en signal has a re-
circulating mux to hold its ON value between capture_dr and update_dr; this enables the
scan_en to not change unnecessarily when long shift sequences are broken using the pause_dr
state.
Figure 8-15 illustrates the waveforms of the input signals from the TAP controller and the
generated output signals. Capture is performed during the run_test_idle state; this provides for
an arbitrary number of tck capture cycles by constraining tms to 0.
Figure 8-15. Signal Waveforms for TAP-Based LPCT Controller
Type 3 - LPCT Controller-Generated Scan Enable

A Type 3 LPCT controller requires a minimum of three top-level pins including a pulse-always
clock, an input data channel, and an output data channel.
As shown in Figure 8-16, the pulse-always clock source can be either the reference clock from
an on-chip PLL or the output of a PLL that is always running. The LPCT controller logic
operates based on this clock; the EDT and capture clocks are derived from this clock.
Note
For Type 2 and Type 3 controllers, the top-level scan enable pin is removed and the
internally-generated scan enable pin is used.
Figure 8-16. Before and After EDT and LPCT Controller Logic
In the Type 3 configuration, the LPCT controller contains the following components as shown
in Figure 8-16:
• Test Sequence Detector — Detects a specified input sequence and produces a signal to
enable test mode. This is optional depending on how you configure the test mode enable.
• Test Configuration Data Register — Contains information about the test pattern set
such as the number of chain/scan tests, shift/capture cycles, and the EDT logic mode of
operation including low-power, bypass, and dual configurations. The size of the test
configuration register is approximately 50 bits and is directly related to the size of the
shift, capture, and pattern counters. The test configuration data is read once during the
test_setup procedure.
• Finite State Machine — Generates the scan control signals during test pattern
application and controls pattern shift and capture counters.
• Pattern, Shift, And Capture Counters — Track test pattern data for the finite state
machine.
Test Mode Enable

Depending on the application, a signal from the LPCT controller to enable test mode must be
configured using one of the following methods:
• Test Mode Signal — Test mode is enabled after the test mode signal is asserted for one
cycle, and the test session end is determined by the test pattern counters. When this
signal is a top-level pin, the correct test_setup procedure is automatically generated.
When this signal is an internal pin, you must modify the test_setup procedure to ensure
that the internal test mode signal is asserted as necessary and that the controller logic is
reset before entering test mode.
• Test Mode Sequence — Test mode is enabled when a specific input sequence is
detected within a specific number of cycles after the LPCT controller is reset. This is
required when no top-level pin is used. You can specify the sequence/cycles with the
set_lpct_controller command when setting up the LPCT controller. The generated test
procedure file contains all the initialization cycles necessary to enter test mode when
using sequence detection.
Note
Only one of these methods can be used to enable test mode for any single
application.
Test Patterns and the Type 3 LPCT Controller

When generating test patterns for a Type 3 LPCT controller, you must take into account the
following test pattern setups:
• NCPs or Clock Control Definitions can be Used for Capture Cycles — The LPCT
controller hardware is configured for a fixed number of capture cycles as determined by
the set_lpct_controller -max_capture_cycles command. Consequently, you must use
NCPs to specify all possible clocking sequences and add additional cycles so all test
patterns use the fixed number of capture cycles.
o If NCPs are used, each one must have the same number of capture cycles.
o If clock control definitions are used, the tool automatically ensures that all patterns
in the pattern set have the same number of capture cycles.
o The value of the capture cycle width portion of the test configuration data is
automatically stored in the test patterns as part of the test_setup procedure.
• Chain Test Patterns — The LPCT controller includes separate counters for chain test
and scan test patterns. The chain tests do not include a capture cycle, so the controller
does not enter capture state for chain test patterns.
• Iddq Test Patterns — Iddq tests do not have a capture cycle, but there is a quiescent
(dead) cycle between pattern loads. During this time, you must ensure that no functional/
design clocks pulse. NCPs are not supported for iddq test patterns.
• Parallel Test Patterns — The LPCT controller includes internally-added primary input
pins, so you must use the -mode_internal switch when saving parallel test patterns. For
more information, see the write_patterns command.
• WGL and Verilog Test Patterns — If you are using the Type 3 LPCT controller, you
cannot use the write_patterns -mode LSI switch when saving WGL or Verilog patterns.
When you save WGL or Verilog patterns using the -mode LSI switch, the tool
manipulates the patterns and adds extra cycles to ensure the same number of cycles in
both pre- and post-shift. These modifications are inconsistent with the Type 3 LPCT
hardware and cause the patterns to get out of sync with the LPCT Finite State machine.
Because these same conditions can be enabled if you set the ALL_FIXED_CYCLES
parameter to anything other than 0, you cannot save patterns with the
ALL_FIXED_CYCLES parameter set to 1 or 2 when using the Type 3 LPCT controller.
Figure 8-17 and show the waveforms for signals generated by the Type 3 LPCT controller
configuration.
Note
The edt_clock signal is a gated version of the pulse-always clock that is always generated by
the LPCT controller.
Figure 8-17. Scan Test Pattern Timing
Detecting Faults on Reset Lines

When using the Type 3 LPCT controller, the functional reset for the design is also used to reset
the LPCT controller. Therefore, the faults along the reset lines are not detected by ATPG
because the reset is in the deasserted state during the entire ATPG session. You can use one of
the following two methods to recover the coverage along the reset lines:
• Assert Reset for the Entire Pattern Set — With this method, the patterns to detect
faults along the reset lines must be in a different pattern set with their own test_setup
procedure. To use this method, make the following change in the dofile generated during
the logic creation phase of the LPCT controller:
In the Pattern Generation dofile, specify pin constraints and register values as follows:
Change This To This
add_input_constraints reset_control -C0 add_input_constraints reset_control -C1
add_register_value lpct_config_reset_control 0 add_register_value lpct_config_reset_control 1
Note
When specifying an active low reset, using the set_lpct_pins -reset -active low
command, you should reverse the pin constraint and register values. That is, you
should flip the pin constraint from C1 to C0 and the register value from 1 to 0.
The add_register_value command holds the reset to the design in the asserted state while
the reset to the controller is deasserted. Although this method requires two separate sets
of patterns each with their own test_setup procedure, no additional design requirements
are needed to create these patterns.
• Use LPCT Condition Bits — With this method, you use a scan flop in the design as a
control (condition) bit that enables ATPG to automatically justify the appropriate value
to assert or deassert the reset signal to the design. With this method, only one pattern set
is created for each fault model. To use this method, make the following changes:
In the IP Creation dofile, specify the condition scan cell as follows:
Add This
set_lpct_condition_bits -condition reset -from <scancell_name>
In the Pattern Generation dofile, specify pin constraints and register values as follows:
Change This To This
add_input_constraints reset_control -C0 add_input_constraints reset_control -C1
add_register_value lpct_config_reset_control 0 add_register_value lpct_config_reset_control 1
Note
When specifying an active low reset, using the set_lpct_pins -reset -active low
command, you should reverse the pin constraint and register values. That is, you
should flip the pin constraint from C1 to C0 and the register value from 1 to 0.
ATPG justifies the value in this scan cell in the last load cycle before capture to ensure
the reset to the design is asserted or deasserted as needed. Using this method enables you
to generate a single test pattern set to detect reset line faults as well as other design
faults.
Figure 8-18. Chain Test Pattern Timing
Toggling Scan Enable

When using the Type 3 LPCT controller, the scan enable signal generated by the LPCT
controller (lpct_scan_en) is always driven to 0 during capture. For stuck-at patterns, if the scan
enable signal to the design is required to toggle during capture, you must use dedicated scan
cells (condition bits); these scan cells must be part of the scan chain. To toggle the scan enable
signal, do the following:
In the IP Creation dofile, specify the condition scan cell:

Add This
set_lpct_condition_bits -condition scan_en -from <scancell_name>
In the Pattern Generation dofile, specify pin constraints and register values:
Change This To This
add_input_constraints scan_en_control -C0 add_input_constraints scan_en_control -C1
add_register_value lpct_config_scan_en_control 0 add_register_value lpct_config_scan_en_control 1
LPCT Configuration Examples

This section provides an example for creating each of the three LPCT configuration types and
examples of the dofile and test procedure files generated for each configuration.
For more information on the differences between configuration types, see LPCT Controller
Types.

Type 1 Controller LPCT Clock Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Type 2 Controller Scan Shift Clock Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Type 1 Controller Generation Example

This example generates a Type 1 LPCT controller.
Sample Dofile:
// Group definition
add_scan_groups grp1 scan_setup.testproc
// Clock definitions
add_clocks 0 /occ/NX2 -pseudo_port_name NX2

// Scan chain definitions

// EDT configuration
set_edt_options -channels 2 -location internal
// LPCT configuration
set_lpct_controller -generate_scan_enable off \
-tap_controller_interface off -shift_control clock
// LPCT Pin connections

set_lpct_pins clock refclk
set_lpct_pins input_scan_en scan_en
// Run DRC
// Insert EDT and LPCT controller logic in design

// The command writes out the LPCT-specific TCD file
Type 2 Controller Generation Example

This example generates a Type 2 LPCT controller.
Sample Dofile:
// Group definition
add_scan_groups grp1 scan_setup.testproc
// Clock definitions

add_clocks 0 tck
// Pin constraints
add_input_constraints trst -C1
// Scan chain definitions

// EDT configuration
set_edt_pins input_channel 1 tdi m8051_i/edt_channels_in1

set_edt_pins output_channel 1 tdo tap_i/tap_edt_channel_reg_in
// LPCT configuration
set_lpct_controller -generate_scan_enable on \
-tap_controller_interface on -shift_control clock
// LPCT Pin connections to LPCT controller pins
set_lpct_pins clock tck pad_instance_1_i/po_pad_tck

set_lpct_pins reset - tap_i/U2/Z
set_lpct_pins capture_dr - tap_i/tap_ctrl_i/capturedr
set_lpct_pins shift_dr - tap_i/tap_ctrl_i/shiftdr
set_lpct_pins update_dr - tap_i/tap_ctrl_i/updatedr
set_lpct_pins test_mode - tap_i/instruction_decoder_i/edt_scan_inst
set_lpct_pins tms tms pad_instance_1_i/po_pad_tms
set_lpct_pins output_scan_en scan_en
// Run DRC
// Insert EDT and LPCT controller logic in design
Type 3 Controller Example

This example generates a Type 3 LPCT controller and displays the associated pattern generation
dofile and test procedure file generated by the tool.
Sample Dofile:
read_cell_library ../library/adk.tcelllib
# Read Verilog design (synthesized and scan inserted)

read_verilog ../des_chip_scan.v
# Set design top module

set_current_design des_chip
read_core_descriptions des_chip_rtl.tcd
add_core_instances -module des_chip_rtl_tessent_occ -parameter_values \
{fast_cap_mode off}
# add scan chain definitions

dofile des_chip_scan.dofile
# Set up EDT options

set_edt_options on -location internal -bypass on
# Set up the LPCT controller (type 3)

set_lpct_controller on -generate_scan_enable on -tap_controller_interface
off \
-shift_control enable
set_lpct_controller on -test_mode sequence 110010010010001110 200 \
-max_shift 5000 -max_capture 4
# Connections to/from LPCT controller.

# Primary input to attach as the continuous clock to the LPCT controller.
set_lpct_pins clock clk_st
# Scan_enable pin for design is needed as an input to Type 3 LPCT

controller
set_lpct_pins output_scan_enable tmp_scan_en
# Connect lpct_capture_en output to the OCC.

set_lpct_pins capture_enable [get_pins capture_en -of_instance
*_tessent_occ*inst]
# Connect lpct_shift_en output to the OCC.

set_lpct_pins shift_enable [get_pins occ_scan_en -of_instance
*_tessent_occ*inst]
# Check design rules

report_edt_configuration -all
report_lpct_configuration
report_lpct_pins
report_edt_pins -all
# Generate and insert EDT and LPCT logic

write_edt_files des_chip -replace
exit -f
Sample Pattern Generation Command Sequence:

# Read scan inserted design

read_verilog des_chip_edt_top_gate.v
# read cell library

read_cell_library ../library/adk.tcelllib
# set current design

set_current_design des_chip
## NOTE: Assuming that the scan chains and the clock definitions are
## inaccurate
set_procedure_retargeting_options -scan on -ijtag off
# Read the TCD files for each of the instruments.

# In this case, there are two instruments - EDT and OCC
read_core_description des_chip_rtl_tessent_occ.tcd
read_core_description des_chip_des_chip_edt.tcd
read_core_description des_chip_des_chip_lpct.tcd
set occ_module [get_modules {.*_tessent_occ(_[[:digit:]])*} -regexp]
set lpct_module [get_modules {.*_lpct(_[[:digit:]])*} -regexp]
set edt_module [get_modules {.*_edt(_[[:digit:]])*} -regexp]
# Associating the TCDs with each of the instances that it describes

# This automates the control of the pins and constraints required during
# test_setup for ATPG
# add_core_instance -module $edt_top_module
add_core_instance -module $occ_module -parameter_value {fast_cap_mode on}
add_core_instance -module $lpct_module
add_core_instance -module $edt_module
set_procfile_name ./top_level.testproc
dofile ./top_level_des_chip.dofile
set_external_capture_options -fixed 7
# Report the cores that are described

report_core_descriptions
# Check DRC rules

# Report DRC rules

report_drc_rules
# Add all faults

add_faults -all
# Create patterns
create_patterns
# Write patterns
write_patterns ./generated/pat.v -verilog -serial -param paramfile -
replace
exit -f
Type 1 Controller LPCT Clock Example

This example generates a simple Type 1 controller that specifies a top-level scan clock as the
LPCT clock.
set_context dft –edt
add_clock 0 clk //Note – there is a single clock in the design
add_scan_chains ...
set_lpct_controller on –shift_control clock
set_lpct_pin clock clk //LPCT clock is shared with scan clock
set_lpct_pin input_scan_enable scan_en
set_lpct_pin test_clock_connection test_mode_mux/B
report_lpct_pins
Type 2 Controller Scan Shift Clock Example

This example generates a Type 2 LPCT controller that uses tck as a scan shift clock. The test
mode multiplexer, which chooses between the LPCT-generated scan clock and the functional
clock, already exists in the design. The test_clock_connection pin on the mux is specified with
the test_clock_connection pin type.
This example is illustrated in Figure 8-19.
set_context dft –edt

add_clock 0 tck
add_scan_chains ...
set_lpct_controller –tap_controller_interface on
set_lpct_controller –shift_control clock
set_lpct_pins output_scan_enable scan_en
set_lpct_pins tck tck pad_tck/Z //LPCT clock is tck
set_lpct_pins tms tms pad_tms/Z
set_lpct_pins reset – tap_i/tlr
set_lpct_pins capture_dr – tap_i/capturedr
set_lpct_pins shift_dr – tap_i/shiftdr
set_lpct_pins update_dr – tap_i/updatedr
set_lpct_pins test_mode – tap_i/edt_scan_inst
set_lpct_pins test_clock_connection test_mode_mux/B
set_edt_options –channel 1
set_edt_pins input 1 tdi pad_tdi/Z
set_edt_pins output 1 tdo tap_i/tap_edt_channel_reg_in
report_lpct_pins
report_lpct_configuration
Figure 8-19. Type 2 LPCT Design Example

By default, bypass circuitry is included in the EDT logic. The bypass circuitry enables you to
bypass the EDT logic and access uncompressed scan chains in the design core.
Bypassing the EDT logic enables you to apply uncompressed test patterns to the design to
• Debug compressed test patterns.

• Apply additional custom uncompressed scan chains.
• Apply test patterns from other ATPG tools.
Bypass logic can also be inserted in the core netlist at scan insertion time. This enables you to
place the multiplexers and lockup cells required to operate the bypass mode inside the core
netlist instead of the EDT logic. This option enables more effective design routing. For more
information, see “Insertion of Bypass Chains in the Netlist” on page 56.
You can also set up two bypass scan chain configurations. In addition to the default
configuration, you can create a second bypass configuration that concatenates all scan chains
together into one bypass chain for use when hardware test channels are limited. For more
information, see “Dual Bypass Configurations” on page 236.

Generating EDT Logic When Bypass Logic Is Defined in the Netlist . . . . . . . . . . . . . . 234
Generation of Identical EDT and Bypass Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 237
Use of Bypass Patterns in Uncompressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Creating Bypass Test Patterns in Uncompressed ATPG . . . . . . . . . . . . . . . . . . . . . . . . . 241
Structure of the Bypass Logic

Because the number of core scan chains is relatively large, they are reconfigured into fewer,
longer scan chains for bypass mode. For example, in a design with 100 core scan chains and
four external channels, every 25 scan chains are concatenated to form one bypass chain. This
bypass chain is then connected between the input and output pins of a given channel.
Figure 8-20 illustrates conceptually how the bypass mode is implemented.
Generating EDT Logic When Bypass Logic Is Defined in the Netlist
Figure 8-20. Bypass Mode Circuitry
Notice that the bypass logic is implemented with multiplexers. The tool includes the
multiplexers and any lockup cells needed to concatenate scan chains in the EDT logic.
Note
When lockup cells are inserted as part of the bypass logic, the EDT logic requires a system
clock. If the same bypass logic is placed in the netlist, the EDT logic does not require a
system clock.
You can also set up the EDT clock to pulse before the scan chain shift clocks to avoid using a
system clock. For more information, see the -pulse_edt_before_shift_clocks switch of the
set_edt_options command.
The bypass circuitry is run from bypass mode in Tessent FastScan.
Generating EDT Logic When Bypass Logic Is

Defined in the Netlist
EDT technology supports netlists that contain two sets of pre-defined scan chains. Predefining
two sets of scan chains enables you to insert both the bypass chains and the core chains into the
core design with a scan-insertion tool.
Generating EDT Logic When Bypass Logic Is Defined in the Netlist
Note
Design blocks that contain bypass chains in the EDT logic and design blocks that contain
bypass chains in the core can coexist in a design.
Restrictions and Limitations

• Bypass patterns cannot be created from compressed test patterns. You must generate
bypass patterns from Tessent Shell. See “Creating Bypass Test Patterns in
Uncompressed ATPG” on page 241.
Prerequisites
• Both bypass and core scan chains must be inserted in the design netlist. For more
information, see “Insertion of Bypass Chains in the Netlist” on page 56.
Procedure
2. Load the design and library and set the context for EDT logic generation.
set_context dft -edt read_verilog my_gate_scan.v read_cell_library \
my_lib.aptg set_current_design top
3. Set up parameters for the EDT logic generation.

For more information, see “Preparation for EDT Logic Creation” on page 70.
4. Enable the tool to use existing bypass chains. For example:
set_edt_options -bypass_logic use_existing_bypass_chains
For more information, see the set_edt_options command.

5. Specify the number of bypass chains. For example:
set_edt_options -bypass_chain 2
For more information, see the set_bypass_chains command.

6. Specify the input and output pins for the bypass chains. For example:
set_bypass_chains 2 -pins scan_in2 scan_out2
For more information, see the set_bypass_chains command.

7. Generate the EDT logic. For more information, see “Creation of EDT Logic Files” on
page 98.
Related Topics
Creating Bypass Test Patterns in Uncompressed ATPG
Dual Bypass Configurations
Dual Bypass Configurations

You can use the set_edt_options -single_bypass_chain command to output EDT logic with two
bypass configurations.
The two bypass configurations are
• Default Scan Chain Configuration — All scan chains are evenly distributed and
concatenated into scan chains equal to the number of input/output channels in the EDT
logic. This configuration can also be specified with the “set_edt_options
-bypass_chains” command and switch. For more information, see “Compression Bypass
Logic” on page 233.
• Single Bypass Scan Chain Configuration — All scan chains are concatenated together
to form one scan chain for bypass mode. A single bypass chain configuration can be
used in test environments with hardware limitations.
When dual configurations are specified, an additional primary input edt_single_bypass_chain
pin is created to enable and turn off the single chain configuration. For more information, see
“Single Chain Bypass Logic” on page 331.
An additional dofile <design>_single_bypass_chain.dofile is also produced to define the single

top-level scan chain and force the edt_single_bypass_chain pin to 1.
Additional lockup cells are inserted as needed. For more information, see “Lockups in the
Bypass Circuitry” on page 262.
By default only test patterns for the default configuration are saved. To save the test patterns for
the single chain bypass configuration, you must use the “write_patterns
-edt_single_bypass_chain” command.
Note
Single bypass chain configuration is associated with one compression block. To use this
feature in a block-level architecture, you must manually integrate all single bypass chains
together at the top-level.
The single bypass configuration is not included in reported test pattern statistics and scan
chains. Only information about the default bypass configuration is reported.
Related Topics
Structure of the Bypass Logic
Lockups in the Bypass Circuitry
Use of Bypass Patterns in Uncompressed ATPG
Generation of Identical EDT and Bypass Test Patterns
Generation of Identical EDT and Bypass Test

Patterns
The EDT technology supports the creation of uncompressed versions of each EDT pattern. The
availability of uncompressed EDT patterns enables you to use uncompressed ATPG in bypass
mode to directly load the scan cells with the same values that compressed ATPG loads. For
debugging simulation mismatches in the core logic, it is sometimes helpful if you can apply the
exact same patterns with uncompressed ATPG in bypass mode that you applied with
compressed ATPG.
Note
You can only convert EDT test patterns to uncompressed test patterns for bypass mode if the
bypass scan chains are created with compressed ATPG. Otherwise, you must use
uncompressed ATPG to generate bypass test patterns. See “Creating Bypass Test Patterns in
After you generate EDT patterns in the Pattern Generation phase, you can direct the tool to
translate the EDT patterns into bypass mode uncompressed ATPG patterns and write the
translated patterns to a file. The file format is the same as the regular uncompressed ATPG
binary file format. You accomplish the translation and create the binary file by issuing the
write_patterns command with the -EDT_Bypass and -Binary switches. For example:
write_patterns my_bypass_patterns.bin -binary -edt_bypass
You can then read the binary file into uncompressed ATPG, re-simulate the patterns in the
analysis system mode to verify that the expected values computed in compressed ATPG are still
valid in bypass mode, and save the patterns in any of the tool’s supported formats; WGL or
Verilog for example. An example of this tool flow is provided in “Use of Bypass Patterns in
There are several reasons you cannot use EDT technology alone to create the EDT bypass
patterns:
• The bypass operation requires a different set of test procedures. These are only loaded
when running uncompressed ATPG and are unknown to EDT in the Pattern Generation
phase.
If the bypass test procedures produce different tied cell values than the EDT test
procedures, simulation mismatches can result if the EDT patterns are simply reformatted
for bypass mode. An example of this would be if a boundary scan TAP controller were
used to drive the EDT bypass signal. With the two sets of test procedures, the register
driving the signal is forced to different values. As a result, the expected values computed
for EDT would be incorrect for bypass mode.
• EDT would not have run any DRCs to ensure that the scan chains can be traced in
bypass mode.
• You may need to verify that captured values do not change in bypass mode.
When it translates EDT patterns into bypass patterns, EDT changes the captured values on some
scan cells to Xs to emulate effects of EDT compaction and scan chain masking. For example, if
two scan cells are XORed together in the compactor and one of them had captured an X, the tool
sets the captured value of the other to X so no fault can be detected on those cells, incorrectly
credited, then lost during compaction.
Similarly, if a scan chain is masked for a given pattern, the tool sets captured values on all scan
cells in that chain to X. When translating the EDT patterns, the tool preserves those Xs so the
two pattern sets are identical. While this can lower the “observability” possible with the bypass
patterns, it emulates EDT test conditions. For more information on how EDT uses masking,
refer to “Understanding Scan Chain Masking in the Compactor” on page 285.
Chain Test Pattern Handling for Bypass Operation

The EDT technology saves only the translated EDT scan patterns in the binary file. The
enhanced “chain + EDT logic” test patterns are not saved. The purpose of the enhanced test
patterns is to verify the operation of the EDT logic as well as the scan chains. Because no
shifting occurs through the EDT logic when it is bypassed, regular chain test patterns are
sufficient to verify the scan chains work in bypass configuration; the regular chain test patterns
are appended to the compressed test pattern set when you write out the bypass patterns.
Note
Because the EDT pattern set contains the enhanced test patterns and the bypass pattern set
does not, the number of patterns in the EDT and bypass pattern sets are different.
You can use the bypass test patterns with uncompressed ATPG to debug problems in the core
design and scan chains but not in the EDT logic. If the enhanced tests fail in compressed ATPG
and the bypass chain test passes in uncompressed ATPG, the problem is probably in the EDT
logic or the interface between the EDT logic and the scan chains.

After you save the bypass patterns, invoke Tessent Shell, read the design, and use the dofile and
test procedure file generated when the EDT logic is created. You then read into Tessent Shell
the binary pattern file you previously saved from compressed ATPG. You should re-simulate
the patterns in the analysis system mode to verify that the expected values computed with
compressed ATPG are still valid in bypass mode. Then save the patterns in any of the tool’s
supported formats, WGL or Verilog for example.
Bypass Pattern Flow Example

The following example demonstrates how to use bypass patterns in ATPG mode.
Note
The following steps assume that, as part of a normal flow, you already have run Tessent
Shell to create the EDT logic, followed by Design Compiler to synthesize it. You must
complete both steps in order to run Tessent Shell with uncompressed ATPG in bypass mode.
The bypass dofile and the bypass test procedure file generated by compressed ATPG are
required by uncompressed ATPG in order to correctly apply a bypass pattern set.
In the compressed ATPG Pattern Generation phase, issue a

“write_patterns -binary -edt_bypass” command to write bypass patterns. For example:
write_patterns my_bypass_patterns.bin -binary -edt_bypass
Notice that the -Binary and the -Edt_bypass switches are both required in order to write bypass
patterns.
Tessent Shell Setup in Uncompressed ATPG

Invoke Tessent Shell in setup mode and invoke the bypass dofile generated by compressed
ATPG. Place the design in the same state in uncompressed ATPG that you used in compressed
ATPG, then run DRC.
Note
Placing the design in the same state in uncompressed ATPG as in compression ATPG
ensures the expected test values in the bypass patterns remain valid when the design is
configured for bypass operation.
The following example uses the bypass dofile, created_bypass.dofile, described in “Creation of
EDT Logic Files” on page 98:
dofile created_bypass.dofile
Verify that no DRC violations occurred.
Processing of the Bypass Patterns

To simulate the bypass patterns and verify the expected values, you can enter commands similar
to the following:
read_patterns my_bypass_patterns.bin
report_failures -pdet
Note
The expected values in the binary pattern file mirror those with which compressed ATPG
observes EDT patterns. Therefore, if compressed ATPG cannot observe a scan cell (for
example, due to scan chain masking or compaction with a scan cell capturing an X), the
expected value of the cell is set to X even if it can be observed by uncompressed ATPG in
bypass mode.
Saving of the Patterns With Compressed ATPG Observability

To save the patterns in another format using the expected values in the binary pattern file, issue
the write_patterns command with the -External switch. For example, to save ASCII patterns:
write_patterns my_bypass_patterns.ascii -external
Saving of the Patterns With Uncompressed ATPG Observability
Alternatively, you can save expected values based on what is observable by uncompressed
ATPG when the design is in bypass operation. Some scan cells that had X expected values in
compressed ATPG, due to scan chain masking or compaction with an X in another scan cell,
may be observed by uncompressed ATPG. To write_patterns where the expected values reflect
uncompressed ATPG observability, first simulate the patterns as follows:
simulate_patterns -store_patterns all
Note
The preceding command sequence causes the Xs that emulate the effect of compaction in
EDT to disappear from the expected values. The resultant bypass patterns are no longer
equivalent to the EDT patterns; only the stimuli are identical in the two pattern sets. For a given
EDT pattern, therefore, the corresponding bypass pattern no longer provides test conditions
identical to what the EDT pattern provided in compressed ATPG.
Using the -Store_patterns switch in analysis system mode when specifying the external file as
the pattern source causes uncompressed ATPG to place the simulated patterns in the tool’s
internal pattern set. The simulated patterns include the load values read from the external
pattern source and the expected values based on simulation.
Note
If you fault simulate the patterns loaded into uncompressed ATPG, the test coverage
reported may be slightly higher than it actually is in compressed ATPG. This is because
uncompressed ATPG recomputes the expected values during fault simulation rather than using
the values in the external pattern file. The recomputed values do not reflect the effect of the
compactors and scan chain masking that are unique to EDT. Therefore, the recomputed values
likely contain fewer Xs, resulting in the higher coverage number.
When you subsequently save these patterns, take care not to use the -External switch with the
write_patterns command. The -External switch saves the current external pattern set rather than
the internal pattern set containing the simulated expected values. The following example saves
the simulated expected values in the internal pattern set to the file, my_bypass_patterns.ascii:
write_patterns my_bypass_patterns.ascii
Creating Bypass Test Patterns in Uncompressed

ATPG
Generate test patterns for the bypass chains located in your netlist or in the EDT logic.
Prerequisites
• If a signal other than the edt_bypass signal is used for the mux select that enables the
bypass chains, the test procedure file for the bypass chains must be modified to permit
bypass chains to be traced.
• EDT logic must be created and synthesized into your netlist and test procedure files
generated by compressed ATPG are available.
Procedure
1. Invoke Tessent Shell. The setup prompt displays.
<Tessent_Tree_Path>/bin/tessent -shell -logfile \
../transcripts/edt_pattern_gen.log -replace
2. Set the context, read in the design library, read and set current design.
SETUP> read_verilog created_edt_top_gate.v
3. If a Tessent Shell Database (TSDB) is not available, read the TCD file for EDT IP using
the read_core_description command. For example:
If a TSDB is available, the tool automatically reads the TCD for the EDT logic.
4. Define the parameter values to automatically configure the EDT logic using the
add_core_instances command. In this case, you want to create bypass patterns, so use
the “edt_bypass on” switch. For example
SETUP> add_core_instances -core cpu_edt \
-parameter_values edt_bypass on
5. Add top-level clocks driving the scan changes using the add_clocks command.
add_clocks 0 clk1 clk2 clk3 clk4 ramclk
6. Provide the top-level test procedure file using the set_procfile_name command.
7. Change to analysis system mode, which runs DRC.

8. Check for and debug any DRC violations.
9. Create uncompressed ATPG patterns as you would for a design without EDT. For
example:
add_faults /my_core
create_patterns
report_scan_volume
Be sure to add faults only on the core of the design (assumed to be “/my_core” in this
example) and disregard the EDT logic.
The report_scan_volume command provides information for analyzing pattern data and
achieved compression.
Uncompressed ATPG patterns that utilize the bypass circuitry are generated.
10. Save the results to the TSDB.
ANALYSIS> write_tsdb_data -replace
This command writes the results of the TSDB, including the flat model, the TCD, the
PatDB pattern file, and the fault list. This information is useful for pattern retargeting
and diagnosis.
11. Save the patterns in parallel and serial Verilog format.
ANALYSIS> write_patterns ../generated/patterns_edt_p.v -verilog -replace -parallel
ANALYSIS> set_pattern_filtering -sample 2
ANALYSIS> write_patterns ../generated/patterns_edt_s.v -verilog -replace -serial
12. Save the patterns in tester format. For example WGL.

ANALYSIS> write_patterns ../generated/test_patterns.wgl -wgl -replace
Related Topics
Uncompressed ATPG (External Flow) and Boundary Scan
Uncompressed ATPG (External Flow) and

Boundary Scan
When using boundary scan with the external compressed pattern flow, you can use any tool to
insert boundary scan. There are two approaches that are typically used to configure the TAP
controller when you insert boundary scan.
• Drive the minimal amount of the EDT control circuitry with the TAP controller, so the
boundary scan simply coexists with EDT.
• Drive the EDT logic clock, update, and bypass signals with the TAP controller.
Note
As mentioned previously, boundary scan cells must not be present in your design before you
add the EDT logic. This requirement also applies to I/O pads. You must enable compressed
ATPG to create the EDT logic as a wrapper around your core design.
For more information on the overall external compressed pattern flow, see “Compressed Pattern
Boundary Scan Coexisting With EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Drive Compressed ATPG With the TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Boundary Scan Coexisting With EDT Logic

This section describes how EDT logic can coexist with boundary scan and provides a flow
reference for this methodology. This approach enables the EDT logic to be controlled by
primary input pins and not by the boundary scan circuitry. In test mode, the boundary scan
circuitry just needs to be reset. Also, all PIs and POs are directly accessible.
1. Preparation for Synthesis of Boundary Scan and EDT Logic
2. Modification of the Dofile and Procedure File for Boundary Scan
Preparation for Synthesis of Boundary Scan and EDT Logic

Prior to synthesizing the EDT logic and boundary scan circuitry, you should ensure any scripts
used for synthesis include the boundary scan circuitry. For example, the Design Compiler
synthesis script that compressed ATPG generates needs the following modifications (shown in
bold font) to ensure the boundary scan circuitry is synthesized along with the EDT logic:
Note
The modifications are to the example script shown in “Design Compiler Synthesis Script
/************************************************************************
** Synopsys Design Compiler synthesis script for created_edt_bs_top.v
**
************************************************************************/
/* Read input design files */

read -f verilog created_core_blackbox.v
read -f verilog created_edt.v
read -f verilog created_edt_top.v
read -f verilog edt_top_bscan.v
/*ADDED*/
current_design edt_top_bscan /*MODIFIED*/
/* Check design for inconsistencies */

check_design
/* Timing specification */
create_clock -period 10 -waveform {0,5} edt_clock
create_clock -period 10 -waveform
{0,5} tck /*ADDED*/
/* Avoid clock buffering during synthesis. However, remember */

/* to perform clock tree synthesis later for edt_clock */
set_clock_transition 0.0 tck
/*ADDED*/
set_dont_touch_network tck
/*ADDED*/
/* Avoid assign statements in the synthesized netlist.

/* Compile design */
uniquify
set_dont_touch cpu
/* Report design results for EDT logic */

report_area > created_dc_script_report.out
report_constraint -all_violators -verbose >>
report_timing -path full -delay max >> created_dc_script_report.out
report_reference >> created_dc_script_report.out
/* Remove top-level module */

remove_design cpu
/* Read in the original core netlist */

read -f verilog gate_scan.v
current_design edt_top_bscan
/*MODIFIED*/
link
/* Write output netlist using a

new file name*/
write -f verilog -hierarchy -o created_edt_bs_top_gate.v /*MODIFIED*/
After you have made any required modifications to the synthesis script to support boundary
scan, you are ready to synthesize the design—see “The EDT Logic Synthesis Script” on
page 123.
Modification of the Dofile and Procedure File for Boundary Scan

To correctly operate boundary scan circuitry, you need to edit the dofile and test procedure file
created by compressed ATPG.
Note
The information in this section applies only when the design includes boundary scan.
Typical changes include:
• The internal scan chains are one level deeper in the hierarchy because of the additional
level added by the boundary scan wrapper. This needs to be taken into consideration for
the add_scan_chains command.
• The boundary scan circuitry needs to be initialized. This typically requires you to revise
both the dofile and test procedure file.
• You may need to make additional changes if you drive compressed ATPG signals with
the TAP controller.
In the simplest configuration, the EDT logic is controlled by primary input pins, not by the
boundary scan circuitry. In test mode, the boundary scan circuitry just needs to be reset.
Following is the same dofile shown in “EDT IP Generation Dofiles” on page 370, except now it
includes the changes (shown in bold font) necessary to support boundary scan when configured
simply to coexist with EDT logic. The boundary scan circuitry is assumed to include a TRST
asynchronous reset for the TAP controller.
add_scan_groups grp1 modified_edt.testproc
add_scan_chains -internal chain1 grp1 /core_i/cpu_i/edt_si1

/core_i/cpu_i/edt_so1
add_clocks 0 clk
add_clocks 0 edt_clock
add_input_constraints tms -C1
add_input_constraints edt_clock -C0
set_edt_options -channels 1 -ip_version 1
The test procedure file, created_edt.testproc, shown in “EDT IP Generation Dofiles” on

page 370, must also be changed to accommodate boundary scan circuitry that you configure to
simply coexist with EDT logic. Here is that file again, but with example changes for boundary
scan added (in bold font). This modified file was saved with the new name
modified_edt.testproc, the name referenced in the fifth line of the preceding dofile.
set time scale 1.000000 ns ;

set strobe_window time 100 ;
timeplate gen_tp1 =
force_pi 0 ;
measure_po 100 ;
pulse clk 200 100;
pulse edt_clock 200 100;
pulse ramclk 200 100;
period 400 ;
end;
procedure capture =
timeplate gen_tp1 ;
cycle =
force_pi ;
measure_po ;
pulse_capture_clock ;
end;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
force edt_update 0 ;
measure_sco ;
pulse clk ;
pulse edt_clock ;
end;
end;
procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force clk 0 ;
force edt_bypass 0 ;
force edt_clock 0 ;
force ramclk 0 ;
force scan_en 1 ;
pulse edt_clock ;
end ;
apply shift 26;
end;
procedure test_setup =
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
...
force tms 1;
force tck 0;
force trst 0;
end;
cycle =
Drive Compressed ATPG With the TAP Controller
force trst 1;
end;
end;
Drive Compressed ATPG With the TAP Controller

You can drive one or more compressed ATPG signals from the TAP controller; however, there
are a few more requirements and restrictions than in the simplest case where the boundary scan
just coexists with EDT logic.
Some of these requirements and restrictions apply when you set up the boundary scan circuitry,
others when you generate patterns:
• If you want to completely drive the EDT logic from the TAP controller, you first should
decide on an instruction to drive the EDT channels.
• To ensure the TAP controller stays in the proper state for shift as well as capture during
EDT pattern generation, you should specify TCK as the capture clock. This requires a
“set_capture_clock TCK -atpg” command in the EDT dofile that causes the capture
clock TCK to be pulsed only once during the capture cycle.
• Also, the TAP controller must step through the Exit1-DR, Update-DR, and Select-DR-
Scan states to go from the Shift-DR state to the Capture-DR state. This requires three
intervening TCK pulses between the pulse corresponding to the last shift and the
capture. These three pulses need to be suppressed for the clock supplied to the core.
• The EDT update signal is usually asserted during the first cycle of the load/unload
procedure, so as not to restrict clocking in the capture window. Typically, the EDT clock
must be in its off state in the capture window. Because there is already a restriction in
the capture window due to the “set_capture_clock TCK -atpg” command, you can
supply the EDT clock from the same waveform as the core clock without adding any
more constraints. To update the EDT logic, the EDT update signal must now be asserted
in the capture window. You can use the Capture-DR signal from the TAP controller to
drive the EDT update signal.
• You should also modify any synthesis scripts to include the boundary scan circuitry. For
an example of a Design Compiler script with the necessary changes, see “Preparation for
Synthesis of Boundary Scan and EDT Logic” on page 243.
Use of Pipeline Stages in the Compactor

Pipeline stages can sometimes improve the overall rate of data transfer through the logic in the
compactor by increasing the scan shift frequencies. Pipeline stages are flip-flops that hold
intermediate values output by a logic level so that values entering that logic level can be updated
earlier in a clock cycle. Because the EDT logic is relatively shallow, most designs do need
compactor pipeline stages to attain the needed shift frequency. The limiting factors on shift
frequencies are usually the performance of the scan chains and power considerations.
Use of Pipeline Stages in the Compactor
You can enable the addition of pipeline stages in the compactor with the
set_edt_options -pipeline_logic_levels_in_compactor command when creating the EDT logic.
Pipeline stages added to the compactor use the EDT clock and lockup cells as described in
“Lockups Between Scan Chain Outputs and Compactor” on page 261.
Note
The -pipeline_logic_levels_in_compactor switch specifies the maximum number of
combinational logic levels (XOR gates) between compactor pipeline stages, not the number
of pipeline stages. The number of logic levels between any two pipeline stages controls the
propagation delay between pipeline stages.
Use of Pipeline Stages Between Pads and Channel Inputs or Outputs
Use of Pipeline Stages Between Pads and

Channel Inputs or Outputs
When the signal propagation delay between a pad and the corresponding channel input or output
is excessive, you may want to add pipeline stages. Use the guidelines provided in this section to
add pipeline stages between a top-level channel input pin/pad and the corresponding
decompressor input, or between a compactor output and the corresponding channel output pin/
pad. The number of pipeline stages on each input/output channel can vary.
Typically, pipeline stages are inserted throughout the design during top-level design integration.
Pipeline stages are generally not placed within the EDT logic.
Note
You must use the set_edt_pins -pipeline_stages command during test pattern generation to
enable channel pipeline stages. You must also modify the associated test procedure file as
described in this section.

Clocks for Channel Output Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Input Channel Pipelines Must Hold Their Value During Capture. . . . . . . . . . . . . . . . . 253
DRC for Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
DRC for Channel Output Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Input/Output Pipeline Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Channel Output Pipelining

To support channel output pipelines, the tool ensures there are enough shift cycles per pattern to
flush out the pipeline and observe all scan chains.
The number of cycles needed to fully load the scan chains determines the limit of how many
output pipeline stages can be added without increasing the number of shift cycles.
Figure 8-21 illustrates the factors that determine the number of pipeline stages that can be added
without any shift penalty; the number of stages depends on the number of decompressor
initialization cycles and the number of input pipeline stages.
Channel Input Pipelining
Figure 8-21. Channel Outputs and Pipelining
In the figure, 118 cycles are required to fully load the scan chains because the data has to shift
from the primary channel input (on the left) through the last scan cell in the longest scan chain.
Only 104 cycles are needed to fully unload the scan chains from the first scan cell in the chains
to the primary channel output. Because 118 cycles are needed to fully load and unload the scan
chains, up to 14 additional output pipeline stages can be added without any shift penalty.
Channel Input Pipelining

While the contents of the channel output pipeline stages at the beginning of shifting each pattern
are irrelevant because the process flushes them out, the contents of the channel input pipeline
stages do matter because they go to the decompressor when shifting begins (just after the
decompressor is initialized in the load_unload procedure).
The tool adds an additional test pattern before every test pattern set. This test pattern initializes
the channel input pipelining stages before the load of the very first real test pattern.
The number of additional shift cycles is typically incremented by the number of channel input
pipeline stages. If the number of additional shift cycles is four without input pipelining, and the
channel input with the most pipeline stages has two stages, the number of additional shift cycles
in each test pattern is incremented to six.
Clocks for Channel Input Pipeline Stages
If you have a choice between using either input or output pipeline stages, you should choose
output stages for the following reasons:
• The number of shift cycles for the same number of pipeline stages is higher when the
pipeline stages are on the input side.
• You must ensure that input channel pipelines hold their value during the capture cycle.
For information on how to do this, see “Input Channel Pipelines Must Hold Their Value
During Capture” on page 253.
Clocks for Channel Input Pipeline Stages

If you use channel input pipelining, you must ensure there is no clock skew between the channel
input pipeline and the decompressor. If you use channel output pipelining, you must ensure
there is no clock skew between the compactor (if you also use compactor pipelining) and the
channel output pipeline, or between the scan chain outputs (if no compactor pipelining is used)
and the channel output pipeline.
On the input side, the pipeline stages are connected to the decompressor, which is clocked by
the leading edge of the EDT clock. If the channel input pipeline is not clocked by the EDT
clock, a lockup cell must be inserted between the pipeline and the decompressor.
Note
EDT patterns saved for application through bypass mode (write_patterns -edt_bypass) may
not work correctly if the first cell of a chain, driven by channel input pipeline stages in
bypass mode, captures on the trailing edge of the clock. This is because that first cell of the
chain, which is normally a primary, becomes a copy of the last input pipeline stage in bypass
mode. To resolve this, you must add a lockup cell that is clocked on the trailing edge of a shift
clock at the end of the pipeline stages for a particular channel input. This ensures that the first
cell in the scan chain remains a primary.
Clocks for Channel Output Pipeline Stages

On the output side, the last state element driving the channel output is either a compactor
pipeline stage clocked by the EDT clock or the last elements of the scan chains when the
compactor has no pipelining. In addition to ensuring no clock skew between the chains/
compactor and the pipeline stages, you must ensure that the first pipeline stages capture on the
leading edge (LE) when no compactor pipelining is used. This is because if the last scan cell in
a chain captures on the LE and the path from the last scan cell to the channel pipeline is
combinational, and the channel pipeline stage captures on the trailing edge (TE), the pipeline
stage is essentially a copy during shift and the last scan cell no longer gets observed.
To ensure there is no clock skew between the pipeline stages and the compactor outputs, you
can use the set_edt_pins -change_edge_on_compactor_output command to specify whether
compactor output data changes on the LE or TE of the EDT clock. For example, specify the
Input Channel Pipelines Must Hold Their Value During Capture
compactor output changes at the trailing edge of the clock before feeding LE pipeline stages.
Depending on your application, compressed ATPG automatically inserts lockup cells and
output channel pipeline stages as needed. For more information, see set_edt_pins in the Tessent
Shell Reference Manual.
If you use pipeline stages clocked with the rising edge of the edt_clock, the tool inserts lockup
cells in the IP Creation phase to balance clock skew on the output side pipeline registers. For
more information, see “Lockups in the Bypass Circuitry” on page 262.
Note
If the clock used for the pipeline stages is not a shift clock, it must be pulsed in the shift
procedure.
Input Channel Pipelines Must Hold Their Value

During Capture
The tool adds an additional test pattern before every test pattern set to initialize channel input
pipelining stages before the load of the first test pattern. You must ensure that the values that get
shifted into the input pipeline stages at the end of shift (for every pattern) are not changed
during capture.
As mentioned earlier in “Channel Input Pipelining” on page 251, following the initialization
pattern, the tool ensures that every generated pattern has sufficient trailing zeros (ones for
channels with pad inversion) to set the pipeline stages to zeros/ones after every pattern is shifted
in.
You can ensure this in one of the following ways:
• Constrain the clock used for the pipeline stages off.

• Constrain the channel input pin to 0 (or 1 in case of channel inversion).
Note
During scan pattern retargeting or when EDT Mapping or EDT Finder is enabled
(EDT Finder is enabled by default), TestKompress automatically adds proper
constraints to input channels if pipelines are detected and their clocks are not
constrained off during capture. For more information on EDT mapping and EDT Finder,
see set_edt_mapping and set_edt_finder in the Tessent Shell Reference Manual. For
more information on scan pattern retargeting, see “Scan Pattern Retargeting” in the
Tessent Scan and ATPG User’s Manual.
Because the EDT clock is already constrained during the capture cycle, and drives the
decompressor (no clock skew), using the EDT clock to control the input pipeline stages
is recommended.
DRC for Channel Input Pipelining
Note
If the pipeline stages use the EDT clock, the channel pins must be forced to zero (or
one if there is channel inversion) in load_unload as well, because the EDT clock is
pulsed there as well (to reset the decompressor and update the mask logic).
TestKompress automatically adds the needed force statements in the load_unload
procedure if you have not already added them.
DRC for Channel Input Pipelining

The K19 and K22 design rules detect errors in initializing the channel input pipeline stages. If
the pipeline is not correctly initialized for the first pattern, K19 reports mismatches on the EDT
block channel inputs - assuming the hierarchy is not dissolved and the EDT logic is identified. If
the EDT logic channel inputs cannot be located, for example because the design hierarchy was
dissolved, K19 reports that Xs are shifted out of the decompressor. On the EDT logic channel
inputs, the simulated values would mismatch within the first values shifted out, while the rest of
the bits subsequently applied would match.
If the pipeline is correctly initialized for the first pattern and K19 passes, but the pipeline
contents change (during capture or the following load_unload prior to shift) such that it no
longer contains zeros, K22 fails. K19 and K22 detect these cases if input channel pipelining is
defined and issue warnings about the possible problems related to channel pipelining.
DRC for Channel Output Pipelining

The K20 rule check considers channel output pipelining, in addition to any compactor
pipelining that may exist. K20 reports any discrepancy between the number of identified and
specified pipeline stages between the scan chains and pins (including compactor and channel
output pipelines).
If the first stage of the channel output pipeline is TE instead of LE, this results in one less cycle
of delay than expected, which also triggers a K20 violation. If the first stage is TE, and you
specify one less pipeline stage, those two errors may mask each other, which means no violation
is reported. However, this may result in mismatches during serial pattern simulation.
Input/Output Pipeline Examples

These pipeline examples demonstrate and input with two pipeline stages and an output with one
pipeline stage and the modified load_unload procedure with the user-supplied events to support
pipelining.
The following command defines two pipeline stages for input channel 1:
set_edt_pins input_channel 1 -pipeline_stages 2
Change Edge Behavior in Bypass and EDT Modes
This example sets the EDT context to core1 (EDT context is specific to modular compressed
ATPG and is explained in “Modular Compressed ATPG” on page 161), and then specifies that
all output channels of the core1 block have one pipeline stage:
set_current_edt_block core1
set_edt_pins output_channel -pipeline_stages 1
Following is the modified load_unload procedure for a design with two channels having input
pipelining; edt_channel1 has inversion and edt_channel2 does not. The input pipeline stages are
clocked by the EDT clock, edt_clock. The user-added events that support pipelining are shown
in bold and comments are shown in italics.
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
// To ensure the values shifted into the input pipeline stages at
// the end of shift are not changed during capture, you must force
// channel pins with pipelines to zero (or one if there is channel
// inversion) because edt_clock is pulsed in load_unload and is
// also used for the pipeline stages.
force edt_channel1 1 ;
force edt_channel2 0 ;
force system_clk 0 ;
force edt_clock 0 ;
force ramclk 0 ;
force scan_en 1 ;
pulse edt_clock ;
end;
apply shift 21 ;
end;
Change Edge Behavior in Bypass and EDT

Modes
The output side compaction logic combines the scan outputs of multiple internal scan chains
into an EDT channel output. In the general case, the last scan cell of scan chains may be clocked
by different clocks and edges. Tessent TestKompress can add logic to ensure a uniform change
edge at the compactor output. By default, the tool uses the trailing edge (TE) as the change edge
for both bypass mode (multi- and single-mode bypass chains) and EDT mode (compactor
output).
Note
The default TE change edge is optimal for channel pipelining. If you choose to change the
default to the leading edge or any edge, ensure that no channel pipeline stages are added
later in the flow, because this could cause timing issues.
Change Edge Behavior in Bypass and EDT Modes
In bypass mode, the tool adds a retiming cell at the end of every bypass chain as needed to
ensure the same edge as EDT mode. Similarly, the tool also ensures that the default capture
edge (for the first cell) for every bypass chain is changed to LE. That is, the tool adds an LE
retiming flop at the beginning of every bypass chain, as needed. The added bypass chain mode
input capture and output change edge cell are clocked by the same clock driving the first or last
scan cell, respectively. This clock waveform may not be aligned with the EDT clock waveform.
In EDT mode, the default TE compactor change edge is not suitable for the following situations:
• The channel output pipeline register is TE and clocked by system clock. In this case,
there may be clock skew issues between the compactor change edge register clocked by
edt_clock and the channel pipeline register clocked by system clock.
To avoid this case, change the channel output pipeline register clock to LE.
• When the design has a JTAG controller and TDO output is used as a channel output. In
this case, there may be clock skew issues between compactor change edge register
clocked by edt_clock and TDO change TE register clocked by tck.
To avoid this case, specify change edge leading for this channel output. Assuming the
first channel output is TDO, you can specify this with the following commands:
set_edt_pins output_channel -change_edge_at_compactor_output leading \
for {set channel 2} {$channel <= $n_channels} {incr channel} \
{ set_edt_pins output_channel $channel \
-change_edge_at_compactor_output trailing}
Understanding Lockup Cells
Understanding Lockup Cells

The tool analyzes the timing relationships of the clocks that control the sequential elements
between the scan chains and the EDT logic and inserts edge-triggered flip-flops (lockup cells)
when necessary to synchronize the clocks and ensure data integrity.
You can use the report_edt_lockup_cells command to display a detailed report of the lockup
cells the tool has inserted.

Lockup Cell Analysis for Bypass Lockup Cells Not Included as Part of the EDT Chains
259
Lockup Cell Analysis for Bypass Lockup Cells Included as Part of the EDT Chains . 267
Lockups Between Channel Outputs and Output Pipeline Stages . . . . . . . . . . . . . . . . . . 275
Lockup Cell Insertion

The tool analyzes the relationship between the clock that controls each sequential element
sourcing data (source clock) and the clock that controls the sequential element receiving the
data (destination clock).
The tool inserts a lockup cell when the source and destination clocks overlap as follows:
• Both clocks have identical waveform timing within a tester cycle; clocks are on at the
same time and their edges are aligned.
• The active edge of the destination clock occurs later in the cycle than the active edge of
the source clock.
When clocks are non-overlapping, data is protected by the timing sequence and no lockup cells
are inserted.
Note
Partially overlapping clocks are not supported.
You can set up the EDT logic clock and scan chain shift clocks to be non-overlapping by
pulsing the EDT clock before the shift clock of each scan chain. When the EDT logic is set up in
this manner, there is no need for lockup cells between the EDT logic and scan chains. However,
a lockup cell driven by the EDT clock is still inserted between all bypass scan chains. For more
information, see “Pulse EDT Clock Before Scan Shift Clocks” on page 83.
If your design contains a mix of overlapping and non-overlapping clocking, or the shift clocks
are pulsed before the EDT logic clock, you must let the tool analyze the design and insert
lockup cells (default behavior), as described in “Lockup Cell Analysis for Bypass Lockup Cells
Lockup Cell Insertion
Not Included as Part of the EDT Chains” on page 259 and “Lockup Cell Analysis for Bypass
Lockup Cells Included as Part of the EDT Chains” on page 267.
Lockup Cell Analysis for Bypass Lockup Cells Not

Included as Part of the EDT Chains
Lockup cell analysis is performed for bypass lockup cells that are not included as part of the
EDT chains. This happens for lockups between decompressor and scan chain inputs, lockups
between scan chain outputs and the compactor, and lockups in the bypass circuitry.
Lockups Between Decompressor and Scan Chain Inputs . . . . . . . . . . . . . . . . . . . . . . . . 259
Lockups Between Scan Chain Outputs and Compactor . . . . . . . . . . . . . . . . . . . . . . . . . 261
Lockups in the Bypass Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Lockups Between Decompressor and Scan Chain Inputs

The decompressor is located between the scan channel input pins and the scan chain inputs. It
contains sequential circuitry clocked by the EDT clock. As the off state of the EDT clock (at the
EDT logic module port) is always 0, leading edge triggered (LE) flip-flops are used in this
sequential circuitry. Scan chain clocking does not utilize the EDT clock. Therefore, there is a
possibility of clock skew between the decompressor and the scan chain inputs.
For each scan chain, the tool analyzes the clock timing of the last sequential element in the
decompressor stage (source) and the first active sequential element in the scan chain
(destination).
Note
The first sequential element in the scan chain could be an existing lockup cell (a transparent
latch for example) and may not be part of the first scan cell in the chain.
The tool analyzes the need for lockup cells on the basis of the waveform edge timing (change
edge and capture edge, respectively) of the source and destination clocks. The change edge is
typically the first time at which the data on the source scan cell’s output may update. The
capture edge is the capturing transition at which data is latched on the destination scan cell’s
output. The tool inserts lockup cells between the decompressor and scan chains based on the
following rules:
• A lockup cell is inserted when a source cell’s change edge coincides with the destination
cell’s capture edge.
• A lockup cell is inserted when the change edge of the source cell precedes the capture
edge of the destination cell.
In addition, the tool attempts to place lockup cells in a way that introduces no additional delay
between the decompressor and the scan chains and tries to minimize the number of lockup cells
at the input side of the scan chains. The lockup cells are driven by the EDT clock to reduce
routing of the system clocks from the core to the EDT logic.
Table 8-4 summarizes the relationships and the lockup cells the tool inserts on the basis of the
preceding rules, assuming there is no pre-existing lockup cell (transparent latch) between the
decompressor and the first scan cell in each chain.
Table 8-4. Lockup Cells Between Decompressor and Scan Chain Inputs
Clock Source Dest. Source1 Dest.1, 2 # Lockups Lockup3
Waveforms Clock Clock Change Capture Inserted Edge(s)
Edge Edge
Overlapping EDT clock Scan clock LE LE 1 TE
EDT clock Scan clock LE TE 2 TE, LE
EDT clock Scan clock LE active high 2 TE, LE
(TE)
EDT clock Scan clock LE active low 1 TE
(LE)
Non- EDT clock Scan clock LE LE 2 TE, LE
Overlapping4 EDT clock Scan clock LE TE 2 TE, LE
EDT clock Scan clock LE active high 2 TE, LE
(TE)
EDT clock Scan clock LE active low 2 TE, LE
(LE)
1. LE = Leading edge, TE = Trailing edge.
2. Active high/low = Active clock level when destination is a latch. Active high means the latch is active when
the primary input (PI) clock is on. Active low means the latch is active when the PI clock is off. (LE) or (TE)
indicates the clock edge corresponding to the latch’s capture edge.
3. Lockup cells are driven by the EDT clock.
4. These are cases for which the tool determines that the source edge precedes the destination edge. (Lockups
are unnecessary if the destination edge precedes the source edge).
To minimize the number of lockup cells added, the tool always adds a trailing edge triggered
(TE) lockup cell at the output of the Linear Feedback Shift Machine (LFSM) in the
decompressor. The tool adds a second LE lockup cell at the input of the scan chain only when
necessary, as shown in Table 8-4.
Note
If there is a pre-existing transparent latch between the decompressor and the first scan cell, a
single lockup cell (LE) is added between the decompressor and the latch. This ensures the
correct value is captured into the first scan cell from the decompressor.
Lockups Between Scan Chain Outputs and Compactor

When compactor pipeline stages are inserted, lockup cells are inserted as needed in front of the
first pipeline stage. Pipeline stages are LE flip-flops clocked by the EDT clock, similar to the
sequential elements in the decompressor.
The clock timing between the last active sequential element in the scan chain (source) and the
first sequential element (first pipeline stage) that it feeds in the compactor (destination) is
analyzed. Similar to the input side of the scan chains, the tool analyzes the need for lockup cells
on the basis of the waveform edge timings (change edge and capture edge, respectively, of the
source and destination clocks). The change edge is typically the first time at which the data on
the source scan cell’s output may update. The capture edge is the capturing transition at which
data is latched on the destination scan cell’s output.
Lockup cells driven by the EDT clock are added according to the following rules:
cell’s capture edge.
In addition, the tool attempts to place lockup cells in a way that introduces no additional delay
between the scan chains and the compactor pipeline stages. It also tries to minimize the number
of lockup cells at the output side of the scan chains. The lockup cells are driven by the EDT
clock so as to reduce routing of the system clocks from the core to the EDT logic.
Table 8-5 shows how the tool inserts lockup cells in the compactor.
Table 8-5. Lockup Cells Between Scan Chain Outputs and Compactor
Clock Source Dest. Source1,2 Dest.1 # Lockups Lockup3
Edge Edge
Overlapping Scan clock EDT clock LE LE 1 TE
Scan clock EDT clock TE LE none -
Scan clock EDT clock active high LE 1 TE
(LE)
Scan clock EDT clock active low LE none -
(TE)
Table 8-5. Lockup Cells Between Scan Chain Outputs and Compactor (cont.)
Clock Source Dest. Source1,2 Dest.1 # Lockups Lockup3
Edge Edge
Non- Scan clock EDT clock LE LE 1 TE
Overlapping4 Scan clock EDT clock TE LE 1 TE
Scan clock EDT clock active high LE 1 TE
(LE)
Scan clock EDT clock active low LE 1 TE
(TE)
2. Active high/low = Active clock level when source is a latch. Active high means the latch is active when
the primary input (PI) clock is on. Active low means the latch is active when the PI clock is off. (LE) or (TE)
indicates the clock edge corresponding to the latch’s change edge.
3. Lockup cells are driven by the EDT clock.
4. These are cases for which the tool determines that the source edge precedes the destination edge. (Lockups
are unnecessary if the destination edge precedes the source edge).
Lockups in the Bypass Circuitry

The number and location of lockup cells the tool inserts in the bypass logic depend on the active
edges (change edge and capture edge, respectively) of the source and destination clocks. The
change edge is typically the first time at which the data on the source scan cell’s output may
update. The capture edge is the capturing transition at which data is latched on the destination
scan cell’s output.
The number and location of lockup cells also depend on whether the first and last active
sequential elements in the scan chain are clocked by the same clock. The first and last active
sequential elements in a scan chain could be existing lockup cells and may not be part of a scan
cell. The tool inserts the lockup cells between source and destination scan cells according to the
following rules:
cell’s capture edge and the cells are clocked by different clocks.
• If multiple lockup cells are inserted, the tool ensures that:
o A primary/copy scan cell combination is always driven by the same clock. This
prevents the situation where captured data in the primary cell is lost because a
different clock drives the copy cell and is not pulsed in a particular test pattern.
o The earliest data capture edge of the last lockup cell is not before the latest time
when the destination cell can capture new data. This makes the first scan cell of
every chain a primary and prevents D2 DRC violations.
o If the earliest time when data is available at the output of the source is before the
earliest data capture edge of the first lockup, the first lockup cell is driven with the
same clock that drives the source.
• If a lockup cell already exists at the end of a scan chain, the tool learns its behavior and
treats it as the source cell.
Table 8-6 summarizes how the tool inserts lockup cells in the bypass circuitry.
Table 8-6. Bypass Lockup Cells
Clock Source1 Dest.1 Source2, 3 Dest.2, 3 # Lockups Lockup Edge(s)
Waveforms Clock Clock Change Capture Inserted
Edge Edge
Overlapping clk1 clk1 LE LE none -
clk1 clk1 LE TE 1 TE clk1
clk1 clk1 TE TE none -
clk1 clk1 TE LE none -
Overlapping clk1 clk2 LE LE 1 TE clk1
clk1 clk2 LE TE 2 LE clk1, TE clk2
clk1 clk2 TE TE 2 LE clk1, TE clk2
clk1 clk2 TE LE none -
Non-Overlapping4 clk1 clk2 LE LE 2 LE clk1, TE clk2
clk1 clk2 LE TE 2 LE clk1,
TE clk2
clk1 clk2 TE TE 2 LE clk1, TE clk2
clk1 clk2 TE LE 2 LE clk1, TE clk2
Overlapping clk1 clk1 active high active high 1 TE clk1
(LE) (TE)
clk1 clk1 active high active low 1 TE clk1
(LE) (LE)
clk1 clk1 active low active low none -
(TE) (LE)
clk1 clk1 active low active high none -
(TE) (TE)
Table 8-6. Bypass Lockup Cells (cont.)

Edge Edge
Overlapping clk1 clk2 active high active high 2 LE clk1, TE clk2
(LE) (TE)
clk1 clk2 active high active low 1 TE clk1
(LE) (LE)
clk1 clk2 active low active low none -
(TE) (LE)
clk1 clk2 active low active high 2 LE clk1, TE clk2
(TE) (TE)
Non-Overlapping4 clk1 clk2 active high active high 2 LE clk1, TE clk2
(LE) (TE)
clk1 clk2 active high active low 2 LE clk1, TE clk2
(LE) (LE)
clk1 clk2 active low active low 2 LE clk1, TE clk2
(TE) (LE)
clk1 clk2 active low active high 2 LE clk1, TE clk2
(TE) (TE)
Overlapping clk1 clk1 LE active high 1 TE clk1
(TE)
clk1 clk1 LE active low none -
(LE)
clk1 clk1 active high LE none -
(LE)
clk1 clk1 active low LE none -
(TE)

Edge Edge
Overlapping clk1 clk2 LE active high 2 LE clk1, TE clk2
(TE)
clk1 clk2 LE active low 1 TE clk1
(LE)
clk1 clk2 active high LE 1 TE clk1
(LE)
clk1 clk2 active low LE none -
(TE)
Non-Overlapping4 clk1 clk2 LE active high 2 LE clk1, TE clk2
(TE)
clk1 clk2 LE active low 2 LE clk1, TE clk2
(LE)
clk1 clk2 active high LE 2 LE clk1, TE clk2
(LE)
clk1 clk2 active low LE 2 LE clk1, TE clk2
(TE)
Overlapping clk1 clk1 TE active high none -
(TE)
clk1 clk1 TE active low none -
(LE)
clk1 clk1 active high TE 1 TE clk1
(LE)
clk1 clk1 active low TE none -
(TE)

Edge Edge
Overlapping clk1 clk2 TE active high 2 LE clk1, TE clk2
(TE)
clk1 clk2 TE active low 2 LE clk1, TE clk2
(LE)
clk1 clk2 active high TE 2 LE clk1, TE clk2
(LE)
clk1 clk2 active low TE 2 LE clk1, TE clk2
(TE)
Non-Overlapping4 clk1 clk2 TE active high 2 LE clk1, TE clk2
(TE)
clk1 clk2 TE active low 2 LE clk1, TE clk2
(LE)
clk1 clk2 active high TE 2 LE clk1, TE clk2
(LE)
clk1 clk2 active low TE 2 LE clk1, TE clk2
(TE)
1. clk1 & clk2 are the functional (scan) clocks.
3. Active high/low = Active clock level when source or destination is a latch. Active high means the latch is
active when the primary input (PI) clock is on. Active low means the latch is active when the PI clock is off.
(LE) or (TE) indicates the clock edge corresponding to the latch’s change/capture edge.
4. These are cases for which the tool determines the source edge precedes the destination edge. (Lockups are
unnecessary if the destination edge precedes the source edge).
Lockup Cell Analysis for Bypass Lockup Cells Included as Part of the EDT Chains
Lockup Cell Analysis for Bypass Lockup Cells

Included as Part of the EDT Chains
The tool adds lockup cells at the scan chain boundary to eliminate bypass-only lockup cells.
Note
See “Differences Based on Inclusion/Exclusion of Bypass Lockup Cells in EDT Chains” on
page 269 for a thorough explanation of the differences that result when bypass lockup cells
are included in the EDT chain as opposed to when they are not.
The tool analyzes the clocking of first and last active scan elements and adds lockup cells at
scan chain inputs and outputs as required. These cells are added to ensure each scan chain starts
with a LE register and ends with a TE register. These lockup cells are included as part of both
EDT and EDT-bypass scan chains. They avoid clock skew problems between the decompressor
and scan chains, scan chains and compactor, as well as when concatenating EDT scan chains
into bypass chains. They also provide the ability to map EDT mode patterns into bypass mode.
As an exception, when all of the first and last scan elements are driven by the LE of the same
clock and the compactor has no sequential registers, scan chain output lockup cells are added
only for the last internal chain grouped into bypass chains.
EDT Lockup and Scan Chain Boundary Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Differences Based on Inclusion/Exclusion of Bypass Lockup Cells in EDT Chains . . . 269
Lockup Cell Functionality Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Comparison of Bypass Lockup Cell Insertion Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
EDT Lockup and Scan Chain Boundary Lockup Cells

When lockup cells at chain boundaries are inserted, the tool combines the analysis of
decompressor and compactor lockup cells along with the scan chain input/output bypass lockup
cells.
Table 8-7 summarizes how the tool adds lockup cells for different clocking configurations.
Table 8-7. EDT Lockup and Scan Chain Boundary Lockup Cells
Clock EDT Scan Chain Scan Chain Compactor
(source → destination) Decompressor Input Output Lockup
(last cell → first cell) Lockup Cells1 Lockup Lockup Cell 1
Same source and destination clocks
LE clk → LE clk TE edt_clock - TE clk -
LE clk → LE clk2 TE edt_clock - - -
LE clk → TE clk TE edt_clock LE clk TE clk -
Table 8-7. EDT Lockup and Scan Chain Boundary Lockup Cells (cont.)
TE clk → LE clk TE edt_clock - - -
TE clk → TE clk TE edt_clock LE clk - -
Overlapping clocks, clkS and clkD
LE clkS → LE clkD TE edt_clock - TE clkS -
LE clkS → TE clkD TE edt_clock LE clkD TE clkS -
TE clkS → LE clkD TE edt_clock - - -
TE clkS → TE clkD TE edt_clock LE clkD - -
Non-overlapping clocks, clkS overlaps with edt_clock, clkD later than edt_clock & clkS
LE clkS → LE clkD TE edt_clock LE clkS TE clkS -
LE clkS → TE clkD TE edt_clock LE clkS TE clkS -
TE clkS → LE clkD TE edt_clock LE clkS - -
TE clkS → TE clkD TE edt_clock LE clkS - -
Non-overlapping clocks, clkS and clkD (either same or different clocks) later than
edt_clock
LE clkS → LE clkD TE, LE edt_clock - TE clkS -
LE clkS → TE clkD TE, LE edt_clock LE clkD TE clkS -
TE clkS → LE clkD TE, LE edt_clock - - -
TE clkS → TE clkD TE, LE edt_clock LE clkD - -
Overlapping clocks, same or different
active high clkS (LE) → TE edt_clock LE clkD TE clkS -
active high clkD (TE)
active high clkS (LE) → - - TE clkS -
active low clkD (LE)
active low clkS (TE) → TE edt_clock LE clkD - -
active low clkS (TE) → TE edt_clock - - -
LE clkS → TE edt_clock LE clkD TE clkS -
Table 8-7. EDT Lockup and Scan Chain Boundary Lockup Cells (cont.)
LE clkS → TE edt_clock - TE clkS -
TE clkS → TE edt_clock LE clkD - -
TE clkS → TE edt_clock - - -
active high clkS (LE) → TE edt_clock - TE clkS -
LE clkD
active high clkS (LE) → TE edt_clock LE clkD TE clkS -
TE clkD
active low clkS (TE) → TE edt_clock - - -
LE clkD
active low clkS (TE) → TE edt_clock LE clkD - -
TE clkD
1. Decompressor and compactor lockup cells are not included as part of the EDT scan chains.
2. Special case where all scan cells are clocked by a single LE clock.This optimization is applicable
only when lockup cells are not required in the compactor, except for making compactor change edge as
trailing. Any of compactor pipelining, TK/LBIST (due to MISR lockup), dual configuration may
necessitate compactor lockup.
Differences Based on Inclusion/Exclusion of Bypass

Lockup Cells in EDT Chains
The behavior of the tool in adding decompressor/compressor lockup cells and scan chain lockup
cells is based on factors such as whether lockup cells are included as part of the EDT scan
chains during pattern generation, the edges of the scan cells in the chains, and whether single
bypass chain functionality is specified.
Complete information on how the tool adds lockup cells when they are not included in EDT
chains is presented in “Lockup Cell Analysis for Bypass Lockup Cells Not Included as Part of
the EDT Chains” on page 259.
Internal Scan Chain Definition

Figure 8-22 illustrates the internal scan chain definition anchor points (scan inputs and scan
outputs) during pattern generation when bypass lockup cells are not included as part of the EDT
scan chains.
Figure 8-22. Scan Chain and Bypass Lockup Cells Not in the EDT Scan Chain
You can insert bypass lockup cells such that they are included as part of the EDT scan chains.
This enables the tool to detect the actual bypass lockup cells and account for them correctly.
Figure 8-23 illustrates the internal scan chain definition anchor points (scan inputs and scan
outputs) when bypass lockup cells are included as part of the EDT scan chains.
Figure 8-23. Scan Chain and Bypass Lockup Cells in the EDT Scan Chain
Note
The lockup cells inside bypass logic are now included as part of the EDT scan chains as
well. The first level lockup cells for the decompressor are still excluded from the scan chain
definition as is the case when bypass lockup cells are not included as part of the EDT scan
chains.
Insertion Algorithm When Bypass Lockup Cells are Included at the Boundary of the EDT
Chains
As shown in Figure 8-23, when bypass lockup cells are included in the EDT scan chain,
TestKompress does the following:
• If the last scan cell is a LE scan cell, the tool adds a TE lockup cell clocked by the last
scan cell clock to the scan chain output.
• If the first scan cell is a TE scan cell, the tool adds a LE lockup cell to the scan chain
input.
• If all of the scan chains are clocked by the LE of the same clock, the tool makes an
exception and adds lockup cells only for the last internal scan chain of each bypass
chain. This facilitates the concatenation of the bypass chains of an EDT block at a higher
level.
• The LE lockup cell at the scan chain input is clocked by the source scan clock if it has an
early waveform compared with the destination scan clock; otherwise, the lockup cell is
clocked by the destination scan clock.
• The second decompressor lockup cell is not required when the destination scan cell is a
TE with the same waveform as the EDT clock. When the first scan cell has a late clock,
the second decompressor lockup cell is included only if the lockup cell at the last scan
chain output is pulsed with a late clock.
• The new lockup cell can influence EDT and compactor lockup cells because these new
lockup cells are visible in the EDT path and are cumulative with dedicated EDT-only
lockup cells in the decompressor and compactor.
• Compactor lockup cell analysis includes the source lockup cell at the scan chain output.
In particular, if a TE source lockup cell is needed for a bypass lockup cell, it is also used
for a compactor lockup cell.
Single Bypass Chain
When using this functionality, bypass lockup cells are also added to the input of the first and
output of the last internal chains grouped into a bypass chain. This enables the regular bypass
chains to be easily concatenated to form the single bypass chain for the entire EDT block.
The lockup cells for bypass mode concatenation also enable concatenating the single bypass
chain of all EDT blocks declared in the tool during IP creation. TestKompress does not actually
concatenate the single bypass chains of the EDT blocks; rather TestKompress facilitates the
process for some other tool to make such a concatenation.
You can concatenate the single bypass chains of all the EDT blocks in a design to construct a
system-wide single bypass chain, even across blocks not declared in IP creation. In such cases,
if the source clock from the preceding EDT block is pulsed earlier than the destination clock
from the succeeding EDT block in the system-wide single chain concatenation order, these scan
cells become a primary-copy pair. This should be properly accounted for when translating EDT
mode patterns into the single system-wide bypass chain patterns.
Lockup Cell Functionality Limitations

The lockup cell functionality cannot be used with certain features.
The following features are not compatible with lockup cells:
• Generating a blackbox for the EDT logic using “set_edt_options -blackbox on” —
When including bypass lockup cells in EDT scan chains, the scan chains are defined on
the EDT decompressor and compactor instance pins in the EDT logic. The instance pins
are not available in a blackbox description of the EDT module.
• Pulsing EDT clock before shift clock — Because the bypass lockup cells are clocked
by edt_clock in this case, including them as part of the scan chains results in D1
violations on all the lockup cells at scan chain inputs.
Comparison of Bypass Lockup Cell Insertion Results

This section compares the circuitry created by bypass lockup cell insertion depending upon
whether the bypass lockup cell is included or excluded from the EDT chain.
Case 1: No Bypass Lockup Cell

Figure 8-24 illustrates the circuitry when the bypass lockup cell insertion algorithm does not
insert any lockup cells: on the left is the circuitry when bypass lockup cells are excluded from
EDT chains, and on the right is the circuitry when they are included in EDT chains.
When both the last and first scan cells are TE and clocked by the same clock, a LE lockup cell is
added to the destination scan chain input. In this case, the second decompressor lockup cell in
the EDT decompressor is not added. This is shown in Figure 8-24. This is an example that
demonstrates the case when the bypass lockup cell affects the EDT decompressor lockup cell.
Figure 8-24. TE CLK to TE CLK
Case 2: One Bypass Lockup Cell

When bypass lockup cells are excluded from the EDT chain, the tool inserts one bypass lockup
cell in the following cases:
• If LE clk to TE clk, the tool inserts a TE clk lockup as illustrated, on the left, in
Figure 8-25. Note, the absence of the second decompressor lockup cell, on the right, in
Figure 8-25.
Figure 8-25. LE Clk to TE Clk
• If LE clk1 to LE clk2, the tool inserts a TE clk1 lockup as illustrated, on the left, in
Figure 8-26.
Figure 8-26. LE Clk1 to LE Clk2 Overlapping
Case 3: Two Bypass Lockup Cells

Figure 8-27 illustrates the case where the tool infers two lockup cells in both cases, but the clock
edges of the lockup cells are different. This case applies when both clkS and clkD are
overlapping with the EDT clock, and when clkS overlaps with the EDT clock but clkD has a
late waveform.
Lockups Between Channel Outputs and Output Pipeline Stages
Figure 8-27. LE ClkS to TE ClkD
Figure 8-28 illustrates the case when the destination cell is TE, but the same situation applies
when the destination cell is LE.
Figure 8-28. ClkS to ClkD, Both Clocks Later Than EDT Clock
Lockups Between Channel Outputs and Output

Pipeline Stages
During the top-level design integration process, clocking requirements may require you to insert
lockup cells between the EDT logic and pad terminals. If the clocking of the last scan cells
compacted into an output channel and the clocking of the output pipeline stage (outside the EDT
logic) overlap, you must add a lockup cell (outside the EDT logic). Tessent Shell in the EDT IP
Creation phase does not insert these lockup cells.
However, if internal compactor pipelining is enabled in the EDT logic, and the output pipeline
stages are active on the leading edge (LE) of the EDT clock, no lockup cells are necessary
because the internal compactor pipeline stages also use the leading edge (LE) of the EDT clock.
Lockups Between Channel Outputs and Output Pipeline Stages
If the output pipeline stages use a different edge or clock, the existing lockup cells may be
insufficient, and you must specify the change edge for the compactor outputs or insert lockup
cells manually. When you specify the change edge for the compactor outputs, the tool inserts
pipeline stages and lockup cells as needed to ensure the compactor outputs change as specified.
You use the set_edt_pins command with the -CHange_edge_at_compactor_output option to

specify the change edge for the compactor outputs. Depending on the change edge specified for
the compactor outputs, the tool inserts lockup cells between the compactor output and output
channels as described in Table 8-8.
Table 8-8. Lockup Insertion Between Channel Outputs and Output Pipeline
-CHange_edge_at_compactor_ Compactor Lockup Last Lockup Inserted
Output Pipeline Between Scan Scan Between
Stages Chain and Cell Compactor
Compactor Output and
Output
Channels
LEading_edge_of_edt_clock LE1 NA2 NA none3
none LE NA none
none TE NA LE
none none LE none
none none TE4 LE
TRailing_edge_of_edt_clock LE NA NA TE
none LE NA TE
none TE NA none
none none LE TE
none none TE none
1. “LE” indicates the leading edge of the clock pulse.
2. “NA” indicates the state of that column has no effect on the resulting action described in the right-most
column (Lockup inserted between compactor output and output channels).
3. “None” indicates the object does not exist or is not inserted.
4. “TE” indicates the trailing edge of the clock pulse.
Related Topics
Use of Pipeline Stages Between Pads and Channel Inputs or Outputs
Compression Performance Evaluation
Compression Performance Evaluation

Focus on the parts of the compressed ATPG flow that are necessary to perform experiments on
compression rates and performance so you can make informed choices about how to fine-tune
performance.
Figure 8-29 illustrates the typical evaluation flow.
Figure 8-29. Evaluation Flow
The complete Tessent TestKompress flow is described in “Top-Down Design Flows” on

page 44.
In an experimentation flow, where your intention is to verify how well EDT works in a design,
you generate compressed patterns and use these patterns to verify coverage and pattern count,
but not to perform final testing. Consequently, you do not need to write out the hardware
description files. The first thing you should do, though, to make the data you obtain from
running compressed ATPG meaningful, is establish a point of reference using uncompressed
ATPG.
Establishing a Point of Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Performance Measurement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Establishing a Point of Reference
Establishing a Point of Reference

The following steps describe the flow for establishing a point of reference for evaluating the
performance of the compression. A design configured with eight scan chains is assumed.
To illustrate how you establish a point of reference using uncompressed ATPG, assume as a
starting point that you have both a non-scan netlist and a netlist with eight scan chains. You
would calculate the test data volume for measuring compression performance in the following
way:
Note
#patterns may provide a reasonable approximation for #scan loads, but be aware that some
patterns require multiple scan loads.
For a regular scan-based design without EDT, the volume per scan load remains fairly constant
for any number of scan chains because the number of shifts decreases when the number of
chains increases. Therefore, it does not matter which scan chain configuration you use when
you establish the reference point.
Procedure
1. Invoke Tessent Shell on your design.
2. Set the context, read in the netlist with eight scan chains and a library, and set the current
design.
read_verilog mydesign_scan_8.v
3. Run the dofile that performs basic setup.

dofile atpg_8.dofile
4. Run DRC and verify that no DRC violations occur.

5. Generate patterns. Assuming the design does not have RAMs, you can just generate
basic patterns. To speed up the process, use fault sampling. It is important to use the
same fault sample size in both the uncompressed and compressed runs.
Performance Measurement
add_faults /cpu_i
create_patterns
report_statistics
report_scan_volume
6. Note the test coverage and the total data volume as reported by the report_scan_volume
command.
Performance Measurement
In the compressed and uncompressed runs, you should examine some statistics to assist with
your evaluation.
Specifically, the numbers you should examine include the following:
• Test coverage (report_statistics)

• CPU time (report_statistics)
• Scan data volume (report_scan_volume)
• Observable X sources (E5) violations, which can explain lower compression
performance.
• Runs to compare results with and without fault sampling.
Performance Improvement
There are some analyses you can do if the measured performance is not as expected.
Table 8-9 lists some suggested analyses.
Table 8-9. Summary of Performance Issues
Unsatisfactory Result Suggested Analysis
Compression - Many observable X sources. Examine E5 violations.
- Too short scan chain vs. # of additional shift cycles.1Verify the
# of additional shift cycles, and scan chain length using the
report_edt_configurations command.
Run time - Untestable/hard to compress patterns. If they cause a high
runtime for uncompressed ATPG, they also cause a high runtime
for compressed ATPG.
- If compressed ATPG has a much larger runtime than
uncompressed ATPG, examine X sources, E5 violations.
Coverage - Shared scan chain I/Os. Scan pins are masked by default. These
pins should be dedicated.
- Too aggressive compression (chain-to-channel ratio too high),
leading to incompressible patterns. Use the report_aborted_faults
command to debug. Look for EDT aborted faults.
1. Additional shift cycles refers to the sum of the initialization cycles, masking bits (when using
Xpress), and low-power bits (when using a low-power decompressor).
Variance in the Number of Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Variance in the Number of Scan Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Determining the Limits of Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Speed up the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Variance in the Number of Scan Chains

The effective compression depends primarily on the ratio between the number of internal scan
chains and the number of external scan channels. In most cases, it is sufficient to just do an
approximate configuration. For example, if the number of scan channels is eight and you need
4X compression, you can configure the design with 38 chains. This typically results in 3.5X to
4.5X compression.
In certain cases, such a rough estimate is not enough. Usually, the number of scan channels is
fixed because it depends on characteristics of the tester. Therefore, to experiment with different
compression outcomes, different versions of the netlist (each with a different number of scan
chains) are necessary.
Related Topics
Variance in the Number of Scan Channels
Variance in the Number of Scan Channels

Another alternative to varying the number of scan chains in order to evaluate compression
performance, is to use a design with a relatively high number of scan chains and experiment
with different numbers of channels. You can do these experiments, varying the chain-to-channel
ratio. Then, when you find the optimum ratio, reconfigure the scan chains to match the number
of scan channels you want. You can achieve similar test data volume reduction for a 100:10
configuration as for a 50:5 configuration.
For example, assume you have a design with 350,000 gates and 27,000 scan cells. If a certain
tester requires the chip to have 16 scan channels, and your compression goal is to have no less
than 4X compression, you might proceed as follows:
1. Determine the approximate number of scan chains you need. This example assumes a
reasonable estimate is 60 scan chains.
2. Use Tessent Scan to configure the design with many more scan chains than you
estimated, say, 100 scan chains.
3. Run the tool for 30, 26, 22, and 18 scan channels. Notice that these numbers are all
between 1-2X the 16 channels you need.
Note
Use the same commands with compressed ATPG that you used with uncompressed
ATPG when you established a point of reference, with one exception: with
compressed ATPG, you must use the set_edt_options command to reconfigure the
number of scan channels.
Suppose the results show that you achieve 4X compression of the test data volume using 22
scan channels. This is a chain-to-channel ratio of 100:22 or 4.55. For the final design, where you
want to have 16 scan channels, you would expect approximately a 4X reduction with 16 x 4.55
= 73 scan chains.
Determining the Limits of Compression

The maximum amount of compression you can attain is limited by the ratio of scan chains to
channels. If the number of scan channels is fixed, the number of scan chains in your design
becomes the limiting factor.
Understanding Compactor Options
For example, if your design has eight scan chains, the most compression you can achieve under
optimum conditions is less than 8X compression. To exceed this maximum, you must
reconfigure the design with a higher number of scan chains.
Related Topics
Speed up the Process

If you need to perform multiple iterations, either by changing the number of scan chains or the
number of scan channels, you can speed up the process by using fault sampling. When you use
fault sampling, first perform uncompressed ATPG with fault sampling. Then, use the same fault
sample when generating compressed patterns.
Note
You should always use the entire fault list when you do the final test pattern generation. Use
fault sampling only in preliminary runs to obtain an estimate of test coverage with a
relatively short test runtime. Be aware that sampling has the potential to produce a skewed
result and is a means of estimation only.
Related Topics

There are two compactors available in compressed ATPG, Xpress and basic.
• Xpress
The Xpress compactor is the second generation compactor generated by default. The
Xpress compactor optimizes compression for all designs but is especially effective for
designs that generate X values. The Xpress compactor observes all chains with known
values and masks out scan chains that contain X values. This X handling results in fewer
test patterns being required for designs that generate X values.
Depending on the application, the EDT logic generated with the Xpress compactor
requires additional clocking cycles. The additional clocking cycles are determined by
the ratio of scan chains to output channels and are relatively few when compared with
the total shift cycles.
• Basic
The basic compactor is the first generation compactor enabled with the -compactor_type
basic switch with the set_edt_options command.
The basic compactor should be used for designs that do not generate many unknown (X)
values. Due to scan cell masking, the basic compactor is significantly less effective on
designs that generate unknown (X) values in scan cells when a test pattern is applied.
The EDT logic generated when the basic compactor is used may be up to 30% smaller
than EDT logic generated when the Xpress compactor is used. However, when X values
are present, more test patterns may be required.
Basic Compactor Architecture

Figure 8-30. Basic Compactor
A mask code (prepended with a decoder mode bit) is generated with each test pattern to
determine which scan chains are masked or observed. The basic compactor determines which
chains to observe or mask using the mask code as follows:
1. The decompressor loads the mask code into the mask shift register.
2. The mask code is parallel-loaded into the mask hold register, where the decoder mode
bit determines the observe mode: either one scan chain or all scan chains.
3. The mask code in the mask hold register is decoded and each bit drives one input of a
masking AND gate in the compactor. Depending on the observe mode, the output of
these AND gates is either enabled or turned off.
Xpress Compactor Architecture

Figure 8-31. Xpress Compactor
A mask code (prepended with a decoder mode bit) is generated with each test pattern to
determine which scan chains are masked or observed. The Xpress compactor determines which
chains to observe or mask using the mask code as follows:
1. Each test pattern is loaded into the decompressor through a mask shift register on the
input channel.
2. The mask code is appended to each test pattern and remains in the mask shift register
once the test pattern is completely loaded into the decompressor.
3. The mask code is then parallel-loaded into the mask hold register, where the decoder
mode bit determines whether the basic decoder or the XOR decoder is used on the mask
code.
o The basic decoder selects only one scan chain per compactor. The basic decoder is
selected when there is a very high rate of X values during scan testing or during
chain test to enable failing chains to be fully observed and easy to diagnose.
o The XOR decoder masks or observes multiple scan chains per compactor, depending
on the mask code. For example, if the mask code is all 1s, then all the scan chains are
observed.
Understanding Scan Chain Masking in the Compactor
4. The decoder output is shifted through a multiplexer, and each bit drives one input on the
masking AND gates in the compactor to either turn off or enable the output, depending
on the decoder mode and bit value.
Understanding Scan Chain Masking in the

Compactor
It is important to use scan chain masking in the compactor in order to ensure accurate scan chain
observations.
Why Masking is Needed

To facilitate compression, the tool inserts a compactor between the scan chain outputs and the
scan channel outputs. In this circuitry, one or more stages of XOR gates compact the response
from several chains into each channel output. Scan chains compacted into the same scan
channel are said to be in the same compactor group.
One common problem with different compactor strategies is handling of Xs (unknown values).
Scan cells can capture X values from unmodeled blocks, memories, non-scan cells, and so forth.
Assume two scan chains are compacted into one channel. An X captured in Chain 1 then blocks
the corresponding cell in Chain 2. If this X occurs in Chain 1 for all patterns, the value in the
corresponding cell in Chain 2 can never be measured. This is illustrated in Figure 8-32, where
the row in the middle shows the values measured on the channel output.
Figure 8-32. X-Blocking in the Compactor
The tool records an X in the pattern file in every position made unmeasurable as a result of the
actual occurrence of an X in the corresponding cell of a different scan chain in the same
compactor group. This is referred to as X blocking. The capture data for Chain 1 and Chain 2
that you would see in the ASCII pattern file for this example would look similar to Figure 8-33.
The Xs substituted by the tool for actual values, unmeasurable because of the compactor, are
shown in red.
Figure 8-33. X Substitution for Unmeasurable Values
Resolving X Blocking With Scan Chain Masking

The solution to this problem is a mechanism utilized in the EDT logic called “scan chain
masking.” This mechanism enables selection of individual scan chains on a per-pattern basis.
Two types of scan chain masking are used: 1-hot masking and flexible masking.
• With 1-hot masking, only one chain is observed via each scan channel's compaction
network. All the other chains in that compactor are masked so they produce a constant 0
to the input of the compactor. This enables observation of fault effects for the observed
chains even if there are Xs in the observation cycles for the other chains. 1-hot masking
patterns are only generated for a few ATPG cycles at points when the non-masking and
flexible masking algorithms fail to detect any significant number of faults.
• Flexible masking patterns enable multiple chains to be observed via each scan channel's
compaction network. Flexible masking is not fully non-masking; with fully non-
masking patterns, none of the chains are masked so Xs in some cycles of some chains
can block the observation of the fault effects in some other chain. The Xpress compactor
observes all chains with known values and masks out those scan chains that contain X
values so they do not block observation of other chains. With Xpress flexible masking,
only a subset of the chains is masked to maximize the fault detection profile while
reducing the impact on pattern count. When a fault effect cannot be observed at the
channel output under any of the flexible masking configurations, the tool uses 1-hot
masking to guarantee the detection of such faults.
Figure 8-34 shows how scan chain masking would work to resolve X blocking for the case in
“Why Masking is Needed” on page 285. For one pattern, only the values of Chain 2 are
measured on the scan channel output. This way, the Xs in Chain 1 do not block values in Chain
2. Similar patterns would then also be produced where Chain 2 is turned off while the values of
Chain 1 are observed on the scan channel output.
Figure 8-34. Example of Scan Chain Masking
When using scan chain masking, the tool records the actual measured value for each cell in the
unmasked, selected scan chain in a compactor group. The tool masks the rest of the scan chains
in the group, which means the tool changes the values to all Xs. With masking, the capture data
for Chain 1 and Chain 2 that you would see in the ASCII pattern file would look similar to
Figure 8-35, assuming Chain 2 is to be observed and Chain 1 is masked. The values the tool
changed to X for the masked chain are shown in red.
Figure 8-35. Handling of Scan Chain Masking
Following is part of the transcript from a pattern generation run for a simple design where
masked patterns were used to improve test coverage. The design has three scan chains, each
containing three scan cells. One of the scan chain pins is shared with a functional pin, contrary
to recommended practice, in order to illustrate the negative impact such sharing has on test
coverage.
Fault Aliasing
// ------------------------------------------------------
// Simulation performed for #gates = 134 #faults = 68
// system mode = analysis pattern source = internal patterns
// ---------------------------------------------------------
// #patterns test #faults #faults #eff. #test
// simulated cvrg in list detected patterns patterns
// deterministic ATPG invoked with abort limit = 30
// --- ------ --- --- --- ---
// 32 82.51% 16 47 6 6
// --- ------ --- --- --- ---
// Warning: Unsuccessful test for 10 faults.
// deterministic ATPG invoked with abort limit = 30
// EDT with scan masking.
// --- ------ --- --- --- ---
// 96 91.26% 0 16 6 12
// --- ------ --- --- --- ---
The transcript shows six non-masked and six masked patterns were required to detect all faults.
Here’s an excerpt from the ASCII pattern file for the run showing the last unmasked pattern and
the first masked pattern:
pattern = 5;
apply "edt_grp1_load" 0 =
chain "edt_channel1" = "00011000000";
end;
force "PI" "100XXX0" 1;
measure "PO" "1XXX" 2;
pulse "/CLOCK" 3;
apply "grp1_unload" 4 =
chain "chain1" = "1X1";
end;
pattern = 6;
apply "edt_grp1_load" 0 =
chain "edt_channel1" = "11000000000";
end;
force "PI" "110XXX0" 1;
measure "PO" "0XXX" 2;
pulse "/CLOCK" 3;
apply "grp1_unload" 4 =
chain "chain1" = "XXX";
chain "chain2" = "111";
chain "chain3" = "XXX";
end;
The capture data for Pattern 6, the first masked pattern, shows that this pattern masks chain1 and
chain3 and observes only chain2.
Fault Aliasing
Another potential issue with the compactor used in the EDT logic is called fault aliasing.
Assume one fault is observed by two scan cells, and that these scan cells are located in two scan
Fault Aliasing
chains that are compacted to the same scan channel. Further, assume that these cells are in the
same locations (columns) in the two chains and neither chain is masked.
The following figure illustrates this case. Assume that the good value for a certain pattern is a 1
in the two scan cells. This corresponds to a 0 measured on the scan channel output, due to the
XOR in the compactor. If a fault occurs on this site, 0s are measured in the scan cells, which
also result in a 0 on the scan channel output. For this unique scenario, it is not possible to see the
difference between a good and a faulty circuit.
Figure 8-36. Example of Fault Aliasing
The solution to this problem is to utilize scan chain masking. The tool does this automatically.
In compressed ATPG, a fault that is aliased is not marked detected for the unmasked pattern
(refer to the previous figure). Instead, the tool uses a masked pattern as shown in the following
figure. This mechanism guarantees that all potentially aliased faults are securely detected. Cases
in which a fault is always aliased and requires a masking pattern to detect it are rare.
Figure 8-37. Using Masked Patterns to Detect Aliased Faults
About Reordering Patterns
About Reordering Patterns

In Tessent Shell, you can reorder patterns using static compaction.
You reorder patterns with the compress_patterns command, and pattern optimization with the
order_patterns command. You can also use split pattern sets by, for example, reading a binary
or ASCII pattern file back into the tool, and then saving a portion of it using the -Begin and
-End options to the write_patterns command.
The tool does not support reordering of serial EDT patterns by a third-party tool, after the
compressed patterns are saved.
This has to do with what happens in the compactor when two scan chains have different lengths.
Suppose two scan chains are compacted into one channel, as illustrated in Figure 8-38. Chain 1
is six cells long and Chain 2 is three cells long. The captured values of the last three bits of
Chain 1 are going to be XOR’d with the first three values of the next pattern being loaded into
Chain 2. For regular ATPG, this problem does not occur because the expected values on Chain
2, after you shift three positions, are all Xs. So you never observe the values being loaded as
part of the next pattern. But, if that is done with EDT, the last three positions of Chain 1 are
XOR’d with X and faults observed on these last cells are lost. Because the padding data for the
shorter scan chains is derived from the scan-in data of the next pattern, avoid reordering serial
patterns to ensure valid computed scan-out data.
Figure 8-38. Handling Scan Chains of Different Length
Handling of Last Patterns

In order to completely shift out the values contained in the final capture cycle, the tool shifts in
the last pattern one additional time so that the output matches the calculated value.
When the design contains chains of different lengths, the tool pads the shorter chains using the
values generated by the decompressor during next pattern load. The calculated expected values
on the last pattern unload are based on loading the last pattern one more time.
Caution
Modifying the last pattern load causes mismatches.
EDT Aborted Fault Analysis

When creating compressed patterns, some faults may not be detected and become classified as
EDT Aborted (EAB). While a fault may become EAB due to insufficient encoding capacity,
linear dependency or other reason, it is important to understand what design characteristics may
be contributing to coverage loss.
Analysis Overview
A fault is classified as EDT Aborted (EAB) when the test cube (EAB test cube) for the fault is
not compressible. Normally, the test coverage loss caused by EAB faults is small but in some
special situations there may be many EAB faults, causing notable test coverage loss. Using
EAB analysis, you can identify the common scan cell(s) that are involved in many EAB test
cubes.
Tessent TestKompress records a number of EAB test cubes during each create_patterns session
for analysis after the session. By default, the tool analysis a minimum of 1000 EAB test cubes.
Using the set_edt_abort_analysis_options command, you can change the default. After issuing
the create_patterns command, you can report the analysis results of the stored EAB test cubes
using the report_edt_abort_analysis command. Using this command, you can customize the
report output so that it contains the most specified shift positions, the most specified scan cells,
and details to inspect the EAB test cubes.
Note
For some designs, the number of EAB faults analyzed by the tool may be higher than the
number of EAB faults in the output of the report_statistics command. This can happen when
a fault is considered EAB during pattern generation (when this analysis is performed) but it is
later detected during simulation of a subsequent pattern.
A design may contain multiple EDT blocks and test cube encoding failure may occur in more
than one EDT block. The analysis, however, is only performed for the first failing EDT block.
For example, if an EAB test cube has specified bits in 3 EDT blocks and the tool found that the
bits in the first EDT block cannot successfully be encoded, the analysis thereafter for this EAB
test cube only considers the bits specified in this block. Bits from other blocks are ignored for
the rest of the analysis.
Results Analysis
When performing EAB fault analysis, focus your efforts on data that can most efficiently help
identify problems and that can be addressed in the design, EDT configuration, or tool setup. As
such, it is important to understand the following scenarios:
• If an EAB test cube specifies many more bits in an EDT block than the total number of
variables the tool can supply for that block in one pattern, it is expected that the test cube
cannot be compressed. Given that the number of specified bits are simply too large, it
may not be worthwhile to perform analysis for this type of test cubes. The implemented
command enables the user to specify the analysis range for the collected EAB test cubes
so that such test cubes can be skipped.
• Note that a variable is one bit shifted from the tester into the EDT decompressor, and
ultimately used to provide the decompressed data shifted into scan chains. If the number
of bits specified by ATPG exceeds about 90% of the variables shifted into the
decompressor, there is a high probability that the test cannot be compressed.
• An EAB test cube may specify a large number of bits in the failing block but not all bits
are relevant in terms of compressibility. It is possible that only a few bits in this block
cannot be compressed when specified by themselves. These bits are the real problem
sources that should be analyzed and understood. The focus of the new tool feature is to
provide detailed report statistics for these bits. These responsible bits of an EAB test
cube are referred to as the smallest EAB test cube.
• When reporting a bit, the tool also reports the property of the bit, if such information is
available. For example, if the bit has a cell constraint, is a clock control condition bit, or
if the bit is part of the condition bits of an NCP. This information can help locate the
problem directly.
Chapter 9
Integrating Compression at the RTL Stage
You can create EDT logic during the RTL design phase, rather than waiting for the complete
synthesized gate-level design netlist. Creating the EDT logic early enables you to consider the
EDT logic earlier in the floor-planning, placement, and routing phases.
IP Generation and Insertion Using EDT Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Basic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Pipeline Stage Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Bused EDT Channel Input and Output Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Lockup Cells on the Input Side of the EDT Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Lockup Cells on the Output Side of the EDT Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 297
EDT Specification Wrapper Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Validating the EDT Specification and Creating the EDT IP . . . . . . . . . . . . . . . . . . . . . . . 300
Legacy Skeleton RTL Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Skeleton Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Skeleton Design Input and Interface Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Creation of the EDT Logic for a Skeleton Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Integration of the EDT Logic Into the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Skeleton Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
IP Generation and Insertion Using EDT Specification
IP Generation and Insertion Using EDT

Specification
The primary way of creating and, optionally, inserting EDT logic during the RTL stage is using
the configuration-based specification EDT wrapper contained in the DftSpecification wrapper.
Basic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Pipeline Stage Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Bused EDT Channel Input and Output Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Lockup Cells on the Input Side of the EDT Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Lockup Cells on the Output Side of the EDT Controller. . . . . . . . . . . . . . . . . . . . . . . . . 297
EDT Specification Wrapper Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Validating the EDT Specification and Creating the EDT IP. . . . . . . . . . . . . . . . . . . . . . 300
Basic Flow
The EDT specification flow is used to create and optionally insert the EDT IP into your RTL. In
general, this flow consists of creating the EDT specification, validating the specification, and
generating the EDT IP.
At its most basic level, an EDT specification is an ASCII file that describes your EDT IP using
configuration data syntax to encode the specification. You input this EDT specification into
Tessent Shell, which creates the EDT IP and, if you specify, inserts the IP into your RTL.
Flow Limitations
With the EDT specification RTL flow, you cannot specify the first and last scan cell of each
chain. EDT IP is created with the assumption that all scan chains are inserted with a leading-
edge cell for the first scan cell and a trailing-edge cell for the last scan cell. This is a limitation
with this flow.
Requirements
To create EDT logic during the RTL stage, you must know the following parameters for your
design:
• Number of external scan channels.

• Number of internal scan chains.
• Longest scan chain length range. This is an estimate of the minimum number of scan
cells and maximum number of scan cells the tool can expect in the longest scan chain.
Pipeline Stage Insertion
You should also have knowledge about the design interface if you are creating/inserting the
EDT logic external to the design core.
Flow Overview
The EDT specification flow with Tessent Shell consists of the following steps:
1. Create the EDT specification wrapper that describes the EDT IP you require using the
configuration-based specification—see “EDT Specification Wrapper Creation” on
page 298.
2. Validate and process the EDT specification. During this step, you create in IJTAG
network to create connection points for the EDT IP and generate the EDT IP. You can
also inserted the created EDT IP into your RTL during this step—see “Validating the
EDT Specification and Creating the EDT IP” on page 300.
Pipeline Stage Insertion

When using configuration-based specification EDT, the pipeline stage insertion order depends
on the order of the PipelineStage configuration data wrappers.
The tool inserts the pipeline stages in the design from left-to-right starting from the first
specified PipelineStage wrapper. For a single EDT input or output channel, you specify the first
pipeline stage using the wrapper placed above all other PipelineStage wrappers within the scope
of its parent wrapper. The same rule applies to the last pipeline stage, which is specified by the
wrapper placed below all other PipelineStage wrappers of the same configuration-based
specification data scope.
For EDT input channels the pipeline stage inserted closest to the EDT decompressor is the last
specified pipeline stage as in the following example configuration-based specification wrapper:
EdtChannelsIn(1) {
port_pin_name: top_channel_in1 ;
PipelineStage {
leaf_instance_name: pipe1 ;
}
PipelineStage {
}
PipelineStage {
}
}
In the above example, the insertion process creates three pipeline stages on the first EDT input
channel with “pipe3” placed closest to the EDT decompressor.
Bused EDT Channel Input and Output Connections
For EDT output channels, the tool inserts the first specified pipeline stage closest to the EDT
compactor as in the following example configuration-based specification wrapper:
EdtChannelsOut(1) {
port_pin_name: top_channel_out1 ;
PipelineStage {
}
PipelineStage {
}
PipelineStage {
}
}
In the above example, the insertion process creates three pipeline stages on the first EDT output
channel with “pipe1” placed closest to the EDT compactor.
Bused EDT Channel Input and Output Connections

Using the configuration-based specification EDT flow, you can specify bused EDT channel
input and output connections in a single wrapper.
The EdtChannelsIn and EdtChannelsOut accept multiple EDT channel index values using the
(id) component of the wrapper. When specified, the tool connects them to a bus or a list of ports
or pins by using a single EdtChannelsIn or EdtChannelsOut configuration-based specification
data wrapper.
For example:
EdtChannelsIn(4:1) {
port_pin_name : top_bus[3:0] ;
}
The tool connects the first four EDT input channels to the top_bus[3:0] port object. The first
EDT channel connects to top_bus[0] and the fourth channel connects to top_bus[3].
When specifying multiple index values using either EdtChannelsIn(id) or EdtChannelsOut(id),

the order of the EDT IP connections is determined by the order of the channel index range. The
tool performs the insertion “left to left” and “right to right”; given this, you should check if the
order of the channel index range is the same as the order of the bus or port list. If either the
channel index range or the connection bus range has a different order the created connections,
then the tool “swaps” the connections, that is the highest EDT IP channel is connected to the
LSB of the connection object.
The process_dft_specification command for EDT creates bus ports for EDT channel
connections on the block level as specified in the configuration data. If the bus ports exist
Lockup Cells on the Input Side of the EDT Controller
already, they are used for EDT channel connections. If they do not exist,
process_dft_specification creates them on the block level.
Limitation
When you specify at least one input connection, you must specify all values and ranges.
Lockup Cells on the Input Side of the EDT

Controller
If pipeline stages are inserted on the input side, a lockup cell is added between the last input
pipeline stage (counting from the top level EDT input channel port) and the EDT logic only if
the clock driving the last pipeline stage is different than the clock driving the EDT logic.
Figure 9-1 provides an example of a lockup cell on the input side:
Figure 9-1. Lockup Cell EDT Controller Input Side
Lockup Cells on the Output Side of the EDT

Controller
If pipeline stages are inserted on the output side then a lockup cell is always inserted after the
last output pipeline stage (counting from the EDT output channel pin on the EDT Controller).
Figure 9-2 provides an example of a lockup cell on the output side.
Lockup Cells Clock Connections
Figure 9-2. Lockup Cells on EDT Controller Output Side
Lockup Cells Clock Connections

Every pipeline stage can be clocked by a different source; however, when the tool automatically
inserts lockup cells, these cells use the clocks that drive the pipelines.
The tool connects the clock pin of every inserted lockup cell to the clock that drives the last
pipeline stage of EDT input or output channel as follows:
• On the input side, if the tool inserts a lockup cell, then the cell is driven by the clock
source of the pipeline stage closest to the EDT IP.
• On the output side, if the tool inserts a lockup cell, then the cell is driven by the clock of
the pipeline stage farthest from the EDT IP.
EDT Specification Wrapper Creation

The first step to integrating EDT IP into your RTL is creating the EDT specification wrapper.
The EDT wrapper and DftSpecification wrapper sections in the Tessent Shell Reference Manual
provide the complete syntax and options you use when creating your EDT specification
wrapper.
Once you have nested the EDT wrapper within the DftSpecification wrapper, then you use
Tessent Shell to process and validate your wrapper and create the EDT IP. Tessent Shell writes
the EDT IP output to the Tessent Shell Data Base (TSDB), a structured directory containing
subdirectories and files.
EDT Specification Wrapper Creation
EDT Specification Example

You manually create the EDT wrapper using the syntax described in “EDT” in the Tessent Shell
Reference Manual. The following example shows a basic EDT specification wrapper nested in a
DftSpecification wrapper you can use as a guide:
DftSpecification(CoreA,rtl) +{
EDT +{
Controller(1) +{
scan_chain_count : 16;
input_channel_count : 2;
output_channel_count : 2;
longest_chain_range : 100, 110;
separate_control_data_channels : on;
leaf_instance_name : edt_inst_new;
BypassChains {
present : on;
bypass_chain_count : 2;
single_bypass_chain : on;
}
Compactor {
type : xpress;
pipeline_logic_levels_in_compactor : 5;
}
Clocking {
type : edge;
lockup_cells : on;
retime_chain_boundaries : off;
reset_signal : off;
}
HighCompressionConfiguration {
present : on;
input_channel_count : 1;
output_channel_count : 1;
}
ShiftPowerOptions {
present : on ;
full_control : on ;
min_switching_threshold_percentage : 25 ;
}
Connections +{
edt_clock : clock1 ;
EdtChannelsIn(2) {
port_pin_name : user_control1_chin2;
}
EdtChannelsOut(1) {
port_pin_name : user_control1_chout1;
}
}
}
}
}
In the DftSpecification wrapper, you can only define the nested EDT specification once. Within
each Controller sub-wrapper, you specify using required configuration parameters, for example
basic scan chain and EDT channel information, for each EDT IP Controller you define.
Validating the EDT Specification and Creating the EDT IP
Validating the EDT Specification and Creating the

EDT IP
Use Tessent Shell to validate the DftSpecification containing the EDT specification and create
the EDT IP. The tool writes the EDT IP to TSDB. The first step of the EDT IP RTL flow is
inserting the IJTAG network. The IJTAG Network Insertion functionality enables you to
connect existing instruments and insert SIBs, TDRs, and ScanMuxes to create your own IJTAG
network. You can optionally insert the EDT IP into the RTL.
Prerequisites
• EDT Specification. See “EDT Specification Wrapper Creation” on page 298.
• A list of IDs that specify the Scan Resource Instrument (SIB) that are used to create the
Sib(id) wrappers in the IJTAG network. Refer to create_dft_specification in the Tessent
Shell Reference Manual for more information and “IJTAG Network Insertion” in the
Tessent IJTAG User’s Manual.
• Scan cell estimates. Refer to “Requirements” on page 294.
Procedure
1. From a shell, invoke Tessent Shell.
% tessent -shell
2. Set the context to “dft -rlt”.

SETUP> set_context dft -rtl
3. Read in the RTL.

SETUP> read_verilog CoreA.v
4. Set the current design and the design level.

SETUP> set_current_design rtl_design
SETUP> set_design_level physical_block
5. Set the TSDB directory location if other than the present working directory.
SETUP> set_tsdb_output_dir tsdbA
6. Add static DFT control signals. For example:

SETUP> add_dft_signals ltest_en int_ltest_en ext_ltest_en int_mode ext_mode
The add_dft_signals command specifies DFT signals used to control aspects of DFT
logic.
7. Add dynamic DFT control signals. For example:
SETUP> add_dft_signals scan_en -source_node scan_en
SETUP> add_dft_signals {test_clock edt_update} -source_nodes test_clock \
edt_upate
8. If you are using fast capture, then define functional clocks. For example:
SETUP> foreach clk [dict keys $FUNC_CLOCKS] {
add_clocks 0 $clk -period [dict get $FUNC_CLOCKS $clk]
}
9. Change from setup to analysis mode.

SETUP> check_design_rules
In RTL context, check_design_rules synthesizes the design in parts before creating the
flat model. Then it runs the DRC rules specific to the current context. If no DRC with a
severity of error fails, the tool enters analysis mode.
10. Create the IJTAG network, specifying the Sib IDs. For example:
ANALYSIS> create_dft_specification -sri_sib_list "edt"
Specifying the -sri_sib_list switch and string pair with create_dft_specification creates
connection points for the inserted EDT to connect to.
11. Obtain scan cell estimate to figure out number of EDT chains. For example:
set scannable_flop_count \
[sizeof_collection [get_gate_pins -filter \
{primitive_name==DFF && pin_index==0 && !is_non_scannable}]]
set scannable_flop_count \
[expr {$scannable_flop_count + 4*[llength [dict keys $FUNC_CLOCKS]]}]
puts "Estimated scan cell count: $scannable_flop_count"

Estimated scan cell count: 7766
set chain_count \
[expr {int(ceil($scannable_flop_count / $SCAN_CHAIN_LENGTH) \
* (1 + $CHAIN_COUNT_MARGIN))}]
(code) puts "Chain count: $chain_count"

Chain count: 41
12. Add EDT and the EDT Controller to the configuration tree created in the previous step.
ANALYSIS > add_config_element EDT -in_wrapper dftspec
ANALYSIS > add_config_element Controller(1) -in_wrapper dftspec
13. Connect to the EDT SIB. For example, the following Tcl proc:
set_config_value ijtag_host_interface "Sib(edt)" -in_wrapper $edt_cont
set_config_value scan_chain_count -in $edt_cont $chain_count
set_config_value input_channel_count -in $edt_cont $::EDT_IN_CHANNELS
set_config_value output_channel_count -in $edt_cont $::EDT_OUT_CHANNELS
set_config_value longest_chain_range -in $edt_cont $::LONGEST_CHAIN_RANGE
14. Validate and create the EDT IP based on the EDT specification.
ANALYSIS> process_dft_specification -no_insertion
The tool processes the DftSpecification and writes the EDT IP to the TSDB directory.
If required, you can also insert the EDT IP into your RTL by omitting the -no_insertion
switch to the process_dft_specification command.
15. Extract the ICL network:
ANALYSIS > extract_icl
Related Topics
add_config_element [Tessent Shell Reference Manual]
add_dft_signals [Tessent Shell Reference Manual]
check_design_rules [Tessent Shell Reference Manual]
create_dft_specification [Tessent Shell Reference Manual]
extract_icl [Tessent Shell Reference Manual]
process_dft_specification [Tessent Shell Reference Manual]
read_verilog [Tessent Shell Reference Manual]
set_config_value [Tessent Shell Reference Manual]
set_context [Tessent Shell Reference Manual]
set_current_design [Tessent Shell Reference Manual]
set_design_level [Tessent Shell Reference Manual]
set_tsdb_output_directory [Tessent Shell Reference Manual]
Legacy Skeleton RTL Flow
Legacy Skeleton RTL Flow

The legacy skeleton RTL flow uses the create_skeleton_design utility to create a skeleton
design.
Note
While you can still use the skeleton flow, moving to the “IP Generation and Insertion Using
EDT Specification” on page 294 is recommended to integrate EDT logic at the RTL stage.
Skeleton Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Skeleton Design Input and Interface Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Skeleton Design Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Skeleton Design Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Creation of the EDT Logic for a Skeleton Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Longest Scan Chain Range Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Integration of the EDT Logic Into the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Skeleton Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Input File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Skeleton Flow Overview

The create_skeleton_design utility is used to create a skeleton design.
Figure 9-3 shows the IP Creation RTL stage flow. The utility, create_skeleton_design is used to
create a skeleton design. This utility writes out a gate-level skeleton Verilog design and several
related files required to create EDT logic.
To use the create_skeleton_design utility, you must create a Skeleton Design Input File. The
Skeleton Design Input File contains the requisite number of scan chains with the first and last
cell of each of these chains driven by the appropriate clocks. For more information, see
“Skeleton Design Input File” on page 307.
If you are creating/inserting the EDT logic external to the design core, you must also create a
Skeleton Design Interface File. For more information, see “Skeleton Design Interface File” on
page 310.
Figure 9-3. EDT IP Creation RTL Stage Flow
Use the following steps to create EDT logic for an RTL design:
1. Create a Skeleton Design Input File. For more information, see “Skeleton Design Input
File” on page 307.
2. If you are inserting the EDT logic external to the core design (Compressed Pattern
External Flow), create a Design Interface File to provide the interface description of the
core design in Verilog format. For more information, see “Skeleton Design Interface
File” on page 310.
3. Run the create_skeleton_design utility. For example:
o Internal Flow:
create_skeleton_design -o output_file_prefix \
-i skeleton_design_input_file
o External Flow:
create_skeleton_design -o output_file_prefix \
-i skeleton_design_input_file -design_interface \
file_name
The utility writes out the following four files:

<output_file_prefix>.v — Skeleton design netlist
<output_file_prefix>.dofile — Dofile
<output_file_prefix>.testproc — Test procedure file
<output_file_prefix>.atpglib — Tessent cell library
For a complete example showing create_skeleton_design input files and the resultant
output files, see the “Skeleton Flow Example” on page 314.
4. Invoke Tessent Shell, set the correct context, and read the skeleton design netlist and the
Tessent cell library.
5. Provide compression setup commands.
o Run the dofile and test procedure file to set up the scan chains for the EDT logic.
o Issue the set_edt_options command to specify the number of scan channels. You
should use the -Longest_chain_range switch with this command to specify an
estimated length range (min_number_cells and max_number_cells) for the longest
scan chain in the design. For additional information, refer to “Longest Scan Chain
Range Estimate” on page 311.
6. Provide EDT DRC, configuration, and logic creation commands.
o Use the set_system_mode analysis command to flatten the design and run DRCs.
o Issue other configuration commands as needed.
o Write out the RTL description of the EDT logic with the write_edt_files command.
Skeleton Design Input and Interface Files

This section describes the inputs and outputs for the create_skeleton_design utility.
These inputs and outputs are illustrated in Figure 9-4. The Skeleton Design Input File is always
required. You need the Skeleton Design Interface File only if you plan to create the EDT logic
external to the core design (see “Compressed Pattern External Flow” on page 47). You must
create both files using the format and syntax described in the following subsections.
Figure 9-4. create_skeleton_design Inputs and Outputs
Skeleton Design Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Input File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Input File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Skeleton Design Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Skeleton Design Input File

Create the skeleton design input file using the rules described in the next section.
Input File Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Input File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Input File Format

This section describes the format of the input file for create_skeleton_design.
The example Skeleton Design Input File Format shows the format of the skeleton design input
file. Required keywords are highlighted in bold. This file contains distinct sections that are
described after the example. shows a small working example.
Figure 9-5. Skeleton Design Input File Format
// Description of scan pins and LSSD system clock with design interface
// (required)
scan_chain_input <prefix> <bused|indexed> [<starting_index_if_indexed>]
scan_chain_output <prefix> <bused|indexed> [<starting_index_if_indexed>]
lssd_system_clock <clock_name> // Any system clock for LSSD designs
scan_enable <scan_enable_name> // Any scan_enable pin name
// Clock definitions (required)

begin_clocks // Keyword to begin clock definitions
<clock_name> <off_state> // Clock name and off state
<clock_name> <off_state> // Clock name and off state
end_clocks // Keyword to end clock definitions
// Scan chain specification (required)

begin_chains // Keyword to begin chain
definitions
// first_chain_number and last_chain_number specify range of chains
// MUXD chain
<first_chain_number> <last_chain_number> <chain_length> \
<TE|LE> <first_cell_clock> <TE|LE> <last_cell_clock>
//LSSD chain
<first_chain_number> <last_chain_number> <chain_length> \
LA <first_cell_primary_clock> <first_cell_remote_clock> \
LA <last_cell_primary_clock> <last_cell_remote_clock>
end_chains // Keyword to end chain definitions
Scan Pins and LSSD System Clock Specification Section

Note
This section is required when you use the -Design_interface switch with
create_skeleton_design to enable the tool to create a correct instantiation of the core in the
top-level EDT wrapper (“Compressed Pattern External Flow” on page 47). If the scan pins
specified in this section are not present in the design interface, the utility automatically adds
them to the skeleton design. You can omit this section if you are not using the -Design_interface
switch.
In this section, specify the scan chain pin name prefix and the type, bused or indexed, using the
keywords, “scan_chain_input” and “scan_chain_output”. The bused option results in scan chain
pins being declared as vectors, that is, <prefix>[Max-1:0]. The indexed option results in scan
chain pins being declared as scalars, numbered consecutively beginning with the specified
starting index, and named in “<prefix><index>” format.
If you intend to share channel outputs, you can specify the name of a scan enable pin using the
“scan_enable” keyword. If you do not specify a scan enable pin, the tool automatically adds a
default pin named “scan_en” to the output skeleton design.
If the design contains LSSD scan cells, you can optionally use the lssd_system_clock keyword
to specify the name of any one LSSD system clock. If you do not specify a name, the tool uses
the default name, “lssd_system_clock”.
Clock Definition Section

In this section, specify clock names and their corresponding off states. The utility uses these off
states to create a correct skeleton dofile and skeleton test procedure file. (See the add_clocks
command for additional details about the meaning of clock off states.)
Scan Chain Specification Section

The scan chain specification section is the key section. Here, you specify the number of scan
chains, length of the chains, and clocking of the first and last scan cell.
Note
If the EDT logic clock is pulsed before the scan chain shift clock, you do not need to
account for the clocking of the first and last cell in each scan chain; this information is
evaluated. For more information, see “Pulse EDT Clock Before Scan Shift Clocks” on page 83.
To simplify and shorten this section, you can list, on one line, a range of chains that have the
same specifications. Each line should contain the chain number of the first chain in the range,
the chain number of the last chain in the range, length of the chains, and the edge and clock
information of the first and last scan cell. For IP creation with the skeleton flow, the length of
the scan chains can be any value not less than 2, but typically 2 suffices for the purpose of
creating appropriate EDT logic. In the created skeleton design, all chains in this range are the
same length and contain a first and last scan cell with the same clocking.
The edge specification must be one of the following:
• LE for a scan cell whose output changes on the leading edge of the specified clock
• TE for a scan cell whose output changes on the trailing edge of the specified clock
• LA for an LSSD scan cell
When you specify the clock edge of the last scan cell, it is critical to include the lockup cell
timing as well. For example, if a leading edge (LE) triggered scan memory element is followed
by a lockup cell, the edge specification of the scan cell must be TE (not LE) because the cell
contains a scan memory element followed by a lockup cell and the scan cell output changes on
the trailing edge (TE) of the clock. Specifying incorrect edges results in the tool inserting
improper lockup cells and may require you to regenerate the EDT logic later.
Note
When the scan chain specification indicates the first and last scan cell have primary/remote
or primary/copy clocking (for example, an LE first scan cell and a TE last scan cell), the
create_skeleton_design utility increases that chain’s length by one cell in the skeleton netlist it
writes out. This is done to satisfy a requirement of lockup cell analysis and does not alter the
EDT logic; the length of the scan chains seen by the tool after it reads in the skeleton netlist is as
specified in the skeleton design input file.
Comment Lines
You can place comments in the file by beginning them with a double slash (//). Everything after
a double slash on a line is treated as a comment and ignored.
Input File Example

The following example utilizes bused scan chain input and output pins. It also defines two
clocks, clk1 and clk2, with off-states 0 and 1, respectively.
A total of eight scan chains are specified. Chains 1 through 4 are of length 2, with the first cell
being LE clk1 triggered and the last cell being TE clk1 triggered. Chains 5 and 6 are of length 3,
with the first cell being LE clk2 triggered and the last cell being TE clk2 triggered. Chains 7 and
8 are also of length 3, with the first and last cells being of LSSD type, clocked by primary and
remote clocks, mclk and sclk, respectively.
Figure 9-6. Skeleton Design Input File Example
// Double slashes (//) mean everything following on the line is a comment.

//
// edt_si[7:0] and edt_so[7:0] pins are created for scan chains.
scan_chain_input edt_si bused
scan_chain_output edt_so bused
begin_clocks
clk1 0
clk2 1
mclk 0
sclk 0
end_clocks
begin_chains
// chains 1 to 4 have the following characteristics (Mux scan)
1 4 2 LE clk1 TE clk1
// chains 5 and 6 have the following characteristics (Mux scan)
5 6 3 LE clk2 TE clk2
// chains 7 and 8 have the following characteristics (LSSD)
7 8 3 LA mclk sclk LA mclk sclk
end_chains
Skeleton Design Interface File

You should create a skeleton design interface file if you are creating EDT logic that is inserted
external to the design core. It should contain only the interface description of the core design in
Verilog format; that is, only the module port list and declarations of these ports as input, output,
or inout.
For an example of this file, see “Interface File” on page 315.
Tip
The interface file ensures the files written out by the create_skeleton_design utility
contains the information the tool needs to write out valid core blackbox
(*_core_blackbox.v) and top-level wrapper (*_edt_top.v) files.
Creation of the EDT Logic for a Skeleton Design
Creation of the EDT Logic for a Skeleton Design

After invoking Tessent Shell and reading the skeleton design, you must set up the following
parameters with the set_edt_options command:
• Number of external scan channels
• Estimate of the longest scan chain length (optional). This value enables flexibility when
configuring scan chains. For more information, see “Longest Scan Chain Range
Estimate” on page 311.
For example:
set_edt_options -longest_chain_range 75 125
For more information on setting up and creating the EDT logic, see “Creation of EDT Logic
Files” on page 98.
Longest Scan Chain Range Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Longest Scan Chain Range Estimate

The longest scan chain range estimate defines a range for the length of the longest scan chain in
the design. The EDT logic is then configured to enable the longest scan chain in the design to
fall within this range without requiring the EDT logic to be regenerated.
This builds in flexibility in cases, such as the RTL flow, where the scan chains may change after
the EDT logic is created as follows:
• min_number_cells — Specifies the lower bound of the longest scan chain range. You
should avoid specifying an artificially low value for the set_edt_options
“min_number_cells” command option if you separate control and data channels or use
the basic compactor.
Note
The set_edt_options “longest_chain_range” switch defines a range for the length of
the longest scan chain in your design. This does not mean the range of lengths of all
the scan chains in your design. Setting the min_number_cells option based on these
considerations enables the tool to configure the EDT logic to ensure robust pattern
compression.
For more information on compactors, see “Understanding Compactor Options” on

page 282.
• max_number_cells — Specifies the higher bound of the longest scan chain range and is
used to configure the phase shifter in the decompressor. The phase shifter is configured
to separate the bit streams provided to the scan chains by at least as many cycles as
Integration of the EDT Logic Into the Design
specified by the max_number_cells value. This reduces linear dependencies among the
bit streams supplied to the internal scan chains.
The flexibility of this restriction is determined by the linear dependencies present in a
design and the number of scan cells specified for the longest scan chain. Some designs
tolerate up to a 25% increase in scan chain length before the EDT logic is affected.

After you create the EDT logic, integrating it into the design is a manual process.
• For EDT logic created external to the design core (“Compressed Pattern External Flow”
on page 47):
If you provided the create_skeleton_design utility with the recommended interface file
when it generated the skeleton design, you can continue with the compressed pattern
external flow (optionally insert I/O pads and boundary scan, then synthesize the I/O
pads, boundary scan, and EDT logic).
If you did not use an interface file, you must manually provide the interface and all
related interconnects needed for the functional design before synthesizing the EDT
logic.
• For EDT logic created within the design core (“Compressed Pattern Internal Flow” on
page 50):
Integrating the EDT logic into the design is a manual process you perform using your
own tools and infrastructure to stitch together different blocks of the design to create a
top level design.
Note
The Design Compiler synthesis script that the tool writes out does not contain
information for connecting the EDT logic to design I/O pads, as the tool did not have
access to the complete netlist when it created the EDT logic.
Knowing When to Regenerate the EDT Logic

By the time the gate-level netlist is available, there may be changes to the design that affect the
EDT logic as described in the following list. When one of these changes occurs in the design,
the safest approach is to always regenerate the EDT logic and compare the new RTL with the
previous RTL to determine if the EDT logic is changed.
• Number of Channels or Chains has Changed — In this case, the EDT logic must be
regenerated.
• Clocking of a First or Last Scan Cell has Changed — Whether the EDT logic actually
needs to be regenerated depends on whether the clock edge that triggers the first or last
scan cell has changed and whether lockup cells are inserted for bypass mode scan
chains. You should regenerate the EDT logic any time the clocking of the first or last
scan cell changes. Note, this scan chain clocking information is not relevant (not a cause
for regenerating EDT logic) if you set up the EDT clock to pulse before the scan chain
shift clocks. For more information, see “Pulse EDT Clock Before Scan Shift Clocks” on
page 83.
• Length of the Longest Scan Chain is less than the min_number_cells Specified with
the set_edt_options -Longest_chain_range Switch — If the EDT logic uses the
Xpress compactor (default), this value does not affect the architecture and the EDT logic
does not need to be regenerated.
However, if the EDT logic uses the Basic compactor, this parameter is used to configure
the length of the mask register in the compactor. In this case, you should regenerate the
EDT logic. For more information, see “Longest Scan Chain Range Estimate” on
page 311”.
• Length of the Longest Scan Chain is Greater than the max_number_cells Specified
with the set_edt_options -Longest_chain_range Switch — Whether the EDT logic
actually changes or not depends on whether the phase shifter in the decompressor needs
to be redesigned or not. The flexibility of this restriction is determined by the linear
dependencies present in a design and the number of scan cells specified for the longest
scan chain. Some designs tolerate up to a 25% increase in scan chain length before the
EDT logic is affected. For more information, see “Longest Scan Chain Range Estimate”
on page 311”.
Skeleton Flow Example

This section shows example skeleton design input and interface files and the output files the
create_skeleton_design utility generated from them.
Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Input File
The following example skeleton design input file, my_skel_des.in, utilizes indexed scan chain
input and output pins. The file defines two clocks, NX1 and NX2, with off-states 0, and
specifies a total of 16 scan chains, most of which are 31 scan cells long. Notice the clocking of
the first and last scan cell in each chain is specified, but no other scan cell definition is required.
This is because the utility has built-in ATPG models of simple mux-DFF and LSSD scan cells
that are sufficient for it to write out a skeleton design (and for the tool to use later to create the
EDT logic).
Note
If you plan to create the EDT logic within the core design (“Compressed Pattern Internal
Flow” on page 50), this file is the only input the utility needs.
scan_chain_input scan_in indexed 1

scan_chain_output scan_out indexed 1
begin_clocks
NX1 0
NX2 0
end_clocks
begin_chains
1 1 31 TE NX1 TE NX1
6 6 32 LE NX2 LE NX2
10 10 31 LE NX2 LE NX2
11 11 31 LE NX2 LE NX2
12 12 31 LE NX2 LE NX2
13 13 31 LE NX2 LE NX2
14 14 31 LE NX2 LE NX2
15 15 31 LE NX2 LE NX2
16 16 31 LE NX2 LE NX2
end_chains
Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Interface File
The following shows an example interface file nemo6_blackbox.v for the design described in
the preceding input file.
Use of an interface file is recommended if you intend to create the EDT logic as a wrapper
external to the core design (“Compressed Pattern External Flow” on page 47).
module nemo6 ( NMOE , NMWE , DLM , ALE , NPSEN , NALEN , NFWE , NFOE ,
NSFRWE , NSFROE , IDLE , XOFF , OA , OB , OC , OD , AE ,
BE , CE , DE , FA , FO , M , NX1 , NX2 , RST , NEA ,
NESFR , ALEI , PSEI , AI , BI , CI , DI , FI , MD ,
scan_in1 , scan_out1 , scan_in2 , scan_out2 , scan_in3 ,
scan_out3 , scan_in4 , scan_out4 , scan_in5 , scan_out5 ,
scan_in6 , scan_out6 , scan_in7 , scan_out7 , scan_in8 ,
scan_out8 , scan_in9 , scan_out9 , scan_in10 , scan_out10 ,
scan_in11 , scan_out11 , scan_in12 , scan_out12 ,
scan_in13 , scan_out13 , scan_in14 , scan_out14 ,
scan_in15 , scan_out15 , scan_in16 , scan_out16 , scan_en);
input NX1 , NX2 , RST , NEA , NESFR , ALEI , PSEI , scan_in1 , scan_in2 ,
scan_in3 , scan_in4 , scan_in5 , scan_in6 , scan_in7 , scan_in8 ,
scan_in9 , scan_in10 , scan_in11 , scan_in12 , scan_in13 ,
scan_in14 , scan_in15 , scan_in16 , scan_en ;
input [7:0] AI ;
input [7:0] BI ;
input [7:0] CI ;
input [7:0] DI ;
input [7:0] FI ;
input [7:0] MD ;
output NMOE , NMWE , DLM , ALE , NPSEN , NALEN , NFWE , NFOE , NSFRWE ,
NSFROE , IDLE , XOFF , scan_out1 , scan_out2 , scan_out3 ,
scan_out4 , scan_out5 , scan_out6 , scan_out7 , scan_out8 ,
scan_out9 , scan_out10 , scan_out11 , scan_out12 , scan_out13 ,
scan_out14 , scan_out15 , scan_out16 ;
output [7:0] OA ;
output [7:0] OB ;
output [7:0] OC ;
output [7:0] OD ;
output [7:0] AE ;
output [7:0] BE ;
output [7:0] CE ;
output [7:0] DE ;
output [7:0] FA ;
output [7:0] FO ;
output [15:0] M ;
endmodule
Outputs
This section shows examples of the four ASCII files written out by the create_skeleton_design
utility when run on the preceding input and interface files using the following shell command:
create_skeleton_design -o bb1 -design_interface nemo6_blackbox.v \
-i my_skel_des.in
The utility wrote out the following files:
bb1.v bb1.dofile bb1.testproc bb1.atpglib
Skeleton Design
Following is the gate-level skeleton netlist that resulted from the example input and interface
files of the preceding section. For brevity, lines are not shown when content is readily apparent
from the structure of the netlist. Parts attributable to the interface file are highlighted in bold; the
utility would not have included them if there had not been an interface file.
Note
The utility obtains the module name from the interface file, if available. If you do not use an
interface file, the utility names the module “skeleton_design_top”.
module nemo6 (NMOE, NMWE, DLM, ALE, NPSEN, NALEN, NFWE,

NFOE, NSFRWE,
NSFROE, IDLE, XOFF, OA, OB, OC,
OD, AE, BE, CE, DE, FA, FO, M, NX1,
NX2,
RST, NEA, NESFR, ALEI, PSEI, AI,
BI, CI, DI, FI, MD, scan_in1,
scan_in2, ..., scan_in16, scan_out1, scan_out2, ..., scan_out16, scan_en);
output NMOE;
output NMWE;
output DLM;
output ALE;
output NPSEN;
output NALEN;
output NFWE;
output NFOE;
output NSFRWE;
output NSFROE;
output IDLE;
output XOFF;
output [7:0] OA;
output [7:0] OB;
output [7:0] OC;
output [7:0] OD;
output [7:0] AE;
output [7:0] BE;
output [7:0] CE;
output [7:0] DE;
output [7:0] FA;
output [7:0] FO;
output [15:0] M;
input NX1;
input NX2;
input RST;
input NEA;
input NESFR;
input ALEI;
input PSEI;
input [7:0] AI;
input [7:0] BI;
input [7:0] CI;
input [7:0] DI;
input [7:0] FI;
input [7:0] MD;
input scan_in1;
input scan_in2;
...
input scan_in16;
output scan_out1;
output scan_out2;
...
output scan_out16;
input scan_en;
wire NX1_inv;
wire chain1_cell1_out;
...
...
.
.
.
...
inv01 NX1_inv_inst ( .Y(NX1_inv), .A(NX1));
muxd_cell chain1_cell0 ( .Q(scan_out1), .SI(chain1_cell1_out),

.D(1’b0), .CLK(NX1_inv), .SE(scan_en) );
muxd_cell chain1_cell1 ( .Q(chain1_cell1_out), .SI(chain1_cell2_out),
...
muxd_cell chain1_cell30 ( .Q(chain1_cell30_out), .SI(scan_in1),
.D(1’b0),.CLK(NX1_inv), .SE(scan_en) );

muxd_cell chain2_cell1 ( .Q(chain2_cell1_out), .SI(chain2_cell2_out),
...
.
.
.

.D(1’b0), .CLK(NX2), .SE(scan_en) );
muxd_cell chain16_cell1 ( .Q(chain16_cell1_out),
.SI(chain16_cell2_out), .D(1’b0), .CLK(NX2), .SE(scan_en) );
...
.D(1’b0), .CLK(NX2), .SE(scan_en) );
endmodule
Skeleton Design Dofile

The generated dofile includes most setup commands required to create the EDT logic.
Following is the example dofile bb1.dofile the utility wrote out based on the previously
described inputs:
add_scan_groups grp1 bb1.testproc

add_clocks 0 NX1
add_clocks 0 NX2
Skeleton Design Test Procedure File

The utility also writes out a test procedure file that has the test procedure steps needed to create
EDT logic. Following is the example test procedure file bb1.testproc the utility wrote out using
the previously described inputs:

timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse NX1 40 10;
pulse NX2 40 10;
period 100 ;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
measure_sco ;
pulse NX1 ;
pulse NX2 ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force NX1 0 ;
force NX2 0 ;
force scan_en 1 ;
end ;
apply shift 2 ;
end ;
Skeleton Design Tessent Cell Library

The Tessent cell library written out by the utility contains the models used to create the skeleton
design. You must use this library when you perform EDT IP Creation on the skeleton design in
Tessent Shell.
model inv01(A, Y) (
input (A) ()
output(Y) (primitive = _inv(A, Y); )
)
// muxd_scan_cell is the same as sff in adk library.

model muxd_scan_cell (D, SI, SE, CLK, Q, QB) (
scan_definition (
type = mux_scan;
data_in = D;
scan_in = SI;
scan_enable = SE;
scan_out = Q, QB;
)
input (D, SI, SE, CLK) ()
intern(_D) (primitive = _mux (D, SI, SE, _D);)
output(Q, QB) (primitive = _dff(, , CLK, _D, Q, QB); )
)
Note
You can get the utility to write out a Verilog simulation library that matches the Tessent cell
library by including the optional -Simulation_library switch in the shell command.
Appendix A
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 Siemens EDA
Support.
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Global Customer Support and Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
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 “Documentation Options” in the Siemens® Software and 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 <software_release_tree>/doc/infohubs/index.html
PDF:
acroread <software_release_tree>/doc/pdfdocs/_tessent_pdf_qref.pdf
• Application Online Help — You 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.
Getting Help
Global Customer Support and Success
Global Customer Support and Success

A support contract with Siemens Digital Industries Software is a valuable investment in your
organization’s success. With a support contract, you have 24/7 access to the comprehensive and
personalized Support Center portal.
Support Center features an extensive knowledge base to quickly troubleshoot issues by product
and version. You can also download the latest releases, access the most up-to-date
documentation, and submit a support case through a streamlined process.
https://support.sw.siemens.com
If your site is under a current support contract, but you do not have a Support Center login,
register here:
https://support.sw.siemens.com/register
Appendix B
EDT Logic Specifications
This section contains illustrations of EDT logic specifications.

EDT Logic With Basic Compactor and Bypass Module . . . . . . . . . . . . . . . . . . . . . . . . . 325
EDT Logic With Xpress Compactor and Bypass Module . . . . . . . . . . . . . . . . . . . . . . . . 326
Decompressor Module With Basic Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Decompressor Module With Xpress Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Input Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Compactor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Output Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Single Chain Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Basic Compactor Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Xpress Compactor Controller Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Dual Compression Configuration Input Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Dual Compression Configuration Output Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
EDT Logic With Power Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
EDT Logic With Basic Compactor and Bypass

Module
Illustration of the basic compactor and bypass module.
EDT Logic With Xpress Compactor and Bypass Module
EDT Logic With Xpress Compactor and

Bypass Module
Illustration of the Xpress compactor and bypass module.
Decompressor Module With Basic Compactor
Decompressor Module With Basic Compactor

Illustration of the details for a decompressor used with a basic compactor, eight scan chains, and
two scan channels.
Decompressor Module With Xpress

Compactor
Illustration of the details for a decompressor used with an Xpress compactor, eight scan chains,
and two scan channels.
Input Bypass Logic
Input Bypass Logic

Illustration of input bypass logic.
Compactor Module
Compactor Module
Illustration of the compactor module.
Output Bypass Logic
Output Bypass Logic

Illustration of output bypass logic.
Single Chain Bypass Logic
Single Chain Bypass Logic

Illustration of single chain bypass logic.
Basic Compactor Masking Logic
Basic Compactor Masking Logic

Illustration of basic compactor masking logic.
Xpress Compactor Controller Masking Logic
Xpress Compactor Controller Masking Logic

Illustration of Xpress compactor controller masking logic.
Dual Compression Configuration Input Logic

The illustration shows input logic details when both a 2-channel and a 16-channel compression
configuration are defined. Note that the first 2 channels of the 16-channel configuration are
always used for the 2-channel configuration.
Red highlights the path for channel 1 when the 2-channel configuration is active. Blue
highlights the path for channel 2 when the 2-channel input configuration is active.
Dual Compression Configuration Output Logic
Dual Compression Configuration Output Logic

The illustration shows output logic details when both a 2-channel and a 4-channel compression
configuration are defined.
Note that the first 2 channels of the 4-channel configuration are always used for the 2-channel
configuration.

Illustration of EDT logic with a power controller.
Appendix C
Troubleshooting
This appendix is divided into three parts.

Debugging Simulation Mismatches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Resolving DRC Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Incorrect References in Synthesized Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Limiting Observable Xs for a Compact Pattern Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Applying Uncompressable Patterns With Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 365
If There Are EDT Aborted Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Internal Scan Chain Pins Incorrectly Shared With Functional Pins . . . . . . . . . . . . . . . . . . 367
Masking Broken Scan Chains in the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Debugging Simulation Mismatches

This section provides a suggested flow for debugging simulation mismatches in a design that
uses EDT.
You are assumed to be familiar with the information provided in “Potential Causes of
Simulation Mismatches” of the Tessent Scan and ATPG User’s Manual, so that information is
not repeated here. Your first step with EDT should be to determine if the source of the mismatch
is the EDT logic or the core design. Figure C-1 shows a suggested flow to help you begin this
process.
Troubleshooting
Debugging Simulation Mismatches
Figure C-1. Flow for Debugging Simulation Mismatches
If the core design is the source of the mismatch, then you can use uncompressed ATPG
troubleshooting methods to pinpoint the problem. This entails saving bypass patterns from
compressed ATPG, which you then process and simulate in uncompressed ATPG with the
design configured to operate in bypass mode. Alternatively, you can invoke Tessent Shell with
the circuit (configured to run in bypass mode) and generate another set of uncompressed
patterns. For more information, refer to “Compression Bypass Logic” on page 233.
Troubleshooting
Resolving DRC Issues
Resolving DRC Issues

This section supplements the DRC information in the reference manual with some suggestions
to help you reduce the occurrence of certain DRC violations.
Full descriptions of the EDT-specific “K” rules, K19 through K22 DRC Violations, are
provided in “Design Rule Checking” in the Tessent Shell Reference Manual.

K19 Through K22 DRC Violations

K19 through K22 are simulation-based DRCs. They verify the decompressor and compactor
through zero-delay serial simulation and analyze mismatches to try to determine the source of
each mismatch. As a troubleshooting aid, these DRCs transcript detailed messages listing the
gates where the tool’s analysis determined each mismatch originated, and specific simulation
results for these gates.
The tool can provide the most debugging information if you have preserved the EDT logic
hierarchy, including pin pathnames and instance names, during synthesis. When this is not the
case and either rule check fails, the tool transcripts a message that begins with the following
reminder (K22 would be similar):
Warning: Rule K19 can provide the most debug information if the EDT logic
hierarchy, including pin and instance names, is preserved during
synthesis and can be found by Tessent TestKompress.
The message then lists specifics about any instances or pin pathnames the tool cannot resolve,
so you can make adjustments in tool setups or your design if you choose. For example, if the
message continues:
The following could not be resolved:

EDT logic top instance "edt_i" not found.
EDT decompressor instance "edt_decompressor_i" not found.
you can use the set_edt_instances command to provide the tool with the necessary information.
Use the report_edt_instances command to double-check the information.
If the tool can find the EDT logic top, decompressor and compactor instances, but cannot find
expected EDT pins on one or more of these instances, the specifics would tell you about the pins
as in this example for an EDT design with two channels:
The following could not be resolved:

EDT logic top instance "edt_i" exists, but could not find
2-bit channel pin vector "edt_channels_in" on the instance.
EDT decompressor instance "edt_decompressor_i" exists, but
could not find 2-bit channel pin vector "edt_channels_in"
on the instance.
Troubleshooting
K19 Through K22 DRC Violations
When the tool is able to find the EDT logic top, decompressor and compactor instances, but
cannot resolve a pin name within the EDT logic hierarchy, it is typically because the name was
changed during synthesis of the EDT RTL. To help prevent interruptions of the pattern creation
flow to fix a pin naming issue, you are urged to preserve during synthesis, the pin names the tool
created in the EDT logic hierarchy. For additional information about the synthesis step, refer to
“The EDT Logic Synthesis Script” on page 123.
Troubleshooting
Debugging Best Practices

For most common K19 and K22 debug tasks, you can report gate simulation values with the
set_gate_report drc_pattern command.
Typical debug tasks include checking for correct values on:
• EDT control signals (edt_clock, edt_update, edt_bypass, edt_reset)

• Sensitized paths from:
o Input channel pins to the decompressor and from the decompressor to the scan
chains during shift. (K19)
o Scan chains to the compactor and from the compactor to the output channel pins
during shift. (K22)
When you use the drc_pattern option the gate simulation data for different procedures in the test
procedure file display. For more information on the use of Drc_pattern reporting, refer to “State
Stability Issues” in the Tessent Scan and ATPG User’s Manual.
In rare cases, you may need to see the distinct simulation values applied in every shift cycle. For
these special cases, you can force the tool to simulate every event specified in the test procedure
file by issuing the set_gate_report command with the “drc_pattern K19” or “drc_pattern K22”
argument.
The following two subsections provide detailed discussion of the K19 and K22 DRCs, with
debugging examples utilizing the drc_pattern, K19, and K22 options to the set_gate_report
command.
Understanding K19 Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Incorrect Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Inverted Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Incorrect EDT Channel Signal Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Incorrect Scan Chain Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
X Generated by EDT Decompressor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Understanding K22 Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Inverted Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Incorrect Scan Chain Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Masking Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Troubleshooting
Understanding K19 Rule Violations

DRC K19 simulates the test_setup, load_unload, shift and capture procedures as defined in the
test procedure file. By default, this simulation is performed with constrained pins initialized to
their constrained values. To speed up simulation times, however, the rule simulates only a small
number of shift cycles. If the first scan cell of each scan chain is loaded with the correct values,
then the EDT decompressor works properly and this rule check passes.
If the first scan cell of any scan chain is loaded with incorrect data, the K19 rule check fails. The
tool then automatically performs an initial diagnosis to determine where along the path from the
channel inputs to the core chain inputs the problem originated. Figure C-2 shows the data flow
through the decompressor and where in this flow the K19 rule check validates the signals.
Figure C-2. Order of Diagnostic Checks by the K19 DRC
Troubleshooting
For example, if the K19 rule detected erroneous data at the output of the first scan cell (1) in
scan chain 2, the rule would check whether data applied to the core chain input (2) is correct. If
the data is correct at the core chain input, the tool would issue an error message similar to this:
Erroneous bit(s) detected at core chain 2 first cell

/cpu_i/option_reg_2/DFF1/ (7021).
Data at core chain 2 input /cpu_i/edt_si2 (43) is correct.
Expected: 0011101011101001X
Simulated:01100110001110101
The error message reports the value the tool expected at the output of the first cell in scan chain
2 for each shift cycle. For comparison, the tool also lists the values that occurred during the
DRC’s simulation of the circuitry. If the data is correct at the first scan cell (1) and at the core
chain inputs (2), the rule next checks the data at the outputs of the core chain input drivers (3).
Note
The term, “core chain input drivers” refers to any logic that drives the scan chain inputs.
Usually, the core chain input drivers are part of the EDT logic. However, if a circuit
designer inserts logic between the EDT logic and the core scan chain inputs, the drivers might
be outside the EDT module.
The signals at (3) should always be the same as the signals at the core chain inputs (2). The tool
checks that this is so, however, because the connection between these two points is emulated
and not actually a physical connection.
Note
Due to the tool’s emulation of the connection between points (2) and (3), you cannot obtain
the gate names at these points by tracing between them with a “report_gates -backward” or
“report_gates -forward” command. However, reporting a gate that has an emulated connection
to another gate at this point displays the name and gate ID# of the other gate; you can then issue
report_gates for the other gate and continue the trace from there.
If the data at the outputs of the core chain input drivers (3) is correct, the rule next checks the
chain input data at the outputs of the EDT module (4). For each scan chain, if the data is correct
at (4), but incorrect at the core chain input (2), the tool issues a message similar to the following:
Erroneous bit(s) detected at core chain 1 input /tiny_i/scan_in1 (11).

Data at EDT module chain 1 input (source) /edt_i/edt_bypass_logic_i/ix31/Y
(216) is correct.
Expected: 10011101011101001
Simulated:10110011000111010
In this message, “EDT module chain 1 input (source)” refers to the output of the EDT module
that drives the “core chain 1 input.” The word “source” indicates this is the pattern source for
chain 1. Also, notice the gate name “/edt_i/edt_bypass_logic_i/ix31/Y” for the EDT module
chain 1 input. Because the tool simulates the flattened netlist and does not model the
hierarchical module pins, the tool reports the gate driving the EDT module output.
Troubleshooting
Note
The K19 and K22 rules always report gates driving EDT module inputs or outputs. Again,
this is because in the flattened netlist there is no special gate that represents module pins.
The K19 rule verifies the data at the EDT module chain inputs (4) only if the EDT module
hierarchy is preserved. If the netlist is flattened, or the EDT module name or pin names are
changed during synthesis, the tool can no longer identify the EDT module and its pins.
Tip
Preserving the EDT module during synthesis provides better diagnostic messages if the
simulation-based DRCs (K19 and K22) fail during the Pattern Generation Phase.
The K19 rule continues comparing the simulated data to what is expected for all nine locations
shown in Figure C-2 until it finds a location where the simulated data matches the expected
data. The tool then issues an error message that describes where the problem first occurred, and
where the data was verified successfully.
This rule check not only reports erroneous data, but also reports unexpected X or Z values, as
well as inverted signals. This information can be very useful when you are debugging the
circuit.
Examples of some specific K19 problems, with suggestions for how to debug them, are detailed
in the Related Topics table.
Related Topics
Incorrect Control Signals
Incorrect Scan Chain Order
Inverted Signals
X Generated by EDT Decompressor
Incorrect EDT Channel Signal Order
Using “set_gate_report drc_pattern K19”
Incorrect Control Signals

Fixing incorrect values on EDT control signals often resolves other K19 violations. Problems
with control signals may be detected by other K rules, so it is a good practice to check for these
in the transcript prior to the K19 failure(s) and fix them first. At minimum, the other K rule
failures may provide clues that help you solve the K19 issues.
Troubleshooting
If K19 detects incorrect values on an EDT control signal, the tool issues a message similar to the
following one for the EDT bypass signal (edt_bypass by default):
1 EDT module control signals failed. (K19-1)

Inverted data detected at EDT module bypass /edt_bypass (37).
Expected: 0000000000000000000000
Simulated: 1111111111111111111111
Because the edt_bypass signal is a primary input, and the message indicates it is at a constant
incorrect value, it is reasonable to suspect that the load_unload or shift procedure in the test
procedure file is applying an incorrect value to this pin. The edt_bypass signal should be 0
during load_unload and shift (see Figure 6-1), so you could use the following command
sequence to check the pin’s value after DRC.
1. set_gate_report drc_pattern load_unload

2. report_gates /edt_bypass
3. set_gate_report drc_pattern shift
4. report_gates /edt_bypass
The following transcript excerpt shows an example of the use of this command sequence, along
with examples of procedures you would be examining for errors:
set_gate_report drc_pattern load_unload

report gate /edt_bypass
The values reported for the load_unload are okay, but in the first “apply shift” (shown in bold
font), edt_bypass is 1 when it should be 0. This points to the shift procedure as the source of the
problem.
Troubleshooting
You can use the following commands to confirm:
set_gate_report drc_pattern shift

report_gate /edt_bypass
The DRC simulation data for the shift procedure shows it is forcing the edt_bypass signal to the
wrong value (1 instead of 0). The remedy is to change the force statement to “force edt_bypass
0”.
Following is another example of the tool’s K19 messaging—for an incorrect value on the EDT
update signal (highlighted in bold).
EDT update pin "edt_update" is not reset before pulse of EDT clock pin
"edt_clock" in shift procedure. (K18-1)
1 error in test procedures. (K18)
...
1 EDT module control signals failed.
(K19-1)
Inverted data detected at EDT module
update /edt_update (36).
Expected: 0000000000000000000000
Simulated: 1111111111111111111111
4 of 4 EDT decompressor chain outputs (bus
/cpu_edt_i/cpu_edt_decompressor_i/edt_scan_in) failed. (K19-2)
Erroneous bit(s) detected at EDT decompressor chain 1 output
/cpu_edt_i/cpu_edt_decompressor_i/ix97/Y (282).
Data at EDT module channel inputs (signal /cpu_edt_i/edt_channels_in)
is correct.
Expected: 110101101111010100001X
Simulated: 0000000000000000000000
...
Notice that earlier in the transcript there is a K18 message that mentions the same control signal
and describes an error in the shift procedure. A glance at Figure 6-1 shows the EDT update
Troubleshooting
signal should be 1 during load_unload and 0 for shift. You could now check the value of this
signal as follows (relevant procedure file excerpts are shown below the example commands):
set_gate_report drc_pattern shiftreport_gate /edt_update
The output of the gate report for the shift procedure shows the EDT update signal is 1 during
shift. The reason is an incorrect force statement in the shift procedure, shown in the procedure
excerpt below the example. Changing “force edt_update 1;” to “force edt_update 0;” in the shift
procedure would resolve these K18 and K19 violations.
Inverted Signals
You can use inverting input pads to drive the EDT decompressor.
However, you must specify the inversion using the set_edt_pins command. (This actually is true
of any source of inversion added on the input side of the decompressor.) Without this
information, the decompressor generates incorrect data and the K19 rule check transcript
includes a message similar to the following:
1 of 1 EDT module channel inputs (signal /cpu_edt_i/edt_channels_in)

failed. (K19-1)
Inverted data detected at EDT module channel 1 input /U$1/Y (237).
Data at channel 1 input pin /edt_channels_in1 (38) is correct.
Expected: 1000001011011000010000
Simulated: 0111110100100111101111
The occurrence message lists the name and ID of the gate where the inversion was detected
(point 6 in Figure C-2). It also lists the upstream gate where the data was correct (point 8 in
Figure C-2). To debug, trace back from point 6 looking for the source of the inversion. For
example:
report_gates /U$1/Y
Troubleshooting
// /U$1 inv02
// A I /edt_channels_in1
// Y O /cpu_edt_i/cpu_edt_decompressor_i/ix199/A1
/cpu_edt_i/cpu_edt_decompressor_i/ix191/A1
/cpu_edt_i/cpu_edt_decompressor_i/ix183/A1
b
// /edt_channels_in1 primary_input
// edt_channels_in1 O /U$1/Y
The trace shows there are no gates between the primary input where the data is correct and the
gate (an inverter) where the inversion was detected, so the latter is the source of this K19
violation. You can use the -Inv switch with the set_edt_pins command to solve the problem.
report_edt_pins
//
// --------------- -------- ---------
//
set_edt_pins input_channel 1 -inv

report edt pins
//
// --------------- -------- ---------
// Scan channel 1 input edt_channels_in1 inv
//
Incorrect EDT Channel Signal Order

If you manually connect the EDT module to the core scan chains, it is easy to connect signals in
the wrong order. If the K19 rule check detects incorrectly ordered signals at any point, it issues
Troubleshooting
messages similar to the following; notice the statement that signals appear to be connected in
the wrong order:
2 of 2 EDT module channel inputs (bus /edt_i/edt_channels_in) failed.
(K19-1)
Erroneous bit(s) detected at EDT module channel 1 input
/edt_channels_in2 (9).
Expected: 010000000
Simulated: 000000000
Erroneous bit(s) detected at EDT module channel 2 input
/edt_channels_in1 (8).
Expected: 000000000
Simulated: 010000000
2 signals appear to be connected in the wrong
order at EDT module
channel inputs (bus /edt_i/edt_channels_in). (K19-2)
Data at EDT module channel 2 input /edt_channels_in1 (8) match those
expected at EDT module channel 1 input /edt_channels_in2 (9).
Data at EDT module channel 1 input /edt_channels_in2 (9) match those
expected at EDT module channel 2 input /edt_channels_in1 (8).
DRC reports this as two K19 occurrences, but the same signals are mentioned in both
occurrence messages. Notice also that the Expected and Simulated values are the same, but
reversed for each signal, a corroborating clue. The fix is to reconnect the signals in the correct
order in the netlist.

The tool enables you to add and delete scan chain definitions with the commands
add_scan_chains and delete_scan_chains. If you use these commands, it is mandatory that you
keep the scan chains in exactly the same order in which they are connected to the EDT module.
For example, the input of the scan chain added first must be connected to the least significant bit
of the EDT module chain input port (point 4 in Figure C-2). Deleting a scan chain with the
delete_scan_chains command and then adding it back again with add_scan_chains changes the
defined order of the scan chains, resulting in K19 violations. If scan chains are not added in the
right order, the K19 rule check issues a message similar to the following:
2 signals appear to be connected in the wrong order at core chain

inputs. Check if scan chains were added in the wrong order. (K19-2)
Data at core chain 6 input /cpu_i/edt_si6 (39)
match those expected at core chain 5 input /cpu_i/edt_si5 (40).
Data at core chain 5 input /cpu_i/edt_si5 (40)
match those expected at core chain 6 input /cpu_i/edt_si6 (39).
To check if scan chains were added in the wrong order, issue the report_scan_chains command
and compare the displayed order with the order in the dofile the tool wrote out when the EDT
logic was created. For example:
report_scan_chains
Troubleshooting
chain = chain1 group = grp1

input = /cpu_i/scan_in1 output = /cpu_i/scan_out1 length = unknown
...
shows chains 5 and 6 reversed from the order in this excerpt of the original tool-generated
dofile:
//
// Define the instance names of the decompressor, compactor, and the
// container module, which instantiates the decompressor and compactor.
// Locating those instances in the design enables DRC to provide more
// debug information in the event of a violation.
// If multiple instances exist with the same name, substitute the instance
// name of the container module with the instance’s hierarchical path
// name.
set_edt_instances -edt_logic_top test_design_edt_i

set_edt_instances -decompressor test_design_edt_decompressor_i
set_edt_instances -compactor test_design_edt_compactor_i
add_scan_groups grp1 testproc

add_scan_chains -internal chain1 grp1 /cpu_i/scan_in1 /cpu_i/scan_out1
...
The easiest way to solve this problem is either to delete all scan chains and add them in the right
order:
delete_scan_chains -all
add_scan_chains -internal chain1 grp1 /cpu_i/scan_in1/cpu_i/scan_out1
...
or exit the tool, correct the order of add_scan_chains commands in the dofile, and start the tool
with the corrected dofile.
Troubleshooting
X Generated by EDT Decompressor

Xs should never be applied to the scan chain inputs. If this occurs, the K19 rule check issues a
message similar to this:
X detected at EDT module chain 1 input (source)
/edt_i/edt_bypass_logic_i/U86/Z (3303).
Data at EDT decompressor chain 1 output
/edt_i/edt_decompressor_i/U83/Z (2727) is correct.
Expected: 10100010000000010001
Simulated: X0X000X00000000X000X
Provided the EDT module hierarchy is preserved, the message describes the origin of the X
signals. The preceding message, for example, indicates the EDT bypass logic generates X
signals, while the EDT decompressor works properly.
To debug these problems, check the following:
• Are the core chain inputs correctly connected to the EDT module chain input port?
Floating core chain inputs could lead to an X.
• Are the channel inputs correctly connected to the EDT module channel input ports?
Floating EDT module channel inputs could lead to an X.
• Are the EDT control signals (edt_clock, edt_update and edt_bypass by default) correctly
connected to the EDT module? If the EDT decompressor is not reset properly, X signals
might be generated.
• Is the EDT update signal (edt_update by default) asserted in the load_unload procedure
so that the decompressor is reset? If the decompressor is not reset properly, X signals
might be generated.
• Is the EDT bypass signal (edt_bypass by default) forced to 0 in the shift procedure? If
the edt_bypass signal is not 0, X signals from un-initialized scan chains might be
switched to the inputs of the core chains.
• If the EDT control signals are generated on chip (by means of a TAP controller, for
example), are they forced to their proper values so the decompressor is reset in the
load_unload procedure?
You can report the K19 simulation results for gates of interest by issuing “set_gate_report k19”
in setup system mode, then using “report_gates” on the gates after the K19 rule check fails. You
can also use an HDL simulator like Questa SIM. In order to do that, ignore failing K19 DRCs by
issuing a “set_drc_handling k19 ignore” command. Next, generate three random patterns in
analysis system mode and save the patterns as serial Verilog patterns. Then simulate the circuit
with an HDL simulator and analyze the signals of interest.
Troubleshooting

If you issue a set_gate_report command with the “drc_pattern K19” argument, you can use
report_gates to view the simulated values for the entire sequence of events in the test procedure
file for any K19-simulated gate. The representation of the test_setup procedure uses the final
stable values. View the full details by running the “set_gate_report drc_pattern test_setup”
command. The “drc_pattern K19” argument also has several options that enable you to limit the
content of the displayed data.
The following shows how you might report on the simulated values for the “core chain 2 first
cell” mentioned in the first error message example of this section (see “Understanding K19 Rule
Violations” on page 344):
set_gate_report drc_pattern k19

// Resimulating.......
report_gates 7021
// /cpu_i/option_reg_2/DFF1 (7021) DFF
// "S" I 50-
// "R" I 46-
// CLK I 1-/clk
// "D0" I 1774-
// "OUT" O 52- 53-
//
// Proc: t ld_u sh 1 sh 2 sh 3 sh 4 sh 5 sh 6... cap
// ----- - ---- ---- ---- ---- ---- ---- ---- ---
// Time: 234 123 123 123 123 123 123... o o
// * 0000 0000 0000 0000 0000 0000 0000... fXf
// ----- - ---- ---- ---- ---- ---- ---- ---- ---
// Sim: X XXXX XX00 0001 0011 0010 1110 1111... XXX
// Emu: - ---- ---0 ---0 ---1 ---1 ---1 ---0... ---
// Mism: * * * *
// Monitor: core chain 1 first cell.
//
// Inputs:
// S 0 0000 0000 0000 0000 0000 0000 0000... 0X0
// R 0 0000 0000 0000 0000 0000 0000 0000... 0X0
// CLK X 0000 0010 0010 0010 0010 0010 0010... 0X0
// DO X XXXX XX00 0001 0011 0010 1110 1111... XXX
You can see from this report the effect each event in each shift cycle had on the gate’s value
during simulation. The time numbers (read vertically) indicate the relative time events occurred
within each cycle, as determined from the procedure file. If the gate is used by DRC as a
reference point in its automated analysis of K19 mismatches, the report lists the value the tool
expected at the end of each cycle and whether it matched the simulated value. The last line
reminds you the gate is a monitor gate (a reference point in its automated analysis) and tells you
its location in the data path. These monitor points correspond to the eight points illustrated in
Figure C-2.
Troubleshooting
Understanding K22 Rule Violations

Like DRC K19, the K22 rule check simulates the test_setup, load_unload and shift procedures,
as defined in the test procedure file. But the K22 rule check performs more simulations than
K19; one simulation in non-masking mode and a number of simulations in masking mode. If the
correct values are shifted out of the channel outputs in both modes, then the EDT compactor
works properly and this rule check passes.
If erroneous data is observed at any channel output, either in non-masking or masking mode, the
K22 rule check fails. The tool then automatically performs an initial diagnosis to determine
where along the path from the core scan chains to the channel outputs the problem originated.
Figure C-3 shows the data flow through the compactor and where in this flow the K22 rule
check validates the signals.
Figure C-3. Order of Diagnostic Checks by the K22 DRC
For example, if the K22 rule detected erroneous data at the channel outputs (6), the tool would
begin a search for the origin of the problem. First, it checks if the core chain outputs (1) have the
correct values. If the data at (1) is correct, the tool next checks the data at the inputs of the EDT
Troubleshooting
module (2). If the simulated data does not match the expected data here, the tool stops the
diagnosis and issues a message similar to the following:
Error:Non-masking mode: 1 of 8 EDT module chain outputs (sink)

(bus /edt_i/edt_scan_out) failed. (K22-1)
Erroneous bit(s) detected at EDT module chain 3 output (sink)
/cpu_i/stack2_reg_8/Q (1516).
Data at core chain 3 output /cpu_i/edt_so3 (7233) is correct.
Check if core chain 3 output is properly connected to EDT module
chain 3 output (sink).
Expected: 111101001101100100000000001000100000
Simulated: 110100100101101000101011010111001111
Error:Masking mode (mask 3): 1 of 8 EDT module chain outputs (sink)

(bus /edt_i/edt_scan_out) failed. (K22-2)
Erroneous bit(s) detected at EDT module chain 3 output (sink)
/cpu_i/stack2_reg_8/Q (1516).
Data at core chain 3 output /cpu_i/edt_so3 (7233) is correct.
Check if core chain 3 output is properly connected to EDT module
chain 3 output (sink).
Expected: 110001001011000000000000000000110001
Simulated: 00011000111010000000001111001101100
In this message, “EDT module chain 3 output (sink)” refers to the input of the EDT module that
is driven by the “core chain 3 output.” The word “sink” indicates this is the sink for the
responses captured in chain 3. Also, notice the gate name “/cpu_i/stack2_reg_8/Q” for the EDT
module chain 3 output. Because the tool simulates the flattened netlist and does not model
hierarchical module pins, the tool reports the gate driving the EDT module’s input.
Note
The K19 and K22 rules always report_gates driving EDT module inputs or outputs. This is
because in the flattened netlist there is no special gate that represents module pins.
The message has two parts; the first part reporting problems in non-masking mode, the second
reporting problems in masking mode. The preceding example tells you the masking mode fails
when the mask is set to 3; that is, when the third core chain is selected for observation.
Note
In masking mode, only one core chain per compactor group is observed at the channel
output for the group. In non-masking mode, the output from all core chains in a compactor
group are compacted and observed at the channel output for the group.
Given the error message, it is easy to debug the problem. Check the connection between the
core chain output (1 in Figure C-3 on page 355) and the EDT module, making sure any logic in
between is controlled correctly. Usually, there is no logic between the core chain outputs and
the EDT module.
Troubleshooting
The K22 rule verifies data at the EDT module chain outputs (2) only if the EDT module
hierarchy is preserved. If the netlist is flattened or the EDT module’s name or pin names are
changed during synthesis, the tool can no longer identify the EDT module and its pins.
Note
Preserving the EDT module during synthesis provides better diagnostic messages if the
simulation-based DRCs (K19 and K22) fail during the Pattern Generation Phase.
If the data at the EDT module chain outputs (2) is correct, the K22 rule continues comparing the
simulated data to the expected data for the EDT compactor outputs (3), the EDT module
channel outputs(4), and so on until the tool identifies the source of the problem. This approach
is analogous to that used for the K19 rule checks described in “Understanding K19 Rule
Violations” on page 344.
For guidance on methods of debugging incorrect or inverted signals, X signals, and signals or
scan chains in the wrong order, the discussion of these topics in “Understanding K19 Rule
Violations” on page 344 is good background information for K22 rule violations.
Inverted Signals
You can use inverting pads on EDT channel outputs.
However, you must specify the inversion using the set_edt_pins command. (This actually is true
of any source of inversion added on the output side of the compactor.) Without this information,
Troubleshooting
the compactor generates incorrect data and the K22 rule check transcript includes a message
similar to the following (for a design with one scan channel and four core scan chains):
Non-masking mode: 1 of 1 channel output pins failed. (K22-1)

Inverted data detected at channel 1 output pin /edt_channels_out1 (564).
Data at EDT module channel 1 output /cpu_edt_i/edt_bypass_logic_i/ix23/Y
(458) is correct.
Expected: X000001101110000100111
Simulated: X111110010001111011000
Masking mode (mask 1): 1 of 1 channel output pins failed. (K22-2)

(458) is correct.
Expected: X111101001010010011001
Simulated: X000010110101101100110

(458) is correct.
Expected: X111111110000000010010
Simulated: X000000001111111101101

(458) is correct.
Expected: X010001010000110011101
Simulated: X101110101111001100010

(458) is correct.
Expected: X110101011110011101110
Simulated: X001010100001100010001
Notice the separate occurrence messages are identifying the same problem.
The occurrence messages list the name and ID of the gate where the inversion was detected
(point 6 in Figure C-3). It also lists the upstream gate where the data was correct (point 4 in
Figure C-3). To debug, simply trace back from point 6 looking for the source of the inversion.
For example:
report_gates /edt_channels_out1
// /edt_channels_out1 primary_output
// edt_channels_out1 I /ix77/Y
b
// /ix77 inv02
// A I /cpu_edt_i/edt_bypass_logic_i/ix23/Y
// Y O /edt_channels_out1
Troubleshooting
The trace shows there are no gates between the primary output where the inversion was detected
and the gate (an inverter) where the data is correct, so the latter is the source of this K22
violation. You can use the -Inv switch with the set_edt_pins command to solve the problem.
report_edt_pins
//
// --------------- -------- ---------
//
set_edt_pins output_channel 1 -inv

report edt pins
//
// --------------- -------- ---------
// " " " output edt_channels_out1 inv
//

You can add and delete scan chain definitions with the commands add_scan_chains and
delete_scan_chains. If you use these commands, it is mandatory that you keep the scan chains in
exactly the same order in which they are connected to the EDT module.
For example, the output of the scan chain added first must be connected to the least significant
bit of the EDT module chain output port (point 2 in Figure C-3). Deleting a scan chain with the
delete_scan_chains command and then adding it again with add_scan_chains changes the
defined order of the scan chains, resulting in K22 violations. If scan chains are not added in the
right order, the K22 rule check issues a message similar to the following:
4 signals appear to be connected in the wrong order at EDT module chain

outputs (sink) (bus/cpu_edt_i/edt_so). (K22-8)
Data at EDT module chain 2 output (sink) /cpu_i/datai/uu1/Y (254)
match those expected at EDT module chain 1 output (sink)
/cpu_i/datao/uu1/Y (256).
Data at EDT module chain 3 output (sink) /cpu_i/datai1/uu1/Y (253)
/cpu_i/datai/uu1/Y (254).
Data at EDT module chain 4 output (sink) /cpu_i/addr_0/uu1/Y (245)
/cpu_i/datai1/uu1/Y (253).
Data at EDT module chain 1 output (sink) /cpu_i/datao/uu1/Y (256)
/cpu_i/addr_0/uu1/Y (245).
Troubleshooting
To check if scan chains were added in the wrong order, issue the report_scan_chains command
and compare the displayed order with the order in the dofile the tool wrote out when the EDT
logic was created. For example:
report_scan_chains
shows chain1 added last instead of first, chain2 added first instead of second, and so on; not the
order in this excerpt of the original tool-generated dofile:
//
// Define the instance names of the decompressor, compactor, and the
// container module, which instantiates the decompressor and compactor.
// Locating those instances in the design enables DRC to provide more
// debug information in the event of a violation.
// If multiple instances exist with the same name, substitute the instance
// name of the container module with the instance’s hierarchical path
// name.
set_edt_instances -edt_logic_top test_design_edt_i

set_edt_instances -decompressor test_design_edt_decompressor_i
set_edt_instances -compactor test_design_edt_compactor_i
add_scan_groups grp1 testproc

...
The easiest way to solve this problem is either to delete all scan chains and add them in the right
order:
delete_scan_chains -all
or exit the tool, correct the order of add_scan_chains commands in the dofile and start the tool
with the corrected dofile.
Troubleshooting
Note
When the tool is set up to treat K19 violations as errors, the invocation default, incorrect
scan chain order is detected by the K19 rule check, because the tool performs K19 checks
before K22—see “Incorrect Scan Chain Order” on page 351 in the K19 section for example tool
messages. In this case, the tool stops before issuing any K22 messages related to the incorrect
order.
If the issue was actually one of incorrect signal order only at the outputs of the internal scan
chains and the inputs were in the correct order, you would get K22 messages similar to the
preceding and no K19 messages about scan chains being “added in the wrong order.”
Masking Problems
Most masking problems are caused by disturbances in the operation of the mask hold and shift
registers.
One such problem results in the following message for the decoded masking signals:
Non-masking mode: 4 of 4 EDT decoded masking signals failed. (K22-1)

Constant X detected at EDT decoded masking signal 1
/cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63/Y (343).
Expected: 1111111111111111111111
Simulated: XXXXXXXXXXXXXXXXXXXXXX
You can usually find the source of masking problems by analyzing the mask hold and shift
registers. In this example, you could begin by tracing back to find the source of the Xs:
set_gate_level primitive
set_gate_report drc_pattern state_stability
report_gates /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63/Y
// /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63 (343) NAND
// (ts)( ld)(shift)(cap)(stbl)
// "I0" I ( X)(XXX)(XXX~X)(XXX)( X) 294-
// B0 I ( X)(XXX)(XXX~X)(XXX)( X) 291- ../decoder1/ix107/Y
// Y O ( X)(XXX)(XXX~X)(XXX)( X) 419- ../ix41/A1
// /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63 (294) OR
// A0 I ( X)(XXX)(XXX~X)(XXX)( X) 208- ../reg_masks_hold_reg_0_/Q
// A1 I ( X)(XXX)(XXX~X)(XXX)( X) 214- ../reg_masks_hold_reg_1_/Q
// "OUT" O ( X)(XXX)(XXX~X)(XXX)( X) 343-
Troubleshooting
// /cpu_edt_i/cpu_edt_compactor_i/reg_masks_hold_reg_0_ (208) BUF

// "I0" I ( X)(XXX)(XXX~X)(XXX)( X) 538-
// Q O ( X)(XXX)(XXX~X)(XXX)( X) 235- ../ix102/A0
// 292- ../decoder1/ix57/A0
// 293- ../decoder1/ix113/A
// 346- ../decoder1/ix61/A0
// 294- ../decoder1/ix63/A0
// /cpu_edt_i/cpu_edt_compactor_i/reg_masks_hold_reg_0_ (538) DFF

// "S" I ( 0)(000)(000~0)(000)( 0) 48-
// "R" I ( 0)(000)(000~0)(000)( 0) 150-
// CLK I ( 0)(000)(000~0)(000)( 0) 47-
// D I ( X)(XXX)(XXX~X)(XXX)( X) 235- ../ix102/Y
// "OUT" O ( X)(XXX)(XXX~X)(XXX)( X) 208- 209-
The trace shows the clock for the mask hold register is inactive. Trace back on the clock to find
out why:
report_gates 47
// /cpu_edt_i (47) TIE0
// "OUT" O ( 0)(000)(000~0)(000)( 0) 541-../reg_masks_hold_reg_1_/CLK
// 540-../reg_masks_shift_reg_1_/CLK
// 539-../reg_masks_shift_reg_0_/CLK
// 538-../reg_masks_hold_reg_0_/CLK
// 537 ../reg_masks_shift_reg_2_/CLK
// 536-../reg_masks_hold_reg_2_/CLK
The information for the clock source shows it is tied. As the EDT clock should be connected to
the hold register, you could next report on the EDT clock primary input at the compactor and
check for a connection to the hold register:
report_gates /cpu_edt_i/cpu_edt_compactor_i/edt_clock. . .
Based on the preceding traces, you would expect to find that the EDT clock was not connected
to the hold register. Because an inactive clock signal to the mask hold register would cause
masking to fail, check the transcript for corroborating messages that indicate multiple similar
Troubleshooting
masking failures. These DRC messages, which preceded the K22 message in this example,
provide such a clue:
Pipeline identification for channel output pins failed. (K20-1)

Non-masking mode: Failed to identify pipeline stage(s) at channel 1 output
pin /edt_channels_out1 (563).
Masking mode (mask 1, chain1): Failed to identify pipeline stage(s) at
channel 1 output pin /edt_channels_out1 (563).
Error during identification of pipeline stages. (K20)

Rule K21 (lockup cells) not performed for the compactor side since
pipeline identification failed.
Notice the same failure was reported in masking mode for all scan chains. To fix this particular
problem, you would need to connect the EDT clock to the mask hold register in the netlist.

The set_gate_report command has a “drc_pattern K22” argument that enables you to view the
simulated values for the entire sequence of events in the test procedure file for any K22-
simulated gate.
This “drc_pattern K22”argument is similar to the “drc_pattern K19” argument described in
“Using “set_gate_report drc_pattern K19”” on page 354. Like the “drc_pattern K19” argument,
the “drc_pattern K22” argument also has several options that enable you to limit the content of
the displayed data.
Troubleshooting
Miscellaneous
Miscellaneous
This section contains the following troubleshooting procedures:
Incorrect References in Synthesized Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Limiting Observable Xs for a Compact Pattern Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Applying Uncompressable Patterns With Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . 365
If There Are EDT Aborted Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Internal Scan Chain Pins Incorrectly Shared With Functional Pins . . . . . . . . . . . . . . . 367
Masking Broken Scan Chains in the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Incorrect References in Synthesized Netlist

Use the information in this section to troubleshoot problems that cause Design Compiler to
insert \**TSGEN** references in a synthesized netlist.
Run Design Compiler to synthesize the netlist and verify that no errors occurred and check that
tri-state buffers were correctly synthesized. For certain technologies, Design Compiler is unable
to correctly synthesize tri-state buffers and inserts an incorrect reference to “\**TSGEN**”
instead. You can run the grep command to check for TSGEN:
grep TSGEN created_edt_bs_top_gate.v
If TSGEN is found, as shown in bold font in the following example Verilog code,
module tri_enable_high ( dout, oe, pin );

input dout, oe;
output pin;
wire pin_tri_enable;
tri pin_wire;
assign pin = pin_wire;
\**TSGEN** pin_tri ( .\function (dout),
.three_state(pin_tri_enable), .\output (pin_wire) );
N1L U16 ( .Z(pin_tri_enable), .A(oe) );
endmodule
Troubleshooting
Limiting Observable Xs for a Compact Pattern Set
you need to change the line of code that contains the reference to a correct instantiation of a tri-
state buffer. The next example corrects the previous instantiation to the LSI lcbg10p technology
(shown in bold font):
module tri_enable_high ( dout, oe, pin );

input dout, oe;
output pin;
wire pin_tri_enable;
tri pin_wire;
assign pin = pin_wire;
BTS4A pin_tri ( .A (dout), .E (pin_tri_enable),
.Z
(pin_wire) );
N1A U16 ( .Z(pin_tri_enable), .A(oe) );
endmodule
Limiting Observable Xs for a Compact Pattern Set

EDT can handle Xs, but you may want to limit them in order to enhance compression. To
achieve a compact pattern set (and decrease runtime as well), ensure the circuit has few, or no,
X generators that are observable on the scan chains. For example, if you bypass a RAM that is
tested by memory BIST, X sources are reduced because the RAM is no longer an X generator in
analysis mode.
If no Xs are captured on the scan chains, usually no fault effects are lost due to the compactors
and the tool does not have to generate patterns that use scan chain output masking. For circuits
with no Xs observable on the scan chains, the effective compression is usually much higher
(everything else being equal) and the number of patterns is only slightly more than what ATPG
generates without EDT. DRC’s rule E5 identifies sources of observable Xs.
One clue that you probably have many observable Xs is usually apparent in the transcript for an
EDT pattern generation run. With few or no observable Xs, the number of effective patterns in
each simulation pass without scan chain masking is (ideally) 64. Numbers significantly lower
can indicate that Xs are reducing test effectiveness. This is confirmed if the number of effective
patterns rises significantly when the tool uses masking to block the observable Xs.
Applying Uncompressable Patterns With Bypass

Mode
Occasionally, the tool generates an effective pattern that cannot be compressed using EDT
technology. Although this is a rare occurrence, if many faults generate such patterns, it can have
an impact on test coverage. Decreasing the number of scan chains usually remedies the
problem. Alternatively, you can bypass the EDT logic, which reconfigures the scan chains into
fewer, longer scan chains. This requires an uncompressed ATPG run on the remaining faults.
Troubleshooting
Note
You can use bypass mode to apply uncompressed patterns. You can also use bypass mode
for system debugging purposes.

If you find effective compression is much less than you targeted, taking steps to remedy or
reduce the following should improve the compression:
• Many observable Xs—EDT can handle observable Xs but their occurrence requires the
tool to use masking patterns. Masking patterns observe fewer faults than non-masking
patterns, so more of them are required. More patterns lowers effective compression.
If the session transcript shows all patterns are non-masking, then observable Xs are not
the cause of the lower than expected compression. If the tool generated both masking
and non-masking patterns and the percentage of masking patterns exceeds 25% of the
total, then there are probably many observable Xs. To find them, look for E5 DRC
messages. You activate E5 messages by issuing a “set_drc_handling e5 note” command.
Note
Many observable Xs are likely to result in a much higher runtime compared to
uncompressed ATPG. This probably also results in a much lower number of
effective patterns reported in the transcript when compressed ATPG is not using scan
chain masking, compared to when the tool is using masking.
“Resolving X Blocking With Scan Chain Masking” on page 286 describes masking
patterns. It also shows how the tool reports their use in the session transcript, and
illustrates how masked patterns appear in an ASCII pattern file. See also “Limiting
Observable Xs for a Compact Pattern Set” on page 365.
• EDT Aborted Faults—For information about these types of faults, refer to “If There Are
EDT Aborted Faults” on page 367 in the next section.
• If there are no EDT aborted faults, try a more aggressive compression configuration by
increasing the number of scan chains.
If Test Coverage Is Less Than Expected

If you find test coverage is much less than you expected, first compare it to the test coverage
obtainable without EDT. If the test coverage with EDT is less than you obtain with
Troubleshooting
If There Are EDT Aborted Faults
uncompressed ATPG, the following sections list steps you can take to raise it to the same level
as uncompressed ATPG:
If There Are EDT Aborted Faults

When the tool generates an effective fault test, but is unable to compress the pattern, the fault is
classified as an EDT aborted fault.
See “EDT Aborted Fault Analysis” on page 291 for a method to perform analysis on these
faults.
A warning is issued at the end of the run for EDT aborted faults and reports the resultant loss of
coverage. You can also obtain this information by issuing the report_aborted_faults command
and looking for the “edt” class of aborted faults. Each of the following increases the probability
of EDT aborted faults:
• Relatively aggressive compression (large chain-to-channel ratio)

• Large number of ATPG constraints
• Relatively small design
If the number of undetected faults is large enough to cause a relevant decrease of test coverage,
try re-inserting a fewer number of scan chains.
Internal Scan Chain Pins Incorrectly Shared With

Functional Pins
Relatively low test coverage can indicate internal scan chain pins are shared with functional
pins. These pins must not be shared because the internal scan chain pins are connected to the
EDT logic and not to the top level. Also, the tool constrains internal scan chain input pins to X,
and masks internal scan chain output pins. This has minimal impact on test coverage only if
these are dedicated pins. By default, DRC issues a warning if scan chain pins are not dedicated
pins.
Be sure none of the internal scan chain input or output pins are shared with functional pins.
Only scan channel pins may be shared with functional pins. Refer to “Scan Chain Pins” on
page 57 for additional information.
Masking Broken Scan Chains in the EDT Logic

You can set up the EDT logic to mask the any of the load, capture, or unload values on specified
scan chains by inserting custom logic between the scan chain outputs and the compactor. The
custom logic enables you to either feed the required circuit response (0/1) to the compactor or
tie the scan chain output to an unknown value (X).
Troubleshooting
Masking Broken Scan Chains in the EDT Logic
For more information, see the add_chain_masks command.
Appendix D
Dofile-Based Legacy IP Creation and Pattern
Generation Flow
Prior to the introduction of the TCD-based EDT IP flow, dofiles created during the IP
generation phase were used as the primary input into the EDT pattern generation phase.
The dofile-based legacy flow can still be used as an alternative method of transferring
information from ETD IP to ATPG.
EDT IP Generation Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

EDT Bypass Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
EDT Pattern Generation Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Generated Bypass Dofile and Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Creation of Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Low Pin Count Test Controller Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Dofile-Based Legacy IP Creation and Pattern Generation Flow
EDT IP Generation Dofiles
EDT IP Generation Dofiles

During the IP generation phase, the tool produces several dofiles for use during EDT pattern
generation.
EDT Bypass Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Test Pattern Generation Files

The tool automatically writes a dofile and a test procedure file containing EDT-specific
commands and test procedure steps. As with the similar files produced by Tessent Scan after
scan insertion, these files perform basic setups; however, you need to add commands for any
pattern generation or pattern saving steps.
• Dofile — The dofile includes setup commands, switches, or both required to generate
test patterns. This is an example dofile created_edt.dofile, the EDT-specific parts of this
file are in bold font:
add_clocks 0 clk
// Define the instance names of the decompressor,compactor, and the

// container module, which instantiates the decompressor and
// compactor. Locating those instances in the design enables DRC to
// provide more debug information in the event of a violation. If
// multiple instances exist with the same name, substitute the
// instance name of the container module with the instance’s
// hierarchical path name.
set_edt_instances -edt_logic_top cpu_edt_i

set_edt_instances -decompressor cpu_edt_decompressor_i
set_edt_instances -compactor cpu_edt_compactor_i
add_scan_groups grp1 created_edt.testproc

add_scan_chains -internal chain1 grp1 /cpu_i/edt_si1 /cpu_i/edt_so1
// EDT settings. Please do not modify.

// Inconsistency between the EDT settings and the EDT logic may
// lead to DRC violations and invalid patterns.
set_edt_options -separate_control_data_channels on -channels 5 \

-initialization_cycles 7 -longest_chain_range 2 53 -ip_version 7\
--decompressor_size 25 -injectors_per_channel 2 -scan_chains 13 \
-compactor_type xpress -lockup on -bypass_chain_change_edge on
Notice the -internal switch used with the add_scan_chains command. This switch must
be used for all compressed scan chains (scan chains driven by and observed through the
EDT logic) when setting up to generate compressed test patterns. The reason for this
requirement is to define the compressed scan chains as internal, rather than external
channels, as explained in “Design Rule Checks” on page 97.
Note
Be sure the scan chain input and output pin pathnames specified with the
add_scan_chains -internal command are kept during layout. If these pin pathnames
are lost during the layout tool’s design flattening process, the generated dofile no longer
works. If that happens, you must manually generate the add_scan_chains -internal
commands, substituting the original pin pathnames with new, logically equivalent, pin
pathnames.
Note
If your design includes uncompressed scan chains (chains whose scan inputs and outputs are
primary inputs and outputs), you must define each such scan chain using the
add_scan_chains command.
Other commands in this file add the EDT clock and constrain it to its off state, specify the
number of scan channels, and specify the version of the EDT logic architecture.
• Test Procedure File — The tool also writes a test procedure file for test pattern
generation. The tool takes the test procedure file used for EDT logic creation and adds
the test procedures necessary to drive the EDT logic.
The following example is a test procedure file, created_edt.testproc. The EDT-specific
parts of this file are shown in bold font.
//
timeplate gen_tp1 =
force_pi 0 ;
measure_po 100 ;
pulse clk 200 100;
period 400 ;
end;
procedure capture =
timeplate gen_tp1 ;
cycle =
force_pi ;
measure_po ;
end;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
measure_sco ;
pulse clk ;
pulse edt_clock ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force clk 0 ;
force edt_clock 0
;
force ramclk 0 ;
force scan_en 1 ;
pulse edt_clock ;
end ;
apply shift 26;
end;
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
end;
end;
EDT Bypass Files
EDT Bypass Files

During IP creation, the tool creates files associated with EDT bypass.
• Dofile— This example dofile, created_bypass.dofile, enables you to run regular ATPG.
The dofile specifies the scan channels as chains because in bypass mode, the channels
connect directly to the input and output of the concatenated internal scan chains,
bypassing the EDT circuitry.
//
add_scan_groups grp1 created_bypass.testproc
add_scan_chains edt_channel1 grp1 edt_channels_in1
edt_channels_out1
add_clocks 0 clk
• Test Procedure File — Notice the line (in bold font) near the end of this otherwise
typical test procedure file, created_bypass.testproc. That line forces the EDT bypass
signal, “edt_bypass” to a logic high in the load_unload procedure and activates bypass
mode.
EDT Bypass Files
//
timeplate gen_tp1 =
force_pi 0 ;
measure_po 100 ;
pulse clk 200 100;
period 400 ;
end;
procedure capture =
timeplate gen_tp1 ;
cycle =
force_pi ;
measure_po ;
end;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
measure_sco ;
pulse clk ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force clk 0 ;
force ramclk 0 ;
force scan_en 1 ;
end ;
apply shift 125;
end;
EDT Pattern Generation Dofiles
EDT Pattern Generation Dofiles

The first two setups described in the preceding section are included in the dofile generated with
the EDT logic.
For an example of this dofile, see “Test Pattern Generation Files” on page 370.
The test procedure file also needs modifications to ensure the EDT update signal is active in the
load_unload procedure and the EDT clock is pulsed in the load_unload and shift procedures.
These modifications are implemented automatically in the test procedure file output with the
EDT logic as follows:
• The timeplate used by the shift procedure is updated to include the EDT clock.
• In this timeplate, there must be a delay between the trailing edge of the clock and the end
of the period. Otherwise, a P3 DRC violation occurs.
• The load_unload procedure is set up to initialize the EDT logic and apply shift a number
of times corresponding to the longest “virtual” scan chain (longest scan chain plus
additional shift cycles) seen by the tester. The number of additional shift cycles is
reported by the report_edt_configurations command.
Note
“Additional shift cycles” refers to the sum of the initialization cycles, masking bits
(when using Xpress), and low-power bits (when using a low-power decompressor).
• The shift procedure is updated to include pulsing of the EDT clock signal and
deactivation of the EDT update signal.
• The EDT bypass signal is forced to a logic low if the EDT circuitry includes bypass
logic.
Generated Bypass Dofile and Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Creation of Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Generated Bypass Dofile and Procedure File

The tool generates a dofile and an test procedure file you can use with Tessent FastScan to
activate bypass mode and run regular ATPG.
Examples of these files are shown in “Bypass Mode Files” on page 111. If your design includes
boundary scan and you want to run in bypass mode, you must modify the bypass dofile and
procedure file to work properly with the boundary scan circuitry.
Creation of Test Patterns

The compression technology supports all of the pattern functionality in uncompressed ATPG,
with the exception of MacroTest and random patterns. This includes combinational, clock-
sequential (including patterns with multiple scan loads), and RAM sequential patterns. It also
includes all the fault types.
See “EDT Aborted Fault Analysis” on page 291 for additional considerations.
When you generate test patterns, you should use the dofile and test procedure files the tool
generated during logic creation. If you added boundary scan, you must modify the files as
explained in “Modification of the Dofile and Procedure File for Boundary Scan” on page 245.
To create the EDT logic, you invoked Tessent Shell with the core level of the design. To
generate test patterns, you invoke Tessent Shell with the synthesized top level of the design that
includes synthesized pads, boundary scan, if used, and the EDT logic. Here is an example
invocation of Tessent Shell with a Verilog file named created_edt_top.v, assumed here to be the
top-level file generated when the EDT logic was created:
Invoke Tessent Shell:
You are automatically placed in setup mode. Specify the context for generating test patterns and
load the Verilog file and library:

read_verilog created_edt_top.v
read_cell_library my_atpg_lib
For a description of how the created_edt_top.v file is generated, refer to “Creation of EDT
Logic Files” on page 98. Next, you need to set up for EDT pattern generation. To do this, run
the dofile. For example:
dofile created_edt.dofile
For information about the EDT-specific contents of this dofile, refer to “Test Pattern Generation
Files” on page 370. Enter analysis mode and verify that no DRC violations occur. Pay special
attention to the EDT DRC messages.
Now, you can enter the commands to generate the EDT patterns. If you ran uncompressed
ATPG on just the core design prior to inserting the EDT logic, it is useful to add faults on just
the core now to enable you to make valid comparisons of test performance using EDT versus
not using EDT.
add_faults /my_core
// Only target faults in core
create_patterns
report_statistics
report_scan_volume
Another reason to add faults on the core is to avoid incorrectly reported low test coverage, as
explained earlier in “Adding Faults on the Core Only is Recommended” on page 154.
The report_scan_volume command provides reference numbers when analyzing the achieved
compression.
Low Pin Count Test Controller Dofiles
Low Pin Count Test Controller Dofiles

During IP creation, the tool creates files associated with LPCT controller.
This section provides an example for creating each of the three LPCT configuration types and
examples of the dofile and test procedure files generated for each configuration.


This example for a Type 1 LPCT controller provides a sample tool-created pattern generation
dofile and test procedure file.
Sample pattern generation dofile:

// Read the LPCT TCD file for EDT IP
read_core_description created_cpu_edt_lpct.tcd
add_primary_inputs /occ/NX2 -internal -pseudo_port_name NX2

add_clocks 0 refclk
add_clocks 0 NX1
add_clocks 0 NX2
add_input_constraints scan_en -C0
set_edt_instances -edt_logic_top m8051_edt_i

set_edt_instances -decompressor m8051_edt_decompressor_i
set_edt_instances -compactor m8051_edt_compactor_i

add_scan_chains -internal chain1 grp1 /m8051_edt_i/edt_scan_in[0]
/m8051_edt_i/edt_scan_out[0]

set_edt_options -channels 2 -longest_chain_range 2 32 -ip_version 7 \

-decompressor_size 12 -injectors_per_channel 3 -scan_chains 16 \
-compactor_type xpress
set_edt_pins clock -
set_mask_register -input_channel_mask_register_sizes 1 7 2 6
set_mask_decoder_connection -mode_bit 1 7
set_mask_decoder_connection -1hot_decoder 1 1 6 1 5 1 4 1 3
set_mask_decoder_connection -xor_decoder chain1 1 6 1 5 1 4
// LPCT configuration settings. Please do not modify.

// Inconsistency between the LPCT configuration settings and the LPCT
// logic may lead to DRC violations and invalid patterns.
set_lpct_controller on -generate_scan_enable off \

-tap_controller_interface off -shift_control clock \
-load_unload_cycles 2 2
Sample pattern generation test procedure file:

timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse /NX1 20 10;
pulse /NX2 20 10;
pulse refclk 20 10;
period 40 ;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
// cycle 1 starts at time 0
cycle =
force_sci ;
measure_sco ;
pulse /NX1 ;
pulse /NX2 ;
pulse refclk ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force /NX1 0 ;
force /NX2 0 ;
force RST 0 ;
force scan_en 1 ;
pulse refclk ;
end ;
cycle =
force scan_en 1 ;
pulse refclk ;
end ;
apply shift 45;
cycle =
force scan_en 0 ;
pulse refclk ;
end ;
cycle =
force scan_en 0 ;
pulse refclk ;
end;
end;
timeplate gen_tp1 ;
cycle =
force scan_en 0 ;
pulse refclk ;
end ;
cycle =
force scan_en 0 ;
pulse refclk ;
end;
end;


add_clocks 0 tck -pulse_in_capture
add_clocks 0 NX1
add_clocks 0 NX2
add_input_constraints trst -C1

add_input_constraints tms -C0
set_edt_instances -edt_logic_top m8051_bscan_edt_i

set_edt_instances -decompressor m8051_bscan_edt_decompressor_i
set_edt_instances -compactor m8051_bscan_edt_compactor_i

add_scan_chains -internal chain1 grp1 /m8051_bscan_edt_i/edt_scan_in[0]
/m8051_bscan_edt_i/edt_scan_out[0]

set_edt_options -channels 1 -longest_chain_range 2 32 -ip_version 7 \

-decompressor_size 12 -injectors_per_channel 6 -scan_chains 16 \
set_edt_pins clock -
set_edt_pins input_channel 1 tdi
set_edt_pins output_channel 1 tdo
set_mask_register -input_channel_mask_register_sizes 1 8
set_mask_decoder_connection -1hot_decoder 1 1 7 1 6 1 5 1 4 1 3

set_lpct_controller on -generate_scan_enable on \
-tap_controller_interface on -shift_control clock \
-load_unload_cycles 3 2

Note
The following test_setup procedure is not generated by the tool but copied from a user-
provided test procedure file as an example.

timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse /NX1 20 10;
pulse /NX2 20 10;
pulse tck 20 10;
period 40 ;
end;
procedure shift lpct_tap_last_shift =

scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
force tms 1 ;
measure_sco ;
pulse /NX1 ;
pulse /NX2 ;
pulse tck ;
end;
end;
timeplate gen_tp1 ;

cycle =
force tck 0 ;
force tms 1 ;
force trst 0 ;
end ;
cycle =
force trst 1 ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end ;
cycle =
force tms 1 ;
pulse tck ;
end ;
cycle =
force tms 1 ;
pulse tck ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end ;
cycle =
force tdi 0 ;
force tms 0 ;
pulse tck ;
end ;
cycle =
force tdi 1 ;
force tms 0 ;
pulse tck ;
end ;
cycle =
force tdi 0 ;
force tms 0 ;
pulse tck ;
end ;
cycle =
force tdi 0 ;
force tms 1 ;
pulse tck ;
end ;
cycle =
force tms 1 ;
pulse tck ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
force tms 0 ;
measure_sco ;
pulse /NX1 ;
pulse /NX2 ;
pulse tck ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;

cycle =
force /NX1 0 ;
force /NX2 0 ;
force RST 0 ;
force tck 0 ;
force tdi 0 ;
force tms 1 ;
force trst 1 ;
pulse tck ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end ;
apply shift 51;
apply lpct_tap_last_shift 1;
cycle =
force tms 1 ;
pulse tck ;
end ;
cycle =
force tms 0 ;
pulse tck ;
end;
end;


add_primary_input -internal \
/m8051_lpct_clock_gater_i/m8051_lpct_edt_clock_gater_i/clk_out \
-pin_name edt_clock
/m8051_lpct_i/m8051_lpct_fsm_i/m8051_lpct_control_signal_generator_i/edt_update \
-pin_name edt_update
add_primary_input -internal /m8051_lpct_i/m8051_lpct_interface_i/edt_bypass \
-pin_name edt_bypass
/m8051_lpct_i/m8051_lpct_fsm_i/m8051_lpct_control_signal_generator_i/scan_en \
-pin_name lpct_scan_en
/m8051_lpct_i/m8051_lpct_fsm_i/m8051_lpct_control_signal_generator_i/lpct_capture_en\
-pin_name lpct_capture_en
/m8051_lpct_i/m8051_lpct_fsm_i/m8051_lpct_control_signal_generator_i/
lpct_clock_mux_select -pin_name lpct_clock_mux_select
/m8051_lpct_i/m8051_lpct_fsm_i/m8051_lpct_control_signal_generator_i/lpct_shift_en \
-pin_name lpct_shift_en
/m8051_lpct_i/m8051_lpct_fsm_i/m8051_lpct_control_signal_generator_i/
lpct_test_active -pin_name lpct_test_active
add_primary_input -internal /m8051_lpct_i/m8051_lpct_interface_i/reset_control \
-pin_name reset_control
add_primary_input -internal /m8051_lpct_i/m8051_lpct_interface_i/scan_en_control \
-pin_name scan_en_control
add_clocks 0 refclk -pulse_always

add_clocks 0 NX1
add_clocks 0 NX2

add_input_constraints edt_update -C0
add_input_constraints edt_bypass -CX
add_input_constraints lpct_capture_en -C1
add_input_constraints lpct_clock_mux_select -C0
add_input_constraints lpct_shift_en -C0
add_input_constraints lpct_test_active -C1
add_input_constraints lpct_reset -C0
add_input_constraints reset_control -C0
add_input_constraints scan_en_control -C0
set_edt_instances -edt_logic_top m8051_edt_i
set_edt_instances -decompressor m8051_edt_decompressor_i
set_edt_instances -compactor m8051_edt_compactor_i
add_scan_chains -internal chain1 grp1 /m8051_edt_i/edt_scan_in[0] \


set_edt_options -channels 2 -longest_chain_range 2 32 -ip_version 7

-decompressor_size 12 -injectors_per_channel 3 -scan_chains 16
set_edt_pins update edt_update

set_edt_pins clock edt_clock
set_edt_pins bypass edt_bypass
set_mask_register -input_channel_mask_register_sizes 1 7 2 6


set_lpct_controller on -generate_scan_enable on -tap_controller_interface

off -shift_cycles_reg_width 10 -capture_cycles_reg_width 2
-scan_patterns_reg_width 20 -chain_patterns_reg_width 10
-test_mode_detect signal -shift_control clock -load_unload_cycles 0 2
-bypass_controller off -reset_condition off
set_pattern_type -max_sequential 3
add_register_value lpct_config_edt_bypass 0
add_register_value lpct_config_reset_control 0
add_register_value lpct_config_scan_en_control 0
add_register_value lpct_config_chain_pattern_load_count -width 10 \
-load_count chain_patterns -lsb_shifted_first
add_register_value lpct_config_scan_pattern_load_count -width 20 \
-load_count scan_patterns -lsb_shifted_first
add_register_value lpct_config_capture_depth -width 2 -capture_cycles_max \
-lsb_shifted_first
add_register_value lpct_config_shift_length -width 10 -shift_length \
-lsb_shifted_first
set_chain_test -suppress_capture on

timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse /NX1 20 10;
pulse /NX2 20 10;
pulse refclk 20 10;
period 40 ;
end;
procedure load_unload_register lpct_shift_data =

timeplate gen_tp1 ;
shift =
cycle =
force lpct_data_in # ;
pulse refclk ;
end;
end;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
force lpct_shift_en 1 ;
measure_sco ;
pulse /NX1 ;
pulse /NX2 ;
pulse edt_clock ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force /NX1 0 ;
force /NX2 0 ;
force RST 0 ;
force edt_clock 0 ;
force lpct_capture_en 0 ;
force lpct_clock_mux_select 1 ;
force lpct_scan_en 1 ;
force lpct_test_active 1 ;
pulse edt_clock ;
end ;
apply shift 45;
cycle =
force lpct_scan_en 0 ;
end ;
cycle =
end;
end;
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
force lpct_data_in 0 ;
force lpct_reset 1 ;
force lpct_test_mode 0 ;
end ;
cycle =
force lpct_reset 0 ;
end ;
cycle =
force lpct_test_mode 1 ;
end ;
apply lpct_shift_data lpct_data_in = 1 ;
apply lpct_shift_data lpct_data_in = lpct_config_edt_bypass ;
apply lpct_shift_data lpct_data_in = lpct_config_reset_control ;
apply lpct_shift_data lpct_data_in = lpct_config_scan_en_control ;
apply lpct_shift_data lpct_data_in =
lpct_config_chain_pattern_load_count ;
apply lpct_shift_data lpct_data_in =
lpct_config_scan_pattern_load_count ;
apply lpct_shift_data lpct_data_in = lpct_config_capture_depth ;
apply lpct_shift_data lpct_data_in = lpct_config_shift_length ;
apply lpct_shift_data lpct_data_in = 0 ;
end;
procedure test_end =
timeplate gen_tp1 ;
cycle =
end ;
cycle =
end ;
cycle =
end;
end;
Index
Compressed ATPG
Index
—A— commands
add_edt_blocks, 184 add_edt_blocks, 184
add_scan_chains -internal, 98, 137, 371, 372 add_scan_chains, 98, 137, 372
Advanced topics, 187 delete_edt_blocks, 185
Architecture, EDT, 21, 81 report_edt_blocks, 181, 185
—B— report_edt_configurations, 84, 85, 98,
Batch mode, 37 184, 185, 376
Boundary scan report_edt_instances, 185, 341
circuitry, 125 report_edt_lockup_cells, 257
EDT and, 243 report_edt_pins, 86, 90, 94
EDT coexisting with, 243 report_environment, 37, 71
EDT signals driven by, 248 report_scan_volume, 63
inserting, 124 set_bypass_chains, 95
modifying EDT dofile for, 54, 243 set_compactor_connections, 95
modifying EDT test procedure file for, 54, set_current_edt_block, 181, 185
243 set_dofile_abort, 38
pre-existing, 54 set_edt_instances, 185, 341, 371
synthesis, preparing for, 243 set_edt_mapping, 185
top level wrapper for, 125 set_edt_options, 70, 80, 81
Bypass circuitry, 23, 105 set_edt_options pins, 104
customizing, 80, 95 set_edt_pins, 87, 90
diagram, 234 set_logfile_handling, 39
Bypass mode write_edt_files, 100, 185
circuitry, 234 emulating uncompressed ATPG with, 18
generated files for, 103 generating EDT patterns with, 48, 50
single chain, 331 inputs and outputs, 50
Bypass patterns, EDT external flow, 49
flow example, 238 internal flow, 50
using, 238 pre-synthesis flow, 294
Bypassing EDT logic, 233 tool flows, 50
external logic, 24, 47
—C— Compression
Channel input pipeline stages seeEffective Compression
defining, 250 compression
Channel output pipeline stages baseline, 63
defining, 250 Contr ol and channel pins
Clocking in EDT, 25, 83 sharing with functional pins
Commands EDT reset pin, 88
running system, 37 Control and channel pins

basic configuration, 86 for bypass mode (plain ATPG), 374, 376
default configuration, 86, 87 for generating EDT patterns, 82, 372
sharing with functional pins, 87 for inserting scan chains, 56
channel input pin, 88 Dofiles, 37
channel output pin, 88
EDT bypass pin, 89 —E—
EDT clock pin, 88 EDT
EDT configuration pin, 89 as extension of ATPG, 20
EDT reset pin, 81 clocking scheme, 25, 83
EDT scan enable pin, 89 compression
EDT update pin, 88 seeEffective compression
example, 89 configuration, reporting, 84
reporting, 90 control and channel pins
requirements, 87 seeControl and channel pins
summary, 85 definition of, 20
create_skeleton_design, 303 diagnostics
flow, 303, 304 flow example, 238
input file, 307 with EDT bypass patterns, 238
example, 309 EDT bypass patterns, 238
inputs, 307 EDT internal patterns, 157, 158
inputs and outputs, 306, 307 fundamentals, 17
interface file, 310, 315 generating EDT test patterns
outputs, 307, 316 seePattern generation phase
skeleton design, 316 I/O pads and, 46
skeleton design dofile, 316 logic
skeleton design Tessent cell library, conceptual diagram, 21, 164
316 pattern generation
skeleton design test procedure file, 316 seePattern generation phase
pattern size, 63
—D— pattern types supported, 27
Decompressor, 21, 23, 104 scan channels,seeScan channels
delete_edt_blocks command, 185 signals
Design Compiler synthesis script, 106, 123, bypass
126 seePattern generation phase
Design flow, EDT clock
design requirements, 46 seePattern generation phase
tasks and products, 44 internal control of, 25
Design requirements, 46 reset, 81
Design rules checks update
EDT-specific rules (K rules), 25 seePattern generation phase
introduction, 25 EDT internal patterns, 157, 158
TIE-X message, 97 EDT logic
transcript messages, 98 configuration, 81
upon leaving setup mode, 97 architecture, 81
verifying EDT logic operation with, 150 pipeline stages, 80
Dofile creating, 65

multiple configurations managing pre-existing, 53
configuration pin, 89 requirements, 46
parameters, 74 I/O pins, usage, 23
version of, specifying, 81 insert_test_logic -output new, 57, 59
EDT reset signal Intellectual property (IP)
specifying, 81 blocks
Effective compression detailed description of, 326
chain-to-channel ratio and, 367 specification, 326
controlling, 25 synthesizing
Embedded deterministic test Design Compiler and, 123
seeEDT verifying operation of, 150
EMPTY, 92, 138, 155, 157, 159, 243, 248, 249, design rules checks, 150
263, 289, 368, 379 Internal logic location flow
Enhanced procedure file tasks and products, 44
for bypass mode (plain ATPG), 376
External logic location flow —L—
definition of, 24 Length of longest scan chain
steps, 47 specifying, 81
tasks and products, 44 Lockup cells
insertion, 257
—F— reporting, 257
Fault aliasing, 288 Log files, 37
Fault sampling, 278 Logic creation phase
Faults, supported, 27 in EDT design flow, 48
Logic location
—G— external, 24
Generated EDT logic files
Generated files —M—
blackbox description of core, 105 Masking,seeScan chains, masking
described, 101 Memories
edt circuitry, 103, 104 handling of, 44, 365
for bypass mode (plain ATPG) X values and, 285, 365
dofile, 374, 376 Modular Compressed ATPG
enhanced procedure file, 376 generating for a fully integrated design, 179
test procedure file, 376 input channel sharing, 166
for use in EDT pattern generation phase
dofile, 371 —O—
test procedure file, 372 Operating system commands, running within
synthesis script, 106, 107, 123, 126 tool, 37
top-level wrapper, 103 —P—
Generating EDT test patterns Pattern generation
seePattern generation phase seePattern generation phase
—I— Pattern generation phase, 135
I/O pads adding scan chains, 136
adding, 124 EDT signals, controlling
bypass, 136

clock, 136 report_edt_pins command, 86, 90, 94
update, 136 report_scan_volume command, 63
generating EDT patterns, 377 Reset signal, 81
in EDT design flow, 48, 50, 135
optimizing compression, 156 —S—
pattern post-processing, 158 Scan chains
prerequisites, 136 custom masking of, 367
reordering patterns, 290 determining how many to use, 56
setting up, 136 length
simulating EDT patterns, 158 longest, specifying range for, 81
test procedure waveforms, example, 136 limitations on, 55, 104
verifying EDT patterns, 135, 158 masking, 285
Pattern verification, 63 pattern file example, 288
Patterns transcript example, 288
reordering,seePattern generation phase, why needed, 285
reordering patterns Xblocking and, 285
types supported, 25, 27 prerequisites for inserting, 55
Performance reordering
evaluation flow, 277 impact on EDT logic, 103
improving, 280 synthesizing, 53, 55
measuring, 279 uncompressed
Pin sharing defining for EDT pattern generation,
not permitted, 104 137, 165, 372
pemitted, 57, 104 effect on test coverage estimate, 56
permitted, 87 including, 56, 137, 372
Pipeline stages leaving undefined during IP creation,
description of, 248 56
including, 80, 249 modular flow and, 165
Pre-synthesis flow, 294 Scan channels
conceptual diagram, 21
—R— controlling compression with, 21, 27
Reduced netlist definition of, 21
role in Internal logic location flow, 119 introduction, 20
using to improve synthesis run time, 119 pins, sharing with functional pins, 57, 87
writing, 119 Scripts, 37
Reorder set_bypass_chains command, 95
patterns,seePattern generation phase, set_compactor_connections command, 95
reordering patterns set_current_edt_block command, 181, 185
scan chains,seeScan chains, reordering set_edt_instances command, 185, 341, 371
Report set_edt_options command, 70, 80, 81
EDT configuration, 84 set_edt_pins command, 87, 90
report_edt_blocks command, 185 Shell commands, running system commands,
report_edt_configurations command, 84, 85, 37
98, 169, 184, 185, 376 Spacial compactor
report_edt_instances command, 185, 341 connections, customizing, 95
report_edt_lockup_cells command, 257 Spatial compactor, 23, 104

Supported Functions, 17 —W—
Supported pattern types, 25 write_edt_files comma nd, 100
Synthesizing write_edt_files command, 185
scan chains, 53
with a reduced netlist, 119 —X—
X blocking, 286
—T— Xs, observable, 365
Tessent FastScan
command-line mode, emulating with
Tessent TestKompress, 47
creating bypass patterns, 241
Tessent Scan
dofile for inserting scan chains, example,
56
insert_test_logic command, 57, 59
creating logic with, 48
emulating Tessent FastScan with, 47
Test data volume, 278
Test procedure file
for bypass mode (plain ATPG), 376
for generating EDT patterns, 372
Tools used in EDT flow, 44
Troubleshooting, 340
EDT aborted faults, 367
incompressible patterns, 365
K19 through K22 DRC violations, 341
less than expected
compression, 366
test coverage, 366
lockup cells in EDT IP, reporting, 257
masking broken scan chains, 367
simulation mismatches, 339, 340
too many observable Xs, 365
TSGEN, incorrect references to, 124, 364
—U—
User interface
dofiles, 37
log files, 37
running system commands, 37
—V—
Verification of EDT IP, 150
Verification of EDT patterns, 135, 158

Third-Party Information
Details on open source and third-party software that may be included with this product are available in the
<your_software_installation_location>/legal directory.

Edt GD 1

Uploaded by

Copyright:

Available Formats

Edt GD 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Edt GD 1

Uploaded by

Copyright:

Available Formats

SIEMENS EDA

Support Center: support.sw.siemens.com

Revision Changes Status/

Tessent™ TestKompress™ User’s Manual, v2021.3

Revision History ISO-26262

Tessent™ TestKompress™ User’s Manual, v2021.3 5

Defining Dual Compression Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 Tessent™ TestKompress™ User’s Manual, v2021.3

Core Instance Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Tessent™ TestKompress™ User’s Manual, v2021.3 7

Tessent OCC and LPCT Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

8 Tessent™ TestKompress™ User’s Manual, v2021.3

Variance in the Number of Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Tessent™ TestKompress™ User’s Manual, v2021.3 9

Basic Compactor Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

10 Tessent™ TestKompress™ User’s Manual, v2021.3

Tessent™ TestKompress™ User’s Manual, v2021.3 11

12 Tessent™ TestKompress™ User’s Manual, v2021.3

Figure 1-1. EDT as Seen From the Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Tessent™ TestKompress™ User’s Manual, v2021.3 13

Figure 8-5. -shift_control Option: clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

14 Tessent™ TestKompress™ User’s Manual, v2021.3

Table 1-1. Supported Scan Architecture Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Tessent™ TestKompress™ User’s Manual, v2021.3 15

16 Tessent™ TestKompress™ User’s Manual, v2021.3

• Tessent Shell Reference Manual — Contains information on Tessent TestKompress

Tessent™ TestKompress™ User’s Manual, v2021.3 17

Supported Test Patterns

• Random pattern generation.

Tessent TestKompress Inputs

• Scan-inserted gate-level Verilog netlist.

18 Tessent™ TestKompress™ User’s Manual, v2021.3

Tessent™ TestKompress™ User’s Manual, v2021.3 19

Figure 1-1. EDT as Seen From the Tester

20 Tessent™ TestKompress™ User’s Manual, v2021.3

• Number of scan chains in the design core

Structure and Function

Figure 1-2. Tester Connected to a Design With EDT

Tessent™ TestKompress™ User’s Manual, v2021.3 21

22 Tessent™ TestKompress™ User’s Manual, v2021.3

TestKompress Compression Logic

Tessent™ TestKompress™ User’s Manual, v2021.3 23

24 Tessent™ TestKompress™ User’s Manual, v2021.3

Tessent™ TestKompress™ User’s Manual, v2021.3 25

ASCII and Binary Patterns

26 Tessent™ TestKompress™ User’s Manual, v2021.3

To summarize, the compression technology:

• Accepts the same fault models as uncompressed ATPG.

Many parameters limit the effective compression, including the following:

• Number of scan chains in your design core

Tessent™ TestKompress™ User’s Manual, v2021.3 27

• Routing Congestion — There is no limit to the number of internal scan chains,

28 Tessent™ TestKompress™ User’s Manual, v2021.3

TestKompress Usage Flow Overview

EDT IP Creation and Pattern Generation Flow

Tessent™ TestKompress™ User’s Manual, v2021.3 29

30 Tessent™ TestKompress™ User’s Manual, v2021.3

This flow consists of the following stages:

Tessent™ TestKompress™ User’s Manual, v2021.3 31