Edt Deterministic Test Guide

EDT™
(Embedded Deterministic Test)

Process Guide
Software Version 8.2007_2

May 2007
 2001-2007 Mentor Graphics Corporation

All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
RESTRICTED RIGHTS LEGEND 03/97
U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirely
at private expense and are commercial computer software provided with restricted rights. Use,
duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the
restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.7202-
3(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted
Rights clause at FAR 52.227-19, as applicable.
Contractor/manufacturer is:
Mentor Graphics Corporation
8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777.
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: www.mentor.com/supportnet
Send Feedback on Documentation: www.mentor.com/supportnet/documentation/reply_form.cfm
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other third parties. No one is permitted to use these Marks without the
prior written consent of Mentor Graphics or the respective third-party owner. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/terms_conditions/trademarks.cfm.
Table of Contents
Chapter 1
Overview and Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Manual Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
What is EDT?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Understanding EDT Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Solving the Cost of Test Problem with EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
What is the TestKompress Tool?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Overview of the TestKompress Tool Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Comparing EDT and Traditional ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Clocking Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Memories and Non-scan Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
ASCII and Binary Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Comparing EDT and ATPG Test Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Test Quality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Design Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Understanding EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Checking the Logic with EDT-specific DRC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
How Large is the EDT Logic? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Internal Control of EDT Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Controlling EDT Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Setting Up a TestKompress Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
User Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Running Batch Mode Using Dofiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Generating a Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Running UNIX Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Conserving Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Interrupting the Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Exiting the Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapter 2
Understanding the TestKompress Tool Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Top-Down Design Flow with EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Pin Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
I/O Pads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
The EDT Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
External IP Location Flow (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Internal IP Location Flow (Internal Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
EDT Process Guide, V8.2007_2 3

May 2007
Table of Contents
Chapter 3
Scan Chain Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
External EDT Logic Location Flow (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Internal EDT Logic Location Flow (Internal Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Inserting Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Including Uncompressed Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Determining How Many Scan Chains to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Using One Scan Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Avoiding Sharing Scan Chain Pins with Functional Pins. . . . . . . . . . . . . . . . . . . . . . . . . . 51
Reordering Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Examining a DFTAdvisor Dofile Used for EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Establishing a Compression Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Running FastScan ATPG (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Simulating the FastScan Test Patterns (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Chapter 4
Creating the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Understanding TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Invoking TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Preparing for EDT Logic Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Setting Up TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Setting Parameters for the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Running DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
DRC when EDT Pins are Shared with Functional Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Creating the RTL Description of the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Understanding Generated EDT Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Top-level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
EDT Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Design Compiler Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
EDT Pattern Generation Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Bypass Mode Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Estimating Test Coverage and Scan Data Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Chapter 5
Synthesizing the EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Preparing for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
External IP Location Flow (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Internal IP Location Flow (Internal Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Synthesizing a Netlist with the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapter 6
Pattern Generation and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Preparing for Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Using the Automatically Generated EDT Dofile and Procedure File. . . . . . . . . . . . . . . . . 103
Verifying the IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4 EDT Process Guide, V8.2007_2

May 2007
Table of Contents
Generating EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Optimizing Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Saving the Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Post-Processing of EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Simulating the Generated Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Setting Up for HDL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Chapter 7
Special Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Bypassing EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Structure of the Bypass Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Applying Identical Patterns in EDT and Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Using EDT Bypass Patterns in FastScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
EDT Bypass Pattern Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Creating Bypass Patterns with FastScan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
EDT and Boundary Scan (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Flow overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Boundary Scan Coexisting with EDT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Driving EDT Signals with the TAP Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Using Pipeline Stages in the EDT Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using Pipeline Stages Between Pads and Channel Inputs or Outputs. . . . . . . . . . . . . . . . . . 129
Channel Output Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Clocking of Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Initializing the Input Channel Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
DRC for Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
DRC for Channel Output Pipelining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Understanding How Lockup Cells are Inserted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Lockups Between Decompressor and Scan Chain Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . 135
Lockups Between Scan Chain Outputs and Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Lockups in the Bypass Circuitry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Evaluating Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Establishing a Point of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Measuring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Improving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Masking Scan Chain Output Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Why Masking is Needed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Resolving X Blocking with Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Fault Aliasing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Reordering Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Chapter 8
Modular TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Modular TestKompress Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

May 2007
Table of Contents
Planning Your Modular TestKompress Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Modular TestKompress Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Balancing Scan Chains Within and Between Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
User Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Creating EDT Logic for Each Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Generating Modular EDT Logic for a Fully Integrated Design . . . . . . . . . . . . . . . . . . . . . 162
Applying Unique Names to Modules within the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . 162
Estimating a Block’s Coverage and Pattern Count. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Synthesizing Block-level EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Verifying EDT Logic for a Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Preparing the Top-level Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Integrating EDT Blocks into the Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Integrating Block-level Dofiles into a Top-level Dofile. . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Integrating Block-level Test Procedure Files into One File . . . . . . . . . . . . . . . . . . . . . . . . 177
Generating Top-level Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Creating Block-level EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Generating Top-level Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Modular TestKompress Command Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 9
Pre-Synthesis EDT Logic Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Performing a Pre-Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Skeleton Design Input and Interface Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Skeleton Design Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Skeleton Design Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
create_skeleton_design Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Creating EDT Logic Using a Skeleton Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
How the Tool Uses the -Longest_Chain_Range Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 199
Integrating the EDT Logic into the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Knowing When to Regenerate the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Input File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Online Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Examples and Solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Appendix B
IP Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Appendix C
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Debugging Simulation Mismatches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Resolving DRC Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

May 2007
Table of Contents
K19 through K22 DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Incorrect References to \**TSGEN** in Synthesized Netlist . . . . . . . . . . . . . . . . . . . . . . 235
Limiting Observable Xs for a Compact Pattern Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Applying Incompressible Patterns Thru Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Independent Shift Limitation of VHDL Parallel Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . 237
If EDT Compression is Less Than Expected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
If Test Coverage is Less Than Expected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Glossary
Index
Third-Party Information
End-User License Agreement

May 2007
List of Figures
Figure 1-1. EDT as Seen from the Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 1-2. Tester Connected to a Design with EDT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 1-3. Summary of Example Results Obtainable with EDT . . . . . . . . . . . . . . . . . . . . . 25
Figure 1-4. Tester Memory Map for ATPG and EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 1-5. EDT Logic Located Outside the Core (External Flow) . . . . . . . . . . . . . . . . . . . 28
Figure 1-6. EDT Logic Located Within the Core (Internal Flow). . . . . . . . . . . . . . . . . . . . . 29
Figure 2-1. Top-Down Design Flow External . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 2-2. Top-Down Design Flow Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 2-3. EDT External Flow with TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 2-4. EDT Internal Flow with TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 3-1. Scan Chain Insertion and Synthesis Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 4-1. EDT Logic Creation Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 4-2. Example of a Basic EDT Pin Configuration (External EDT Logic). . . . . . . . . . 65
Figure 4-3. Example of a Basic EDT Pin Configuration (Internal EDT Logic) . . . . . . . . . . 66
Figure 4-4. Example with Pin Sharing Shown in Table 4-1(External EDT Logic) . . . . . . . . 71
Figure 4-5. Contents of the Top Level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4-6. Contents of the “edt” Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 4-7. Design Netlist with Internal Connection Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 5-1. Preparing For and Synthesizing the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 5-2. Contents of Boundary Scan Top Level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 6-1. EDT Pattern Generation and Verification Procedure . . . . . . . . . . . . . . . . . . . . . 101
Figure 6-2. Sample EDT Test Procedure Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 6-3. Example Decoder Circuitry for Six Scan Chains and One Channel. . . . . . . . . . 106
Figure 6-4. Circuitry in the Pattern Generation Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 7-1. Bypass Mode Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Figure 7-2. Evaluation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Figure 7-3. X-Blocking in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Figure 7-4. X Substitution for Unmeasurable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Figure 7-5. Example of Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Figure 7-6. TestKompress Handling of Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . 148
Figure 7-7. Example of Fault Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 7-8. Using Masked Patterns to Detect Aliased Faults . . . . . . . . . . . . . . . . . . . . . . . . 151
Figure 7-9. Handling Scan Chains of Different Length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Figure 8-1. Modular TestKompress Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Figure 8-2. Block-Level EDT Logic Creation and Verification . . . . . . . . . . . . . . . . . . . . . . 156
Figure 8-3. Design that Contains Several EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Figure 8-4. Block-level Netlist and Script Integration Flow . . . . . . . . . . . . . . . . . . . . . . . . . 161
Figure 8-5. EDT-specific Netlist Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Figure 8-6. Creation of Top Level Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Figure 8-7. Creating Top-level Dofile for a Design with Two EDT Blocks . . . . . . . . . . . . . 175

May 2007
List of Figures
Figure 8-8. Creation of Top Level Test Procedure File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Figure 8-9. Creating a Top-level Timeplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 8-10. Creating a Top-level Load_unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 179
Figure 8-11. Creating a Top-level Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Figure 8-12. Netlist with Two Cores and Shared TestKompress Control Signals . . . . . . . . 185
Figure 9-1. TestKompress Pre-synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Figure 9-2. Create_skeleton_design Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Figure C-1. Flow for Debugging Simulation Mismatches. . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Figure C-2. Order of Diagnostic Checks by the K19 DRC . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Figure C-3. Order of Diagnostic Checks by the K22 DRC . . . . . . . . . . . . . . . . . . . . . . . . . . 228

May 2007
List of Tables
Table 1-1. Supported EDT Logic/Scan Architecture Combinations . . . . . . . . . . . . . . . . . . 21

Table 2-1. Supported EDT IP/Scan Architecture Combinations . . . . . . . . . . . . . . . . . . . . . 40
Table 4-1. Example Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table 4-2. Default EDT Pin Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 7-1. Lockup Cells Between Decompressor and Scan Chain Inputs . . . . . . . . . . . . . . 136
Table 7-2. Lockup Cells Between Scan Chain Outputs and Compactor . . . . . . . . . . . . . . . 137
Table 7-3. Bypass Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Table 7-4. Summary of Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Table 8-1. Modular TestKompress Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

May 2007
Chapter 1
Overview and Key Concepts
The EDT ™ Process Guide is part of the EDT-specific documentation in the design-for-test
(DFT) document set. EDT-specific documentation also includes the TestKompress® chapter of
the Design-for-Test Release Notes, the TestKompress command reference pages from the
ATPG and Failure Diagnosis Tools Reference Manual, and the EDT-specific design rules
checking (DRC) described in the “EDT Rules” section of the Design-for-Test Common
Resources Manual.
Manual Organization
This manual is divided into the following chapters:
• Chapter 1, beginning with “What is EDT?” on page 12, discusses the basic concepts
behind the Mentor Graphics EDT technology and the TestKompress product, establishes
the framework in which TestKompress is used, and briefly describes some strategies of
its use. The chapter concludes with a “User Interface Overview”.
• Chapter 2 gives conceptual information necessary for you to utilize TestKompress in an
existing FastScan™ flow, and to make optimal strategy decisions regarding EDT.
• Chapter 3 describes how to prepare a design for EDT and how to perform scan chain
insertion as part of the EDT flow.
• Chapter 4 discusses how to use TestKompress to create EDT logic.
• Chapter 5 discusses the EDT-specific aspects of synthesizing a design that includes
EDT.
• Chapter 6 discusses how to use TestKompress to generate patterns for a design with
EDT.
• Chapter 7 covers additional topics to increase your understanding of TestKompress and
the EDT technology.
• Chapter 8 describes how to use TestKompress for ATPG on designs comprised of
separate interconnected blocks or modules of logic.
• Chapter 9 describes how to create EDT logic before the core is synthesized.
• Appendix A describes available help resources.
• Appendix B provides a detailed specification of the EDT logic, showing its major
components and how they are interconnected.
• Appendix C provides troubleshooting information for simulation mismatch debugging,
DRC issues, and miscellaneous problems.

May 2007
What is EDT?
What is EDT?
Consistent with Moore’s law, design sizes are increasing very rapidly. For design-for-test
(DFT), particularly scan and ATPG, this means the volume of scan test data and test time are
likely to continue growing exponentially. Test costs, which depend on the volume of test data
and test time, will therefore continue to represent a major and rapidly increasing percentage of
an integrated circuit’s manufacturing costs.
EDT™ (Embedded Deterministic Test) is the Mentor Graphics technology that offers a new
non-intrusive DFT methodology for reducing test data volume and test time dramatically. EDT
accomplishes this reduction by applying a new type of compression during deterministic test
vector generation (ATPG), and providing hardware that is embedded on-chip to receive and
decompress the patterns before delivering them to the core. The embedded EDT hardware also
compacts the test results before returning them to the tester. The benefit of using such a reduced
volume of data is that tester memory and channel requirements are reduced proportionally. The
reduced data volume, along with the embedded technology, results in much shorter test
application times and higher tester throughput than with traditional ATPG.
EDT technology is based on traditional, deterministic ATPG1, so you obtain the same fault
models, test coverage, and a very similar flow. EDT simply expands the well-proven
capabilities of ATPG by providing you with vastly improved compression of scan test data and
a much greater reduction in test time. Together, the compression of time and data enable you to
use less expensive structural testers and prolongs the life of existing automatic test equipment
(ATE).
Understanding EDT Basics

Each scan pattern has to be shifted serially through the scan chains. The time required to shift in
patterns is proportional to the length of the chains. For a given design, a higher number of
shorter scan chains results in shorter test times because shorter chains require proportionally
fewer shifts per pattern. However, the number of scan chains is limited by the ATE or by the
chip packaging and I/O restrictions. For testers with scan options, the number of scan chains is
typically 8, 16, or 32. For functional testers, the number of scan chains can be in the hundreds
for ICs with large pin counts.
As designs grow in size, additional test patterns are required to achieve the same level of
coverage and maintain the escape rate—the number of defective parts shipped to customers—at
an acceptable level. Even with the same number of scan patterns, test data volume and scan test
time will increase due to the increasing number of scan cells. Before EDT, additional patterns
meant that additional memory was required on the ATE to store test data and that the test time
would increase. As long as test patterns can fit in tester memory, test time is linear to the
1. For an introduction to deterministic ATPG, refer to Chapter 2, “Understanding Scan and ATPG Basics,”
in the Scan and ATPG Process Guide.

May 2007
number of test patterns. If the test patterns cannot fit in the tester’s memory, there are usually
three possible solutions, none of them ideal:
• Load as much data as possible into the tester’s memory, and then reload the tester when
the first part of the test is complete. Reloading is expensive in terms of time.
• Divide the test into multiple programs and run them in multiple passes. This, too, is
expensive in terms of time.
• Truncate the test pattern set, which reduces the overall test quality and increases the
escape rate.
For a scan-based test, a good approximation of the test data volume is given by the product of
the number of scan patterns and the number of scan cells:
Test Data Volume = ( # of Scan Cells ) × ( # of Scan Patterns )
The number of scan cells is proportional to the design size; typically, there is one scan cell for
every 20 to 30 gates.
The test time depends on the length of the longest scan chain (the number of scan cells it
contains) and on the number of test patterns. The following three equations summarize how the
number of scan cells and scan patterns determine test time:
# of Scan Cells
Scan Chain Length = ----------------------------------------
# of Scan Chains
# of Scan Cells
# of Test Cycles = ---------------------------------------- × # of Scan Patterns
# of Scan Chains
1
Test Time = # of Test Cycles × -------------------------
Frequency
To reduce test data volume, ATPG tools apply various software-based compression techniques
to ensure the order of patterns in the pattern set is optimal and that each pattern detects as many
faults as possible. Even with increasingly sophisticated compression techniques, an increasing
number of integrated circuit (IC) designs are reaching the point where test data volume exceeds
tester limits. Either test patterns have to be truncated and the quality levels reduced, or other
(more efficient) DFT approaches must be used.
Another way to reduce test cost is to use logic built-in self-test (LBIST™). Logic BIST also uses
internal scan, but provides for generation of test patterns on-chip using a pseudo-random pattern
generator. The results are captured in a signature generator. Because the patterns are non-
deterministic, some patterns may not detect any additional faults and the test coverage is
typically lower than for ATPG. To compensate for this, test points are typically inserted in the

May 2007
design. It is also necessary to ensure no unknown values (X states) propagate to the signature
register. Additionally, the random nature of the patterns makes it difficult to use logic BIST for
fault models other than stuck-at. One major advantage of logic BIST is its applicability in field
and system tests. In these applications, it is often acceptable to have lower test coverage than for
manufacturing test. For manufacturing test, logic BIST is often combined with top-up ATPG
patterns to achieve the test quality you want. The number of top-up patterns can consist of up to
40% of the ATPG patterns needed if the design was tested only with ATPG rather than logic
BIST combined with top-up ATPG.
Therefore, where test data volume and test time must be reduced, neither logic BIST nor
conventional ATPG are ideal solutions for designs requiring high quality test and minimal
impact of DFT circuitry on the design.
Solving the Cost of Test Problem with EDT

EDT technology achieves much higher 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 EDT patterns. The following sections detail how this is done.
Understanding EDT Scan Channels

With EDT, the number of internal scan chains is significantly larger than the number of external
“virtual” scan chains the EDT hardware presents to the tester. Figure 1-1 illustrates
conceptually how a design tested using EDT technology is seen from the tester compared to the
same design tested using conventional scan and ATPG.

May 2007
Figure 1-1. EDT as Seen from the Tester
Conventional ATPG
EDT
Scan chains Internal Scan chains
Scan channels
(virtual scan chains)
Under EDT methodology, the “virtual” scan chains are called scan channels to distinguish them
from the scan chains inside the core.1 Their number is significantly less than the number of
internal scan chains. You control the amount of compression by varying two parameters:
• the number of scan chains in your design core, and

• the number of channels (“virtual” scan chains) the EDT logic should present to the
tester. This must be the same as the number of tester channels, so is usually fixed.
Their ratio is called the chain-to-channel ratio:
# of Scan Chains
Chain-to-channel ratio = ----------------------------------------------
# of Scan Channels
For example, if there are two external channels feeding the embedded EDT circuitry, which in
turn drives 20 internal scan chains, the chain-to-channel ratio for the scan data is 20/2 = 10.
The effective compression, which is the actual amount of compression you achieve with EDT,
is less than the chain-to-channel ratio. The example in the section, “Comparing EDT and
Traditional ATPG” demonstrates how you determine the effective compression. The key point
1. The term “scan channel” is used from now on to refer to a “virtual” scan chain as seen by the tester when
a chip includes EDT technology.

May 2007
to remember is EDT compression is achieved by reducing the amount of data per pattern and
not by reducing the number of patterns as in traditional ATPG. The pattern count is usually
slightly higher, everything else being equal, than with traditional ATPG.
Understanding the Structure and Function of the EDT

Architecture
EDT technology consists of logic embedded on-chip, new EDT-specific DRC, and a new
deterministic pattern generation technique. You create and insert the EDT logic in a part of the
EDT flow referred to as the “EDT Logic Creation Phase.” Following that, in the “EDT Pattern
Generation Phase,” you generate and verify the EDT patterns. The next two sections provide an
overview of the EDT logic and of how EDT patterns function with it.
EDT logic
Figure 1-2 shows conceptually how the EDT logic is structured with respect to the design core
and consists of two main components: a decompressor and a spatial compactor.
Figure 1-2. Tester Connected to a Design with EDT
IC
D
e C
ATE c o Scan
Scan o
Channel m m Channel
Inputs
p Core Design p Outputs
r with Scan Chains a
Compressed c
Patterns e t
s o
s r
o
r
Compressed
Expected Response
A decompressor is located between the external scan channel inputs and the internal scan chain
inputs. A spatial1 compactor is inserted between the internal scan chain outputs and the external
scan channel outputs. You have the option of including bypass circuitry for which a third block
(not shown) is added. No additional logic (test points or X-bounding logic) is inserted into the
core of the design. Therefore, the EDT logic affects only scan channel inputs and outputs, and
1. The spatial compactor block compacts the outputs of many internal scan chains into a few external scan
channel outputs, reducing the need for space that otherwise would be required for routing multiple scan chain
outputs. In this manual, the shorter term “compactor” refers to the spatial compactor.

May 2007
thus has no effect on functional paths. The size of the EDT logic is comparable to the size of a
boundary scan Test Access Port (TAP) or a memory BIST controller.
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 EDT pattern has a small number of initialization cycles, so the
total number of shifts per pattern would be slightly more than the number of scan cells in each
chain.
For example, if each chain has 1,250 scan cells and each EDT pattern requires four initialization
cycles, the tester sees a design with two chains requiring 1,254 shifts per pattern. After
initialization, these patterns apply one bit of data to each decompressor input in each clock cycle
(two bits total, in parallel, on the two channel inputs). In the same clock cycle, the decompressor
outputs load the 20 internal scan chains. Compared to a traditional ATPG design, an EDT
design has the same number of scan channels interfacing with the tester, but many more scan
chains. Because the scan chains are balanced, they are much shorter and thus require
proportionally fewer shift cycles to load.
How EDT Patterns Work with the EDT Logic

EDT pattern generation is deterministic. For a given testable fault, a pattern generated for EDT
satisfies ATPG constraints and can avoid bus contention, similar to conventional ATPG. The
difference is the pattern is in EDT compressed format.
A set of such patterns is stored on the tester and each pattern provides the data applied to the
decompressor and holds the responses observed on the outputs of the compactor. The tester
applies the compressed patterns to the circuit through the EDT logic, which lies between the
scan channel pins and the internal scan chains. The decompression operation is transparent to
the tester, so you do not have to modify the tester. From the perspective of the tester, there are
relatively few “virtual” scan chains, and not the many scan chains physically present in the
design.
The compressed 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 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 response captured in the scan cells
is compressed by the spatial compactor and the compressed response is compared on the tester.
The compactor ensures faults are not masked and X-states do not corrupt the response.
Note
EDT compactors can tolerate unknown states (Xs), unlike time-based compactors, such
as multiple input signature registers (MISRs).

May 2007
What is the TestKompress Tool?

The Mentor Graphics® TestKompress® tool implements the EDT™ technology.
As an EDT tool, it performs two major functions:
• Creates Verilog or VHDL register-transfer level (RTL) descriptions of the hardware for
decompressing EDT patterns and compacting test responses.
• Generates patterns compressed specifically for on-chip processing by the EDT
hardware.
In performing these functions, the tool allows you to 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 logic based on the parameters you
specify and 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. The tool generates test patterns based
primarily on the number of channels you specify. Test patterns include parallel and serial test
benches for Verilog and VHDL, as well as parallel and serial WGL, and most other formats
supported by FastScan™.
TestKompress can also emulate FastScan running in command-line mode. In this mode, the tool
provides traditional FastScan capability (minus the GUI). Enter a “set edt off” command
immediately after invoking on a netlist in one of the formats supported by FastScan and you can
then use the tool with that netlist just like you would a standalone version of FastScan.
The next section provides a brief overview of the steps and commands in the TestKompress
tool’s EDT flow. Following that, the remainder of the chapter covers these additional
introductory topics:
• Comparing EDT and Traditional ATPG

• Comparing EDT and ATPG Test Performance
• Understanding EDT Logic
• Controlling EDT Compression
• User Interface Overview
In the chapters that follow, use of TestKompress is described in detail. In this manual,
references to TestKompress mean the EDT capability of the tool, and references to FastScan
mean either FastScan or the FastScan command-line mode of TestKompress.
Overview of the TestKompress Tool Flow

This section outlines the TestKompress default flow by briefly introducing the steps and
commands required to incorporate EDT technology in a gate level Verilog netlist. This

May 2007
summary does not provide full details for running the tool, but rather is intended to familiarize
you with the three main activities in the tool’s flow:
• Creating the EDT Logic

• Synthesizing the EDT Logic
• Generating EDT Patterns
Note
The commands shown in bold font in the following examples are EDT-specific and,
therefore, likely the only commands that are unfamiliar.
Creating the EDT Logic
1. Invoke TestKompress on Your Gate Level Netlist

<mgcdft tree>/bin/testkompress …/gatelevel_netlist.v -verilog \
-library $ATPG_LIB -dofile edt_ip_creation.do \
-logfile …/transcripts/edt_ip_creation.log -replace
2. Provide TestKompress Commands
Tip: The following commands can be located in the dofile used for invocation in step 1.
// Setup TestKompress.
add scan groups grp1 …/generated/atpg.testproc
add scan chains chain1 grp1 edt_si1 edt_so1
...
analyze control signals -auto_fix
// Specify the number of scan channels.

set edt -channels 1
// Flatten the design, run DRCs.

set system mode atpg
// Verify the EDT configuration is as expected.

report edt configuration -verbose
// Generate the RTL EDT logic and save it.

write edt files created -verilog -replace
// At this point, you can optionally create patterns (without saving them)
// to get an estimate of the potential test coverage.
create patterns
// Create reports
report statistics

May 2007
report scan volume
// Close the session and exit.

exit
Synthesizing the EDT Logic
1. Run Design Compiler

Note
The Design Compiler synthesis script referenced in the following invocation line is
output from “write edt files” in preceding step 2.
dc_shell -f …/created_dc_script.scr |& tee …/transcripts/dc_edt.log
Generating EDT Patterns
1. Invoke TestKompress on the Netlist with the Synthesized EDT Circuitry

Note
The netlist created_edt_top.v referenced in the following invocation line is output from
“write edt files” (see step 2 of the earlier section, “Creating the EDT Logic”).
<mgcdft tree>/bin/testkompress …/created_edt_top.v -verilog \

-library $ATPG_LIB -dofile edt_pattern_gen.do \
-logfile …/transcripts/edt_pattern_gen.log -replace
2. Provide TestKompress Commands

// Run the *_edt.dofile output from “write edt files” when creating
// the EDT logic.
dofile …/created_edt.dofile

// Verify the EDT configuration.

report edt configuration
// Generate patterns.
create patterns
// Create reports.
report statistics
report scan volume
// Save the patterns in ASCII format.

save patterns …/generated/patterns_edt.ascii -ascii -replace
// Save the patterns in parallel and serial Verilog format.

May 2007
Comparing EDT and Traditional ATPG
save patterns …/generated/patterns_edt_p.v -verilog -replace -parallel

save patterns …/generated/patterns_edt_s.v -verilog -replace -serial
-sample 2
// Save the patterns in tester format; WGL for example.

save patterns fs_out/test_patterns.wgl -wgl -replace
// Close the session and exit.

exit

TestKompress 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. However, you can direct the
tool to create latch-based logic for pure LSSD designs. Table 1-1 summarizes the EDT
logic/scan architecture combinations the tool supports.
Table 1-1. Supported EDT Logic/Scan Architecture Combinations

Scan Architecture
EDT Logic LSSD Mux-DFF Mixed
Architecture
DFF-based Supported Supported Supported
Latch-based Supported Not supported Not supported
Clocking Scheme
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; the EDT logic
does not interfere with the system clock(s) in any way.
You can set up the EDT clock to be a dedicated pin (named edt_clock by default) or you can
share the EDT clock with a functional non-clock pin. Such sharing may cause a decrease in test
coverage because TestKompress must constrain the EDT 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 could be disturbed when the EDT clock is
pulsed in the load_unload procedure 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 clock is
constrained to its off-state during the capture cycle.

May 2007
Because the clock used in the EDT logic is different than the scan clock, the tool can insert
lockup cells automatically between the EDT logic and the scan chains as needed. TestKompress
inserts lockup cells as part of the EDT logic; the tool never modifies the design core.
Latch-based EDT logic uses two EDT clocks (a master and a slave clock) to drive the logic. For
reasons similar to those listed above for DFF-based logic, you must not share the master EDT
clock with the system master clock. You can, however, share the slave EDT clock with the
system slave clock.
Note
During the capture cycle, the system slave clock, which is shared with the slave EDT
clock, is pulsed. This does not affect the EDT logic because the values in the master
latches do not change. Similarly, in the load_unload cycle, although the slave EDT clock
is pulsed, the value at the outputs of the system slave latches is unchanged because the
slave latches capture old values.
In a skew load procedure, when a master clock is only pulsed at the end of the shift cycle
(so different values can be loaded in the master and slave latches), the EDT logic is
unaffected because the master EDT clock is not shared.
Memories and Non-scan Cells

No special handling is required for memories or other non-scan sequential elements. As for
FastScan, it is an advantage to model the memories and controllable memory clocks, so that
RAM sequential or clock-sequential patterns can be used. If the memory is not controllable or
not modeled, the coverage may be reduced. You can test non-scan flip-flops using clock-
sequential patterns. Bounding of X sources is not required.
ASCII and Binary Patterns

TestKompress can write out patterns in ASCII and binary formats, and can read these patterns
back in. As in FastScan, you use these formats primarily for debugging simulation mismatches
and archiving. However, for EDT, the data is arranged differently than in ASCII patterns saved
from FastScan.
When you create patterns with TestKompress, it stores the captured data with respect to the
internal scan chains, but stores the load data with respect to the external scan channels. The load
data you see in the pattern file is thus in its compressed format—the form in which it is fed to
the EDT decompressor.
Another difference from FastScan is that with the TestKompress simulator, Xs may not be due
to capture; they may result from the tool’s emulation of the EDT compactor. For a detailed
discussion of this effect and how TestKompress limits it with masking, refer to Chapter 7,
“Masking Scan Chain Output Pins.”

May 2007
Diagnostics
TestKompress supports the same diagnostics that YieldAssist supports. Basically, you perform
a diagnosis by collecting the failing pattern data from the tester, placing it in a failure file that
you can provide as input to the tool’s Diagnose Failures command, then running the command
to obtain a diagnostics report. For complete information on these tool’s diagnostics capabilities
and how to use them, refer to the YieldAssist User’s Guide.
Comparing EDT and ATPG Test Performance

The following subsections illustrate, with an example circuit containing 64,000 flip-flops, the
difference in test performance using a 16 scan channel tester with traditional FastScan ATPG
versus EDT implemented with the TestKompress tool. The comparisons focus on the two key
determinants of the cost of test: tester memory requirements and test cycles.
Tester memory requirements are determined by the number of tester channels and the volume of
test data. The data volume depends on the number of patterns and the number of shifts per
pattern:
Tester Memory = ( # of Channels ) × ( # of Patterns ) × ( # of Shifts per Pattern )
The number of test cycles, which is directly proportional to test time, depends on the number of
patterns and the number of clock cycles (shifts) required per pattern.
# of Test Cycles = ( # of Patterns ) × ( # of Shifts per Pattern )
Traditional Scan/ATPG
In traditional scan/ATPG, when the design is configured into 16 scan chains, each chain has
approximately 64,000/16 = 4,000 scan cells. If ATPG requires 4,200 patterns, 4,000 cycles
deep, the required tester memory is:
6
Tester Memory (ATPG) = 16 × 4200 × 4000 = 268.8 ×10
The number of test cycles is:

6
# of Test Cycles (ATPG) = 4200 × 4000 = 16.8 ×10
EDT Technology
When you use EDT technology, you can configure the same design into 160 internal scan
chains of 400 flip-flops each. This gives a chain-to-channel ratio of 10 (160/16) and requires
4,400 patterns, 404 cycles deep.

May 2007
Note
Four additional cycles per pattern are required for initialization of the EDT circuitry in
this example. The number of initialization cycles varies depending on the specific design
and the EDT configuration you use. The number of shift cycles is more than the length of
the longest chain (reported during DRC) because the tool must apply additional cycles
with every EDT pattern to set up the decompressor.1
The required tester memory for EDT is therefore much less:

6
Tester Memory (EDT) = 16 × 4400 × 404 = 28.4 ×10
The calculation of test cycles shows that it also is much less:

6
# of Test Cycles (EDT) = 4400 × 404 = 1.78 ×10
Effective Compression
The ratio of the tester memory figures in the two cases gives you the effective compression due
to EDT:
Tester Memory(ATPG) 268.8
Effective Compression = -------------------------------------------------------- = ------------- ≈ 9.45
Tester Memory(EDT) 28.4
Because it accounts for the initialization cycles and the slightly higher pattern count, the
effective compression is about 9.5X, slightly less than the chain-to-channel ratio of 10.
You can also calculate effective compression using the ratio of test cycles:
# of Test Cycles(ATPG) 16.8
Effective Compression = ---------------------------------------------------------- = ---------- ≈ 9.45
# of Test Cycles(EDT) 1.78
Figure 1-3 summarizes the ATPG and EDT configuration and results for this design. As
illustrated in the figure, both the number of test cycles and the tester memory required are
reduced by about 9.45 times (9.45X).
1. (# of Scan Cells / # of Scan Chains) is used to estimate the number of shifts (clock cycles) per pattern in
traditional scan and ATPG. For a design with EDT, the estimate additionally includes the number of
initialization cycles required by each EDT pattern, as follows:
# of Shifts per Pattern (EDT) = (# of Scan Cells / # of Scan Chains) + # of Init Cycles per Pattern

May 2007
Figure 1-3. Summary of Example Results Obtainable with EDT

ATPG EDT
4,000 404
1
1 2
3
2
3
1
2
4,200 3 4,400
patterns patterns
16
160
16
Test cycles: Test cycles:

4,200*4,000 4,200 * 4,000 4,400*404
= 9.45
Tester Memory: 4,400 * 404 Tester Memory:
16*4,200*4,000 16*4,400*404
Figure 1-4 illustrates how the tester memory requirements are reduced with EDT. Each column
represents a scan channel: 16 channels both for EDT and ATPG.

May 2007
Figure 1-4. Tester Memory Map for ATPG and EDT Patterns
1st EDT Vector 404

2nd EDT Vector 404
1st 9.9
X 3rd EDT Vector
4th EDT Vector
404
404
4000
ATPG 5th EDT Vector
6th EDT Vector
7th EDT Vector
404
404
404
Vector
X
8th EDT Vector 404
9.9
9th EDT Vector 404
10th EDT Vector 404
11th EDT Vector 404
12th EDT Vector 404
2nd 4394th EDT Vector 404
4000
ATPG 4395th EDT Vector
4396th EDT Vector
4397th EDT Vector
404
404
404
Vector 4398th EDT Vector

4399th EDT Vector
4400th EDT Vector
404
404
404
16
4200th
ATPG 9.45X compression overall
Vector (due to greater number
of EDT patterns)
16
Test Quality
EDT uses compression algorithms that are fault-model independent and pattern-type
independent. The 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 and/or generated by FastScan.
Note
TestKompress does not currently support random pattern generation.
Support for FastScan MacroTest is limited to bypass mode: you can apply MacroTest
patterns to a design with EDT technology only by accessing the scan chains directly,
bypassing EDT.
To summarize:

May 2007
Understanding EDT Logic
• EDT accepts the same fault models as ATPG.

• EDT accepts the same deterministic pattern types as ATPG (TestKompress support of
MacroTest is limited, however, as noted previously).
• EDT can achieve the same test coverage as ATPG.
Design Impact
Compared to scan, EDT has no additional impact on functional logic. The EDT decompressor is
placed between the chip pins and internal scan inputs, and the compactor is placed between the
internal scan outputs and chip pins. The impact of pin sharing in EDT (functional pins shared
with the decompressor inputs and compactor outputs) is the same as with pin sharing in
conventional scan. Because EDT patterns are deterministic, random pattern resistance does not
present any problem, and there is no need for test points. There is also no need for bounding
logic to mask unknown states. The compactor can handle unknown states.
EDT requires a signal for update of the compactor register and decompressor reset. This pin can
be shared with a functional pin. The EDT circuitry also requires a separate clock pin, which also
can be shared with a functional pin. This pin has to be constrained in capture. If you choose to
include bypass circuitry (for direct access to the internal scan chains), a bypass mode pin is
needed. It, too, can be shared.
EDT offers these advantages compared to other compaction methods:
• No hardware (test points or bounding logic) is added inside the design.

• X sources are acceptable. No bounding logic is necessary.

TestKompress generates hardware as EDT logic blocks in VHDL or Verilog RTL. You
integrate the EDT logic into your design by invoking the tool on the core level of the design.
The tool then generates the following 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.
• Compactor—Compacts the test responses from the scan chains in your core design into
a small number of scan output channels. Compacts test responses as they are shifted out.
• 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.
The decompressor resides between the channel inputs (connected to the tester) and the scan
chain inputs of the core. Its main parts are an LFSM and a phase shifter. The compactor resides
between the core scan chain outputs and the channel outputs connected to the tester. It primarily

May 2007
consists of spatial compactor(s) and gating logic. If you choose to implement bypass circuitry,
the tool includes bypass multiplexers in the EDT logic. Chapter 7, “Bypassing EDT Logic,”
discusses bypass mode.
The previously mentioned components of the EDT logic are all contained within an EDT block
that, by default, is instantiated in a top level “wrapper” module. The design core is also
instantiated in the top level wrapper. This is illustrated conceptually in Figure 1-5. You insert
pads and I/O cells on this new top level. Because the EDT logic is outside the core design (the
netlist on which you invoked the tool), the tool flow you use to implement this configuration is
referred to as the external EDT logic location flow, or simply “external flow.”
Figure 1-5. EDT Logic Located Outside the Core (External Flow)
edt_channels_in edt_channels_out PIs POs
edt_top
edt_clock edt
edt_scan_in
edt_update edt_ edt_
decompressor compactor
core
edt_bypass edt_ edt_scan_out

bypass (opt.)
Alternatively, you can invoke TestKompress on a design that already contains I/O pads. For
these designs, the tool enables you to insert the EDT block in the existing top level within the
original design. This is shown conceptually in Figure 1-6. Because the EDT logic is instantiated
within the netlist TestKompress was invoked on, this configuration is referred to as the internal
EDT logic location flow, or “internal flow.”

May 2007
Figure 1-6. EDT Logic Located Within the Core (Internal Flow)
edt_channels_in edt_channels_out PIs POs
core with I/O Pads
edt
edt_clock edt_scan_in
edt_ edt_ Module A
edt_update decompressor compactor edt_scan_out
edt_ edt_scan_in
edt_bypass bypass (opt.)
edt_scan_out Module B
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. The Chapter 7 section, “Understanding How Lockup
Cells are Inserted,” describes in detail how the tool determines where to put the lockups.
Checking the Logic with EDT-specific DRC Rules

The TestKompress tool performs the same ATPG design rules checking (DRC) after design
flattening that FastScan performs. A detailed discussion of DRC is included in “ATPG Design
Rules Checking” in the Scan and ATPG Process Guide.
The tool also checks a separate class of DRC rules, the K class, which is specifically for EDT.
For information on how to interpret these rules, refer to Chapter 4, “Running DRC.” The “EDT
Rules (K Rules)” section in the Design-for-Test Common Resources Manual provides reference
information on each EDT-specific rule.
How Large is the EDT Logic?

Mentor Graphics engineers measured the size of the EDT logic compared to a logic BIST
controller, a memory BIST controller, and a TAP controller. They also measured how the size
of the EDT logic changes with the size of the circuit.

May 2007
Controlling EDT Compression
The Conclusions
• A rough estimate of the size of the EDT logic is 25 gates per internal scan chain.
• 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.
• For a one million gate design configured into 200 internal scan chains, a complete EDT
logic block with the decompressor, compactor, and bypass circuitry with lockup cells
required 3,500 two-input equivalent gates, or less than 20 gates per chain. The logic
occupied an estimated 0.35% of the area. The size of the EDT logic does not vary much
with the size of the design.
• The EDT logic for eight scan channels and 100 internal scan chains 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.
Internal Control of EDT Signals

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 disable the edt_clock in functional
mode. For detailed information about how to do this with boundary scan, refer to the “EDT and
Boundary Scan (External Flow)” section of Chapter 7.
Controlling EDT Compression

As described in the section, “Comparing EDT and ATPG Test Performance,” the compression
in the scan data due to EDT (relative to traditional ATPG) is a function of three factors:
• Chain-to-channel ratio: The ratio of scan chains (internal to the core) to scan channels
(external)
• Change in the total number of patterns
• Change in the number of shift cycles for each pattern
You only have direct control of the chain-to-channel ratio. The three factors are, however,
related. The higher the ratio of internal scan chains to external scan channels, the higher the
compression per pattern; but that increases the possibility of TestKompress generating patterns
it cannot compress and can lead to lower test coverage. Higher chain-to-channel ratios also
decrease the number of faults dynamic compaction can fit into a pattern. This can increase the
total number of patterns and, therefore, decrease overall compression.
The tool does not limit the number of internal scan chains. You may find, however, that routing
constraints limit the chain-to-channel ratio. Most practical configurations do not exceed the
tool’s capability to compress patterns. That is, the tool is unlikely to abort on a fault for which it
generated a test pattern that could not be compressed.

May 2007
Setting Up a TestKompress Library
Setting Up a TestKompress Library

TestKompress uses the Mentor Graphics ATPG libraries used by FastScan, FlexTest, and
DFTAdvisor. No other special libraries are required. If you only have access to a Verilog
library, you can convert it to the ATPG library format with the aid of the Mentor Graphics
utility, LibComp. This utility automates much or all of the conversion effort. For more
information, refer to “Creating ATPG Models” in the Design-for-Test Common Resources
Manual.
User Interface Overview

TestKompress provides a command-line interface. When you invoke the tool, it opens in setup
mode with the following command line prompt:
SETUP>
Running Batch Mode Using Dofiles

You can run TestKompress 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.
To use a dofile, you must specify it at invocation by using the -Dofile switch.
If you place all commands, including the Exit command, in a dofile, you can run the entire
session as a batch process. Once you generate a dofile, you can run it at invocation. For
example, to run TestKompress as a batch process using the commands contained in the dofile
my_dofile.do, enter:
shell> <mgcdft tree>/bin/testkompress -dofile my_dofile.do
The following shows an example TestKompress dofile:
// my_dofile.do
//
// Dofile for EDT Logic Creation Phase.
// Execute setup script from DFTAdvisor.

dofile my_atpg.dofile
// Set up EDT.
set edt -channels 2
// Run DRC.
// Report and write EDT logic.

May 2007

report edt pins
// 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
Generating a Log File

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
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, or by issuing
the Set Logfile Handling command. When setting up a log file, you can instruct TestKompress
to generate a new log file, replace an existing log file, or append information to a log file that
already exists.
Note
If you create a log file during a tool session, the log file will only contain notes, warnings,
or 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.
Running UNIX Commands

You can run UNIX operating system commands within DFT applications by using the System
command. For example, the following command executes the UNIX operating system
command ls within a DFT application session:
prompt> system ls
Conserving Disk Space

To conserve disk storage space, DFTAdvisor™, FastScan, TestKompress, and FlexTest™ can
read and write disk files using either the UNIX compress or the GNU gzip command. When
you provide a filename with the appropriate filename extension (“.Z” for compress, or “.gz” for
gzip), the tools automatically process the file using the appropriate utility. Two commands
control this capability:
• Set File Compression - Turns file compression on or off. This command applies to all
files that the tool reads from and writes to.

May 2007
• Set Gzip Options - Specifies which GNU gzip options to use when the tool is processing
files that have the .gz extension.
Note
The file compression used by the tools to manage disk storage space is unrelated to the
pattern compression you apply to test pattern sets in order to reduce the pattern count.
You will see many references to the latter type of compression throughout the DFT
documentation.
Interrupting the Session

To interrupt the invocation of a DFT product and return to the operating system, press
Control-C. You can also use Control-C to interrupt the current operation and return control to
the tool.
Exiting the Session

To exit TestKompress and return to the operating system, type “exit” at the command line:
prompt> exit

May 2007

May 2007
Chapter 2
Understanding the TestKompress Tool Flow
Top-Down Design Flow with EDT

Figures 2-1 and 2-2 compare the basic steps and the Mentor Graphics tools you would use
during a typical ATPG top-down design flow with the steps and tools you use when EDT is
incorporated in the flow. A thorough description of the typical ATPG flow is contained in the
Scan and ATPG Process Guide, so is not repeated here. This manual discusses the steps shown
in grey; it also mentions certain aspects of other design steps, where applicable. This flow
primarily shows the typical top-down design process flow using a structured EDT strategy.
The first task in any design flow is creating the initial register transfer level (RTL) design,
through whatever means you choose. If your design is in VHDL or Verilog format and it
contains memory models, at this point you can add built-in self-test (BIST) circuitry.
MBISTArchitect™ creates and inserts RTL-customized internal testing structures for design
memories.
Commonly, in an ATPG flow that does not use EDT, you would next insert and verify I/O pads
and boundary scan circuitry using BSDArchitect™ (BSDA). 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
DFTAdvisor. In the normal ATPG flow, after you insert scan, you could optionally reverify the
timing because you added scan circuitry. Once you were sure the design is functioning as
desired, you would generate test patterns using FastScan™ or FlexTest™ (depending on your
scan methodology) and ASIC Vector Interfaces to generate a test pattern set in the appropriate
format.

May 2007
Figure 2-1. Top-Down Design Flow External
ATPG EDT
(External Flow)
Create Initial Design
& Verify Functionality
Insert/Verify Insert/Verify
MBISTArchitect BIST Circuitry BIST Circuitry MBISTArchitect
Insert/Verify Synthesize/Optimize
Design & Design Compiler
BSDArchitect Boundary Scan
Circuitry Verify Timing PrimeTime
Insert
Insert I/O Pads Internal Scan DFTAdvisor
Circuitry
Synthesize/Optimize Create & Insert EDT

Design Compiler Intellectual Property TestKompress
the Design
(IP Creation Phase)
PrimeTime Boundary Scan
Verify Timing Boundary Scan BSDArchitect
Circuitry Circuitry
Insert
DFTAdvisor Internal Scan Insert I/O Pads
Circuitry
Re-verify Timing Synthesize/Optimize Design Compiler

(opt.) Design Incrementally PrimeTime
FastScan Generate (Pattern

Generate/Verify TestKompress
FlexTest Generation Phase) &
Test Patterns ModelSim
ModelSim Verify EDT Patterns
Hand off
to Vendor

May 2007
Figure 2-2. Top-Down Design Flow Internal
ATPG EDT
(Internal Flow)
Create Initial Design
& Verify Functionality
MBISTArchitect BIST Circuitry BIST Circuitry MBISTArchitect
BSDArchitect Boundary Scan Boundary Scan BSDArchitect
Circuitry Circuitry
Insert I/O Pads Insert I/O Pads
Synthesize/Optimize
Synthesize/Optimize Design & Design Compiler
Design Compiler
the Design Verify Timing PrimeTime
Insert
PrimeTime Verify Timing Internal Scan DFTAdvisor
Circuitry
Insert Create EDT

DFTAdvisor Internal Scan Intellectual Property TestKompress
Circuitry (IP Creation Phase)
Insert IP/Synthesize
Re-verify Timing Design Compiler
the Design
(optional)
Incrementally
FastScan Generate (Pattern
Generate/Verify TestKompress
FlexTest Generation Phase) &
Test Patterns ModelSim
ModelSim Verify EDT Patterns
Hand off
to Vendor

May 2007
By comparison, an EDT flow can take one of two paths:
• External IP Location Flow (external flow)—Differs from the typical ATPG flow in that
you do not insert I/O pads and boundary scan until after you run TestKompress on the
scan-inserted core to insert the EDT IP. The EDT IP is located external to the design
netlist.
• Internal IP Location Flow (internal flow)—Similar to a typical ATPG flow, you may
insert and verify I/O pads and boundary scan circuitry before you synthesize and
optimize the design. The EDT IP is instantiated in the top level of the design netlist,
permitting the IP 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 IP
would be connected to the internal nodes of the pad cells used for channel and control
signals and you would run TestKompress on the scan-inserted core that includes I/O
pads and boundary scan.
You should choose an EDT flow based on whether the EDT IP 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 IP 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 IP.
Following that, you insert and verify boundary scan circuitry if needed. Only then do you add
I/O pads.1 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 the EDT IP, run Design Compiler to integrate the IP
into the design and synthesize it. TestKompress produces a Design Compiler script you can use
to insert the EDT IP into the design and connect it, as well as perform synthesis of the IP.
In either EDT flow, once you are sure the design is functioning as desired, you generate test
patterns using TestKompress. In this step, TestKompress performs extensive DRC that, among
other things, verifies the synthesized EDT IP.
Note
Notice that you run TestKompress twice: first to create the EDT IP (IP Creation Phase)
and again to generate EDT patterns (Pattern Generation Phase).
You should also verify that the design and patterns still function correctly with the proper
timing information applied. You can use ModelSim or another Verilog or VHDL 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.
1. You can use the Mentor Graphics BSDArchitect™ (BSDA) tool to insert boundary scan and I/O pads.

May 2007
Design Requirements
Note
It is important to check with your vendor early on in your design process for specific
requirements and restrictions that may affect your EDT strategy. In particular, 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.
Design Requirements
Before you begin an EDT flow, you must ensure your design satisfies the following
prerequisites:
Format
Your design input to TestKompress must be in gate level Verilog or VHDL. The IP created by
TestKompress is in Verilog or VHDL RTL.
Pin Access
As in FastScan, the design needs to allow access to all clock pins through primary input pins.
There is no restriction on the number of clocks.
I/O Pads
The next two sections describe the I/O pad requirements for each of the two EDT flows. These
prerequisites are quite different depending on which EDT flow, external or internal, you use.
External Flow
TestKompress creates the EDT IP as a collar around the circuit (see Figure 1-5). Therefore, the
core design ready for IP insertion must consist of only the core without I/O pads. In this flow,
TestKompress cannot insert the IP between scan chains and I/O pads already in the design.
Note
Add the I/O pads around the collar after it is created, but before logic synthesis. The same
applies to boundary scan cells: add them after the EDT IP has been included in the
design.
The design may or may not have I/O pads when you generate EDT patterns. For example, to
determine the expected test coverage, you can use TestKompress to perform a pattern
generation trial run on the core in the IP Creation Phase before inserting I/O pads.

May 2007
The EDT Flows
Note
You should not save patterns TestKompress generates in the IP Creation Phase, as these
patterns do not account for how the I/O pads are integrated into the final synthesized
design.
When producing the final patterns for a whole chip, run TestKompress on the design that you
synthesized after inserting the I/O pads.
For more information, refer to Chapter 3, “Managing Pre-existing I/O Pads.”
Internal Flow
The core design, ready for IP 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. Refer to “Sharing Functional Pins with EDT Control
and Channel Pins” in Chapter 4 for more information about pin sharing.
Note
The design may have I/O pads; it is not a requirement. When the IP is inserted into the
netlist, you can connect it to any internal design nodes you choose, or to the netlist’s top
level.
The EDT Flows

This section provides an overview of the steps you follow in each of the two EDT flows:
• External IP Location Flow (External Flow)

• Internal IP Location Flow (Internal Flow)
the same design. The tool creates DFF-based EDT IP by default. However, you can direct the
tool to create latch-based IP for pure LSSD designs. Table 2-1 summarizes the EDT IP/scan
architecture combinations the tool supports.
Table 2-1. Supported EDT IP/Scan Architecture Combinations

Scan Architecture
EDT IP LSSD Mux-DFF Mixed
Architecture
DFF-based Supported Supported Supported
Latch-based Supported Not supported Not supported

May 2007
The EDT Flows
External IP Location Flow (External Flow)

Figure 2-3 details 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. The chapters that
follow describe each of these steps in detail.
1. Prepare and synthesize the RTL design.

2. Insert an appropriately large number of scan chains using DFTAdvisor or a third-party
tool. For information on how to do this using DFTAdvisor, refer to Chapter 5, “Inserting
Internal Scan and Test Circuitry,” in the Scan and ATPG Process Guide.
3. Perform a FastScan 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. If you want, you can run TestKompress in FastScan command-line
mode to perform this step. See “Invoking TestKompress” on page 58 for information on
how to access the FastScan command-line mode.
4. Simulate the FastScan vectors (optional).
5. EDT IP Creation Phase: Invoke TestKompress on the scan-inserted gate level
description of the core without I/O pads or boundary scan. Create the RTL description of
the EDT IP.
6. Insert I/O pads and boundary scan (optional).
7. Incrementally synthesize the I/O pads, boundary scan, and EDT IP.
8. EDT Pattern Generation Phase: After you insert I/O pads and boundary scan, and
synthesize all the added circuitry (including the EDT IP), invoke TestKompress on the
synthesized top level netlist (Verilog or VHDL) and generate the EDT test patterns. You
can write test patterns in the same formats FastScan uses (for example, VHDL, Verilog,
and WGL).
9. Simulate the compressed test vectors 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.

May 2007
The EDT Flows
Figure 2-3. EDT External Flow with TestKompress
From
Synthesis
Synthesized
Netlist
(no scan)
Insert Scan
ATPG Netlist
Scripts with scan
Create EDT IP
EDT EDT
Scripts RTL
Insert I/O Pads

& JTAG
Synthesize
EDT IP & JTAG
Layout
Synthesized
Netlist with
EDT IP
Generate
EDT Patterns
Patterns
Sign-off
Simulation

May 2007
The EDT Flows
Internal IP Location Flow (Internal Flow)

Figure 2-4 details the steps shown in grey 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. The chapters that
follow describe each of these steps in detail.
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 will not be
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 DFTAdvisor 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 will become internal nodes and the pins removed when the EDT IP is inserted
into the design and connected to the scan chains. For information on how to insert scan
chains using DFTAdvisor, refer to Chapter 5, “Inserting Internal Scan and Test
Circuitry,” in the Scan and ATPG Process Guide.
Note
As the new scan I/Os at the top level are only temporary, take care not to insert pads on
them.
3. Perform a FastScan 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. If you want, you can run TestKompress in FastScan command-line
mode to perform this step. See “Invoking TestKompress” on page 58 for information on
how to access the FastScan command-line mode.
4. Simulate the FastScan vectors (optional).
5. EDT IP Creation Phase: Invoke TestKompress on the scan-inserted gate level
description of the core. Create the RTL description of the EDT IP. TestKompress creates
the EDT IP but does not incorporate it into the design; the Design Compiler script the
tool generates will perform IP insertion and connection, in addition to synthesis.
6. Run the Design Compiler script to instantiate the EDT IP in the top level of the design,
connect the EDT logic between the design core and I/O pad cells, and incrementally
synthesize the EDT logic.
Note
The EDT IP is always inserted at the top level within the original design.

May 2007
The EDT Flows
7. EDT Pattern Generation Phase: After you insert the EDT IP, invoke TestKompress on
the synthesized top level netlist (Verilog or VHDL) and generate the EDT test patterns.
You can write test patterns in the same formats FastScan uses (for example, VHDL,
Verilog, and WGL).
8. Simulate the compressed test vectors 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. EDT Internal Flow with TestKompress

Insert I/O Pads
& JTAG
Synthesized From
Netlist Synthesis
(no scan)
Insert Scan
ATPG Netlist
Scripts with scan
Create EDT IP
EDT EDT
Scripts RTL
Insert &
Synthesize EDT IP
Layout
Synthesized
Netlist with
EDT IP
Generate
EDT Patterns
Patterns
Sign-off
Simulation

May 2007
The EDT Flows

May 2007
The EDT Flows

May 2007
Chapter 3
Scan Chain Synthesis
For testers (ATEs) with scan options, the number of channels is usually fixed and the parameter
you will vary 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 EDT flow. DFTAdvisor is the Mentor Graphics tool you use to insert scan chain
circuitry in your design.1
Figure 3-1. Scan Chain Insertion and Synthesis Procedure
Synthesize
the Design
1. Preparing the Design

Insert Internal
Scan/Test Circuitry 2. Inserting Scan Chains
(DFTAdvisor)
3. Establishing a Compression Target
Create
EDT Logic
(TestKompress)
This chapter discusses each of the tasks outlined in Figure 3-1.
This chapter discusses each of the previously mentioned tasks as it relates to the EDT process
flow.
Preparing the Design

As a prerequisite to reading this section, you should understand the information in Chapter 5,
“Inserting Internal Scan and Test Circuitry” in the Scan and ATPG Process Guide. The
following subsections assume you are familiar with that information and only cover the EDT-
specific issues you need to be aware of before you insert test structures into your design.
1. You can use any scan insertion tool to insert scan chains; however, this chapter assumes you use
DFTAdvisor.

May 2007
Preparing the Design
External EDT Logic Location Flow (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 so you can perform the EDT Logic Creation Phase on a design
without 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 described in this section.
If the core and the I/O pads are in separate blocks, removing the I/O pads is simple to do:
1. Invoke DFTAdvisor using the -Top switch to extract the core and write it out.
2. Insert scan into the core and synthesize the EDT hardware around it.
3. Reinsert the EDT hardware-core combination into the original circuit in place of the
core you extracted, such that it is connected to the I/O pads.
Note
TestKompress also has a -Top invocation switch that enables you to run the tool on the
core. However, you must still use the -Top invocation switch in DFTAdvisor to extract
the core when you perform scan insertion on the core prior to invoking TestKompress.
If your design flow dictates that the I/O pads be inserted prior to scan insertion, you can create a
black box 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 TestKompress creates the RTL model of
the EDT block, you use the RTL model as the new architecture or definition of the black box
placeholder. The port names of the EDT block must match those of the black box 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 TestKompress in the EDT Logic Creation Phase. The EDT circuitry 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.

May 2007
Inserting Scan Chains
If the design already includes boundary scan, you need to extract the core or remove the
boundary scan, so you can perform the EDT Logic Creation Phase on a design without
boundary scan. This is the same requirement, described in the preceding section, that applies to
pre-existing I/O pads.
If the core and boundary scan are in separate blocks, you can invoke DFTAdvisor using the -
Top switch to extract the core and write it out. You then insert scan into the core and synthesize
the EDT hardware around it. Afterward, reinsert the EDT hardware-core combination into the
original circuit in place of the core you extracted, such that it is connected to the boundary scan
circuitry.
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 EDT Pattern Generation Phase.
For more complete information about including boundary scan, refer to Chapter 5, “Adding
Boundary Scan (External Flow).”
Synthesizing a Gate-level Version of the Design

As a prerequisite to starting the EDT flow, you need a synthesized gate level netlist of the core
design without scan. As explained earlier, the design must not have boundary scan or I/O pads.
You can synthesize the netlist using any synthesis tool and any technology.
Internal EDT Logic Location Flow (Internal Flow)

The EDT hardware 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 also must 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 (if you specify bypass
circuitry during setup); and 2n channel I/Os, where n is the number of external channels for the
netlist. Refer to “Specifying EDT Control and Channel Pins” in Chapter 4 for more detailed
information about EDT control and channel pins.

Insert an appropriately large number of scan chains. For testers with the scan option, the number
of channels is usually fixed and the variable will be the number of chains. Therefore, scan
configuration is an important part of the EDT flow. Refer to the next section, “Determining
How Many Scan Chains to Use,” for more information.
The following limitations exist for the insertion of scan chains:

May 2007
• Only full 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 summarizes the EDT
logic/scan architecture combinations the tool supports. For information about specific
scan cell types, refer to “Scan Architectures” in the Scan and ATPG Process Guide.
• Both prefixed and bused scan input and output pins are allowed; however, the buses for
bused pins must be in either ascending or descending order (not in random order).
• The scan chains must be connected to dedicated scan pins inserted at the top level of
your core design. The reason for this requirement is explained in the section “Avoiding
Sharing Scan Chain Pins with Functional Pins.”
• TestKompress does not support “dummy” scan chains as defined in FastScan. This is
because EDT is strongly dependent on the scan configuration, particularly the number of
scan chains. FastScan ATPG performance is independent of the scan configuration and
can assume that all scan cells are configured into a single scan chain when dummy scan
chains are used.
You can use any scan insertion tool capable of configuring the required number of scan chains
(for example, DFTAdvisor).
Note
Because TestKompress generates the RTL description of the EDT logic in Verilog or
VHDL, you must save the scan-inserted design in one of these two formats.
Including Uncompressed Scan Chains

Uncompressed scan chains, scan chains not driven by or observed through EDT logic, are
permitted in a design that uses EDT. You insert and synthesize them like any other scan chains,
but leave them undefined (by not issuing Add Scan Chains commands for them) when setting
up TestKompress in the EDT Logic Creation Phase. The tool will then ignore them when
creating the EDT logic.
Note
The presence of uncompressed chains may reduce the accuracy of the test coverage and
scan data volume estimates you can obtain as an optional step after you run the tool to
create the EDT logic (these estimates are explained in “Estimating Test Coverage and
Scan Data Volume” on page 92). Therefore, Mentor Graphics recommends you skip the
estimation step if you include uncompressed chains in your design.
For additional information, refer to the following sections:
• “Setting Up TestKompress” on page 60

• “EDT Pattern Generation Files” on page 88

May 2007
• “Preparing for Pattern Generation” on page 101

• “Modular TestKompress Requirements” on page 158
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 desired compression, 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 similar problems as for RAMs, where routing can be a
problem if several hundred scan chains start at the decompressor and end at the compactor.
There are other reasons to decrease the number of scan chains: two examples are to limit the
number of incompressible patterns and/or to reduce the pattern count. For more explanation,
refer to the Chapter 1 section, “Controlling EDT Compression.”
For testers with a scan option, the number of channels is usually fixed and the variable you
modify will be the number of chains. Because the effective compression will be 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 EDT. 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.5 to 6X compression.
Using One Scan Group

EDT supports the use of exactly one scan group.
Note
A scan group is a concept used by Mentor Graphics DFT and ATPG tools to group scan
chains based on operation. This concept is fully explained in the “Scan Groups” section
of the Scan and ATPG Process Guide.
Avoiding Sharing Scan Chain Pins with Functional Pins

When you perform scan insertion on the core design, you must not share any scan chain pins
with functional pins. You must connect the inserted scan chains to dedicated pins you create for
them at the top level. If you use the external flow, these pins will become internal nodes when
the tool creates the EDT wrapper. If you use the internal flow, the pins get 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. To ensure the scan chains have
dedicated output pins, use the -Output New option with the Insert Test Logic command in
DFTAdvisor.

May 2007
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
TestKompress for inserting the EDT logic. Refer to “Specifying EDT Control and
Channel Pins” in Chapter 4 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.
Reordering Scan Chains

The EDT circuitry (including bypass circuitry) depends on the clocking of the design. When
needed to prevent clock skew problems, TestKompress automatically includes lockup cells in
the EDT circuitry. If, after you create the EDT logic, you reorder the scan chains incorrectly, the
automatically inserted lockup cells will no longer behave correctly. The potential problem areas
are the following:
• 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 circuitry 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.
• If you use a lockup latch 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 latch at the end of each
chain enables you to reorder however you want. You can move clock domains and you

May 2007
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 latch 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.
Examining a DFTAdvisor Dofile Used for EDT

As previously mentioned, the scan chains for EDT must have dedicated pins. To ensure this is
the case for the outputs, you must use the -Output New option with the Insert Test Logic
command in DFTAdvisor. The following is an example dofile for inserting scan chains with
DFTAdvisor. Notice the use of “-output new” (shown in bold font) and the single scan group:
// dfta.do
//
// DFTAdvisor dofile to insert scan chains for EDT.
// Setup required scan type and methodology: mux-DFF, full scan.

set scan type mux_scan
setup scan identification full_scan
// Setup 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 lockup latch on
// Setup Test Control Pins.

setup scan insertion -sen scan_en
setup scan insertion -ten test_en
// Setup scan chain naming.

setup scan pins Input -prefix edt_si -initial 1 -modifier 1
setup scan pins Output -prefix edt_so -initial 1 -modifier 1
// Flatten design, run DRCs, and identify scan cells.

set system mode dft
report statistics
add clock groups grp1 clk1 clk2 clk3 clk4
run
// Insert scan chains and test logic.

insert test logic -edge merge -clock merge -number 16 -output new
// “-output new” is required to ensure separate scan chain outputs.
// Report information.

May 2007
Establishing a Compression Target
report scan chains

report test logic
// Write output files.

write netlist my_gate_scan.v - verilog -replace
write atpg setup my_atpg -replace
exit
You should obtain the following outputs from DFTAdvisor:
• 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

This is an optional step in the EDT flow that enables you to do the following:
• Estimate the final test coverage early in the flow, before you insert the EDT logic.
• Obtain the scan data volume for plain ATPG using the Report Scan Volume command,
before you generate and synthesize the EDT logic. Later, in TestKompress, you can
obtain the same statistic for EDT. You then can assess the benefits of EDT by
comparing the volume figures in the two cases.
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.

May 2007
Running FastScan ATPG (Optional)

Note
To perform traditional ATPG as described in this section, you can enter a “set edt off”
command after invoking TestKompress. This places the tool in FastScan command-line
mode, enabling you to run it like a standalone version of FastScan (except for the absence
of the GUI). Alternatively, you can simply use FastScan.1
This run is like any ATPG run and does not have any special settings; the key point to
remember is to use settings (pattern types, constraints, and so on) that are identical to those you
use when you run TestKompress to generate EDT compressed patterns.
The test procedure file you use for this FastScan run can, in theory, be identical to the one
generated by DFTAdvisor. But, you should modify it to include the same timing, as specified by
the tester, that you use when you generate EDT patterns. By using the same timing information,
you ensure simulation comparisons will be realistic. To avoid DRC violations when you save
patterns, you should also update the test procedure file with information for RAM clocks and
for non-scan-related procedures.
You can use the Report Scan Volume command in TestKompress and FastScan to perform a
more accurate comparison of the scan data volume in each case and more clearly assess the
benefits of EDT.
Save the patterns you generate only if you want to simulate them.
Note
This ATPG run is only intended to provide test coverage and pattern volume information
for plain ATPG. Save the patterns if you want to simulate them, but be aware that they
have no other purpose. You generate and save the sign-off EDT compressed patterns in
the EDT Pattern Generation Phase when you run TestKompress on the entire design—
after you have synthesized the I/O pads and EDT logic.
Simulating the FastScan Test Patterns (Optional)

Like the FastScan test pattern generation described in the preceding section, simulating the
generated patterns is an optional step in the EDT flow.
In the Mentor Graphics flow, you can use the ModelSim simulator. You can also use any other
Verilog simulator instead.
1. Both the FastScan command-line mode of TestKompress (EDT off) and the standalone FastScan product
are referred to as FastScan in this manual.

May 2007

May 2007
Chapter 4
This chapter describes how you use TestKompress to add EDT logic to your scan-inserted
design. This part of the TestKompress flow is referred to as the EDT IP Creation Phase.
Figure 4-1 shows the layout of this chapter as it applies to the process of creating and inserting
the EDT logic.
Figure 4-1. EDT Logic Creation Procedure
Insert Internal 1. Understanding TestKompress

Scan/Test Circuitry
(DFTAdvisor) 2. Preparing for EDT Logic Creation
Create 3. Running DRC

EDT Logic
(TestKompress) 4. Creating the RTL Description of the EDT Logic
Synthesize 5. Understanding Generated EDT Files

EDT Hardware 6. Estimating Test Coverage and Scan Data Volume
(Design Compiler)
This chapter discusses each of the tasks outlined in Figure 4-1, providing details on using
TestKompress. For more information on all available functionality in the tool, refer to the
ATPG and Failure Diagnosis Tools Reference Manual.
Understanding TestKompress
In the EDT flow, you use TestKompress to accomplish two very different tasks:
1. Create the EDT logic (EDT IP Creation Phase), and

2. Generate EDT patterns (EDT Pattern Generation Phase)
This chapter is concerned with the first task (EDT IP Creation Phase), in which you set up and
run TestKompress on the scan-inserted core to create RTL-level descriptions of the EDT logic
in either Verilog or VHDL.
RTL has the following advantages compared to a gate level description:

May 2007
Understanding TestKompress
• You do not need to provide technology mapping. For gate level code, you would need to
specify the library model to use for every gate type needed. RTL eliminates this
requirement because the technology mapping is performed during synthesis.
• RTL code may be better optimized by synthesis tools.
You invoke TestKompress in command-line mode. Before you use TestKompress, you should
become familiar with the basic process flow described in Chapter 2, and the tool’s invocation as
described in the following subsection.
You should also have a good understanding of the following chapters in the Scan and ATPG
Process Guide:
• Chapter 2, “Understanding Scan and ATPG Basics”

• Chapter 3, “Understanding Common Tool Terminology and Concepts”
Invoking TestKompress
Note
To use TestKompress for creating EDT logic or generating EDT patterns, your design
must be a gate level netlist in either Verilog or VHDL format, and the tool’s EDT
capability must be on (the default). The tool will invoke on a flattened model that was
generated by FastScan, but TestKompress will then emulate FastScan command-line
mode only.
Invoke TestKompress by entering the application name on the shell command line, along with
all required arguments (design_name, design type, and library).
<mgcdft tree>/bin/testkompress {{{design_name [-VERILOG | -VHDL| -FLAT]} |

{-MODEL {cell_name | ALL}}} [-INCDIR include_directory…]
[-TOP model_name] {-LIBrary library_name}
[-LOGfile logfile_name [-REPlace]] [-DOFile dofile_name] [-HIStory]
[-LICense retry_limit] [-SENsitive] [-32 | -64]} |
{-HELP | -USAGE | -MANUAL | -VERSION}
Once the design and library are loaded, the tool opens a command-line interface in Setup mode,
ready for you to begin working on your design.
For an explanation of each of the available invocation arguments and switches, refer to “Shell
Commands” in the ATPG and Failure Diagnosis Tools Reference Manual. You can obtain an
abbreviated description of the invocation options by entering the following command at the
shell prompt:
<mgcdft tree>/bin/testkompress -help
The following example invokes TestKompress on the Verilog design, “my_gate_scan.v” using
the library called “my_lib.atpg”:

May 2007
Preparing for EDT Logic Creation
<mgcdft tree>/bin/testkompress my_gate_scan.v -verilog \

-lib my_lib.atpg
You can use a dofile to simplify many of the tasks described in the following sections, as in this
example dofile, edt_ip_creation.do:
// edt_ip_creation.do
//
// Dofile for EDT Logic Creation Phase.
// Execute setup script from DFTAdvisor.

dofile my_atpg.dofile
// Set up EDT.
set edt -channels 2
set edt pins bypass my_bypass
// Run DRC.
// Report and write EDT logic.

report edt pins
// Exit.
exit
Issue the following command to invoke TestKompress with the dofile:
<mgcdft tree>/bin/testkompress my_gate_scan.v -verilog -lib my_lib.atpg \

-dofile edt_ip_creation.do
Note
You can invoke on a netlist in any format supported by FastScan if you operate the tool in
FastScan command-line mode. To enable this mode, enter “set edt off” at the Setup
prompt immediately after invocation. For details about the formats FastScan supports,
refer to the description of the design_name argument in the fastscan shell command
section of the ATPG and Failure Diagnosis Tools Reference Manual.

The following subsections discuss the steps you typically take to prepare for the insertion of the
EDT logic into your design. You can create the EDT logic immediately after you insert scan
chains, or you can run traditional ATPG and simulate the resulting vectors first, as described in
the Chapter 3 section, “Establishing a Compression Target.”
Creating the EDT logic is the first step in the EDT flow that involves TestKompress EDT
capabilities. When you invoke TestKompress on a gate level Verilog or VHDL netlist, EDT
capability is on by default and you are in Setup mode. EDT must be on whenever you are doing

May 2007
EDT logic creation or EDT pattern generation. You can use the Report Environment command
to check the tool’s EDT status. The following example shows this command’s output when
EDT is on:
SETUP> report environment

EDT = ON (compressed patterns)
All of the setup steps shown in the following subsections require the tool to be in Setup system
mode with EDT on.
Setting Up TestKompress
Note
When the tool creates the EDT logic, only scan chains defined with the Add Scan Chains
command get connected so as to be driven by and observed through the EDT logic.
Therefore, do not issue this command for any scan chains you want to leave
uncompressed. See “Including Uncompressed Scan Chains” on page 50 for more
information.
You need to set up TestKompress before you can create the EDT logic. You do this by
executing commands, while in Setup mode, that define the scan chains, much as you would do
for FastScan in preparation for a normal ATPG run. These commands are explained in
“Defining the Scan Data” in the Scan and ATPG Process Guide.
You can include these commands in a dofile or invoke the dofile that DFTAdvisor generated to
define clocks and scan chains. For example:
SETUP> dofile my_atpg.dofile
The following shows an example setup dofile generated by DFTAdvisor:
//
// Generated by DFTAdvisor
//
add scan groups grp1 my_atpg_setup.testproc
...
add write controls 0 ramclk
add read controls 0 ramclk
add clocks 0 clk

May 2007
Setting Parameters for the EDT Logic

To configure the EDT logic, you specify certain parameters using the Set EDT command. The
two most important parameters are the position of the EDT logic, internal or external, with
respect to the original netlist the tool read in, 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. The
following command, for example, specifies to construct an external EDT logic with two input
channels and two output channels:
SETUP> set edt -channels 2
Other parameters specify whether to create DFF-based or latch-based EDT logic and whether to
include bypass circuitry in the EDT logic, lockup cells in the decompressor, and/or pipeline
stages in the compactor. The tool defaults for these parameters are as follows:
• DFF-based EDT logic

• Lockup cells in the decompressor, compactor, and bypass circuitry
• No pipeline stages in the compactor
• Generate bypass logic
The command’s usage is as follows:
SET EDt [OFf |

{ON [-CHannels integer] [{-INPut_CHannels integer} {-OUtput_CHannels integer}]}
[-BYPASS_Chains integer] [-LOCAtion {External | Internal}]
[-BYpass_logic {ON | OFf}] [-CLocking {Edge | Level}]
[-PIpeline_logic_levels_in_compactor {OFf | integer}] [-LOCKup_cells {ON | OFf}]
[-LONgest_chain_range {min_number_cells max_number_cells}]
[-RESet_signal {OFf | Asynchronous}] [-IP_version integer]}]
The following topics describe the most commonly used parameter settings:
Specifying a Different Number of Input and Output Channels

Including Bypass Circuitry
Specifying Latch-based EDT logic
Including Pipeline Stages in the Compactor
Adding Lockup Cells
Specifying a Range for the Length of the Longest Scan Chain
Including a Reset for the EDT Logic
Specifying the Version of the EDT Architecture
Specifying a Different Number of Input and Output Channels

Occasionally, the number of input channels you want will differ from the number of output
channels. To specify different numbers, you use the pair of switches, -Input_Channels and
-Output_Channels, instead of the -Channels switch.

May 2007
Including Bypass Circuitry

The command by default generates bypass logic. If you include bypass logic, it is transparent
during normal EDT operation. You can, however, activate it to bypass the EDT circuitry so you
can run traditional ATPG. In bypass mode, the bypass circuitry concatenates the internal scan
chains into fewer, longer chains; the number of longer chains corresponding to the number of
scan channels. These longer scan chains are connected directly to the channel inputs and
outputs, bypassing the EDT hardware. This allows you to use the channel inputs and outputs as
traditional scan input and output pins with an ATPG tool such as FastScan. For more detailed
information, refer to “Bypassing EDT Logic” and Figure 7-1.
Specifying Latch-based EDT logic

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.
Including Pipeline Stages in the Compactor

The EDT logic can include pipeline stages between logic levels within the compactor. The
-PIpeline_logic_levels_in compactor switch gives you control of this feature by enabling you to
specify a maximum number of logic levels (XOR gates) the tool should allow in the spatial
compactors without inserting a pipeline stage. The default is to not insert any pipeline stages.
The Chapter 7 section, “Using Pipeline Stages in the EDT Compactor,” contains detailed
information on the use of pipeline stages in the compactor.
Adding Lockup Cells

Often, lockup cells are needed between the decompressor and the core, between the core and the
compactors (if you specify insertion of pipeline stages), and between scan chains when they are
concatenated for bypass mode. By default, the tool inserts edge-triggered flip-flops when
lockup cells are needed, but you can use the -Lockup_cells switch to specify not to insert them.
Mentor Graphics highly recommends that you not disable lockup cell synthesis. Doing so can
lead to DRC violations in the pattern generation phase and inability to generate valid patterns.
The tool inserts lockup cells not only to prevent clock skew, but also to control cycle boundaries
between the EDT logic and the scan chains. This ensures no coverage loss occurs in bypass
mode because of dependencies created by concatenating scan chains. It also enables the tool to
map EDT patterns into bypass mode (Save Patterns -Binary -EDT_bypass).
For a discussion of lockup cells, refer to the section, “Merging Chains with Different Shift
Clocks” in the Scan and ATPG Process Guide. For more detailed information on the tool’s use
of lockup cells and pipeline stages in EDT, see the Chapter 7 sections, “Using Pipeline Stages in
the EDT Compactor,” and “Understanding How Lockup Cells are Inserted.”

May 2007
Specifying a Range for the Length of the Longest Scan Chain

Sometimes, you may want to change the length of the scan chains in your design after using
TestKompress to generate 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 will not have to regenerate the EDT logic because of a shortening or lengthening of
the longest chain.
Note
This applies to scan chain length only. For example, you could reorder the scan chains in
a way that necessitates EDT logic regeneration even though the length of the longest
chain remained within the range specified with the -Longest_chain_range switch. Refer
to “Reordering Scan Chains” in Chapter 3 for more information.
Including a Reset for the EDT Logic

The EDT logic may optionally include an asynchronous reset signal that resets all the sequential
elements in the logic. Use “-reset_signal asynchronous” with the Set EDT command if you want
the EDT logic to include this signal. If you choose to include the reset, the hardware will also
include a dedicated control pin for it (named “edt_reset” by default).
Specifying the Version of the EDT Architecture

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
switch. This enables you to specify the version of the EDT architecture TestKompress should
expect in the design. In the EDT Logic Creation Phase, TestKompress writes a dofile containing
EDT-specific commands for use in the Pattern Generation Phase. Any Set EDT commands
included in this dofile will also use this switch to specify the EDT architecture version;
therefore, you usually do not need to explicitly specify this switch.
Note
The IP version applies to just the hardware architecture and is only incremented when
that changes. A newer version of TestKompress, in which only the kernel has been
updated but the logic generated is functionally the same, will have the same IP version
number as before. Only the software version will change.
Using the latest edition of the tool, you can thus still generate patterns for the older EDT logic
architectures. By default, the tool assumes the EDT logic version is identical to the currently
supported version.

May 2007
Reporting the EDT Configuration

You can report the current EDT configuration with the Report EDT Configuration command.
This command lists configuration details including the number of scan channels and IP version:
SETUP> report edt configuration

// 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 Configuration command needs a flat model and DRC results to
produce the most useful information, you usually use this command in other than Setup
mode. For an example of the command’s output when issued after DRC, see “DRC when
EDT Pins are Shared with Functional Pins” later in this chapter.
Specifying EDT Control and Channel Pins

The EDT hardware 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 (optional—included when you specify bypass circuitry)
• Reset control (optional—included when you specify an asynchronous reset for the EDT
logic)
Figure 4-2 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.

May 2007
Figure 4-2. Example of a Basic EDT Pin Configuration (External EDT Logic)
Design Design
Primary Wrapper Primary
Inputs Core Outputs
portain[7] portain[7] q1 q1
portain[5] portain[5]
a1 a1
scan_enable scan_enable
EDT Logic
edt_bypass bypass
edt_clock clock
edt_update update
edt_channels_in1 ch. 1 ch. 1 edt_channels_out1

input output
ch. 2 ch. 2 edt_channels_out2
edt_channels_in2 input output
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 the “Defining Shared Pins”
section, TestKompress assigns the default EDT pin name shown.
To see the names of the EDT pins, issue the Report EDT Pins command:
SETUP> 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 -

May 2007
Figure 4-3 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.1 You enable the tool to make these connections by specifying the internal node to which
you want each EDT control and channel I/O to connect. This is described later, in the section,
“Specifying Internal Node Connections for EDT Pins (Internal Flow only).”
Figure 4-3. Example of a Basic EDT Pin Configuration (Internal EDT Logic)
Design Design
Primary Design Core with I/O pads Primary
Inputs Module A Outputs
a1 a1
internal node
(I/O pad output)
EDT Logic
edt_bypass bypass internal node
(I/O pad input)
edt_clock clock
edt_update update
edt_channels_in1 ch. 1 ch. 1 edt_channels_out1

input output
ch. 2 ch. 2 edt_channels_out2
edt_channels_in2 input output
Sharing Functional Pins with EDT Control and Channel Pins

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, if necessary, to inform the
tool that a pin’s signal will be inverted in the I/O pad for that pin. This command’s usage line is
as follows:
1. With the internal flow, you would typically direct the tool to connect the EDT control and channel I/O pins
to internal nodes as described in the text. However, if needed, you can have the tool connect the control and
channel I/Os to top level pins.

May 2007
SET EDt Pins {{{Input_channel | Output_channel} index} | Clock | Reset | Update |

Scan_enable | Bypass} [pin_name] [internal_node_name] [-Noinv | -Inv]
When you specify to share a channel output pin with a functional pin, TestKompress inserts a
multiplexer before the output pin. This multiplexer is controlled by the scan-enable signal.
Therefore, you must use the Set EDT Pins command to make the scan-enable signal known to
the tool. 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 command, Report Drc Rules K13.
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 in the EDT IP Creation Phase. This is true whether you add I/O pads to the design
after the EDT IP Creation Phase (external flow) or before (internal flow). TestKompress
requires the pin inversion information so it can generate an EDT test procedure that operates
correctly with the full netlist read into the tool in the Pattern Generation Phase.
If bypass circuitry is implemented, you need to force the bypass control signal to enable or
disable bypass mode. When you use TestKompress to generate EDT patterns, you disable
bypass mode by setting the control signal to the off state. When you generate regular ATPG
patterns, using FastScan 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 that are 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 EDT 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 allowed.
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 does not
accept a bit of a bus being a clock. The EDT clock pin must only be shared with a non-clock pin

May 2007
that does not disturb scan cells; otherwise, the scan cells will be disturbed during the
load_unload procedure when the EDT clock is pulsed. This restriction might cause some
reduced coverage. Mentor Graphics recommends you 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, Design Compiler 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. Mentor
Graphics recommends you 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.
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 Chapter 7, “Bypassing EDT Logic.”
Note
RTL generation allows sharing of control pins. The preceding restrictions ensure the EDT
circuitry operates correctly and with only negligible loss, if any, of test coverage.
Creating EDT Logic When Sharing Functional Pins with EDT Pins
The synthesis methodology does not change when you specify pin sharing. You do, however,
need to add a step to the EDT IP Creation Phase. In this extra step, you define how you want
pins to be shared. Suppose, for example, that you are utilizing the tool’s external flow; you have
two scan channels in your design 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]

May 2007
Table 4-1. Example Pin Sharing

EDT Pin Description Functional Pin Name
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:

// --------------- -------- ---------
// Bypass mode edt_bypass -
Defining Shared Pins

You 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 also can
use the command to change the name of the new pin the tool creates for each dedicated EDT
pin. Figure 4-4 illustrates both of these cases conceptually.
Note
In the external flow, the pin sharing you specify is implemented in a wrapper the tool
creates when you generate the EDT logic. The “Top-level Wrapper” section contains
additional information about this wrapper. In the internal flow, the pin sharing is
implemented when you insert and synthesize the EDT logic.
When the pin you specify in the command already exists in the core, TestKompress will share
the EDT signal with that pin. The figure shows an example of this for the EDT clock signal. The
command, “set edt pins clock a1”, will cause TestKompress 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, the tool will create a dedicated EDT pin with the specified name. For
example, “set edt pins bypass my_bypass” will cause 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, TestKompress creates a dedicated pin with the default name. If the default

May 2007
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
Reset edt_reset
Update edt_update
Scan Enable scan_en
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
When you share a pin between an EDT channel output and a core output, TestKompress
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-4 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:
SETUP> set edt pins input 1 portain[7]

SETUP> set edt pins input 2 portain[6]
SETUP> set edt pins output 2 q2
SETUP> set edt pins update portain[5]
SETUP> set edt pins clock a1
SETUP> set edt pins bypass my_bypass
If you report the EDT pins using the “report edt pins” command after issuing the preceding
commands, you will see that the shared EDT pins have the same name as the functional core
pins. You will also see, for each pin, whether the pin’s signal was specified as inverted. Notice
that the listing now includes the scan enable pin because of the shared EDT output pin:

// --------------- -------- ---------
// Clock a1 -
// Update portain[5] -
// Scan enable scan_enable -
// Bypass mode my_bypass -
// Scan channel 1 input portain[7] -

May 2007
// Scan channel 2 input portain[6] -

// " " " output q2 -
Figure 4-4. Example with Pin Sharing Shown in Table 4-1(External EDT Logic)
Design Wrapper Design

Primary Primary
Inputs Core Outputs
portain[6] portain[6] q2
q2
a1 a1
EDT Logic
my_bypass bypass
clock
update
ch. 1 ch. 1
input output edt_channels_out1
ch. 2 ch. 2
input output
After DRC, you can use “report drc rules k13” to see a report of the pins the tool will add to the
top level of the design to implement the EDT hardware.
ATPG> 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)
Specifying Internal Node Connections for EDT Pins (Internal Flow only)
When you use the internal flow, you must provide TestKompress with the name of each internal
node (instance pin name) to which the tool should connect each EDT control or channel pin.
You use the Set EDT Pins command to specify the internal node names.

May 2007
Note
Before specifying internal nodes, you must set up the tool for the internal flow by issuing
the “set edt -location internal” command.
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:
SETUP> 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 tool will connect the EDT
logic directly to the top level pin, ignoring the pad. This may result in undesirable behavior.
If you do not specify either pin name, and TestKompress 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 will need
to add a pad later that corresponds to that port.
For the internal flow, the Report EDT Pins command displays an additional column that lists the
names of the nodes to which the EDT pins are connected. For example (note that the pin
inversion column is omitted for clarity):

//
// 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
//
Customizing the Structure of the Bypass Chains

If you chose to include bypass circuitry when you used the Set EDT command to specify certain
parameters for the EDT logic (see “Including Bypass Circuitry” earlier in this chapter),
TestKompress automatically determined the chain connections to create each bypass chain.
These interconnections are fine for most designs. However, you can specify custom chain
connections (to meet unique routing requirements, for example) using the Set Bypass Chains
command. This command’s usage is as follows:

May 2007
Running DRC
SET BYpass Chains {-Bypass_chain_number chain_number}

{-Edt_chains {chain_name…}}
For more information about the bypass circuitry and its operation, refer to “Bypassing EDT
Logic” in Chapter 7.
Related Commands:
Report Bypass Chains - displays user-specified bypass chain connections.

Reset Bypass Chains - removes user-specified bypass chain connections.
Customizing the Compactor Connections

After you use the Set EDT command to specify the number of scan channels in the EDT logic
(see “Setting Parameters for the EDT Logic”), TestKompress automatically determines which
scan chain outputs to compact into each channel output. The tool’s determination is fine for
most designs; however, you can use the Set Compactor Connections command to override the
tool and specify your own choice of chain outputs to compact into each scan channel output.
This command’s usage is as follows:
SET COmpactor COnnections {-CHANnel channel_number}

{-CHAIns {chain_name…}}
Related Commands:
Report Compactor Connections - displays user-specified compactor connections.

Reset Compactor Connections - removes user-specified compactor connections.
Running DRC
DRC is performed automatically when you leave setup mode:
SETUP> set sytem mode atpg
TestKompress shares DRC rules with the other Mentor Graphics DFT tools (DFTAdvisor,
FastScan and FlexTest). In addition, a class of EDT-specific “K” rules are checked. The section,
“EDT Rules (K Rules)” in the Design-for-Test Common Resources Manual provides 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-2, in which none of the
EDT pins are shared with functional pins:

May 2007
Running DRC
// ------------------------------------------------------
// Begin EDT rules checking.
// ------------------------------------------------------
// Running EDT IP 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 TestKompress will add seven pins, which include scan channel pins, to
the top level of the design. The last two messages refer to pins at either end 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, TestKompress 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 TestKompress 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. This
switch does, on internal scan nodes, the same thing that the Add Primary Inputs and Add
Primary Outputs commands do on non-EDT designs.
DRC when EDT Pins are Shared with Functional Pins

If you specified to share any EDT pin with a functional pin, DRC will include messages for K
rules affected by the sharing. Here is DRC output for the design shown in Figure 4-2, after it is
re-configured to share certain EDT pins with functional pins, as illustrated in Figure 4-4:
// ----------------------------------------------------------
// Begin EDT rules checking.
// ----------------------------------------------------------
// Running EDT IP 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

May 2007
Creating the RTL Description of the EDT Logic
warning about the shared EDT clock pin points this out to you. For details, refer to “Sharing
Functional Pins with EDT Control and Channel Pins” on page 66.
If you report the current configuration with the Report EDT Configuration command after
DRC, you will get more useful information. For example:
ATPG> report edt configuration

// 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.
Creating the RTL Description of the EDT Logic

You generate the EDT logic by issuing the Write EDT Files command. This command writes
files that describe the EDT logic in either Verilog or VHDL RTL (whichever you specify, with
the default based on the input netlist format), one or more dofiles and test procedure files for use
later in the flow, and a synthesis script. For example, if you specify the filename_prefix
argument as “created” and also specify the -Verilog switch:
ATPG> write edt files created -verilog -replace
TestKompress generates the following files:1
• created_edt_top.v Top level wrapper; instantiates the core, EDT logic

(external flow only) circuitry, and channel output sharing multiplexers
• created_edt.v EDT circuitry
• created_core_blackbox.v Blackbox description of the core; used for synthesis
(external flow only)
• created_dc_script.scr Design Compiler synthesis script for the EDT logic
1. The “created” prefix is used for now on when referring to these files in examples.

May 2007
Understanding Generated EDT Files
• _reduced_netlist.v Reduced netlist containing only the modules required

(internal flow only) for making necessary connections between pad terminals
and EDT logic pins. Use for synthesis only.
• _rest_of_netlist.v Portion of the netlist not contained in the
(internal flow only) _reduced_netlist.v.
• created_edt.dofile Dofile for the EDT Pattern Generation Phase
• created_edt.testproc Test Procedure File for the EDT Pattern
Generation Phase
• created_bypass.dofile Dofile for FastScan (bypass mode)
• created_bypass.testproc Test Procedure File for FastScan (bypass mode)

The structure of the EDT hardware described in these files depends on 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 hardware depends on the functionality of the core logic.
Note
Generally, you must regenerate the EDT logic if you reorder the scan chains. This is
because the reordering typically alters the clocking of the first and last scan cells in every
scan chain on which the lockup cells depend. You can reorder the scan chains or make
other changes to the core, without regenerating the EDT logic, if the changes satisfy two
conditions:
1) They do not affect the clocking of the first and last scan cell in every scan chain, and
2) They do not alter the length of the longest scan chain. You can handle this second
condition with the -Longest_chain_range switch. See “Specifying a Range for the Length
of the Longest Scan Chain” on page 63 for details.
Refer to “Reordering Scan Chains” in Chapter 3 for more information.
The following sections list additional details about each of the generated files.

May 2007
Top-level Wrapper
Figure 4-5 illustrates the contents of the new top level netlist file, created_edt_top.v.
TestKompress generates this file only if you are using the external flow.
Figure 4-5. Contents of the Top Level Wrapper
edt_top
edt
edt_clock
edt_update
edt_bypass
} Scan channel ins Scan channel outs

}
Scan chain ins Scan chain outs
Scan chain in
core Scan chain out
} Functional
Input
Pins
Functional
Output
Pins
}
edt_pinshare_logic
(optional)
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 “Avoiding Sharing Scan Chain
Pins with Functional Pins,” in Chapter 3. Scan channel pin sharing (or renaming) that you
specified using the Set EDT Pins command is implemented in the top-level wrapper. This is

May 2007
discussed in detail in “Sharing Functional Pins with EDT Control and Channel Pins,” earlier in
the chapter.
EDT Circuitry
Figure 4-6 shows a conceptual view of the contents of the file, created_edt.v.
Figure 4-6. Contents of the “edt” Module
edt
edt_decompressor
From
Input
Pins
} }Scan channel
Inputs
edt_clock
edt_update Scan chain inputs
edt_bypass_logic
edt_bypass
Scan
Chain
Inputs
} } To core
From
Core
} } Scan chain
Outputs
Scan
Channel
Outputs
} }
To
Output
Pins
edt_compactor
Scan chain Scan
Outputs Channel
Outputs
edt_clock
edt_update
This file contains the top level “edt” module, which instantiates the two main blocks
(decompressor and compactor, shown conceptually in Figure 1-2). When you specify to include
bypass circuitry, the “edt” module will contain an additional module for the bypass circuitry.
The following two blocks are always present:
• The decompressor, which is connected between the scan channel input pins and the
internal scan chain inputs

May 2007
• The compactor, which is connected between the internal scan chain outputs and the scan
channel output pins
Core
Generated only when you use the tool’s external flow, 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

TestKompress generates a sample Design Compiler 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
Design Compiler command language (dcsh) by including a “-synthesis_script dc_shell”
argument with the Write EDT Files command.
External Flow
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

May 2007
# 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
Internal Flow
TestKompress generates a sample Design Compiler synthesis script, created_dc_script.scr. For
the internal flow, this script is more complex than that generated for external flow because it
includes additional commands that help instantiate the EDT logic within the design core.
Typically, you will need to modify this script. Here is an example script in TCL format,
followed by a detailed description of the tasks it performs:
#************************************************************************
# Synopsys Design Compiler script for EDT logic insertion
#
#************************************************************************
# Initialize DC variables
set bus_naming_style {%s[%d]}
# Read input design files

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 IP 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]

May 2007
# Connect core scan inputs to EDT IP 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 IP 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.

May 2007
# 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]

May 2007
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 IP 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 IP
current_design retimetest_edt

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
# Avoid assign statements in the synthesized netlist.

# Compile design
uniquify
# Report design results for EDT IP

report_area > results/created_dc_script_report.out
report_constraint -all_violators -verbose >>
results/created_dc_script_report.out
report_timing -path full -delay max >>
report_reference >> results/created_dc_script_report.out
# Synthesize EDT multiplexor

current_design retimetest_edt_mux_2_to_1

check_design
# Compile design

May 2007
# Report design results for EDT mux

report_area >> results/created_dc_script_report.out
report_timing -path full -delay max >>
# Write output netlist

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 IP 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 module and 2x1 multiplexer module—The EDT module 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—As mentioned earlier, 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 module.
6. Remove scan chain input ports—Remove the dangling scan chain input ports that are
not connected to any logic after preceding 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 will be created and the EDT control pin will be
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

May 2007
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 black box 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 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.
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

May 2007
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, Design Compiler writes
out a gate level netlist that contains the original core, the EDT logic, and any
multiplexers TestKompress added to facilitate sharing of output pins.
Using a Reduced Netlist to Improve Synthesis Run Time

In the internal flow, the EDT logic is instantiated within an existing pad-inserted netlist and
connections are made from the pad terminals to the EDT logic pins. Typically, the connectivity
is accomplished by running Design Compiler, for which TestKompress writes out a synthesis
script. By default, this script reads in the entire input netlist and performs the necessary
connections.
Input netlists can be huge, however, 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 get TestKompress to
write out a reduced-size netlist especially for the synthesis run by including the
-Reduced_netlist switch with the Write EDT Files 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 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 “synthesis only” file but includes everything else. You
then use the output netlist from the synthesis run along with the second netlist as inputs for the
Pattern Generation Phase.
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.

May 2007
Figure 4-7. Design Netlist with Internal Connection Nodes

TOP
u1/A u4/C
p31
c1/C1
a1/ASUB u2
u1/ASUB1 a_b/A_B
c2/C1
u3
u2/ASUB2
u6/ACONT
c3/C3
u71/A
p3 p31
a1/ASUB
a_b/A_B
u1/ASUB1
u5/clkctrl
u7/D
u2/ASUB2
p3
When writing out the EDT files with the -Reduced_netlist switch, the tool would distribute the
modules between the two netlists as follows:
• Reduced netlist for synthesis — TOP, A, ASUB, clkctrl

• Rest of input netlist — 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.
When writing out the architecture of a top-level entity in VHDL, all the lower-level cells
instantiated within are specified as components. A configuration specification that binds the
components to a particular entity/architecture pair is also written out. However, if you split the
netlist, not all sub-entities may have been defined in the reduced netlist file; so referencing them
may be an error. As an example, consider the following input netlist:
entity sub is
port (i : in std_logic; o : out std_logic);
end;
architecture gates of sub is
...
end;

May 2007
entity top is
port (i1, i2 : in std_logic; o1, o2 : in std_logic);
end;
architecture gates of top is
component sub
port (i : in std_logic; o : out std_logic);
end component;
for ALL : sub
use entity WORK.sub(gates);
...
end;
If the entity top is included, but entity sub is excluded from the reduced synthesis netlist, then
the configuration specification (highlighted in bold) would be erroneous. For this reason, the
tool does not write out configuration specifications for any of the components when splitting a
VHDL netlist.
EDT Pattern Generation Files

TestKompress automatically writes a dofile and an test procedure file containing EDT-specific
commands and test procedure steps. As with the similar files produced by DFTAdvisor after
scan insertion, these files will perform basic setups; however, you will need to add commands
for any pattern generation or pattern saving steps.
Dofile
The dofile includes setup commands and/or switches required for the Pattern Generation Phase.
An example dofile created_edt.dofile is shown below. The EDT-specific parts of this file are in
bold font.
//
// Written by TestKompress
//
// Define the instance names of the decompressor, compactor, and the
// container module which instantiates the decompressor and compactor.
// Locating those instances in the design allows DRC to provide more debug
// information in the event of a violation.
// If multiple instances exist with the same name, subtitute 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

May 2007

add clocks 0 clk

add clocks 0 edt_clock
add pin constraints edt_clock C0
// 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 -channels 3 -ip_version 3 -decompressor_size 12

-injectors_per_channel 2
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 for EDT pattern generation. The reason for this requirement is explained in
“Running DRC,” earlier in the chapter.
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 will not work anymore. 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 without the -Internal switch when setting up for EDT pattern
generation. You will need to add these commands to the dofile manually.
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. For information
about how you can use this dofile in the EDT Pattern Generation Phase, refer to the Chapter 6
section, “Preparing for Pattern Generation.”
Test Procedure File

TestKompress also writes a test procedure file that has test procedures steps needed for the
Pattern Generation Phase. The tool creates this file by starting with the original test procedure

May 2007
file that you used in the IP Creation Phase, and making additions that will drive the EDT logic.
The following is an example of a test procedure file, created_edt.testproc, written by
TestKompress. The EDT-specific parts of this file are shown in bold font. For complete details
about the EDT-specific functionality included in this file, refer to the Chapter 6 section,
“Preparing for Pattern Generation.”
//
//
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;

May 2007
procedure test_setup =
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
end;
end;
Bypass Mode Files

Unless you specified “-bypass_logic off” with the Set EDT command, the EDT logic will
include bypass circuitry. When you include bypass circuitry, the Write EDT Files command
writes a dofile and an test procedure file you can use with FastScan to activate bypass mode and
run regular ATPG. These files are in addition to the dofile and test procedure file described in
the preceding section.
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.
//
//
timeplate gen_tp1 =
force_pi 0 ;
measure_po 100 ;
pulse clk 200 100;

May 2007
Estimating Test Coverage and Scan Data Volume

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;

Note
If your design contains uncompressed scan chains, they may adversely affect the
accuracy of the test coverage and scan data volume estimates described in this section.
Mentor Graphics recommends you skip this estimation step if there are uncompressed
scan chains in your design. For more information, refer to “Including Uncompressed
Scan Chains” on page 50.
After you run TestKompress to create the EDT logic, you can optionally generate test patterns
to estimate the test coverage and scan data volume. You do not need to generate patterns at this
point in the flow; however, the estimates you obtain for a given configuration can be useful (for
comparison with the test results you obtained without EDT in your design).
You should not save patterns you generate at this stage in the EDT flow. The tool emulates the
combined core and EDT logic when it generates them, but the patterns are not the same as those
the tool will generate after you synthesize the core and EDT logic into a unified gate level

May 2007
netlist. Therefore, use these patterns for pattern count and coverage estimation purposes only.
You generate the patterns for simulation and manufacturing test later, during the Pattern
Generation Phase. For this optional pattern generation, use commands similar to those you
would use in FastScan. For example:
ATPG> create patterns

ATPG> report statistics
ATPG> report scan volume
You can repeat this optional pattern generation for different configurations to experiment with
coverage and data volume. For situations where the number of channels is fixed, you can repeat
scan insertion multiple times to set up the design with different numbers of scan chains. When
you rerun TestKompress to regenerate the EDT logic with the same number of scan channels,
the compression will be different for each scan chain configuration.
Note
If you obtain compression lower than you expect, refer to “If EDT Compression is Less
Than Expected” on page 238 for troubleshooting suggestions. If test coverage is less than
you can obtain without EDT, refer to “If Test Coverage is Less Than Expected” on
page 239.

May 2007

May 2007
Chapter 5
This chapter describes issues related to the synthesis of the EDT logic. Figure 5-1 shows the
layout of this chapter as it applies to the synthesis process.
Figure 5-1. Preparing For and Synthesizing the EDT Logic
Create
EDT Logic
(TestKompress)
1. Overview
Synthesize
EDT Hardware 2. Preparing for Synthesis
(Design Compiler)
3. Synthesizing a Netlist with the EDT
Generate/Verify
EDT Patterns
(TestKompress)
Overview
After you create the EDT logic, the next step is to synthesize it. If you are using the internal
flow, insertion of the IP between the I/O pads and the core occurs as a part of synthesis.
TestKompress creates a basic Design Compiler synthesis script, in either dcsh or TCL format,
that you can use as a starting point. Running the synthesis script is a separate step where you
exit TestKompress and use Design Compiler to synthesize the EDT logic. Of course, you can
use any synthesis tool; the generated Design Compiler script is simply meant to aid you in
developing a script tailored to your needs and the synthesis tool you use.
Note
If you use the external flow, be sure to insert boundary scan and I/O pads after you create
the EDT logic, but before you synthesize it. These topics are covered in the following
section, “Preparing for Synthesis.”
You may be able to run the script without modification to synthesize (and insert if you are using
the internal flow) the EDT logic, provided the following are true:

May 2007
Preparing for Synthesis
• Design Compiler is the synthesis tool.

• The default clock definitions are acceptable.
• Technology library files are set up correctly in the .synopsys_dc.setup file in the
directory from which Design Compiler is invoked.
Note
The syntax of the .synopsys_dc.setup file and the Design Compiler synthesis script differ
depending on which format, dcsh or TCL, they support.
Note
If the .synopsys_dc.setup file does not exist, you must add the library file references to the
synthesis script.

The previous chapter describes how to create an RTL description of the EDT logic. The next
step is to incrementally synthesize it into the gate level netlist. The following two sections
describe, for each flow, how to prepare for synthesis.
External IP Location Flow (External Flow)

Once the IP is created, but before you synthesize it, Mentor Graphics recommends you 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 circuitry.
Note
You can add boundary scan and I/O pads simultaneously using BSDArchitect.
Adding Boundary Scan (External Flow)

Note
As a prerequisite to using boundary scan with EDT, you should understand boundary
scan concepts. For general process, concept, and procedure information on boundary scan
and on the Mentor Graphics boundary scan product, BSDArchitect, refer to the Boundary
Scan Process Guide.
Boundary scan cells must not be present in your design before you add the EDT logic. To
include boundary scan in your design, you perform an additional step after the EDT Logic
Creation Phase. In this step, you can use any tool you want to insert boundary scan. As shown in

May 2007
Figure 5-2, the circuitry should include the boundary scan register, TAP controller, and
(optionally) I/O pads.
Figure 5-2. Contents of Boundary Scan Top Level Wrapper
edt_top_bscan
edt_top
tap
edt
bsr_instance_1
core
pad_instance_1
(optional)
The Mentor Graphics boundary scan tool, BSDArchitect, creates a Verilog RTL description
containing a wrapper that instantiates the EDT wrapper, which includes the EDT logic and the
core design and the boundary scan circuitry. This causes one additional level of hierarchy to be
inserted outside the EDT wrapper. For a detailed description of the EDT boundary scan flow,
refer to the Chapter 7 section, “EDT and Boundary Scan (External Flow).”
Adding I/O Pads (External Flow)

You can use any method to insert I/O pads after scan insertion and EDT logic creation. The
Chapter 3 section, “Managing Pre-existing I/O Pads,” describes two exceptions where, with
some minimal extra steps, you can successfully generate the EDT logic for a design with pre-
existing I/O pads. The following two subsections describe how to reinsert the pads after you
have run the tool to create the EDT logic.

May 2007
Synthesizing a Netlist with the EDT Logic
If the Core and Pads were in Separate Blocks

If the core and pads were in separate blocks and you separated them as described in Chapter 3,
you should now reinsert the EDT hardware-core combination into the original circuit in place of
the core you extracted. When you reinsert it, ensure the EDT hardware-core combination is
connected to the I/O pads. Add pads for any new EDT pins that are not shared with existing core
pins and for which no pads were present as placeholders.
If a Flow Required Pad Insertion Before Scan Insertion

If your design flow dictates that I/O pads be inserted prior to scan insertion and you used the
architecture swapping solution described in the Chapter 3 section, “Managing Pre-existing I/O
Pads,” then I/O pads are already included in your scan-inserted design, and you can proceed to
insert boundary scan.
Internal IP Location Flow (Internal Flow)

The synthesis script for the internal flow contains synthesis commands similar to those in the
script generated for the external flow. But unlike the external flow script, it also contains
commands to help insert the EDT logic between pre-existing I/O pad cells and the scan chains
in the core. So, you do not have to perform the manual steps described in the preceding section
to manage pre-existing I/O pads.

Note
Mentor Graphics strongly recommends that during synthesis you preserve the pin names
TestKompress created in the EDT logic hierarchy when it wrote out the RTL in the IP
Creation Phase. Preserving the pin names will ensure the tool can resolve the pins in the
Pattern Generation Phase and optimize the tool’s ability to provide useful debug
information during DRC.
Next, you synthesize a gate-level netlist of the EDT logic. If you use Design Compiler to
synthesize the netlist, examine the .synopsys_dc.setup file and verify that it points to the correct
libraries. Also, examine the Design Compiler synthesis script generated by TestKompress in the
IP Creation Phase and make any needed modifications. Refer to “Design Compiler Synthesis
Script” in Chapter 4 for example scripts for EDT logic written in Verilog RTL.
Note
When using the external flow, you will need to modify this script to read in the RTL
description of the boundary scan circuitry if you added boundary scan. Refer to
“Preparing to Synthesize Boundary Scan and EDT IP” for an example Design Compiler
synthesis script, with modifications for boundary scan.

May 2007
Three Design Compiler commands TestKompress includes in the synthesis script for either flow
merit further comment to clarify what they do:
• set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

This command prevents Design Compiler from including “assign” statements in the
Verilog gate level netlist. This is done because assign statements can cause problems in
some tools later in the design flow.
• set_clock_transition 0.0 edt_clock
These commands prevent buffering of the EDT clock during synthesis and preserve,
when Design Compiler optimizes the design, the EDT clock network TestKompress
added to the EDT logic. With these commands, be sure to perform clock tree synthesis
later for the EDT clock.
After you run Design Compiler to synthesize the netlist and verify no errors occurred, check
that tri-state buffers were correctly synthesized. Design Compiler is unable to correctly
synthesize tri-state buffers for certain technologies and inserts incorrect references to
“\**TSGEN**” instead.
Note
This is not due to a problem in the generated RTL; rather, it is a Design Compiler issue. If
the “TSGEN” keyword exists in the synthesized netlist, you must correct it. For details on
how to proceed, refer to “Incorrect References to \**TSGEN** in Synthesized Netlist”
on page 235.

May 2007

May 2007
Chapter 6
Pattern Generation and Verification
This chapter describes how you use TestKompress to generate EDT patterns. In this part of the
flow, referred to as the EDT Pattern Generation Phase, you generate the final set of test vectors
for the design. The chapter also describes how to verify the generated patterns. Figure 6-1
shows the layout of this chapter and the processes involved.
Figure 6-1. EDT Pattern Generation and Verification Procedure
Synthesize 1. Preparing for Pattern Generation

EDT Hardware
(Design Compiler) 2. Verifying the IP
3. Generating EDT Patterns
Generate/Verify
EDT Patterns 4. Optimizing Compression
(TestKompress)
5. Saving the Patterns
Hand off to Vendor 6. Setting Up for HDL Simulation

7. Running the Simulation
After you insert I/O pads and boundary scan, and synthesize all the added circuitry (including
the EDT logic), invoke TestKompress on the synthesized top level netlist (Verilog or VHDL)
and generate the EDT test patterns.
Note
You can write test patterns in the same formats FastScan uses (for example, VHDL,
Verilog, and WGL).
Preparing for Pattern Generation

Note
You can reuse FastScan dofiles, with addition of some EDT-specific commands, to
generate compressed patterns with the same test coverage as the original FastScan
patterns. You cannot directly reuse pre-computed, existing ATPG patterns.

May 2007
To prepare for EDT pattern generation, check that the tool’s EDT capability is on1, and
configure the tool the same as when you created the IP. For example, if you created the IP with
one scan channel, you must generate test patterns for circuitry with one channel.
Note
The tool issues DRC violations if you attempt to generate patterns for a different number
of scan channels than you used in the IP.
You must also add scan chains in the same order the tool used in the IP Creation Phase, as the
tool infers connections to the EDT logic from this order. To reliably add the correct number of
chains in the correct order in the Pattern Generation Phase, Mentor Graphics recommends you
use the setup dofile the tool generated in the IP Creation Phase. You can, of course, add your
own customizations to this dofile.
The Report Scan Chains command lists the scan chains in the same order they were added
originally. For additional information, refer to the next section, “Using the Automatically
Generated EDT Dofile and Procedure File.”
Compared to when you generated test patterns using FastScan with the scan-inserted core
design (see “Running FastScan ATPG (Optional)”), 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 circuitry. This is done by exercising the EDT clock, update and
bypass (if present) control signals as illustrated in Figure 6-2.
Figure 6-2. Sample EDT Test Procedure Waveforms

load_unload shift shift capture load_unload shift
scan enable
scan clock
EDT update
EDT clock
EDT bypass
EDT reset
1. Issue a “report environment” command and look for the line, “EDT = ON (compressed patterns)”. If
necessary, enter a “set edt on” command to turn on EDT.

May 2007
Prior to each scan load, the EDT circuitry 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-2,
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. The operation of these signals is described in the
load_unload and shift procedures in the test procedure file the tool generates in the IP Creation
Phase. An example of this file is shown in the Chapter 4 section, “EDT Pattern Generation
Files.”
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 during the IP Creation Phase 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.
• If your design includes uncompressed scan chains (chains you did not define with the
Add Scan Chains command when setting up for the IP Creation Phase and whose scan
inputs and outputs are primary inputs and outputs), you must define each such scan
chain using the Add Scan Chains command without the -Internal switch when setting up
for EDT 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 in the Chapter 7 section, “Modifying the EDT Dofile
and Procedure File for Boundary Scan.”
Using the Automatically Generated EDT Dofile and

Procedure File
The first two setups described in the preceding section are included in the dofile TestKompress
automatically generates during the IP Creation Phase. For an example of this dofile, refer to
“Dofile” in the “EDT Pattern Generation Files” section of Chapter 4.
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 written by
TestKompress in the IP Creation Phase, as follows:
• The timeplate used by the shift procedure is updated to include the EDT clock.

May 2007
• In this timeplate, there must be a delay between the trailing edge of the clock and the end
of the period. Otherwise, a P3 (Procedure Rule #3) DRC violation will occur.
• The load_unload procedure is set up to initialize the EDT circuitry and apply shift a
number of times corresponding to the longest “virtual” scan chain (longest scan chain
plus initialization cycles) seen by the tester. The number of initialization cycles is
reported by the Report EDT Configuration command.
• 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.
For an example of this test procedure file, refer to “Test Procedure File” in the “EDT Pattern
Generation Files” section of Chapter 4.
Using the Automatically Generated Bypass Dofile and Procedure

File
The tool generates a dofile and an test procedure file you can use with FastScan to activate
bypass mode and run regular ATPG.1 Examples of these files are shown in the Chapter 4
section, “Bypass Mode Files.” If your EDT 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.
Verifying the IP
TestKompress uses two mechanisms to verify that the EDT logic will work as it is supposed to:
• Design rules checking (DRC)

• Enhanced chain and IP (chain+IP) test
The next two sections describe these mechanisms.
Design Rules Checking (DRC)

Several DRC rules verify the EDT circuitry operates correctly. The tool provides the most
complete information about violations of these rules when you have preserved the IP structure
through synthesis. Following is a brief summary of just the rules that verify operation of the
EDT logic:
• K19 — This check simulates the EDT decompressor netlist and performs diagnostic
checks if a simulation-emulation mismatch occurs.
1. You can also run regular ATPG using the FastScan command-line mode of TestKompress. Simply enter a
“set edt off” command after invoking the tool to change to FastScan command-line mode.

May 2007
• K20 — This check identifies the number of pipeline stages within the compactors, based
on simulation.
• K22 — This check simulates the EDT compactor netlist and performs diagnostic checks
if a simulation-emulation mismatch occurs.
For detailed descriptions of all the EDT design rules (K rules) checked during DRC, refer to the
“Design Rules Checking” chapter of the Design-for-Test Common Resources Manual.
Enhanced Chain and IP Test

In addition to performing DRC verification of the EDT logic, TestKompress automatically
saves, as part of the pattern set, an enhanced chain and IP (chain+IP) test. This test consists of
several scan patterns that verify correct operation of the EDT circuitry and the scan chains. The
tool generates the enhanced test whether you add faults on the core or on the entire design. This
enhanced test is necessary because the EDT circuitry is not the standard scan-based circuitry for
which traditional chain test patterns are designed. The traditional chain test only targets faults
on the scan chains. It does not guarantee high test coverage of the EDT logic. The enhanced
chain+IP test helps in debugging simulation mismatches and guarantees very high test coverage
of the EDT logic.
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 decompressed and
shifted into a mask shift register as the pattern data is shifted into the scan chains. Once a
pattern’s codes are in this register, they are then 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 will always be one or more unused outputs.)

May 2007
Figure 6-3. Example Decoder Circuitry for Six Scan Chains and One Channel
Masking
gates
1
2
3
Chain To compactor
Outputs 4 XOR tree
5
6
Decoder
2n bits out
Classic decoder
used
decodes to 1-hot
out of 2n
n code bits in
unused
Mask Hold Register
edt_mask Mask Shift Register
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 will 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 enhanced chain test for a 10X configuration has a minimum of 18 patterns. These 18
patterns can be composed of the following non-masking and masking patterns: two non-
masking patterns (control bit is set), ten masking patterns (control bit is not set, codes
correspond to “used” codes), six non-masking patterns (control bit is not set, but codes result in
the one-hot selector being in the “unused” group).

May 2007
The actual set of chain test patterns depends on how many chains each channel has. For
example, if you have two channels and 19 chains, the first channel will have ten chains and the
second, nine chains. In this case, the composition of the chain test will be:
• Patterns 0 and 1 — Non-masking patterns (control bit is set).

• Patterns 2 through 10 — Masking patterns (control bit is not set). Only one chain will be
observed per channel, due to “used” codes for each channel.
• Pattern 11 — Masking pattern (control bit is not set). For channel 1, one chain will be
observed due to a “used” code for this channel. For channel 2, all chains will be
observed due to an “unused” code for that channel.
• Patterns 12 through 17 — Masking patterns (control bit is not set). However, for both
channels all chains will be observed due to “unused” codes.
You can clearly see this 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 will have binary
expected values. All other chains in that channel will have X expected values. To see an
example of a masked ASCII pattern, refer to “Masking Scan Chain Output Pins” on page 146.
So, depending on which chain test is failing, it is possible to deduce which chain might be
causing problems. In the preceding example, if a failure occurred for any of the patterns 2
through 10, you could immediately map it back to the failing chain and, based on the cycle
information, to a failing cell. For pattern 11, if channel 1 had a failure, you similarly could map
it back to a chain and a cell. If only a non-masking pattern or a masking pattern with “unused”
codes failed, then mapping is a little bit tricky. But in this case, most likely masking patterns
would fail as well.
Coverage for Enhanced Chain and IP Test

Experiments performed by Mentor Graphics engineers using sequential fault simulation in
FlexTest demonstrate that test coverage for the EDT logic with the enhanced chain test is nearly
100% when the IP does not include bypass logic (essentially multiplexers that bypass the
decompressor and compactor). Test coverage declines to just above 94% when the IP 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.

May 2007
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 IP faults. But because IP
fault detection cannot be serially simulated, TestKompress conservatively does not give credit
for them. This results in a relatively high number of undetected faults in the IP being included in
the calculation of test coverage. You, therefore, see a lower reported test coverage than is
actually the case.
The chain+IP test targets faults in the EDT logic as well. The tool always performs the chain+IP
test, so adding faults on the entire design is not necessary in order to get IP test coverage. To
avoid incorrectly low reported test coverage, the best practice is to add faults on the core only.

TestKompress supports all FastScan pattern functionality, 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. When you
generate EDT patterns, use as a starting point, the dofile and test procedure file written by
TestKompress in the IP Creation Phase. If you added boundary scan, you will need to modify
the files as explained in the section, “Modifying the EDT Dofile and Procedure File for
Boundary Scan.”
In the IP Creation Phase, you invoked TestKompress on the core level of the design. For the
Pattern Generation Phase, you invoke the tool on the synthesized top level of the design that
includes synthesized pads, boundary scan if used, and the EDT logic. Here is an example
invocation on a Verilog file named created_edt_top.v, assumed here to be the top level file the
tool generated in the IP Creation Phase:
<mgcdft tree>/bin/testkompress created_edt_top.v -verilog \

-lib my_atpg_lib -log edt_pattern_generation.log -replace
For a description of how this file is generated, refer to the Chapter 4 section, “Creating the RTL
Description of the EDT Logic.” Next, you need to set up TestKompress. To do this, invoke the
dofile written by the tool in the IP Creation Phase. For example:
SETUP> dofile created_edt.dofile
For information about the EDT-specific contents of this dofile, refer to “EDT Pattern
Generation Files” in Chapter 4. Enter ATPG mode and verify that no DRC violations occur. Pay
special attention to the EDT DRC messages.
SETUP> set system mode atpg
Now, you can enter the commands to generate the EDT patterns. If you ran FastScan 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 without EDT.

May 2007
ATPG> add faults /my_core// Only target faults in core

Another reason to add faults on the core is to avoid incorrectly low reported test coverage, as
explained earlier in “Adding Faults on the Core Only is Recommended.”
The Report Scan Volume command provides reference numbers when analyzing the achieved
compression.
Note
If you reorder the scan chains after you generate EDT patterns, you must regenerate the
patterns. This is true even if the EDT logic has not changed. EDT patterns cannot be
modified manually to accommodate the reordered scan chains.
Figure 6-4 illustrates an important characteristic of the EDT circuitry in the Pattern Generation
Phase.
Figure 6-4. Circuitry in the Pattern Generation Phase
floating PI
D
Chain 4
e
c C
o o
m Chain 3 m
p p
SI a SO
r
e c
Chain 2 t
s o
s r
o
Chain 1
r
There is no physical connection between the decompressor and the internal scan chains, as seen
within the tool in the Pattern Generation Phase. This modification occurs only within the tool,
as a result of the “add scan chains -internal” command. TestKompress does not modify the
external netlist in any way.
Basically, TestKompress breaks the connection and turns the internal scan chain inputs into PIs
as a means of controlling the values the ATPG engine can place on them. TestKompress
exercises this control by constraining these PIs to Xs at certain points during pattern generation,
thereby preventing interference with values being output by the decompressor. It does this while

May 2007
emulating the behavior of an unbroken connection between the decompressor and the scan
chains.
Note
If you report primary inputs, the scan chain inputs are reported in lines that begin with
“USER:”. This is important to remember when you are debugging simulation
mismatches.
Optimizing Compression
You can do a number of things to ensure maximum compression in TestKompress:
• Limit observable Xs
• Use Dynamic Compaction1
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
Create Patterns for the smallest pattern set, as it executes 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 the Patterns

Save EDT test patterns in the same way you do in FastScan. For complete information about
saving patterns, refer to the Save Patterns command in the ATPG and Failure Diagnosis Tools
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-
1. As in FastScan, dynamic compaction is also referred to as “ATPG compression” or “dynamic

compression” in TestKompress.

May 2007
Post-Processing of EDT Patterns
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 the section, “Reordering Patterns”
in Chapter 7.
Parallel Patterns
Because parallel simulation patterns force and observe the decompressed data directly on the
scan cells, they have to be written by TestKompress, which 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 Save 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 Save 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
exception that they have X expected values for cells which 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 the Chapter 7 section, “Masking Scan Chain Output Pins.”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, will be shorter because the extra initialization 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. TestKompress, however, writes

May 2007
Simulating the Generated Test Patterns
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 111 for more information.
The TestKompress 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 ATPG engine can then include it when generating EDT 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 vectors, you can verify the
correctness of the captured data for the vector, 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.
Note
Parallel VHDL patterns require the ModelSim simulator, same as the parallel VHDL
patterns produced by FastScan.
To verify that the test vectors and the EDT circuitry operate correctly, you need to serially
simulate the test vectors 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 save 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. The section,
“Simulating the Design with Timing” in the Scan and ATPG Process Guide provides useful
background information on the use of this switch. Refer to the Save Patterns command
description in the ATPG and Failure Diagnosis Tools Reference Manual for usage information.
Note
You must use TestKompress 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 decompressed
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.

May 2007
Setting Up for HDL Simulation

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

../created_edt_top_gate.v -y my_sim_lib
This will compile 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:
../modeltech/<platform>/vlog pat_p_edt.v pat_s_edt.v
Running the Simulation

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

-l sim_p_edt.log -c
../modeltech/<platform>/vsim edt_top_pat_s_edt_v_ctl -do "run -all" \
-l sim_s_edt.log -c
The “-c” runs the ModelSim simulator in non-GUI mode.

May 2007

May 2007
Chapter 7
Special Topics
Introduction
This chapter provides information about how you can perform traditional ATPG runs on an
EDT design that includes bypass circuitry in the EDT logic. The chapter also details how you
can integrate boundary scan into an EDT design when you use the tool’s external flow. Some of
the advanced features of the TestKompress tool are discussed as well. You do not need to
understand every topic to use the tool; however, these topics are useful for those seeking
detailed understanding of the tool and the EDT logic.
Following is a list of the topics discussed in this chapter:
Bypassing EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

EDT and Boundary Scan (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Using Pipeline Stages in the EDT Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Using Pipeline Stages Between Pads and Channel Inputs or Outputs . . . . . . . . . . . . . . 129
Understanding How Lockup Cells are Inserted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Evaluating Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Masking Scan Chain Output Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Fault Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Reordering Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Bypassing EDT Logic

TestKompress provides an option to bypass the entire EDT logic and access the internal scan
chains directly. This enables you to use FastScan (or the FastScan command-line mode of
TestKompress) to apply regular ATPG patterns, patterns that cannot be compressed such as
hand-made scan patterns, or patterns from other ATPG tools such as FlexTest. To access the
FastScan command-line mode of TestKompress, enter a “set edt off” command after
invocation; you can now run TestKompress like a standalone version of FastScan (except for
the absence of the GUI). In the following sections, references to FastScan mean either FastScan
or the FastScan command-line mode of TestKompress.
Structure of the Bypass Logic

Because the number of internal scan chains is relatively large, the tool reconfigures the scan
chains in bypass mode into fewer, longer scan chains. For example, in a design with 100

May 2007
Special Topics
Bypassing EDT Logic
internal scan chains and four external channels, every 25 scan chains can be concatenated in
bypass mode to form one scan chain. This scan chain can then be connected between the input
and output pins of a given channel.
Figure 7-1 illustrates conceptually how the bypass mode is implemented.
Figure 7-1. Bypass Mode Circuitry
Chain 4 .
Chain 3 .
SI . SO
Chain 2 .
Chain 1 .
Decompressor Compactor
Notice that the bypass logic is implemented with multiplexers. When you utilize the internal
flow, TestKompress includes the multiplexers in the EDT logic that is instantiated in the top
level of the design. With the external flow, TestKompress adds a third EDT block that contains
the multiplexers and instantiates it in the top level wrapper.
By default, the EDT logic includes the bypass circuitry. To operate the bypass circuitry, you run
FastScan in bypass mode on the gate level netlist containing the EDT circuitry. The following
sections describe the steps you use to “turn on” bypass mode.
Applying Identical Patterns in EDT and Bypass Mode

TestKompress supports the creation of decompressed versions of each EDT pattern. The
availability of decompressed EDT patterns enables you to use FastScan in bypass mode to
directly load the scan cells with the same values TestKompress (EDT On) loads. For debugging
simulation mismatches in the core logic, it is sometimes helpful if you can apply the exact same
patterns with FastScan in bypass mode that you applied with TestKompress.

May 2007
Special Topics
Bypassing EDT Logic
After you generate EDT patterns in the Pattern Generation Phase, you can direct TestKompress
to translate the EDT patterns into bypass mode FastScan patterns and write the translated
patterns to a file. The file format is the same as the regular FastScan binary file format. You
accomplish the translation and create the binary file by issuing the Save Patterns command with
the -EDT_Bypass and -Binary switches. For example:
ATPG> save patterns my_bypass_patterns.bin -binary -edt_bypass
You can then read the binary file into FastScan, optionally simulate the patterns in the Good
machine system mode to verify that the expected values computed in TestKompress 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 the section, “Using EDT
Bypass Patterns in FastScan.”
There are several reasons you cannot use TestKompress alone to create the EDT bypass
patterns:
• Bypass operation requires a different set of test procedures. These are only loaded when
running FastScan and are unknown to TestKompress 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. The two sets of test procedures would cause the
register driving the signal to be forced to different values and the expected values
computed for EDT would therefore not be correct for bypass mode.
• TestKompress 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, TestKompress 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 XOR’d 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 TestKompress uses
masking, refer to “Masking Scan Chain Output Pins.”
Chain Test Pattern Handling for Bypass Operation

TestKompress saves only the translated EDT scan patterns in the binary file. The tool does not
save the EDT enhanced chain and IP (chain + IP) test patterns. The purpose of the chain + IP

May 2007
Special Topics
Bypassing EDT Logic
test 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, verification of the logic with the chain + IP
test is unnecessary. Regular FastScan chain test patterns are sufficient to verify the scan chains
work in bypass configuration; FastScan appends these to the pattern set when you write out the
EDT bypass patterns from FastScan.
Note
Because the EDT pattern set contains the chain + IP test patterns while the EDT bypass
pattern set written by TestKompress does not, the total number of patterns in the EDT and
EDT bypass pattern sets will be different.
In FastScan, you can use the EDT bypass patterns for debugging problems in the core design
and the scan chains, but not in the EDT logic. If the chain + IP test fails in TestKompress but the
bypass chain test passes in FastScan, it indicates a possible problem in the EDT logic or the
interface between the EDT logic and the scan chains. Be aware that EDT bypass patterns will
not help you debug these problems.
Using EDT Bypass Patterns in FastScan

After you save the EDT bypass patterns, you invoke FastScan on the design using the dofile and
test procedure file generated in the TestKompress IP Creation Phase. You then read into
FastScan the binary pattern file you previously saved from TestKompress. You can optionally
simulate the patterns in the FastScan good machine mode to verify that the expected values
computed in TestKompress are still valid in bypass mode. Then save the patterns in any of the
tool’s supported formats, WGL or Verilog for example.
EDT Bypass Pattern Flow Example

Note
The following steps assume that, as part of a normal EDT flow, you already have run
TestKompress to create the EDT IP, followed by Design Compiler to synthesize it. You
must complete both steps (described in Chapters 4 and 5, respectively) in order to run
FastScan in bypass mode. The bypass dofile and the bypass test procedure file generated
by TestKompress are required by FastScan in order to correctly apply an EDT bypass
pattern set.
In the TestKompress Pattern Generation Phase, issue a “save patterns -binary -edt_bypass”
command to write EDT bypass patterns. For example:
ATPG> save patterns my_bypass_patterns.bin -binary -edt_bypass
Notice that the -Binary and the -Edt_bypass switches are both required in order to write EDT
bypass patterns.

May 2007
Special Topics
Bypassing EDT Logic
Setting Up FastScan
In Setup system mode in FastScan, start by invoking the bypass dofile generated in the
TestKompress IP Creation Phase. Place the design in the same state in FastScan that you used in
TestKompress, then run DRC.
Note
Placing the design in the same state in FastScan as in TestKompress ensures the expected
test values in the EDT bypass patterns remain valid when the design is configured for
bypass operation.
The following example uses the bypass dofile, created_bypass.dofile, described in the Chapter
4 section, “Creating the RTL Description of the EDT Logic”:
SETUP> dofile created_bypass.dofile

SETUP> set system mode good
Verify that no DRC violations occurred.
Processing the EDT Bypass Patterns

To simulate the EDT bypass patterns and verify the expected values, enter commands similar to
the following:
GOOD> set pattern source external my_bypass_patterns.bin

GOOD> report failures -pdet
Note
The expected values in the binary pattern file mirror those with which TestKompress
observes EDT patterns. Therefore, if TestKompress 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 FastScan in bypass
mode.
Saving the Patterns with TestKompress Observability

To save the patterns in another format using the expected values in the binary pattern file, issue
the Save Patterns command with the -External switch. For example, to save ASCII patterns:
GOOD> set pattern source external my_bypass_patterns.bin

GOOD> save patterns my_bypass_patterns.ascii -external
Saving the Patterns with FastScan Observability

Alternatively, you can save expected values based on what is observable by FastScan when the
design is in bypass operation. Some scan cells which had X expected values in TestKompress,
due to scan chain masking or compaction with an X in another scan cell, may be observed by

May 2007
Special Topics
Bypassing EDT Logic
FastScan. To save patterns where the expected values reflect FastScan observability, first
simulate the patterns as follows:
SETUP> set system mode good

GOOD> set pattern source external my_bypass_patterns.bin -store_patterns
GOOD> run
Note
The preceding command sequence will cause the Xs that emulate the effect of
compaction in EDT to disappear from the expected values. The resultant bypass patterns
will no longer be equivalent to the EDT patterns; only the stimuli will be identical in the
two pattern sets. For a given EDT pattern, therefore, the corresponding bypass pattern
will no longer provide test conditions identical to what the EDT pattern provided in
TestKompress.
Using the -Store_patterns switch in Good system mode when specifying the external file as the
pattern source causes FastScan 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 FastScan, the test coverage reported may be
slightly higher than it actually is in TestKompress. This is because FastScan 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, there likely will be fewer Xs in the
recomputed values, resulting in the higher coverage number.
When you subsequently save these patterns, take care not to use the -External switch with the
Save 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:
GOOD> save patterns my_bypass_patterns.ascii
Creating Bypass Patterns with FastScan

Note
The following steps assume that, as part of a normal EDT flow, you already have run
TestKompress to create the EDT IP, followed by Design Compiler to synthesize it. You
must complete both steps (described in Chapters 4 and 5, respectively) in order to run
FastScan in bypass mode. The bypass dofile and the bypass test procedure file generated
by TestKompress, are required by FastScan in order to generate patterns in bypass mode.

May 2007
Special Topics
EDT and Boundary Scan (External Flow)
Setting Up FastScan
First, you need to set up FastScan before you start generating test patterns. You do this by
invoking the bypass dofile in Setup mode and then running DRC. The following example uses
the bypass dofile, created_bypass.dofile, described in the Chapter 4 section, “Creating the RTL
Description of the EDT Logic”:
SETUP> dofile created_bypass.dofile

Verify that no DRC violations occurred.
Generating the Bypass Patterns

After you run the previous two commands and pass DRC, create basic patterns as you would for
a design without EDT. For example, the following sequence of commands will create patterns
with dynamic compression. Be sure to add faults only on the core of the design (assumed to be
“/my_core” in this example) and disregard the EDT circuitry.
ATPG> add faults /my_core

The Report Scan Volume command provides reference numbers you can use when analyzing
the achieved compression, or to see if the patterns will fit on the tester.
The generated patterns are standard ATPG patterns that utilize the bypass circuitry.

The information in this section applies to the external EDT logic location flow.
Flow overview
Note
As mentioned previously, boundary scan cells must not be present in your design before
you add the EDT logic. This is the same requirement that applies to I/O pads and is for
the same reason; to enable TestKompress to create the EDT circuitry as a wrapper around
your core design.
To include boundary scan in your design, you perform an additional step after the EDT IP
Creation Phase. In this step, you can use any tool you want to insert boundary scan. However,
the following sections assume you use BSDArchitect, which creates an RTL description of the
boundary scan circuitry. Figure 5-2 shows a conceptual view of how BSDArchitect incorporates
this boundary scan description into a wrapper that in turn instantiates the EDT wrapper
containing the EDT IP and the core design.

May 2007
Special Topics
When you insert boundary scan, you typically configure the TAP controller in one of two ways:
• Drive the minimal amount of the EDT control circuitry with the TAP controller, so the
boundary scan simply coexists with EDT. This is described in the next section,
“Boundary Scan Coexisting with EDT.”
• Drive the EDT clock, update, and bypass signals with the TAP controller as described in
the section, “Driving EDT Signals with the TAP Controller.”
These two approaches are described in the following sections.
Boundary Scan Coexisting with EDT

This section describes how EDT can coexist with boundary scan and provides a flow reference
for this methodology. This approach enables the EDT circuitry 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.
Invoking BSDArchitect
Issue the bsdarchitect shell command to invoke BSDArchitect on the top level wrapper,
“edt_top”. For example:
<mgcdft tree>/bin/bsdarchitect created_edt_top.v -verilog \

-log bsda.log -replace -nogui
Note
BSDArchitect only needs the top level wrapper, not the complete netlist.
Inserting Boundary Scan Circuitry

Issue the following commands to configure the scan channels to be accessible through PIs and
POs and all control signals to be controlled by PIs:
BSDA> run
BSDA> report bscan cell
BSDA> report bscan status
BSDA> save bscan -replace
The boundary scan circuit in the resulting file, edt_top_bscan.v, will include the TRST port for
the TAP interface, which provides an asynchronous reset for the TAP controller. This is the
BSDArchitect default unless you use the Set Bscan Reset command to eliminate the TRST port.
Modifying the BSDArchitect Output

You must modify the BSDArchitect Verilog output if it contains instantiations of “pullup” and
you are using Design Compiler for synthesis. If you do not remove them or comment them out,
these instantiations become unresolved references during logic synthesis.

May 2007
Special Topics
Note
Set Bscan Pullup is a BSDArchitect command that turns off the generation of pull-up
resistors. For information on the use of this command, refer to the BSDArchitect
Reference Manual.
Preparing to Synthesize Boundary Scan and EDT IP

Prior to synthesizing the EDT IP and boundary scan circuitry, you should ensure any scripts you
use for synthesis include the boundary scan circuitry. For example, the Design Compiler
synthesis script that the TestKompress tool generated in the IP Creation Phase would need the
following modifications (shown in bold font) to ensure the boundary scan circuitry is
synthesized along with the EDT IP:
Note
The modifications are to the example script shown in the “Design Compiler Synthesis
Script” section of Chapter 4.
/************************************************************************
** 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

May 2007
Special Topics
/* Report design results for EDT IP */

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 -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. This is described in the section, “Synthesizing a
Netlist with the EDT Logic.”
Modifying the EDT Dofile and Procedure File for Boundary Scan
Note
The information in this section applies only when the design includes boundary scan.
To correctly operate boundary scan circuitry, you need to edit the dofile and test procedure file
TestKompress wrote in the IP Creation Phase. The changes you must make, typically, are as
follows:
• 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 EDT signals with the TAP
controller.
In the simplest configuration, the EDT circuitry 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 the Chapter 4 section, “EDT Pattern Generation Files,”
except now it includes the changes (shown in bold font) necessary to support boundary scan
when configured simply to coexist with EDT. The boundary scan circuitry is assumed to
include a TRST asynchronous reset for the TAP controller.

May 2007
Special Topics
//
//
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 pin constraints tms C1
add pin constraints edt_clock C0
set edt -channels 1 -ip_version 1
The test procedure file, created_edt.testproc, shown in the Chapter 4 section, “EDT Pattern
Generation Files,” must also be changed to accommodate boundary scan circuitry that you
configure to simply coexist with EDT. 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.
//
//
timeplate gen_tp1 =
force_pi 0 ;
measure_po 100 ;
pulse clk 200 100;
pulse edt_clock 200 100;
period 400 ;
end;

May 2007
Special Topics
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 ;
...
force tms 1;
force tck 0;
force trst 0;
end;
cycle =
force trst 1;
end;
end;
Driving EDT Signals with the TAP Controller

You can drive one or more EDT 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

May 2007
Special Topics
with EDT. Some of these apply when you set up the boundary scan circuitry, others when you
generate patterns:
• If you want to drive the entire EDT circuitry from the TAP controller, you first should
decide on an instruction to drive the EDT channels. BSDArchitect provides the
INT_SCAN instruction that, in a traditional scan design, enables all the internal scan
chains to be configured into one long chain and placed between TDI and TDO, while PIs
and POs have direct access. For a design with EDT, you can use INT_SCAN to drive
one of the channels by defining the channel as a core register, then making that register
the target for the INT_SCAN instruction, as shown in the following dofile excerpt:
// Define EDT channel as a core register.
add core register int_scan_reg edt_channels_in1 edt_channels_out1
-length 99
// Define INT_SCAN instruction to drived the EDT channel.

add bscan instruction INT_SCAN -int_scan -reg int_scan_reg
Loading the INT_SCAN instruction in the instruction register places the specified
internal core register between TDI and TDO. With this configuration, any remaining
channels can be driven directly by the PIs and observed on the POs.
Note
TestKompress does not currently support the BSDArchitect MULT_SCAN instruction.
• 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. As
described next, BSDArchitect can generate the gating logic necessary to suppress these
three pulses for any one core clock.
• Once you define the core register and specify it as the target register for the INT_SCAN
instruction, the next step is to specify the scan interface using the Set Iscan Interface
command. The scan interface consists of the type of scan, the scan enable signal, the
scan clock, and the mode (whether scan input/output pins are available at the top-level).
Here’s an example of that command:
set iscan interface -type mux_scan -sen scan_en
-mode stand_alone -tclk clk
The “-tclk clk” switch defines a scan clock named “clk”, that BSDArchitect creates by
routing the TCK signal through gating logic, as described in the preceding bullet. Please

May 2007
Special Topics
Using Pipeline Stages in the EDT Compactor
refer to the BSDArchitect Reference Manual for complete information about the other
switches.
The key point to remember is, if there are other clocks, they also need to be driven by the
gated TCK signal. The Set Iscan Interface command currently only supports a single
scan clock. To obtain the logic necessary to drive additional clocks, you can use Add
Port Connection command. The following example multiplexes two additional clocks,
“nclk” and “edt_clock” with TCK, using INT_SCAN as the select signal:
// Define EDT channel as a core register
add port connection nclk "buf tck" -top_select "buf INT_SCAN"
add port connection edt_clock "buf tck" -top_select "buf INT_SCAN"
In the resulting RTL file, you must manually disconnect TCK from the multiplexer
inputs and connect the gated TCK signal (similar to that used for “clk”).
• 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 circuitry, 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.
• BSDArchitect provides means to tie the EDT bypass signal to 0 (bypass mode inactive)
when INT_SCAN instruction is loaded.
• When preparing for synthesis, remove instantiations of “pullup” from the Verilog output
if you are using Design Compiler for synthesis as described previously in “Modifying
the BSDArchitect Output.” You should also modify any scripts you use for synthesis to
include the boundary scan circuitry. For an example of a Design Compiler script with
the necessary changes, see the section, “Preparing to Synthesize Boundary Scan and
EDT IP.”
Using Pipeline Stages in the EDT Compactor

Pipeline stages can sometimes improve the overall rate of data transfer through the logic in the
EDT 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 IP logic is relatively shallow, most designs will not
need compactor pipeline stages to attain the desired shift frequency. The limiting factors on
shift frequencies are usually the performance of the scan chains and power considerations.
Should you need pipeline stages in the compactor, you specify to include them with the Set
EDT -Pipeline_logic_levels_in_compactor command when setting up the tool in the IP Creation
Phase. These pipeline stages are clocked by the EDT clock and require that the tool insert

May 2007
Special Topics
Using Pipeline Stages Between Pads and Channel Inputs or Outputs
lockup cells for them as described in the section, “Lockups Between Scan Chain Outputs and
Compactor” on page 136.
Note
The -Pipeline_logic_levels_in_compactor switch specifies the maximum number of
combinational logic levels (XOR gates) between compactor pipeline stages, and not the
number of pipeline stages. The number of logic levels between any two pipeline stages is
used because that controls the propagation delay between pipeline stages. Being a
limiting design factor, propagation delay is typically of most interest.
Using Pipeline Stages Between Pads and

Channel Inputs or Outputs
When the signal propagation delay between a pad and the corresponding EDT channel input or
output is excessive, you may want to add pipeline stages. Following the guidelines in this
section, you can add pipeline stages between a top level channel input pin/pad and its
corresponding decompressor input, or between a compactor output and its corresponding
channel output pin/pad. Different channel inputs or outputs may have a different number of
pipeline stages or none.
Typically, you would make decisions about and insert pipeline stages during top-level design
integration. Since this logic may be spread throughout the design and should not be contained
within the EDT logic modules, TestKompress does not create channel pipeline stages as part of
the EDT logic.
Important: If you add channel pipeline stages, you need to inform TestKompress of their
existence using the Set EDT Pins -Pipeline_stages command when setting up the tool in the
Pattern Generation Phase. You must also make certain changes in your test procedure file as
described in the following subsections.
Channel Output Pipelining

TestKompress supports channel output pipelinessimilar to compactor pipeline support (see
“Using Pipeline Stages in the EDT Compactor” on page 128 for information about compactor
pipelining). The tool ensures there are sufficient additional shift cycles per pattern to flush out
the pipeline and observe the entire scan chains. Without pipelining, the number of additional
shift cycles per pattern, compared to the length of the longest scan chain, is typically four. As
long as the number of output pipeline stages (including both compactor and channel output
pipelining) is less than or equal to this number, the tool will not increase the number of
additional shift cycles in each pattern. If the number of output pipeline stages is more than four,
the tool automatically increases the number of additional shift cycles to at least match that
number.

May 2007
Special Topics
Channel Input Pipelining

While the contents of the channel output pipeline stages at the beginning of shifting each pattern
are irrelevant since they will be flushed out, the contents of the channel input pipeline stages do
matter because they will go to the decompressor when shifting begins (just after the
decompressor is initialized in the load_unload procedure).
Important: At the beginning of shift for every pattern, all channel input pipeline stages must
contain a value of zero. This can be achieved by a number of different methods with different
trade-offs; these are described in “Initializing the Input Channel Pipeline” on page 131.
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 tool will increment to six the
number of additional shift cycles in each pattern.
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
• Accommodating the initialization requirement for pipeline stages on the input side
requires extra effort on your part.
Clocking of 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, ensure there is a lockup cell between the pipeline and the decompressor.
Note
EDT patterns saved for application through bypass mode (Save 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 master, becomes a copy of the last input pipeline stage in
bypass mode. To resolve this, you must add at the end of the pipeline stages for a
particular channel input, a lockup cell that is clocked on the trailing edge of a shift clock.
This ensures that the first cell in the scan chain remains a master.

May 2007
Special Topics
On the output side, the last state element driving the channel output is either a compactor
pipeline stage clocked by the EDT clock, or more likely 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.
If the clock used for the pipeline stages is not a shift clock, remember to pulse it in the shift
procedure.
Additional clocking considerations, related to the initialization of the input pipeline stages, are
described in the next section.
Initializing the Input Channel Pipeline

As mentioned earlier in the “Channel Input Pipelining” section, the input (but not output)
channel pipeline stages must have zeros before shifting in any pattern. TestKompress pattern
generation assists with this by ensuring every pattern generated has sufficient trailing zeros
(ones for the channels with pad inversion) to set the pipeline stages to zeros after every pattern
is shifted in. Therefore, you have the following general options:
• Initialize the input pipeline stages during load_unload in either of the following ways:
o Use an asynchronous reset dedicated to those pipeline stages (it should not disturb
the scan cells).
o Use the edt_update and edt_clock signals to perform a synchronous reset as done for
initializing the decompressor in load_unload.
This option is straightforward to implement, but requires additional signals (not timing-
critical) to be routed to the pipeline stages.
• Initialize the input pipeline stages prior to the first pattern only, then ensure the zeros
that get shifted into the input pipeline stages at the end of shift (for every pattern) are not
changed during capture. This may be attractive if you have no direct reset mechanism
for the input pipeline stages and want to avoid routing reset signals.
This option has two components: How to initialize the pipeline stages for the first
pattern, and how to ensure that zeros shifted into the pipeline stages at the end of shift
are not changed during capture.
o Initializing the pipeline stages before the first pattern can be done in the test_setup
procedure by forcing all channel pins with pipeline stages to zero (one if there is
inversion in the pad, between the pin and the pipeline stages), and pulsing the
pipeline stages clock(s) as many times as the number of pipeline stages.

May 2007
Special Topics
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, since the EDT clock is pulsed there as
well (to reset the decompressor and update the mask logic).
o After each scan load, the input pipeline stages contain zeros as mentioned earlier.
There are two options to maintain those zeros through the capture cycle:
• Constrain the clock used for the pipeline stages off.
• Constrain the channel input pin to 0 (or 1 in case of channel inversion).
Since 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

The K19 and K22 rules checks will detect errors in initializing the channel input pipeline stages.
If the pipeline is not correctly initialized for the first pattern, K19 should report mismatches on
the EDT block channel inputs - assuming the hierarchy is not dissolved and the EDT logic is
identified. If the EDT block channel inputs cannot be located, e.g. because the design hierarchy
was dissolved, K19 will report that Xs are shifted out of the decompressor. On the EDT block
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 passed, but the pipeline
contents get changed (during capture or the following load_unload prior to shift) such that it no
longer contains zeros, K22 will fail. K19 and K22 will detect those cases if you defined input
channel pipelining; 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 will report 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 will result in one less
cycle of delay than expected, which will also trigger a K20 violation. If the first stage is TE, and
the user specifies one less pipeline stage, those 2 errors may mask each other and no violation
may be reported. However, this may result in mismatches during serial pattern simulation.

May 2007
Special Topics
Examples
The following command defines two pipeline stages for input channel 1:
set edt pins input_channel 1 -pipeline_stages 2
This example sets the EDT context to core1 (EDT context is specific to modular TestKompress
and is explained in the Modular TestKompress chapter), then specifies that all output channels
of the core1 block have one pipeline stage:
set current block core1

set edt pins output_channel -pipeline_stages 1
Following are the modified test procedures for a design with two channels having input
pipelining. The input pipeline stages are clocked by the EDT clock, edt_clock. One channel
(edt_channel1) has five channel input pipeline stages and inversion in the pad (between the pin
and first pipeline stage), while the other channel (edt_channel2) has three pipeline stages and no
inversion. The user-added events that support the pipelining are shown in bold, comments in
bold italics.
timeplate gen_tp1 ;
// Initialize up to five input pipeline stages

cycle =
force edt_channel1 1 ; // 5 pipeline stages, inversion
force edt_channel2 0 ; // 3 pipeline stages, no inversion
pulse edt_clock ;
end;
cycle =
pulse edt_clock ;
end;
cycle =
pulse edt_clock ;
end;
cycle =
pulse edt_clock ;
end;
cycle =
// This 5th pulse is not necessary in test_setup since edt_clock
// gets pulsed again in load_unload. Had another clock been used to
// control the pipeline stages, this pulse would be necessary.
pulse edt_clock ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
// For channel pins with pipelines: as was done in test_setup,
// the pins must be forced again since edt_clock is pulsed in
// load_unload and it is also used for the pipeline stages.
force edt_channel1 1 ;
force edt_channel2 0 ;

May 2007
Special Topics
Understanding How Lockup Cells are Inserted
force system_clk 0 ;
force edt_clock 0 ;
force ramclk 0 ;
force scan_enable 1 ;
pulse edt_clock ;
end;
apply shift 21 ;
end;

This section introduces the subject of how TestKompress inserts lockup cells as part of the EDT
logic. For an introduction to lockup cells, refer to “Merging Chains with Different Shift Clocks”
in the Scan and ATPG Process Guide. TestKompress inserts edge-triggered flip-flops as lockup
cells in the EDT logic created by the tool, never in the core. To determine where to insert lockup
cells, the tool analyzes the timing relationships between the waveform edges of the clocks that
control the sequential elements at the interfaces between the scan chains and the EDT logic. The
following topics describes each case where lockup cells are inserted:
• Lockups Between Decompressor and Scan Chain Inputs

• Lockups Between Scan Chain Outputs and Compactor
• Lockups in the Bypass Circuitry
The tool examines the relationship between the clock that controls each sequential element
sourcing data across an interface and the clock that controls the sequential element receiving the
data. These two clocks are referred to as the source clock and the destination clock,
respectively. The tool categorizes the relationship of these two clocks as either overlapping or
non-overlapping:
• Overlapping—The two clocks have identical waveform timing within a tester cycle;
they are “on” at the same time and their edges are aligned.
• Non-overlapping—Both clocks are active in a tester cycle, but only one clock is “on” at
any time; the clock edges are not aligned.
Note
The tool does not support partially overlapping source and destination clocks.
When the source clock and the destination clock do not overlap, and the active edge of the
destination clock occurs earlier in the cycle than the active edge of the source clock, a lockup is
unnecessary. In this case, the tool does not insert a lockup cell. You can obtain a detailed report
of the lockup cells the tool has inserted by issuing the Report EDT Lockup_cells command.

May 2007
Special Topics
Lockups Between Decompressor and Scan Chain Inputs

The EDT 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 IP 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.
TestKompress 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. 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. It also 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 so as to
reduce routing of the system clocks from the core to the EDT hardware.
Table 7-1 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.

May 2007
Special Topics
Table 7-1. Lockup Cells Between Decompressor and Scan Chain Inputs
Clock Source Dest. clock Source1 Dest.1, 2 # Lockups Lockup3
Waveforms 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 2 TE, LE
(LE)
Non- EDT clock Scan clock LE LE 2 TE, LE
4
Overlapping
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 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 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 7-1.
Note
If there is a pre-existing transparent latch between the decompressor and the first scan
cell, the tool will detect it and add a single lockup cell (LE) 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 TestKompress inserts pipeline stages, it may insert lockup cells as needed in front of the
first pipeline stage. Pipeline stages are LE flip-flops clocked by the EDT clock, similar to the

May 2007
Special Topics
sequential elements in the decompressor. If the tool does not insert pipeline stages, it will not
insert lockup cells in the compactor.
For each scan chain, the tool analyzes 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). Similar to the input side of the scan chains, TestKompress
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.
It adds lockup cells, driven by the EDT clock, 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 hardware.
Table 7-2 shows how the tool inserts lockup cells in the compactor.
Table 7-2. Lockup Cells Between Scan Chain Outputs and Compactor
Clock Source Dest. clock Source1, 2 Dest.1 # Lockups Lockup3
Waveforms clock change capture inserted edge(s)
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)
Non- Scan clock EDT clock LE LE 1 TE
4
Overlapping
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)

May 2007
Special Topics
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.
Lockups in the Bypass Circuitry

The number and location of lockup cells TestKompress 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 latches and may not be part of a
scan cell. TestKompress 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 master/copy scan cell combination is always driven by the same clock. This
prevents the situation where captured data in the master 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 master 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 there is an active lockup cell at the beginning of a scan chain, the tool identifies it and
treats it as the source cell.
• If a lockup latch already exists at the end of a scan chain, the tool learns its behavior and
treats it as the source cell.

May 2007
Special Topics
Table 7-3 summarizes how the tool inserts lockup cells in the bypass circuitry.
Table 7-3. Bypass Lockup Cells

Clock Source1 Dest.1 Source2, 3 Dest.2, 3 # Lockups Lockup
Waveforms clock clock change capture inserted edge(s)
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- clk1 clk2 LE LE 2 LE clk1,
4
Overlapping 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 1 TE clk1
(TE) (TE)

May 2007
Special Topics

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

May 2007
Special Topics

edge edge
Non- clk1 clk2 LE active high 2 LE clk1,
Overlapping4 (TE) TE clk2
clk1 clk2 LE active low 2 LE clk1,
(LE) TE clk2
clk1 clk2 active high LE 2 LE clk1,
(LE) TE clk2
clk1 clk2 active low LE 2 LE clk1,
(TE) TE clk2
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)
Overlapping clk1 clk2 TE active high 2 LE clk1,
(TE) TE clk2
clk1 clk2 TE active low 2 LE clk1,
(LE) TE clk2
clk1 clk2 active high TE 2 LE clk1,
(LE) TE clk2
clk1 clk2 active low TE 2 LE clk1,
(TE) TE clk2
Non- clk1 clk2 TE active high 2 LE clk1,
Overlapping4 (TE) TE clk2
clk1 clk2 TE active low 2 LE clk1,
(LE) TE clk2
clk1 clk2 active high TE 2 LE clk1,
(LE) TE clk2
clk1 clk2 active low TE 2 LE clk1,
(TE) TE clk2
1. clk1 & clk2 are the functional (scan) clocks.

May 2007
Special Topics
Evaluating Performance
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.
The purpose of this section is to focus on the parts of the EDT 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 7-2 illustrates the typical evaluation flow.
Figure 7-2. Evaluation Flow
From
Synthesis
Synthesized
Netlist
(no scan)
Insert Scan
ATPG Netlist
Scripts with scan
Generate Patterns Generate Patterns

with TestKompress with FastScan
The complete EDT flow, as described in Chapter 2, includes two separate invocations of the
EDT software. These are described in detail in the following chapters:
• Chapter 4: Creating the EDT Logic

• Chapter 6: Pattern Generation and Verification
In an experimentation flow, where your intention is to verify how well EDT works in a design,
you only invoke TestKompress once, and use it just to generate patterns. You can 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 TestKompress meaningful, is establish a
point of reference using FastScan.

May 2007
Special Topics
Establishing a Point of Reference

To illustrate how you establish a point of reference using FastScan, 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:
Test Data Volume = ( #scan loads ) × ( volume per scan load )
= ( #scan loads ) × ( #shifts per patterns ) × ( #scan channels )
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 will remain 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 much which scan chain configuration you use
when you establish the reference point.
In the following sections, the required steps to establish a point of reference are described
briefly. A design configured with eight scan chains is assumed.
Invoke FastScan
Issue the following command to invoke FastScan on the netlist with eight scan chains and
execute the dofile that performs basic setup. For example:
<mgcdft tree>/bin/fastscan mydesign_scan_8.v -verilog -lib my_lib.atpg

-dofile atpg_8.dofile -log fs_8.log -replace -nogui
Run DRC
Issue the following command to run DRC and prepare for running ATPG:
Verify that no DRC violations occur.
Generate Patterns
Assuming the design does not have RAMs and is full scan, 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 FastScan run and the EDT run.

May 2007
Special Topics
ATPG> add faults /cpu_i

ATPG> set fault sampling 10
Note the test coverage and the total data volume as reported by the Report Scan Volume
command.
Measuring Performance
In these two runs (TestKompress and FastScan), the numbers you will want to examine are:
• Test coverage (Report Statistics)

• CPU time (Report Statistics)
• Scan data volume (Report Scan Volume)
Another interesting number is the number of observable X sources (E5 (Extra Rule #5))
violations, which can explain lower compression performance.
Also, you can do a run that compares the results with and without fault sampling.
Improving Performance
Table 7-4 suggests some analyses you can do if the measured performance is not as expected:
Table 7-4. Summary of Performance Issues

Unsatisfactory Result Suggested Analysis
Compression - Many observable X sources. Examine E5 violations.
- Too short scan chain vs. # of initialization cycles.
Verify the # of initialization cycles, and scan chain
length using the Report EDT Configuration command.
Run time - Untestable/hard to compress patterns. If they cause a
high runtime in FastScan, they will also cause a high
runtime in TestKompress.
- If TestKompress has a much larger runtime than
FastScan, examine X sources, E5 violations.
Coverage - Shared scan chain I/Os. Scan pins will be masked by
default. For a normal IP Insertion Phase, these pins
should be dedicated.
- Too aggressive compression (chain-to-channel ratio too
high), leading to incompressible patterns. Use Report
Aborted Faults command to debug. Look for EDT
aborted faults.

May 2007
Special Topics
Varying 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 will typically result 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.
Varying the Number of Scan Channels

Another alternative is to first 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, within one invocation of TestKompress. 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 DFTAdvisor to configure the design with many more scan chains than you
estimated, say, 100 scan chains.
3. Run TestKompress 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 TestKompress that you used in FastScan when you
established a point of reference, with one exception: in TestKompress, you must use the
Set EDT 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.

May 2007
Special Topics
Masking Scan Chain Output Pins
Determining the Limits of Compression

You will find that 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. For example, if your design has eight scan chains, the
most compression you can achieve under optimum conditions will be less than 8X compression.
To exceed this maximum, you would need to reconfigure the design with a higher number of
scan chains.
Speeding 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 ATPG with fault sampling using FastScan. Then, use the same
fault sample when generating patterns for TestKompress.
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. For more information on fault sampling,
refer to the description of the -Sample switch under the Save Patterns command in the
ATPG and Failure Diagnosis Tools Reference Manual.

This section covers the topic of scan chain masking; why it is necessary, and how
TestKompress uses masking. You do not need to understand this topic to use TestKompress;
however, you can increase your understanding of the tool and the EDT IP by reading this
material.
Why Masking is Needed

For a design with EDT, TestKompress 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 will then
block 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 will never be measured. This is illustrated in Figure 7-3,
where the row in the middle shows the values measured on the channel output.

May 2007
Special Topics
Figure 7-3. X-Blocking in the Compactor
Chain 1
1 0 X 1 X 0 0 0 1 Chain Output
Channel
0 1 X 1 X 1 X X 0
Output
compactor
Chain 2
1 1 0 0 X 1 X X 1 Chain Output
TestKompress 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 7-4.
The Xs substituted by the tool for actual values, unmeasurable because of the compactor, are
shown in red.
Figure 7-4. X Substitution for Unmeasurable Values
Chain 1
1 0 X 1 X 0 X X 1
Chain 2
1 1 X 0 X 1 X X 1
Resolving X Blocking with Scan Chain Masking

The solution to this problem is a mechanism utilized in the EDT IP called “scan chain
masking.” This mechanism allows selection of individual scan chains on a per-pattern basis.
Figure 7-5 shows how this would work for the example of the preceding section. For one
pattern, only the values of Chain 2 are measured on the scan channel output. This way, the Xs in
Chain 1 will not block values in Chain 2. Similar patterns would then also be produced where
Chain 2 is disabled while the values of Chain 1 are observed on the scan channel output.

May 2007
Special Topics
Figure 7-5. Example of Scan Chain Masking
Chain 1
1 0 X 1 X 0 0 0 1 Chain Output
0
1 1 0 0 X 1 X X 1
masking Channel
gates Output
1 compactor
Chain 2
1 1 0 0 X 1 X X 1 Chain Output
When using scan chain masking, TestKompress records the actual measured value for each cell
in the unmasked, selected scan chain in a compactor group. TestKompress 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 7-6, 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 7-6. TestKompress Handling of Scan Chain Masking
Chain 1 (masked)
X X X X X X X X X
Chain 2
1 1 0 0 X 1 X X 1
Following is part of the TestKompress transcript from a pattern generation run for a simple
teaching design in which the tool employed masked patterns to improve coverage:1
1. The design had three scan chains, each containing just three scan cells. One of the scan chain pins was
shared with a functional pin, contrary to recommended practice, in order to illustrate the negative impact such
sharing has on test coverage.

May 2007
Special Topics
// ---------------------------------------------------------
// Simulation performed for #gates = 134 #faults = 68
// system mode = ATPG pattern source = internal patterns
// ---------------------------------------------------------
// #patterns test #faults #faults #eff. #test
// simulated cvrg in list detected patterns patterns
// deterministic ATPG invoked with abort limit = 30
// EDT without scan masking. Dynamic compaction disabled.
// --- ------ --- --- --- ---
// 32 82.51% 16 47 6 6
// --- ------ --- --- --- ---
// Warning: Unsuccessful test for 10 faults.
// EDT with scan masking. Dynamic compaction disabled.
// --- ------ --- --- --- ---
// 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.

May 2007
Special Topics
Fault Aliasing
Fault Aliasing
Another potential issue with the compactor used in the EDT IP is called fault aliasing. Assume
one fault is observed by two scan cells, and that these scan cells are located in two scan 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. Figure 7-7 illustrates this.
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 7-7. Example of Fault Aliasing
Chain 1
1/0 Chain Output
Good/Faulty
0/0
Channel
1/0 Output
Chain 2
1/0 Chain Output
The solution to this problem is to utilize scan chain masking. TestKompress does this
automatically. In TestKompress, a fault that is aliased will not be marked detected for the
unmasked pattern (Figure 7-7). Instead, the tool uses a masked pattern as shown in Figure 7-8.
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.

May 2007
Special Topics
Reordering Patterns
Figure 7-8. Using Masked Patterns to Detect Aliased Faults
Chain 1
1/0 Chain Output
Good/Faulty
1/0 1
1/0
Channel
0 Output
Chain 2
1/0
Chain Output
Reordering Patterns
Within the TestKompress tool, you can reorder patterns using static compaction, using the
Compress Patterns command, and pattern optimization, using 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 Save
Patterns command.
TestKompress does not support reordering of serial EDT patterns by a third-party tool, after the
patterns have been saved from the TestKompress tool.
This has to do with what happens in the compactor when two scan chains have different length.
Suppose two scan chains are compacted into one channel, as illustrated in Figure 7-9. 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 7-9. Handling Scan Chains of Different Length
Pattern 2 Pattern 1
000111 1 1 0 0 1 1
Channel
Output
111 010 0 0 0
Fill

May 2007
Special Topics
Reordering Patterns

May 2007
Chapter 8
Modular TestKompress
Introduction
The default behavior of TestKompress requires the instantiation of a single EDT logic block at
the top level of a design, after all design blocks are assembled into a netlist. Although this is the
most direct method of implementing compression, inserting and verifying EDT logic in each of
the blocks before top-level integration is often preferable. Modular TestKompress enables you
to insert and verify EDT logic at the block level. In the modular flow, you perform a standard
TestKompress insertion for each block, and verify its operation with the patterns generated in
the tool’s Pattern Generation Phase. Once the EDT logic is created, synthesized and verified for
all the blocks, you then perform an extra top-level integration step that enables you to generate
final top-level patterns for the fully-integrated design.
You can also run the modular flow of Test Kompress on a a fully integrated design, where EDT
logic is created for each block within the design. Sometimes this is preferable to other flows for
efficiency in routing and layout. For more information, see the “Generating Modular EDT
Logic for a Fully Integrated Design” section in this chapter.
This chapter describes how to use TestKompress for ATPG on modular designs. Modular
designs are comprised of separate interconnected blocks or modules of logic that were
developed and verified in relative isolation from each other before being instantiated in a larger
design. In typical block-based flows, most if not all of the design and verification process is
finished at the block level by the time top-level integration is started.
Following is a list of the topics discussed in this chapter:
Modular TestKompress Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Planning Your Modular TestKompress Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Creating EDT Logic for Each Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Generating Modular EDT Logic for a Fully Integrated Design . . . . . . . . . . . . . . . . . . . 162
Preparing the Top-level Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Generating Top-level Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Modular TestKompress Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

May 2007
Modular TestKompress Overview

Figure 8-1 shows an overview of the modular TestKompress flow The parts of the flow specific
to modular TestKompress are highlighted in bold. Click on the links in the figure to access
detailed information.

May 2007
Figure 8-1. Modular TestKompress Flow
Modular flow planning: page 158

Test proc
Block N Dofile file Balancing scan chains: page 159
Netlist Block N
with scan Block N (review standard flows: page 40)
Block-Level EDT Logic Creation and Verification

(DRC, coverage, pattern simulation)
Repeat for each block
(Figure 8-2)
EDT EDT Test

EDT Block N Dofile proc file
Netlist
with EDT Block N Block N
User Integration: page 164
Top-level Top-level
Top-level Proc
Dofile
Netlist File
TestKompress SETUP> set edt mapping on (page 167)

SETUP> add scan groups
Setup SETUP> add edt block... (page 173)
(for each block) SETUP> set edt Instances...
SETUP> dofile <blk-level dofile> (page 167)
Design Rule SETUP> set system mode atpg

Top-level Checking
Pattern Creation
(perform once) Configuration ATPG> report edt configuration -all_blocks
(page 184)
Generate Top-level
EDT Patterns
Create Reports
Save Results ATPG> save patterns

Pattern Gen Phase
Top-level
EDT Patterns

May 2007
Figure 8-2 shows the insertion and verification of EDT logic at the block level. It is very much
like inserting and verifying EDT logic at the top level; you simply repeat the process for each
individual block. After you have created and verified the EDT logic for the smaller blocks, you
perform a new and relatively easy user integration step during design integration to define the
block-level EDT logic. Finally, you generate top-level patterns for the fully integrated design.
Figure 8-2. Block-Level EDT Logic Creation and Verification
Block-Level EDT Logic Creation - repeat for each block (page 161)
Test
Netlist Dofile Proc
with scan File
TestKompress
Setup
DRC
Configuration
Create EDT logic
EDT Logic Creation Phase
Design Compiler DC
Synthesize design Synth EDT
Script RTL
EDT
EDT Test
Synth Netlist Dofile Proc
with EDT File
Block-level Verification - repeat for each block (page 164)

TestKompress
DRC, Coverage
Create Patterns
Pattern Generation Phase
Time-based
Block-level Verify Patterns
Patterns Simulator
In this chapter, the term, “EDT block” refers to a design block that implements a full
complement of the EDT hardware (decompressor, compactor, and optionally bypass logic). An
EDT block is not necessarily a module (entity) in the HDL but rather is a
decompressor/compactor/core group. It may not even be within a given module (entity) as is the
case, for example, if the design is flattened for place-and-route. An EDT block’s EDT hardware
drives all the scan chains within the block. Figure 8-3 shows a conceptual example of a netlist
with four EDT blocks (each consisting of a design block with integrated EDT hardware) and a

May 2007
separate EDT block for the top-level glue logic. The top-level glue logic is testable with EDT
hardware as shown, or using bypass mode as described in “Bypassing EDT Logic” on page 115.
Figure 8-3. Design that Contains Several EDT Blocks
Netlist
D D
e e
C C
c c
o o
o o
m m
m EDT Block 1 m EDT Block 2
with Scan Chains p with Scan Chains p
p p
a a
r (sub-block w/ integrated r (sub-block w/ integrated
c c
e EDT hardware) e EDT hardware)
t t
s s
o o
s s
r r
o o
r r
top-level logic
D (top-level glue logic)
C
c o
m EDT Block 5 with Scan Chains
p m
r p
D D
e e
C C
c c
o o
o o
m m
m m
EDT Block 3 p p
p p EDT Block 4
with Scan Chains a with Scan Chains a
r r
c c
e (sub-block w/ integrated e (sub-block w/ integrated
t t
s EDT hardware) s EDT hardware)
o o
s s
r r
o o
r r
Note
You are urged to become familiar with the standard TestKompress flows that use single-
IP implementations prior to using the tool with a modular design to create multiple block-
level IP implementations. The standard flows are outlined in earlier chapters and in the
TestKompress training offered by Mentor Graphics Education Services.

May 2007
Planning Your Modular TestKompress Flow
The benefits of the modular approach include:
• Creation and verification of EDT logic at the block level
Note
Block-level verification is when you create block-level patterns that you then simulate to
prove that the EDT logic is correct. In modular TestKompress, you use block-level
patterns only to verify the block-level EDT logic. Block-level patterns are not usable at
the top level of the design. You create final top-level patterns from the top of the design.
• Reduction of routing congestion caused by a large number of internal scan chains

• Support for design flows where blocks are implemented by separate design teams
• Support for all standard core-level flows
• Easier integration of cores that already contain fully verified EDT logic
• Faster run time for a very large design if it has multiple EDT blocks instead of one large
decompressor and compactor

This section describes specifics to consider when planning your modular TestKompress flow.
Modular TestKompress Requirements

• Each EDT block’s EDT logic must be connected to its own set of scan chains. That is,
you cannot share scan chains between different EDT blocks.
• Uncompressed scan chains (scan chains not driven by or observed through the EDT
logic) are permitted, provided the chains’ scan inputs and outputs are primary inputs and
outputs. That is, the inputs and outputs must be connected directly to top level pins.
Note
You must define each such scan chain in the Pattern Generation Phase of modular
TestKompress using the Add Scan Chains command without the -Internal switch. For
additional information, refer to “Including Uncompressed Scan Chains” on page 50.
• 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. Refer to “Balancing Scan Chains Within and Between Blocks” on page 159 for
more information.
• Sharing EDT pins with functional pins within the same EDT block is supported as long
as the standard recommendations and restrictions are followed. These are described in

May 2007
the Chapter 4 sections on pin sharing, starting with “Sharing Functional Pins with EDT
Control and Channel Pins” on page 66.
• Control signals from different EDT blocks, 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.
All channel pins, however, must be connected to different top-level pins.
• Scan channels cannot be concatenated. Plan for a sufficient number of top-level pins to
access scan channels from all the EDT blocks.
• You must manually connect block-level signals when you prepare the top-level netlist.
This includes connecting EDT signals to I/O pads and inserting any multiplexers needed
for channel output signals you share with functional signals. More on this in the section,
“Integrating EDT Blocks into the Netlist” on page 165.
• You must manually create the top-level dofile and top-level test procedure file needed
for top-level pattern generation. This process is detailed in the sections, “Integrating
Block-level Dofiles into a Top-level Dofile” on page 166 and “Integrating Block-level
Test Procedure Files into One File” on page 177.
Balancing Scan Chains Within and Between Blocks

Design blocks usually represent a large amount of hardware and will most likely include many
internal blocks and many scan chains. Because scan chain balance is important for efficient
ATPG, it is very important to plan the lengths of scan chains inside each design block so that all
blocks have approximately the same scan chain lengths. The following sections provide
information on scan chain planning at the block level:
• “Determining How Many Scan Chains to Use” on page 51

• “Varying the Number of Scan Chains” on page 145
• “Varying the Number of Scan Channels” on page 145
If you target the same EDT compression for every block and apportion available tester channels
among the blocks based on each block’s proportional share of the design’s overall gate count,
you can coordinate chain lengths across multiple blocks according to the following two
equations:
# of Scan Cells in block

Scan Chain Length ≈ --------------------------------------------------------------------------------------------------------------------------------
( # of Channels for block ) × ( Chain-to-channel ratio )
# of Scan Cells in block

# of Channels for block ≈ ----------------------------------------------------------- × # of top-level Channels
# of Scan Cells in chip

May 2007
Tip: Since different designers may perform scan insertion for different design blocks, it is
a good practice to coordinate, at the project management level, the selection of a target
scan chain length that will work for all blocks.
Note
Remember when using modular TestKompress, it is very important for optimal test
coverage and efficient ATPG to have intra-block and inter-block scan chain balance.
User Integration
As with the standard TestKompress flow, modular TestKompress ATPG requires three types of
information:
• Netlist
• Dofile
• Test procedure file
To create this information for the top-level ATPG performed by modular TestKompress, you
perform an extra step after you have created the IP for each block. This extra step consists of
integrating the output from each of the block-level IP Creation steps into a top-level netlist,
dofile, and test procedure file. The netlists for this integration step are the gate-level netlists that
resulted from the synthesis of each block’s EDT logic. The dofiles and test procedure files are
those the tool wrote out when you used the Write EDT Files command during the IP Creation
Phase for each block. You then use these files for the top-level ATPG as illustrated in
Figure 8-4.

May 2007
Creating EDT Logic for Each Block
Figure 8-4. Block-level Netlist and Script Integration Flow
from Block 1 IP Creation from Block N IP Creation
EDT Block 1 Dofile

Test proc
file
… EDT Block N Dofile
Test proc
file
Netlist Block 1 Netlist Block N
with EDT Block 1 with EDT Block N
Instantiate in Integrate into one Integrate into one

netlist top-level dofile top-level test proc file
(page 165) (page 166) (page 177)
Top-level
Top-level
Netlist test proc
Dofile
with EDT file
Create Top-level
EDT Patterns
(page 184)

TestKompress supports several methods of logic creation and integration, all of which are
outlined in Chapters 2 through 5 of this manual and the TestKompress training material. For the
modular TestKompress flow, select and use any one of these methods to create the EDT logic
for each design block. The following rules apply when you are creating the EDT logic:
• Be sure scan chains are balanced and that their lengths are approximately the same as the
chain lengths in other blocks. Refer to “Balancing Scan Chains Within and Between
Blocks” on page 159 for more information.
• You can optionally generate test patterns in a block’s IP Creation Phase to estimate test
coverage and scan data volume as described in “Estimating a Block’s Coverage and
Pattern Count” on page 163.

May 2007
• After you write out the RTL for a block’s EDT logic, you must synthesize it (see
“Synthesizing Block-level EDT Logic” on page 163), then verify it as explained in
“Verifying EDT Logic for a Block” on page 164.
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 EDT files generated by this procedure support the same capabilities as the block by block
modular flow.
Requirements
• The integrated design must be complete and fully functional
• Each block must have dedicated input and output channels
Procedure
1. Add each design block, one at a time, using the Add EDT Block command.
2. Once a block is added, set up the EDT logic for it with a Set EDT command. The Set
EDT command only applies to the current block. EDT control signals can be shared
among blocks.
3. Once all the design blocks are added and set up, enter ATPG mode. For more
information, see the Set System Mode command.
4. Enter a Write EDT Files command. A composite set of EDT files is created including an
RTL file, a synthesis script, an EDT 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 EDT files for EDT logic synthesis and pattern generation.
Applying Unique Names to Modules within the EDT Logic

When you write out EDT RTL for multiple blocks, you use a different invocation of the tool for
each block. Each invocation has no knowledge of what happened in another invocation.
Therefore, the tool adds the prefix “top_module_name_” to all module (entity) names defined in
the RTL to help ensure the generated Verilog module (or VHDL entity) names are unique. The
top_module_name is the name of the top module of the netlist read in. Were the tool to use the
same prefix for each EDT block’s RTL, the blocks would not be uniquely identified, leading to
naming conflicts when you integrated them into the final netlist.

May 2007
This mechanism is fine for most purposes, but in some circumstances you may find it desirable
to use a different prefix. You can specify your own prefix by including “-rtl_prefix
prefix_string” with the Write EDT Files command when writing out the EDT RTL for a block.
To change the default prefix to “core1_”, for example, you would use:
write edt files... -rtl_prefix core1
Tip: If you use “-rtl_prefix prefix_string”, it is a good practice to coordinate the choice of
a prefix string among the engineers who will be writing out the EDT RTL for other
blocks. This will provide the opportunity not only to standardize on a helpful naming
convention (for example, core<#>), but also help prevent the accidental selection of the
same prefix for different blocks.
Estimating a Block’s Coverage and Pattern Count

After you run TestKompress to create IP for a block, you have the opportunity to estimate test
coverage and pattern count for it while still in the IP Creation Phase. As explained in
“Estimating Test Coverage and Scan Data Volume” on page 92, you do this by creating patterns
to obtain an upper bound of the coverage for the block. Be aware that this coverage may be
lower once the block is embedded in the design since the tool no longer will have direct access
to the block’s inputs and outputs.
To get a conservative coverage estimate, you can constrain all functional inputs to X with the
Add Pin Constraint command, and mask all functional outputs with the Set Output Masks
command. To constrain the functional input my_func_in to X, for example, you would use:
SETUP> add pin constraint my_func_in cx
To mask the two primary outputs my_func_out1 and my_func_out2, the command would be:
SETUP> add output masks my_func_out1 my_func_out2
Be aware that constraining the inputs to X and masking the outputs will likely produce very
pessimistic results: in addition to reducing the coverage, it will negatively affect compression
since all those inputs become X sources when the CX constraints are added to the pins.
Note
Remember that eventually final ATPG must be performed at the top level of the design.
Because the top-level ATPG will be affected by all cores in the design, coverage and
pattern count may be somewhat different.
Synthesizing Block-level EDT Logic

After you create the EDT logic for a block, you synthesize it. This step is like the synthesis
described in Chapter 5 for the standard TestKompress flow. Of course, the Design Compiler

May 2007
Preparing the Top-level Files
synthesis script TestKompress creates for a block is specific to that block, and the result of
synthesis is a gate-level netlist of the specific EDT block.
Note
During synthesis you should preserve the pin names TestKompress created in the EDT
logic hierarchy when it wrote out the RTL in the IP Creation Phase. Preserving the pin
names will ensure the tool can resolve the pins in the Pattern Generation Phase and
optimize the tool’s ability to provide useful debug information during DRC.
Verifying EDT Logic for a Block

You should perform block-level verification of the EDT logic after you synthesize it. Simply
running the pattern count and coverage estimation step that is an optional part of the block-level
IP Creation Phase (see preceding section, “Estimating a Block’s Coverage and Pattern Count”)
is not sufficient because the EDT logic is only emulated in that phase. Block-level verification
consists of two tasks:
• Creation of patterns in the Pattern Generation Phase of the tool using the block-level
dofile and test procedure file written by TestKompress
• Simulation of the resulting patterns in a timing-based simulator using the block-level
test bench created during block-level pattern creation.
Performing block-level ATPG on the synthesized EDT block in the Pattern Generation Phase
allows the Pattern Generation Phase DRC rules to verify the EDT logic is instantiated correctly
inside the block. You then simulate these patterns using the block-level test bench created
during block-level pattern generation, as explained in the Chapter 6 section, “Simulating the
Generated Test Patterns.”
Note
Recall that block-level patterns may not be used at the top level of the design. You must
generate separate top-level patterns for use at the top level of the design.
For more information on the verification performed by the tool’s DRC in the Pattern Generation
Phase, refer to “Verifying the IP” on page 104.

After block-level IP is created, synthesized, and verified for all the blocks in the design, you can
prepare the top-level files as outlined in Figure 8-4. You will need these to generate final top-
level EDT patterns. There are three top-level files you need to prepare: netlist, dofile, and test
procedure file. The next three subsections describe how to prepare these files.

May 2007
Integrating EDT Blocks into the Netlist

The integration of the EDT blocks into one unified design is a manual process of building a
netlist that instantiates all the EDT blocks with all the interconnects needed for the functional
design. This is shown conceptually in Figure 8-5 for an example Verilog design. Recall that you
can share control signals, such as edt_update, edt_clock, edt_bypass, edt_reset, scan_enable and
test_en between EDT blocks; but all channel pins, whether within or between blocks, must be
connected to different top-level pins. You can individually route the block-level channel input
and output signals from each block to the top level when you route all the other functional
signals from the blocks to the top-level pads.
Note
At the same time you are providing the logic to connect EDT channels and control signals
to top-level ports, you can also provide any functional interconnects between EDT blocks
or from EDT blocks to other parts of the design (a PLL for example).

May 2007
Figure 8-5. EDT-specific Netlist Integration
gate_scan_1.v gate_scan_2.v gate_scan_N.v

... ... ...
module core1 (...); module cor module coreN (...);
... ... ...
endmodule endmodule endmodule
... ... ...
IP creation for each of N cores

rtl_1_edt.v rtl_2_edt.v rtl_N_edt.v
... ... ...
module core1_edt (...); module c module coreN_edt (...);
... ... ...
endmodule endmodule endmodule
... ... ...
rtl_1_edt_top.v rtl_2_edt_top tl_N_edt_top.v

... ... ...
module core1_edt_top (clk,...); module co module coreN_edt_top (...);
... ... ...
core1 core1_i (...); core2 coreN coreN_i (...);
core1_edt core1_edt_i (...); core2_ coreN_edt coreN_edt_i (..
... ... ...
endmodule endmodul endmodule
... ... ...
Build a netlist that instantiates EDT blocks & interconnects

all_cores_edt_top_gate.v
module edt_top_all_cores (core1_clk,..., core2_clk,..., coreN_clk);
input core1_clk;
input core2_clk;
output ...
...
input coreN_clk;
output ...
core1_edt_top edt_block1 (core1_clk, core1_..., ..., core1_<lastpin>);

core2_edt_top edt_block2 (core2_clk, core2_..., ..., core2_<lastpin>);
...
coreN_edt_top edt_blockN (coreN_clk, coreN_..., ..., coreN_<lastpin>);

...
endmodule
Integrating Block-level Dofiles into a Top-level Dofile

As part of the extra user-integration step, you must manually construct a top-level dofile that
incorporates the setup information from each block-level dofile. You will then use the top-level
dofile for top-level pattern creation.

May 2007
Follow these steps to construct the top-level dofile:
1. Place an Add Scan Groups command at the beginning of the dofile, specifying the top-
level test procedure file you prepared as described in the section, “Integrating Block-
level Test Procedure Files into One File” on page 177.
2. Next, define the setups for each block using one of these two approaches:
Automatic Block-level Dofile Integration . . . . . . . . . . . . . . . . . . . . . . .page 167
Manual Block-level Dofile Integration. . . . . . . . . . . . . . . . . . . . . . . . . .page 170
3. After the section where all EDT blocks are defined, add commands to perform DRC and
top-level pattern creation.
Automatic Block-level Dofile Integration

The simplest, least time-consuming way to integrate the setup information in the block-level
dofiles into a top-level dofile is to let modular TestKompress obtain most setups directly from
the block-level dofiles. You do this by placing a Set EDT Mapping On command in your top-
level dofile, after top-level Add Clocks and Add Pin Constraints commands but before the
block-specific setup commands. Then use subsequent Dofile commands to run each EDT
block’s dofile.
As the tool performs the commands in the block-level dofiles, a built-in mapping mechanism
will automatically map the names of scan groups, scan chains, and most pin pathnames to the
corresponding top-level names needed for top-level pattern creation. (The exceptions are
pathnames of clock pins and constrained pins, for which you must provide top level definitions
as described next).
Note
The block-level dofiles do not contain any top-level pin or path naming information
because this information was not available during the block-level IP creation step.
Complete the top-level dofile’s setups for each EDT block as follows:
• Insert commands to define each block’s clock signals (Add Clocks, Add Read Controls,
Add Write Controls) and pin constraints (Add Pin Constraint) using the top-level pin
names in the top-level netlist.
There is no need to modify the corresponding commands in the block-level dofiles.
DRC rule K24 (EDT Rule #24) will verify the top level pin names are consistent with
the clock, read control, write control, and pin constraint signals specified in the block-
level dofiles.
• Place an Add EDT Block or Set Current Block command before each block-specific
group of setup commands.

May 2007
The Add EDT Block command defines an arbitrary name of your choice for the block
about to be defined and sets the EDT context for certain subsequent commands to this
block. The block name, which gives you a way to refer to this block later in the session,
should be unique. The command’s usage is as follows:
ADD EDt Block block_name
This command also sets the EDT context for certain subsequent commands to the block
you just defined. Subsequent commands that are sensitive to the EDT context will apply
only to this block until you change the context to a different block. The Add Scan
Chains command, EDT-specific commands that define attributes for a given block, and
some reporting commands are presently the only context-sensitive commands. Most
commands like Set System Mode, Report Statistics and Create Patterns, are unaffected
by the context and always operate on the whole design.
The Set Current Block command, which only applies to EDT blocks previously defined
with the Add EDT Block command, simply changes the EDT context to the specified
EDT block. Its usage is:
SET CUrrent Block block_name
You could define multiple EDT block names before providing any block-specific setup
information, then use the Set Current Block command to specify the required block-
specific setup information, as shown in the following top-level dofile excerpt:
...
set edt mapping on
add edt block alpha
add edt block bravo
add edt block charlie
...
set current block bravo
// Perform setups for bravo block.
dofile created2_edt.dofile
...
set current block alpha
// Perform setups for alpha block.
...
You can view currently defined block names with the Report EDT Blocks command and
delete a block definition with the Delete EDT Blocks command.
Tip: To make it as easy as possible to keep track of your setups for each block, try to
group all setup commands for a block together.
Following is an example top-level dofile that reuses the block-level dofiles to specify top-level
pattern creation setups for a modular design with three unique EDT blocks.
// all_cores_edt.do
//

May 2007
// Dofile to create top level patterns for design with 3 unique EDT blocks
add scan groups grp1 all_cores_edt.testproc
// Define top-level clocks and pin constraints for all blocks.

add clocks 0 core1_clk
add write controls 0 core1_ramclk
add read controls 0 core1_ramclk
add clocks 0 shared_edt_clock
add pin constraint shared_edt_clock C0
set edt mapping on
// DEFINE BLOCK 1
add edt block a1 //Name this block “a1” (block’s tag for later cmds)
// DEFINE BLOCK 2
add edt block a2 //Name this block “a2”
// DEFINE BLOCK 3
add edt block a3 //Name this block “a3”
// Report what’s been set.

report scan chains -all_blocks
report edt blocks
report edt configuration -all_blocks
// Once all EDT blocks are defined, perform DRC and verify there are
// no DRC violations.
report drc rules
// Create patterns that use all blocks simultaneously and generate

// patterns that target faults in the entire design.
create patterns
...
If an EDT Block is Instantiated Multiple Times at the Top Level

In the block-level IP Creation Phase, the tool includes in the *_edt.dofile written out with the
EDT RTL, a Set EDT Instances -Edt_logic_top command that specifies the instance name of
the Verilog module (VHDL entity) that contains the EDT hardware. If you instantiate this block
multiple times at the modular design’s top level, however, this instance name will not resolve to
a unique instance path within the top-level netlist. To enable the tool to uniquely identify each
of these multiple instances, include a Set EDT Instances -Block_location command in the top-
level dofile that specifies the exact location of the instance in the top-level netlist. It should be
the first setup command for the block.

May 2007
For example, if the a2 and a3 blocks in the last example of the preceding section were actually
two instances of the same EDT block, the block definitions in the top-level dofile would need to
be similar to this:
...
// DEFINE BLOCK 2
set edt instances -block_location <top_level instance or path name>
// DEFINE BLOCK 3
set edt instances -block_location <top_level instance or path name>
...
Manual Block-level Dofile Integration

The mapping performed automatically by the tool when you place a Set EDT Mapping On
command in the top-level dofile can be done manually instead. Manual mapping is more time-
consuming, however. Figure 8-6 shows the manual dofile integration flow. Detailed
information on the manual flow follows the figure.
Note
If you construct the top-level dofile by this method, do not include
“set edt mapping on” in the dofile.
Figure 8-6. Creation of Top Level Dofile
Copy of Copy of
Dofile …… Dofile
Block N
Block 1
Edit, copy and paste

applicable sections
into one top-level dofile
Top Level
Dofile

May 2007
Using Block-level Dofiles as Templates

Prior to top-level ATPG, make a copy of each block-level dofile and edit each copy so it
includes the following:
• New hierarchical pathnames (prefix the block pathname to the existing pin pathnames so
they reflect the new hierarchy in the integrated netlist).
• Unique top-level names for scan chains (add a block-specific prefix)
• Top-level pin names, matching those in the netlist (specify which chip-level pins now
drive the block-level signals referred to in the block-level files)
• Full hierarchical pathname for the instance specified with “set edt instances
-edt_logic_top” if, when integrated into the netlist, the instance will have a non-unique
name.
You must provide hierarchical paths for both internal scan chain I/O and EDT logic blocks.
Also, update the names of any block-level pins to match name changes you make in the top-
level netlist.
Tip: If you edit copies rather than the original dofiles, the originals will be available for
immediate re-use at the block-level, if necessary.
Two example dofiles are shown next, each written for a different design block in a modular
flow:
• Example Dofile for Block 1

• Example Dofile for Block 2
Figure 8-7 on page 175 shows example edits as they might appear in the top-level dofile created
from these two block-level files.
Example Dofile for Block 1

The first example block-level dofile, created_edt.dofile, is shown below. It was output by “write
edt files created” in the block-level IP Creation Phase for the same design example used to
create the non-modular Dofile example shown in the “EDT Pattern Generation Files” section of
Chapter 4. Notice that the two dofiles are identical; there are no special modular-specific
commands required!
//
//


May 2007
// If multiple instances exist with the same name, substitute the instance
// name.

add scan groups grp1 created_edt.testproc

add clocks 0 clk

add pin constraint edt_clock C0


Example Dofile for Block 2

The second example block-level dofile, created2_edt.dofile, is shown below. It was output by
“write edt files created2” in the IP Creation Phase for this block.
//
//

// If multiple instances exist with the same name, substitute the instance
// name.
set edt instances -edt_logic_top cpu2_edt_i

set edt instances -decompressor cpu2_edt_decompressor_i
set edt instances -compactor cpu2_edt_compactor_i
add scan groups grp1 created2_edt.testproc

May 2007
add scan chains -internal chain1 grp1 /cpu2_i/edt_si1 /cpu2_i/edt_so1

add clocks 0 clk

add pin constraint edt_clock C0


Merging Block-level Dofile Information into One Top-level Dofile

Once you have made appropriate revisions in the content of the dofile copies, you can construct
the top-level dofile. Figure 8-7 shows an example top-level dofile created by merging the edited
content from each of the two preceding example block-level dofiles. The shaded areas on this
example highlight what was copied directly from the block-level files. Required edits are shown
in bold font.
After you have copied the edited block-level setup information (shaded areas) into the top-level
dofile, add the following additional commands to complete the dofile’s setups for each EDT
block:
• Precede each block-specific group of setup commands with an Add EDT Block
command. This command defines an arbitrary name of your choice for the block about
to be defined. The block name, which gives you a way to refer to this block later in the
session, should be unique. The command’s usage is as follows:
ADD EDt Block block_name
This command also sets the EDT context for certain subsequent commands to the block
you just defined. This means subsequent commands that are sensitive to the EDT
context will apply only to this block until you change the context to a different block.
The Add Scan Chains command, EDT-specific commands that define attributes for a
given block, and some reporting commands are presently the only context-sensitive
commands. Most commands like Set System Mode, Report Statistics and Create
Patterns, are unaffected by the context and always operate on the whole design.
You can change the context by issuing another Add EDT Block command or, if the
block to which you want to change is already defined, by issuing a Set Current Block
command. The latter’s usage is:
SET CUrrent Block block_name

May 2007
You could define multiple EDT block names before providing any block-specific setup
information, then use the Set Current Block command to specify the required block-
specific setup information, as shown in the following dofile excerpt:
add edt block alpha
add edt block bravo
add edt block charlie
...
set current block bravo
// Define scan chains for bravo block.
add scan chains -internal bravo_chain1 grp1
/edt_top_bravo/bravo_i/edt_si /edt_top_bravo/bravo_i/edt_so
...
set current block alpha
// Define scan chains for alpha block.
add scan chains -internal alpha_chain1 grp1
/edt_top_alpha/alpha_i/edt_si /edt_top_alpha/alpha_i/edt_so
...
You can view currently defined block names with the Report EDT Blocks command and
delete a block definition with the Delete EDT Blocks command.
For each block, just as in the non-modular TestKompress flow, you must add the scan
chains in the same order specified in the IP Creation Phase. This is the same order as in
the created dofile from that phase.
Tip: To make it as easy as possible to keep track of your setups for each block, try to
group all setup commands for a block together.
• Insert appropriate Set EDT Pins commands that specify the chip-level pin to which you
connected each EDT control and channel signal. If you connected each EDT block’s
edt_update signal to the same chip-level pin, for example, then you specify that same pin
name for edt_update for each block.
The tool includes a “set edt pins” command in the block-level dofile for each EDT pin
that you issued the command for in the block’s IP Creation Phase. You can simply edit
these commands with the correct top-level names. If you did not issue “set edt pins” to
alter a particular EDT pin’s defaults in the IP Creation Phase, the tool will not include
the command in the dofile and in this case, you must add the command with the correct
top-level name.

May 2007
Figure 8-7. Creating Top-level Dofile for a Design with Two EDT Blocks
Copy of
Dofile
// all_cores_edt.do Block 1
//
// Dofile to create top level patterns for design with 2 EDT bloc
// Define the top-level test procedure file. Copy of

add scan groups grp1 all_cores_edt.testproc Dofile
Block 2
// DEFINE BLOCK 1
add edt block cp1 //Name this block “cp1” (block’s tag for use in cmds)

add scan chains -internal blk1_chain1 grp1 /edt_block1/cpu_i/edt_si1

/edt_block1/cpu_i/edt_so1
...
add scan chains -internal blk1_chain8 grp1 /edt_block1/cpu_i/edt_si8
/edt_block1/cpu_i/edt_so8
Update pathnames for
add clocks 0 core1_clk additional hierarchy.
add clocks 0 shared_edt_clock
add write controls 0 core1_ramclk
Define unique top-level names
add read controls 0 core1_ramclk
for this block’s scan chains.
add pin constraint shared_edt_clock C0
Make pin names match top-
level netlist (Figure 8-5).
// Define EDT pins for block 1
set edt pins in 1 core1_edt_channels_in1
set edt pins out 1 core1_edt_channels_out1
set edt pins in 2 core1_edt_channels_in2 Define top-level EDT pins with
set edt pins out 2 core1_edt_channels_out2 names that match top-level
set edt pins in 3 core1_edt_channels_in3 netlist.
set edt pins out 3 core1_edt_channels_out3
set edt pins clock shared_edt_clock
set edt pins update shared_edt_update
// DEFINE BLOCK 2
add edt block cp2 //Name this block “cp2” (block’s tag for use in cmds)
// set edt instances -edt_logic_top cpu2_edt_i

// set edt instances -decompressor cpu2_edt_decompressor_i
// set edt instances -compactor cpu2_edt_compactor_i

May 2007
add scan chains -internal blk2_chain1 grp1 /edt_block2/cpu2_i/edt_si1

/edt_block2/cpu2_i/edt_so1
...
add scan chains -internal blk2_chain5 grp1 /edt_block2/cpu2_i/edt_si5
/edt_block2/cpu2_i/edt_so5
Update pathnames for
additional hierarchy.
//Next 2 top-level cmds already issued (BLOCK 1) so must be commented out.
//add clocks 0 shared_edt_clock
//add pin constraint shared_edt_clock C0
Define unique top-level names
for this block’s scan chains.
Make pin names match top-

level netlist (Figure 8-5).
// Define EDT pins for block 2
set edt pins in 1 core2_edt_channels_in1 Define top-level EDT pins with
set edt pins out 1 core2_edt_channels_out1 names that match top-level
set edt pins clock shared_edt_clock netlist.
set edt pins update shared_edt_update
// Report what’s been set. Include -all_blocks; otherwise

report scan chains -all_blocks data for just the current block
report edt blocks is displayed.
// Once all EDT blocks are defined, perform DRC and verify there are
// no DRC violations.
report drc rules
// Create patterns that use all blocks simultaneously and generate

// patterns that target faults in the entire design.
create patterns
...

May 2007
Integrating Block-level Test Procedure Files into One File

Like the block-level dofiles, the block-level test procedure files contain only block-level
information. Prior to running top-level ATPG, you must integrate all block-level test procedure
files into a single top-level test procedure file as illustrated in Figure 8-8.
Figure 8-8. Creation of Top Level Test Procedure File
Test proc Test proc

file …… file
Block 1 Block N
Edit, copy and paste

applicable sections
into one top-level file
Top-level
Test proc
file
During each block-level IP Creation Phase, TestKompress produces a block-level test

procedure file similar to the example test procedure file shown in Chapter 4 (see “Test
Procedure File” under “EDT Pattern Generation Files” in Chapter 4). In a non-modular
TestKompress flow, you would use this test procedure file in the Pattern Generation Phase to
create final patterns for the design. However, in a modular TestKompress flow as part of the
extra user-integration step, you manually combine the relevant content from each block-level
test procedure file into a single top-level test procedure file and use that for top-level pattern
generation. Block-level pattern generation is only for verification of that block’s EDT logic as
explained in “Verifying EDT Logic for a Block” on page 164.
The integration of block-level test procedure files is straightforward. You take information from
each of the block-level test procedure files and aggregate test-setup, load-unload, shift and
capture procedure information into one file that is a superset of the information required for
each block. This usually is only a matter of clock definitions as well as adding the correct force
or pulse statements for edt_update and edt_clock during the load_unload, shift and capture
procedures. Pin names may also need to be changed. This process is illustrated in the next
section.

May 2007
Using a Block-level Test Procedure File as a Template

Prior to top-level ATPG, make a copy of one of the block-level files (preferably the one
containing the most procedures) to use as a template. Then using a text editor, make the
following modifications to convert it to a top-level test procedure file.
Note
The following bullets illustrate the merging process with a few excerpts based on the
procedure file example shown in the “Test Procedure File” section of Chapter 4. You are
likely to be working with more highly customized test procedures that require more
extensive merging. For example, if there is top-level initialization that requires a complex
test_setup procedure to put the chip into test mode (such as for JTAG test control), you
need to add this procedure; it will not have been created within the block level test
procedure files.
• Copy in any missing procedures from the other block-level files

• Update the timeplate or timeplates to include all statements present in each block-
specific timeplate and add any needed top-level customizations. As you add statements,
update the pin names to match the corresponding name changes in the top-level netlist.
An example of these edits is shown in Figure 8-9.
Figure 8-9. Creating a Top-level Timeplate
timeplate gen_tp1 = timeplate gen_tp1 =

force_pi 0; force_pi 0;
measure_po 100; measure_po 100;
pulse clk 200 100; pulse clk 200 100;
pulse edt_clock 200 100; pulse edt_clock 200 100;
pulse ramclk 200 100; period 400;
period 400; end;
end;
Add all clocks from the block-level timeplates. Add block-
specific prefixes to the names so they are unique and you
know with which block each is associated.
timeplate gen_tp1 =
force_pi 0;
measure_po 100;
pulse core1_clk 200 100;
pulse core2_clk 200 100;
pulse shared_edt_clock 200 100;
period 400;
end;

May 2007
• Update the load_unload procedure to include all statements present in each block-
specific version of this procedure. As you add statements, update the pin names like you
did for the timeplate. An example of these edits is shown in Figure 8-10.
Figure 8-10. Creating a Top-level Load_unload Procedure
procedure load_unload = procedure load_unload =

scan_group grp1; scan_group grp1;
timeplate gen_tp1; timeplate gen_tp1;
cycle = cycle =
force clk 0; force clk 0;
force edt_bypass 0; force edt_bypass 0;
force edt_update 1; force edt_update 1;
force edt_clock 0; force edt_clock 0;
force ramclk 0; force scan_en 1;
force scan_en 1; pulse edt_clock;
pulse edt_clock; end;
end; apply shift 26;
apply shift 16; end;
end;
Add all clocks from the block-level load_unload procedures.

Add block-specific prefixes to the names if necessary so
they are unique.
scan_group grp1;
timeplate gen_tp1;
cycle =
force core1_clk 0;
force core2_clk 0;
force shared_edt_bypass 0;
force shared_edt_update 1;
force shared_edt_clock 0;
force ramclk 0;
force core1_scan_en 1;
force core2_scan_en 1;
pulse shared_edt_clock;
end;
apply shift 26; Must be greater than one.
end;
Note
The number you specify in the apply shift statement should be greater than one but is
otherwise irrelevant; the tool will always apply shifts based on the actual traced length of
the scan chains.
• Update the shift procedure to include all statements present in each block-specific shift
procedure. As you add statements, make updates to the pin names similar to those in the
top-level timeplate and load_unload procedure. An example of these edits is shown in
Figure 8-11.

May 2007
Figure 8-11. Creating a Top-level Shift Procedure
procedure shift = procedure shift =

scan_group grp1; scan_group grp1;
timeplate gen_tp1; timeplate gen_tp1;
cycle = cycle =
force_sci; force_sci;
force edt_update 0; force edt_update 0;
measure_sco; measure_sco;
pulse clk; pulse clk;
pulse edt_clock; pulse edt_clock;
end; end;
end; end;
Add all clocks from the block-level shift procedures. Add

block-specific prefixes to the names so they are unique.
procedure shift =
scan_group grp1;
timeplate gen_tp1;
cycle =
force_sci;
force shared_edt_update 0;
measure_sco;
pulse core1_clk;
pulse core2_clk;
pulse shared_edt_clock;
end;
end;
If the same procedure occurs in multiple block-level test procedure files, you need to include it
just once in the top-level file. But in the top-level version of the procedure, you must include all
the pin-specific statements (force, pulse, and so on) from each block level version.
Example Block-level Test Procedure Files

The following are examples of two test procedure files the tool wrote in the IP Creation Phase
for the same two sub-blocks used in the netlist and dofile examples. Following these block-level
examples is the top-level test procedure file created from them. Notice that identical pin names
occur in the force and pulse statements in each block-level file. To enable the tool to force/pulse
the correct pins at the top-level, you would need to change the block-level pin names at the top
level as you merged the statements from the block-level files into the top-level procedure file.
// created_edt.testproc // created2_edt.testproc
// //
// Written by TestKompress // Written by TestKompress
// //
set time scale 1.000000 ns ; set time scale 1.000000 ns ;
set strobe_window time 100 ; set strobe_window time 100 ;
timeplate gen_tp1 = timeplate gen_tp1 =

May 2007
force_pi 0 ; force_pi 0 ;
measure_po 100 ; measure_po 100 ;
pulse clk 200 100; pulse clk 200 100;
pulse edt_clock 200 100; pulse edt_clock 200 100;
pulse ramclk 200 100; period 400;
period 400 ; end;
end;
procedure capture = procedure capture =

timeplate gen_tp1 ; timeplate gen_tp1 ;
cycle = cycle =
force_pi ; force_pi ;
measure_po ; measure_po ;
pulse_capture_clock ; pulse_capture_clock ;
end; end;
end; end;
procedure ram_passthru = procedure shift =

timeplate gen_tp1 ; scan_group grp1 ;
cycle = timeplate gen_tp1 ;
force_pi ; cycle =
pulse_write_clock ; force_sci ;
end ; force edt_update 0 ;
cycle = measure_sco ;
measure_po ; pulse clk ;
pulse_capture_clock ; pulse edt_clock ;
end; end;
end; end;
procedure ram_sequential = procedure load_unload =

timeplate gen_tp1 ; scan_group grp1 ;
cycle = timeplate gen_tp1 ;
force_pi ; cycle =
pulse_read_clock ; force clk 0 ;
pulse_write_clock ; force edt_bypass 0;
end ; force edt_clock 0;
end ; force edt_update 1;
force scan_en 1 ;
procedure clock_sequential = pulse edt_clock ;
timeplate gen_tp1 ; end ;
cycle = apply shift 26;
force_pi ; end;
pulse_read_clock ; procedure test_setup =
pulse_write_clock ; timeplate gen_tp1 ;
end ; cycle =
end ; force edt_clock 0 ;
end;
procedure shift = end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
measure_sco ;
pulse clk ;
pulse edt_clock ;
end;

May 2007
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force clk 0 ;
force edt_bypass 0;
force edt_clock 0;
force edt_update 1;
force ramclk 0 ;
force scan_en 1 ;
pulse edt_clock ;
end ;
apply shift 16;
end;
timeplate gen_tp1 ;
cycle =
force edt_clock 0 ;
end;
end;
Example Top-level Test Procedure File

Here is the top-level test procedure file that aggregates all the procedures from the preceding
block-level files. Notice that, with the exception of all the EDT control pins which are shared,
pins with the same name from different blocks were given unique names by addition of a prefix
(shown in bold font) indicating in which block-level design they occur. Be sure the top-level pin
names you use in the top-level test procedure file match the names you gave these pins in the
netlist.
// all_cores_edt.testproc
//
// Manually created from created1_edt.testproc & created2_edt.testproc
//
timeplate gen_tp1 =
force_pi 0 ;
measure_po 100 ;
pulse core1_clk 200 100 ;
pulse core2_clk 200 100 ;
pulse shared_edt_clock 200 100 ;
pulse ramclk 200 100 ;
period 400 ;
end;
procedure capture =
timeplate gen_tp1 ;
cycle =
force_pi ;

May 2007
measure_po ;
end;
end;
procedure ram_passthru =
timeplate gen_tp1 ;
cycle =
force_pi ;
pulse_write_clock ;
end ;
cycle =
measure_po ;
end;
end;
procedure ram_sequential =
timeplate gen_tp1 ;
cycle =
force_pi ;
pulse_read_clock ;
pulse_write_clock ;
end ;
end ;
procedure clock_sequential =
timeplate gen_tp1 ;
cycle =
force_pi ;
pulse_read_clock ;
pulse_write_clock ;
end ;
end ;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;
force shared_edt_update 0 ;
measure_sco ;
pulse core1_clk ;
pulse core2_clk ;
pulse shared_edt_clock ;
end;
end;
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force core1_clk 0 ;
force core2_clk 0 ;
force shared_edt_bypass 0 ;
force shared_edt_update 1 ;
force shared_edt_clock 0 ;

May 2007
Generating Top-level Patterns
force ramclk 0 ;
force core1_scan_en 1 ;
force core2_scan_en 1 ;
pulse shared_edt_clock ;
end;
apply shift 26;
end;
timeplate gen_tp1 ;
cycle =
force shared_edt_clock 0 ;
end;
end;

Note
To generate top-level patterns, you must have a top-level design netlist, dofile and test
procedure file, prepared as described earlier in this chapter. Refer to “Preparing the Top-
level Files” for more information.
Generating patterns with the top-level netlist, dofile, and test procedure file is just like
generating patterns in the standard flow. There are a couple of important differences, however:
• During the top-level modular TestKompress Pattern Generation Phase, you can use the
Set Current Block command to direct the tool to apply EDT-specific commands, as well
as the Add Scan Chains command, to a particular EDT block. Restricting the
applicability of tool commands in this way enables you to re-specify the characteristics
of that block without affecting other parts of the design. See the Set Current Block
command reference description for examples of the use of this command.
• To see currently defined blocks, use the Report EDT Blocks command. Be aware that
the Add Scan Chains command and the EDT-specific commands that define attributes
for a given block operate only on the current EDT block. 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
Following is a brief example of the modular TestKompress commands you use during EDT
logic creation and pattern generation. Figure 8-12 shows the example design. In this example,
TestKompress control signals are shared at the top level; each EDT block, created utilizing the
default external IP location flow, is composed of a wrapper that instantiates the EDT logic and
the scan-inserted core.

May 2007
Example
Figure 8-12. Netlist with Two Cores and Shared TestKompress Control Signals
edt_top_all_cores
edt_block1
core1_edt_i
edt_clock
edt_update
edt_bypass
Channel ins
}Channel ins
}
Channel outs Channel outs
core1_i
Scan chain in Scan chain out
Functional } Functional
Input
Pins }Functional
Input
Pins
Functional
Output
Pins
Output
Pins
shared_edt_clock
shared_edt_update
shared_edt_bypass edt_block2
core2_edt_i
edt_clock
edt_update
edt_bypass
Channel ins
}Channel ins
}
Channel outs Channel outs
core2_i
Scan chain in Scan chain out
Functional Functional
Input
Pins }Functional
Input Output
} Functional
Output
Pins Pins
Pins

May 2007
Example
Creating Block-level EDT Logic

The following dofile excerpt creates EDT logic with unique module names based on the core
module name. Notice that the commands you use for IP creation in a modular TestKompress
flow are the same as what you use in the tool’s default flow.
// Define scan chains, clocks, and EDT hardware.

add scan groups grp1 group1.testproc
...
add clocks clk1 0
set edt -channels 6
// Create EDT hardware with unique module names.

write edt files created1 -replace
Now, you simply repeat this process, invoking the tool on each core-level logic block in the
design and creating IP for it.
After block-level EDT logic creation, it is important to perform block-level verification on each
block. You do this by synthesizing a block’s EDT logic, then invoking TestKompress on the
resultant gate-level netlist and performing a block-level Pattern Generation Phase. Simulate the
resulting patterns in a timing-based simulator using the block-level test bench created during
block-level pattern creation. This is a good time to check the block-level scan chain balancing.
Note
Block-level patterns may not be used at the top-level.

Assume you have created the top-level netlist, dofile, and test procedure file, as described in the
section, “Preparing the Top-level Files” on page 164. The next section shows how the top-level
dofile might look when the block-level dofiles are reused as described in “Automatic Block-
level Dofile Integration” on page 167. Following that is an example of the top-level dofile
constructed using the manual method.
Example Top-level Dofile that Reuses Block-level Dofiles

In this example, the Set EDT Mapping command activates the automatic mapping of commands
from the block level dofiles to the top level. This command is required when reusing block-level
dofiles. Commands and options specific to modular TestKompress are shown in bold font.
// Define the top-level test procedure file to be used by all blocks.

add scan groups grp1 top_level.testproc

May 2007
Example
// Define top-level clocks and pin constraints here.

add clocks...
add read controls...
add write controls...
add pin constraint...
...
// 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 block 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 block 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.


create patterns
// Create reports.
report statistics
report scan volume
save patterns...
exit
Example Top-level Dofile that does not Reuse Block-level Dofiles

This example differs from the preceding example in that the relevant sections of each block-
level dofile were copied, the copies manually edited to achieve mapping similar to that
accomplished automatically by the Set EDT Mapping command in the preceding example, then
the revised sections pasted into this top-level dofile. Commands, options and edits specific to
modular TestKompress are shown in bold font.
// Define the top-level test procedure file to be used by all blocks.

add scan groups grp1 top_level.testproc
// Define the block tag (this is an arbitrary name) for an EDT block
// and automatically set it as the current EDT block.
add edt block cpu1

May 2007
Example
// The following commands were copied from the dofile generated for this
// block, with the modifications highlighted.
// Define the location (instance name) of the top-level EDT logic for this
// block; also the decompressor and compactor.
set edt instances -edt_logic_top core1_edt_i
set edt instances -decompressor core1_edt_decompressor_i
set edt instances -compactor core1_edt_compactor_i
add scan chains -internal blk1_chain1 grp1 /edt_block1/core1_i/edt_si1

/edt_block1/core1_i/edt_so1
...
set edt -channels...
// Specify the top-level control signals and channel I/O for

// this block (required).
set edt pins...
// Repeat the preceding procedure for another block.

add edt block cpu2
set edt instances -edt_logic_top core2_edt_i

set edt instances -decompressor core2_edt_decompressor_i
set edt instances -compactor core2_edt_compactor_i

...
set edt -channels...
set edt pins...
// Once all EDT blocks are defined, create patterns that use all the
// blocks simultaneously and generate patterns that target faults in
// the entire design.


create patterns
// Create reports.
report statistics
report scan volume
save patterns...
exit

May 2007
Modular TestKompress Command Reference

Table 8-1 contains links to reference descriptions of commands specific to modular
TestKompress or that have certain options specifically for modular TestKompress.
Table 8-1. Modular TestKompress Command Summary

Command Description
Add EDT Block Creates a name identifier for an EDT block instantiated in a
netlist.
Delete EDT Blocks Removes the data for the specified EDT block(s) from the tool’s
internal database.
Report EDT Blocks Displays current user-defined EDT block names.
Report EDT Configuration 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 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 hardware; for use by DRC.
Set EDT Mapping Enables the automatic mapping necessary for block-level dofiles
to be reused for top-level pattern creation.
Write EDT Files Writes all the EDT files required to implement the EDT
technology in a design.

May 2007

May 2007
Chapter 9
Pre-Synthesis EDT Logic Creation
You can create EDT logic early in your design flow, during the RTL design phase, rather than
waiting for the complete synthesized gate-level netlist of the core design. Creating the EDT
logic early, referred to as the pre-synthesis or skeleton flow, may enable you to consider the
logic’s impact early enough to plan how best to meet area and performance goals during floor-
planning, placement and routing phases.
If you know the following parameters that determine the EDT logic, you can create it before a
complete gate-level netlist is available:
• Number of external scan channels

• Number of internal scan chains
• Clocking of the first and last scan cell of each chain
• Longest scan chain length range (an estimate of the minimum number of scan cells and
maximum number of scan cells the tool can expect in the longest scan chain)
Note
Knowledge of the interface of the design is also recommended if you will be creating the
EDT logic external to the design core (External Flow).
Performing a Pre-Synthesis Flow

Figure 9-1 shows the TestKompress pre-synthesis flow. The utility, create_skeleton_design
(found in <mgcdft_tree>/bin alongside the testkompress executable), enables you to create
early EDT logic. This utility writes out a gate level “skeleton” Verilog design and several
related files you can use to perform a TestKompress IP Creation run. The skeleton design is a
design that contains just the requisite number of scan chains, with the first and last cell of each
of these chains driven by appropriate clocks. The utility gets this information from a special
input file you create for this purpose. If you will be creating the EDT logic external to the design
core, Mentor Graphics recommends you also provide an interface file.
Follow these steps:
1. Using the known number of internal scan chains and clocking of the first and last scan
cell of each chain, create a skeleton design input file following the syntax rules
explained in “Skeleton Design Input File” on page 194. You can use any ASCII text
editor you like to create this file.

May 2007
Performing a Pre-Synthesis Flow
Figure 9-1. TestKompress Pre-synthesis Flow
Prepare Input
& Interface Files
Skeleton Create Skeleton
Design Design Input File
Input File (page 194)
Create Skeleton
Design Interface File Design
(page 197) Interface File
(if ext. flow)
Run
create_skeleton_design
(page 197)
Skel.
Skeleton Skeleton Skeleton Test
Gate-level ATPG Library Dofile Proc.
Netlist File
Run TestKompress
Logic Creation Phase
(page 198)
2. If you will be creating EDT logic outside the core design (External IP Location Flow
(External Flow)), Mentor Graphics recommends you create a design interface file that
provides only the interface description of the core design in Verilog format. The format
of this file is described in “Skeleton Design Interface File” on page 197. Use any ASCII
text editor you like to create this file.
The interface file ensures the skeleton design contains the information TestKompress
needs in order to create valid pin sharing, core and EDT wrapper descriptions. This file
is unnecessary when you create the EDT logic within the core design (Internal IP
Location Flow (Internal Flow)).
3. Add the pathname of the bin directory in your Mentor Graphics DFT tree to the PATH
environment variable.
4. Run the create_skeleton_design utility using a command string similar to one of the
following:
• Internal Flow:
create_skeleton_design -o output_file_prefix \
-i skeleton_design_input_file
• External Flow:

May 2007
Skeleton Design Input and Interface Files
create_skeleton_design -o output_file_prefix \
-i skeleton_design_input_file -design_interface file_name
The utility will write out the following four files:

<output_file_prefix>.v
<output_file_prefix>.dofile
<output_file_prefix>.testproc
<output_file_prefix>.atpglib
Tip: For a list of all available options, see “create_skeleton_design Usage” on page 197.
You can get a similar list by entering a “create_skeleton_design -help -verbose” shell
command.
For a complete example showing create_skeleton_design input files and the resultant
output files, see the “Example” on page 200.
5. Invoke TestKompress on the scan-inserted skeleton netlist, <output_file_prefix>.v,
using the ATPG library, <output_file_prefix>.atpglib.
6. Provide TestKompress setup commands.
• Use the setup commands in the dofile, <output_file_prefix>.dofile, and use the test
procedure file, <output_file_prefix>.testproc.
• Issue the Set EDT command to specify the number of scan channels. Mentor
Graphics recommends you 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 “How the
Tool Uses the -Longest_Chain_Range Numbers” on page 199.
7. Provide TestKompress DRC, configuration, and logic creation commands.
• Use the Set System Mode Atpg command to flatten the design and run DRCs.
• Issue other configuration commands as needed.
• Write out the RTL description of the EDT logic with the Write EDT Files command.

Figure 9-2 shows the inputs and outputs to the create_skeleton_design utility. The “Skeleton
Design Input File” is always required. The “Skeleton Design Interface File” is needed only if
you will be creating the EDT logic external to the core design (External Flow). You must create
both files using the format and syntax described in the following subsections.

May 2007
Figure 9-2. Create_skeleton_design Inputs and Outputs
Skeleton Skel. Design

Design Interface File
Input File (if ext. IP)
create_skeleton_design
Test Verilog
Dofile Skel. Gate- ATPG
Procedure Simulation
level netlist Library
File Library
(Verilog)
Skeleton Design Input File

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

Example 9-1 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.
Example 9-2 on page 196 shows a small working example.
Example 9-1. 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

May 2007
<first_chain_number> <last_chain_number> <chain_length> \

LA <first_cell_master_clock> <first_cell_slave_clock> \
LA <last_cell_master_clock> <last_cell_slave_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, in order to enable TestKompress later to create a correct
instantiation of the core in the top level EDT wrapper (External Flow). If the scan pins
specified in this section are not present in the design interface, the utility will
automatically add them to the skeleton design. You can omit this section if you will not
be 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 will result in scan
chain pins being declared as vectors, i.e., <prefix>[Max-1:0]. The indexed option will result 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 will automatically add
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 will
use 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 first and last scan cell. 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. 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 will be the same length and contain a first and last scan cell with the same clocking.

May 2007
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 latch
timing as well. For example, if a leading edge (LE) triggered scan memory element is followed
by a lockup latch, the edge specification of the scan cell must be TE (not LE) since the cell
contains a scan memory element followed by a lockup latch and the scan cell output changes on
the trailing edge (TE) of the clock. Specifying incorrect edges will result in improper lockup
cells being inserted by TestKompress and may result in your having to regenerate the EDT logic
later.
Note
When the scan chain specification indicates the first and last scan cell have master/slave
or master/copy clocking (for example, an LE first scan cell and a TE last scan cell), the
create_skeleton_design utility will increase that chain’s length by one cell in the
skeleton netlist it writes out. This is done to satisfy a requirement of TestKompress
lockup cell analysis and will not alter the EDT logic; the length of the scan chains seen by
TestKompress after it reads in the skeleton netlist will be 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 master and slave clocks, mclk and sclk,
respectively.
Example 9-2. 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

May 2007
create_skeleton_design Usage
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

The skeleton design interface file is recommended if you will have TestKompress create the
EDT logic external to the core design. 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 201.
Tip: The interface file ensures the files written out by the create_skeleton_design utility
contain the information TestKompress needs in order to write out valid core black box
(*_core_blackbox.v) and top level wrapper (*_edt_top.v) files.
create_skeleton_design Usage
create_skeleton_design [-Help [-Verbose]] [-O output_file_prefix] [-simulation_library]
[-design_interface file_name] -I skeleton_design_input_file
• -Help
An optional switch that lists all the invocation switches, with no descriptions.
• -Verbose
An optional switch that, together with -Help, lists all the invocation switches and a brief
description of each.
• -O output_file_prefix
An optional switch and string pair that specifies a prefix for the utility to use when
constructing the names of the output files:
<output_file_prefix>.v
<output_file_prefix>.dofile
<output_file_prefix>.testproc
<output_file_prefix>.atpglib
The utility uses the default prefix “test” if you do not specify a prefix with -O.

May 2007
Creating EDT Logic Using a Skeleton Design
• -Simulation_library
An optional switch that specifies to write out a Verilog simulation library that matches
the <output_file_prefix>.atpglib ATPG library.
• -Design_interface file_name
An optional switch and string pair that specifies the pathname of a file containing a
Verilog description of the design interface. This file is recommended if you will be
using the External Flow. It enables TestKompress later to write out valid core black box
(*_core_blackbox.v) and top level wrapper (*_edt_top.v) files.
• -I skeleton_design_input_file
A required switch and string pair that specifies the pathname of the skeleton design
input file.
Creating EDT Logic Using a Skeleton Design

A skeleton design provides information regarding the number of scan chains and clocking of the
first and last scan cell in each chain. Two additional parameters (one required, the other optional
but recommended) are specified using the tool’s Set EDT command during setup, after you
have invoked TestKompress on the skeleton design:
• Number of external scan channels (required)

• Longest scan chain length range (optional, but useful when the final length of the
longest chain is unknown ahead of time)
You can specify both parameters with one command, similar to this:
set edt -channels number_of_channels -longest_chain_range min_number_cells

max_number_cells
or with two commands:
set edt -channels number_of_channels

set edt -longest_chain_range min_number_cells max_number_cells
The command(s) can be placed in a dofile or entered at the tool’s command line during setup.
Tip: The arguments specified with the -Longest_chain_range switch should reflect the
estimated length for the longest scan chain. For example, if you estimate the longest
chain will be 100 cells long, an appropriate range can be 75 to 125. It is necessary to
supply the range for only the longest chain. The length of the rest of the chains is
immaterial and does not affect the EDT logic.

May 2007
Integrating the EDT Logic into the Design
How the Tool Uses the -Longest_Chain_Range Numbers

The mask register in the EDT compactor and the internal core scan chains are loaded
simultaneously by the decompressor during scan shifting. If the mask register’s length exceeds
the specified min_number_cells, the tool uses the min_number_cells to configure the mask
register into multiple scan chains. This ensures the mask register is not the longest chain in the
design.
Note
While you may specify a min_number_cells as low as 2, it is advisable not to specify an
artificially low number. Specifying an extremely low min_number_cells will cause the
mask register to be partitioned into an unnecessarily large number of relatively short scan
chains. In rare cases this can result in incompressible patterns (due to a large number of
specified bits in a column corresponding to mask register bits for a masked pattern).
The tool uses the specified max_number_cells to ensure the bit streams supplied by the phase
shifter (in the decompressor) to internal scan chains are separated by at least as many cycles as
the max_number_cells. This reduces linear dependencies among the bit streams supplied to the
internal scan chains.
Integrating the EDT Logic into the Design

After you create the EDT logic, integrating it into the design is a manual process.
• For EDT logic created external to the design core (External Flow):
If you provided the create_skeleton_design utility with the recommended interface file
when it generated the skeleton design, you can continue with the standard TestKompress
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 will need to 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 (Internal Flow):
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
Be aware the Design Compiler synthesis script that TestKompress writes out will 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.

May 2007
Example
Knowing When to Regenerate the EDT Logic

By the time the final gate-level netlist is available, there may have been some changes to the
parameters that affect the EDT logic. Following are scenarios that could require regeneration of
the EDT logic:
• The number of channels or chains changes.

• The clocking of a first or last scan cell changes.
If this occurs, the safest approach is to regenerate the EDT logic. Whether the logic
actually changes or not depends on whether the clock edge that triggers the first or last
scan cell has changed. In addition, it depends on whether lockup cells were inserted for
bypass mode scan chains. Without a thorough understanding and knowledge of the
lockup cell insertion process, it is not entirely obvious if the logic might change. Hence,
Mentor Graphics strongly recommends you regenerate the EDT logic any time the
clocking of the first or last scan cell changes. You can determine if the logic has changed
by comparing the EDT logic RTL from the earlier run.
• The length of the longest scan chain in the final netlist is less than the min_number_cells
specified with the Set Edt -Longest_chain_range switch.
Whether the EDT logic needs to be regenerated or not depends on whether the mask
register length is more than the length of the longest scan chain (as determined by scan
chain tracing in the netlist). The safest approach is to regenerate the EDT logic and
compare the RTL from the earlier run to determine if it has changed.
• The length of the longest scan chain in the final netlist is greater than the
max_number_cells specified with the Set Edt -Longest_chain_range switch.
Whether the EDT logic needs to be regenerated or not depends on whether the phase
shifter needs to be redesigned or not. The phase shifter is designed to guarantee a
minimum separation of scan chain bit streams by at least as much as the specified
max_number_cells. The safest approach is to regenerate the EDT logic and compare the
RTL from the earlier run to determine if it has changed.
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
Note
If you will be creating the EDT logic within the core design (Internal Flow), this file is
the only input the utility needs.

May 2007
Example
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 TestKompress later to use to
create the EDT logic).
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
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 (External Flow).
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 ,

May 2007
Example
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 whose 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”.

May 2007
Example
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;
...

May 2007
Example
...
.
.
.
...
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 for the TestKompress IP Creation
Phase. Following is the example dofile bb1.dofile the utility wrote out based on the previously
described inputs:
add scan groups grp1 bb1.testproc

add scan chains chain1 grp1 scan_in1 scan_out1

May 2007
Example

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 for the
TestKompress IP Creation Phase. 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 ATPG Library

The ATPG library written out by the utility contains the models used to create the skeleton
design. You must use this library when you run TestKompress on the skeleton design.

May 2007
Example
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); )
)
model lssd_scan_cell (D, SYS_CLK, SI, MCLK, SCLK, Q, QB) (

scan_definition (
type = lssd;
data_in = D;
scan_in = SI;
scan_master_clock = MCLK;
scan_slave_clock = SCLK;
scan_out = Q;
)
input (D, SYS_CLK, SI, MCLK, SCLK) ()
intern(MOUT) (primitive = _dlat master ( , , SYS_CLK, D, MCLK, SI,
MOUT, );)
output(Q, QB) (primitive = _dlat slave ( , , SCLK, MOUT, Q, QB );)
)
Note
You can get the utility to write out a Verilog simulation library that matches the ATPG
library by including the optional -Simulation_library switch in the shell command.

May 2007
Appendix A
Getting Help
There are several ways to get help when setting up and using DFT software tools. Depending on
your need, help is available from the following sources:
• Documentation
• Online Command Help
• Mentor Graphics Support
• Examples and Solutions
Documentation
A comprehensive set of reference manuals, user guides, and release notes is available in two
formats:
• HTML for searching and viewing online

• PDF for printing
The documentation is available from each software tool and online at:
http://supportnet.mentor.com
For more information on setting up and using DFT documentation, see the “Using DFT
Documentation” chapter in the Managing Mentor Graphics DFT Software manual
Online Command Help

Online command usage information is available from the command line in all DFT tools. You
can use the Help command to display a list of available commands, the syntax usage, or the
entire reference page for a command.
Mentor Graphics Support

Mentor Graphics software support includes software enhancements, access to comprehensive
online services with SupportNet, and the optional On-Site Mentoring service. For details, see:
http://supportnet.mentor.com/about/

May 2007
Getting Help
Examples and Solutions
If you have questions about a software release, you can log in to SupportNet and search
thousands of technical solutions, view documentation, or open a Service Request online at:
http://supportnet.mentor.com
If your site is under current support and you do not have a SupportNet login, you can register for
SupportNet by filling out the short form at:
http://supportnet.mentor.com/user/register.cfm
All customer support contact information can be found on our web site at:
http://supportnet.mentor.com/contacts/supportcenters/index.cfm
Examples and Solutions

If you have a current SupportNet login, then you can access the SupportNet Design-for-Test
Circuits and Solutions site, which contains a variety of example circuits and dofiles specific to
DFT. You can access this site at the following URL:
http://supportnet.mentor.com/reference/other-info/dft_circuits/index.cfm

May 2007
Appendix B
IP Specification
NOTE: Functional pins

not shown
D
e C
c o
o B m B
m y p y
p p a p
r a Core a
e s c s
edt_channels_in[...] s s t s edt_channels_out[...]
s o
o r
r
edt_clock .
edt_update . edt_mask
edt_bypass .
scan_en .
Details for an example design with eight scan chains & two scan channels:
Decompressor connnected to scan chain

inputs in EDT mode
D Q D Q
Clk Clk
D Q
P D Q
. h .
Clk Clk
D Q
a D Q
. s . B
L Clk
D Q e
Clk
D Q y
edt_channels_in1 F . Clk . Clk p
D Q S D Q
a
edt_channels_in2 S . Clk h . Clk
s
i
M .
D
Clk
Q
f .
D
Clk
Q
s
D Q
t D Q
. Clk
e . Clk
D Q D Q
r
edt_update . Clk . Clk
edt_mask
edt_clock . . (scan chain masking data)
# scan channels < # of lockups < # scan chains 0 < # lockups < # scan chains
(lockups are always inserted here) # depends on scan chain arrangement &
clocking of lockups ahead of Phase Shifter

May 2007
IP Specification
Source
Destination
Bypass Core
1
Chain 1 .
0
1 .
0
Chain 2
D .
e D Q
1
.
Chain 3
c Clk
0
. C
o D Q D Q
m Clk . Clk
1
Chain 4 . o
0 m
p .
r 1 p
Chain 5 . a
e 0
s . c
s
1
Chain 6 . t
0 o
o .
r 1 r
Chain 7 .
0
.
1
Chain 8 .
0
.
system_clk2
system_clk1
edt_bypass
0=EDT mode
1=Bypass mode (concatenate)
edt_channels_in1 & 2 Output bypass

Lockup cells (inserted per Bypass Lockup Table 7-3)
Compactor
Core (complex case)
LC Bank A
Chain 1 D Q
LC Bank B
Clk
D Q
Clk
Chain 2 D Q
M
a
Clk
O edt_channels_out1
s P u
Chain 3 D Q
t
k i
i
Clk
D Q p
Chain 4 n D Q
Clk p u
g t
Clk
e
Chain 5 D Q l B
L y
o Clk
D Q i p
Chain 6
g D Q
Clk n a
i e s
c Clk
s edt_channels_out2
Chain 7 D Q
Clk
D Q
Clk
Chain 8 D Q
Clk

May 2007
IP Specification
Core Compactor
Chain 1 (simple case)
Chain 2
M
a O edt_channels_out1
Chain 3 s u
k t
i p
Chain 4 n u
g t
Chain 5 B
L y
o p
Chain 6
g a
i s
c s edt_channels_out2
Chain 7
Chain 8
Output Bypass
Scan chain 4 output 1
1
Scan channel 1 0
edt_channels_out1
Func output from core 0
Masking Scan chain 8 output 1

1
gates Scan channel 2 0
edt_channels_out2
0
1 Func output from core
2 Compactor
3 edt_bypass scan_en
4 Compactor (active high)
Chain
Outputs 5
6 Compactor only when bypass logic

is included
7
Compactor only when a channel output is
8 shared with a functional output
Decoder
edt_update Mask Hold Register
edt_mask
. Mask Shift Register
edt_clock

May 2007
IP Specification

May 2007
Appendix C
Troubleshooting
This appendix is divided into three parts. The first part, “Debugging Simulation Mismatches,”
lists some TestKompress-specific aspects of debugging simulation mismatches that you may
already be familiar with from past ATPG experience. The second part, “Resolving DRC
Issues,” contains some explanation (and examples where applicable) of causes of EDT-specific
design rule violations and possible solutions. The “Miscellaneous” section covers a few topics
that are unrelated to simulation mismatches or DRC.
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 the “Debugging
Simulation Mismatches in FastScan” section of the Scan and ATPG Process Guide, 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.

May 2007
Troubleshooting
Debugging Simulation Mismatches
Figure C-1. Flow for Debugging Simulation Mismatches
Start
Any K19 Debug K19 thru K22

thru K22 DRC Y DRC violations.
violations?
EDT Use TestKompress to Debug with FastScan

Parallel patterns Y
debug. or using EDT bypass
Fail? patterns. Problem is
likely in capture.
N
Bypass Debug chain problems

Serial Chain Y with FastScan.
Test Fails?
EDT Focus on Interface

Serial Chain logic between EDT
Y
Test Fails? logic and scan cells.
Contact
customer support.
If the core design is the source of the mismatch, then you can use traditional ATPG
troubleshooting methods in FastScan to pinpoint the problem. This entails saving EDT bypass
patterns from TestKompress, which you then process and simulate in FastScan with the design
configured to operate in bypass mode. Alternatively, you can invoke FastScan on the circuit
(configured to run in bypass mode) and generate another set of patterns. For more information,
refer to “Bypassing EDT Logic” in Chapter 7.

May 2007
Troubleshooting
Resolving DRC Issues

“Design Rules Checking” in the Design-For-Test Common Resources Manual provides full
descriptions of the EDT-specific “K” rules. This section supplements that information with
some suggestions to help you reduce the occurrence of certain DRC violations.
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.
TestKompress 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 will transcript 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 TestKompress.
The message then lists specifics about instance(s) and/or pin pathname(s) 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.
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

May 2007
Troubleshooting
TestKompress created in the EDT logic hierarchy. For additional information about the
synthesis step, refer to “Synthesizing a Netlist with the EDT Logic” on page 98.
Debugging Best Practices

For most common K19 and K22 debug tasks, if you want to report gate simulation values, it is
often sufficient to issue the Set Gate Report command with the Drc_pattern argument.
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 Report Gates command (or DFTVisualizer) displays
gate simulation data for different procedures in the test procedure file. For more information on
the use of Drc_pattern reporting, refer to “State Stability Reporting” in the Scan and ATPG
Process Guide.
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 K19 or K22 argument while in Setup
mode.
Tip: Use Set Gate Report with the K19 or K22 argument only when necessary. Because
the tool has to log simulation data for all simulated setup and shift cycles, Set Gate Report
K19/K22 reporting can slow EDT DRC run time and increase memory usage compared
to Set Gate Report Drc_pattern reporting.
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” on page 216

“Understanding K22 Rule Violations” on page 227
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

May 2007
Troubleshooting
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

Data Flow
8 7 6 5 4 3 2 1
Internal Nodes (optional)
Bypass (optional)
Decompressor
Primary Inputs
EDT Core
1: Core chain <index> first cell

2: Core chain <index> input
3: Core chain <index> input driver
4: EDT module chain <index> input (source)
5: EDT decompressor chain <index> output
6: EDT module channel <index> input
7: Channel <index> input internal node
8: Channel <index> input pin
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

May 2007
Troubleshooting
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. Figure 6-4 and the explanation accompanying it detail
why TestKompress emulates this 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 will display 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 TestKompress simulates the flattened netlist and does not model the
hierarchical module pins, the tool reports the gate driving the EDT module’s output.
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.

May 2007
Troubleshooting
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’s name or pin names are
changed during synthesis, TestKompress will no longer be able to identify the EDT module and
its pins.
Tip: Preserving the EDT module during synthesis allows for 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 eight 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 following sections:
Incorrect Control Signals

Inverted Signals
Incorrect EDT Channel Signal Order
Incorrect Scan Chain Order
X Generated by EDT Decompressor
Using Set Gate Report K19

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.
If K19 detects incorrect values on an EDT control signal, the tool will issue a message similar to
this 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

May 2007
Troubleshooting
during load_unload and shift (see Figure 6-2), 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
// /edt_bypass primary_input
// edt_bypass O (0001) /cpu_bypass_logic_i/ix23/S0...
scan_group grp1;
timeplate gen_tp1;
cycle =
force clear 0 ;
force edt_update 1;
timeplate gen_tp1 = force edt_clock 0;
force_pi 0; force edt_bypass 0;
measure_po 10; force scan_en 1;
pulse tclk 20 10; pulse tclk 0;
pulse edt_clock 20 10; pulse edt_clock;
period 40; end;
end; apply shift 22;
end;
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. You can use the following commands to confirm:

May 2007
Troubleshooting
set gate report drc_pattern shift

report gate /edt_bypass
// /edt_bypass primary_input
// edt_bypass O (111) /cpu_bypass_logic_i/ix23/S0...
procedure shift =
scan_group grp1;
timeplate gen_tp1;
cycle =
timeplate gen_tp1 = force_sci;
force_pi 0; force edt_bypass 1;
measure_po 10; force edt_update 0;
pulse tclk 20 10; measure_sco;
pulse edt_clock 20 10; pulse tclk;
period 40; pulse edt_clock;
end; end;
end;
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 which mentions the same control
signal and describes an error in the shift procedure. A glance at Figure 6-2 shows the EDT
update 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):

May 2007
Troubleshooting
set gate report drc_pattern shift

report gate /edt_update
// /edt_update primary_input
// edt_update O (111) /cpu_bypass_logic_i/ix23/S0...
procedure shift =
scan_group grp1;
timeplate gen_tp1;
cycle =
timeplate gen_tp1 = force_sci;
force_pi 0; force edt_update 1;
measure_po 10; measure_sco;
pulse tclk 20 10; pulse tclk;
pulse edt_clock 20 10; pulse edt_clock;
period 40; end;
end; end;
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
TestKompress enables you to 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 will generate incorrect data and the K19 rule check will
transcript a message similar to this:
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

// /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

May 2007
Troubleshooting
// 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
//

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
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).

May 2007
Troubleshooting
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.

TestKompress 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, then adding it back again with Add Scan Chains, will change 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 will issue 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 in the IP Creation
Phase. For example:
report scan chains

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 TestKompress-
generated dofile:
//
// Written by TestKompress v8.2004_1.10 on Tue Dec 14 15:18:41 2004
//
// name.

May 2007
Troubleshooting
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

...
or exit the tool, correct the order of Add Scan Chains commands in the dofile and start the tool
with the corrected dofile.

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.

May 2007
Troubleshooting
• 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?
In TestKompress, 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 ModelSim. In order to do that, ignore
failing K19 DRCs by issuing a “set drc handling k19 ignore” command. Next, generate three
random patterns in Atpg system mode and save the patterns as serial Verilog patterns. Then
simulate the circuit with an HDL simulator and analyze the signals of interest.

If you issue a Set Gate Report command with the K19 argument prior to DRC, 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 K19 argument also has several options that enable you to
limit the content of the displayed data.
Tip: Use Set Gate Report with the K19 argument only when necessary. Because the tool
has to log simulation data for all simulated setup and shift cycles, Set Gate Report K19
reporting can slow EDT DRC run time and increase memory usage compared to Set Gate
Report Drc_pattern reporting.
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 216):
set gate report k19

// Warning: Data will be accessible after running DRC.

...
Erroneous bits 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
...
report gates 7021

May 2007
Troubleshooting
// /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: ts ld_u sh 1 sh 2 sh 3 sh 4 sh 5 sh 6... cap
// ----- -- ---- ---- ---- ---- ---- ---- ---- ---
// Time: i 234 123 123 123 123 123 123... o o
// n0 0000 0000 0000 0000 0000 0000 0000... fXf
// ----- -- ---- ---- ---- ---- ---- ---- ---- ---
// Sim: XX XXXX XX00 0001 0011 0010 1110 1111... XXX
// Emu: -- ---- ---0 ---0 ---1 ---1 ---1 ---0... ---
// Mism: * * * *
// Monitor: core chain 1 first cell.
//
// Inputs:
// S 00 0000 0000 0000 0000 0000 0000 0000... 0X0
// R 00 0000 0000 0000 0000 0000 0000 0000... 0X0
// CLK X0 0000 0010 0010 0010 0010 0010 0010... 0X0
// DO XX XXXX XX00 0001 0011 0010 1110 1111... XXX
You can see from this report the effect that each event in each shift cycle had on the gate’s value
during simulation. The time numbers (read vertically) indicate the relative time that events
occurred within each cycle, as determined from the procedure file. If the gate is one used by the
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 matches the simulated value. Also, the
last line of the report 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.
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.

May 2007
Troubleshooting
Figure C-3. Order of Diagnostic Checks by the K22 DRC

Data Flow
2 5 6
Internal Nodes (optional)
Primary Outputs
Bypass (optional)
Compactor
Core EDT
Decoder
1 3 4
1: Core chain <index> output

2: EDT module chain <index> output (sink)
3: EDT compactor channel <index> output
4: EDT module channel <index> output
5: Channel <index> output internal node
6: Channel <index> output pin
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, TestKompress next checks the data at the inputs of
the EDT 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).

May 2007
Troubleshooting
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 TestKompress 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) 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.
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, TestKompress will no longer be able to identify the EDT module and
its pins.
Note
Preserving the EDT module during synthesis allows for 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 the section, “Understanding K19
Rule Violations” on page 216.
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 the section, “Understanding

May 2007
Troubleshooting
K19 Rule Violations,” is good background information for K22 rule violations. Examples of
some specific K19 problems, with example debugging steps, are detailed in these sections:

Inverted Signals
Some specific K22 problems, with example debugging steps, are detailed in the following
sections:
Inverted Signals
Masking Problems
Inverted Signals
TestKompress enables you to 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, the compactor
will generate incorrect data and the K22 rule check will transcript a message similar to this (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

May 2007
Troubleshooting

(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
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
//

May 2007
Troubleshooting

TestKompress 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 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, then adding it again with Add Scan Chains, will change 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 will issue 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).
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 in the IP Creation
Phase. 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 TestKompress-generated dofile:
//
// Written by TestKompress v8.2004_5.10 on Tue Dec 14 15:18:41 2004
//
// name.

May 2007
Troubleshooting
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.
Note
When the tool is set up to treat K19 violations as errors, the invocation default, incorrect
scan chain order will be detected by the K19 rule check, since the tool performs K19
checks before K22. (See “Incorrect Scan Chain Order” in the K19 section for example
tool messages). In this case, the tool will stop 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:

May 2007
Troubleshooting
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)
// "I0" I ( X)(XXX)(XXX~X)(XXX) 294-
// B0 I ( X)(XXX)(XXX~X)(XXX) 291- …/decoder1/ix107/Y
// Y O ( X)(XXX)(XXX~X)(XXX) 419- …/ix41/A1
b
// /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63 (294) OR
// A0 I ( X)(XXX)(XXX~X)(XXX) 208- …/reg_masks_hold_reg_0_/Q
// A1 I ( X)(XXX)(XXX~X)(XXX) 214- …/reg_masks_hold_reg_1_/Q
// "OUT" O ( X)(XXX)(XXX~X)(XXX) 343-
b
// /cpu_edt_i/cpu_edt_compactor_i/reg_masks_hold_reg_0_ (208) BUF
// "I0" I ( X)(XXX)(XXX~X)(XXX) 538-
// Q O ( X)(XXX)(XXX~X)(XXX) 235- …/ix102/A0
// 292- …/decoder1/ix57/A0
// 293- …/decoder1/ix113/A
// 346- …/decoder1/ix61/A0
// 294- …/decoder1/ix63/A0
b
// /cpu_edt_i/cpu_edt_compactor_i/reg_masks_hold_reg_0_ (538) DFF
// "S" I ( 0)(000)(000~0)(000) 48-
// "R" I ( 0)(000)(000~0)(000) 150-
// CLK I ( 0)(000)(000~0)(000) 47-
// D I ( X)(XXX)(XXX~X)(XXX) 235- …/ix102/Y
// "OUT" O ( X)(XXX)(XXX~X)(XXX) 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) 541- …/reg_masks_hold_reg_1_/CLK
// 540- …/reg_masks_shift_reg_1_/CLK
// 538- …/reg_masks_hold_reg_0_/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:

May 2007
Troubleshooting
Miscellaneous
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
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 K22 argument similar to the K19 argument described in
“Using Set Gate Report K19” on page 226. If you issue the command prior to DRC, you can use
“report gates” to view the simulated values for the entire sequence of events in the test
procedure file for any K22-simulated gate. Like the K19 argument, the K22 argument also has
several options that enable you to limit the content of the displayed data.
Tip: Use Set Gate Report with the K22 argument only when necessary. Because the tool
has to log simulation data for all simulated setup and shift cycles, “set gate report k22”
reporting can slow EDT DRC run time and increase memory usage compared to “set gate
report drc_pattern” reporting.
Miscellaneous
Incorrect References to \**TSGEN** in Synthesized Netlist
After you run Design Compiler to synthesize the netlist and verify that no errors occurred,
check that tri-state buffers were correctly synthesized. For certain technologies, Design

May 2007
Troubleshooting
Miscellaneous
Compiler is unable to correctly synthesize tri-state buffers and inserts an incorrect reference to
“\**TSGEN**” instead. You can run the UNIX 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
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 will no longer be an X
generator in ATPG mode.
If no Xs are captured on the scan chains, usually no fault effects are lost due to the compactors
and TestKompress 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 (Extra Rule #5) identifies sources of observable
Xs.
One clue 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 will (ideally) be 32 for 32-bit invocations and

May 2007
Troubleshooting
Miscellaneous
64 for 64-bit invocations. Numbers significantly lower indicate Xs are reducing test
effectiveness. This is confirmed if the number of effective patterns rises significantly when
TestKompress uses masking to block the observable Xs. This is shown in the following excerpt
from the transcript for a 32-bit invocation run:
// #patterns test #faults #faults # eff. # test

// simulated cvrg in list detected patterns patterns
// deterministic ATPG invoked with abort limit 30
// EDT without scan masking. Dynamic compaction enabled.
...
// --- ------ --- --- --- ---
// 608 61.51% 3301 58 17 93
// --- ------ --- --- --- ---
// 640 63.17% 3249 52 14 107
// --- ------ --- --- --- ---
// 672 65.63% 3211 38 18 125
// --- ------ --- --- --- ---
// Warning: Unsuccessful test for 972 faults.
// EDT with scan masking. Dynamic compaction disabled.
// 736 82.06% 2007 638 32 157
// --- ------ --- --- --- ---
// 768 84.42% 1638 369 32 189
// --- ------ --- --- --- ---
// 800 86.16% 1221 417 32 221
// --- ------ --- --- --- ---
...
Applying Incompressible Patterns Thru Bypass Mode

Occasionally, TestKompress will generate an effective pattern that cannot be compressed using
EDT technology. Although it 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 hardware, which reconfigures the scan chains
into fewer, longer scan chains. This requires a separate ATPG run on the remaining faults with
a traditional ATPG tool such as FastScan.
Note
You can use bypass mode to apply patterns generated with tools other than TestKompress
(FastScan, for example). You can also use bypass mode for system debugging purposes.
Independent Shift Limitation of VHDL Parallel Patterns

EDT does not currently support VHDL parallel simulation patterns with independent shifts
(post shifts). This applies to independent shifts that are present in the test procedure (to support
boundary scan, for example), or added by the tool. If you attempt to save VHDL parallel
patterns that use independent shifts, TestKompress transcripts an error message.

May 2007
Troubleshooting
Miscellaneous
The reason for this restriction is that the test bench must be able to force the scan chain input
pins when applying independent shifts. Those pins are primary inputs in traditional ATPG, but
in EDT they are internal nodes, driven by the decompressor. The Verilog test bench can force
the internal scan pins when needed, but the VHDL test bench cannot.
Note
The tool identifies certain types of shadow cells that require one post shift for correct
loading during parallel pattern simulation, and automatically includes that post shift in
the generated patterns. To disable the tool’s identification of these types of shadow cells,
use the “set shadow check restricted” command. This will enable you to save the patterns.
Be aware, however, that this can lower test coverage.
If EDT Compression is Less Than Expected

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
If there are many observable Xs, you will probably see a much higher runtime compared
to FastScan. You will probably also see a much lower number of effective patterns
reported in the transcript when TestKompress is not using scan chain masking, compared
to when the tool is using masking.
The Chapter 7 section, “Resolving X Blocking with Scan Chain Masking,” 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” earlier in this chapter.
• EDT Aborted Faults—For information about these types of faults, refer to “If there are
EDT aborted faults” in the next section.
• If there are no EDT aborted faults, try a more aggressive compression configuration by
increasing the number of scan chains.

May 2007
Troubleshooting
Miscellaneous
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, using FastScan. If the test coverage with EDT is less than you obtain
with FastScan, the following sections list steps you can take to raise it to the same level as
traditional FastScan ATPG:
If there are EDT aborted faults

When TestKompress generates an effective fault test, but is unable to compress the pattern, the
fault is classified as an EDT aborted fault. TestKompress issues a warning 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 “Avoiding Sharing Scan
Chain Pins with Functional Pins” in Chapter 3 for additional information.

May 2007
Troubleshooting
Miscellaneous

May 2007
Glossary
Bypass Circuitry
Additional logic circuitry that TestKompress includes in the EDT logic when you use the
-Bypass_logic On option with the Set EDT command. If you include bypass logic, you
optionally can run the circuit in bypass mode to perform regular ATPG if you want. See also
Bypass Mode.
Bypass Mode
When the EDT logic includes bypass circuitry, bypass mode is when the bypass circuitry
concatenates the internal scan chains into fewer, longer scan chains, bypassing the EDT
circuitry. Bypass mode thus enables you to run regular ATPG. See Bypass Circuitry.
Chain-to-channel Ratio
The ratio of the number of scan chains in the design core to the number of channels (“virtual”
scan chains) the EDT logic presents to the tester. The latter must be the same as the number of
tester channels, so is usually fixed.
Channel
Refer to Scan Channel.
Compactor
Refer to Spacial Compactor.
Compactor Group
In the compactor 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.
Compactor Stage
A single level of logic (XOR gates) in the Spacial Compactor. Each spatial compactor is
comprised of one or more compactor stages. See also First Compactor Stage.
Compression
Refer to Effective Compression.
Current EDT Block

The EDT block that is the sole target of context-sensitive commands in the top-level Pattern
Generation Phase of a modular TestKompress flow. See Chapter 8, “Modular TestKompress,”
for more information.
Core
The original design without boundary scan or I/O pads, to which you add EDT technology.

May 2007
Glossary
Decompressor
The component of the EDT logic that converts EDT-compressed patterns into normal scan
patterns and applies them to the scan-inserted design core.
EDT
The trademark representing the Embedded Deterministic Test technology developed by Mentor
Graphics. See also Embedded Deterministic Test Technology.
EDT Block
A design block in a modular TestKompress design that implements a full complement of the
EDT hardware (decompressor, compactor, and optionally bypass logic). It is not necessarily a
module (entity) in the HDL, but rather is a decompressor/compactor/core group. An EDT block’s
EDT hardware drives all the scan chains within the block. See Chapter 8,
“Modular TestKompress,” for more information.
EDT Logic
The hardware synthesized into a design to implement the Mentor Graphics EDT technology.
This hardware consists of two main components: A “decompressor” and a “compactor.”
EDT Logic Creation Phase

The part of the EDT flow in which you create and insert EDT logic into a design. You must
complete this phase before you insert boundary scan or I/O pads. See also Pattern Generation
Phase.
EDT Patterns
The compressed patterns generated by TestKompress.
Effective Compression
The ratio of the tester memory required with ATPG to the tester memory required with EDT. See
“Comparing EDT and Traditional ATPG” on page 21 for an example calculation of effective
compression.
Embedded Deterministic Test Technology

The technology developed and patented by Mentor Graphics that uses on-chip hardware to allow
highly compressed data to be applied to a circuit under test (CUT) without being decompressed
first by the tester (ATE).
First Compactor Stage

The Compactor Stage closest to the scan chains.
Internal Scan Chain

Refer to Scan Chain.
IP Version
The version of the EDT hardware architecture. This is different than the software version of the
tool. A newer version of TestKompress, in which only the kernel is updated but the architecture
of the EDT logic it generates is the same as before, will have the same IP version number. Only
the software version would increment.

May 2007
Glossary
Joint Test Action Group (JTAG)

The committee that formulated IEEE standard 1149.1 describing boundary scan.
JTAG
Refer to Joint Test Action Group (JTAG).
Pattern Generation Phase

The part of the EDT flow in which you generate and verify EDT patterns. Occurs after you
synthesize the design including the EDT logic, I/O pads and optionally boundary scan. See
also EDT Logic Creation Phase.
Pin Sharing
Refers to functional pins shared with the decompressor inputs and compactor outputs.
Pipeline Stages (Channel)

Pipeline stages you insert outside the EDT logic, between top level pins/pads and EDT channel
inputs and outputs, to improve signal propagation time. For more information, see
“Using Pipeline Stages Between Pads and Channel Inputs or Outputs” on page 129.
Pipeline Stages (Compactor)

Flip-flops (clocked by the leading edge of the EDT clock) that TestKompress optionally inserts
in the spacial compactor to improve the overall rate of data transfer through the compactor logic.
For more information, see “Using Pipeline Stages in the EDT Compactor” on page 128.
Scan Chain
A scan chain that is inside the core design; an internal scan chain.
Scan Chain Masking

The mechanism whereby TestKompress records the actual measured value for each cell in a
specific scan chain in a compactor group, and changes the values to all Xs in all other chains in
the group, enabling the tool to observe the specific scan chain.
Scan Channel
A “virtual” scan chain that a chip incorporating EDT technology provides as the input/output
interface to a channel of a tester. A chip design may include more than one scan channel, based
upon the number of channels available on the ATE, that will be used to test the chip.
Shared EDT Pin

An EDT decompressor input or EDT compactor output that, rather than being a dedicated EDT
pin, is shared with a functional pin.
Spacial Compactor
The part of the EDT logic that converts the outputs of a collection of internal scan chains into
one external scan channel output. In addition to the compaction in the number of scan chain
outputs, the conversion reduces the need for space that would otherwise be required to route
multiple scan chain outputs.

May 2007
Glossary
X Blocking
The X recorded by the tool in the pattern file in every position made unmeasurable as a result of
the occurrence of an X in the corresponding cell of a different scan chain in the same compactor
group.

May 2007
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
— Symbols — pre-existing, 48
.gz, 32 prerequisites, 96
.Z, 32 synthesis, preparing for, 123
top level wrapper for, 97
—A— Built-in self-test, 13
Add edt block command, 155, 167, 173, 186, Bypass circuitry, 16, 27, 78
189 customizing, 72
Add scan chains -internal, 74, 88, 89, 103 diagram, 116
Advanced topics, 115 including, 62
Architecture, EDT, 16, 63 Bypass mode
ATE circuitry, 116
memory map for ATPG and EDT patterns, generated files for, 91
26 introduction, 26, 27
memory requirements Bypass patterns, EDT
estimating, 23 to 26 flow example, 118
number of channels and, 23 using, 118
number of patterns and, 23 Bypassing EDT logic, 115 to 121
number of shifts and, 23
memory, handling limits of, 12, 13 —C—
ATPG Chain and IP test, enhanced, 105
compared with EDT, 21 to 27 Chain-to-channel ratio
Automatic test equipment, see ATE definition of, 15
effective compression and, 15
—B— Channel input pipeline stages
Batch mode, 31 defining, 129
Boundary scan Channel output pipeline stages
BSDArchitect defining, 129
description, 97 Channel, see Scan Channel
documentation, 96 Clocking in EDT, 21
invoking, 122 Commands
modifying BSDArchitect output, 122 interrupting, 33
circuitry, 97 running UNIX system, 32
EDT and, 121 to 128 Compactor, see Spacial compactor
EDT coexisting with, 122 to 126 Compress files
EDT signals driven by, 126 to 128 .gz filename extension to, 32
flow overview, 121 .Z filename extension to, 32
inserting, 96, 122 set file compression command, 32
modifying EDT dofile for, 49, 124 set gzip options command, 33
modifying EDT test procedure file for, 49, Compression, see Effective Compression
124 Conserve disk space

May 2007 DRAFT 5/8/07
UNIX utilities to, 32 Design rules checks

Control and channel pins EDT-specific rules (K rules), 29
basic configuration, 64 introduction, 29
default configuration, 65, 66 TIE-X message, 74
sharing with functional pins, 66 to 71 transcript messages, 74
channel input pin, 67 upon leaving setup mode, 73
channel output pin, 67 verifying EDT IP operation with, 104
defining, 69 DFTAdvisor
EDT bypass pin, 68 dofile for inserting scan chains, example,
EDT clock pin, 67 53
EDT reset pin, 63, 68 insert test logic command, 51, 53, 54
EDT scan enable pin, 68 Diagnostics, 23
EDT update pin, 68 Documentation, EDT-specific
example, 68 EDT Process Guide, 11
reporting, 69 Dofile
requirements, 66 for bypass mode (plain ATPG), 91, 104
summary, 64 for creating EDT intellectual property, 59
create_skeleton_design, 191 for generating EDT patterns, 63, 88, 103
flow, 191, 192 for inserting scan chains, 53
input file, 194 Dofiles, 31
example, 196 merging for modular EDT, 173
inputs, 194
inputs and outputs, 193, 194 —E—
interface file, 197, 201 EDT
outputs, 194, 202 as extension of ATPG, 12
skeleton design, 202 clocking scheme, 21
skeleton design ATPG library, 205 compared with FastScan ATPG, 21 to 27
skeleton design dofile, 204 compression, see Effective compression
skeleton design test procedure file, 205 configuration, reporting, 64
usage, 197 control and channel pins, see Control and
channel pins
—D— definition of, 12, 242
Decompress files design flow, see Design flow, EDT
.gz filename extension to, 32 diagnostics
.Z filename extension to, 32 flow example, 118
Decompressor, 16, 17, 27, 78, 242 with EDT bypass patterns, 118
Delete edt blocks command, 168, 174, 189 documentation, see Documentation, EDT-
Design Compiler synthesis script, 79, 95 specific
Design flow, EDT EDT bypass patterns, 118
design requirements, 39, 58 EDT internal patterns, 111, 112
FastScan and, 55 example, 21 to 26
introduction, 35 to 39 extra initialization cycles, 24
steps, 40 to 41, 43 to 44 fundamentals, 12 to 17
tasks and products, 36, 37 generating EDT test patterns, see Pattern
Design input format, 39 generation phase
Design requirements, 39 I/O pads and, 39

DRAFT 5/8/07 May 2007
logic command-line mode, emulating with

conceptual diagram, 16, 157 TestKompress, 18, 41, 43, 55, 58,
impact on core design, 27 59
MacroTest and, 26 creating bypass patterns, 120
modular TestKompress, 153 EDT design flow and, 55
pattern generation, see Pattern generation Fault aliasing, 150
phase Fault sampling, 143
pattern size, 54 Faults, supported, 26
pattern types supported, 26 File compression, decompression
pin sharing, 27 .gz extension, 32
scan channels, see Scan channels .Z extension, 32
signals set file compression command, 32
bypass, see Pattern generation phase set gzip options command, 33
clock, see Pattern generation phase Filename extensions
internal control of, 30 .gz, 32
reset, 63 .Z, 32
update, see Pattern generation phase
EDT internal patterns, 111, 112 —G—
EDT logic Generated EDT IP files, see Intellectual
creating, 57 property (IP)
EDT reset signal Generated files, 76 to 92
specifying, 63 black box description of core, 79
Effective compression described, 76
chain-to-channel ratio and, 15, 239 edt circuitry, 78
controlling, 30, 54 for bypass mode (plain ATPG)
definition of, 24 dofile, 91, 104
estimating, 92 enhanced procedure file, 104
example, 21 to 26 test procedure file, 91
traditional ATPG compression and, 21 to for use in EDT pattern generation phase
26 dofile, 88, 103
Embedded deterministic test, see EDT enhanced procedure file, 103
Enhanced chain and IP test, 105 test procedure file, 89
Enhanced procedure file modular EDT
for bypass mode (plain ATPG), 104 merging dofiles, 173
for generating EDT patterns, 103 synthesis script, 79, 80, 95
Estimating top-level wrapper, 77
effective compression, 92 Generating EDT test patterns, see Pattern
test coverage, 92 generation phase
Exiting the tool, 33 —I—
External IP location flow I/O pads
definition of, 28 adding, 97
steps, 41 managing pre-existing, 48
tasks and products, 36 requirements, 39
—F— I/O pins, usage, 17
FastScan Insert test logic -output new, 51, 53

May 2007 DRAFT 5/8/07
Intellectual property (IP) tasks and products, 37

blocks using a reduced netlist with, 86
detailed description of, 76 to 79, 209 to Interrupting commands, 33
211 IP creation phase
integrating in design, 27 to 29 in EDT design flow, 41, 43
bypass circuitry, see Bypass circuitry introduction, 16, 38
components of, 29 pattern generation in, 92
configuration, 63 IP location
architecture, 63 external, 28
bypass circuitry, 62 internal, 28
latch-based IP, 62
lockup cells, 62 —L—
pipeline stages, 62 Latch-based IP
creating, 16, 18, 75 specifying, 62
decompressor, see Decompressor Length of longest scan chain
definition of, 16 specifying, 63
files Lockup cells
black box description of core, 79 including, 62
edt circuitry, 78 insertion, 134 to 142
list, 75 reporting, 134
summary, 75 Log files, 32
top-level wrapper, 28, 77 —M—
format of, 39 Masking, see Scan chains, masking
generated files, see files Memories
overview, ?? to 17, 27 to 30 handling of, 22, 35, 236
parameters, 61 non-scan cells and, 22
RTL description of, 75 X values and, 146, 236
scan architectures supported, 21, 40, 50 Memory requirements, ATE, see ATE memory
setting up TestKompress to create, 60 requirements
size of, 29 Modular TestKompress, 153
spatial compactor, see Spatial compactor
specification, 209 —P—
synthesizing Pattern generation phase, 101 to 111
Design Compiler and, 98 adding scan chains, 102
overview, 95 circuitry in, 109
preparation, 96 EDT signals, controlling
TestKompress and, 18 bypass, 102
verifying operation of, 104 to 108 clock, 102
chain and IP test, 105 update, 102
design rules checks, 104 generating EDT patterns, 108 to 110
version of, specifying, 63 in EDT design flow, 41, 44, 101
wrapper for, 28 introduction, 16, 38
Internal IP location flow optimizing compression, 110
definition of, 28 pattern post-processing, 111
steps, 43 prerequisites, 102 to 103

DRAFT 5/8/07 May 2007
reordering patterns, 151 Reporting the EDT configuration, 64

setting up TestKompress, 102 Reset bypass chains command, 73
simulating EDT patterns, 112 Reset compactor connections command, 73
test procedure waveforms, example, 102 Reset signal, 63
verifying EDT patterns, 101, 112 to 113
Pattern generation, see Pattern generation —S—
phase Scan architectures supported, 21, 40, 50
Pattern verification, 54 Scan chains
Patterns chain-to-channel ratio and, 15
reordering, see Pattern generation phase, determining how many to use, 51
reordering patterns grouping requirement, 51
types supported, 22, 26 length
Performance equation for, 13
establishing a reference point, 143 longest, specifying range for, 63
evaluating, 142 to 146 limitations on, 49, 77
evaluation flow, 142 masking, 146 to 149
improving, 144 pattern file example, 149
issues and analysis summary, 144 transcript example, 148
measuring, 144 why needed, 146
Pin sharing, 27 X blocking and, 147
allowed, 52, 66, 77 prerequisites for inserting, 49
not allowed, 51, 77 reordering
Pipeline stages impact on EDT IP, 52, 76
description of, 128 impact on EDT patterns, 109
including, 62, 128 scan and functional pin sharing, avoiding,
Pre-synthesis flow, 191 51
synthesizing, 47, 49
—R— uncompressed
Reduced netlist defining for EDT pattern generation,
role in Internal IP location flow, 86 89, 103, 158
using to improve synthesis run time, 86 effect on test coverage estimate, 50
writing, 76, 86 including, 50, 89, 103
Reorder leaving undefined during IP creation,
patterns, see Pattern generation phase, 50
reordering patterns modular flow and, 158
scan chains, see Scan chains, reordering setting up, 60
Report bypass chains command, 73 Scan channels
Report compactor connections command, 73 chain-to-channel ratio and, 15
Report drc rules command, 67 conceptual diagram, 15
Report edt blocks command, 168, 174, 189 controlling compression with, 15
Report edt configuration command, 64, 75, definition of, 15
104, 187, 188, 189 introduction, 14
Report edt instances command, 189, 215 pins, sharing with functional pins, 52, 66,
Report edt lockup_cells command, 134 67
Report edt pins command, 65, 69, 72 Scan group
Report scan volume command, 54, 55, 109 requirement, 51

May 2007 DRAFT 5/8/07
Scripts, 31 report edt configuration, 64, 75, 104,

Set bypass chains command, 72 187, 188, 189
Set compactor connections command, 73 report edt instances, 189, 215
Set Current block command, 173, 184 report edt lockup_cells, 134
Set current block command, 189 report edt pins, 65, 69, 72
Set edt command, 59 to 63 report environment, 60
Set edt instances command, 88, 172, 186, 189, report scan volume, 54, 55, 109
215 reset bypass chains, 73
Set edt mapping command, 186 reset compactor connections, 73
Set edt pins command, 66, 69 set bypass chains, 72
Shell commands, running UNIX commands, set compactor connections, 73
32 set current block, 173, 184, 189
Skeleton flow, 191 set dofile abort, 32
Spacial compactor set edt, 59 to 63
connections, customizing, 73 set edt instances, 88, 172, 186, 189, 215
Spatial compactor, 17, 27, 78, 243 set edt mapping, 186
Supported pattern types, 22 set edt pins, 66, 69, 77
Synthesizing set file compression, 32
EDT IP, see Intellectual property (IP), set gzip options, 33
synthesizing set logfile handling, 32
scan chains, 47 write edt files, 75, 189
with a reduced netlist, 86 see also ATPG and Failure Diagnosis
Tools Reference Manual
—T— creating EDT logic with, 57
Test coverage creating intellectual property with, 41, 43
estimating, 92 default flows, 35 to 44
Test cycles, 13, 23 emulating FastScan with, 18, 41, 43, 55, 58
Test data volume, 13, 14, 23, 143 generating EDT patterns with, 41, 44
Test procedure file inputs and outputs, 44
for bypass mode (plain ATPG), 91 external flow, 42
for generating EDT patterns, 89 internal flow, 44
Test time, 13, 14 invoking, 58
Tester, see ATE modular flow, 153
TestKompress pre-synthesis flow, 191
ATPG library, 31 setting up to create IP, 60
capabilities skeleton flow, 191
summary, 18 tool flows
commands external IP, 28, 41
add edt block, 155, 167, 173, 186, 189 internal IP, 28, 43
add scan chains, 74, 89, 103 user interface, 31
delete edt blocks, 168, 174, 189 Tools used in EDT flow, 36, 37
report bypass chains, 73 Troubleshooting, 213 to 239
report compactor connections, 73 EDT aborted faults, 239
report drc rules, 67 incompressible patterns, 237
report edt blocks, 168, 174, 184, 189

DRAFT 5/8/07 May 2007
independent shifts and VHDL parallel

patterns, 237
K19 through K22 DRC violations, 215 to
219, ?? to 230
less than expected
compression, 238
test coverage, 239
lockup cells in EDT IP, reporting, 134
simulation mismatches, 213, 214
too many observable Xs, 236
TSGEN, incorrect references to, 99, 235
—U—
UNIX commands, running within tool, 32
Unknown states, spatial compactor and, 17, 27
User interface
dofiles, 31
exiting, 33
interrupting commands, 33
log files, 32
running UNIX system commands, 32
—V—
Verification of EDT IP, 104 to 108
Verification of EDT patterns, 101, 112 to 113
—W—
Write edt files command, 75, 189
—X—
X blocking, 147
Xs, observable, 236

May 2007 DRAFT 5/8/07

DRAFT 5/8/07 May 2007
Third-Party Information
This section provides information on open source and third-party software that may be included in Design-for-Test software
products.
• •This software application may include GTK 2.6.1 third-party software and may be subject to the following copyright(s)
and/or use terms:
Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd and Clark Cooper
Copyright (c) 2001, 2002 Expat maintainers.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
**********************************************************************
Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.
Development of this software was funded, in part, by Cray Research Inc.,
UUNET Communications Services Inc., Sun Microsystems Inc., and Scriptics
Corporation, none of whom are responsible for the results. The author
thanks all of them.
Redistribution and use in source and binary forms -- with or without
modification -- are permitted for any purpose, provided that
redistributions in source form retain this entire copyright notice and

indicate the origin and nature of any modifications.
I'd appreciate being given credit for this package in the documentation
of software which uses it, but that is not a requirement.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
HENRY SPENCER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
**********************************************************************
wxWindows adopted the code out of Tcl 8.4.5. Portions of regc_locale.c
and re_syntax.n were developed by Tcl developers other than Henry Spencer;
these files bear the Tcl copyright and license notice:
**********************************************************************
This software is copyrighted by the Regents of the University of
California, Sun Microsystems, Inc., Scriptics Corporation, ActiveState
Corporation and other parties. The following terms apply to all files
associated with the software unless explicitly disclaimed in
individual files.
The authors hereby grant permission to use, copy, modify, distribute,

and license this software and its documentation for any purpose, provided
that existing copyright notices are retained in all copies and that this
notice is included verbatim in any distributions. No written agreement,
license, or royalty fee is required for any of the authorized uses.
Modifications to this software may be copyrighted by their authors
and need not follow the licensing terms described here, provided that
the new terms are clearly indicated on the first page of each file where
they apply.
IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY
DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE
IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE
NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
MODIFICATIONS.
GOVERNMENT USE: If you are acquiring this software on behalf of the
U.S. government, the Government shall have only "Restricted Rights"
in the software and related documentation as defined in the Federal
Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2). If you
are acquiring the software on behalf of the Department of Defense, the
software shall be classified as "Commercial Computer Software" and the
Government shall have only "Restricted Rights" as defined in Clause
252.227-7013 (c) (1) of DFARs. Notwithstanding the foregoing, the
authors grant the U.S. Government and others acting in its behalf
permission to use and distribute the software in accordance with the
terms specified in this license.
**********************************************************************
The wxWindows license applies to further modifications to regcustom.h
and regc_locale.c.
****************************************************************************
-----------------------------------------------------
License for Scintilla and SciTE
Copyright 1998-2003 by Neil Hodgson <neilh@scintilla.org>
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation.
NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE
OR PERFORMANCE OF THIS SOFTWARE.

-----------------------------------------------------
Copyright (c) 1988-1997 Sam Leffler
Copyright (c) 1991-1997 Silicon Graphics, Inc.
Permission to use, copy, modify, distribute, and sell this software and
its documentation for any purpose is hereby granted without fee, provided
that (i) the above copyright notices and this permission notice appear in
all copies of the software and related documentation, and (ii) the names of
Sam Leffler and Silicon Graphics may not be used in any advertising or
publicity relating to the software without the specific, prior written
permission of Sam Leffler and Silicon Graphics.
THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND,
EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR
ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND,
OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF
LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
OF THIS SOFTWARE.
-----------------------------------------------------
(C) 1995-2004 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler
jloup@gzip.org madler@alumni.caltech.edu
If you use the zlib library in a product, we would appreciate *not*
receiving lengthy legal documents to sign. The sources are provided
for free but without warranty of any kind. The library has been
entirely written by Jean-loup Gailly and Mark Adler; it does not
include third-party code.
If you redistribute modified sources, we would appreciate that you include
in the file ChangeLog history information documenting your changes. Please
read the FAQ for more information on the distribution of modified source
versions.
This software application may include GTK 2.6.1 third-party software and may be subject to the following copyrights.
wxWindows Library Licence, Version 3
====================================
Copyright (C) 1998 Julian Smart, Robert Roebling [, ...]
Everyone is permitted to copy and distribute verbatim copies
of this licence document, but changing it is not allowed.
WXWINDOWS LIBRARY LICENCE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
This library is free software; you can redistribute it and/or modify it
under the terms of the GNU Library General Public Licence as published by
the Free Software Foundation; either version 2 of the Licence, or (at
your option) any later version.
This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library
General Public Licence for more details.
You should have received a copy of the GNU Library General Public Licence
along with this software, usually in a file named COPYING.LIB. If not,
write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
Boston, MA 02111-1307 USA.
EXCEPTION NOTICE
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of
the library as licenced under the wxWindows Library Licence, applying
either version 3 of the Licence, or (at your option) any later version of
the Licence as published by the copyright holders of version 3 of the
Licence document.
2. The exception is that you may use, copy, link, modify and distribute
under the user's own terms, binary object code versions of works based
on the Library.
3. If you copy code from files distributed under the terms of the GNU
General Public Licence or the GNU Library General Public Licence into a
copy of this library, as this licence permits, the exception does not
apply to the code that you add in this way. To avoid misleading anyone as
to the status of such modified files, you must delete this exception
notice from such code and/or adjust the licensing conditions notice
accordingly.
4. If you write modifications of your own for this library, it is your
choice whether to permit this exception to apply to your modifications.
If you do not wish that, you must delete the exception notice from such
code and/or adjust the licensing conditions notice accordingly.
• This software application may include GTK+ third-party software, portions of which may be subject to the GNU Library
General Public License. You can view the complete license at: http://www.gnu.org/copyleft/library.html, or find the file
at mgcdft_tree/docs/legal/.
• To obtain a copy of the GTK+ source code, send a request to request_sourcecode@mentor.com. This offer may be
accepted for three years from the date Mentor Graphics Corporation first distributed the GTK+ source code.
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/terms_conditions/enduser.cfm
IMPORTANT INFORMATION
USE OF THIS SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS

LICENSE AGREEMENT BEFORE USING THE SOFTWARE. USE OF SOFTWARE INDICATES YOUR
COMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH
IN THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND
CONDITIONS SHALL NOT APPLY.
END-USER LICENSE AGREEMENT (“Agreement”)
This is a legal agreement concerning the use of Software between you, the end user, as an authorized
representative of the company acquiring the license, and Mentor Graphics Corporation and Mentor Graphics
(Ireland) Limited acting directly or through their subsidiaries (collectively “Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by you and an
authorized representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties'
entire understanding relating to the subject matter and supersede all prior or contemporaneous agreements. If you
do not agree to these terms and conditions, promptly return or, if received electronically, certify destruction of
Software and all accompanying items within five days after receipt of Software and receive a full refund of any
license fee paid.
1. GRANT OF LICENSE. The software programs, including any updates, modifications, revisions, copies, documentation
and design data (“Software”), are copyrighted, trade secret and confidential information of Mentor Graphics or its
licensors who maintain exclusive title to all Software and retain all rights not expressly granted by this Agreement.
Mentor Graphics grants to you, subject to payment of appropriate license fees, a nontransferable, nonexclusive license to
use Software solely: (a) in machine-readable, object-code form; (b) for your internal business purposes; (c) for the license
term; and (d) on the computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half
mile (800 meter) radius. Mentor Graphics’ standard policies and programs, which vary depending on Software, license
fees paid or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be
limited, for example, to execution of a single session by a single user on the authorized hardware or for a restricted period
of time (such limitations may be technically implemented through the use of authorization codes or similar devices); and
(c) support services provided, including eligibility to receive telephone support, updates, modifications, and revisions.
2. EMBEDDED SOFTWARE. If you purchased a license to use embedded software development (“ESD”) Software, if
applicable, Mentor Graphics grants to you a nontransferable, nonexclusive license to reproduce and distribute executable
files created using ESD compilers, including the ESD run-time libraries distributed with ESD C and C++ compiler
Software that are linked into a composite program as an integral part of your compiled computer program, provided that
you distribute these files only in conjunction with your compiled computer program. Mentor Graphics does NOT grant
you any right to duplicate, incorporate or embed copies of Mentor Graphics' real-time operating systems or other
embedded software products into your products or applications without first signing or otherwise agreeing to a separate
agreement with Mentor Graphics for such purpose.
3. BETA CODE. Software may contain code for experimental testing and evaluation (“Beta Code”), which may not be used
without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’ authorization, Mentor Graphics grants to you a
temporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Code without charge
for a limited period of time specified by Mentor Graphics. This grant and your use of the Beta Code shall not be construed
as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not to release
commercially in any form. If Mentor Graphics authorizes you to use the Beta Code, you agree to evaluate and test the
Beta Code under normal conditions as directed by Mentor Graphics. You will contact Mentor Graphics periodically
during your use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of your
evaluation and testing, you will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,
weaknesses and recommended improvements. You agree that any written evaluations and all inventions, product
improvements, modifications or developments that Mentor Graphics conceived or made during or subsequent to this
Agreement, including those based partly or wholly on your feedback, will be the exclusive property of Mentor Graphics.
Mentor Graphics will have exclusive rights, title and interest in all such property. The provisions of this section 3 shall
survive the termination or expiration of this Agreement.
4. RESTRICTIONS ON USE. You may copy Software only as reasonably necessary to support the authorized use. Each
copy must include all notices and legends embedded in Software and affixed to its medium and container as received from
Mentor Graphics. All copies shall remain the property of Mentor Graphics or its licensors. You shall maintain a record of
the number and primary location of all copies of Software, including copies merged with other software, and shall make
those records available to Mentor Graphics upon request. You shall not make Software available in any form to any
person other than employees and on-site contractors, excluding Mentor Graphics' competitors, whose job performance
requires access and who are under obligations of confidentiality. You shall take appropriate action to protect the
confidentiality of Software and ensure that any person permitted access to Software does not disclose it or use it except as
permitted by this Agreement. Except as otherwise permitted for purposes of interoperability as specified by applicable
and mandatory local law, you shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive from
Software any source code. You may not sublicense, assign or otherwise transfer Software, this Agreement or the rights
under it, whether by operation of law or otherwise (“attempted transfer”), without Mentor Graphics’ prior written consent
and payment of Mentor Graphics’ then-current applicable transfer charges. Any attempted transfer without Mentor
Graphics' prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics' option, result in
the immediate termination of the Agreement and licenses granted under this Agreement. The terms of this Agreement,
including without limitation, the licensing and assignment provisions shall be binding upon your successors in interest
and assigns. The provisions of this section 4 shall survive the termination or expiration of this Agreement.
5. LIMITED WARRANTY.
5.1. Mentor Graphics warrants that during the warranty period Software, when properly installed, will substantially
conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrant
that Software will meet your requirements or that operation of Software will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. You
must notify Mentor Graphics in writing of any nonconformity within the warranty period. This warranty shall not be
valid if Software has been subject to misuse, unauthorized modification or improper installation. MENTOR
GRAPHICS' ENTIRE LIABILITY AND YOUR EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS'
OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF SOFTWARE TO MENTOR
GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF SOFTWARE THAT DOES NOT MEET THIS
LIMITED WARRANTY, PROVIDED YOU HAVE OTHERWISE COMPLIED WITH THIS AGREEMENT.
MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B) SOFTWARE
WHICH IS LICENSED TO YOU FOR A LIMITED TERM OR LICENSED AT NO COST; OR
(C) EXPERIMENTAL BETA CODE; ALL OF WHICH ARE PROVIDED “AS IS.”
5.2. THE WARRANTIES SET FORTH IN THIS SECTION 5 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS
NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, WITH
RESPECT TO SOFTWARE OR OTHER MATERIAL PROVIDED UNDER THIS AGREEMENT. MENTOR
GRAPHICS AND ITS LICENSORS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF
INTELLECTUAL PROPERTY.
6. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY

WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS
OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
(INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS' OR ITS LICENSORS'
LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT PAID BY YOU FOR THE SOFTWARE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR
GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE
PROVISIONS OF THIS SECTION 6 SHALL SURVIVE THE EXPIRATION OR TERMINATION OF THIS
AGREEMENT.
7. LIFE ENDANGERING ACTIVITIES. NEITHER MENTOR GRAPHICS NOR ITS LICENSORS SHALL BE
LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITH THE USE OF SOFTWARE IN
ANY APPLICATION WHERE THE FAILURE OR INACCURACY OF THE SOFTWARE MIGHT RESULT IN
DEATH OR PERSONAL INJURY. THE PROVISIONS OF THIS SECTION 7 SHALL SURVIVE THE
EXPIRATION OR TERMINATION OF THIS AGREEMENT.
8. INDEMNIFICATION. YOU AGREE TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITS
LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE, OR LIABILITY, INCLUDING
ATTORNEYS' FEES, ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF SOFTWARE AS
DESCRIBED IN SECTION 7. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THE EXPIRATION OR
TERMINATION OF THIS AGREEMENT.
9. INFRINGEMENT.
9.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against you alleging that
Software infringes a patent or copyright or misappropriates a trade secret in the United States, Canada, Japan, or
member state of the European Patent Office. Mentor Graphics will pay any costs and damages finally awarded
against you that are attributable to the infringement action. You understand and agree that as conditions to Mentor
Graphics' obligations under this section you must: (a) notify Mentor Graphics promptly in writing of the action;
(b) provide Mentor Graphics all reasonable information and assistance to defend or settle the action; and (c) grant
Mentor Graphics sole authority and control of the defense or settlement of the action.
9.2. If an infringement claim is made, Mentor Graphics may, at its option and expense: (a) replace or modify Software so
that it becomes noninfringing; (b) procure for you the right to continue using Software; or (c) require the return of
Software and refund to you any license fee paid, less a reasonable allowance for use.
9.3. Mentor Graphics has no liability to you if infringement is based upon: (a) the combination of Software with any
product not furnished by Mentor Graphics; (b) the modification of Software other than by Mentor Graphics; (c) the
use of other than a current unaltered release of Software; (d) the use of Software as part of an infringing process; (e) a
product that you make, use or sell; (f) any Beta Code contained in Software; (g) any Software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; or (h) infringement by
you that is deemed willful. In the case of (h) you shall reimburse Mentor Graphics for its attorney fees and other costs
related to the action upon a final judgment.
9.4. THIS SECTION IS SUBJECT TO SECTION 6 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS AND YOUR SOLE AND EXCLUSIVE REMEDY WITH RESPECT TO
ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR TRADE SECRET MISAPPROPRIATION
BY ANY SOFTWARE LICENSED UNDER THIS AGREEMENT.
10. TERM. This Agreement remains effective until expiration or termination. This Agreement will immediately terminate
upon notice if you exceed the scope of license granted or otherwise fail to comply with the provisions of Sections 1, 2, or
4. For any other material breach under this Agreement, Mentor Graphics may terminate this Agreement upon 30 days
written notice if you are in material breach and fail to cure such breach within the 30 day notice period. If Software was
provided for limited term use, this Agreement will automatically expire at the end of the authorized term. Upon any
termination or expiration, you agree to cease all use of Software and return it to Mentor Graphics or certify deletion and
destruction of Software, including all copies, to Mentor Graphics’ reasonable satisfaction.
11. EXPORT. Software is subject to regulation by local laws and United States government agencies, which prohibit export
or diversion of certain products, information about the products, and direct products of the products to certain countries
and certain persons. You agree that you will not export any Software or direct product of Software in any manner without
first obtaining all necessary approval from appropriate local and United States government agencies.
12. RESTRICTED RIGHTS NOTICE. Software was developed entirely at private expense and is commercial computer
software provided with RESTRICTED RIGHTS. Use, duplication or disclosure by the U.S. Government or a U.S.
Government subcontractor is subject to the restrictions set forth in the license agreement under which Software was
obtained pursuant to DFARS 227.7202-3(a) or as set forth in subparagraphs (c)(1) and (2) of the Commercial Computer
Software - Restricted Rights clause at FAR 52.227-19, as applicable. Contractor/manufacturer is Mentor Graphics
Corporation, 8005 SW Boeckman Road, Wilsonville, Oregon 97070-7777 USA.
13. THIRD PARTY BENEFICIARY. For any Software under this Agreement licensed by Mentor Graphics from Microsoft
or other licensors, Microsoft or the applicable licensor is a third party beneficiary of this Agreement with the right to
enforce the obligations set forth herein.
14. AUDIT RIGHTS. You will monitor access to, location and use of Software. With reasonable prior notice and during
your normal business hours, Mentor Graphics shall have the right to review your software monitoring system and
reasonably relevant records to confirm your compliance with the terms of this Agreement, an addendum to this
Agreement or U.S. or other local export laws. Such review may include FLEXlm or FLEXnet report log files that you
shall capture and provide at Mentor Graphics’ request. Mentor Graphics shall treat as confidential information all of your
information gained as a result of any request or review and shall only use or disclose such information as required by law
or to enforce its rights under this Agreement or addendum to this Agreement. The provisions of this section 14 shall
survive the expiration or termination of this Agreement.
15. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. THIS AGREEMENT SHALL BE
GOVERNED BY AND CONSTRUED UNDER THE LAWS OF THE STATE OF OREGON, USA, IF YOU ARE
LOCATED IN NORTH OR SOUTH AMERICA, AND THE LAWS OF IRELAND IF YOU ARE LOCATED
OUTSIDE OF NORTH OR SOUTH AMERICA. All disputes arising out of or in relation to this Agreement shall be
submitted to the exclusive jurisdiction of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the
laws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia (except for Japan) arising out of or in relation to
this Agreement shall be resolved by arbitration in Singapore before a single arbitrator to be appointed by the Chairman of
the Singapore International Arbitration Centre (“SIAC”) to be conducted in the English language, in accordance with the
Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by reference
in this section 15. This section shall not restrict Mentor Graphics’ right to bring an action against you in the jurisdiction
where your place of business is located. The United Nations Convention on Contracts for the International Sale of Goods
does not apply to this Agreement.
16. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid,
unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in
full force and effect.
17. PAYMENT TERMS AND MISCELLANEOUS. You will pay amounts invoiced, in the currency specified on the
applicable invoice, within 30 days from the date of such invoice. Any past due invoices will be subject to the imposition
of interest charges in the amount of one and one-half percent per month or the applicable legal rate currently in effect,
whichever is lower. Some Software may contain code distributed under a third party license agreement that may provide
additional rights to you. Please see the applicable Software documentation for details. This Agreement may only be
modified in writing by authorized representatives of the parties. Waiver of terms or excuse of breach must be in writing
and shall not constitute subsequent consent, waiver or excuse.
Rev. 060210, Part No. 227900

Edt Deterministic Test Guide

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 Deterministic Test Guide

Uploaded by

Copyright:

Available Formats

EDT™

(Embedded Deterministic Test)

Software Version 8.2007_2

 2001-2007 Mentor Graphics Corporation

RESTRICTED RIGHTS LEGEND 03/97

EDT Process Guide, V8.2007_2 3

4 EDT Process Guide, V8.2007_2

Generating EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

EDT Process Guide, V8.2007_2 5

Planning Your Modular TestKompress Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

6 EDT Process Guide, V8.2007_2

K19 through K22 DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

EDT Process Guide, V8.2007_2 7

Figure 1-1. EDT as Seen from the Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

8 EDT Process Guide, V8.2007_2

Figure 8-8. Creation of Top Level Test Procedure File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

EDT Process Guide, V8.2007_2 9

Table 1-1. Supported EDT Logic/Scan Architecture Combinations . . . . . . . . . . . . . . . . . . 21

10 EDT Process Guide, V8.2007_2

EDT Process Guide, V8.2007_2 11

Understanding EDT Basics

12 EDT Process Guide, V8.2007_2

Test Data Volume = ( # of Scan Cells ) × ( # of Scan Patterns )

EDT Process Guide, V8.2007_2 13

Solving the Cost of Test Problem with EDT

Understanding EDT Scan Channels

14 EDT Process Guide, V8.2007_2

Figure 1-1. EDT as Seen from the Tester

Scan chains Internal Scan chains

• the number of scan chains in your design core, and

EDT Process Guide, V8.2007_2 15

Understanding the Structure and Function of the EDT

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

16 EDT Process Guide, V8.2007_2

How EDT Patterns Work with the EDT Logic

EDT Process Guide, V8.2007_2 17

What is the TestKompress Tool?

As an EDT tool, it performs two major functions:

• Comparing EDT and Traditional ATPG

Overview of the TestKompress Tool Flow

18 EDT Process Guide, V8.2007_2

• Creating the EDT Logic

Creating the EDT Logic

1. Invoke TestKompress on Your Gate Level Netlist

2. Provide TestKompress Commands

// Specify the number of scan channels.

// Flatten the design, run DRCs.

// Verify the EDT configuration is as expected.

// Generate the RTL EDT logic and save it.

EDT Process Guide, V8.2007_2 19

report scan volume

// Close the session and exit.

Synthesizing the EDT Logic

1. Run Design Compiler

dc_shell -f …/created_dc_script.scr |& tee …/transcripts/dc_edt.log

Generating EDT Patterns

1. Invoke TestKompress on the Netlist with the Synthesized EDT Circuitry

<mgcdft tree>/bin/testkompress …/created_edt_top.v -verilog \

2. Provide TestKompress Commands

// Flatten the design, run DRCs.

// Verify the EDT configuration.

// Save the patterns in ASCII format.

// Save the patterns in parallel and serial Verilog format.