edt_gd

EDT™ Process Guide

Software Version 8.2009_3

August 2009

2001-2009 Mentor Graphics CorporationAll rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of thisdocument may duplicate this document in whole or in part for internal business purposes only, provided that this entirenotice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonableeffort 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 makechanges in specifications and other information contained in this publication without prior notice, and thereader should, in all cases, consult Mentor Graphics to determine whether any changes have beenmade.

The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth inwritten agreements between Mentor Graphics and its customers. No representation or other affirmationof fact contained in this publication shall be deemed to be a warranty or give rise to any liability of MentorGraphics whatsoever.

MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIALINCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY ANDFITNESS FOR A PARTICULAR PURPOSE.

MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, ORCONSEQUENTIAL 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 OFSUCH DAMAGES.

RESTRICTED RIGHTS LEGEND 03/97

U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirelyat 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 therestrictions 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 - RestrictedRights 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.2210Website: www.mentor.com

SupportNet: supportnet.mentor.com/Send Feedback on Documentation: supportnet.mentor.com/user/feedback_form.cfm

TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property ofMentor Graphics Corporation or other third parties. No one is permitted to use these Marks without theprior 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 toindicate 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.

http://www.mentor.com

http://supportnet.mentor.com/

http://supportnet.mentor.com/user/feedback_form.cfm

http://www.mentor.com/terms_conditions/trademarks.cfm

EDT Process Guide, V8.2009_3 3August 2009

Table of Contents

Chapter 1Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

What is TestKompress? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11What is EDT?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11What Test Patterns are Supported by TestKompress?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12What Scan Architectures Can I Use With TestKompress? . . . . . . . . . . . . . . . . . . . . . . . . . . 12What Do I Need to Use TestKompress? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12How Does TestKompress Affect My Design?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Understanding EDT Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Scan Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Structure and Function of the EDT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14How Test Patterns Work with the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Overview of the TestKompress Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

DRC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Internal Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Logic Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21ASCII and Binary Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Fault Models and Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Compression Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

User Interface Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Batch Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24UNIX Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Disk Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Interrupt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 2Understanding the TestKompress Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Top-Down Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Pin Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31I/O Pads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31External Flow Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Internal Flow Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

The EDT Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32External EDT Logic Flow (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Internal EDT Logic Flow (Internal Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Table of Contents

4August 2009

EDT Process Guide, V8.2009_3

Chapter 3Scan Chain Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Preparing the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39External Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Internal Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Inserting Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Inserting Bypass Chains in the Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Including Uncompressed Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Determining How Many Scan Chains to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Using One Scan Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Avoiding Sharing Scan Chain Pins with Functional Pins. . . . . . . . . . . . . . . . . . . . . . . . . . 44Reordering Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Examining a DFTAdvisor Dofile Used with TestKompress . . . . . . . . . . . . . . . . . . . . . . . 45

Establishing a Compression Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Running FastScan ATPG (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Simulating the FastScan Test Patterns (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 4Creating EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

About TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Invoking TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Preparing for EDT Logic Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Defining Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Setting Parameters for the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Reporting the EDT Logic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Understanding EDT Control and Channel Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Sharing Functional Pins with EDT Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Specifying Connections for EDT Pins (Internal Flow only) . . . . . . . . . . . . . . . . . . . . . . . 66Specifying Internally Driven EDT Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Customizing the Structure of the Bypass Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Customizing the Compactor Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Running DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69DRC when EDT Pins are Shared with Functional Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Creating EDT Logic Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Specifying Module/Instance Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

About the EDT Logic Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Top-level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72EDT Logic Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Synthesis Script External Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Synthesis Script Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Test Pattern Generation Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Bypass Mode Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Creating a Reduced Netlist for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Inserting EDT Logic Inside the Core Before Synthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Synthesis Script for Pre-Inserted EDT Logic Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Estimating Test Coverage and Data Volume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Table of Contents


Chapter 5Synthesizing the EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Preparing for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

External EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Internal EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

About Synthesizing EDT Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 6Generating/Verifying Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Preparing for Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Using the Generated Dofile and Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Verifying the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Generating Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Optimizing Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Saving the Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Post-Processing of EDT Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Simulating the Generated Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Setting Up for HDL Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapter 7Special Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Bypassing EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Structure of the Bypass Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Generating EDT Logic When Bypass Logic is Defined in the Netlist . . . . . . . . . . . . . . . . 115Generating Identical EDT and Bypass Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Using Bypass Patterns in FastScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Bypass Pattern Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Creating Bypass Patterns with FastScan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

TestKompress and Boundary Scan (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Flow overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Boundary Scan Coexisting with EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Driving TestKompress with the TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Using Pipeline Stages in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Using Pipeline Stages Between Pads and Channel Inputs or Outputs. . . . . . . . . . . . . . . . . . 129

Channel Output Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Clocking of Channel Input Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Clocking of Channel Output Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Initializing the Input Channel Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131DRC for Channel Input Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132DRC for Channel Output Pipelining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Understanding How Lockup Cells are Inserted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Lockups Between Decompressor and Scan Chain Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . 135Lockups Between Scan Chain Outputs and Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Lockups Between Channel Outputs and Output Pipeline Registers. . . . . . . . . . . . . . . . . . 138

Table of Contents

6August 2009


Lockups in the Bypass Circuitry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Evaluating Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Establishing a Point of Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Measuring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Improving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Understanding Compactor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Basic Compactor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Xpress Compactor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Understanding Scan Chain Masking in the Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Why Masking is Needed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Resolving X Blocking with Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Fault Aliasing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Reordering Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Chapter 8Modular TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

About the Modular Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Understanding Modular TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Creating a Block-level Compression Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Balancing Scan Chains Between Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Sharing Input Scan Channels on Identical EDT blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Generating Modular EDT Logic for a Fully Integrated Design . . . . . . . . . . . . . . . . . . . . . 163Estimating Test Coverage/Pattern Count for EDT Blocks . . . . . . . . . . . . . . . . . . . . . . . . . 164

Creating a Top-level Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Block-level Test Procedure Files Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Top-level Test Procedure File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Creating the Top-level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Creating the Top-level Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Instantiating a EDT Block Multiple Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Top-level Dofile Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Generating Top-level Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Modular TestKompress Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Modular Flow Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 9Integrating TestKompress at the RTL Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

About the RTL Stage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Skeleton Design Input and Interface Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Skeleton Design Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Skeleton Design Interface File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

create_skeleton_design Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Creating EDT Logic for a Skeleton Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Understanding the Longest Scan Chain Length Estimate. . . . . . . . . . . . . . . . . . . . . . . . . . 190Integrating the EDT Logic into the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Knowing When to Regenerate the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Skeleton Flow Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Input File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Table of Contents


Appendix AGetting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Online Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Appendix BEDT Logic Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

EDT Logic with Basic Compactor and Bypass Module. . . . . . . . . . . . . . . . . . . . . . . . . . . 201EDT Logic with Xpress Compactor and Bypass Module. . . . . . . . . . . . . . . . . . . . . . . . . . 201Decompressor Module with Basic Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Decompressor Module with Xpress Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Input Bypass Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Compactor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Output Bypass Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Basic Compactor Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Xpress Compactor Controller Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Dual Compression Configuration Input Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Dual Compression Configuration Output Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Appendix CTroubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Debugging Simulation Mismatches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Resolving DRC Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

K19 through K22 DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Incorrect References to \**TSGEN** in Synthesized Netlist . . . . . . . . . . . . . . . . . . . . . . 231Limiting Observable Xs for a Compact Pattern Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Applying Incompressible Patterns Thru Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 233If Compression is Less Than Expected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233If Test Coverage is Less Than Expected. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Index

Third-Party Information

End-User License Agreement

8August 2009


List of Figures

Figure 1-1. EDT as Seen from the Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 1-2. Tester Connected to a Design with EDT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figure 1-3. EDT logic Located Outside the Core (External Flow) . . . . . . . . . . . . . . . . . . . . 19Figure 1-4. EDT logic Located Within the Core (Internal Flow) . . . . . . . . . . . . . . . . . . . . . 20Figure 2-1. Top-Down Design Flow External . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 2-2. Top-Down Design Flow Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figure 2-3. EDT External Flow with TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 2-4. EDT Internal Flow with TestKompress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 3-1. Scan Chain Insertion and Synthesis Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 4-1. EDT Logic Creation Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figure 4-2. Example of a Basic EDT Pin Configuration (External EDT Logic). . . . . . . . . . 60Figure 4-3. Example of a Basic EDT Pin Configuration (Internal EDT Logic) . . . . . . . . . . 61Figure 4-4. Example with Pin Sharing Shown in Table 4-1(External EDT Logic) . . . . . . . . 66Figure 4-5. Internally Driven edt_update Control Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Figure 4-6. Contents of the Top Level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 4-7. Contents of the EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Figure 4-8. Design Netlist with Internal Connection Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 87Figure 5-1. Preparing For and Synthesizing the EDT logic. . . . . . . . . . . . . . . . . . . . . . . . . . 93Figure 5-2. Contents of Boundary Scan Top Level Wrapper . . . . . . . . . . . . . . . . . . . . . . . . 95Figure 6-1. Test Pattern Generation and Verification Procedure . . . . . . . . . . . . . . . . . . . . . 99Figure 6-2. Sample EDT Test Procedure Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Figure 6-3. Example Decoder Circuitry for Six Scan Chains and One Channel. . . . . . . . . . 104Figure 6-4. Circuitry in the Pattern Generation Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Figure 7-1. Bypass Mode Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Figure 7-2. Evaluation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Figure 7-3. Basic Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Figure 7-4. Xpress Compactor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Figure 7-5. X-Blocking in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Figure 7-6. X Substitution for Unmeasurable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Figure 7-7. Example of Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Figure 7-8. TestKompress Handling of Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . 152Figure 7-9. Example of Fault Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Figure 7-10. Using Masked Patterns to Detect Aliased Faults . . . . . . . . . . . . . . . . . . . . . . . 154Figure 7-11. Handling Scan Chains of Different Length. . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Figure 8-1. Modular Design with Five EDT blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Figure 8-2. Creating the Top-level Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Figure 8-3. Creating a Top-level Timeplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Figure 8-4. Creating a Top-level Load_unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 167Figure 8-5. Creating a Top-level Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Figure 8-6. Netlist with Two Cores Sharing TestKompress Control Signals . . . . . . . . . . . . 179

List of Figures


Figure 9-1. TestKompress RTL Stage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Figure 9-2. Create_skeleton_design Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Figure C-1. Flow for Debugging Simulation Mismatches. . . . . . . . . . . . . . . . . . . . . . . . . . . 210Figure C-2. Order of Diagnostic Checks by the K19 DRC . . . . . . . . . . . . . . . . . . . . . . . . . . 213Figure C-3. Order of Diagnostic Checks by the K22 DRC . . . . . . . . . . . . . . . . . . . . . . . . . . 224

10August 2009


List of Tables

Table 1-1. Supported Scan Architecture Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Table 4-1. Example Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Table 4-2. Default EDT Pin Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Table 7-1. Lockup Cells Between Decompressor and Scan Chain Inputs . . . . . . . . . . . . . . 136Table 7-2. Lockup Cells Between Scan Chain Outputs and Compactor . . . . . . . . . . . . . . . 137Table 7-3. Bypass Lockup Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Table 7-4. Summary of Performance Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Table 8-1. Modular Flow Stage Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Table 8-2. Modular TestKompress Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 181


Chapter 1Getting Started

This manual describes how to integrate TestKompress® into your design process. Moreinformation can be found in the following manuals:

• ATPG and Failure Diagnosis Tools Reference Manual — Contains information onTestKompress commands.

• Design-for-Test Common Resources Manual — Contains information for DRCsincluding the TestKompress-specific EDT Rules.

What is TestKompress?TestKompress is a Design-for-Test (DFT) software application that creates test patterns andimplements compression for the testing of manufactured ICs.

TestKompress creates and imbeds compression logic (EDT logic) and generates compressedtest patterns that work together to provide effective IC testing and compression of test data asfollows:

Test patterns — Compressed test patterns are generated and loaded onto the Automatic TestEquipment (ATE).

Imbedded logic — EDT logic is generated and imbedded in the IC to:

1. Receive the compressed test patterns from the ATE and decompress them.

2. Deliver the uncompressed test patterns to the core design for testing.

3. Receive and compress the test results and return them to the ATE.

TestKompress is command-line driven and supports traditional ATPG.

Advanced compression reduces ATE memory and channel requirements and reduced datavolume results in shorter test application times and higher tester throughput than with traditionalATPG.

What is EDT?Embedded Deterministic Testing (EDT) is the technology used by TestKompress. EDTtechnology is based on traditional, deterministic ATPG, so you obtain the same fault models,


Getting StartedWhat Test Patterns are Supported by TestKompress?

August 2009

test coverage, and a very similar flow. EDT expands the well-proven capabilities of ATPG byproviding improved compression of scan test data and reduction in test time.

What Test Patterns are Supported byTestKompress?

TestKompress supports all types of test patterns except:

• Random pattern generation.

• FastScan MacroTest. You can only apply MacroTest patterns to a design withTestKompress by accessing the scan chains directly, bypassing the EDT logic.

What Scan Architectures Can I Use WithTestKompress?

TestKompress logic supports mux-DFF and LSSD or a mixture of the scan architectures aslisted in Table 1-1.

What Do I Need to Use TestKompress?You need the following components to use TestKompress:

• Scan-inserted gate-level Verilog netlist or an RTL description in Verilog or VHDL.

• Design Compiler (DC) or other synthesis tool.

• Compatible ATPG library of the models used for your design scan circuitry. Ifnecessary, you can convert Verilog libraries to a compatible ATPG library format withthe LibComp utility. For more information, see “Creating ATPG Models” in the Design-for-Test Common Resources Manual.

• Timing simulator, such as ModelSim.

How Does TestKompress Affect My Design?Depending on the configuration and placement of the EDT logic, your design may be affectedas follows:

Table 1-1. Supported Scan Architecture Combinations

EDT Logic Supported Scan Architectures

DFF-based LSSD, Mux-DFF, and mixed

Latch-based LSSD

Getting StartedUnderstanding EDT Technology


• Extra level of hierarchy -- If you place the EDT logic outside the core design, you mustadd a boundry scan wrapper which adds a level of hierarchy.

• Minimal physical space -- The size of the EDT logic is roughly about 25 gates perinternal scan chain. The following examples can be used as guidelines to roughlyestimate the size of the EDT logic for a design:

o For a one million gate design with 200 scan chains, the logic BIST controllerincluding PRPG, MISR and the BIST controller, is 1.25 times the size of the EDTlogic for 16 channels.

o For a one million gate design configured into 200 internal scan chains, the EDTlogic including decompressor, compactor, and bypass circuitry with lockup cellsrequires less than 20 gates per chain. The logic occupies an estimated 0.35% of thearea. The size of the EDT logic does not vary significantly based on the size of thedesign.

o For 8 scan channels and 100 internal scan chains, the EDT logic was found to betwice as large as a TAP controller, and 19% larger than the MBIST™ controller for a1k x 8-bit memory.

Understanding EDT TechnologyTestKompress achieves compression of scan test data by controlling a large number of internalscan chains using a small number of scan channels. Scan channels can be thought of as virtualscan chains because, from the point of view of the tester, they operate exactly the same astraditional scan chains. Therefore, any tester that can apply traditional scan patterns can applycompressed patterns as described in the following topics:

• Scan Channels

• Structure and Function of the EDT Architecture

• How Test Patterns Work with the EDT Logic

Scan ChannelsWith TestKompress, the number of internal scan chains is significantly larger than the numberof external virtual scan chains the EDT logic presents to the tester. Figure 1-1 illustratesconceptually how a design tested with EDT technology is seen from the tester compared to thesame design tested using conventional scan and ATPG.



August 2009

Figure 1-1. EDT as Seen from the Tester

Under EDT methodology, the virtual scan chains are called scan channels to distinguish themfrom the scan chains inside the core. Their number is significantly less than the number ofinternal scan chains. You control the amount of compression by varying two parameters:

• number of scan chains in your design core

• number of channels (virtual scan chains) presented to the tester. This must be the sameas the number of tester channels on the ATE, so it is usually fixed.

Their ratio is called the chain-to-channel ratio:

For example, if there are two external channels feeding the embedded EDT circuitry, which inturn 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 key point to remember is EDT compression isachieved by reducing the amount of data per pattern and not by reducing the number of patternsas in traditional ATPG. The pattern count is usually slightly higher, everything else being equal,than with traditional ATPG.

Structure and Function of the EDT ArchitectureEDT technology consists of logic embedded on-chip, new EDT-specific DRC, and adeterministic pattern generation technique.

EDT

Conventional ATPG

Scan chains

Scan channels

Internal Scan chains

(virtual scan chains)

Chain-to-channel ratio # of Scan Chains# of Scan Channels----------------------------------------------=



The imbedded logic includes adecompressor located between the external scan channel inputsand the internal scan chain inputs and a compactor located between the internal scan chainoutputs and the external scan channel outputs. See Figure 1-2.

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

You have the option of including bypass circuitry for which 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, EDT logic affects only scan channel inputs and outputs, and thus has no effect onfunctional paths.

Figure 1-2 shows an example design with two scan channels and 20 short internal scan chains.From the point of view of the ATE, the design appears to have two scan chains, each as long asthe internal scan chains. Each compressed test pattern has a small number of initializationcycles, so the total number of shifts per pattern would be slightly more than the number of scancells in each chain.

For example, if each chain has 1,250 scan cells and each compressed pattern requires fourinitialization 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 clockcycle (two bits total, in parallel, on the two channel inputs). In the same clock cycle, thedecompressor 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 morescan chains. Because the scan chains are balanced, they are much shorter and thus requireproportionally fewer shift cycles to load.

IC

ATE Scan ScanChannelOutputs

ChannelInputs

CompressedPatterns

CompressedExpected Response

Compactor

Decompressor

Core Designwith Scan Chains


Getting StartedOverview of the TestKompress Flow

August 2009

How Test Patterns Work with the EDT LogicTestkompress generates compressed test patterns specifically for on-chip processing by theEDT logic.

For a given testable fault, a compressed test pattern satisfies ATPG constraints and avoids buscontention, similar to conventional ATPG.

A set of compressed test patterns is stored on the ATE and each test pattern applies data to theinputs of the decompressor and holds the responses observed on the outputs of the compactor.The ATE applies the compressed test patterns to the circuit through the decompressor, whichlies between the scan channel pins and the internal scan chains. From the perspective of thetester, there are relatively few scan chains present in the design.

The compressed test patterns, after passing through the decompressor, create the necessaryvalues in the scan chains to guarantee fault detection. The functional input and output pins aredirectly 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 ofinternal scan chains to feed the smaller number of external channels. The response captured inthe scan cells is compressed by the compactor and the compressed response is compared on thetester. The compactor ensures faults are not masked and X-states do not corrupt the response.

You define parameters, such as the number of scan channels and the insertion of lockup cells,which are also part of the RTL code. TestKompress automatically determines the internalstructure of the EDT hardware based on the parameters you specify, the number of internal scanchains, the length of the longest scan chain, and the clocking of the first and last scan cell ineach chain. Test patterns include parallel and serial test benches for Verilog as well as paralleland serial WGL, and most other formats supported by FastScan™.

Overview of the TestKompress FlowThis section describes the default TestKompress flow by briefly introducing the steps andrequired to incorporate EDT into a gate level Verilog netlist. This summary is intended toprovide an overview of the three main phases in the flow:

• Creating the EDT Logic

• Synthesizing the EDT Logic

• Generating Test Patterns

NoteThe commands shown in bold font in the following examples are EDT-specific

Getting StartedOverview of the TestKompress Flow


Creating the EDT Logic

1. Invoke TestKompress on Your Gate Level Netlist

<mgcdft tree>/bin/testkompress …/gatelevel_netlist.v \-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.testprocadd scan chains chain1 grp1 edt_si1 edt_so1add scan chains chain2 grp1 edt_si2 edt_so2...add scan chains chain5 grp1 edt_si5 edt_so5analyze 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 reportsreport statisticsreport scan volume

// Close the session and exit.exit

Synthesizing the EDT Logic

1. Run Design Compiler

NoteThe Design Compiler synthesis script referenced in the following invocation line isoutput from “write edt files” in preceding step 2.


Getting StartedEDT Logic

August 2009

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

Generating Test Patterns

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

NoteThe 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 statisticsreport 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.save patterns …/generated/patterns_edt_p.v -verilog -replace -parallelsave 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

EDT LogicTestKompress generates hardware in blocks in VHDL or Verilog RTL. You integrate the EDTlogic into your design by invoking TestKompress on the core level of the design. The tool thengenerates the following components:



• Decompressor—Feeds a large number of scan chains in your core design from a smallnumber 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 intoa 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 lockupcells if necessary) to concatenate the internal scan chains into fewer, longer chains.Enables you to access the internal scan chains directly through the channel pins.Generated by default.

The decompressor resides between the channel inputs (connected to the tester) and the scanchain inputs of the core. Its main parts are an LFSM and a phase shifter. The compactor residesbetween the core scan chain outputs and the channel outputs connected to the tester. It primarilyconsists 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.

To facilitate design routing, you can also insert the bypass logic in the netlist at scan insertiontime. For more information, see “Inserting Bypass Chains in the Netlist” on page 42.

The previously mentioned components are all contained within the EDT logic block that, bydefault, is instantiated in a top level “wrapper” module. The design core is also instantiated inthe top level wrapper. This is illustrated conceptually in Figure 1-3. You insert pads and I/Ocells on this new top level. Because the EDT logic is outside the core design (the netlist onwhich you invoked the tool), the tool flow you use to implement this configuration is referred toas the external EDT logic location flow, or simply “external flow.”

Figure 1-3. EDT logic Located Outside the Core (External Flow)

edt_channels_in edt_channels_out

edt_scan_out

edt_scan_in

edt_clock

edt_update edt_decompressor

EDT Logic

edt_top

core

PIs POs

edt_compactor

edt_bypass (opt.)

edt_bypass



August 2009

Alternatively, you can invoke TestKompress on a design that already contains I/O pads. Forthese designs, the tool enables you to insert the EDT logic block in the existing top level withinthe original design. This is shown conceptually in Figure 1-4. Because the EDT logic isinstantiated within the netlist TestKompress was invoked on, this configuration is referred to asthe internal EDT logic location flow.

Figure 1-4. EDT logic Located Within the Core (Internal Flow)

By default, the tool automatically inserts lockup cells as needed in the EDT logic. They areplaced within the EDT logic, between the EDT logic and the design core, and in the bypasscircuitry that concatenates the scan chains. The Chapter 7 section, “Understanding How LockupCells are Inserted,” describes in detail how the tool determines where to put the lockups.

DRC RulesTestKompress performs the same ATPG design rules checking (DRC) after design flatteningthat FastScan performs. A detailed discussion of DRC is included in “ATPG Design RulesChecking” in the Scan and ATPG Process Guide.

In addition, TesKompress also runs a set of DRC specifically for EDT. For more information,see “Running DRC” on page 69.”

Internal ControlIn many cases, it is preferable to use internal controllers (JTAG or test registers) to control EDTsignals, such as edt_bypass, edt_update, scan_en, and to disable the edt_clock in functional

edt_channels_in edt_channels_out

edt_scan_out

edt_scan_inedt_clock

edt_updateedt_

decompressor

EDT Logic

core with I/O Pads

Module A

PIs POs

edt_compactor

edt_bypass (opt.)edt_bypass

Module Bedt_scan_out

edt_scan_in



mode. For detailed information about how to do this with boundary scan, refer to the“TestKompress and Boundary Scan (External Flow)” on page 121.

Logic ClockingThe default EDT logic contains combinational logic and flip-flops. All the flip-flops, exceptlockup cells, are positive edge-triggered, and clocked by a dedicated clock signal that isdifferent from the scan clock. There is no clock gating within the EDT logic, so it does notinterfere with the system clock(s) in any way.

You can set up the TestKompress clock to be a dedicated pin (named edt_clock by default) oryou can share the TestKompress clock with a functional non-clock pin. Such sharing may causea decrease in test coverage because TestKompress constrains the TestKompress clock pinduring test pattern generation. You must not share the TestKompress clock with another clockor RAM control pin for several reasons:

• If shared with a scan clock, the scan cells may be disturbed when the Testkompressclock is pulsed in the load_unload procedure during pattern generation.

• If shared with RAM control signals, RAM sequential patterns and multiple load patternsmay not be applicable.

• If shared with a non-scan clock, test coverage may decline because the Testkompressclock is constrained to its off-state during the capture cycle.

Because the clock used in the EDT logic is different than the scan clock, lockup cells can beinserted automatically between the EDT logic and the scan chains as needed. TestKompressinserts lockup cells as part of the EDT logic and never modifies the design core.

NoteYou can set the EDT clock to pulse before the scan chain shift clocks and avoid havinglockup cells inserted. For more information, see “Setting EDT Clock to Pulse BeforeScan Shift Clocks” on page 58.

Latch-based EDT logic uses two clocks (a master and a slave clock) to drive the logic. Forreasons similar to those listed above for DFF-based logic, you must not share the masterTestKompress clock with the system master clock. You can, however, share the slaveTestKompress clock with the system slave clock.



August 2009

NoteDuring the capture cycle, the system slave clock, which is shared with the slaveTestKompress clock, is pulsed. This does not affect the EDT logic because the values inthe master latches do not change. Similarly, in the load_unload cycle, although the slaveTestKompress clock is pulsed, the value at the outputs of the system slave latches isunchanged 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 isunaffected because the master TestKompress clock is not shared.

ASCII and Binary PatternsTestKompress can write out patterns in ASCII and binary formats, and can read these patternsback in. As in FastScan, you use these formats primarily for debugging simulation mismatchesand archiving. However, TestKompress arranges data differently than in ASCII patterns savedby FastScan.

When you create patterns with TestKompress, the captured data is stored with respect to theinternal scan chains, but the load data is stored with respect to the external scan channels. Theload data in the pattern file is in compressed format—the same form it is fed to thedecompressor.

Another difference from FastScan is that with the TestKompress simulator, Xs may not be dueto capture; they may result from the emulation of the compactor. For a detailed discussion ofthis effect and how TestKompress limits it with masking, refer to “Understanding Scan ChainMasking in the Compactor” on page 150.

Fault Models and Test PatternsTestkompress uses fault-model independent and pattern-type independent compressionalgorithms. The technology supports all fault models (stuck-at, transition, Iddq, and path delay)and deterministic pattern types (combinational, RAM sequential, clock-sequential, and multipleloads) supported and/or generated by FastScan.

To summarize, TestKompress:

• Accepts the same fault models as ATPG.

• Accepts the same deterministic pattern types as ATPG (TestKompress support ofMacroTest is limited, however, as noted previously).

• Produces the same test coverage as ATPG.

Getting StartedUser Interface Overview


Compression RatioThe TestKompress compression in the scan data 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 thecompression per pattern; but that increases the possibility of TestKompress generating patternsit cannot compress and can lead to lower test coverage. Higher chain-to-channel ratios alsodecrease the number of faults dynamic compaction can fit into a pattern. This can increase thetotal number of patterns and, therefore, decrease overall compression.

TestKompress does not limit the number of internal scan chains. You may find, however, thatrouting constraints limit the chain-to-channel ratio. Most practical configurations do not exceedthe tool’s capability to compress patterns. That is, the tool is unlikely to abort on a fault forwhich it generated a test pattern that could not be compressed.

User Interface OverviewTestKompress provides a command-line interface. When you invoke the tool, it opens in setupmode with the following command line prompt:

SETUP>

Batch ModeYou can run TestKompress in batch mode by using a dofile to pipe commands into theapplication. Dofiles let you automatically control the operations of the tool. The dofile is a textfile you create that contains a list of application commands that you want to run, but withoutentering them individually. If you have a large number of commands, or a common set ofcommands 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 entiresession as a batch process. Once you generate a dofile, you can run it at invocation. Forexample, to run TestKompress as a batch process using the commands contained in the dofilemy_dofile.do, enter:

shell> <mgcdft tree>/bin/testkompress -dofile my_dofile.do

The following shows an example TestKompress dofile:



August 2009

// 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.set system mode atpg

// Report and write EDT logic.report edt configurationreport edt pinswrite edt files created -verilog -replace

// Exit.exit

By default, if the tool encounters an error when running one of the commands in the dofile, itstops dofile execution. However, you can turn this setting off or specify to exit to the shellprompt by using the Set Dofile Abort command

Log FilesLog files provide a useful way to examine the operation of the tool, especially when you run thetool in batch mode using a dofile. If errors occur, you can examine the log file to see exactlywhat happened. The log file contains all DFT application operations and any notes, warnings, orerror messages that occur during the session.

You can generate log files by using the -Logfile switch when you invoke the tool, or by issuingthe Set Logfile Handling command. When setting up a log file, you can instruct TestKompressto generate a new log file, replace an existing log file, or append information to a log file thatalready exists.

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

UNIX CommandsYou can run UNIX operating system commands within DFT applications by using the Systemcommand. For example, the following command executes the UNIX operating systemcommand ls within a DFT application session:

prompt> system ls



Disk SpaceTo conserve disk storage space, DFTAdvisor™, FastScan, TestKompress, and FlexTest™ canread and write disk files using either the UNIX compress or the GNU gzip command. Whenyou provide a filename with the appropriate filename extension (“.Z” for compress, or “.gz” forgzip), the tools automatically process the file using the appropriate utility. Two commandscontrol this capability:

• Set File Compression - Turns file compression on or off. This command applies to allfiles that the tool reads from and writes to.

• Set Gzip Options - Specifies which GNU gzip options to use when the tool is processingfiles that have the .gz extension.

NoteThe file compression used by the tools to manage disk storage space is unrelated to thepattern 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 DFTdocumentation.

InterruptTo interrupt the invocation of a DFT product and return to the operating system, pressControl-C. You can also use Control-C to interrupt the current operation and return control tothe tool.

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

prompt> exit



August 2009


Chapter 2Understanding the TestKompress Flow

Top-Down Design FlowFigures 2-1 and 2-2 compare the basic steps and the Mentor Graphics tools used for a typicalATPG top-down design flow with the steps and tools used to incorporate TestKompress in theflow. For more information on the ATPG flow, see is contained in the Scan and ATPG ProcessGuide so it is not repeated here. This manual discusses the steps shown in grey; it also mentionscertain aspects of other design steps, where applicable. This flow primarily shows the typicaltop-down design process flow using a structured compression 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 Verilog format and contains memorymodels, you can add built-in self-test (BIST) circuitry to your RTL design. MBISTArchitect™

creates and inserts RTL-customized internal testing structures for design memories.

Commonly, in an ATPG flow that does not use TestKompress, you would next insert and verifyI/O pads and boundary scan circuitry using BSDArchitect™ (BSDA). Then, you wouldsynthesize and optimize the design using the Synopsys Design Compiler tool or anothersynthesis tool, followed by a timing verification with a static timing analyzer such asPrimeTime.

After synthesis, you are ready to insert internal scan circuitry into your design usingDFTAdvisor. In the normal ATPG flow, after you insert scan, you could optionally reverify thetiming because you added scan circuitry. Once you were sure the design is functioning asdesired, you would generate test patterns using FastScan™ or FlexTest™ (depending on yourscan methodology) and generate a test pattern set in the appropriate format.


Understanding the TestKompress FlowTop-Down Design Flow

August 2009

Figure 2-1. Top-Down Design Flow External

Insert/Verify

CircuitryBoundary Scan

Hand offto Vendor

InsertInternal Scan

Circuitry

Create Initial Design& Verify Functionality

BSDArchitect

DFTAdvisor

EDT

MBISTArchitect

BSDArchitect

MBISTArchitect

Synthesize/Optimizethe Design Logic

Insert/VerifyBIST Circuitry


ATPG

Design Compiler

DFTAdvisor

TestKompress

Insert I/O Pads

Insert I/O Pads

Insert/Verify


InsertInternal Scan

Circuitry

Generate (PatternGeneration Phase) &Verify EDT Patterns

Generate/VerifyTest Patterns

Design Compiler

PrimeTime

Design Compiler

(External Flow)

Re-verify Timing(opt.)

Verify TimingInsert/Verify


Design &Synthesize/Optimize

Verify Timing PrimeTime

PrimeTimeDesign IncrementallySynthesize/Optimize

TestKompressModelSim

FastScanFlexTestModelSim

Create & Insert EDT



Figure 2-2. Top-Down Design Flow Internal

Hand offto Vendor

InsertInternal Scan

Circuitry

Create Initial Design& Verify Functionality

BSDArchitect

DFTAdvisor

EDT

MBISTArchitect

BSDArchitect

MBISTArchitect

Synthesize/Optimizethe Design



ATPG

DFTAdvisor

TestKompress

Insert I/O Pads

Insert/Verify


InsertInternal Scan

Circuitry

Generate (PatternGeneration Phase) &Verify EDT Patterns

Generate/VerifyTest Patterns

Design Compiler

PrimeTime

Design Compiler

(Internal Flow)

Insert I/O Pads

Insert/Verify


the DesignInsert Logic/Synthesize

Incrementally

Re-verify Timing(optional)

Verify Timing

Design CompilerDesign &Synthesize/Optimize

Verify Timing PrimeTime

TestKompressModelSim

FastScanFlexTestModelSim

Create EDT Logic



August 2009

By comparison, a TestKompress flow can take one of two paths:

• External Logic Location Flow (external flow)—Differs from the typical ATPG flow inthat you do not insert I/O pads and boundary scan until after you run TestKompress onthe scan-inserted core to insert the EDT logic. The EDT logic is located external to thedesign netlist.

• Internal Logic Location Flow (internal flow)—Similar to a typical ATPG flow, you mayinsert and verify I/O pads and boundary scan circuitry before you synthesize andoptimize the design. The EDT logic is instantiated in the top level of the design netlist,permitting the logic to be connected to internal nodes (I/O pad cells or an internal testcontroller block, for example) or to the top level of the design. Typically, the EDT logicis connected to the internal nodes of the pad cells used for channel and control signalsand you would run TestKompress on the scan-inserted core that includes I/O pads andboundary scan.

You should choose a TestKompress flow based on whether the EDT logic signals need to beconnected to nodes internal to the design netlist read into the tool (internal nodes of I/O pads,for example), or whether the EDT logic can be connected to the design using a wrapper.

In the external flow, after you insert scan circuitry the next step is to insert the EDT logic.Following that, you insert and verify boundary scan circuitry if needed. Only then do you addI/O pads. Then, you incrementally synthesize and optimize the design using either DesignCompiler or another synthesis tool.

In the internal flow, you can integrate I/O pads and boundary scan into the design before thescan insertion step. Then, after you create the EDT logic, run Design Compiler to integrate thelogic into the design and synthesize it. TestKompress produces a Design Compiler script youcan use to synthesize the EDT logic and insert it into the design.

In either flow, once you are sure the design is functioning as desired, you generate test patternsusing TestKompress. In this step, TestKompress performs extensive DRC that, among otherthings, verifies the synthesized EDT logic.

NoteNotice that you run TestKompress twice: first to create the EDT logic and again togenerate compressed test patterns.

You should also verify that the design and patterns still function correctly with the propertiming information applied. You can use ModelSim or another simulator to achieve this goal.You may then have to perform a few additional steps required by your ASIC vendor beforehanding off the design for manufacture and testing.

Understanding the TestKompress FlowDesign Requirements


NoteIt is important to check with your vendor early on in your design process for specificrequirements and restrictions that may affect your compression strategy. In particular,you should determine the limitations of the vendor's test equipment. To plan effectivelyfor using EDT, you must know the number of channels available on the tester and itsmemory limits.

Design RequirementsBefore you begin a TestKompress flow, you must ensure your design satisfies the followingprerequisites:

FormatYour design input to TestKompress must be in gate level Verilog or VHDL. The logic createdby TestKompress is in Verilog or VHDL RTL.

Pin AccessAs 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 PadsThe next two sections describe the I/O pad requirements for each of the two TestKompressflows. These prerequisites are quite different depending on which flow, external or internal, youuse.

External Flow RequirementsTestKompress creates the EDT logic as a collar around the circuit (see Figure 1-3). Therefore,the core design ready for logic insertion must consist of only the core without I/O pads. In thisflow, TestKompress cannot insert the logic between scan chains and I/O pads already in thedesign.

NoteAdd the I/O pads around the collar after it is created, but before logic synthesis. The sameapplies to boundary scan cells: add them after the EDT logic is included in the design.

The design may or may not have I/O pads when you generate test patterns. For example, todetermine the expected test coverage, you can use TestKompress to perform a test patterngeneration trial run on the core when the EDT logic is created before inserting I/O pads.


Understanding the TestKompress FlowThe EDT Flows

August 2009

NoteYou should not save the test patterns TestKompress generates when the EDT logic iscreated, as these patterns do not account for how the I/O pads are integrated into the finalsynthesized design.

When producing the final patterns for a whole chip, run TestKompress on the synthesizeddesign after inserting the I/O pads.

For more information, refer to Chapter 3, “Managing Pre-existing I/O Pads.”

Internal Flow RequirementsThe core design, ready for EDT logic insertion, may include I/O pad cells for all the I/Os youinserted before or during initial synthesis. The I/O pads, when included, can be present at anylevel of the design hierarchy, and do not necessarily have to be at the top level. If the netlistincludes I/O pads, there should also be some pad cells reserved for EDT control and channelpins that are not going to be shared with functional pins. Refer to “Sharing Functional Pins withEDT Pins” in Chapter 4 for more information about pin sharing.

NoteThe design may have I/O pads; it is not a requirement. When the EDT logic is insertedinto the netlist, you can connect it to any internal design nodes or top level of the designnetlist.

The EDT FlowsThis section provides an overview of the steps you follow in each of the two EDT flows:

• External EDT Logic Flow (External Flow)

• Internal EDT Logic Flow (Internal Flow)

TestKompress supports mux-DFF and LSSD scan architectures, or a mixture of the two, withinthe same design. The tool creates DFF-based EDT logic by default. However, you can direct thetool to create latch-based IP for pure LSSD designs. Table 1-1 on page 12 summarizes the scanarchitecture combinations supported by TestKompress.



External EDT Logic Flow (External Flow)Figure 2-3 details the steps shown in grey in Figure 2-1, and shows the files used in the tool’sexternal flow. The basic steps in the flow are summarized in the following list. The chapters thatfollow 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-partytool. For information on how to do this using DFTAdvisor, refer to Chapter 5, “InsertingInternal 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). Usethis run to ensure there are no basic issues such as simulation mismatches caused by anincorrect library. If you want, you can run TestKompress in FastScan command-linemode to perform this step. See “Invoking TestKompress” on page 50 for information onhow to access the FastScan command-line mode.

4. Simulate the FastScan vectors (optional).

5. EDT logic Creation Phase: Invoke TestKompress on the scan-inserted gate leveldescription of the core without I/O pads or boundary scan. Create the RTL description ofthe EDT logic.

6. Insert I/O pads and boundary scan (optional).

7. Incrementally synthesize the I/O pads, boundary scan, and EDT logic.

8. EDT Pattern Generation Phase: After you insert I/O pads and boundary scan, andsynthesize all the added circuitry (including the EDT logic), invoke TestKompress onthe 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 forregular ATPG, the typical practice is to simulate all parallel patterns and a sample ofserial patterns.



August 2009

Figure 2-3. EDT External Flow with TestKompress

Synthesized

(no scan)

Create EDT logic

Netlist

ATPGScripts with scan

Netlist

RTLEDT

Synthesized

Patterns

GenerateEDT Patterns

Sign-offSimulation

Insert I/O Pads& JTAG

SynthesizeEDT logic & JTAG

Layout

Insert Scan

EDTScripts

Netlist withEDT logic

FromSynthesis



Internal EDT Logic Flow (Internal Flow)Figure 2-4 details the steps shown in grey in Figure 2-2, and shows the files used in the tool’sinternal flow. The basic steps in the flow are summarized in the following list. The chapters thatfollow describe each of these steps in detail.

1. Prepare and synthesize the RTL design, including boundary scan and I/O pads cells forall I/Os. Provide I/O pad cells for any EDT control and channel pins that will not beshared with functional pins.

NoteIn this step, you must know how many EDT control and channel pins are needed, so youcan provide the necessary I/O pads.

2. Insert an appropriately large number of scan chains using DFTAdvisor or a third-partytool. Be sure to add new primary input and output pins for the scan chains to the toplevel of the design. These new pins are only temporary; the signals to which theyconnect will become internal nodes and the pins removed when the EDT logic isinserted into the design and connected to the scan chains. For information on how toinsert scan chains using DFTAdvisor, refer to Chapter 5, “Inserting Internal Scan andTest Circuitry,” in the Scan and ATPG Process Guide.

NoteAs the new scan I/Os at the top level are only temporary, take care not to insert pads onthem.

3. Perform a FastScan ATPG run on the scan-inserted design without EDT (optional). Usethis run to ensure there are no basic issues such as simulation mismatches caused by anincorrect library. If you want, you can run TestKompress in FastScan command-linemode to perform this step. See “Invoking TestKompress” on page 50 for information onhow to access the FastScan command-line mode.

4. Simulate the FastScan vectors (optional).

5. EDT logic Creation Phase: Invoke TestKompress on the scan-inserted gate leveldescription of the core. Create the RTL description of the EDT logic. TestKompresscreates the EDT logic but does not incorporate it into the design; the Design Compilerscript the tool generates will perform EDT logic insertion and connection, in addition tosynthesis.

6. Run the Design Compiler script to instantiate the EDT logic in the top level of thedesign, connect the EDT logic between the design core and I/O pad cells, andincrementally synthesize the EDT logic.



August 2009

NoteThe EDT logic is always inserted at the top level within the original design.

7. EDT Pattern Generation Phase: After you insert the EDT logic, invoke TestKompresson the synthesized top level netlist (Verilog or VHDL) and generate the EDT testpatterns. 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 forregular ATPG, the typical practice is to simulate all parallel patterns and a sample ofserial patterns.



Figure 2-4. EDT Internal Flow with TestKompress

Synthesized

(no scan)

Create EDT logic

Netlist


Netlist

RTLEDT

Synthesized

Patterns

GenerateEDT Patterns

Sign-offSimulation

Insert I/O Pads& JTAG

Insert &Synthesize EDT logic

Layout

Insert Scan

EDTScripts

Netlist withEDT logic

FromSynthesis



August 2009


Chapter 3Scan Chain Synthesis

For ATEs with scan options, the number of channels is usually fixed and the only variableparameter 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 partof the TestKompress flow.

You can use DFTAdvisor or other scan insertion tool to insert scan chain circuitry in yourdesign before generating TestKompress (TK) logic. You can also generate the EDT logic beforescan chain insertion, For more information, see the “Integrating TestKompress at the RTLStage” on page 183 of this document.

Figure 3-1. Scan Chain Insertion and Synthesis Procedure

This chapter discusses each of the tasks outlined in Figure 3-1.

Preparing the DesignAs 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. Thefollowing 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.

Insert InternalScan/Test Circuitry

(DFTAdvisor)

Create

(TestKompress)EDT logic

Synthesizethe Design

3. Establishing a Compression Target

2. Inserting Scan Chains

1. Preparing the Design


Scan Chain SynthesisPreparing the Design

August 2009

External Flow

Managing Pre-existing I/O PadsBecause the synthesized hardware is added as a collar around the core design, the core shouldnot have I/O pads when you create the EDT logic. If the design has I/O pads, you need to extractthe core or remove the I/O pads.

NoteIf you must insert I/O pads prior to or during initial synthesis, consider using the internalflow, 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 logic around it.

3. Reinsert the EDT logic/core combination into the original circuit in place of the core youextracted, such that it is connected to the I/O pads.

NoteTestKompress also has a -Top invocation switch that enables you to run the tool on thecore. However, you must still use the -Top invocation switch in DFTAdvisor to extractthe 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 ablack box as a place holder that corresponds to the TK block. You can then stitch the I/O padsand, subsequently, the scan chains to this block. Once TestKompress creates the RTL model ofthe TK block, you use the RTL model as the new architecture or definition of the black boxplaceholder. The port names of the TK block must match those of the black box already in thedesign, so only the architectures need to be swapped.

Managing Pre-existing Boundary ScanIf your design requires boundary scan, you must add the boundary scan circuitry outside the toplevel wrapper created by TestKompress. The EDT logic is typically controlled by primary inputpins and not by the boundary scan circuitry. In test mode, the boundary scan circuitry just needsto be reset.

NoteIf you must insert boundary scan prior to or during initial synthesis, consider using theinternal flow, which is intended for pre-existing boundary scan or I/O pads.

Scan Chain SynthesisInserting Scan Chains


If the design already includes boundary scan, you need to extract the core or remove theboundary scan. This is the same requirement, described in the preceding section, that applies topre-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 synthesizethe EDT logic around it. Afterward, reinsert the EDT logic/core combination into the originalcircuit in place of the core you extracted, such that it is connected to the boundary scan circuitry.

NoteBoundary scan adds a level of hierarchy outside the EDT wrapper and requires you tomake certain modifications to the generated dofile and test procedure file that you use forthe test pattern generation.

For more complete information about including boundary scan, refer to Chapter 5, “AddingBoundary Scan (External Flow).”

Synthesizing a Gate-level Version of the DesignAs a prerequisite to starting the TestKompress flow, you need a synthesized gate level netlist ofthe core design without scan. As explained earlier, the design must not have boundary scan orI/O pads. You can synthesize the netlist using any synthesis tool and any technology.

Internal FlowThe EDT logic is connected between the I/O pads and the core, so the core should have I/O padcells in place for all the design I/Os. You also must add I/O pads for any EDT control andchannel pins that you do not want to share with the design’s functional pins. There are threemandatory EDT control pins: edt_clock, edt_update, and edt_bypass (unless you disable bypasscircuitry during setup); and 2n channel I/Os, where n is the number of external channels for thenetlist. Refer to “Understanding EDT Control and Channel Pins” in Chapter 4 for more detailedinformation about EDT control and channel pins.

Inserting Scan ChainsInsert an appropriately large number of scan chains. For testers with the scan option, the numberof channels is usually fixed, and the variable is the number of chains. Therefore, scanconfiguration is an important part of the TestKompress 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:

• Only full scan using the mux-DFF or LSSD scan cell type (or a mixture of the two) issupported. The tool creates DFF-based EDT logic by default; however, you can direct itto create latch-based logic for pure LSSD designs. Table 1-1 on page 12 summarizes the



August 2009

EDT logic/scan architecture combinations the tool supports. For information aboutspecific scan cell types, refer to “Scan Architectures” in the Scan and ATPG ProcessGuide.

• Both prefixed and bused scan input and output pins are allowed; however, the buses forbused 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 ofyour core design. For more information, see “Avoiding Sharing Scan Chain Pins withFunctional Pins” on page 44.”

• TestKompress does not support “dummy” scan chains as defined in FastScan. This isbecause EDT logic is dependent on the scan configuration, particularly the number ofscan chains. FastScan ATPG performance is independent of the scan configuration andcan assume that all scan cells are configured into a single scan chain when dummy scanchains are used.

NoteBecause TestKompress generates the RTL description of the EDT logic in Verilog orVHDL, you must save the scan-inserted design in one of these two formats.

Inserting Bypass Chains in the NetlistTestKompress can generate compression logic for netlists that contain two sets of pre-definedscan chains. This enables you to insert both the bypass chains for bypass mode and the core scanchains for compression mode into the netlist with a scan-insertion tool before the EDT logic isgenerated.

You can use any scan insertion tool, but you must adhere to the following rules when definingthe scan chains:

• Scan chains and bypass chains must use the same I/O pins.

• If the control pin used to select bypass or compression mode is shared with theedt_bypass pin, the bypass chains must be active when the edt_bypass pin is at 1, and thescan chains must be active when the edt_bypass pin is at 0.

• Test procedure file for the EDT logic must set up the mux select, so the shortenedinternal scan chains can be traced.

Inserting bypass chains with a scan insertion tool ensures that lockup cells and multiplexersused for bypass mode operation are fully integrated into the design netlist to allow moreeffective design routing.

For more information, see “Bypassing EDT Logic” on page 113.



Including Uncompressed Scan ChainsUncompressed scan chains, scan chains not driven by or observed through EDT logic, arepermitted in a design that uses TestKompress. You insert and synthesize them like any otherscan chains, but do not define them when creating the EDT logic.

You must define the uncompressed scan chain during test pattern generation using the Add ScanChains command without the -Internal switch.

You can set up uncompressed scan chains to share top-level pins by defining existing top-levelpins as equivalent or physically defining multiple scan chains with the same top-level pin. Formore information, see the Add Scan Chains and Add Pin Equivalences commands in the ATPGand Diagnosis Tools Reference Manual.

NoteBecause the uncompressed scan chains are not defined, the accuracy of the test coverageand scan data volume estimates as described in “Estimating Test Coverage and DataVolume” on page 90 may not be accurate. Skip this estimation step if your designcontains uncompressed chains.

For additional information, refer to the following sections:

• “Preparing for EDT Logic Creation” on page 51

• “Test Pattern Generation Files” on page 82

• “Preparing for Test Pattern Generation” on page 99

• “Each EDT block must have a discrete set of scan chains — Scan chains cannot beshared between blocks.” on page 161

Determining How Many Scan Chains to UseAlthough you generally determine the number of scan chains based on the number of scanchannels and the desired compression, routing congestion can create a practical limitation onthe number of scan chains a design can have. With a very large number of scan chains (usuallymore than a thousand), you can run into similar problems as for RAMs, where routing can be aproblem if several hundred scan chains start at the decompressor and end at the compactor.

Other reasons to decrease the number of scan chains might be to limit the number ofincompressible patterns and/or to reduce the pattern count. For more information, see“Compression Ratio” on page 23.

For testers with a scan option, the number of channels is usually fixed and the variable youmodify will be the number of chains. Because the effective compression will be slightly lessthan the ratio between the two numbers (the chain-to-channel ratio), in most cases it is sufficientto do an approximate configuration by using slightly more chains than indicated by the



August 2009

chain-to-channel ratio. How many more depends on the specific design and on your experiencewith TestKompress. 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 thanindicated by the chain-to-channel ratio). This typically results in 4.5 to 6X compression.

Using One Scan GroupEDT supports the use of exactly one scan group.

A scan group a grouping of scan chains based on operation. For more information, see the “ScanGroups” section of the Scan and ATPG Process Guide.

Avoiding Sharing Scan Chain Pins with Functional PinsWhen you perform scan insertion on the core design, you must not share any scan chain pinswith functional pins. You must connect the inserted scan chains to dedicated pins you create forthem at the top level.

If you use the external flow, these pins become internal nodes when the tool creates the TKwrapper. If you use the internal flow, the pins are removed when the EDT logic is instantiated inthe design and connected. Therefore, using dedicated pins does not increase the number of pinsneeded 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.

NoteYou can share functional pins with the external decompressor scan channel pins.Remember, these channels become the new “virtual” scan chains seen by the tester. Youspecify the number of channels, as well as any pin sharing, in a later step when you set upTestKompress for inserting the EDT logic. Refer to “Understanding EDT Control andChannel Pins” in Chapter 4 for more information.

NoteIf a scan cell drives a functional output, avoid using that output as the scan pin. If thatscan cell is the last cell in the chain, you must add a dedicated scan output.

Reordering Scan ChainsThe EDT logic (including bypass circuitry) depends on the clocking of the design. Whennecessary to prevent clock skew problems, TestKompress automatically includes lockup cells inthe EDT logic. If, after you create the EDT logic, you reorder the scan chains incorrectly, theautomatically inserted lockup cells will no longer behave correctly. The potential problem areasare the following:



• Between the decompressor and the scan chains (between the EDT clock and the scanclock(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 (betweendifferent scan clocks)

You can avoid regenerating the EDT logic by ensuring the following are true after you reorderthe 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 clockdomain. If both leading edge (LE) triggered and trailing edge (TE) triggered cells existin the same chain, do not move these two domains relative to each other. Afterreordering, the first and last cell in a chain do not have to be precisely the same cells thatoccupied those positions before reordering, but you do need to have the same clockdomains (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 LEtriggered, you do not have to preserve the clock domains at the beginning and end ofeach scan chain.

When all scan cells in the design are LE triggered, the lockup latch at the end of eachchain enables you to reorder however you want. You can move clock domains and youcan reorder across chains. But if there are both LE and TE triggered flip-flops, you mustmaintain the clock and edge at the beginning and end of each chain. Therefore, theeffectiveness and need of the lockup latch at the end of each chain depends on thereordering 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 testand a few patterns to ensure there are no problems. If you include bypass circuitry in the EDTlogic (the default), you should also create and serially simulate the bypass mode chain test and afew patterns.

Examining a DFTAdvisor Dofile Used with TestKompressAs previously mentioned, the scan chains for TestKompress must have dedicated pins. Toensure this is the case for the outputs, you must use the -Output New option with the Insert TestLogic command in DFTAdvisor. The following is an example dofile for inserting scan chainswith DFTAdvisor. Notice the use of “-output new” (shown in bold font) and the single scangroup:

// dfta.do//// DFTAdvisor dofile to insert scan chains for EDT.


Scan Chain SynthesisEstablishing a Compression Target

August 2009

// Setup required scan type and methodology: mux-DFF, full scan.set scan type mux_scansetup 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 invadd cell models latch -type dlat CLK D -active highset lockup latch on

// Setup Test Control Pins.setup scan insertion -sen scan_ensetup scan insertion -ten test_en

// Setup scan chain naming.setup scan pins Input -prefix edt_si -initial 1 -modifier 1setup scan pins Output -prefix edt_so -initial 1 -modifier 1

// Flatten design, run DRCs, and identify scan cells.set system mode dftreport statisticsadd clock groups grp1 clk1 clk2 clk3 clk4run

// 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.report scan chainsreport test logic

// Write output files.write netlist my_gate_scan.v - verilog -replacewrite 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

Establishing a Compression TargetThis is an optional step in the TestKompress 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 canobtain the same statistic for EDT test patterns. You then can assess the benefits ofTestkompress by comparing the volume figures in the two cases.

NoteDirectly comparing pattern counts is not meaningful because EDT patterns are muchsmaller than ATPG patterns. This is because the relatively short scan chains used in EDTrequire many fewer shift cycles per scan pattern.

• Provide additional help for debugging. You can simulate the patterns you generate inthis 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 createthe EDT logic.

NoteIf you include bypass circuitry, you also can run regular ATPG after you insert the EDTlogic.

Running FastScan ATPG (Optional)

NoteTo 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-linemode, enabling you to run it like a standalone version of FastScan (except for the absenceof the GUI). Alternatively, you can simply use FastScan.

This run is like any ATPG run and does not have any special settings; the key point to rememberis to use settings (pattern types, constraints, and so on) that are identical to those you use whenyou run TestKompress to generate compressed patterns.

The test procedure file you use for this FastScan run can, in theory, be identical to the onegenerated by DFTAdvisor. But, you should modify it to include the same timing, as specified bythe 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 savepatterns, you should also update the test procedure file with information for RAM clocks andfor non-scan-related procedures.

You can use the Report Scan Volume command in TestKompress and FastScan to perform amore accurate comparison of the scan data volume in each case and more clearly assess thebenefits of EDT.

Save the patterns you generate only if you want to simulate them.



August 2009

NoteThis ATPG run is only intended to provide test coverage and pattern volume informationfor plain ATPG. Save the patterns if you want to simulate them, but be aware that theyhave no other purpose. You generate and save the final compressed patterns when yourun TestKompress on the entire top-level design—after you have synthesized the I/Opads and EDT logic.

Simulating the FastScan Test Patterns (Optional)Like the FastScan test pattern generation described in the preceding section, simulating thegenerated patterns is an optional step in the TestKompress flow.

In the Mentor Graphics flow, you can use the ModelSim simulator or any other Verilogsimulator.


Chapter 4Creating EDT Logic

This chapter describes how to create and insert EDT logic into a scan-inserted design.Figure 4-1 shows the layout of this chapter as it applies to the process of creating and insertingthe EDT logic.

Figure 4-1. EDT Logic Creation Process

For more information on TestKompress commands, see the ATPG and Failure Diagnosis ToolsReference Manual.

About TestKompressTestKompress is used to accomplish two very different tasks:

1. Create the EDT logic

2. Generate EDT patterns

TestKompress provides a command-line interface. Before using TestKompress, you shouldbecome familiar with the basic process flow described in Chapter 2.

You should also understand 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”

Create

Insert Internal

(DFTAdvisor)

EDT logic(TestKompress)

Synthesize

(Design Compiler)EDT logic

Scan/Test Circuitry

3. Running DRC

2. Preparing for EDT Logic Creation

1. About TestKompress

6. Estimating Test Coverage and Data Volume

5. About the EDT Logic Files

4. Creating EDT Logic Files


Creating EDT LogicInvoking TestKompress

August 2009

Invoking TestKompressUse this procedure to invoke TestKompress to create or modify the logic and test patternsassociated with a compression application.

For more information on invoking TestKompress, see the testkompress command in the ATPGand Diagnosis Tool Reference Manual.

Prerequisites

Depending on your application, you must have a design in one of the following formats toinvoke TestKompress:

• A scan-inserted gate-level Verilog netlist and a compatible ATPG library of the modelsused for the scan circuitry invokes TestKompress in EDT mode.

For more information on the ATPG library, see the “Creating ATPG Models” in theDesign-for-Test Common Resources Manual.

• A flattened model created by FastScan invokes TestKompress in ATPG mode (FastScanemulation mode). You must also set EDT off once TestKompress invokes. For moreinformation, see the Set EDT command in the ATPG and Diagnosis Tool ReferenceManual.

Procedure

1. Enter the testkompress shell command along with the required arguments. For example:

<mgcdft tree>/bin/testkompress design1.v -lib lib42

TestKompress invokes on the design1.v netlist in Setup mode and ready to configure theEDT logic.

You can also use a dofile to invoke TestKompress and run many of the tasks described in thismanual. For example: 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 2set edt pins bypass my_bypass

// Run DRC.set system mode atpg

// Report and write EDT logic.

Creating EDT LogicPreparing for EDT Logic Creation


report edt configurationsreport edt pinswrite edt files created -verilog -replace

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

Preparing for EDT Logic CreationDepending on your application, the following subsections discuss the steps needed to preparefor creating/inserting EDT logic into your design. You can create the EDT logic immediatelyafter you insert scan chains, or you can run traditional ATPG and simulate the resulting vectorsfirst, as described in the Chapter 3 section, “Establishing a Compression Target.”

When TestKompress is invoked on a gate level netlist, EDT capability is on by default andSetup mode displays. EDT must be on whenever you are creating test patterns or logic for theTestKompress flow. You can use the Report Environment command to check the tool status.The following example shows this command output when EDT is on:

SETUP> report environment

EDT = ON (compressed patterns)

Defining Scan ChainsYou must define the clocks and scan chain information to set up TestKompress. You caninclude these commands in a dofile or invoke the dofile that DFTAdvisor generated to defineclocks 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.testprocadd scan chains chain1 grp1 edt_si1 edt_so1add scan chains chain2 grp1 edt_si2 edt_so2add scan chains chain3 grp1 edt_si3 edt_so3...add scan chains chain98 grp1 edt_si98 edt_so14add scan chains chain99 grp1 edt_si99 edt_so15add scan chains chain100 grp1 edt_si100 edt_so16add write controls 0 ramclkadd read controls 0 ramclk



August 2009

add clocks 0 clk

These commands are explained in “Defining the Scan Data” in the Scan and ATPG ProcessGuide.

Setting Parameters for the EDT LogicUse the Set EDT command to set parameters for the EDT logic. The two most importantparameters are the position of the EDT logic, internal or external, with respect to the originalnetlist the tool read in, and the number of scan channels. For a basic run to create external EDTlogic (the default), you only need to specify the number of channels. For example, the followingcommand sets up 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 toinclude bypass circuitry in the EDT logic, lockup cells in the decompressor, and/or pipelinestages in the compactor. By default, TestKompress generates:

• DFF-based EDT logic

• Lockup cells in the decompressor, compactor, and bypass logic

• An Xpress compactor without pipeline stages

• Bypass logic

For more information, see the Set EDT command in the ATPG and Failure Diagnosis ToolsReference Manual.

The following topics describe other commonly used parameter settings:

• Defining Dual Compression Configurations

• Specifying a Different Number of Input and Output Channels

• Specifying Latch-Based EDT logic

• Including Pipeline Stages in the Compactor

• Specifying a Compactor Type

• Specifying Boundaries for the Longest Scan Chain

• Including a Reset for the EDT logic

• Specifying the Version of the EDT Architecture

• Generating EDT Logic When Bypass Logic is Defined in the Netlist

• Setting EDT Clock to Pulse Before Scan Shift Clocks



Defining Dual Compression ConfigurationsUse this procedure to create two compression configurations when setting up the EDT logic.Using two compression configurations allows you to easily set up and reuse the EDT logic fortwo different test phases. For example, wafer test vs. package test.

When two distinct configurations are defined, an additional EDT pin is generated to select theactive configuration: edt_configuration. For more information on EDT pins, see“Understanding EDT Control and Channel Pins” on page 59.

Separate dofiles and procedure files for ATPG are created for each configuration. One dofileand test procedure file is generated for the bypass mode. These ATPG files are then used togenerate test patterns for each configuration separately as you would with a single compressionconfiguration.

Limitations

• Only two configurations can be defined for any design/design block.

• In the modular flow, you should coordinate compression configuration usage betweendesign groups to ensure that the compression configurations are defined and set upproperly for each block as follows:

o The same two compression configurations must be defined across all blocks.

o The same configuration must always be defined as the highest compressionconfiguration across all blocks.

o To create a single compression configuration for a block, only define parameters forone of the compression configurations.

• Both the input and output channels of one configuration must be equal to or greater thanboth the input and output channels of the other configuration. For example:

The following configurations are supported:

Config1 = 6 input channels and 5 output channelsConfig2 = 5 input channels and 5 output channels

The following configurations are not supported:

Config1 = 6 input channels and 4 output channelsConfig2 = 5 input channels and 5 output channels.

• The channels for the high compression configuration cannot be explicitly specified. Bydefault, the high-compression configuration uses the first channels defined for thelow-compression configuration. This applies to both input and output channels.

• Bypass mode is supported for the low-compression configuration only. You can definethe number of bypass chains in either of the configurations as long as the specified



August 2009

number is less than the number of bypass chains TestKompress generates by default.The default number of bypass chains is determined by the following formula:

(maximum of ( minimum of (#inputs, #outputs) of config1, minimum of(#inputs, #outputs) of config2))

For more information on bypass mode, see “Bypassing EDT Logic” on page 113.

• You cannot generate test patterns during EDT logic creation to determine the testcoverage. TestKompress does not support this feature for EDT logic that includes twoconfigurations. For more information, see “Estimating Test Coverage and DataVolume” on page 90.

• The Basic compactor does not support more than one configuration. By defaultTestKompress generates logic that contains the Xpress compactor. For moreinformation on compactors, see “Understanding Compactor Options” on page 147.

• There are no DRCs specific to dual compression configurations, so you must run DRCon each configuration in the test pattern generation phase. For more information, see“Generating Test Patterns” on page 106.

Prerequisites

• Scan chains must be defined. For more information, see “Defining Scan Chains” onpage 51.

Procedure

Use this procedure to create EDT logic with two compression configurations for a single designblock.

1. Invoke TestKompress. For example:

mgcdft tree>/bin/testkompress my_gate_scan.v -verilog \-lib my_lib.atpg

TestKompress invokes in Setup mode.

2. Define the first compression configuration. For example:

add edt configurations config1set edt -input_channels 6 -output_channels 5

3. Define the second configuration. For example:

add edt configurations config2set edt -input_channels 3 -output_channels 3

To create a single compression configuration for a block, only define parameters for oneof the compression configurations.

4. Define the remaining parameters for the EDT logic. See “Setting Parameters for theEDT Logic” on page 52.



5. Run DRC and fix any violations. See “Running DRC” on page 69. You must run DRCon each configuration.

6. Generate the EDT logic. For more information, see “Creating EDT Logic Files” onpage 71. A separate dofile and procedure file is created for each configuration. Theconfiguration name is appended to the prefix specified with the Write EDT Filescommand:

<filename_prefix>_<configuration_name>_edt.dofile<filename_prefix>_<configuration_name>_edt.testproc

Examples

The following example shows a dofile that creates dual compression configurations for a singleblock.

// edt_ip_creation.do//// Dofile for EDT logic Creation Phase// Execute setup script from DFTAdvisordofile scan_chain_setup.dofile

// Set up EDT configurationsadd edt configurations my_pkg_test_configset edt -channels 16add edt configurations my_wafer_test_configset edt -channels 2

// Set bypass pinset edt pins bypass my_bypass_pin

//Set edt configuration pinset edt pins edt_configuration my_configuration_pinset sys mode atpg

// Report and write EDT logic.report edt configurations -all //reports configurations for all blocks.report edt pins //reports all pins including compression configurationspecific pins.write edt files created -verilog -replace //Create dofiles andtestprocedure files for both the configurations and the bypass mode

The following example shows a dofile that sets up modular TK blocks with dual compressionconfigurations at the top-level.

// Set up dual compression configurationsadd edt configuration manufacturing_testadd edt block B1set edt -pipe 2 -channels 4add edt block B2set edt -channels 1add edt block B3set edt -channels 2

add edt configuration system_test



August 2009

set current block B1set edt -channels 2set current block B2set edt -channels 1set current block B3set edt -channels 1// Set up top-level clocks and channel pins for each blockset current block B1add clocks 0 clkadd clocks 0 reset

dofile scan/atpg1.dofile_topset edt pins in 1 coreA_channel_in1set edt pins out 1 coreA_channel_out1set edt pins in 2 coreA_channel_in2set edt pins out 2 coreA_channel_out2set edt pins in 3 coreA_channel_in3set edt pins out 3 coreA_channel_out3set edt pins in 4 coreA_channel_in4set edt pins out 4 coreA_channel_out4

set current block B2dofile scan/atpg2.dofile2set edt pins in 1 coreB_channel_in1set edt pins out 1 coreB_channel_out1

set current block B3dofile scan/atpg3.dofile3set edt pins in 1 coreC_channel_in1set edt pins out 1 coreC_channel_out1set edt pins in 2 coreC_channel_in2set edt pins out 2 coreC_channel_out//Run DRCset system mode atpg//Report EDT configuration and generate EDT logicreport edt configuration –all -verbose

write edt files ./edt_ip/created1_core_top -verilog -synth dc_shell -replace -rtl_prefix chip_level

exit -d

Related Topics

Specifying a Different Number of Input and Output ChannelsYou can specify a different number of input versus output channels for EDT logic with the-Input_Channels and -Output_Channels switches.

Add EDT Configurations Report EDT Configurations

Delete EDT Configurations Set Current Configuration



Specifying Latch-Based EDT logicTestKompress supports mux-DFF and LSSD scan architectures, or a mixture of the two, withinthe same design. The tool creates DFF-based EDT logic by default. If you have a pure LSSDdesign and prefer the logic to be latch-based, you can use the -Clocking switch to get the tool tocreate latch-based EDT logic.

Specifying a Compactor TypeUse the -COMpactor_type switch to specify which compactor is used in the generated EDTlogic. By default the Xpress compactor is used. For more information, see “UnderstandingCompactor Options” on page 147.

Including Pipeline Stages in the CompactorThe EDT logic can be set up to include pipeline stages between logic levels within thecompactor. The -PIpeline_logic_levels_in_compactor switch allows you to specify a maximumnumber of logic levels (XOR gates) in a compactor before pipeline stages are inserted. Bydefault, no pipeline stages are inserted. For more information, see “Using Pipeline Stages in theCompactor” on page 128.

Specifying Boundaries for the Longest Scan ChainSometimes, you may need to change the length of the scan chains in your design aftergenerating the EDT logic. Ordinarily, you must regenerate the EDT logic when such a changealters the length of the longest scan chain.

During setup, before you generate the EDT logic, you can optionally specify a length range forthe longest scan chain using the -Longest_chain_range switch. As long as any subsequent scanchain modifications do not result in the longest scan chain exceeding the boundaries of thisrange, you will not have to regenerate the EDT logic because of a shortening or lengthening ofthe longest chain.

NoteThis applies only to scan chain length. Other scan chain changes, such as reordering thescan chains may require EDT logic regeneration. For more information, see “ReorderingScan Chains” on page 44”.

Including a Reset for the EDT logicThe EDT logic may optionally include an asynchronous reset signal that resets all the sequentialelements in the logic. Use “-reset_signal asynchronous” with the Set EDT command if you wantthe EDT logic to include this signal. If you choose to include the reset, the hardware will alsoinclude a dedicated control pin for it (named “edt_reset” by default).



August 2009

Specifying the Version of the EDT ArchitectureTo ensure backward compatibility between older EDT logic architectures (created with olderversions of the tool) and pattern generation in the current version of the tool, use the -Ip_versionswitch. This enables you to specify the version of the EDT architecture TestKompress shouldexpect in the design. In the EDT logic creation phase, TestKompress writes a dofile containingEDT-specific commands for use in the Pattern Generation Phase. Any Set EDT commandsincluded 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.

NoteThe logic version is incremented only when the hardware architecture changes. If theTestKompress software is updated, but the logic generated is still functionally the same,only the software version changes.

You can generate test patterns for the older EDT logic architectures, but by default, the EDTlogic version is assumed to be the currently supported version.

Setting EDT Clock to Pulse Before Scan Shift ClocksYou can set up the EDT clock to pulse before the scan chain shift clocks with the-pulse_edt_before_shift_clocks switch of the Set EDT command. By default, the EDT and scanchain shift clocks are pulsed simultaneously. Setting the EDT logic up this way makes itindependent of the scan chain clocking and provides the following benefits:

• Makes creating EDT logic for a design in the RTL stage easier because scan chainclocking information is not required. For more information on creating EDT logic at theRTL stage, see “Integrating TestKompress at the RTL Stage” on page 183.

• Removes the need for lockup cells between scan chains and the EDT logic becausecorrect timing is ensured by the clock sequence. Only a single lockup cell between pairsof bypass scan chains is necessary. For more information, see “Understanding HowLockup Cells are Inserted” on page 134.

• Simplifies clock routing because the lockup cells used for bypass scan chains are drivenby the EDT clock instead of a system clocks. This eliminates the need to route systemclocks to the EDT logic.

To use this functionality, the shift speed must be able to support two independent clock pulsesin one shift cycle, which may increase test time.

Reporting the EDT Logic ConfigurationYou can report the current EDT logic configuration with the Report EDT Configurationscommand. This command lists configuration details including the number of scan channels andlogic version. For example:



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

NoteBecause the Report EDT Configurations command needs a flat model and DRC results toproduce the most useful information, you usually use this command in other than Setupmode. For an example of the command’s output when issued after DRC, see “DRC whenEDT Pins are Shared with Functional Pins” later in this chapter.

Understanding EDT Control and Channel PinsThe EDT logic includes the following pins:

• Scan channel input pins

• Scan channel output pins

• EDT clock

• EDT update

• Scan-enable (optional—included when any scan channel output pins are shared withfunctional pins)

• Bypass mode control

• Reset control (optional—included when you specify an asynchronous reset for the EDTlogic)

• EDT_configuration (optional—included when you specify multiple configurations)

Figure 4-2 shows the basic configuration of these pins for an example design when the EDTlogic is instantiated externally and configured with bypass circuitry and two scan channels.External EDT logic is always instantiated in a top level EDT wrapper.



August 2009

Figure 4-2. Example of a Basic EDT Pin Configuration (External EDT Logic)

The default configuration consists of pins for the EDT clock, update, and bypass inputs. Thereare also two additional pins (one input and one output) for each scan channel. If you do notrename an EDT pin or share it with a functional pin, as described in the “Sharing FunctionalPins with EDT 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 -// Scan channel 2 input edt_channels_in2 -// " " " output edt_channels_out2 -

Figure 4-3 shows how the preceding pin configuration looks if the EDT logic is inserted into adesign netlist that includes I/O pads (internal EDT logic location). Notice that the EDT controland channel I/O pins are now connected to internal nodes of I/O pads that are part of the coredesign. You set up these connections by specifying an internal node for each EDT control and

DesignPrimaryInputs

DesignPrimaryOutputs

Wrapper

EDT logic

Core

portain[6]

portain[5]

a1

update

clock

scan_enable

bypassedt_bypass

a1

q1

q2

output

outputinput

input

portain[7]

edt_channels_out1

portain[7]

portain[6]

portain[5]

q1

q2

scan_enable

edt_channels_out2

edt_channels_in1

edt_channels_in2

edt_clock

edt_update

ch. 1 ch. 1

ch. 2 ch. 2



channel I/O pin. For more information, see Specifying Connections for EDT Pins (InternalFlow only).

Figure 4-3. Example of a Basic EDT Pin Configuration (Internal EDT Logic)

Sharing Functional Pins with EDT PinsEDT pins can be shared with functional pins, with a few restrictions. You use the Set EDT Pinscommand to specify sharing of an EDT pin with a functional pin and to specify whether a signalis inverted in the I/O pad for the pin. For more information, see the Set EDT Pins command.

When you share a channel output pin with a functional pin, TestKompress inserts a multiplexerbefore the output pin. This multiplexer is controlled by the scan-enable signal, and you mustdefine the scan_enable signal with the Set EDT Pins command. If you do not define thescan-enable signal, the tool defaults to “scan_en”, and adds this pin if it does not exist. DuringDRC, all added pins are reported with K13 DRC messages. You can report the exact names ofadded pins using the Report Drc Rules command.

For channel input pins and control pins, you use the -Inv switch to specify (on a per pin basis) ifa signal inversion occurs between the chip input pin and the input to the EDT logic. Forexample, if an I/O pad you intend to use for a channel pin inverts the signal, you must specifythe inversion when creating the EDT logic. TestKompress requires the pin inversion

DesignPrimaryInputs


Design Core with I/O pads

EDT logic

Module A

portain[6]

portain[5]

a1

update

clock

scan_enable

bypassedt_bypass

a1

q1

q2

output

outputinput

input

portain[7]

edt_channels_out1

portain[7]

portain[6]

portain[5]

q1

q2

scan_enable

edt_channels_out2

edt_channels_in1

edt_channels_in2

edt_clock

edt_update

ch. 1 ch. 1

ch. 2 ch. 2

internal node(I/O pad output)

internal node(I/O pad input)



August 2009

information, so the generated test procedure file operates correctly with the full netlist for testpattern generation.

If bypass circuitry is implemented, you need to force the bypass control signal to enable ordisable bypass mode. When you use TestKompress to generate EDT patterns, you disablebypass mode by setting the control signal to the off state. When you generate regular ATPGpatterns, using FastScan for example, you must enable the bypass mode by setting the bypasscontrol signal to the on state. The logic level associated with the on or off state depends onwhether you specify to invert the signal. The bypass control pin is forced in the automaticallygenerated test procedure.

In all cases, EDT pins that are shared with bidirectional pins must have the output enable signalconfigured so that the pin has the correct direction during scan. The following list describes thecircumstances 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 thecore level. This is because the tool includes a multiplexer between the compactor and the outputpad when a channel output pin is shared, and tri-state values cannot pass through themultiplexer. A scan channel output pin that later will be connected to a pad and is bidirectionalat the top level is allowed.

NoteScan channel output pins that are bidirectional need to be forced to Z at the beginning ofthe load_unload procedure. Otherwise, the tool is likely to issue a K20 or K22 ruleviolation during DRC, without indicating the reason.

EDT clock — Must be defined as a clock and constrained to its defined off state. If shared witha bit of a bus, problems can occur during synthesis. For example, Design Compiler (DC) doesnot accept a bit of a bus being a clock. The EDT clock pin must only be shared with a non-clockpin that does not disturb scan cells; otherwise, the scan cells will be disturbed during theload_unload procedure when the EDT clock is pulsed. This restriction might cause somereduced coverage. You should use a dedicated pin for the EDT clock or share the EDT clock pinonly with a functional pin that controls a small amount of logic. If any loss of coverage is notacceptable, then you must use a dedicated pin.

EDT reset — Should be defined as a clock and constrained to its defined off state. If sharedwith a bit of a bus, problems can occur during synthesis. For example, DC does not accept a bitof a bus being a clock. The EDT reset pin must only be shared with a non-clock pin that doesnot disturb scan cells. This restriction might cause some reduced coverage. You should use adedicated pin for the EDT reset, or share the EDT reset pin only with a functional pin thatcontrols a small amount of logic. If any loss of coverage is not acceptable, then you must use adedicated pin.



EDT update — Can be shared with any non-clock pin. Because the EDT update pin is notconstrained, sharing it has no impact on test coverage.

Scan enable — As for regular ATPG, this pin must be dedicated in test mode; otherwise, thereare no additional limitations. EDT only uses it when you share channel output pins. Because it isnot constrained, sharing it has no impact on test coverage.

Bypass (optional) — Must be forced during scan (forced on in the bypass test procedures andforced off in the EDT test procedures). It is not constrained, so sharing it has no impact on testcoverage. For more information on bypass mode, see Chapter 7, “Bypassing EDT Logic.”

Edt_configuration (optional) — The value corresponding with the selected configuration mustbe forced on during scan chain shifting.

NoteRTL generation allows sharing of control pins. The preceding restrictions ensure the EDTlogic operates correctly and with only negligible loss, if any, of test coverage.

Configuring Shared PinsThe synthesis methodology does not change when you specify pin sharing. You do, however,need to add a step to the EDT logic creation phase. In this extra step, you define how pins areshared. For example, you are using the external flow with two scan channels and you want toshare three of the channel pins, as well as the EDT update and EDT clock pins, with functionalpins. Assume the functional pins have the names shown in Table 4-1.

You can see the names of the EDT pins, prior to setting up the shared pins, by issuing the ReportEDT Pins command:


Table 4-1. Example Pin Sharing

EDT Pin Description Functional Pin Name

Input 1 (Channel 1 input) portain[7]

Output 1 (Channel 1 output) edt_channels_out1(new pin, default name)

Input 2 (Channel 2 input) portain[6]

Output 2 (Channel 2 output) q2

Update portain[5]

Clock a1

Bypass my_bypass(new pin, non-default name)



August 2009

// 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 -// Scan channel 2 input edt_channels_in2 -// " " " output edt_channels_out2 -

Use the Set EDT Pins command to specify the functional pin to share with each EDT pin. Withthis command, you can specify to tap an EDT pin from an existing core pin. You also can usethe 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.

NoteIn the external flow, the pin sharing you specify is implemented in a wrapper the toolcreates when you generate the EDT logic. The “Top-level Wrapper” section containsadditional information about this wrapper. In the internal flow, the pin sharing isimplemented when you insert and synthesize the EDT logic.

When the pin you specify in the command already exists in the core, TestKompress will sharethe EDT signal with that pin. The figure shows an example of this for the EDT clock signal. Thecommand, “set edt pins clock a1”, will cause TestKompress to share the EDT clock with the a1pin instead of creating a dedicated pin for the EDT clock. If you specify a pin name that doesnot exist in the core, the tool will create a dedicated EDT pin with the specified name. Forexample, “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 defaultname is unique, TestKompress creates a dedicated pin with the default name. If the defaultname is the same as a core pin name, the tool automatically shares the EDT pin with that corepin. 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 theindex number of the channel



When you share a pin between an EDT channel output and a core output, TestKompressincludes a multiplexer in the circuit together with the EDT logic, but in a separate module at thetop 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 thedefined scan enable pin. If a scan enable pin is not defined, the tool adds one with the EDTdefault 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 q2SETUP> set edt pins update portain[5]SETUP> set edt pins clock a1SETUP> set edt pins bypass my_bypass

If you report the EDT pins using the “report edt pins” command after issuing the precedingcommands, you will see that the shared EDT pins have the same name as the functional corepins. You will also see, for each pin, whether the pin’s signal was specified as inverted. Noticethat the listing now includes the scan enable pin because of the shared EDT output pin:


// Pin description Pin name Inversion// --------------- -------- ---------// Clock a1 -// Update portain[5] -// Scan enable scan_enable -// Bypass mode my_bypass -// Scan channel 1 input portain[7] -// " " " output edt_channels_out1 -// Scan channel 2 input portain[6] -// " " " output q2 -

Scan Channel Output “edt_channels_out” followed bythe index number of the channel

EDT configuration select edt_configuration

Table 4-2. Default EDT Pin Names

EDT Pin Description Default Name



August 2009

Figure 4-4. Example with Pin Sharing Shown in Table 4-1(External EDT Logic)

After DRC, you can use “report drc rules k13” to see a report of the pins the tool will add to thetop level of the design to implement the EDT logic.

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 Connections for EDT Pins (Internal Flow only)For the internal flow, you must specify the name of each internal node (instance pin name) toconnect each EDT control and channel pin. For more information, see the Set EDT Pinscommand.

NoteBefore specifying internal nodes, you must specify internal logic placement with the SetEDT -location internal command.

For every EDT pin, you should provide the name of a design pin and the corresponding instancepin name for the internal node that corresponds to it. The latter is the input (or output) of an I/Opad cell where you want the tool to connect the output (or input) of the EDT logic. For example:

DesignPrimaryInputs


Wrapper

EDT logic

Core

portain[6]

portain[5]

a1

update

clock

scan_enable

bypassmy_bypass

a1

q1

q2

portain[7]

edt_channels_out1

portain[7]

portain[6]

portain[5]

q1

q2

scan_enable

inputch. 1

inputch. 2

output

output

ch. 1

ch. 2



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 padinstance. The last argument is the instance pin name of the internal node of the pad. The padinstance 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 specifyan I/O pad pin name, but not a corresponding internal node name, the EDT logic is connecteddirectly 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 bythe default name, it adds a new port for the EDT pin at the top level of the design. You will needto add a pad later that corresponds to that port.

For the internal flow, the Report EDT Pins command displays an additional column that lists thenames of the nodes to which the EDT pins are connected. For example (note that the pininversion 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//

Specifying Internally Driven EDT PinsWhen an EDT control pin is driven internally by JTAG or other control registers (Figure 4-5),you should use the Set EDT Pins command to specify that no top level pin exists for the controlpin.



August 2009

Figure 4-5. Internally Driven edt_update Control Pin

Specifying these types of pins prevents false K5 DRC violations. You should specify internallydriven pins in one of the following ways:

• EDT logic creation

a. Specify the internal node that drives the control pin during logic creation. Forexample:

SETUP> set edt -location internalSETUP> set edt pins update - JTAG/update_ctrlSETUP> set system mode ATPGSETUP> write edt files my_design -verilog -replace

Where JTAG/update_ctrl is the internal node driving the update control pin.

b. Edit the test procedure file to include any procedures or pin constraints needed todrive the specified internal node (JTAG/update_ctrl) to the correct value.

• Pattern generation

a. Specify the internally driven control pin has no top-level pin during test patterngeneration. For example:

ATPG> set edt pins update -ATPG> add faults /my_designATPG> create patterns

DesignPrimaryInputs


Design Core with I/O pads

EDT logic

Module A

portain[6]

portain[5]

a1

update

clock

scan_enable

bypassedt_bypass

a1

q1

q2

output

outputinput

input

portain[7]

edt_channels_out1

portain[7]

portain[6]

portain[5]

q1

q2

scan_enable

edt_channels_out2

edt_channels_in1

edt_channels_in2

edt_clock

ch. 1 ch. 1

ch. 2 ch. 2

update_ctrl

JTAG

Creating EDT LogicRunning DRC


NoteInput and output channels must always have a corresponding top-level pin.

Customizing the Structure of the Bypass ChainsWhen bypass logic is generated, the connections for each bypass chain are automaticallyconfigured. These interconnections are fine for most designs. However, you can specify customchain connections with the Set Bypass Chains command.

For more information, see “Bypassing EDT Logic” in Chapter 7.

Customizing the Compactor ConnectionsAfter 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 whichscan chain outputs to compact into each channel output. The tool’s determination is fine formost designs; however, you can use the Set Compactor Connections command to override thetool and specify your own choice of chain outputs to compact into each scan channel output.

Running DRCDRC 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 referenceinformation on each EDT-specific rule.

Notice the DRC message describing the EDT rules in the following example transcript. Thistranscript is for the design with two scan channels shown in Figure 4-2, in which none of theEDT pins are shared with functional pins:

// ------------------------------------------------------// Begin EDT rules checking.// ------------------------------------------------------// Running EDT logic Creation Phase.// 7 pin(s) will be added to the EDT wrapper. (K13)// EDT rules checking completed, CPU time=0.01 sec.// All scan input pins were forced to TIE-X.// All scan output pins were masked.// ----------------------------------------------------------

These messages indicate TestKompress will add seven pins, which include scan channel pins, tothe top level of the design. The last two messages refer to pins at either end of the core level


Creating EDT LogicRunning DRC

August 2009

scan chains. Because these pins are not connected to the top level wrapper (external flow) or thetop level of the design (internal flow), the tool does not directly control or observe them in thecapture cycle when generating test patterns. To ensure values are not assigned to the internalscan input pins during the capture cycle, the tool automatically constrains all internal scan chaininputs to X (hence, the “TIE-X” message). Similarly, TestKompress masks faults that propagateto the scan chain output nodes. This ensures a fault is not counted as observed until it propagatesthrough the compactor logic. The tool only adds constraints on scan chain inputs and outputsadded within the tool as PIs and POs.

NoteTo properly configure the internal scan chain inputs and outputs so TestKompress canconstrain them as needed, you must use the -Internal switch with the Add Scan Chainscommand when setting up for pattern generation in the Pattern Generation Phase. Thisswitch does, on internal scan nodes, the same thing that the Add Primary Inputs and AddPrimary Outputs commands do on non-EDT designs.

DRC when EDT Pins are Shared with Functional PinsIf you specified to share any EDT pin with a functional pin, DRC will include messages for Krules affected by the sharing. Here is DRC output for the design shown in Figure 4-2, after it isre-configured to share certain EDT pins with functional pins, as illustrated in Figure 4-4:

// ----------------------------------------------------------// Begin EDT rules checking.// ----------------------------------------------------------// Running EDT logic Creation Phase.// Warning: 1 EDT clock pin(s) drive functional logic. May lower test coverage when pin(s) are constrained. (K12)// 2 pin(s) will be added to the EDT wrapper. (K13)// EDT rules checking completed, CPU time=0.00 sec.// All scan input pins were forced to TIE-X.// All scan output pins were masked.// ----------------------------------------------------------

Notice only two EDT pins are added, as opposed to seven pins before pin sharing. Shared pinscan create a test situation in which a pin constraint might reduce test coverage. The K12warning about the shared EDT clock pin points this out to you. For details, refer to “SharingFunctional Pins with EDT Pins” on page 61.

If you report the current configuration with the Report EDT Configurations command afterDRC, you will get more useful information. For example:

ATPG> report edt configurations

// IP version: 1// Shift cycles: 381, 373 (internal scan length) + 8 (additional cycles)// External scan channels: 2// Internal scan chains: 16

Creating EDT LogicCreating EDT Logic Files


// 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 thelongest chain. This is because the EDT logic requires additional cycles to set up thedecompressor for each EDT pattern (eight in this example). The number of extra cycles isdependent on the EDT logic and the scan configuration.

Creating EDT Logic FilesOnce the EDT logic parameters are specified, use the Write EDT Files command create the filesthat make up the logic. By default, TestKompress writes the RTL files in the same format as theoriginal netlist, either Verilog or VHDL. For example:

ATPG> write edt files created -replace

Where created is the name string prepended to the files and -replace is a switch that allowsTestKompress to overwrite any existing files with the same name.

Depending on the EDT logic placement, the following EDT logic files are created:

• created_edt_top.v (external EDT logic only) — Top level wrapper that instantiates thecore, EDT logic circuitry, and channel output sharing multiplexers.

• created_edt.v — EDT logic description.

• created_core_blackbox.v (external EDT logic only) — Blackbox description of thecore for synthesis.

• created_dc_script.scr — DC synthesis script for the EDT logic.

• created_edt.dofile — Dofile for test pattern generation.

• created_edt.testproc — Test procedure file for test pattern generation.

• created_bypass.dofile — Dofile for uncompressed test patterns (bypass mode)

• created_bypass.testproc — Test procedure file for uncompressed test patterns (bypassmode)

Specifying Module/Instance NamesBy default, TestKompress prepends the name of the top module in the associated netlist to thenames of modules/instances in the generated EDT logic files. This ensures that internal namesare unique, as long as all module names are unique.


Creating EDT LogicAbout the EDT Logic Files

August 2009

If necessary, you can specify the prefix used for internal modules/instance names in the EDTlogic with the Write EDT Files -rtl_prefix prefix_string command. For example:

write edt files... -rtl_prefix core1

All internal module/instance names are prepended with core1 instead of the top module name.

NoteThe specified string must follow the standard rules for Verilog or VHDL identifiers.

About the EDT Logic FilesThe structure of the logic described in the files TestKompress generates depends on thefollowing:

• Location of the EDT logic (internal or external with respect to the design netlist)

• Number of external scan channels

• Number of internal scan chains and the length of the longest chain

• Clocking of the first and last scan cell in every chain (if lockup cells are inserted)

• Names of the pins

Except for the clocking of the scan chain boundaries, which affects the insertion of lockup cells,nothing in the EDT logic depends on the functionality of the core logic.

NoteGenerally, you must regenerate the EDT logic if you reorder the scan chains and theclocking of the first and last scan cell or the scan chain length is affected. See“Reordering Scan Chains” on page 44.

The following sections describe the files generated for the EDT logic.

Top-level WrapperFigure 4-6 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-6. Contents of the Top Level Wrapper

This netlist contains a module, “edt_top”, that instantiates your original core netlist and an “edt”module that instantiates the EDT logic circuitry. If any EDT pins are shared with functionalpins, “edt_top” instantiates an additional module called “edt_pinshare_logic” (shown as theoptional block in Figure 4-6). The EDT pins and all functional pins in the core are connected tothe wrapper. Scan chain pins are not connected because they are driven and observed by the TKblock.

Because scan chain pins in the core are only connected to the “edt” block, these pins must not beshared with functional pins. For more information, refer to “Avoiding Sharing Scan Chain Pinswith Functional Pins,” in Chapter 3. Scan channel pin sharing (or renaming) that you specifiedusing the Set EDT Pins command is implemented in the top-level wrapper. This is discussed indetail in “Sharing Functional Pins with EDT Pins,” earlier in the chapter.

EDT Logic CircuitryFigure 4-7 shows a conceptual view of the contents of the file, created_edt.v.

edt_top

edt

core

Scan chain outs

Scan chain out

FunctionalOutput

Pins

Scan chain in

Functional

edt_clockedt_updateedt_bypass

Scan channel outsScan channel ins

Scan chain ins

InputPins

}

}

}

}

edt_pinshare_logic(optional)



August 2009

Figure 4-7. Contents of the EDT Logic

This file contains the top level module, which instantiates three main blocks:

• decompressor — connected between the scan channel input pins and the internal scanchain inputs

• compactor — connected between the internal scan chain outputs and the scan channeloutput pins

• bypass logic — connected between the EDT logic and the design core. Bypass logic isoptional but generated by default.

CoreGenerated only when the EDT logic is inserted external to the design core, the filecreated_core_blackbox.v contains a black-box description of the core netlist. This can be used

EDT logic

edt_decompressor

Scan chain inputs

Scan

Scan

edt_clockedt_update

edt_bypass

Scan channel

} }

ChainInputs

}

From

ChannelOutputs

Scan chainOutputs

edt_bypass_logic

Inputs

edt_compactor

edt_clockedt_update

}

Scan chainOutputs

ScanChannelOutputs

To core

InputPins

ToOutputPins

FromCore

}}

}

}



when synthesizing the TK block so the entire core netlist does not need to be loaded into thesynthesis tool.

NoteLoading the entire design is advantageous in some cases as it helps optimize the timingduring synthesis.

Synthesis Script External FlowTestKompress generates a sample Design Compiler (DC) synthesis script,created_dc_script.scr. By default, the script is in Tool Command Language (TCL), but you canget the tool to write it in DC command language (dcsh) by including a “-synthesis_scriptdc_shell” argument with the Write EDT Files command.

The following is an example script, in the default TCL format, for a core design that contains atop level Verilog module named “cpu”:

#************************************************************************# Synopsys Design Compiler synthesis script for created_edt_top.v##************************************************************************

# Read input design filesread_file -f verilog created_core_blackbox.vread_file -f verilog created_edt.vread_file -f verilog created_edt_top.v

current_design cpu_edt_top

# Check design for inconsistenciescheck_design

# Timing specificationcreate_clock -period 10 -waveform {0 5} edt_clock

# Avoid clock buffering during synthesis. However, remember# to perform clock tree synthesis later for edt_clockset_clock_transition 0.0 edt_clockset_dont_touch_network edt_clock

# Avoid assign statements in the synthesized netlist.set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile designuniquifyset_dont_touch cpucompile -map_effort medium

# Report design results for EDT logicreport_area > created_dc_script_report.outreport_constraint -all_violators -verbose >> created_dc_script_report.outreport_timing -path full -delay max >> created_dc_script_report.out



August 2009

report_reference >> created_dc_script_report.out

# Remove top-level moduleremove_design cpu

# Read in the original core netlistread_file -f verilog gate_scan.vcurrent_design cpu_edt_toplink

# Write output netlistwrite -f verilog -hierarchy -o created_edt_top_gate.v

Synthesis Script Internal FlowTestKompress generates a sample Design Compiler (DC) synthesis script,created_dc_script.scr. For the internal flow, this script is more complex than that generated forexternal flow because it includes additional commands that help instantiate the EDT logicwithin the design core. Typically, you need to modify this script. Here is an example script inTCL format, followed by a detailed description of the tasks it performs:

#************************************************************************# Synopsys Design Compiler script for EDT logic insertion##************************************************************************

# Initialize DC variablesset bus_naming_style {%s[%d]}

# Read input design filesread_file -f verilog results/created_edt.vread_file -f verilog netlists/gate_scan_sco.v

# Current design is the top-most level.current_design retimetest

# Create an instantiation of EDT logic within the top-level of the design.create_cell retimetest_edt_i [find design retimetest_edt]

# Create instantiation(s) of an EDT mux to support sharing of outputchannel and core pins.

create_cell retimetest_edt_mux_2_to_1_i1 [find designretimetest_edt_mux_2_to_1]

# Connect core scan inputs to EDT logic scan inputs.set scan_inputs { "edt_si1" "edt_si2" "edt_si3" \ "edt_si4" "edt_si5" "edt_si6" \ "edt_si7" "edt_si8" "edt_si9" \ "edt_si10" "edt_si11" "edt_si12" \ "edt_si13" "edt_si14" "edt_si15" \ "edt_si16" }set count 0foreach 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_si4" "edt_si5" "edt_si6" \ "edt_si7" "edt_si8" "edt_si9" \ "edt_si10" "edt_si11" "edt_si12" \ "edt_si13" "edt_si14" "edt_si15" \ "edt_si16" }foreach i $scan_inputs_to_delete { remove_port [find port $i]}

# Connect core scan outputs to EDT logic scan outputs.set scan_outputs { "edt_so1" "edt_so2" "edt_so3" \ "edt_so4" "edt_so5" "edt_so6" \ "edt_so7" "edt_so8" "edt_so9" \ "edt_so10" "edt_so11" "edt_so12" \ "edt_so13" "edt_so14" "edt_so15" \ "edt_so16" }set count 0foreach 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] query_objects [all_connected [find net $temp_net]] incr count}

# Remove scan output ports from top-level.set scan_outputs_to_delete { "edt_so1" "edt_so2" "edt_so3" \ "edt_so4" "edt_so5" "edt_so6" \ "edt_so7" "edt_so8" "edt_so9" \ "edt_so10" "edt_so11" "edt_so12" \ "edt_so13" "edt_so14" "edt_so15" \ "edt_so16" }foreach i $scan_outputs_to_delete { remove_port [find port $i]}

# Connect EDT control pins to the top-level.

# Route pin edt_clk_buf/Z to the EDT control pinretimetest_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]query_objects [all_connected [find net $temp_net]]

# Route pin edt_update to the EDT control pin retimetest_edt_i/edt_update.create_port edt_update -direction increate_net retimetest_edt_update_netconnect_net retimetest_edt_update_net [find port edt_update]



August 2009

connect_net retimetest_edt_update_net [find pinretimetest_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 increate_net retimetest_edt_bypass_netconnect_net retimetest_edt_bypass_net [find port edt_bypass]connect_net retimetest_edt_bypass_net [find pinretimetest_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 pinretimetest_edt_i/edt_channels_in[0].create_port edt_channels_in1 -direction increate_net retimetest_edt_channels_in0_netconnect_net retimetest_edt_channels_in0_net [find port edt_channels_in1]connect_net retimetest_edt_channels_in0_net [find pinretimetest_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 pinretimetest_edt_i/edt_channels_in[1].create_port edt_channels_in2 -direction increate_net retimetest_edt_channels_in1_netconnect_net retimetest_edt_channels_in1_net [find port edt_channels_in2]connect_net retimetest_edt_channels_in1_net [find pinretimetest_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] toleft/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_netconnect_net retimetest_edt_channels_out0_top_net [find pinretimetest_edt_mux_2_to_1_i1/b_in]connect_net retimetest_edt_channels_out0_top_net [find pinretimetest_edt_i/edt_channels_out[0]]

create_net retimetest_edt_mux_2_to_1_i1_out_netconnect_net retimetest_edt_mux_2_to_1_i1_out_net [find pinretimetest_edt_mux_2_to_1_i1/z_out]connect_net retimetest_edt_mux_2_to_1_i1_out_net [find pinleft/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] toedt_channels_out2_buf/A.create_net retimetest_edt_channels_out1_netconnect_net retimetest_edt_channels_out1_net [find pinedt_channels_out2_buf/A]



connect_net retimetest_edt_channels_out1_net [find pinretimetest_edt_i/edt_channels_out[1]]query_objects [all_connected [find net retimetest_edt_channels_out1_net]]

# Connect system clocks to the EDT logic bypass logic.

# Route clock output clk2 to bypass logic.set temp_net [all_connected [find port clk2]]connect_net $temp_net [find pin retimetest_edt_i/clk2]query_objects [all_connected [find net $temp_net]]

# Synthesize EDT logiccurrent_design retimetest_edt





# Compile designuniquifycompile -map_effort medium

# Report design results for EDT logicreport_area > results/created_dc_script_report.outreport_constraint -all_violators -verbose >>results/created_dc_script_report.outreport_timing -path full -delay max >>results/created_dc_script_report.outreport_reference >> results/created_dc_script_report.out

# Synthesize EDT multiplexorcurrent_design retimetest_edt_mux_2_to_1


# Compile designcompile -map_effort medium

# Report design results for EDT muxreport_area >> results/created_dc_script_report.outreport_timing -path full -delay max >>results/created_dc_script_report.out

# Write output netlistcurrent_design retimetestwrite -f verilog -hierarchy -o results/created_edt_top_gate.v



August 2009

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 thebus style to the bus form. This is particularly necessary during logic insertion becausethe 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 descriptionof the EDT logic are read.

3. Set current design—The current design is set to the top-most level of the input netlist.

4. Instantiate the EDT logic and 2x1 multiplexer module—The EDT logic is instantiatedwithin the top-level of the design. If there is sharing between EDT channel outputs andfunctional pins, a 2x1 multiplexer module (the description is included in thecreated_edt.v file) is also instantiated.

5. Connect scan chain inputs—As mentioned earlier, scan chain inputs should beconnected to the top level without any I/O pads associated with them. This part of thescript disconnects the nets that are connected to the scan chain input ports and connectsthem to the EDT logic.

6. Remove scan chain input ports—Remove the dangling scan chain input ports that arenot connected to any logic after preceding step 5.

7. Connect scan chain outputs—Same as step 5, except that now the scan chain outputs areconnected to the EDT logic.

8. Remove scan chain output ports—Scan chain output ports, which are left dangling afterstep 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 connectthe EDT control signal. If not, a new port is created, and the EDT control pin isconnected to the new port. The script shows the connection for only the edt_clocksignal. 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 theinput channel pin and connect the EDT input channel pin to the newly created port. Thishas to be repeated for each input channel pin. This is done only when no internal nodename was specified for the EDT pin. If an internal node name was specified, the scriptwould be the same as in step 9.

NoteBe 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 isdriven by functional logic—The output channel pin in this case is shared with afunctional pin. Whenever the node is shared with functional logic or is connected toTIE-X (a black box is assumed in such cases), a multiplexer is inserted. However, if thespecified internal node is connected to a constant signal value, the net is disconnectedand connected to the EDT channel output pin. This section of the script inserts amultiplexer and connects the inputs from the EDT logic and the functional net to themultiplexer inputs. The output of the multiplexer is connected to the input of the I/O padcell.

NoteThe select input of the multiplexer is connected to the existing scan enable signal, as thefunctional or scan chain output can be propagated through the multiplexer depending onthe shift and capture modes of scan operation.

You should specify the name of the scan enable signal. If a name is not specified and apin with a default name (scan_en) does not exist at the top level, a new scan_en pin iscreated.

12. Connect EDT channel output pin to a non-shared specified internal node (or a top-levelpin)—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 andconnects it to the channel output pin.

13. Connect system clocks to EDT logic—For the bypass mode, scan chains areconcatenated so that the EDT logic can be bypassed and normal ATPG scan patterns canbe 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 guaranteeproper scan shifting. These “bypass” lockup cells are driven by the clocks that drive thesource or the destination scan cells. As a result, some system clocks have to be routed tothe bypass module of the EDT logic. Clock lines are tapped right before they fan out tomultiple modules or scan cells and are brought up to the topmost level and connected tothe 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 forsynthesizing the logic. This part of the script is almost the same as that of the externalflow, with the following exceptions: the EDT logic is synthesized first followed by theEDT multiplexer(s). In both cases, the synthesis is local to the RTL blocks and does notaffect the core, which is already at the gate level.

15. Write out final netlist—Once the synthesis step is completed, DC writes out a gate levelnetlist that contains the original core, the EDT logic, and any multiplexersTestKompress added to facilitate sharing of output pins.



August 2009

Test Pattern Generation FilesTestKompress automatically writes a dofile and an test procedure file containing EDT-specificcommands and test procedure steps. As with the similar files produced by DFTAdvisor afterscan insertion, these files perform basic setups; however, you need to add commands for anypattern generation or pattern saving steps.

DofileThe dofile includes setup commands and/or switches required to generate test patterns. Anexample dofile created_edt.dofile is shown below. The EDT-specific parts of this file are inbold 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_iset edt instances -decompressor cpu_edt_decompressor_iset edt instances -compactor cpu_edt_compactor_i

add scan groups grp1 created_edt.testprocadd scan chains -internal chain1 grp1 /cpu_i/edt_si1 /cpu_i/edt_so1add scan chains -internal chain2 grp1 /cpu_i/edt_si2 /cpu_i/edt_so2add scan chains -internal chain3 grp1 /cpu_i/edt_si3 /cpu_i/edt_so3add scan chains -internal chain4 grp1 /cpu_i/edt_si4 /cpu_i/edt_so4add scan chains -internal chain5 grp1 /cpu_i/edt_si5 /cpu_i/edt_so5add scan chains -internal chain6 grp1 /cpu_i/edt_si6 /cpu_i/edt_so6add scan chains -internal chain7 grp1 /cpu_i/edt_si7 /cpu_i/edt_so7add scan chains -internal chain8 grp1 /cpu_i/edt_si8 /cpu_i/edt_so8

add clocks 0 clkadd clocks 0 edt_clock

add write controls 0 ramclk

add read controls 0 ramclk

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 usedfor all compressed scan chains (scan chains driven by and observed through the EDT logic)when setting up to generate compressed test patterns. The reason for this requirement isexplained in “Running DRC,” earlier in the chapter.

NoteBe sure the scan chain input and output pin pathnames specified with the Add ScanChains -Internal command are kept during layout. If these pin pathnames are lost duringthe layout tool’s design flattening process, the generated dofile will not work anymore. Ifthat happens, you must manually generate the Add Scan Chains -Internal commands,substituting the original pin pathnames with new, logically equivalent, pin pathnames.

NoteIf your design includes uncompressed scan chains (chains whose scan inputs and outputsare primary inputs and outputs), you must define each such scan chain using the AddScan Chains command without the -Internal switch when setting up for EDT patterngeneration. 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 thenumber of scan channels, and specify the version of the EDT logic architecture. For informationabout how you can use this dofile to generate compressed test patterns, refer to “Preparing forTest Pattern Generation” on page 99.”

Test Procedure FileTestKompress also writes a test procedure file that has test procedures steps needed for thePattern Generation Phase. The tool creates this file by starting with the original test procedurefile that you used in the logic creation phase, and making additions that will drive the EDTlogic. The following is an example of a test procedure file, created_edt.testproc, written byTestKompress. The EDT-specific parts of this file are shown in bold font. For complete detailsabout the EDT-specific functionality included in this file, refer to the Chapter 6 section,“Preparing for Test Pattern Generation.”

//// Written by TestKompress//set time scale 1.000000 ns ;set strobe_window time 100 ;

timeplate gen_tp1 =force_pi 0 ;measure_po 100 ;pulse clk 200 100;



August 2009

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 edt_update 1 ;force ramclk 0 ;force scan_en 1 ;pulse edt_clock ;

end ;apply shift 26;

end;

procedure test_setup =timeplate gen_tp1 ;cycle =

force edt_clock 0 ;end;

end;

Bypass Mode FilesBy default, the EDT logic includes bypass circuitry. To operate the bypass circuitry, anadditional dofile and test procedure file is created. The additional dofile and test procedure fileis then used with FastScan to bypass the TestKompress compression logic and run regularATPG.



For information on the options for creating files, see the Write EDT Files command.

To disable the generation of bypass logic, see the Set EDT command.

For improved design routing, the bypass logic can be inserted into the netlist instead of the EDTlogic. For more information, see “Generating EDT Logic When Bypass Logic is Defined in theNetlist” on page 115.

DofileThis example dofile, created_bypass.dofile, enables you to run regular ATPG. The dofilespecifies the scan channels as chains because in bypass mode, the channels connect directly tothe input and output of the concatenated internal scan chains, bypassing the EDT circuitry.

//// Written by TestKompress//

add scan groups grp1 created_bypass.testprocadd scan chains edt_channel1 grp1 edt_channels_in1 edt_channels_out1

add clocks 0 clk



Test Procedure FileNotice 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 highin the load_unload procedure and activates bypass mode.


timeplate gen_tp1 =force_pi 0 ;measure_po 100 ;pulse clk 200 100;pulse ramclk 200 100;period 400 ;

end;


force_pi ;measure_po ;


Creating EDT LogicCreating a Reduced Netlist for Synthesis

August 2009

pulse_capture_clock ;end;

end;


force_sci ;measure_sco ;pulse clk ;

end;end;


force clk 0 ;force edt_bypass 1 ;force ramclk 0 ;force scan_en 1 ;


end;

Creating a Reduced Netlist for SynthesisIn the internal flow, the EDT logic is instantiated within an existing pad-inserted netlist andconnections are made from the pad terminals to the EDT logic pins. Typically, the connectivityis accomplished by running DC with the synthesis script generated by TestKompress. Bydefault, 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 possibleto run the synthesis tool. If your netlist is in this category, you can get TestKompress to writeout a reduced-size netlist especially for the synthesis run by including the -Reduced_netlistswitch with the Write EDT Files command. The reduced netlist includes only the modulesrequired for the synthesis tool to make the necessary connections between the pad terminals andEDT logic pins. You provide this smaller file to the synthesis tool instead of the entire inputnetlist. The tool writes the rest of the input netlist into a second netlist file that excludes themodules written out in the synthesis only file but includes everything else. You then use theoutput netlist from the synthesis run along with the second netlist as inputs for ATPG.

NoteAnother option is to use TestKompress to insert the EDT logic into the core netlist beforesynthesis. See “Inserting EDT Logic Inside the Core Before Synthesis” on page 88.

Figure 4-8 is a conceptual example of an input netlist. Each box represents an instance with theinstance_name/module_names shown. The small rectangles shaded with dots represent

Creating EDT LogicCreating a Reduced Netlist for Synthesis


instances of technology library cells. The black circles represent four internal EDT logicconnection nodes.

Figure 4-8. Design Netlist with Internal Connection Nodes

When writing out the TestKompress files with the -Reduced_netlist switch, the modules aredistributed between the two netlists as follows:

• <prefix>_reduced_netlist.v (for synthesis) — TOP, A, ASUB, clkctrl

• <prefix>_rest_of_netlist.v (rest of the netlist for ATPG) — ASUB1, ASUB2, A_B,C, C1, C3, ACONT, D

NoteThe reduced netlist for synthesis does not include the technology library cells that haveEDT logic connection nodes because the port list is sufficient for making theseconnections.

When writing out the architecture of a top-level entity in VHDL, all the lower-level cellsinstantiated within are specified as components. A configuration specification that binds thecomponents to a particular entity/architecture pair is also written out. However, if you split thenetlist, not all sub-entities may have been defined in the reduced netlist file; so referencing themmay be an error. As an example, consider the following input netlist:

entity sub isport (i : in std_logic; o : out std_logic);

TOPu1/A

p31

a_b/A_Bu1/ASUB1

u2/ASUB2

a1/ASUB

u3

p3

u6/ACONT

p31

u1/ASUB1

u2/ASUB2

a1/ASUB

p3

u5/clkctrl u7/D

u4/C

c1/C1

c3/C3

c2/C1

u71/A

a_b/A_B

u2


Creating EDT LogicInserting EDT Logic Inside the Core Before Synthesis

August 2009

end;architecture gates of sub is

...end;

entity top isport (i1, i2 : in std_logic; o1, o2 : in std_logic);

end;architecture gates of top is

component subport (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, thenthe configuration specification (highlighted in bold) would be erroneous. For this reason, thetool does not write out configuration specifications for any of the components when splitting aVHDL netlist.

Inserting EDT Logic Inside the Core BeforeSynthesis

This procedure describes how to use TestKompress to insert the EDT logic into the core netlistbefore synthesis. This process eliminates the need to read in the entire netlist during synthesis,thus reducing synthesis time significantly for large designs.

NoteThe order of the gate-level EDT logic modules in the resulting design is different thanthat written when DC inserts the EDT logic during synthesis.

Procedure

1. Invoke TestKompress and configure the EDT logic parameters. See “Creating EDTLogic” on page 49. You must set up the EDT logic insertion to be internal to the designcore with the Set EDT command.

2. Run DRC and correct any errors. See “Running DRC” on page 69.

3. Examine test coverage and data volume estimates and adjust EDT configurations ifnecessary. See “Estimating Test Coverage and Data Volume” on page 90.

NoteYou must enter all commands for determining configuration, test coverage, and datavolume before saving out the EDT logic files. After the composite netlist is written,TestKompress exits and no commands can be issued.

Creating EDT LogicInserting EDT Logic Inside the Core Before Synthesis


4. Create the EDT logic files. For example:

write edt files created -insertion tk

The following files are created:

o created_edt.v — EDT logic description in RTL.

o created_edt_top_rtl.v — Core netlist with an instance of the EDT logic connectedbetween I/O pads and internal scan chains but without a gate-level description of theEDT logic.

o created_dc_script.scr — DC synthesis script that writes out the gate-leveldescription of the EDT logic and then concatenates it with the core design usingsystem level commands.

o created_edt.dofile — Dofile for test pattern generation.

o created_edt.testproc — Test procedure file for test pattern generation.

o created_bypass.dofile — Dofile for uncompressed test patterns (bypass mode).

o created_bypass.testproc — Test procedure file for uncompressed test patterns(bypass mode).

5. Synthesize the EDT logic. See “Synthesizing the EDT Logic” on page 93.

6. Generate test patterns. See “Generating/Verifying Test Patterns” on page 99.

Related Topics

Synthesis Script for Pre-Inserted EDT Logic Example

#************************************************************************# Synopsys Design Compiler synthesis script for config1_edt.v# TestKompress version: v8.2009_3.10-prerelease# Date: Thu Aug 6 01:44:15 2009#************************************************************************

# Bus naming style for Verilogset bus_naming_style {%s[%d]}

# Read input design filesread_file -f verilog results/config1_edt.v

# Synthesize EDT IPcurrent_design circle_edt


Preparing for SynthesisCreating a Reduced Netlist for Synthesis

About the EDT Logic Files


Creating EDT LogicEstimating Test Coverage and Data Volume

August 2009




# Compile designuniquifycompile -map_effort medium

# Report design results for EDT IPreport_area > results/config1_dc_script_report.outreport_constraint -all_violators -verbose >>results/config1_dc_script_report.outreport_timing -path full -delay max >>results/config1_dc_script_report.outreport_reference >> results/config1_dc_script_report.out

write -f verilog -hierarchy -o results/config1_circle_edt_gate.v

# Write output netlistexec cat results/config1_circle_edt_gate.v results/config1_edt_top_rtl.v> results/config1_edt_top_gate.v

# Remove all temporary filesexec rm results/config1_circle_edt_gate.v

Estimating Test Coverage and Data VolumeNoteIf your design contains uncompressed scan chains, they may adversely affect theaccuracy of the test coverage and scan data volume estimates described in this section.you should skip this estimation step if there are uncompressed scan chains in your design.For more information, refer to “Including Uncompressed Scan Chains” on page 43.

After you run TestKompress to create the EDT logic, you should generate test patterns toestimate the test coverage and scan data volume. You do not need to generate patterns at thispoint in the flow; however, the estimates you obtain for a given configuration can be useful (forcomparison with the test results you obtained without TestKompress in your design).

You should not save patterns you generate at this stage in the flow. The tool emulates thecombined core and EDT logic when it generates them, but the patterns are not the same as thosethe tool will generate after you synthesize the core and EDT logic into a unified gate levelnetlist. 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 youwould use in FastScan. For example:

ATPG> create patternsATPG> report statisticsATPG> report scan volume

You can repeat this optional pattern generation for different configurations to experiment withcoverage and data volume. For situations where the number of channels is fixed, you can repeatscan insertion multiple times to set up the design with different numbers of scan chains. Whenyou rerun TestKompress to regenerate the EDT logic with the same number of scan channels,the compression will be different for each scan chain configuration.

NoteIf you obtain compression lower than you expect, refer to “If Compression is Less ThanExpected” on page 233 for troubleshooting suggestions. If test coverage is less than youcan obtain without EDT, refer to “If Test Coverage is Less Than Expected” on page 234.



August 2009


Chapter 5Synthesizing the EDT Logic

This chapter describes issues related to the synthesis of the EDT logic. Figure 5-1 shows thelayout of this chapter as it applies to the synthesis process.

Figure 5-1. Preparing For and Synthesizing the EDT logic

OverviewAfter you create the EDT logic, the next step is to synthesize it. If you are using the internalflow, insertion of the EDT logic between the I/O pads and the core occurs as a part of synthesis.TestKompress creates a basic Design Compiler (DC) synthesis script, in either dcsh or TCLformat, that you can use as a starting point. Running the synthesis script is a separate step whereyou exit TestKompress and use DC to synthesize the EDT logic. You can use any synthesistool; the generated DC script provides a template for developing a custom script for anysynthesis tool.

NoteIf you use the external flow, be sure to insert boundary scan and I/O pads after you createthe EDT logic, but before you synthesize it. These topics are covered in the followingsection, “Preparing for Synthesis.”

You may be able to run the script without modification to synthesize and insert (if you are usingthe internal flow) the EDT logic, provided the following are true:

Create

(Design Compiler)

Generate/Verify

(TestKompress)Test Patterns

EDT Logic(TestKompress)

EDT LogicSynthesize

3. About Synthesizing EDT Logic

2. Preparing for Synthesis

1. Overview


Synthesizing the EDT LogicPreparing for Synthesis

August 2009

• DC is the synthesis tool.

• The default clock definitions are acceptable.

• Technology library files are set up correctly in the .synopsys_dc.setup file in thedirectory from which DC is invoked.

NoteThe syntax of the .synopsys_dc.setup file and the DC synthesis script differ depending onwhich format, dcsh or TCL, they support.

NoteIf the .synopsys_dc.setup file does not exist, you must add the library file references to thesynthesis script.

Preparing for SynthesisThe previous chapters describe how to create an RTL description of the EDT logic. The nextstep is to incrementally synthesize the RTL into the gate level netlist. The following twosections describe, for each flow, how to prepare for synthesis.

External EDT LogicOnce the EDT logic is created, but before you synthesize it, you should insert I/O pads and(optionally) boundary scan. For designs that require boundary scan, you should insert theboundary scan first, followed by I/O pads. Then, synthesize the I/O pads and boundary scantogether with the EDT logic.

NoteYou can add boundary scan and I/O pads simultaneously using BSDArchitect.

Adding Boundary Scan (External Flow)

NoteAs a prerequisite to using boundary scan with TestKompress, you should understandboundary scan concepts. For general process, concept, and procedure information onboundary scan and on the Mentor Graphics boundary scan product, BSDArchitect, referto the Boundary Scan Process Guide.

Boundary scan cells cannot be present in your design before the EDT logic is inserted. Toinclude boundary scan, you perform an additional step after the EDT logic is created. In this

Synthesizing the EDT LogicPreparing for Synthesis


step, you can use any tool to insert boundary scan. As shown in Figure 5-2, the circuitry shouldinclude the boundary scan register, TAP controller, and (optionally) I/O pads.

Figure 5-2. Contents of Boundary Scan Top Level Wrapper

BSDArchitect creates a Verilog RTL description containing a wrapper that instantiates theTestKompress wrapper, EDT logic, core design, and boundary scan circuitry. This causes oneadditional level of hierarchy to be inserted outside the TestKompress wrapper. For a detaileddescription of the TestKompress boundary scan flow, see “TestKompress and Boundary Scan(External Flow)” on page 121.

Adding I/O Pads (External Flow)You can use any method to insert I/O pads after scan insertion and EDT logic creation. If youneed to integrate TestKompress after the I/O pads are inserted, see “Managing Pre-existing I/OPads” on page 40. The following two subsections describe how to reinsert the I/O pads afterEDT logic creation.

Core and Pads in Separate Blocks

If the core and pads were in separate blocks and you separated them as described in “ManagingPre-existing I/O Pads” on page 40, you should now reinsert the EDT logic-core combination

edt_top

edt

core

tap

bsr_instance_1

pad_instance_1

edt_top_bscan

(optional)


Synthesizing the EDT LogicAbout Synthesizing EDT Logic

August 2009

into the original circuit in place of the extracted core. When you reinsert it, ensure the EDTlogic- core combination is connected to the I/O pads. Add pads for any new EDT pins that arenot shared with existing core pins and for which no pads were present as placeholders.

Pad Insertion Before Scan Insertion

If your design flow dictates that I/O pads are inserted prior to scan insertion and you used thearchitecture swapping solution described in the “Managing Pre-existing I/O Pads,” then I/Opads are already included in your scan-inserted design, and you can proceed to insert boundaryscan.

Internal EDT LogicThe synthesis script for the internal flow contains commands similar to those in the scriptgenerated for the external flow. But unlike the external flow script, it also contains commands tohelp 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.

Optionally, you can insert the EDT logic into the core before synthesis. In this case,TestKompress inserts the logic and creates a modified synthesis script to synthesize the EDTlogic. This process simplifies the synthesis and requires substantially less time for large designs.See “Inserting EDT Logic Inside the Core Before Synthesis” on page 88.

About Synthesizing EDT LogicNoteYou should preserve the pin names in the EDT logic hierarchy. Preserving pin namesensures that pins resolve when test patterns are created and increases the usefulness of thedebug information returned during DRC.

If you use DC to synthesize the netlist, examine the .synopsys_dc.setup file and verify that itpoints to the correct libraries. Also, examine the DC synthesis script generated byTestKompress and make any needed modifications. For more information, see “About the EDTLogic Files” on page 72”.

NoteWhen using the external flow and boundary scan, you must modify this script to read inthe RTL description of the boundary scan circuitry. Refer to “Preparing to SynthesizeBoundary Scan and EDT Logic” for an example DC synthesis script with modificationsfor boundary scan.

The following DC commands are included in the synthesis scripts created by TestKompress:



• set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

This command prevents DC from including “assign” statements in the Verilog gate levelnetlist. This is done because assign statements can cause problems in some tools later inthe design flow.

• set_clock_transition 0.0 edt_clockset_dont_touch_network edt_clock

These commands prevent buffering of the EDT clock during synthesis and preserve,when DC optimizes the design, the EDT clock network contained in the EDT logic.With these commands, be sure to perform clock tree synthesis later for the EDT clock.

After you run DC to synthesize the netlist and verify no errors occurred, check that tri-statebuffers were correctly synthesized. DC is unable to correctly synthesize tri-state buffers forcertain technologies and may insert incorrect references to “\**TSGEN**”.

Note If the “TSGEN” keyword exists in the synthesized netlist, you must correct it. See“Incorrect References to \**TSGEN** in Synthesized Netlist” on page 231.



August 2009


Chapter 6Generating/Verifying Test Patterns

This chapter describes how to generate compressed test patterns. In this part of the flow, yougenerate and verify the final set of test patterns for the design. Figure 6-1 shows the layout ofthis chapter and the processes involved.

Figure 6-1. Test Pattern Generation and Verification Procedure

After you insert I/O pads and boundary scan and synthesize the EDT logic, invokeTestKompress on the synthesized top level netlist and generate compressed test patterns.

NoteYou can write test patterns in the same formats FastScan uses (for example, Verilog andWGL).

Preparing for Test Pattern GenerationNoteYou can reuse FastScan dofiles, with addition of some EDT-specific commands, togenerate compressed patterns with the same test coverage as the original FastScanpatterns. You cannot directly reuse pre-computed, existing ATPG patterns.

Generate/VerifyEDT Patterns(TestKompress)

Hand off to Vendor

EDT logic(Design Compiler)

Synthesize

3. Generating Test Patterns

2. Verifying the EDT Logic

1. Preparing for Test Pattern Generation

6. Setting Up for HDL Simulation

5. Saving the Patterns

4. Optimizing Compression

7. Running the Simulation


Generating/Verifying Test PatternsPreparing for Test Pattern Generation

August 2009

To prepare for EDT pattern generation, check that EDT is on, and configure the tool the same aswhen you created the EDT logic. For example, if you create the EDT logic with one scanchannel, you must generate test patterns for circuitry with one channel.

Note DRC violations occur if you attempt to generate patterns for a different number of scanchannels than what the EDT logic is configured for.

You must also add scan chains in the same order they were added to the EDT logic. To reliablyadd the correct number of chains in the correct order in the Pattern Generation Phase, youshould use the setup dofile generated when the EDT logic was created. You can customize thedofile as needed.

The Report Scan Chains command lists the scan chains in the same order they were addedoriginally. For additional information, refer to the next section, “Using the Generated Dofileand Procedure File.”

Compared to when you generated test patterns using FastScan with the scan-inserted coredesign (see “Running FastScan ATPG (Optional)”), there are certain differences in the toolsetup. One of the differences arises because in the Pattern Generation Phase, you need to set upthe patterns to operate the EDT logic. This is done by exercising the EDT clock, update andbypass (if present) control signals as illustrated in Figure 6-2.

Figure 6-2. Sample EDT Test Procedure Waveforms

Prior to each scan load, the EDT logic needs to be reset. This is done by pulsing the EDT clockonce 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

scan enable

EDT update

EDT clock

scan clock

load_unload shift load_unloadcapture shiftshift

EDT bypass

EDT reset



can have any value during capture; they do not have to be constrained. On the other hand, theEDT clock must be 0 during the capture cycle. The operation of these signals is described in theload_unload and shift procedures in the test procedure file the generated with the EDT logic. Anexample of this file is shown in ““Test Pattern Generation Files” on page 82.”

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 thecapture 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 compressedscan chains as internal, as opposed to external channels. This definition is different fromthe definition you used to create the EDT logic because the scan chains are nowconnected 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. Uncompressed scan chains arechains not defined with the Add Scan Chains command when setting up the EDT logicand whose scan inputs and outputs are primary inputs and outputs. You must define eachuncompressed scan chain using the Add Scan Chains command without the -Internalswitch during test pattern generation.

• If you add levels of hierarchy (due, for example, to boundary scan or I/O pads), revisethe pathnames to the internal scan pins listed in the generated dofile. An example dofilewith this modification is shown in the Chapter 7 section, “Modifying the Dofile andProcedure File for Boundary Scan.”

Using the Generated Dofile and Procedure FileThe first two setups described in the preceding section are included in the dofile generated withthe EDT logic. For an example of this dofile, refer to “Dofile” in the “Test Pattern GenerationFiles” section of Chapter 4.

The test procedure file also needs modifications to ensure the EDT update signal is active in theload_unload procedure and the EDT clock is pulsed in the load_unload and shift procedures.These modifications are implemented automatically in the test procedure file output with theEDT logic as follows:

• The timeplate used by the shift procedure is updated to include the EDT clock.

• In this timeplate, there must be a delay between the trailing edge of the clock and the endof the period. Otherwise, a P3 DRC violation will occur.

• The load_unload procedure is set up to initialize the EDT logic and apply shift a numberof times corresponding to the longest “virtual” scan chain (longest scan chain plusinitialization cycles) seen by the tester. The number of initialization cycles is reported bythe Report EDT Configurations command.



August 2009

• The shift procedure is updated to include pulsing of the EDT clock signal anddeactivation of the EDT update signal.

• The EDT bypass signal is forced to a logic low if the EDT circuitry includes bypasslogic.

For an example of this test procedure file, refer to “Test Procedure File” in the “Test PatternGeneration Files” section of Chapter 4.

Using the Generated Bypass Dofile and Procedure FileThe tool generates a dofile and an test procedure file you can use with FastScan to activatebypass mode and run regular ATPG. Examples of these files are shown in “Bypass Mode Files”on page 84.” If your design includes boundary scan and you want to run in bypass mode, youmust modify the bypass dofile and procedure file to work properly with the boundary scancircuitry.

Verifying the EDT LogicTestKompress uses two mechanisms to verify that the EDT logic works properly:

• Design rules checking (DRC)

• Enhanced chain and EDT logic (chain+EDT logic) test

The next two sections describe these mechanisms.

Design Rules Checking (DRC)Several DRC rules verify the EDT logic operates correctly. The tool provides the most completeinformation about violations of these rules when you have preserved the EDT logic structurethrough synthesis. Following is a brief summary of just the rules that verify operation of theEDT logic:

• K19 — simulates the decompressor netlist and performs diagnostic checks if asimulation-emulation mismatch occurs.

• K20 — identifies the number of pipeline stages within the compactors, based onsimulation.

• K22 — simulates the compactor netlist and performs diagnostic checks if a simulation-emulation mismatch occurs.

For detailed descriptions of all the TestKompress design rules (K rules) checked during DRC,refer to the “Design Rules Checking” chapter of the Design-for-Test Common ResourcesManual.



EDT Logic and Chain TestingIn addition to performing DRC verification of the EDT logic, TestKompress saves, as part ofthe pattern set, an EDT logic and chain test. This test consists of several scan patterns that verifycorrect operation of the EDT logic and the scan chains when faults are added on the core or onthe entire design. This test is necessary because the EDT logic is not the standard scan-basedcircuitry that traditional chain test patterns are designed for. The EDT logic and chain test helpsin 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 inthe compactor works. Included in every EDT pattern are mask codes that are decompressed andshifted into a mask shift register as the pattern data is shifted into the scan chains. Once apattern’s codes are in this register, they are then parallel loaded into a hold register that placesthe bit values on the inputs to a decoder. Figure 6-3 shows a conceptual view of the decodercircuitry for a six chains/one channel configuration.

The decoder basically has a classic binary decoder within it and some OR gates. The classicdecoder decodes its n inputs to one-hot out of 2n outputs. The 2n outputs fall into one of twogroups: the “used” group or the “unused” group. (Unless the number of scan chains exactlyequals 2n, there will always be one or more unused outputs.)



August 2009

Figure 6-3. Example Decoder Circuitry for Six Scan Chains and One Channel

Each output in the used group is AND’d with one scan chain output. For a masked pattern, thedecoder typically places a high on one of the used outputs, enabling one AND gate to pass itschain’s output for observation.

The decoder also has a single bit control input provided by the edt_mask signal. Unused outputsof the classic decoder are OR’d together and the result is OR’d with this control bit. If any of theOR’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-maskingpattern, 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 designdetermines 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 allpossible codes plus the edt_mask control bit.

The EDT logic and chain test for a 10X configuration has a minimum of 18 patterns. These 18patterns 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, codescorrespond to “used” codes), six non-masking patterns (control bit is not set, but codes result inthe one-hot selector being in the “unused” group).

edt_mask

Mask Hold Register

Mask Shift Register

2

Chain

Maskinggates

3

4

5

6

1

Outputs

Classic decoderdecodes to 1-hot

out of 2n

Decoder

n code bits in

2n bits out

unused

used

To compactorXOR tree



The actual set of chain test patterns depends on how many chains each channel has. Forexample, if you have two channels and 19 chains, the first channel will have ten chains and thesecond, 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 beobserved per channel, due to “used” codes for each channel.

• Pattern 11 — Masking pattern (control bit is not set). For channel 1, one chain will beobserved due to a “used” code for this channel. For channel 2, all chains will beobserved due to an “unused” code for that channel.

• Patterns 12 through 17 — Masking patterns (control bit is not set). However, for bothchannels 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 codecorresponding to a channel is a “used” code, only one of that channel’s chains will have binaryexpected values. All other chains in that channel will have X expected values. To see anexample of a masked ASCII pattern, refer to “Understanding Scan Chain Masking in theCompactor” on page 150.

So, depending on which chain test is failing, it is possible to deduce which chain might becausing problems. In the preceding example, if a failure occurred for any of the patterns 2through 10, you could immediately map it back to the failing chain and, based on the cycleinformation, to a failing cell. For pattern 11, if channel 1 had a failure, you similarly could mapit 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 patternswould fail as well.

Coverage for EDT Logic and Chain Test

Experiments performed by Mentor Graphics engineers using sequential fault simulation inFlexTest demonstrate that test coverage for the EDT logic with the enhanced chain test is nearly100% when the EDT logic does not include bypass logic (essentially multiplexers that bypassthe decompressor and compactor). Test coverage declines to just above 94% when the EDTlogic includes bypass logic. This is because the EDT chain test does not test the bypass modeinput of each bypass multiplexer (edt_bypass is kept constant in EDT mode during the chaintest).

Note99+% coverage can be achieved in any event by including a bypass mode chain test (thestandard chain test).

The size of the chain test pattern set depends on the configuration of the EDT logic and thespecific design. Typically, about 18 chain test patterns are required when you approach 10Xcompression.


Generating/Verifying Test PatternsGenerating Test Patterns

August 2009

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 faultsin the EDT logic. Traditional scan patterns can probably detect most EDT logic faults. Butbecause EDT logic fault detection cannot be serially simulated, TestKompress conservativelydoes not give credit for them. This results in a relatively high number of undetected faults in theEDT logic being included in the calculation of test coverage. You, therefore, see a lowerreported test coverage than is actually the case.

The EDT logic and chain test targets faults in the EDT logic. The tool always performs the thistest, so adding faults on the entire design is not necessary in order to get EDT logic testcoverage. To avoid false test coverage reports, the best practice is to add faults on the core only.

Generating Test PatternsTestKompress supports all FastScan pattern functionality, with the exception of MacroTest andrandom patterns. This includes combinational, clock-sequential (including patterns withmultiple scan loads), and RAM sequential patterns. It also includes all the fault types. When yougenerate test patterns, use as a starting point, the dofile and test procedure files written byTestKompress during logic creation. If you added boundary scan, you will need to modify thefiles as explained in the section, “Modifying the Dofile and Procedure File for Boundary Scan.”

To create the EDT logic, you invoked TestKompress on the core level of the design. Togenerate test patterns, you invoke TestKompress on the synthesized top level of the design thatincludes synthesized pads, boundary scan if used, and the EDT logic. Here is an exampleinvocation on a Verilog file named created_edt_top.v, assumed here to be the top level filegenerated when the EDT logic was created:

<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 EDTLogic Files.” Next, you need to set up TestKompress. To do this, invoke the dofile. Forexample:

SETUP> dofile created_edt.dofile

For information about the EDT-specific contents of this dofile, refer to “Test Pattern GenerationFiles” in Chapter 4. Enter ATPG mode and verify that no DRC violations occur. Pay specialattention 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 thecore design prior to inserting the EDT logic, it is useful to add faults on just the core now, toenable you to make valid comparisons of test performance using EDT versus without EDT.



ATPG> add faults /my_core// Only target faults in coreATPG> create patternsATPG> report statisticsATPG> report scan volume

Another reason to add faults on the core is to avoid incorrectly low reported test coverage, asexplained earlier in “Adding Faults on the Core Only is Recommended.”

The Report Scan Volume command provides reference numbers when analyzing the achievedcompression.

NoteIf you reorder the scan chains after you generate EDT patterns, you must regenerate thepatterns. This is true even if the EDT logic has not changed. EDT patterns cannot bemodified manually to accommodate the reordered scan chains.

Figure 6-4 illustrates an important characteristic of the EDT logic during test pattern generation.

Figure 6-4. Circuitry in the Pattern Generation Phase

There is no physical connection between the decompressor and the internal scan chains, as seenwithin the tool in the Pattern Generation Phase. This modification occurs only within the tool, asa result of the “add scan chains -internal” command. TestKompress does not modify theexternal netlist in any way.

Basically, TestKompress breaks the connection and turns the internal scan chain inputs into PIsas a means of controlling the values the ATPG engine can place on them. TestKompressexercises 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 whileemulating the behavior of an unbroken connection between the decompressor and the scanchains.

Chain 4

Chain 3

Chain 2

Chain 1

SI SO

Decompressor

Compactor

PIfloating



August 2009

NoteIf 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 simulationmismatches.

Optimizing CompressionYou can do a number of things to ensure maximum compression in TestKompress:

• Limit observable Xs

• Use Dynamic Compaction

Using Dynamic CompactionYou should use dynamic compaction during ATPG if your primary objective is a compactpattern set. Dynamic compaction helps achieve a significantly more compact pattern set, whichis the ultimate goal of using EDT. Because the two compression methods are largelyindependent of each other, you can use dynamic compaction and EDT concurrently. Try to useCreate Patterns for the smallest pattern set, as it executes a good ATPG compression flow that isoptimal for most situations.

NoteFor circuits where dynamic compaction is very time-consuming, you may prefer togenerate patterns without dynamic compaction. The test set that is generated is not themost compact, but it is typically more compact than the test set generated by traditionalATPG with dynamic compaction. And it is usually generated in much less time.

Saving the PatternsSave EDT test patterns in the same way you do in FastScan. For complete information aboutsaving patterns, refer to the Save Patterns command in the ATPG and Failure Diagnosis ToolsReference Manual.

Serial PatternsOne important restriction on EDT serial patterns is that the patterns must not be reordered afterthey are written. Because the padding data for the shorter scan chains is derived from the scan-in data of the next pattern, reordering the patterns may invalidate the computed scan-out data.For more detailed information on pattern reordering, refer to the section, “Reordering Patterns”in Chapter 7.

Generating/Verifying Test PatternsPost-Processing of EDT Patterns


Parallel PatternsBecause parallel simulation patterns force and observe the decompressed data directly on thescan cells, they have to be written by TestKompress, which understands and emulates the EDTlogic.

Some ASIC vendors write out parallel WGL patterns, and then convert them to parallelsimulation patterns using their own tools. This is not possible with default EDT patterns, as theyprovide only scan channel data, not scan chain data. To convert these patterns to parallelsimulation 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 writeparallel EDT patterns with respect to the core scan chains. You can write these patterns in testeror ASCII format and use them to produce parallel simulation patterns as described in the nextsection.

EDT Internal Patterns

The optional -Edt_internal switch to the Save Patterns command enables you to save parallelpatterns as EDT internal patterns. These are tester or ASCII formatted EDT patterns that thetool writes with respect to the core scan chains instead of with respect to the top level scanchannel PIs and POs. These patterns contain the core scan chain force and observe data with theexception that they have X expected values for cells which would not be observed on the outputof the spatial compactor due to X blocking or scan chain masking. X blocking and scan chainmasking are explained in the Chapter 7 section, “Understanding Scan Chain Masking in theCompactor.”Also, of course, the scan chain force and observe points are internal nodes, not toplevel PIs and POs. Because they provide data with respect to the core scan chains, EDT internalpatterns can be converted into parallel simulation patterns.

NoteThe number of scan chain inputs and outputs in EDT internal patterns corresponds to thenumber 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 toload each pattern, will be shorter because the extra initialization cycles that occur innormal EDT patterns for the EDT circuitry are unnecessary.

Post-Processing of EDT PatternsSometimes there is a need to process patterns after they are written to a file. Post-processingmight be needed, for example, to control on-chip phase-locked loops (PLLs). Scan pattern post-processing requires access to the uncompressed patterns. TestKompress, however, writespatterns 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.


Generating/Verifying Test PatternsSimulating the Generated Test Patterns

August 2009

NoteAn 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 parallelsimulation patterns. See “Parallel Patterns” on page 109 for more information.

The TestKompress ATPG engine must set or constrain any scan cells prior to compressing thepattern. So it is essential you identify the type of post-processing you typically need and thentranslate it into functionality you can specify in the tool as part of your setup for patterngeneration. The ATPG engine can then include it when generating EDT patterns.

Simulating the Generated Test PatternsYou can verify the test patterns using parallel and serial test benches the same way you wouldfor normal scan and ATPG. When you simulate serial simulation vectors, you can verify thecorrectness of the captured data for the vector, the chain integrity, and the EDT logic (both thedecompressor and the compactor blocks). When simulation mismatches occur, you can still usethe parallel test bench to debug mismatches that occur during capture. You can use the serialtest bench to debug mismatches related to scan chain integrity and the EDT logic.

NoteParallel VHDL patterns require the ModelSim simulator, same as the parallel VHDLpatterns produced by FastScan.

To verify that the test vectors and the EDT circuitry operate correctly, you need to seriallysimulate the test vectors with full timing. Typically, you would simulate all patterns in paralleland 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 scanchains, be sure to use the -Sample switch when you save patterns for serial simulation. This istrue even though serial patterns simulate faster with EDT than with traditional ATPG due to thefewer 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 usefulbackground information on the use of this switch. Refer to the Save Patterns commanddescription in the ATPG and Failure Diagnosis Tools Reference Manual for usage information.

NoteYou must use TestKompress to generate parallel simulation patterns. You cannot use athird party tool to convert parallel WGL patterns to the required format, as you can fortraditional ATPG. This is because parallel simulation patterns for EDT are decompressedversions 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.



Setting Up for HDL SimulationFirst, 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 SimulationAfter you have compiled the netlist and the vectors, you can simulate the patterns using thefollowing 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.



August 2009


Chapter 7Special Topics

This chapter describes advanced features of TestKompress. For more information, see thefollowing topics:

Bypassing EDT Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

TestKompress and Boundary Scan (External Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Using Pipeline Stages in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Using Pipeline Stages Between Pads and Channel Inputs or Outputs . . . . . . . . . . . . . . 129

Understanding How Lockup Cells are Inserted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Evaluating Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Understanding Compactor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Understanding Scan Chain Masking in the Compactor . . . . . . . . . . . . . . . . . . . . . . . . . 150

Fault Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Reordering Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Bypassing EDT LogicBy default, EDT logic includes logic that bypasses the compression logic to provide directaccess to uncompressed scan chains in the design core.

Bypassing the compression logic enables you to apply standard uncompressed test patterns tothe design to:

• Debug test compressed test patterns

• Apply custom uncompressed scan patterns

• Apply test patterns from other ATPG tools such as FlexTest.

Structure of the Bypass LogicBecause the number of core scan chains is relatively large, they are reconfigured into fewer,longer scan chains for bypass mode. For example, in a design with 100 core scan chains andfour external channels, every 25 scan chains are concatenated to form one bypass chain. Thisbypass chain is then connected between the input and output pins of a given channel.

Figure 7-1 illustrates conceptually how the bypass mode is implemented.


Special TopicsBypassing EDT Logic

August 2009

Figure 7-1. Bypass Mode Circuitry

Notice that the bypass logic is implemented with multiplexers. TestKompress includes themultiplexers and any lockup cells needed when concatenating scan chains in the EDT logic.

You can also insert the bypass logic at scan insertion time. This allows you to place themultiplexers and lockup cells required to operate the bypass mode inside the core netlist insteadof the EDT logic. This option allows more effective design routing. For more information, see“Inserting Bypass Chains in the Netlist” on page 42.

NoteWhen lockup cells are inserted as part of the bypass logic, the EDT logic requires asystem clock. If the same bypass logic is placed in the netlist, the EDT logic does notrequire a system clock.You can also set up the TK clock to pulse before the scan chain shift clocks to avoid usinga system clock. For more information, see the -pulse_edt_before_shift_clocks switch ofthe Set EDT command.

The bypass circuitry is run from bypass mode in FastScan.

Chain 4

Chain 3

Chain 2

Chain 1

SI

.

.

.

.

.

Decompressor Compactor

SO



Generating EDT Logic When Bypass Logic is Defined inthe Netlist

TestKompress supports netlists that contain two sets of pre-defined scan chains. Predefiningtwo sets of scan chains allows you to insert both the bypass chains and the core chains into thecore design with a scan-insertion tool.

NoteDesign blocks that contain bypass chains in the EDT logic and design blocks that containbypass chains in the core can coexist in a design.

Limitations

• Bypass patterns cannot be created from compressed test patterns. You must generatebypass patterns from FastScan or other ATPG tool. See “Creating Bypass Patterns withFastScan” on page 120.

Prerequisites

• Both bypass and core scan chains must be inserted in the design netlist. For moreinformation, see “Inserting Bypass Chains in the Netlist” on page 42.

Procedure

1. Invoke TestKompress. For example:

mgcdft tree>/bin/testkompress my_gate_scan.v -verilog \-lib my_lib.atpg

2. Set up parameters for the EDT logic generation. For more information, see “Preparingfor EDT Logic Creation” on page 51.

3. Enable TestKompress to use existing bypass chains. For example:

setup> set edt -bypass_logic use_existing_bypass_chains

For more information, see the Set EDT command.

4. Specify the number of bypass chains. For example:

setup> set edt -bypass_chain 2

For more information, see the Set Bypass Chains command.

5. Specify the input and output pins for the bypass chains. For example:

setup> set bypass chains 2 -pins scan_in2 scan_out2

For more information, see the Set Bypass Chains command.



August 2009

6. Generate the EDT logic. For more information, see “Creating EDT Logic Files” onpage 71.

Related Topics

Generating Identical EDT and Bypass Test PatternsTestKompress supports the creation of decompressed versions of each EDT pattern. Theavailability of decompressed EDT patterns enables you to use FastScan in bypass mode todirectly load the scan cells with the same values TestKompress (EDT On) loads. For debuggingsimulation mismatches in the core logic, it is sometimes helpful if you can apply the exact samepatterns with FastScan in bypass mode that you applied with TestKompress.

NoteYou can only convert EDT test patterns to decompressed test patterns for bypass mode ifthe bypass scan chains are created with TestKompress. Otherwise, you must use FastScanor TestKompress (EDT off) to generate bypass test patterns. See “Creating BypassPatterns with FastScan” on page 120.

After you generate EDT patterns in the Pattern Generation Phase, you can direct TestKompressto translate the EDT patterns into bypass mode FastScan patterns and write the translatedpatterns to a file. The file format is the same as the regular FastScan binary file format. Youaccomplish the translation and create the binary file by issuing the Save Patterns command withthe -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 Goodmachine system mode to verify that the expected values computed in TestKompress are stillvalid in bypass mode, and save the patterns in any of the tool’s supported formats; WGL orVerilog for example. An example of this tool flow is provided in the section, “Using BypassPatterns in FastScan.”

There are several reasons you cannot use TestKompress alone to create the EDT bypasspatterns:

• Bypass operation requires a different set of test procedures. These are only loaded whenrunning FastScan and are unknown to TestKompress in the Pattern Generation Phase.

If the bypass test procedures produce different tied cell values than the EDT testprocedures, simulation mismatches can result if the EDT patterns are simply reformattedfor bypass mode. An example of this would be if a boundary scan TAP controller wereused to drive the EDT bypass signal. The two sets of test procedures would cause the

Synthesizing the EDT LogicCreating Bypass Patterns with FastScan



register driving the signal to be forced to different values and the expected valuescomputed 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 tracedin 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 capturedvalues 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 hadcaptured an X, the tool sets the captured value of the other to X so no fault can be detected onthose 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 scancells in that chain to X. When translating the EDT patterns, the tool preserves those Xs so thetwo pattern sets are identical. While this can lower the “observability” possible with the bypasspatterns, it emulates EDT test conditions. For more information on how TestKompress usesmasking, refer to “Understanding Scan Chain Masking in the Compactor.”

Chain Test Pattern Handling for Bypass OperationTestKompress saves only the translated EDT scan patterns in the binary file. The enhancedchain + EDT logic test patterns are not saved. The purpose of the enhanced test patterns is toverify the operation of the EDT logic as well as the scan chains. Because no shifting occursthrough the EDT logic when it is bypassed, regular chain test patterns are sufficient to verify thescan chains work in bypass configuration; The regular chain test patterns are appended to thecompressed test pattern set when you write out the bypass patterns.

NoteBecause the EDT pattern set contains the enhanced test patterns and the bypass pattern setdoes not, the number of patterns in the EDT and bypass pattern sets are different.

You can use the bypass test patterns with FastScan to debug problems in the core design andscan chains but not in the EDT logic. If the enhanced tests fail in TestKompress and the bypasschain test passes in FastScan, the problem is probably in the EDT logic or the interface betweenthe EDT logic and the scan chains.

Using Bypass Patterns in FastScanAfter you save the bypass patterns, invoke FastScan on the design using the dofile and testprocedure file generated when the EDT logic is created. You then read into FastScan the binarypattern file you previously saved from TestKompress. You can optionally simulate the patternsin the FastScan good machine mode to verify that the expected values computed inTestKompress are still valid in bypass mode. Then save the patterns in any of the tool’ssupported formats, WGL or Verilog for example.



August 2009

Bypass Pattern Flow Example

NoteThe following steps assume that, as part of a normal flow, you already have runTestKompress to create the EDT logic, followed by Design Compiler to synthesize it.You must complete both steps (described in Chapters 4 and 5, respectively) in order torun FastScan in bypass mode. The bypass dofile and the bypass test procedure filegenerated by TestKompress are required by FastScan in order to correctly apply a bypasspattern set.

In the TestKompress Pattern Generation Phase, issue a “save patterns -binary -edt_bypass”command to write 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 bypasspatterns.

Setting Up FastScanInvoke FastScan in setup mode and invoke the bypass dofile generated by TestKompress. Placethe design in the same state in FastScan that you used in TestKompress, then run DRC.

NotePlacing the design in the same state in FastScan as in TestKompress ensures the expectedtest values in the bypass patterns remain valid when the design is configured for bypassoperation.

The following example uses the bypass dofile, created_bypass.dofile, described in the Chapter4 section, “Creating EDT Logic Files”:

SETUP> dofile created_bypass.dofileSETUP> set system mode good

Verify that no DRC violations occurred.

Processing the Bypass PatternsTo simulate the bypass patterns and verify the expected values, enter commands similar to thefollowing:

GOOD> set pattern source external my_bypass_patterns.binGOOD> report failures -pdet



NoteThe expected values in the binary pattern file mirror those with which TestKompressobserves EDT patterns. Therefore, if TestKompress cannot observe a scan cell (forexample, due to scan chain masking or compaction with a scan cell capturing an X), theexpected value of the cell is set to X even if it can be observed by FastScan in bypassmode.

Saving the Patterns with TestKompress Observability

To save the patterns in another format using the expected values in the binary pattern file, issuethe Save Patterns command with the -External switch. For example, to save ASCII patterns:

GOOD> set pattern source external my_bypass_patterns.binGOOD> 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 thedesign 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 byFastScan. To save patterns where the expected values reflect FastScan observability, firstsimulate the patterns as follows:

SETUP> set system mode goodGOOD> set pattern source external my_bypass_patterns.bin -store_patternsGOOD> run

NoteThe preceding command sequence will cause the Xs that emulate the effect ofcompaction in EDT to disappear from the expected values. The resultant bypass patternswill no longer be equivalent to the EDT patterns; only the stimuli will be identical in thetwo pattern sets. For a given EDT pattern, therefore, the corresponding bypass patternwill no longer provide test conditions identical to what the EDT pattern provided inTestKompress.

Using the -Store_patterns switch in Good system mode when specifying the external file as thepattern 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 theexpected values based on simulation.



August 2009

NoteIf you fault simulate the patterns loaded into FastScan, the test coverage reported may beslightly higher than it actually is in TestKompress. This is because FastScan recomputesthe expected values during fault simulation rather than using the values in the externalpattern file. The recomputed values do not reflect the effect of the compactors and scanchain masking that are unique to EDT. Therefore, there likely will be fewer Xs in therecomputed values, resulting in the higher coverage number.

When you subsequently save these patterns, take care not to use the -External switch with theSave Patterns command. The -External switch saves the current external pattern set rather thanthe internal pattern set containing the simulated expected values. The following example savesthe 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 FastScanUse this procedure to generate test patterns for the bypass chains located in your netlist or in theEDT logic.

Prerequisites

• If a signal other than the edt_bypass signal is used for the mux select that enables thebypass chains, the test procedure file for the bypass chains must be modified to allowbypass chains to be traced.

• EDT logic must be created and synthesized into your netlist, and the bypass dofile andtest procedure files generated by TestKompress are available.

Procedure

1. Invoke FastScan. The setup prompt displays.

2. Run the bypass dofile. For example:

SETUP> dofile created_bypass.dofile

3. Change to ATPG system mode to run DRC. For example:


4. Check for and debug any DRC violations.

5. Create basic ATPG patterns as you would for a design without EDT. For example:

Special TopicsTestKompress and Boundary Scan (External Flow)


ATPG> add faults /my_coreATPG> create patternsATPG> report statisticsATPG> report scan volume

This example creates patterns with dynamic compression. Be sure to add faults only onthe core of the design (assumed to be “/my_core” in this example) and disregard theEDT logic.

The Report Scan Volume command provides information for analyzing pattern data andachieved compression.

Standard ATPG patterns that utilize the bypass circuitry are generated.

Related Topics

TestKompress and Boundary Scan (ExternalFlow)

The information in this section applies to the external EDT logic location flow.

Flow overview

NoteAs mentioned previously, boundary scan cells must not be present in your design beforeyou add the EDT logic. This is the same requirement that applies to I/O pads and is forthe same reason; to enable TestKompress to create the EDT logic as a wrapper aroundyour core design.

Once the EDT logic is created, you can use any tool to insert boundary scan. However, thefollowing sections assume you use BSDArchitect, which creates an RTL description of theboundary scan circuitry. Figure 5-2 shows a conceptual view of how BSDArchitect incorporatesthis boundary scan description into a wrapper that in turn instantiates the EDT wrappercontaining the EDT logic and the core design.

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 theboundary scan simply coexists with EDT. This is described in the next section,“Boundary Scan Coexisting with EDT Logic.”

• Drive the EDT logic clock, update, and bypass signals with the TAP controller asdescribed in the section, “Driving TestKompress with the TAP Controller.”

Using Bypass Patterns in FastScanPreparing for Test Pattern Generation

Generating Test PatternsSimulating the Generated Test Patterns



August 2009

These two approaches are described in the following sections.

Boundary Scan Coexisting with EDT LogicThis section describes how EDT logic can coexist with boundary scan and provides a flowreference for this methodology. This approach enables the EDT logic to be controlled byprimary input pins and not by the boundary scan circuitry. In test mode, the boundary scancircuitry just needs to be reset. Also, all PIs and POs are directly accessible.

Invoking BSDArchitectIssue 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

NoteBSDArchitect only needs the top level wrapper, not the complete netlist.

Inserting Boundary Scan CircuitryIssue the following commands to configure the scan channels to be accessible through PIs andPOs and all control signals to be controlled by PIs:

BSDA> runBSDA> report bscan cellBSDA> report bscan statusBSDA> save bscan -replace

The boundary scan circuit in the resulting file, edt_top_bscan.v, will include the TRST port forthe TAP interface, which provides an asynchronous reset for the TAP controller. This is theBSDArchitect default unless you use the Set Bscan Reset command to eliminate the TRST port.

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

NoteSet Bscan Pullup is a BSDArchitect command that turns off the generation of pull-upresistors. For information on the use of this command, refer to the BSDArchitectReference Manual.



Preparing to Synthesize Boundary Scan and EDT LogicPrior to synthesizing the EDT logic and boundary scan circuitry, you should ensure any scriptsused for synthesis include the boundary scan circuitry. For example, the Design Compilersynthesis script that TestKompress generates needs the following modifications (shown in boldfont) to ensure the boundary scan circuitry is synthesized along with the EDT logic:

NoteThe modifications are to the example script shown in the “Synthesis Script ExternalFlow” 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.vread -f verilog created_edt.vread -f verilog created_edt_top.vread -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_clockcreate_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 edt_clockset_dont_touch_network edt_clockset_clock_transition 0.0 tck /*ADDED*/set_dont_touch_network tck /*ADDED*/

/* Avoid assign statements in the synthesized netlist.set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

/* Compile design */uniquifyset_dont_touch cpucompile -map_effort medium

/* Report design results for EDT logic */report_area > created_dc_script_report.outreport_constraint -all_violators -verbose >>

created_dc_script_report.outreport_timing -path full -delay max >> created_dc_script_report.outreport_reference >> created_dc_script_report.out

/* Remove top-level module */



August 2009

remove_design cpu

/* Read in the original core netlist */read -f verilog gate_scan.vcurrent_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 boundaryscan, you are ready to synthesize the design. This is described in the section, “AboutSynthesizing EDT Logic.”

Modifying the Dofile and Procedure File for Boundary Scan

NoteThe 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 filecreated by TestKompress. Typical changes include:

• The internal scan chains are one level deeper in the hierarchy because of the additionallevel added by the boundary scan wrapper. This needs to be taken into consideration forthe Add Scan Chains command.

• The boundary scan circuitry needs to be initialized. This typically requires you to reviseboth the dofile and test procedure file.

• You may need to make additional changes if you drive TestKompress signals with theTAP controller.

In the simplest configuration, the EDT logic is controlled by primary input pins, not by theboundary 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, “Test Pattern Generation Files,”except now it includes the changes (shown in bold font) necessary to support boundary scanwhen configured simply to coexist with EDT logic. The boundary scan circuitry is assumed toinclude a TRST asynchronous reset for the TAP controller.

//// Written by TestKompress//

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 clkadd clocks 0 edt_clock

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, “Test PatternGeneration Files,” must also be changed to accommodate boundary scan circuitry that youconfigure to simply coexist with EDT logic. Here is that file again, but with example changesfor boundary scan added (in bold font). This modified file was saved with the new namemodified_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;pulse ramclk 200 100;period 400 ;

end;



end;end;



August 2009


force_sci ;force edt_update 0 ;measure_sco ;pulse clk ;pulse edt_clock ;

end;end;


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;


force edt_clock 0 ;...force tms 1;force tck 0;force trst 0;

end;cycle =

force trst 1;end;

end;

Driving TestKompress with the TAP ControllerYou can drive one or more TestKompress signals from the TAP controller; however, there are afew more requirements and restrictions than in the simplest case where the boundary scan justcoexists with EDT logic. Some of these apply when you set up the boundary scan circuitry,others when you generate patterns:

• If you want to completely drive the EDT logic from the TAP controller, you first shoulddecide on an instruction to drive the EDT channels. BSDArchitect provides theINT_SCAN instruction that, in a traditional scan design, enables all the internal scanchains to be configured into one long chain and placed between TDI and TDO, while PIsand 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 registerthe 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 specifiedinternal core register between TDI and TDO. With this configuration, any remainingchannels can be driven directly by the PIs and observed on the POs.

NoteTestKompress 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 duringEDT 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 clockTCK 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 threeintervening TCK pulses between the pulse corresponding to the last shift and thecapture. These three pulses need to be suppressed for the clock supplied to the core. Asdescribed next, BSDArchitect can generate the gating logic necessary to suppress thesethree pulses for any one core clock.

• Once you define the core register and specify it as the target register for the INT_SCANinstruction, the next step is to specify the scan interface using the Set Iscan Interfacecommand. The scan interface consists of the type of scan, the scan enable signal, thescan 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 byrouting the TCK signal through gating logic, as described in the preceding bullet. Pleaserefer to the BSDArchitect Reference Manual for complete information about the otherswitches.

The key point to remember is, if there are other clocks, they also need to be driven by thegated TCK signal. The Set Iscan Interface command currently only supports a singlescan clock. To obtain the logic necessary to drive additional clocks, you can use AddPort Connection command. The following example multiplexes two additional clocks,“nclk” and “edt_clock” with TCK, using INT_SCAN as the select signal:


Special TopicsUsing Pipeline Stages in the Compactor

August 2009

// Define EDT channel as a core registeradd 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 multiplexerinputs 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/unloadprocedure, so as not to restrict clocking in the capture window. Typically, the EDT clockmust be in its off state in the capture window. Because there is already a restriction inthe capture window due to the “set capture clock TCK -atpg” command, you can supplythe EDT clock from the same waveform as the core clock without adding any moreconstraints. To update the EDT logic, the EDT update signal must now be asserted in thecapture window. You can use the Capture-DR signal from the TAP controller to drivethe 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 outputif you are using Design Compiler for synthesis as described previously in “Modifyingthe BSDArchitect Output.” You should also modify any scripts you use for synthesis toinclude the boundary scan circuitry. For an example of a Design Compiler script withthe necessary changes, see the section, “Preparing to Synthesize Boundary Scan andEDT Logic.”

Using Pipeline Stages in the CompactorPipeline stages can sometimes improve the overall rate of data transfer through the logic in thecompactor by increasing the scan shift frequencies. Pipeline stages are flip-flops that holdintermediate values output by a logic level so that values entering that logic level can be updatedearlier in a clock cycle. Because the EDT logic is relatively shallow, most designs do needcompactor pipeline stages to attain the desired shift frequency. The limiting factors on shiftfrequencies 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 SetEDT -Pipeline_logic_levels_in_compactor command when creating the EDT logic. Thesepipeline stages are clocked by the EDT clock use lockup cells as described in the section,“Lockups Between Scan Chain Outputs and Compactor” on page 136.

NoteThe -Pipeline_logic_levels_in_compactor switch specifies the maximum number ofcombinational logic levels (XOR gates) between compactor pipeline stages, not thenumber of pipeline stages. The number of logic levels between any two pipeline stages isused to control the propagation delay between pipeline stages.

Special TopicsUsing Pipeline Stages Between Pads and Channel Inputs or Outputs


Using Pipeline Stages Between Pads andChannel Inputs or Outputs

When the signal propagation delay between a pad and the corresponding channel input or outputis excessive, you may want to add pipeline stages. Following the guidelines in this section, youcan add pipeline stages between a top level channel input pin/pad and its correspondingdecompressor input, or between a compactor output and its corresponding channel outputpin/pad. Different channel inputs or outputs may have a varying number of pipeline stages.

Typically, pipeline stages are inserted throughout the design during top-level design integration.Pipeline stages are generally not placed within the EDT logic.

Important: To use channel pipeline stages, you must enable them with the Set EDT Pins-Pipeline_stages command in the Pattern Generation Phase. You need to also modify theassociated test procedure file as described in the following subsections.

Channel Output PipeliningTo support channel output pipelines, TestKompress ensures there are enough shift cycles perpattern to flush out the pipeline and observe all scan chains. Without pipelining, the number ofadditional shift cycles per pattern, compared to the length of the longest scan chain, is typicallyfour. As long as the total number of output pipeline stages (including both compactor andchannel output pipelining) is less than or equal to four, no additional shift cycles are added. Ifthe total number of output pipeline stages is more than four, the number of additional shiftcycles is increased to equal the number of pipeline stages.

Channel Input PipeliningWhile the contents of the channel output pipeline stages at the beginning of shifting each patternare irrelevant since they will be flushed out, the contents of the channel input pipeline stages domatter because they will go to the decompressor when shifting begins (just after thedecompressor is initialized in the load_unload procedure).

Important: At the beginning of shift for every pattern, all channel input pipeline stages mustcontain a value of zero. This can be achieved by a number of different methods with differenttrade-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 inputpipeline stages. If the number of additional shift cycles is four without input pipelining, and thechannel input with the most pipeline stages has two stages, the tool will increment to six thenumber of additional shift cycles in each pattern.

If you have a choice between using either input or output pipeline stages, you should chooseoutput stages for the following reasons:



August 2009

• The number of shift cycles for the same number of pipeline stages is higher when thepipeline stages are on the input side

• Accommodating the initialization requirement for pipeline stages on the input siderequires extra effort on your part.

Clocking of Channel Input Pipeline StagesIf you use channel input pipelining, you must ensure there is no clock skew between the channelinput pipeline and the decompressor. If you use channel output pipelining, you must ensurethere is no clock skew between the compactor (if you also use compactor pipelining) and thechannel 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 bythe leading edge of the EDT clock. If the channel input pipeline is not clocked by the EDTclock, ensure there is a lockup cell between the pipeline and the decompressor.

NoteEDT 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 stagesin bypass mode, captures on the trailing edge of the clock. This is because that first cell ofthe chain, which is normally a master, becomes a copy of the last input pipeline stage inbypass mode. To resolve this, you must add at the end of the pipeline stages for aparticular 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.

Clocking of Channel Output Pipeline StagesOn the output side, the last state element driving the channel output is either a compactorpipeline stage clocked by the EDT clock or the last elements of the scan chains when thecompactor has no pipelining. In addition to ensuring no clock skew between thechains/compactor and the pipeline stages, you must ensure that the first pipeline stages captureon the leading edge (LE) when no compactor pipelining is used. This is because if the last scancell in a chain captures on the LE and the path from the last scan cell to the channel pipeline iscombinational, and the channel pipeline stage captures on the trailing edge (TE), the pipelinestage is essentially a copy during shift and the last scan cell no longer gets observed.

To ensure there is no clock skew between the pipeline stages and the compactor outputs, youcan use the Set EDT Pins -CHange_edge_on_compactor_output command to specify whethercompactor output data changes on the LE or TE of the EDT clock. For example, specify thecompactor output changes at the trailing edge of the clock before feeding LE pipeline stages.Depending on your application, TestKompress automatically inserts lockup cells and outputchannel pipeline stages as needed. For more information, see Set EDT Pins in the ATPG andFailure Diagnosis Tools Reference Manual.



If you use pipeline stages clocked with the rising edge of the edt_clock, TestKompress insertslockup cells to balance clock skew on the output side pipeline registers. For more information,see “Lockups Between Channel Outputs and Output Pipeline Registers” section in this chapter.

If the clock used for the pipeline stages is not a shift clock, it must be pulsed in the shiftprocedure.

Initializing the Input Channel PipelineAs mentioned earlier in the “Channel Input Pipelining” section, the input channel pipelinestages must contain zeros before shifting in any pattern. TestKompress pattern generationassists with this by ensuring every pattern generated has sufficient trailing zeros (ones for thechannels 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 disturbthe scan cells).

o Use the edt_update and edt_clock signals to perform a synchronous reset as done forinitializing 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 zerosthat get shifted into the input pipeline stages at the end of shift (for every pattern) are notchanged during capture. This may be attractive if you have no direct reset mechanismfor the input pipeline stages and want to avoid routing reset signals.

This option has two components: How to initialize the pipeline stages for the firstpattern, and how to ensure that zeros shifted into the pipeline stages at the end of shiftare not changed during capture.

o Initializing the pipeline stages before the first pattern can be done in the test_setupprocedure by forcing all channel pins with pipeline stages to zero (one if there isinversion in the pad, between the pin and the pipeline stages), and pulsing thepipeline stages clock(s) as many times as the number of pipeline stages.

NoteIf the pipeline stages use the EDT clock, the channel pins must be forced to zero (or one ifthere is channel inversion) in load_unload as well, since the EDT clock is pulsed there aswell (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:



August 2009

• 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 thedecompressor (no clock skew), using the EDT clock to control the input pipelinestages is recommended.

DRC for Channel Input PipeliningThe K19 and K22 rules checks detect errors in initializing the channel input pipeline stages. Ifthe pipeline is not correctly initialized for the first pattern, K19 report mismatches on the EDTblock channel inputs - assuming the hierarchy is not dissolved and the EDT logic is identified. Ifthe EDT logic channel inputs cannot be located, e.g. because the design hierarchy wasdissolved, K19 reports that Xs are shifted out of the decompressor. On the EDT logic channelinputs, the simulated values would mismatch within the first values shifted out, while the rest ofthe bits subsequently applied would match.

If the pipeline is correctly initialized for the first pattern and K19 passes, but the pipelinecontents change (during capture or the following load_unload prior to shift) such that it nolonger contains zeros, K22 fails. K19 and K22 detect these cases if input channel pipelining isdefined and issue warnings about the possible problems related to channel pipelining.

DRC for Channel Output PipeliningThe K20 rule check considers channel output pipelining, in addition to any compactorpipelining that may exist. K20 will report any discrepancy between the number of identified andspecified pipeline stages between the scan chains and pins (including compactor and channeloutput pipelines).

If the first stage of the channel output pipeline is TE instead of LE, this will result in one lesscycle of delay than expected, which will also trigger a K20 violation. If the first stage is TE, andthe user specifies one less pipeline stage, those 2 errors may mask each other and no violationmay be reported. However, this may result in mismatches during serial pattern simulation.

ExamplesThe 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 TestKompressand is explained in the Modular TestKompress chapter), then specifies that all output channelsof the core1 block have one pipeline stage:

set current block core1set edt pins output_channel -pipeline_stages 1



Following are the modified test procedures for a design with two channels having inputpipelining. 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 pinand first pipeline stage), while the other channel (edt_channel2) has three pipeline stages and noinversion. The user-added events that support the pipelining are shown in bold, comments inbold italics.

procedure test_setup =timeplate gen_tp1 ;

// Initialize up to five input pipeline stagescycle =

force edt_channel1 1 ; // 5 pipeline stages, inversionforce edt_channel2 0 ; // 3 pipeline stages, no inversionpulse 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;


// 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 ;force system_clk 0 ;force edt_bypass 0 ;force edt_clock 0 ;force edt_update 1 ;force ramclk 0 ;force scan_enable 1 ;pulse edt_clock ;

end;apply shift 21 ;

end;


Special TopicsUnderstanding How Lockup Cells are Inserted

August 2009

Understanding How Lockup Cells are InsertedThis section describes how lockup cells are inserted as part of the EDT logic. For anintroduction to lockup cells, refer to “Merging Scan Chains with Different Shift Clocks” in theScan and ATPG Process Guide. TestKompress analyzes the timing relationships between thewaveform edges of the clocks that control the sequential elements between the scan chains andthe EDT logic. And, when necessary, edge-triggered flip-flops are inserted as lockup cells tosynchronize the clocks and protect the data. You can use the Report EDT Lockup_cellscommand to display a detailed report of the lockup cells inserted by TestKompress.

When Are Lockup Cells Needed?The relationship between the clock that controls each sequential element sourcing data (sourceclock) and the clock that controls the sequential element receiving the data (destination clock)are analyzed. By default, the following criteria is used to determine when lockup cells areneeded as follows:

• If both clocks have identical waveform timing within a tester cycle; they are “on” at thesame time and their edges are aligned, they are considered overlapping clocks. Whenclocks are overlapping, lockup cells are necessary to protect data, and they areautomatically inserted.

• If both clocks have different waveform timing within a tester cycle; only one clock is“on” at any time, their edges are not aligned, and the active edge of the destination clockoccurs earlier in the cycle than the active edge of the source clock, they are considerednon-overlapping. When clocks are non-overlapping, data is protected by the timingsequence, lockup cells are unnecessary, and none are inserted.

NotePartially overlapping clocks are not supported.

You can set up the EDT logic clock and scan chain clock to be non-overlapping if the EDT logicis pulsed before the shift clocks for all scan chains. When the EDT logic is set up in this manner,there is no need for lockup cells between the EDT logic and scan chains. However, a lockup celldriven by the EDT clock is still inserted between all bypass scan chains. For more information,see “Setting EDT Clock to Pulse Before Scan Shift Clocks” on page 58.

If your design contains a mix of overlapping and non-overlapping clocking, or the shift clocksare pulsed before the EDT logic clock, you must let TestKompress analyze the design and insertlockup cells (default behavior) as described in the following sections:

• Lockups Between Decompressor and Scan Chain Inputs

• Lockups Between Scan Chain Outputs and Compactor



• Lockups Between Channel Outputs and Output Pipeline Registers

• Lockups in the Bypass Circuitry

Lockups Between Decompressor and Scan Chain InputsThe decompressor is located between the scan channel input pins and the scan chain inputs. Itcontains sequential circuitry clocked by the EDT clock. As the off state of the EDT clock (at theEDT logic module port) is always 0, leading edge triggered (LE) flip-flops are used in thissequential circuitry. Scan chain clocking does not utilize the EDT clock. Therefore, there is apossibility 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 thedecompressor stage (source) and the first active sequential element in the scan chain(destination).

NoteThe first sequential element in the scan chain could be an existing lockup cell (atransparent 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 changeedge 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 scancell’s output. The tool inserts lockup cells between the decompressor and scan chains based onthe following rules:

• A lockup cell is inserted when a source cell’s change edge coincides with the destinationcell’s capture edge.

• A lockup cell is inserted when the change edge of the source cell precedes the captureedge of the destination cell.

In addition, the tool attempts to place lockup cells in a way that introduces no additional delaybetween the decompressor and the scan chains. It also tries to minimize the number of lockupcells at the input side of the scan chains. The lockup cells are driven by the EDT clock to reducerouting of the system clocks from the core to the EDT logic.

Table 7-1 summarizes the relationships and the lockup cells the tool inserts on the basis of thepreceding rules, assuming there is no pre-existing lockup cell (transparent latch) between thedecompressor and the first scan cell in each chain.



August 2009

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 LElockup cell at the input of the scan chain only when necessary, as shown in Table 7-1.

NoteIf there is a pre-existing transparent latch between the decompressor and the first scancell, the tool will detect it and add a single lockup cell (LE) between the decompressorand the latch. This ensures the correct value is captured into the first scan cell from thedecompressor.

Lockups Between Scan Chain Outputs and CompactorWhen compactor pipeline stages are inserted, lockup cells are inserted as needed in front of thefirst pipeline stage. Pipeline stages are LE flip-flops clocked by the EDT clock, similar to thesequential elements in the decompressor.

Table 7-1. Lockup Cells Between Decompressor and Scan Chain Inputs

ClockWaveforms

Sourceclock

Dest. clock Source1

changeedge

1. LE = Leading edge, TE = Trailing edge.

Dest.1, 2

captureedge

2. Active high/low = Active clock level when destination is a latch. Active high means the latch is activewhen 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.

# Lockupsinserted

Lockup3

edge(s)

3. Lockup cells are driven by the EDT clock.

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(TE)

2 TE, LE

EDT clock Scan clock LE active low(LE)

2 TE, LE

Non-Overlapping4

4. These are cases for which the tool determines the source edge precedes the destination edge. (Lockupsare unnecessary if the destination edge precedes the source edge).

EDT clock Scan clock LE LE 2 TE, LE

EDT clock Scan clock LE TE 2 TE, LE

EDT clock Scan clock LE active high(TE)

2 TE, LE

EDT clock Scan clock LE active low(LE)

2 TE, LE



The clock timing between the last active sequential element in the scan chain (source) and thefirst sequential element (first pipeline stage) that it feeds in the compactor (destination) isanalyzed. Similar to the input side of the scan chains, TestKompress analyzes the need forlockup 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 atwhich the data on the source scan cell’s output may update. The capture edge is the capturingtransition at which data is latched on the destination scan cell’s output.

Lockup cells driven by the EDT clock are added according to the following rules:

• A lockup cell is inserted when a source cell’s change edge coincides with the destinationcell’s capture edge.


In addition, the tool attempts to place lockup cells in a way that introduces no additional delaybetween the scan chains and the compactor pipeline stages. It also tries to minimize the numberof lockup cells at the output side of the scan chains. The lockup cells are driven by the EDTclock so as to reduce routing of the system clocks from the core to the EDT logic.

Table 7-2 shows how the tool inserts lockup cells in the compactor.

Table 7-2. Lockup Cells Between Scan Chain Outputs and Compactor

ClockWaveforms

Sourceclock

Dest. clock Source1, 2

changeedge

1. LE = Leading edge, TE = Trailing edge.2. Active high/low = Active clock level when source is a latch. Active high means the latch is active whenthe 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.

Dest.1

captureedge

# Lockupsinserted

Lockup3

edge(s)

Overlapping Scan clock EDT clock LE LE 1 TE

Scan clock EDT clock TE LE none -

Scan clock EDT clock active high(LE)

LE 1 TE

Scan clock EDT clock active low(TE)

LE none -

Non-Overlapping4

Scan clock EDT clock LE LE 1 TE

Scan clock EDT clock TE LE 1 TE

Scan clock EDT clock active high(LE)

LE 1 TE

Scan clock EDT clock active low(TE)

LE 1 TE



August 2009

Lockups Between Channel Outputs and Output PipelineRegisters

TestKompress allows you to insert pipeline stages during the top-level design integrationprocess to offset excessive delays between the EDT logic and pad terminals. For moreinformation, see “Using Pipeline Stages Between Pads and Channel Inputs or Outputs” onpage 129.

Depending on the clocking of the last scan cells, lockup cells may required between the scanchain outputs and the output pipeline registers.

TestKompress inserts lockup cells between the compactor and output pipeline registers usingthe criteria described in Table 7-2.

If pipeline registers are driven by the rising edge of the edt_clock, the proper lockup cells areinserted. If the pipeline registers use a different clock or edge, the lockup cells may be invalid.

The inserted lockup cells are driven by the edt_clock. For more information onenabling/disabling compactor pipelining, see the Set EDT command.

Lockups in the Bypass CircuitryThe number and location of lockup cells TestKompress inserts in the bypass logic depend on theactive 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 mayupdate. The capture edge is the capturing transition at which data is latched on the destinationscan cell’s output.

The number and location of lockup cells also depend on whether the first and last activesequential elements in the scan chain are clocked by the same clock. The first and last activesequential elements in a scan chain could be existing lockup latches and may not be part of ascan cell. TestKompress inserts the lockup cells between source and destination scan cellsaccording to the following rules:

• A lockup cell is inserted when a source cell’s change edge coincides with the destinationcell’s capture edge and the cells are clocked by different clocks.


• If multiple lockup cells are inserted, the tool ensures that:

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. (Lockupsare unnecessary if the destination edge precedes the source edge).



o A master/copy scan cell combination is always driven by the same clock. Thisprevents the situation where captured data in the master cell is lost because adifferent 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 timewhen the destination cell can capture new data. This makes the first scan cell ofevery 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 theearliest data capture edge of the first lockup, the first lockup cell is driven with thesame clock that drives the source.

• If there is an active lockup cell at the beginning of a scan chain, the tool identifies it andtreats it as the source cell.

• If a lockup latch already exists at the end of a scan chain, the tool learns its behavior andtreats it as the source cell.

Table 7-3 summarizes how the tool inserts lockup cells in the bypass circuitry.

Table 7-3. Bypass Lockup Cells

ClockWaveforms

Source1

clockDest.1

clockSource2, 3

changeedge

Dest.2, 3

captureedge

# Lockupsinserted

Lockupedge(s)

Overlapping clk1 clk1 LE LE none -

clk1 clk1 LE TE 1 TE clk1

clk1 clk1 TE TE none -

clk1 clk1 TE LE none -

Overlapping clk1 clk2 LE LE 1 TE clk1

clk1 clk2 LE TE 2 LE clk1,TE clk2

clk1 clk2 TE TE 2 LE clk1,TE clk2

clk1 clk2 TE LE none -

Non-Overlapping4

clk1 clk2 LE LE 2 LE clk1,TE clk2

clk1 clk2 LE TE 2 LE clk1,TE clk2

clk1 clk2 TE TE 2 LE clk1,TE clk2

clk1 clk2 TE LE 2 LE clk1,TE clk2



August 2009

Overlapping clk1 clk1 active high(LE)

active high(TE)

1 TE clk1

clk1 clk1 active high(LE)

active low(LE)

1 TE clk1

clk1 clk1 active low(TE)

active low(LE)

none -


active high(TE)

none -

Overlapping clk1 clk2 active high(LE)

active high(TE)

2 LE clk1,TE clk2


active low(LE)

2 LE clk1,TE clk2


active low(LE)

none -


active high(TE)

2 LE clk1,TE clk2

Non-Overlapping4


active high(TE)

2 LE clk1,TE clk2


active low(LE)

2 LE clk1,TE clk2


active low(LE)

2 LE clk1,TE clk2


active high(TE)

2 LE clk1,TE clk2

Overlapping clk1 clk1 LE active high(TE)

1 TE clk1

clk1 clk1 LE active low(LE)

none -


LE none -


LE none -


ClockWaveforms

Source1

clockDest.1

clockSource2, 3

changeedge

Dest.2, 3

captureedge

# Lockupsinserted

Lockupedge(s)



Overlapping clk1 clk2 LE active high(TE)

2 LE clk1,TE clk2


2 LE clk1,TE clk2


LE 1 TE clk1


LE none -

Non-Overlapping4

clk1 clk2 LE active high(TE)

2 LE clk1,TE clk2


2 LE clk1,TE clk2


LE 2 LE clk1,TE clk2


LE 2 LE clk1,TE clk2

Overlapping clk1 clk1 TE active high(TE)

none -

clk1 clk1 TE active low(LE)

none -


TE 1 TE clk1


TE none -

Overlapping clk1 clk2 TE active high(TE)

2 LE clk1,TE clk2


2 LE clk1,TE clk2


TE 2 LE clk1,TE clk2




ClockWaveforms

Source1

clockDest.1

clockSource2, 3

changeedge

Dest.2, 3

captureedge

# Lockupsinserted

Lockupedge(s)


Special TopicsEvaluating Performance

August 2009

Evaluating PerformanceThe purpose of this section is to focus on the parts of the TestKompress flow that are necessaryto perform experiments on compression rates and performance so you can make informedchoices about how to fine-tune performance.

Figure 7-2 illustrates the typical evaluation flow.

Non-Overlapping4

clk1 clk2 TE active high(TE)

2 LE clk1,TE clk2


2 LE clk1,TE clk2





1. clk1 & clk2 are the functional (scan) clocks.2. LE = Leading edge, TE = Trailing edge.3. Active high/low = Active clock level when source or destination is a latch. Active high means the latchis active when the primary input (PI) clock is on. Active low means the latch is active when the PI clockis off. (LE) or (TE) indicates the clock edge corresponding to the latch’s change/capture edge.4. These are cases for which the tool determines the source edge precedes the destination edge. (Lockupsare unnecessary if the destination edge precedes the source edge).


ClockWaveforms

Source1

clockDest.1

clockSource2, 3

changeedge

Dest.2, 3

captureedge

# Lockupsinserted

Lockupedge(s)



Figure 7-2. Evaluation Flow

The complete TestKompress flow, as described in Chapter 2, includes two separate invocationsof TestKompress. These are described in detail in the following chapters:

• Chapter 4: Creating EDT Logic Files

• Chapter 6: Generating/Verifying Test Patterns

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 thesepatterns 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 apoint of reference using FastScan.

Establishing a Point of ReferenceTo 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 calculatethe test data volume for measuring compression performance in the following way:

Synthesized

(no scan)Netlist


Netlist

Insert Scan

FromSynthesis

Generate Patternswith FastScan

Generate Patternswith TestKompress

Test Data Volume #scan loads( ) volume per scan load( )×=

#scan loads( ) #shifts per patterns( ) #scan channels( )××=



August 2009

Note#patterns may provide a reasonable approximation for #scan loads, but be aware thatsome patterns require multiple scan loads.

For a regular scan-based design without EDT, the volume per scan load will remain fairlyconstant for any number of scan chains because the number of shifts decreases when the numberof chains increases. Therefore, it does not matter much which scan chain configuration you usewhen you establish the reference point.

In the following sections, the required steps to establish a point of reference are describedbriefly. A design configured with eight scan chains is assumed.

Invoke FastScanIssue the following command to invoke FastScan on the netlist with eight scan chains andexecute 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

Run DRCIssue the following command to run DRC and prepare for running ATPG:


Verify that no DRC violations occur.

Generate PatternsAssuming 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 inboth the FastScan run and the EDT run.

ATPG> add faults /cpu_iATPG> set fault sampling 10ATPG> create patternsATPG> report statisticsATPG> report scan volume

Note the test coverage and the total data volume as reported by the Report Scan Volumecommand.

Measuring PerformanceIn 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) violations, which canexplain lower compression performance.

Also, you can do a run that compares the results with and without fault sampling.

Improving PerformanceTable 7-4 suggests some analyses you can do if the measured performance is not as expected:

Varying the Number of Scan ChainsThe effective compression depends primarily on the ratio between the number of internal scanchains and the number of external scan channels. In most cases, it is sufficient to just do anapproximate configuration. For example, if the number of scan channels is eight and you need4X compression, you can configure the design with 38 chains. This will typically result in 3.5Xto 4.5X compression.

In certain cases, such a rough estimate is not enough. Usually, the number of scan channels isfixed because it depends on characteristics of the tester. Therefore, to experiment with differentcompression outcomes, different versions of the netlist (each with a different number of scanchains) are necessary.

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 are masked by default. 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.



August 2009

Varying the Number of Scan ChannelsAnother alternative is to first use a design with a relatively high number of scan chains, andexperiment with different numbers of channels. You can do these experiments, varying thechain-to-channel ratio, within one invocation of TestKompress. Then, when you find theoptimum ratio, reconfigure the scan chains to match the number of scan channels you want. Youcan achieve similar test data volume reduction for a 100:10 configuration as for a 50:5configuration.

For example, assume you have a design with 350,000 gates and 27,000 scan cells. If a certaintester requires the chip to have 16 scan channels, and your compression goal is to have no lessthan 4X compression, you might proceed as follows:

1. Determine the approximate number of scan chains you need. This example assumes areasonable estimate is 60 scan chains.

2. Use DFTAdvisor to configure the design with many more scan chains than youestimated, say, 100 scan chains.

3. Run TestKompress for 30, 26, 22, and 18 scan channels. Notice that these numbers areall between 1-2X the 16 channels you need.

NoteUse the same commands with TestKompress that you used in FastScan when youestablished a point of reference, with one exception: in TestKompress, you must use theSet EDT command to reconfigure the number of scan channels.

Suppose the results show that you achieve 4X compression of the test data volume using 22scan channels. This is a chain-to-channel ratio of 100:22 or 4.55. For the final design, where youwant to have 16 scan channels, you would expect approximately a 4X reduction with 16 x 4.55= 73 scan chains.

Determining the Limits of CompressionYou will find that the maximum amount of compression you can attain is limited by the ratio ofscan chains to channels. If the number of scan channels is fixed, the number of scan chains inyour design becomes the limiting factor. For example, if your design has eight scan chains, themost 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 ofscan chains.

Speeding up the ProcessIf you need to perform multiple iterations, either by changing the number of scan chains or thenumber of scan channels, you can speed up the process by using fault sampling. When you usefault sampling, first perform ATPG with fault sampling using FastScan. Then, use the samefault sample when generating patterns for TestKompress.

Special TopicsUnderstanding Compactor Options


NoteYou 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 arelatively short test runtime. Be aware that sampling has the potential to produce askewed result and is a means of estimation only.

Understanding Compactor OptionsThere are two compactors available in TestKompress:

• Xpress

The Xpress compactor is the second generation compactor generated by default. TheXpress compactor optimizes compression for all designs but is especially effective fordesigns that generate X values. The Xpress compactor observes all chains with knownvalues and masks out scan chains that contain X values. This X handling results in fewertest patterns being required for designs that generate X values.

Depending on the application, the EDT logic generated with the Xpress compactorrequires additional clocking cycles. The additional clocking cycles are determined bythe ratio of scan chains to output channels and are relatively few when compared withthe total shift cycles.

• Basic

The basic compactor is the first generation compactor enabled with the-COMpactor_type BAsic switch with the Set EDT command.

The basic compactor should be used for designs that do not generate many unknown (X)values. Due to scan cell masking, the basic compactor is significantly less effective ondesigns that generate unknown (X) values in scan cells when a test pattern is applied.

The EDT logic generated when the basic compactor is used may be up to 30% smallerthan EDT logic generated when the Xpress compactor is used. However, when X valuesare present, more test patterns may be required.



August 2009

Basic Compactor Architecture

Figure 7-3. Basic Compactor

A mask code (prepended with a decoder mode bit) is generated with each test pattern todetermine which scan chains are masked or observed. The basic compactor determines whichchains to observe or mask using the mask code as follows:

1. The decompressor loads the mask code into the mask shift register.

2. The mask code is parallel-loaded into the mask hold register, where the decoder modebit determines the observe mode: either one scan chain or all scan chains.

3. The mask code in the mask hold register is decoded and each bit drives one input of amasking AND gate in the compactor. Depending on the observe mode, the output ofthese AND gates is either enabled or disabled.



Xpress Compactor Architecture

Figure 7-4. Xpress Compactor

A mask code (prepended with a decoder mode bit) is generated with each test pattern todetermine which scan chains are masked or observed. The Xpress compactor determines whichchains to observe or mask using the mask code as follows:

1. Each test pattern is loaded into the decompressor through a mask shift register on theinput channel.

2. The mask code is appended to each test pattern and remains in the mask shift registeronce the test pattern is completely loaded into the decompressor.

3. The mask code is then parallel-loaded into the mask hold register, where the decodermode bit determines whether the basic decoder or the XOR decoder is used on the maskcode.

o The basic decoder selects only one scan chain per compactor. The basic decoder isselected when there is a very high rate of X values during scan testing or duringchain test to allow failing chains to be fully observed and easy to diagnose.

o The XOR decoder masks or observes multiple scan chains per compactor, dependingon the mask code. For example, if the mask code is all 1s, then all the scan chains areobserved.


Special TopicsUnderstanding Scan Chain Masking in the Compactor

August 2009

4. The decoder output is shifted through a multiplexer, and each bit drives one input on themasking AND gates in the compactor to either disable or enable the output, dependingon the decoder mode and bit value.

Understanding Scan Chain Masking in theCompactor

This section describes how and why scan chain masking is used in the compactor to ensureaccurate scan chain observations.

Why Masking is NeededTo facilitate compression, TestKompress inserts a compactor between the scan chain outputsand the scan channel outputs. In this circuitry, one or more stages of XOR gates compact theresponse from several chains into each channel output. Scan chains compacted into the samescan 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 thenblock the corresponding cell in Chain 2. If this X occurs in Chain 1 for all patterns, the value inthe corresponding cell in Chain 2 will never be measured. This is illustrated in Figure 7-5,where the row in the middle shows the values measured on the channel output.

Figure 7-5. X-Blocking in the Compactor

TestKompress records an X in the pattern file in every position made unmeasurable as a resultof the actual occurrence of an X in the corresponding cell of a different scan chain in the samecompactor group. This is referred to as X blocking. The capture data for Chain 1 and Chain 2that you would see in the ASCII pattern file for this example would look similar to Figure 7-6.The Xs substituted by the tool for actual values, unmeasurable because of the compactor, areshown in red.

Channel

1

Output

0

Chain Output

Chain Output

Chain 1

Chain 21 1 1

0111

111

0

0

0000

XX

XX

X

X

X

X

X

compactor



Figure 7-6. X Substitution for Unmeasurable Values

Resolving X Blocking with Scan Chain MaskingThe solution to this problem is a mechanism utilized in the EDT logic called “scan chainmasking.” This mechanism allows selection of individual scan chains on a per-pattern basis.Figure 7-7 shows how this would work for the example of the preceding section. For onepattern, only the values of Chain 2 are measured on the scan channel output. This way, the Xs inChain 1 will not block values in Chain 2. Similar patterns would then also be produced whereChain 2 is disabled while the values of Chain 1 are observed on the scan channel output.

Figure 7-7. Example of Scan Chain Masking

When using scan chain masking, TestKompress records the actual measured value for each cellin the unmasked, selected scan chain in a compactor group. TestKompress masks the rest of thescan chains in the group, which means the tool changes the values to all Xs. With masking, thecapture data for Chain 1 and Chain 2 that you would see in the ASCII pattern file would looksimilar to Figure 7-8, assuming Chain 2 is to be observed and Chain 1 is masked. The values thetool changed to X for the masked chain are shown in red.

1 0

Chain 1

Chain 21 1 1

111

X

XX00

XXX

XX

ChannelOutput

Chain 1

Chain 2

Chain Output

Chain Output1 0 X1 11

1

1 11

1 1 1

XX

XX

X X X

0

00

0000

0

1 compactor

maskinggates



August 2009

Figure 7-8. TestKompress Handling of Scan Chain Masking

Following is part of the TestKompress transcript from a pattern generation run for a simpledesign where masked patterns were used to improve test coverage. The design has three scanchains, each containing three scan cells. One of the scan chain pins is shared with a functionalpin, contrary to recommended practice, in order to illustrate the negative impact such sharinghas on test coverage.

// ------------------------------------------------------// 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.// deterministic ATPG invoked with abort limit = 30// EDT with scan masking. Dynamic compaction disabled.// --- ------ --- --- --- ---// 96 91.26% 0 16 6 12// --- ------ --- --- --- ---

1 0

Chain 1 (masked)

Chain 21 1 1

XXX XXXX

XXX

XX

0

Special TopicsFault Aliasing


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 andthe 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";chain "chain2" = "1X1";chain "chain3" = "0X1";

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 andchain3 and observes only chain2.

Fault AliasingAnother potential issue with the compactor used in the EDT logic is called fault aliasing.Assume one fault is observed by two scan cells, and that these scan cells are located in two scanchains that are compacted to the same scan channel. Further, assume that these cells are in thesame locations (columns) in the two chains and neither chain is masked. Figure 7-9 illustratesthis.

Assume that the good value for a certain pattern is a 1 in the two scan cells. This corresponds toa 0 measured on the scan channel output, due to the XOR in the compactor. If a fault occurs onthis 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 faultycircuit.


Special TopicsReordering Patterns

August 2009

Figure 7-9. Example of Fault Aliasing

The solution to this problem is to utilize scan chain masking. TestKompress does thisautomatically. In TestKompress, a fault that is aliased will not be marked detected for theunmasked pattern (Figure 7-9). Instead, the tool uses a masked pattern as shown in Figure 7-10.This mechanism guarantees that all potentially aliased faults are securely detected. Cases inwhich a fault is always aliased and requires a masking pattern to detect it are rare.

Figure 7-10. Using Masked Patterns to Detect Aliased Faults

Reordering PatternsWithin the TestKompress tool, you can reorder patterns using static compaction, using theCompress 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 backinto the tool, and then saving a portion of it using the -Begin and -End options to the SavePatterns command.

TestKompress does not support reordering of serial EDT patterns by a third-party tool, after thepatterns have been saved from the TestKompress tool.

ChannelOutput

Chain Output

Chain Output

Chain 1

Chain 21/0

1/0

1/0

Good/Faulty 0/0

Chain Output

Chain Output

Chain 1

Chain 21/0

1/0

1/0

ChannelOutput

Good/Faulty 1/0

0

1



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-11. Chain 1is six cells long and Chain 2 is three cells long. The captured values of the last three bits ofChain 1 are going to be XOR’d with the first three values of the next pattern being loaded intoChain 2. For regular ATPG, this problem does not occur because the expected values on Chain2, after you shift three positions, are all Xs. So you never observe the values being loaded aspart of the next pattern. But, if that is done with EDT, the last three positions of Chain 1 areXOR’d with X and faults observed on these last cells are lost. Because the padding data for theshorter scan chains is derived from the scan-in data of the next pattern, avoid reordering serialpatterns to ensure valid computed scan-out data.

Figure 7-11. Handling Scan Chains of Different Length

ChannelOutput

Pattern 1Pattern 2

000111

111 010Fill

1 01 0 1

0

1

00



August 2009


Chapter 8Modular TestKompress

About the Modular FlowModular TestKompress is the process used to integrate TestKompress into the block-leveldesign flow. Using TestKompress at the block-level is similar to using TestKompress at the top-level, except you create/insert EDT logic into each design block and then, integrate the blocksinto a top-level design and generate test patterns.

NoteIn this chapter, a EDT block refers to a design block that contains a full complement ofEDT logic controlling all the scan chains associated with the block.

The modular flow includes one or more of the standard top-level TestKompress flows. Forinformation on the standard top-level flows, see, “Understanding the TestKompress Flow” onpage 27 of this manual.

Requirements

• Block-level compression strategy

• Gate-level or RTL netlist for each block in the design

• DFTAdvisor or other scan insertion tool (optional)

• ATPG library

• Design Compiler or other synthesis tool

• ModelSim or other timing simulator


Modular TestKompressAbout the Modular Flow

August 2009

Modular Flow Diagram

Modular TestKompressAbout the Modular Flow


Flow Stage Descriptions

Related Topics

Generating Modular EDT Logic for a Fully Integrated Design

Table 8-1. Modular Flow Stage Descriptions

Stage Description

Integrate EDT logicinto each DesignBlock

EDT logic can be integrated into each design block using any ofthe standard top-level methods described in this document. Formore information, see the following sections of this document:• Integrating TestKompress at the RTL Stage• Understanding the TestKompress Flow

The first step to using TestKompress in your design flow isdeveloping a compression strategy. For more information, see“Creating a Block-level Compression Strategy” on page 160.

Create a Top-levelTest Procedure File

The test procedure files created by TestKompress for each blockmust be merged to form a top-level test procedure file.For more information, see “Creating a Top-level Test ProcedureFile” on page 165.

Create a Top-levelDesign

Design blocks must be integrated to form a single top-level designnetlist. For more information, see “Creating the Top-level Netlist”on page 172.

Create a Top-levelDofile

The dofiles created by TestKompress for each block must becombined to create a single top-level dofile. For more information,see “Creating the Top-level Dofile” on page 175.

Generate TestPatterns

Test patterns are set up and generated using the top-level netlist,test procedure file, and dofile. For more information, see“Generating Top-level Test Patterns” on page 178.

You should also create bypass test patterns for the top-level netlistat this point. For more information, see “Bypassing EDT Logic”on page 113.


Modular TestKompressUnderstanding Modular TestKompress

August 2009

Understanding Modular TestKompressThe EDT logic inserted in a design block controls all scan chains within the block.

Figure 8-1 shows an example of a modular design with four EDT blocks. Each EDT blockconsists of a design block with integrated EDT logic. The design also contains a separate EDTblock for the top-level glue logic. The top-level glue logic can be tested with EDT logic asshown or with bypass logic as described in “Bypassing EDT Logic” on page 113.

Figure 8-1. Modular Design with Five EDT blocks

Each EDT block has a discrete netlist, dofile, and test procedure file that are integrated togetherto form top-level files for test pattern generation.

Creating a Block-level Compression StrategyYou can create and insert EDT logic into design blocks with any of the methods outlined inChapters 2 through 5 of this manual. You can also mix and match methods between blocks.

Compactor

Decompressor

Compactor

Decompressor

Compactor

Decompressor

Compactor

Decompressor

Dcmpr

Comp

EDT block 5 (Top-level Glue Logic)

EDT block 1 EDT block 2

EDT block 3 EDT block 4

Modular TestKompressCreating a Block-level Compression Strategy


Reference the following rules and guidelines while developing your compression strategy forthe modular flow:

• Scan chain lengths should be balanced — Balanced scan chains yield optimalcompression. Plan the lengths of scan chains inside all blocks in advance so that top-level (inter-block) scan chain lengths are relatively equal. See “Balancing Scan ChainsBetween Blocks” on page 161.

• EDT logic names must be unique — When multiple EDT blocks are integrated into atop-level netlist, all of the EDT logic file names and internal module/instance namesmust be unique. See “Creating EDT Logic Files” on page 71.

• Each EDT block must have a discrete set of scan chains — Scan chains cannot beshared between blocks.

• Uncompressed scan chains must be connected to top-level pins — Uncompressedscan chains are scan chains not driven by or observed through the EDT logic.Uncompressed scan chains are supported if the inputs and outputs are connected directlyto top-level pins. Uncompressed scan chains can also share top-level pins. See“Including Uncompressed Scan Chains” on page 43.

• Only certain control pins can be shared with functional pins — These pins can beshared within the same EDT block. See “Sharing Functional Pins with EDT Pins” onpage 61.

• Control signals can be shared by EDT blocks — Control signals such as edt_update,edt_clock, edt_reset, scan_enable and test_en may be shared between EDT blocks; forexample, the edt_update signals from different blocks could be connected to the sametop-level pin. See “Creating the Top-level Netlist” on page 172.

• Scan channels must have dedicated top-level pins — Only input scan channelsbetween identical EDT blocks can share top-level pins. See “Sharing Input ScanChannels on Identical EDT blocks” on page 162.

• Block-level signals must be connected in the top-level netlist — This includesconnecting EDT logic signals to I/O pads and inserting any multiplexers needed forchannel output signals shared with functional signals. See “Creating the Top-levelNetlist” on page 172.

• EDT logic must be synthesized and verified for each block — See “Synthesizing theEDT Logic” on page 93 and “Generating/Verifying Test Patterns” on page 99.

Balancing Scan Chains Between BlocksDesign blocks may contain a large amount of hardware with many internal blocks and manyscan chains, so scan chain balance is very important for generating efficient test patterns. Youshould carefully plan the lengths of scan chains inside each design block so that all blocks haveapproximately the same scan chain lengths. The following sections provide information on scanchain planning at the block level:



August 2009

• “Determining How Many Scan Chains to Use” on page 43

• “Varying the Number of Scan Chains” on page 145

• “Varying the Number of Scan Channels” on page 146

You should target the same compression for every block and apportion available tester channelsaccording to the relative share of the overall design gate count contained in each block. Use thefollowing two equations to calculate balanced scan chain lengths across multiple blocks:

Tip: Since different designers may perform scan insertion for different design blocks, it isimportant to work together to select a scan chain length target that works for all blocks.

Sharing Input Scan Channels on Identical EDT blocksYou can set up identical EDT blocks to share input scan channels and top-level pins whenintegrating modular design blocks into a top-level netlist.

When EDT blocks share input scan channels, test patterns are broadcast via shared top-levelpins to all the identical EDT blocks simultaneously. This functionality reduces top-level pinrequirements and increases the compression ratio for the input side of the EDT logic.

Requirements

• EDT blocks must be identical as follows:

o Number of input channels and output channels must match

o Input, output, and compactor pipeline stages must match

o Order of scan chains and the number of scan cells in each must match

o Input channel/top-level pin inversions must match

• All corresponding input channels on identical EDT blocks must be shared in thecorresponding order. For example the following channels can be shared:

input channel 1 of block1, input channel 1 of block2, input channel 1 of block3 and soon.

Scan Chain Length# of Scan Cells in block

# of Channels for block( ) Chain-to-channel ratio( )×--------------------------------------------------------------------------------------------------------------------------------≈

# of Channels for block# of Scan Cells in block# of Scan Cells in chip

----------------------------------------------------------- # of top-level Channels×≈



Top-Level Dofile Modifications

You need to set up the input channel sharing when the block-level dofiles are integrated into atop-level dofile. Depending on the application, you can set up the input channel sharing in oneof two ways:

• Make top-level pins equivalent

Use this method when a top-level pin exists for each input channel by defining the pinsfor the corresponding input channels on each block as equivalent. For example:

add edt block core1set edt pin input 1 core1_edt_channels_in1set edt pin input 2 core1_edt_channels_in2add edt block core2set edt pin input 1 core2_edt_channels_in1set edt pin input 2 core2_edt_channels_in2add pin equivalences core1_edt_channels_in1 core2_edt_channels_in1add pin equivalences core1_edt_channels_in2 core2_edt_channels_in2

• Physically share top-level pins

Use this method when top-level pins need to be shared between input channels byexplicitly specifying the top-level pins to be same. For example:

add edt block core1set edt pin input 1 edt_channels_in1set edt pin input 2 edt_channels_in2add edt block core2set edt pin input 1 edt_channels_in1set edt pin input 2 edt_channels_in2

During DRC, the blocks that share input channels are reported. As long as the EDT blocks areidentical and the channel sharing is set up properly, TestKompress DRCs should pass.

Use the Report EDT Configurations -All command to display information on the EDT blocksset up to share input channels.

Generating Modular EDT Logic for a Fully IntegratedDesign

Use this procedure to simultaneously generate modular EDT logic for all blocks within a fullyintegrated 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, youmust generate modular EDT logic one block at a time.

The TestKompress files generated by this procedure support the same capabilities as the blockby block modular flow.



August 2009

Requirements

• The integrated design must be complete and fully functional.

• Each block must have dedicated input and output channels.

Procedure

1. Add each EDT block, one at a time, using the Add EDT Block command.

2. Once a EDT block is added, set up the EDT logic for it with a Set EDT command. TheSet EDT command only applies to the current EDT block. TK control signals can beshared among blocks.

3. Once all the design blocks are added and set up, enter ATPG mode. For moreinformation, see the Set System Mode command.

4. Enter a Write EDT Files command. A composite set of TestKompress files is createdincluding an RTL file, a synthesis script, a dofile/testproc file, and a bypassdofile/testproc file. All block-level TestKompress pins are automatically connected tothe top level.

5. Use this composite set of files to synthesize EDT logic and generate test patterns.

Estimating Test Coverage/Pattern Count for EDT BlocksAfter you create EDT logic for a block, you should create test patterns and estimate testcoverage and pattern count before synthesis. See “Estimating Test Coverage and Data Volume”on page 90.

Test coverage reported may be higher than when the EDT block is embedded in the designbecause TestKompress has direct access to the block-level inputs and outputs at this point.

To get a more realistic coverage estimate, you should:

1. Constrain all functional inputs to X. For example:

SETUP> add pin constraint my_func_in cx

Where the functional input my_func_in is constrained to X.

2. Mask all functional outputs. For example:

SETUP> add output masks my_func_out1 my_func_out2

Where the two primary outputs my_func_out1 and my_func_out2 are masked.

Modular TestKompressCreating a Top-level Test Procedure File


NoteConstraining inputs to X and masking the outputs produces very conservative estimatesthat negatively affect compression because all inputs become X sources when the CXconstraints are added to the pins.

NoteBecause final test patterns are generated at the top-level of the design and are affected byall cores, the final test coverage and pattern count may vary.

Creating a Top-level Test Procedure FilePrior to running top-level ATPG, you must integrate all block-level test procedure files into asingle top-level test procedure file as illustrated in Figure 8-2.

Figure 8-2. Creating the Top-level Test Procedure File

When EDT logic is created for each block, a block-level test procedure file is created. See “TestProcedure File” on page 83. In a standard TestKompress flow, this test procedure file is used tocreate final test patterns for the design. However, in a modular TestKompress flow, youmanually combine the relevant content from each block-level test procedure file into a singletop-level test procedure file that is used for top-level pattern generation.

To create the top-level test procedure file, you take the block-level test procedure files andaggregate test-setup, load-unload, shift and capture procedure information into one file. The



August 2009

top-level test procedure file is a superset of the block-level test procedure files and typicallyconsists of clock definitions and force or pulse statements for edt_update and edt_clock duringthe load_unload, shift and capture procedures. Pin names may also need to be changed. Thisprocess is illustrated in the following procedure.

Prerequisites

• All EDT blocks are created and verified.

Procedure

1. Copy and use one of the block-level test procedure files as a template for the top-levelfile. You should use the block-level test procedure file with the most test procedures.

2. Using a text editor, copy and paste test procedures from the other block-level files intothe top-level file.

3. Update the timeplate or timeplates to include all statements present in each block-specific timeplate and customize the top-level timeplate as needed. As you addstatements, update pin names to match the corresponding name changes in the top-levelnetlist. See Figure 8-3.

Figure 8-3. Creating a Top-level Timeplate

4. Update the load_unload procedure to include all statements present in each block-leveltest procedure. As you add statements, update the pin names. See Figure 8-4.

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;

timeplate gen_tp1 =force_pi 0;measure_po 100;pulse clk 200 100;pulse edt_clock 200 100;period 400;

end;

timeplate gen_tp1 =force_pi 0;measure_po 100;pulse core1_clk 200 100;pulse core2_clk 200 100;pulse edt_clock 200 100;pulse ramclk 200 100;period 400;

end;



Figure 8-4. Creating a Top-level Load_unload Procedure

NoteThe number specified in the apply shift statement should be greater than one but isotherwise irrelevant; actual shifts are determined by the actual traced length of the scanchains.

5. Update the shift procedure to include statements present in each block-specific shiftprocedure. As you add statements, make updates to the pin names similar to those in thetop-level timeplate and load_unload procedure. See Figure 8-5.

procedure load_unload =scan_group grp1;timeplate gen_tp1;cycle =

force clk 0;

end;

force edt_bypass 0;force edt_update 1;force edt_clock 0;force scan_en 1;pulse edt_clock;

end;apply shift 26;


force clk 0;

end;

force edt_bypass 0;force edt_update 1;force edt_clock 0;force ramclk 0;

pulse edt_clock;end;apply shift 16;

force scan_en 1;


force core1_clk 0;

end;

force core2_clk 0;force shared_edt_bypass 0;force shared_edt_update 1;

end;apply shift 26;

force edt_clock 0;force ramclk 0;force core1_scan_en 1;force core2_scan_en 1;pulse edt_clock;

Must be greater than one.



August 2009

Figure 8-5. Creating a Top-level Shift Procedure

If the same procedure occurs in multiple block-level test procedure files, you need to include itjust once in the top-level file. But you must include all the pin-specific statements (force, pulse,and so on) from each block-level version.

Block-level Test Procedure Files ExampleThe following example illustrates two test procedure files written when the EDT logic wascreated for the same two sub-blocks used in the netlist and dofile examples. Following theseblock-level examples is the top-level test procedure file created from them. Notice the identicalpin names in the force and pulse statements in each block-level file. To force/pulse the correctpins at the top-level, you need to change the block-level pin names at the top level when youmerge 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 ;

procedure shift =scan_group grp1;timeplate gen_tp1;cycle =

force_sci;

end;

force edt_update 0;measure_sco;pulse clk;pulse edt_clock;

end;


force_sci;

end;

force shared_edt_update 0;measure_sco;pulse core1_clk;

end;

pulse core2_clk;pulse edt_clock;


force_sci;

end;

force edt_update 0;measure_sco;pulse clk;pulse edt_clock;

end;



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;

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_capture_clock ; 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 ; force edt_update 0 ; measure_sco ; pulse clk ; pulse edt_clock ;



August 2009

end;end;

procedure load_unload = 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;

procedure test_setup = timeplate gen_tp1 ; cycle = force edt_clock 0 ; end;end;

Top-level Test Procedure File ExampleThe following example illustrates a top-level test procedure file that aggregates all theprocedures from the preceding block-level files. Notice that, with the exception of all the sharedEDT control pins, pins with the same name from different blocks were given unique names byaddition of a prefix (shown in bold font) indicating the block-level design where they occur. Besure the top-level pin names you use in the top-level test procedure file match the names yougave these pins in the netlist.

// all_cores_edt.testproc//// Manually created from created1_edt.testproc & created2_edt.testproc//set time scale 1.000000 ns ;set strobe_window time 100 ;

timeplate gen_tp1 =force_pi 0 ;measure_po 100 ;pulse core1_clk 200 100 ;pulse core2_clk 200 100 ;pulse edt_clock 200 100 ;pulse ramclk 200 100 ;period 400 ;

end;





end;end;

procedure ram_passthru =timeplate gen_tp1 ;cycle =

force_pi ;pulse_write_clock ;

end ;cycle =

measure_po ;pulse_capture_clock ;

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_capture_clock ;pulse_read_clock ;pulse_write_clock ;

end ;end ;


force_sci ;force shared_edt_update 0 ;measure_sco ;pulse core1_clk ;pulse core2_clk ;pulse edt_clock ;

end;end;


force core1_clk 0 ;force core2_clk 0 ;force shared_edt_bypass 0 ;force shared_edt_update 1 ;


Modular TestKompressCreating the Top-level Netlist

August 2009

force shared_edt_clock 0 ;force ramclk 0 ;force core1_scan_en 1 ;force core2_scan_en 1 ;pulse edt_clock ;

end;apply shift 26;

end;


force edt_clock 0 ;end;

end;

Creating the Top-level NetlistOnce all EDT blocks are created and verified, you must merge them into a single top-levelnetlist for final test pattern generation. Merging the EDT blocks into a single design is theprocess of building a netlist that instantiates all the EDT blocks including all the interconnectsneeded for the functional design.

TK control signals, such as edt_update, edt_clock, edt_bypass, edt_reset, scan_enable andtest_en can be shared between blocks, but all scan channels must have dedicated top-level pins.

This procedure invokes TestKompress in an integration session to make the connectionsrequired to integrate the EDT blocks into the netlist. Alternatively, you can skip this procedureand make these connections manually.

The specified connections are made through the DC script output at the end of the integrationsession.

Limitations

• The integration process only supports two levels of EDT hierarchy as shown inFigure 8-1. If your design contains additional levels of nested hierarchy within any ofthe EDT blocks, you must manually update the dofiles for the nested blocks with thecorrect block-level EDT pins.

• EDT blocks can only be instantiated in a top-level design. The integration session doesnot support the creation of an external wrapper like the one used for the external flow.For more information on the external flow, see “External EDT Logic Flow (ExternalFlow)” on page 33.

• Uncompressed scan chains cannot be added during the integration session. For moreinformation on using uncompressed scan chains, see “Including Uncompressed ScanChains” on page 43.



• EDT mapping must be enabled for the integration session. See “Creating the Top-levelDofile” on page 175.

Prerequisites

• All EDT blocks are created and verified.

• All design blocks that include EDT logic are fully defined; no black boxes can be used.

• A top-level test procedure file is defined. The top-level test procedure for integrationcombines all the block level pre-TestKompress input test procedures (not the oneswritten out during EDT logic creation) that reference the top-level clock and other pinnames. Pre-TestKompress test procedure files are necessary because the EDT-controlpins generated during EDT logic creation do not exist in the netlist yet.

Procedure

The following commands are typically assembled in a dofile and used to drive the sessionautomatically from the command line. For more information, see “Batch Mode” on page 23.

1. Invoke TestKompress on the top-level design netlist. TestKompress invokes in setupmode.

2. Add the top-level scan chains and test procedure file. For example:

SETUP> add scan groups grp1 top.testproc

3. Define top-level pin constraints and clocks. For example:

SETUP> add clocks 0 clk1 clk2

4. Enable EDT mapping. For example:

SETUP> set edt mapping on

EDT mapping enables Testkompress to obtain EDT pin information from theblock-level dofiles.

5. Add each EDT block and specify it’s location and dofile. For example:

SETUP> add edt block B1SETUP> set edt instance -block_location /SETUP> dofile B1_edt.dofileSETUP> set edt instance -block_location /SETUP> add edt block B2SETUP> dofile B2_edt.dofile

Where:

B1and B2 are the names of the EDT blocks, “set edt instance -block_location /”specifies the EDT block location is the top-level of the design, and B1_edt.dofile andB2_edt.dofile are the dofiles for each block.



August 2009

6. Specify the connections necessary to connect the EDT blocks to the top-level pins. Forexample:

SETUP> add edt connections -signal input_channel 1 -to TK_channel_in[0] -block B1SETUP> add edt connections -signal output_channel 1 -to TK_channel_out[0] \

-block B1SETUP> add edt connections -signal input 1 -to TK_channel_in[1] -block B2SETUP> add edt connections -signal output 1 -to TK_channel_out[1] -block B2SETUP> add edt connections -signal clock -to TK_clk -blocks B1 B2SETUP> add edt connections -signal update -to TK_upd -all_blocksSETUP> add edt connections -signal bypass \

-to /tap_i/tap_ctrl_i/edt_bypass_inst -all_blocks

7. Specify any non-EDT connections needed. For example, connect a tap controller to thetest enable on both design blocks as follows:

SETUP> add edt connections -from tap_i/tap_ctrl_i/test_en \-to /B1_inst/test_en /B2_inst/test_en

8. Change to ATPG mode and run DRC. For example:


9. Report and verify that the EDT connections are setup as specified. For example:

SETUP> report edt connections

10. Write out the DC integration script. For example:

SETUP> write edt files integrate -replace

Modular TestKompressCreating the Top-level Dofile


From the integration session, the Write EDT Files command outputs a DC script used tosynthesize the top-level EDT logic and make the other connections as specified with theAdd EDT Connections command. A mux description in RTL is also produced whennecessary.

Related Topics

Creating the Top-level DofileThis procedure creates a top-level dofile that combines the block-level dofiles and specifiesclock pins and pin constraints required for top-level test pattern generation.

Prerequisites

• Top-level test procedure file. For more information, see “Creating a Top-level TestProcedure File” on page 165.

Procedure

1. Open a text editor to create a dofile.

2. At the beginning of the dofile, reference the top-level test-procedure file to use forgenerating test patterns. For example:

add scan groups grp1 ./all_top_level_edt.testproc

For more information, see the Add Scan Groups command and “Creating a Top-levelTest Procedure File” on page 165.

3. Define the top-level clocks and pin constraints common to all blocks. For example:

add clock 0 edt_clockadd pin constraints edt_clock C0

4. Enable TestKompress to get the setup information for each block from the block-leveldofile created when the EDT logic was created. For example:

set edt mapping on -verbose on

The setup information is automatically obtained from dofiles specified for each blockand mapped to the top-level pins. If EDT mapping is not enabled, you must manuallyenter and map the set information from each dofile in the top-level dofile.

Creating a Top-level Test Procedure File

Delete EDT Connections



August 2009

5. Specify pin constraints and clock signals for the first EDT block (core1) using pin namesfrom the top-level netlist. For example:

add clocks 0 clk_core1add clocks 0 ramclk_core1add write controls 0 ramclk_core1add read controls 0 ramclk_core1

6. Instantiate the first EDT block (core1) into the dofile. For example:

add edt block Core1

Precede each block-specific set of commands with an Add EDT Block command to setthe context. This command also defines an arbitrary identifier of your choice, referred toas the block tag, for block being defined. The block tag, which provides a way to refer tothis block later in the session, should be unique.

7. Specify the path to the dofile Testkompress created for core1. For example:

dofile ../../Core1/generated/created_core1_edt.dofile

8. Repeat steps 5, 6, and 7 for each EDT block, including the top-level glue logic block. Toinstantiate the same EDT block multiple times at the top-level, see “Instantiating a EDTBlock Multiple Times” on page 176.

9. After all EDT blocks are defined, run DRC and top-level pattern creation. For example:

set system mode atpgreport drc rulescreate test patterns

Related Topics

Instantiating a EDT Block Multiple TimesTo instantiate a EDT block multiple times in the top-level dofile, you must specify a uniquelocation within the top-level design for each instance using the Set EDT Instances command.

The Set EDT Instances command specifies the name of the Verilog module/VHDL entity in thetop-level netlist where the EDT logic is located.

For example:

add edt block a1set edt instances -block_location /piccpu_top_level_i/piccpu_core1_idofile created2_edt.dofile

add edt block a2set edt instances -block_location /piccpu_top_level_i/piccpu_core2_i

Instantiating a EDT Block Multiple TimesTop-level Dofile Example



dofile created2_edt.dofile

add edt block a3set edt instances -block_location /piccpu_top_level_i/piccpu_core3_idofile created2_edt.dofile

Block a1, block a2, and block a3 are instantiations of the same EDT block and use the samedofile but are located in separate modules of the design netlist.

Top-level Dofile ExampleThe following dofile specifies setups for creating top-level test patterns for a modular designwith three unique EDT blocks.

// all_cores_edt.do//// Dofile to create top-level patterns for design with 3 unique EDT blocksadd scan groups grp1 all_cores_edt.testproc

// Define top-level clocks and pin constraints for all blocks.add clocks 0 core1_clkadd write controls 0 core1_ramclkadd read controls 0 core1_ramclkadd clocks 0 core2_clkadd clocks 1 core3_clkadd clocks 0 shared_edt_clockadd pin constraint shared_edt_clock C0

set edt mapping on

// DEFINE BLOCK 1add edt block a1 //Name this block “a1” (block’s tag for later cmds)dofile created1_edt.dofile

// DEFINE BLOCK 2add edt block a2 //Name this block “a2”dofile created2_edt.dofile

// DEFINE BLOCK 3add edt block a3 //Name this block “a3”dofile created3_edt.dofile

// Report what’s been set.report scan chains -all_blocksreport edt blocksreport edt configuration -all_blocks

// Once all EDT blocks are defined, perform DRC and verify there are// no DRC violations.set system mode atpgreport drc rules

// Create patterns that use all blocks simultaneously and generate// patterns that target faults in the entire design.create patterns


Modular TestKompressGenerating Top-level Test Patterns

August 2009

...

Generating Top-level Test PatternsNoteTo generate top-level patterns, you must have a top-level design netlist, dofile and testprocedure file, prepared as described earlier in this chapter.

Generating test patterns for the top-level of a modular design is similar to creating test patternsin the standard flow except that you set one block up at a time with the following commands:

• Set Current Block — Applies EDT-specific commands and the Add Scan Chainscommand to a particular EDT block. Restricting commands in this way enables you tore-specify the characteristics of an individual block without affecting other parts of thedesign.

• Report EDT Blocks — Reports on EDT blocks currently defined in TestKompressmemory.

• Delete EDT BLocks — Deletes EDT blocks from TestKompress memory.

A few reporting commands also operate on the current EDT block by default, but provide an-All_blocks switch that enables you to report on the entire design. All other commands (SetSystem Mode, Create Patterns and Report Statistics for example) operate only on the entiredesign.

Modular TestKompress Flow ExampleFigure 8-6 shows an example of the modular TestKompress commands used to integrate EDTblocks and generate test patterns. In this example, TestKompress control signals are shared atthe top level; each EDT block is created with the EDT logic and the scan-inserted core inside ofa wrapper.

Modular TestKompressModular TestKompress Flow Example


Figure 8-6. Netlist with Two Cores Sharing TestKompress Control Signals

1. Invoke TestKompress and define scan chains, clocks and EDT logic for the first block.For example:

// Define scan chains, clocks, and EDT hardware.add scan groups grp1 group1.testprocadd scan chains chain1 grp1 edt_si1 edt_so1add scan chains chain2 grp1 edt_si2 edt_so2...add clocks clk1 0set edt -channels 6set system mode atpg

2. Create EDT logic with unique module names based on the core module name for thefirst block. For example:

// Create EDT hardware with unique module names.write edt files created1 -replace

edt_block1

core1_edt_i

core1_i

Scan chain outs

Scan chain out

FunctionalOutput

Pins

Scan chain in

Functional


Channel outsChannel ins

Scan chain ins

InputPins

}

}

}

}

edt_top_all_cores

edt_block2

core2_edt_i

core2_i

Scan chain outs

Scan chain out

FunctionalOutput

Pins

Scan chain in

Functional



Scan chain ins

InputPins

}

}}

}

shared_edt_clockshared_edt_updateshared_edt_bypass

Channel ins Channel outs


FunctionalOutputPins

FunctionalOutputPins

FunctionalInputPins

FunctionalInputPins


Modular TestKompressModular TestKompress Flow Example

August 2009

3. Repeat steps 1 and 2 for the second block.

4. Using the DC script output during the EDT logic creation, synthesize the EDT logic foreach block.

5. Verify that the EDT logic is instantiated properly by generating and simulating testpatterns for each of the resultant gate-level netlists. This is done using the test benchcreated during test pattern generation and a timing-based simulator.

6. Verify that the block-level scan chains are balanced.

7. Create the top-level netlist, dofile, and test procedure files. The following exampleshows the top-level dofile. For more information, see “Creating the Top-level Dofile” onpage 175.

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

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


// Verify the EDT configuration.report edt configuration -all_blocks

// Generate patterns.create patterns

// Create reports.report statistics

Modular TestKompressModular Flow Command Reference


report scan volume

save patterns...exit

Modular Flow Command ReferenceTable 8-2 describes commands used for the modular design flow.

Table 8-2. Modular TestKompress Command Summary

Command Description

Add EDT Blocks Creates a name identifier for an EDT block instantiated in anetlist.

Add EDT Connections Specifies EDT logic connections during the top-level integrationstep of the modular design flow.

Delete EDT Blocks Removes the specified EDT block(s) from the internal database.

Delete EDT Connections Deletes connections previously specified with the Add EDTConnections command

Report EDT Blocks Displays current user-defined EDT block names.

Report EDT Configurations Displays the configuration of the EDT logic.

Report EDT Connections Reports pin connections made during the top-level integrationsession of the modular flow.

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 aparticular EDT block, not globally.

Set EDT Instances Specifies the instance name or instance pathname of the designblock that contains the TK hardware; for use by DRC.

Set EDT Mapping Enables the automatic mapping necessary for block-level dofilesto be reused for top-level pattern creation.

Write EDT Files Writes all the TK files required to implement the EDTtechnology in a design.


Modular TestKompressModular Flow Command Reference

August 2009


Chapter 9Integrating TestKompress at the RTL Stage

You can create EDT logic during the RTL design phase, rather than waiting for the completesynthesized gate-level design netlist. Creating the EDT logic early allows you to consider theEDT logic earlier in the floor-planning, placement, and routing phases.

To create EDT logic during the RTL stage, you must know the following parameters for yourdesign:


• Number of internal scan chains

• Clocking of the first and last scan cell of each chainThis scan chain clocking information is not necessary if you set up the EDT clock topulse before the scan chain shift clocks. For more information, see “Setting EDT Clockto Pulse Before Scan Shift Clocks” on page 58.

• Longest scan chain length range (an estimate of the minimum number of scan cells andmaximum number of scan cells the tool can expect in the longest scan chain)

You should also have knowledge about the design interface if you are creating/inserting theEDT logic external to the design core.

About the RTL Stage FlowFigure 9-1 shows the TestKompress RTL stage flow. The utility, create_skeleton_design isused to create a skeleton design. This utility writes out a gate level skeleton Verilog design andseveral related files required to create EDT logic.

To use the create_skeleton_design utility, you must create a Skeleton Design Input File. TheSkeleton Design Input File contains the requisite number of scan chains with the first and lastcell of each of these chains driven by the appropriate clocks. For more information, see“Skeleton Design Input File” on page 186.

If you are creating/inserting the EDT logic external to the design core, you must also create aSkeleton Design Interface File. For more information, see “Skeleton Design Interface File” onpage 189.


Integrating TestKompress at the RTL StageAbout the RTL Stage Flow

August 2009

Figure 9-1. TestKompress RTL Stage Flow

Use the following steps to create EDT logic for an RTL design:

1. Create a Skeleton Design Input File. For more information, see “Skeleton Design InputFile” on page 186.

2. If you are inserting the EDT logic external to the core design (External EDT Logic Flow(External Flow)), create a Design Interface File to provide the interface description ofthe core design in Verilog format. For more information, see “Skeleton Design InterfaceFile” on page 189.

3. Run the create_skeleton_design utility. For example:

• Internal Flow:

create_skeleton_design -o output_file_prefix \-i skeleton_design_input_file

• External Flow:

create_skeleton_design -o output_file_prefix \-i skeleton_design_input_file -design_interface file_name

The utility writes out the following four files:

Prepare Input& Interface Files

SkeletonATPG Library

Skeleton

Input FileDesign

Design

(if ext. flow)Interface File

Skeleton

NetlistGate-level Dofile

Create SkeletonDesign Input File

(page 186)

Create SkeletonDesign Interface File

(page 189)

Runcreate_skeleton_design

(page 189)

Run TestKompressLogic Creation Phase

(page 190)

Skeleton TestProc.File

Skel.

Integrating TestKompress at the RTL StageSkeleton Design Input and Interface Files


<output_file_prefix>.v — Skeleton design netlist

<output_file_prefix>.dofile — Dofile

<output_file_prefix>.testproc — Test procedure file

<output_file_prefix>.atpglib — ATPG library

For a complete example showing create_skeleton_design input files and the resultantoutput files, see the “Skeleton Flow Example” on page 192.

4. Invoke TestKompress on the skeleton design netlist and the ATPG library.

5. Provide TestKompress setup commands.

• Run the dofile and test procedure file to set up the scan chains for the TestKompresslogic.

• Issue the Set EDT command to specify the number of scan channels. You should usethe -Longest_chain_range switch with this command to specify an estimated lengthrange (min_number_cells and max_number_cells) for the longest scan chain in thedesign. For additional information, refer to “Understanding the Longest Scan ChainLength Estimate” on page 190.

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

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



August 2009

Figure 9-2. Create_skeleton_design Inputs and Outputs

Skeleton Design Input FileCreate the skeleton design input file using the rules described in the next section.

Input File FormatExample 9-1 shows the format of the skeleton design input file. Required keywords arehighlighted in bold. This file contains distinct sections that are described after the example.Example 9-2 on page 189 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 designsscan_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 stateend_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

create_skeleton_design

Skel. Gate-

(Verilog)level netlist

ProcedureTest

FileDofile ATPG

LibrarySimulation

Library

Verilog

Skeleton

Input FileDesign

Skel. Design

(ext flow)Interface File



<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

NoteThis section is required when you use the -Design_interface switch withcreate_skeleton_design to enable TestKompress to create a correct instantiation of thecore in the top level EDT wrapper (External Flow). If the scan pins specified in thissection are not present in the design interface, the utility automatically adds them to theskeleton design. You can omit this section if you are not using the -Design_interfaceswitch.

In this section, specify the scan chain pin name prefix and the type, bused or indexed, using thekeywords, “scan_chain_input” and “scan_chain_output”. The bused option will result in scanchain pins being declared as vectors, i.e., <prefix>[Max-1:0]. The indexed option will result inscan chain pins being declared as scalars, numbered consecutively beginning with the specifiedstarting 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 adda 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 keywordto specify the name of any one LSSD system clock. If you do not specify a name, the tool willuse the default name, “lssd_system_clock”.

Clock Definition Section

In this section, specify clock names and their corresponding off states. The utility uses these offstates to create a correct skeleton dofile and skeleton test procedure file. (See the Add Clockscommand 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 scanchains, length of the chains, and clocking of first and last scan cell.

NoteYou can omit the clocking of the first and last cell in each scan chain if the EDT logicclock is pulsed before the scan chain shift clock. For more information, see “Setting EDTClock to Pulse Before Scan Shift Clocks” on page 58.



August 2009

To simplify and shorten this section, you can list, on one line, a range of chains that have thesame 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 clockinformation of the first and last scan cell. The length of the scan chains can be any value not lessthan 2, but typically 2 suffices for the purpose of creating appropriate EDT logic. In the createdskeleton design, all chains in this range will be the same length and contain a first and last scancell with the same clocking.

The edge specification must be one of the following:

• LE for a scan cell whose output changes on the leading edge of the specified clock

• TE for a scan cell whose output changes on the trailing edge of the specified clock

• LA for an LSSD scan cell

When you specify the clock edge of the last scan cell, it is critical to include the lockup latchtiming as well. For example, if a leading edge (LE) triggered scan memory element is followedby a lockup latch, the edge specification of the scan cell must be TE (not LE) since the cellcontains a scan memory element followed by a lockup latch and the scan cell output changes onthe trailing edge (TE) of the clock. Specifying incorrect edges will result in improper lockupcells being inserted by TestKompress and you may need to regenerate the EDT logic later.

NoteWhen the scan chain specification indicates the first and last scan cell have master/slaveor master/copy clocking (for example, an LE first scan cell and a TE last scan cell), thecreate_skeleton_design utility will increase that chain’s length by one cell in theskeleton netlist it writes out. This is done to satisfy a requirement of TestKompresslockup cell analysis and will not alter the EDT logic; the length of the scan chains seen byTestKompress after it reads in the skeleton netlist will be as specified in the skeletondesign input file.

Comment Lines

You can place comments in the file by beginning them with a double slash (//). Everything aftera double slash on a line is treated as a comment and ignored.

Input File ExampleThe following example utilizes bused scan chain input and output pins. It also defines twoclocks, clk1 and clk2, with off-states 0 and 1, respectively. A total of eight scan chains arespecified. Chains 1 through 4 are of length 2, with the first cell being LE clk1 triggered and thelast cell being TE clk1 triggered. Chains 5 and 6 are of length 3, with the first cell being LE clk2triggered and the last cell being TE clk2 triggered. Chains 7 and 8 are also of length 3, with thefirst and last cells being of LSSD type, clocked by master and slave clocks, mclk and sclk,respectively.

Integrating TestKompress at the RTL Stagecreate_skeleton_design Usage


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 busedscan_chain_output edt_so busedbegin_clocks clk1 0 clk2 1 mclk 0 sclk 0end_clocksbegin_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 sclkend_chains

Skeleton Design Interface FileYou should create a skeleton design interface file if you are creating EDT logic that is insertedexternal to the design core. It should contain only the interface description of the core design inVerilog 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 193.

Tip: The interface file ensures the files written out by the create_skeleton_design utilitycontains 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 Usagecreate_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 briefdescription of each.

• -O output_file_prefix


Integrating TestKompress at the RTL StageCreating EDT Logic for a Skeleton Design

August 2009

An optional switch and string pair that specifies a prefix for the utility to use whenconstructing 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.

• -Simulation_library

An optional switch that specifies to write out a Verilog simulation library that matchesthe <output_file_prefix>.atpglib ATPG library.

• -Design_interface file_name

An optional switch and string pair that specifies the pathname of a file containing aVerilog description of the design interface. This file is recommended if you will beusing the External Flow. It enables TestKompress 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 inputfile.

Creating EDT Logic for a Skeleton DesignAfter invoking TestKompress on the skeleton design, you must set up the following parameterswith the Set EDT command:


• Estimate of the longest scan chain length (optional). This value allows flexibility whenconfiguring scan chains. For more information, see “Understanding the Longest ScanChain Length Estimate” on page 190.

For example:

set edt -channels 2set edt -longest_chain_range 75 125

For more information on setting up and creating the EDT logic, see “Creating EDT Logic Files”on page 71.

Understanding the Longest Scan Chain Length EstimateThe mask register in the compactor and the internal core scan chains are loaded simultaneouslyby the decompressor during scan shifting. If the mask register’s length exceeds the specified

Integrating TestKompress at the RTL StageIntegrating the EDT Logic into the Design


min_number_cells, the tool uses the min_number_cells to configure the mask register intomultiple scan chains. This ensures the mask register is not the longest chain in the design.

NoteWhile you may specify a min_number_cells as low as 2, it is advisable not to specify anartificially low number. Specifying an extremely low min_number_cells will cause themask register to be partitioned into an unnecessarily large number of relatively short scanchains. In rare cases this can result in incompressible patterns (due to a large number ofspecified 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 phaseshifter (in the decompressor) to internal scan chains are separated by at least as many cycles asthe max_number_cells. This reduces linear dependencies among the bit streams supplied to theinternal scan chains.

Integrating the EDT Logic into the DesignAfter 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 filewhen it generated the skeleton design, you can continue with the standard TestKompressexternal flow (optionally insert I/O pads and boundary scan, then synthesize the I/Opads, boundary scan, and EDT logic).

If you did not use an interface file, you will need to manually provide the interface andall related interconnects needed for the functional design before synthesizing the EDTlogic.

• For EDT logic created within the design core (Internal Flow):

Integrating the EDT logic into the design is a manual process you perform using yourown tools and infrastructure to stitch together different blocks of the design to create atop level design.

NoteThe Design Compiler synthesis script that TestKompress writes out does not containinformation for connecting the EDT logic to design I/O pads, as the tool did not haveaccess to the complete netlist when it created the EDT logic.

Knowing When to Regenerate the EDT LogicBy the time the final gate-level netlist is available, there may have been some changes to theparameters that affect the EDT logic. Following are scenarios that could require regeneration ofthe EDT logic:


Integrating TestKompress at the RTL StageSkeleton Flow Example

August 2009

• 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 logicactually changes or not depends on whether the clock edge that triggers the first or lastscan cell has changed. In addition, it depends on whether lockup cells were inserted forbypass mode scan chains. Without a thorough understanding and knowledge of thelockup 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 theclocking of the first or last scan cell changes. You can determine if the logic has changedby 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_cellsspecified with the Set Edt -Longest_chain_range switch.

Whether the EDT logic needs to be regenerated or not depends on whether the maskregister length is more than the length of the longest scan chain (as determined by scanchain tracing in the netlist). The safest approach is to regenerate the EDT logic andcompare 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 themax_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 phaseshifter needs to be redesigned or not. The phase shifter is designed to guarantee aminimum separation of scan chain bit streams by at least as much as the specifiedmax_number_cells. The safest approach is to regenerate the EDT logic and compare theRTL from the earlier run to determine if it has changed.

Skeleton Flow ExampleThis section shows example skeleton design input and interface files and the output files thecreate_skeleton_design utility generated from them.

Input File

NoteIf you will be creating the EDT logic within the core design (Internal Flow), this file isthe only input the utility needs.

The following example skeleton design input file, my_skel_des.in, utilizes indexed scan chaininput and output pins. The file defines two clocks, NX1 and NX2, with off-states 0, andspecifies a total of 16 scan chains, most of which are 31 scan cells long. Notice the clocking ofthe 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 tocreate the EDT logic).

scan_chain_input scan_in indexed 1scan_chain_output scan_out indexed 1

begin_clocksNX1 0NX2 0end_clocks

begin_chains1 1 31 TE NX1 TE NX12 2 30 TE NX1 TE NX13 3 30 TE NX1 TE NX14 4 31 TE NX1 TE NX15 5 31 TE NX1 TE NX16 6 32 LE NX2 LE NX27 7 31 LE NX2 LE NX28 8 31 LE NX2 LE NX29 9 31 LE NX2 LE NX210 10 31 LE NX2 LE NX211 11 31 LE NX2 LE NX212 12 31 LE NX2 LE NX213 13 31 LE NX2 LE NX214 14 31 LE NX2 LE NX215 15 31 LE NX2 LE NX216 16 31 LE NX2 LE NX2

end_chains

Interface File

The following shows an example interface file nemo6_blackbox.v for the design described inthe preceding input file. Use of an interface file is recommended if you intend to create the EDTlogic 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 ,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 ;



August 2009

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

OutputsThis section shows examples of the four ASCII files written out by the create_skeleton_designutility 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.vbb1.dofilebb1.testprocbb1.atpglib

Skeleton Design

Following is the gate level skeleton netlist that resulted from the example input and interfacefiles of the preceding section. For brevity, lines are not shown when content is readily apparentfrom the structure of the netlist. Parts attributable to the interface file are highlighted in bold; theutility would not have included them if there had not been an interface file.

NoteThe utility obtains the module name from the interface file, if available. If you do not usean interface file, the utility names the module “skeleton_design_top”.

module nemo6 (NMOE, NMWE, DLM, ALE, NPSEN, NALEN, NFWE, NFOE, NSFRWE,NSFROE, IDLE, XOFF, OA, OB, OC, OD, AE, BE, CE, DE, FA, FO, M, NX1, NX2,RST, NEA, NESFR, ALEI, PSEI, AI, BI, CI, DI, FI, MD, scan_in1,scan_in2, ..., scan_in16, scan_out1, scan_out2, ..., scan_out16, scan_en);

output NMOE;



output NMWE;output DLM;output ALE;output NPSEN;output NALEN;output NFWE;output NFOE;output NSFRWE;output NSFROE;output IDLE;output XOFF;output [7:0] OA;output [7:0] OB;output [7:0] OC;output [7:0] OD;output [7:0] AE;output [7:0] BE;output [7:0] CE;output [7:0] DE;output [7:0] FA;output [7:0] FO;output [15:0] M;input NX1;input NX2;input RST;input NEA;input NESFR;input ALEI;input PSEI;input [7:0] AI;input [7:0] BI;input [7:0] CI;input [7:0] DI;input [7:0] FI;input [7:0] MD;

input scan_in1;input scan_in2;...input scan_in16;output scan_out1;output scan_out2;...output scan_out16;input scan_en;

wire NX1_inv;

wire chain1_cell1_out; wire chain1_cell2_out;

... wire chain1_cell31_out; wire chain2_cell1_out; wire chain2_cell2_out;

... wire chain2_cell30_out;

.

.



August 2009

.wire chain16_cell1_out;

wire chain16_cell2_out;...wire chain16_cell31_out;

inv01 NX1_inv_inst ( .Y(NX1_inv), .A(NX1));

muxd_cell chain1_cell0 ( .Q(scan_out1), .SI(chain1_cell1_out),.D(1’b0), .CLK(NX1_inv), .SE(scan_en) );

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

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

muxd_cell chain2_cell0 ( .Q(scan_out2), .SI(chain2_cell1_out),.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(NX1_inv), .SE(scan_en) );

...muxd_cell chain2_cell29 ( .Q(chain2_cell29_out), .SI(scan_in2),

.D(1’b0), .CLK(NX1_inv), .SE(scan_en) );...

muxd_cell chain16_cell0 ( .Q(scan_out16), .SI(chain16_cell1_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) );

...muxd_cell chain16_cell30 ( .Q(chain16_cell30_out), .SI(scan_in16),

.D(1’b0), .CLK(NX2), .SE(scan_en) );

endmodule

Skeleton Design Dofile

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

add scan groups grp1 bb1.testprocadd scan chains chain1 grp1 scan_in1 scan_out1add scan chains chain2 grp1 scan_in2 scan_out2add scan chains chain3 grp1 scan_in3 scan_out3add scan chains chain4 grp1 scan_in4 scan_out4add scan chains chain5 grp1 scan_in5 scan_out5add scan chains chain6 grp1 scan_in6 scan_out6add scan chains chain7 grp1 scan_in7 scan_out7add scan chains chain8 grp1 scan_in8 scan_out8add scan chains chain9 grp1 scan_in9 scan_out9add scan chains chain10 grp1 scan_in10 scan_out10add scan chains chain11 grp1 scan_in11 scan_out11add scan chains chain12 grp1 scan_in12 scan_out12



add scan chains chain13 grp1 scan_in13 scan_out13add scan chains chain14 grp1 scan_in14 scan_out14add scan chains chain15 grp1 scan_in15 scan_out15add scan chains chain16 grp1 scan_in16 scan_out16add clocks 0 NX1add clocks 0 NX2

Skeleton Design Test Procedure File

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

set time scale 1.000000 ns ; 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;

procedure load_unload = 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 skeletondesign. You must use this library when you run TestKompress on the skeleton design.

model inv01(A, Y) (input (A) ()output(Y) (primitive = _inv(A, Y); )

)

// muxd_scan_cell is the same as sff in adk library.



August 2009

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

)

NoteYou can get the utility to write out a Verilog simulation library that matches the ATPGlibrary by including the optional -Simulation_library switch in the shell command.


Appendix AGetting Help

There are several ways to get help when setting up and using DFT software tools. Depending onyour need, help is available from documentation, online command help, and Mentor GraphicsSupport.

DocumentationA comprehensive set of reference manuals, user guides, and release notes is available in twoformats:

• 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 DFTDocumentation” chapter in the Managing Mentor Graphics DFT Software manual.

Online Command HelpOnline command usage information is available from the command line in all DFT tools. Youcan use the Help command to display a list of available commands, the syntax usage, or theentire reference page for a command.

Mentor Graphics SupportMentor Graphics software support includes software enhancements, access to comprehensiveonline services with SupportNet, and the optional On-Site Mentoring service. For details, see:

http://supportnet.mentor.com/about/

If you have questions about a software release, you can log in to SupportNet and searchthousands of technical solutions, view documentation, or open a Service Request online at:



http://supportnet.mentor.com/about/



Getting HelpMentor Graphics Support

August 2009

If your site is under current support and you do not have a SupportNet login, you can register forSupportNet 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

http://supportnet.mentor.com/user/register.cfm

http://supportnet.mentor.com/contacts/supportcenters/index.cfm


Appendix BEDT Logic Specifications

EDT Logic with Basic Compactor and Bypass Module

EDT Logic with Xpress Compactor and Bypass Module

.

Core

edt_clock

edt_channels_in[...]

scan_en .

edt_update .

Compactor

edt_channels_out[...]

NOTE: Functional pins not shown

Decompressor

edt_mask

Bypass Module

.

Core

edt_clock


scan_en

edt_update

Compactor

edt_channels_out[...]

Decompressor

edt_mask

Mask shift register

Controller

NOTE: Functional pins not shown

Bypass Module


EDT Logic Specifications

August 2009

Decompressor Module with Basic CompactorThe following illustration shows details for a decompressor used with a basic compactor, eightscan chains, and two scan channels.

Decompressor Module with Xpress CompactorThe following illustration shows details for a decompressor used with an Xpress compactor,eight scan chains, and two scan channels.

D

Clk

Q

Decompressor

LFSM

edt_clock

Phase

Shifter

D

Clk

Q

.

.

D

Clk

Q

D

Clk

Q

(scan chain masking data)

edt_channels_in1

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

.

.

.

.

.

D

Clk

Q

D

Clk

Q

.

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

.

.

.

.

.

edt_update

# scan channels < # of lockups < # scan chains# depends on scan chain arrangement &

0 < # lockups < # scan chains(lockups are always inserted here)

clocking of lockups ahead of Phase Shifter

edt_channels_in2

edt_mask

Connnected to scan chaininputs in EDT mode

D

Clk

Q

Decompressor

LFSM

edt_clock

Phase

Shifter

D

Clk

Q

.

.

D

Clk

Q

D

Clk

Q

edt_channels_in1

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

.

.

.

.

.

D

Clk

Q

D

Clk

Q

.

.

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

.

.

.

.

.

edt_update

# scan channels < # of lockups < # scan chains# depends on scan chain arrangement &

0 < # lockups < # scan chains

(lockups are always inserted here)clocking of lockups ahead of phase shifter

Connected to scan chaininputs in EDT modeedt_channels_in2

Mask shift registers

Controller



Input Bypass Logic

Compactor Module

D

Clk

Q

Core

edt_bypass

Chain 1

Chain 2

Chain 3

Chain 4

Chain 5

Chain 6

Chain 7

Chain 8

D

Clk

Q D

Clk

Q

system_clk1system_clk2

Decompressor

.

.

.

.

.

.

.

.

.

.

.

Bypass

Compactor

Lockup cells (inserted per Bypass Lockup Table 7-3)

10

10

10

10

10

10

10

10

0=EDT mode1=Bypass mode (concatenate)

SourceDestination

.

.

.

edt_channels_in1 & 2 Output bypass

.

.

Input

Pipe

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

LC Bank A

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

LC Bank B

line

CoreChain 1

Chain 2

Chain 3

Chain 4

Chain 5

Chain 6

Chain 7

Chain 8

Compactor

Pipe

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

D

Clk

Q

LC Bank B

line

CoreChain 1

Chain 2

Chain 3

Chain 4

Chain 5

Chain 6

Chain 7

Chain 8

(complex case)

Output

Bypass

Maskin

Logic

g

edt_channels_out1

edt_channels_out2



August 2009

Output Bypass Logic

CompactorCoreChain 1

Chain 2

Chain 3

Chain 4

Chain 5

Chain 6

Chain 7

Chain 8

edt_channels_out1

edt_bypass

Output Bypass

Scan chain 4 output

Scan chain 8 output

Func. output from core

Func. output from core

Scan channel 1

Scan channel 2

scan_en(active high)

1

1

1

10

00

0

only when a channel output isshared with a functional output

only when bypass logicis included

edt_channels_out2

(simple case)

Output

Bypass

edt_channels_out1

edt_channels_out2

Maskin

Logic

g



Basic Compactor Masking Logic

CompactorCoreChain 1

Chain 2

Chain 3

Chain 4

Chain 5

Chain 6

Chain 7

Chain 8

edt_channels_out1

Decoder

Mask Hold Register

Mask Shift Register

edt_update

edt_mask

edt_clock.

2

Chain

Compactor

Maskinggates

edt_channels_out2

(simple case)

Compactor

Compactor

Compactor

3

4

5

6

7

8

1

Outputs

Maskin

Logic

g



August 2009

Xpress Compactor Controller Masking Logic

CompactorCore

Chain 1

Chain 2

Chain 3

Chain 4

Chain 5

Chain 6

Chain 7

Chain 8

edt_channels_out1

Masking

AND gates

edt_channels_out2

Mask Hold Register

Mask Shift Register

edt_update

edt_mask

edt_clock

One-Hot DecoderXOR Decoder

Mux Controller




Dual Compression Configuration Input LogicThe following illustration shows input logic details when both a 2-channel and a 16-channelcompression configuration are defined. Note that the first 2 channels of the 16-channelconfiguration are always used for the 2-channel configuration.

Red highlights the path for channel 1 when the 2-channel configuration is active. Bluehighlights the path for channel 2 when the 2-channel input configuration is active.



August 2009

Dual Compression Configuration Output LogicThe following illustration shows output logic details when both a 2-channel and a 4-channelcompression configuration are defined. Note that the first 2 channels of the 4-channelconfiguration are always used for the 2-channel configuration.


Appendix CTroubleshooting

This appendix is divided into three parts. The first part, “Debugging Simulation Mismatches,”lists some TestKompress-specific aspects of debugging simulation mismatches that you mayalready be familiar with from past ATPG experience. The second part, “Resolving DRCIssues,” contains some explanation (and examples where applicable) of causes of EDT-specificdesign rule violations and possible solutions. The “Miscellaneous” section covers a few topicsthat are unrelated to simulation mismatches or DRC.

Debugging Simulation MismatchesThis section provides a suggested flow for debugging simulation mismatches in a design thatuses EDT. You are assumed to be familiar with the information provided in the “DebuggingSimulation Mismatches in FastScan” section of the Scan and ATPG Process Guide, so thatinformation is not repeated here. Your first step with EDT should be to determine if the sourceof the mismatch is the EDT logic or the core design. Figure C-1 shows a suggested flow to helpyou begin this process.


TroubleshootingDebugging Simulation Mismatches

August 2009

Figure C-1. Flow for Debugging Simulation Mismatches

If the core design is the source of the mismatch, then you can use traditional ATPGtroubleshooting methods in FastScan to pinpoint the problem. This entails saving bypasspatterns from TestKompress, which you then process and simulate in FastScan with the designconfigured 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.

Start

N

N

Use TestKompress todebug.

Debug with FastScanusing EDT bypasspatterns. Problem is

Any K19thru K22 DRC

violations?

Debug K19 thru K22DRC violations.

N

Focus on Interfacelogic between EDT

or

Y

Parallel patternsFail?

EDT

EDTSerial ChainTest Fails?

Test Fails?Serial Chain

Bypass

Contactcustomer support.

logic and scan cells.

likely in capture.

Debug chain problemswith FastScan.

N

Y

Y

Y

TroubleshootingResolving DRC Issues


Resolving DRC Issues“Design Rule Checking” in the Design-For-Test Common Resources Manual provides fulldescriptions of the EDT-specific “K” rules. This section supplements that information withsome suggestions to help you reduce the occurrence of certain DRC violations.

K19 through K22 DRC ViolationsK19 through K22 are simulation-based DRCs. They verify the decompressor and compactorthrough zero-delay serial simulation and analyze mismatches to try to determine the source ofeach mismatch. As a troubleshooting aid, these DRCs transcript detailed messages listing thegates where the tool’s analysis determined each mismatch originated, and specific simulationresults for these gates.

TestKompress can provide the most debugging information if you have preserved the EDTlogic hierarchy, including pin pathnames and instance names, during synthesis. When this is notthe case and either rule check fails, the tool transcripts a message that begins with the followingreminder (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 cannotresolve, 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 findexpected EDT pins on one or more of these instances, the specifics would tell you about the pinsas 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, butcannot resolve a pin name within the EDT logic hierarchy, it is typically because the name waschanged during synthesis of the EDT RTL. To help prevent interruptions of the pattern creationflow to fix a pin naming issue, you are urged to preserve during synthesis, the pin names



August 2009

TestKompress created in the EDT logic hierarchy. For additional information about thesynthesis step, refer to “About Synthesizing EDT Logic” on page 96.

Debugging Best PracticesFor most common K19 and K22 debug tasks, you can report gate simulation values with the SetGate Report Drc_pattern command.

Typical debug tasks include checking for correct values on:

• EDT control signals (edt_clock, edt_update, edt_bypass, edt_reset)

• Sensitized paths from:

o Input channel pins to the decompressor and from the decompressor to the scanchains during shift. (K19)

o Scan chains to the compactor and from the compactor to the output channel pinsduring shift. (K22)

When you use the Drc_pattern option the gate simulation data for different procedures in thetest procedure file display. For more information on the use of Drc_pattern reporting, refer to“Debugging State Stability” in the Scan and ATPG Process Guide.

In rare cases, you may need to see the distinct simulation values applied in every shift cycle. Forthese special cases, you can force the tool to simulate every event specified in the test procedurefile by issuing the Set Gate Report command with the K19 or K22 argument while in Setupmode.

Tip: Use Set Gate Report with the K19 or K22 argument only when necessary. Becausethe tool has to log simulation data for all simulated setup and shift cycles, Set Gate ReportK19/K22 reporting can slow EDT DRC run time and increase memory usage comparedto Set Gate Report Drc_pattern reporting.

The following two subsections provide detailed discussion of the K19 and K22 DRCs, withdebugging examples utilizing the Drc_pattern, K19 and K22 options to the Set Gate Reportcommand.

“Understanding K19 Rule Violations” on page 212“Understanding K22 Rule Violations” on page 223

Understanding K19 Rule ViolationsDRC K19 simulates the test_setup, load_unload, shift and capture procedures as defined in thetest procedure file. By default, this simulation is performed with constrained pins initialized totheir constrained values. To speed up simulation times, however, the rule simulates only a small



number of shift cycles. If the first scan cell of each scan chain is loaded with the correct values,then the EDT decompressor works properly and this rule check passes.

If the first scan cell of any scan chain is loaded with incorrect data, the K19 rule check fails. Thetool then automatically performs an initial diagnosis to determine where along the path from thechannel inputs to the core chain inputs the problem originated. Figure C-2 shows the data flowthrough 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

For example, if the K19 rule detected erroneous data at the output of the first scan cell (1) inscan chain 2, the rule would check whether data applied to the core chain input (2) is correct. Ifthe 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 chain2 for each shift cycle. For comparison, the tool also lists the values that occurred during the

Prim

ary

Inpu

ts

Inte

rnal

Nod

es (o

ptio

nal)

Deco

mpr

esso

r

Bypa

ss (o

ptio

nal)

CoreEDT

12345678

Data Flow

1: Core chain <index> first cell2: Core chain <index> input3: Core chain <index> input driver4: EDT module chain <index> input (source)5: Decompressor chain <index> output6: EDT module channel <index> input7: Channel <index> input internal node8: Channel <index> input pin

logic



August 2009

DRC’s simulation of the circuitry. If the data is correct at the first scan cell (1) and at the corechain inputs (2), the rule next checks the data at the outputs of the core chain input drivers (3).

NoteThe 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 circuitdesigner inserts logic between the EDT logic and the core scan chain inputs, the driversmight be outside the EDT module.

The signals at (3) should always be the same as the signals at the core chain inputs (2). The toolchecks that this is so, however, because the connection between these two points is emulatedand not actually a physical connection. Figure 6-4 and the explanation accompanying it detailwhy TestKompress emulates this connection.

NoteDue to the tool’s emulation of the connection between points (2) and (3), you cannotobtain 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 anemulated connection to another gate at this point will display the name and gate ID# ofthe other gate; you can then issue Report Gates for the other gate and continue the tracefrom there.

If the data at the outputs of the core chain input drivers (3) is correct, the rule next checks thechain input data at the outputs of the EDT module (4). For each scan chain, if the data is correctat (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 modulethat drives the “core chain 1 input.” The word “source” indicates this is the pattern source forchain 1. Also, notice the gate name “/edt_i/edt_bypass_logic_i/ix31/Y” for the EDT modulechain 1 input. Because TestKompress simulates the flattened netlist and does not model thehierarchical module pins, the tool reports the gate driving the EDT module output.

NoteThe 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 representsmodule pins.

The K19 rule verifies the data at the EDT module chain inputs (4) only if the EDT modulehierarchy is preserved. If the netlist is flattened, or the EDT module name or pin names are



changed during synthesis, TestKompress will no longer be able to identify the EDT module andits pins.

Tip: Preserving the EDT module during synthesis allows for better diagnostic messagesif 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 locationsshown in Figure C-2 until it finds a location where the simulated data matches the expecteddata. The tool then issues an error message that describes where the problem first occurred, andwhere the data was verified successfully.

This rule check not only reports erroneous data, but also reports unexpected X or Z values, aswell as inverted signals. This information can be very useful when you are debugging thecircuit.

Examples of some specific K19 problems, with suggestions for how to debug them, are detailedin the following sections:

Incorrect Control SignalsInverted SignalsIncorrect EDT Channel Signal OrderIncorrect Scan Chain OrderX Generated by EDT DecompressorUsing Set Gate Report K19

Incorrect Control SignalsFixing incorrect values on EDT control signals often resolves other K19 violations. Problemswith control signals may be detected by other K rules, so it is a good practice to check for thesein the transcript prior to the K19 failure(s) and fix them first. At minimum, the other K rulefailures 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 tothis 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 constantincorrect value, it is reasonable to suspect that the load_unload or shift procedure in the testprocedure file is applying an incorrect value to this pin. The edt_bypass signal should be 0during load_unload and shift (see Figure 6-2), so you could use the following commandsequence to check the pin’s value after DRC.



August 2009

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, alongwith examples of procedures you would be examining for errors:

set gate report drc_pattern load_unload

report gate /edt_bypass

The values reported for the load_unload are okay, but in the first “apply shift” (shown in boldfont), edt_bypass is 1 when it should be 0. This points to the shift procedure as the source of theproblem. You can use the following commands to confirm:

set gate report drc_pattern shiftreport gate /edt_bypass


force clear 0 ;

end;

force edt_update 1;

force edt_bypass 0;force edt_clock 0;

pulse edt_clock;end;

force scan_en 1;

apply shift 22;

pulse tclk 0;

// /edt_bypass primary_input// edt_bypass O (0001) /cpu_bypass_logic_i/ix23/S0...

timeplate gen_tp1 =force_pi 0;measure_po 10;pulse tclk 20 10;pulse edt_clock 20 10;period 40;

end;


force_sci;

end;

force edt_update 0;measure_sco;pulse tclk;pulse edt_clock;

end;

force edt_bypass 1;

// /edt_bypass primary_input// edt_bypass O (111) /cpu_bypass_logic_i/ix23/S0...


end;



The DRC simulation data for the shift procedure shows it is forcing the edt_bypass signal to thewrong value (1 instead of 0). The remedy is to change the force statement to “forceedt_bypass 0”.

Following is another example of the tool’s K19 messaging—for an incorrect value on the EDTupdate 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: 11111111111111111111114 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 controlsignal and describes an error in the shift procedure. A glance at Figure 6-2 shows the EDTupdate signal should be 1 during load_unload and 0 for shift. You could now check the value ofthis signal as follows (relevant procedure file excerpts are shown below the examplecommands):

set gate report drc_pattern shiftreport gate /edt_update

The output of the gate report for the shift procedure shows the EDT update signal is 1 duringshift. The reason is an incorrect force statement in the shift procedure, shown in the procedureexcerpt below the example. Changing “force edt_update 1;” to “force edt_update 0;” in the shiftprocedure would resolve these K18 and K19 violations.


force_sci;

end;

force edt_update 1;measure_sco;pulse tclk;pulse edt_clock;

end;

// /edt_update primary_input// edt_update O (111) /cpu_bypass_logic_i/ix23/S0...


end;



August 2009

Inverted SignalsTestKompress 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 istrue of any source of inversion added on the input side of the decompressor.) Without thisinformation, the decompressor will generate incorrect data and the K19 rule check willtranscript 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 inFigure C-2). To debug, trace back from point 6 looking for the source of the inversion. Forexample:

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// edt_channels_in1 O /U$1/Y

The trace shows there are no gates between the primary input where the data is correct and thegate (an inverter) where the inversion was detected, so the latter is the source of this K19violation. You can use the -Inv switch with the Set EDT Pins command to solve the problem.

report edt pins

//// Pin description Pin name Inversion// --------------- -------- ---------// Clock edt_clock -// Update edt_update -// Scan channel 1 input edt_channels_in1 -// " " " output edt_channels_out1 -//

set edt pins input_channel 1 -invreport edt pins

//// Pin description Pin name Inversion// --------------- -------- ---------// Clock edt_clock -// Update edt_update -



// Scan channel 1 input edt_channels_in1 inv// " " " output edt_channels_out1 -//

Incorrect EDT Channel Signal OrderIf you manually connect the EDT module to the core scan chains, it is easy to connect signals inthe wrong order. If the K19 rule check detects incorrectly ordered signals at any point, it issuesmessages similar to the following; notice the statement that signals appear to be connected inthe 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).

Data at channel 1 input pin /edt_channels_in1 (8) is correct.Expected: 010000000Simulated: 000000000

Erroneous bit(s) detected at EDT module channel 2 input/edt_channels_in1 (8).

Data at channel 2 input pin /edt_channels_in2 (9) is correct.Expected: 000000000Simulated: 010000000

2 signals appear to be connected in the wrong order at EDT modulechannel inputs (bus /edt_i/edt_channels_in). (K19-2)

Data at EDT module channel 2 input /edt_channels_in1 (8) match thoseexpected at EDT module channel 1 input /edt_channels_in2 (9).

Data at EDT module channel 1 input /edt_channels_in2 (9) match thoseexpected at EDT module channel 2 input /edt_channels_in1 (8).

DRC reports this as two K19 occurrences, but the same signals are mentioned in bothoccurrence messages. Notice also that the Expected and Simulated values are the same, butreversed for each signal, a corroborating clue. The fix is to reconnect the signals in the correctorder in the netlist.

Incorrect Scan Chain OrderTestKompress enables you to add and delete scan chain definitions with the commands, AddScan Chains and Delete Scan Chains. If you use these commands, it is mandatory that you keepthe scan chains in exactly the same order in which they are connected to the EDT module: forexample, the input of the scan chain added first must be connected to the least significant bit ofthe EDT module chain input port (point 4 in Figure C-2). Deleting a scan chain with the DeleteScan Chains command, then adding it back again with Add Scan Chains, will change thedefined order of the scan chains, resulting in K19 violations. If scan chains are not added in theright 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 chaininputs. 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).



August 2009

To check if scan chains were added in the wrong order, issue the Report Scan Chains commandand compare the displayed order with the order in the dofile the tool wrote out when the EDTlogic was created. For example:

report scan chains

chain = chain1 group = grp1input = /cpu_i/scan_in1 output = /cpu_i/scan_out1 length = unknown


...chain = chain6 group = grp1

input = /cpu_i/scan_in6 output = /cpu_i/scan_out6 length = unknownchain = chain5 group = grp1

input = /cpu_i/scan_in5 output = /cpu_i/scan_out5 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//// 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 test_design_edt_iset edt instances -decompressor test_design_edt_decompressor_iset edt instances -compactor test_design_edt_compactor_i

add scan groups grp1 testprocadd scan chains -internal chain1 grp1 /cpu_i/scan_in1 /cpu_i/scan_out1add scan chains -internal chain2 grp1 /cpu_i/scan_in2 /cpu_i/scan_out2...add scan chains -internal chain5 grp1 /cpu_i/scan_in5 /cpu_i/scan_out5add scan chains -internal chain6 grp1 /cpu_i/scan_in6 /cpu_i/scan_out6

The easiest way to solve this problem is either to delete all scan chains and add them in the rightorder:

delete scan chains -alladd scan chains -internal chain1 grp1 /cpu_i/scan_in1 /cpu_i/scan_out1add scan chains -internal chain2 grp1 /cpu_i/scan_in2 /cpu_i/scan_out2...add scan chains -internal chain5 grp1 /cpu_i/scan_in5 /cpu_i/scan_out5add scan chains -internal chain6 grp1 /cpu_i/scan_in6 /cpu_i/scan_out6

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



X Generated by EDT DecompressorXs should never be applied to the scan chain inputs. If this occurs, the K19 rule check issues amessage 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: 10100010000000010001Simulated: X0X000X00000000X000X

Provided the EDT module hierarchy is preserved, the message describes the origin of the Xsignals. The preceding message, for example, indicates the EDT bypass logic generates Xsignals, 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) correctlyconnected to the EDT module? If the EDT decompressor is not reset properly, X signalsmight be generated.

• Is the EDT update signal (edt_update by default) asserted in the load_unload procedureso that the decompressor is reset? If the decompressor is not reset properly, X signalsmight be generated.

• Is the EDT bypass signal (edt_bypass by default) forced to 0 in the shift procedure? Ifthe edt_bypass signal is not 0, X signals from un-initialized scan chains might beswitched to the inputs of the core chains.

• If the EDT control signals are generated on chip (by means of a TAP controller, forexample), are they forced to their proper values so the decompressor is reset in theload_unload procedure?

In TestKompress, you can report the K19 simulation results for gates of interest by issuing “setgate report k19” in Setup system mode, then using “report gates” on the gates after the K19 rulecheck fails. You can also use an HDL simulator like ModelSim. In order to do that, ignorefailing K19 DRCs by issuing a “set drc handling k19 ignore” command. Next, generate threerandom patterns in Atpg system mode and save the patterns as serial Verilog patterns. Thensimulate the circuit with an HDL simulator and analyze the signals of interest.



August 2009

Using Set Gate Report K19If you issue a Set Gate Report command with the K19 argument prior to DRC, you can useReport Gates to view the simulated values for the entire sequence of events in the test procedurefile for any K19-simulated gate. The K19 argument also has several options that enable you tolimit the content of the displayed data.

Tip: Use Set Gate Report with the K19 argument only when necessary. Because the toolhas to log simulation data for all simulated setup and shift cycles, Set Gate Report K19reporting can slow EDT DRC run time and increase memory usage compared to Set GateReport Drc_pattern reporting.

The following shows how you might report on the simulated values for the “core chain 2 firstcell” mentioned in the first error message example of this section (see “Understanding K19Rule Violations” on page 212):

set gate report k19

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

set system mode atpg

...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: 0011101011101001XSimulated:01100110001110101...

report gates 7021

// /cpu_i/option_reg_2/DFF1 (7021) DFF// "S" I 50-// "R" I 46-// CLK I 1-/clk// "D0" I 1774-// "OUT" O 52- 53-//// Proc: 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 valueduring simulation. The time numbers (read vertically) indicate the relative time that eventsoccurred within each cycle, as determined from the procedure file. If the gate is one used by theDRC as a reference point in its automated analysis of K19 mismatches, the report lists the valuethe tool expected at the end of each cycle and whether it matches the simulated value. Also, thelast line of the report reminds you the gate is a monitor gate (a reference point in its automatedanalysis) and tells you its location in the data path. These monitor points correspond to the eightpoints illustrated in Figure C-2.

Understanding K22 Rule ViolationsLike 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 thanK19; one simulation in non-masking mode and a number of simulations in masking mode. If thecorrect values are shifted out of the channel outputs in both modes, then the EDT compactorworks properly and this rule check passes.

If erroneous data is observed at any channel output, either in non-masking or masking mode, theK22 rule check fails. The tool then automatically performs an initial diagnosis to determinewhere 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 rulecheck validates the signals.



August 2009

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

For example, if the K22 rule detected erroneous data at the channel outputs (6), the tool wouldbegin a search for the origin of the problem. First, it checks if the core chain outputs (1) have thecorrect values. If the data at (1) is correct, TestKompress next checks the data at the inputs ofthe EDT module (2). If the simulated data does not match the expected data here, the tool stopsthe 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: 111101001101100100000000001000100000Simulated: 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).

Prim

ary

Out

puts

Inte

rnal

Nod

es (o

ptio

nal)

Com

pact

or

Bypa

ss (o

ptio

nal)

Core

431

EDT

2

1: Core chain <index> output2: EDT module chain <index> output (sink)3: EDT compactor channel <index> output4: EDT module channel <index> output5: Channel <index> output internal node6: Channel <index> output pin

65

Data Flow

Decoder

logic



Expected: 110001001011000000000000000000110001Simulated: 00011000111010000000001111001101100

In this message, “EDT module chain 3 output (sink)” refers to the input of the EDT module thatis driven by the “core chain 3 output.” The word “sink” indicates this is the sink for theresponses captured in chain 3. Also, notice the gate name “/cpu_i/stack2_reg_8/Q” for the EDTmodule chain 3 output. Because TestKompress simulates the flattened netlist and does notmodel hierarchical module pins, the tool reports the gate driving the EDT module’s input.

NoteThe K19 and K22 rules always report gates driving EDT module inputs or outputs. Thisis 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 secondreporting problems in masking mode. The preceding example tells you the masking mode failswhen the mask is set to 3; that is, when the third core chain is selected for observation.

NoteIn masking mode, only one core chain per compactor group is observed at the channeloutput for the group. In non-masking mode, the output from all core chains in acompactor 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 thecore chain output (1 in Figure C-3) and the EDT module, making sure any logic in between iscontrolled correctly. Usually, there is no logic between the core chain outputs and the EDTmodule.

The K22 rule verifies data at the EDT module chain outputs (2) only if the EDT modulehierarchy is preserved. If the netlist is flattened or the EDT module’s name or pin names arechanged during synthesis, TestKompress will no longer be able to identify the EDT module andits pins.

NotePreserving the EDT module during synthesis allows for better diagnostic messages if thesimulation-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 thesimulated data to the expected data for the EDT compactor outputs (3), the EDT modulechannel outputs(4), and so on until the tool identifies the source of the problem. This approachis analogous to that used for the K19 rule checks described in the section, “Understanding K19Rule Violations” on page 212.

For guidance on methods of debugging incorrect or inverted signals, X signals, and signals orscan chains in the wrong order, the discussion of these topics in the section, “Understanding



August 2009

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

Incorrect Control SignalsInverted SignalsIncorrect EDT Channel Signal OrderIncorrect Scan Chain OrderX Generated by EDT Decompressor

Some specific K22 problems, with example debugging steps, are detailed in the followingsections:

Inverted SignalsIncorrect Scan Chain OrderMasking ProblemsUsing Set Gate Report K22

Inverted SignalsTestKompress enables you to use inverting pads on EDT channel outputs. However, you mustspecify the inversion using the Set EDT Pins command. (This actually is true of any source ofinversion added on the output side of the compactor.) Without this information, the compactorwill generate incorrect data and the K22 rule check will transcript a message similar to this (fora 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: X000001101110000100111Simulated: X111110010001111011000

Masking mode (mask 1): 1 of 1 channel output pins failed. (K22-2)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










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 inFigure 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 detectedand the gate (an inverter) where the data is correct, so the latter is the source of this K22violation. You can use the -Inv switch with the Set EDT Pins command to solve the problem.

report edt pins

//// Pin description Pin name Inversion// --------------- -------- ---------// Clock edt_clock -// Update edt_update -// Scan channel 1 input edt_channels_in1 -// " " " output edt_channels_out1 -//

set edt pins output_channel 1 -invreport edt pins

//// Pin description Pin name Inversion// --------------- -------- ---------// Clock edt_clock -// Update edt_update -// Scan channel 1 input edt_channels_in1 -// " " " output edt_channels_out1 inv//



August 2009

Incorrect Scan Chain OrderTestKompress enables you to add and delete scan chain definitions with the commands, AddScan Chains and Delete Scan Chains. If you use these commands, it is mandatory that you keepthe scan chains in exactly the same order in which they are connected to the EDT module: forexample, the output of the scan chain added first must be connected to the least significant bit ofthe EDT module chain output port (point 2 in Figure C-3). Deleting a scan chain with the DeleteScan Chains command, then adding it again with Add Scan Chains, will change the definedorder of the scan chains, resulting in K22 violations. If scan chains are not added in the rightorder, 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 chainoutputs (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)match those expected at EDT module chain 2 output (sink)/cpu_i/datai/uu1/Y (254).

Data at EDT module chain 4 output (sink) /cpu_i/addr_0/uu1/Y (245)match those expected at EDT module chain 3 output (sink)/cpu_i/datai1/uu1/Y (253).

Data at EDT module chain 1 output (sink) /cpu_i/datao/uu1/Y (256)match those expected at EDT module chain 4 output (sink)/cpu_i/addr_0/uu1/Y (245).

To check if scan chains were added in the wrong order, issue the Report Scan Chains commandand compare the displayed order with the order in the dofile the tool wrote out when the EDTlogic was created. For example:

report scan chains





shows chain1 added last instead of first, chain2 added first instead of second, and so on; not theorder in this excerpt of the original TestKompress-generated dofile:

//// Written by TestKompress v8.2004_5.10 on Tue Dec 14 15:18:41 2004//// 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 test_design_edt_iset edt instances -decompressor test_design_edt_decompressor_iset edt instances -compactor test_design_edt_compactor_i

add scan groups grp1 testprocadd scan chains -internal chain1 grp1 /cpu_i/scan_in1 /cpu_i/scan_out1add scan chains -internal chain2 grp1 /cpu_i/scan_in2 /cpu_i/scan_out2add scan chains -internal chain3 grp1 /cpu_i/scan_in3 /cpu_i/scan_out3add scan chains -internal chain4 grp1 /cpu_i/scan_in4 /cpu_i/scan_out4...

The easiest way to solve this problem is either to delete all scan chains and add them in the rightorder:

delete scan chains -alladd scan chains -internal chain1 grp1 /cpu_i/scan_in1 /cpu_i/scan_out1add scan chains -internal chain2 grp1 /cpu_i/scan_in2 /cpu_i/scan_out2add scan chains -internal chain3 grp1 /cpu_i/scan_in3 /cpu_i/scan_out3add scan chains -internal chain4 grp1 /cpu_i/scan_in4 /cpu_i/scan_out4

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

NoteWhen the tool is set up to treat K19 violations as errors, the invocation default, incorrectscan chain order will be detected by the K19 rule check, since the tool performs K19checks before K22. (See “Incorrect Scan Chain Order” in the K19 section for exampletool messages). In this case, the tool will stop before issuing any K22 messages related tothe incorrect order.

If the issue was actually one of incorrect signal order only at the outputs of the internalscan chains and the inputs were in the correct order, you would get K22 messages similarto the preceding and no K19 messages about scan chains being “added in the wrongorder.”

Masking ProblemsMost masking problems are caused by disturbances in the operation of the mask hold and shiftregisters. 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: 1111111111111111111111Simulated: XXXXXXXXXXXXXXXXXXXXXX

You can usually find the source of masking problems by analyzing the mask hold and shiftregisters. In this example, you could begin by tracing back to find the source of the Xs:



August 2009

set gate level primitiveset gate report drc_pattern state_stabilityreport gates /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63/Y

// /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63 (343) NAND// (ts)( ld)(shift)(cap)(stbl)// "I0" I ( X)(XXX)(XXX~X)(XXX)( X) 294-// B0 I ( X)(XXX)(XXX~X)(XXX)( X) 291- …/decoder1/ix107/Y// Y O ( X)(XXX)(XXX~X)(XXX)( X) 419- …/ix41/A1

b

// /cpu_edt_i/cpu_edt_compactor_i/decoder1/ix63 (294) OR// (ts)( ld)(shift)(cap)(stbl)// A0 I ( X)(XXX)(XXX~X)(XXX)( X) 208- …/reg_masks_hold_reg_0_/Q// A1 I ( X)(XXX)(XXX~X)(XXX)( X) 214- …/reg_masks_hold_reg_1_/Q// "OUT" O ( X)(XXX)(XXX~X)(XXX)( X) 343-

b

// /cpu_edt_i/cpu_edt_compactor_i/reg_masks_hold_reg_0_ (208) BUF// (ts)( ld)(shift)(cap)(stbl)// "I0" I ( X)(XXX)(XXX~X)(XXX)( X) 538-// Q O ( X)(XXX)(XXX~X)(XXX)( X) 235- …/ix102/A0// 292- …/decoder1/ix57/A0// 293- …/decoder1/ix113/A// 346- …/decoder1/ix61/A0// 294- …/decoder1/ix63/A0

b

// /cpu_edt_i/cpu_edt_compactor_i/reg_masks_hold_reg_0_ (538) DFF// (ts)( ld)(shift)(cap)(stbl)// "S" I ( 0)(000)(000~0)(000)( 0) 48-// "R" I ( 0)(000)(000~0)(000)( 0) 150-// CLK I ( 0)(000)(000~0)(000)( 0) 47-// D I ( X)(XXX)(XXX~X)(XXX)( X) 235- …/ix102/Y// "OUT" O ( X)(XXX)(XXX~X)(XXX)( X) 208- 209-

The trace shows the clock for the mask hold register is inactive. Trace back on the clock to findout why:

report gates 47

// /cpu_edt_i (47) TIE0// (ts)( ld)(shift)(cap)(stbl)// "OUT" O ( 0)(000)(000~0)(000)( 0) 541-…/reg_masks_hold_reg_1_/CLK// 540-…/reg_masks_shift_reg_1_/CLK// 539-…/reg_masks_shift_reg_0_/CLK// 538-…/reg_masks_hold_reg_0_/CLK// 537 …/reg_masks_shift_reg_2_/CLK// 536-…/reg_masks_hold_reg_2_/CLK

The information for the clock source shows it is tied. As the EDT clock should be connected tothe hold register, you could next report on the EDT clock primary input at the compactor andcheck for a connection to the hold register:

TroubleshootingMiscellaneous


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 connectedto the hold register. Because an inactive clock signal to the mask hold register would causemasking to fail, check the transcript for corroborating messages that indicate multiple similarmasking 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).Masking mode (mask 2, chain2): 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 particularproblem, you would need to connect the EDT clock to the mask hold register in the netlist.

Using Set Gate Report K22The Set Gate Report command has a K22 argument similar to the K19 argument described in“Using Set Gate Report K19” on page 222. 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 testprocedure file for any K22-simulated gate. Like the K19 argument, the K22 argument also hasseveral 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 toolhas 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 gatereport drc_pattern” reporting.

Miscellaneous

Incorrect References to \**TSGEN** in Synthesized NetlistAfter 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



August 2009

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 SetEDT can handle Xs, but you may want to limit them in order to enhance compression. Toachieve 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 istested by memory BIST, X sources are reduced because the RAM will no longer be an Xgenerator in ATPG mode.

If no Xs are captured on the scan chains, usually no fault effects are lost due to the compactorsand TestKompress does not have to generate patterns that use scan chain output masking. Forcircuits with no Xs observable on the scan chains, the effective compression is usually muchhigher (everything else being equal) and the number of patterns is only slightly more than whatATPG generates without EDT. DRC’s rule E5 identifies sources of observable Xs.

One clue you probably have many observable Xs is usually apparent in the transcript for anEDT pattern generation run. With few or no observable Xs, the number of effective patterns ineach simulation pass without scan chain masking will (ideally) be 32 for 32-bit invocations and64 for 64-bit invocations. Numbers significantly lower indicate Xs are reducing test



effectiveness. This is confirmed if the number of effective patterns rises significantly whenTestKompress uses masking to block the observable Xs. This is shown in the following excerptfrom 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.// deterministic ATPG invoked with abort limit = 30// 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 ModeOccasionally, TestKompress will generate an effective pattern that cannot be compressed usingEDT technology. Although it is a rare occurrence, if many faults generate such patterns, it canhave an impact on test coverage. Decreasing the number of scan chains usually remedies theproblem. Alternatively, you can bypass the EDT logic, which reconfigures the scan chains intofewer, longer scan chains. This requires a separate ATPG run on the remaining faults with atraditional ATPG tool such as FastScan.

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

If Compression is Less Than ExpectedIf you find effective compression is much less than you targeted, taking steps to remedy orreduce the following should improve the compression:

• Many observable Xs—EDT can handle observable Xs but their occurrence requires thetool to use masking patterns. Masking patterns observe fewer faults than non-maskingpatterns, so more of them are required. More patterns lowers effective compression.



August 2009

If the session transcript shows all patterns are non-masking, then observable Xs are notthe cause of the lower than expected compression. If the tool generated both maskingand non-masking patterns and the percentage of masking patterns exceeds 25% of thetotal, then there are probably many observable Xs. To find them, look for E5 DRCmessages. You activate E5 messages by issuing a “set drc handling e5 note” command.

NoteIf there are many observable Xs, you will probably see a much higher runtime comparedto FastScan. You will probably also see a much lower number of effective patternsreported in the transcript when TestKompress is not using scan chain masking, comparedto when the tool is using masking.

The Chapter 7 section, “Resolving X Blocking with Scan Chain Masking,” describesmasking 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 “LimitingObservable Xs for a Compact Pattern Set” earlier in this chapter.

• EDT Aborted Faults—For information about these types of faults, refer to “If there areEDT aborted faults” in the next section.

• If there are no EDT aborted faults, try a more aggressive compression configuration byincreasing the number of scan chains.

If Test Coverage is Less Than ExpectedIf you find test coverage is much less than you expected, first compare it to the test coverageobtainable without EDT, using FastScan. If the test coverage with EDT is less than you obtainwith FastScan, the following sections list steps you can take to raise it to the same level astraditional FastScan ATPG:

If there are EDT aborted faultsWhen TestKompress generates an effective fault test, but is unable to compress the pattern, thefault is classified as an EDT aborted fault. TestKompress issues a warning at the end of the runfor EDT aborted faults and reports the resultant loss of coverage. You can also obtain thisinformation by issuing the Report Aborted Faults command and looking for the “edt” class ofaborted 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 PinsRelatively low test coverage can indicate internal scan chain pins are shared with functionalpins. These pins must not be shared because the internal scan chain pins are connected to theEDT 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 ifthese are dedicated pins. By default, DRC issues a warning if scan chain pins are not dedicatedpins.

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 ScanChain Pins with Functional Pins” on page 44 for additional information.

Masking Broken Scan Chains in the TestKompress LogicYou can set up the TestKompress logic to mask the load, capture, and/or unload values onspecified scan chains by inserting custom logic between the scan chain outputs and thecompactor. The custom logic allows you to either feed the desired circuit response (0/1) to thecompactor or tie the scan chain output to an unknown value (X). For more information, see theAdd Chain Masks command.



August 2009


Glossary

Bypass CircuitryAdditional logic circuitry generated by TestKompress to bypass the decompressor andcompressor in the EDT logic. The bypass circuitry allows you to generate uncompressed testpatterns using traditional ATPG methods.

Bypass ModeTestKompress mode of operation when the bypass circuitry is used to bypass the decompressorand compressor and generate uncompressed test patterns. See Bypass Circuitry.

Chain-to-channel RatioThe 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 oftester channels, so is usually fixed.

ChannelRefer to Scan Channel.

CompactorThe part of the EDT logic that converts the outputs of a collection of internal scan chains intoone external scan channel output. In addition to the compaction in the number of scan chainoutputs, the conversion reduces the need for space that would otherwise be required to routemultiple scan chain outputs.

Compactor GroupIn the compactor circuitry, one or more stages of XOR gates compact the response from severalchains into each channel output. Scan chains compacted into the same scan channel are said to bein the same compactor group.

Compactor StageA single level of logic (XOR gates) in the Compactor. Each spatial compactor is comprised ofone or more compactor stages. See also First Compactor Stage.

CompressionRefer to Effective Compression.

Current EDT BlockThe EDT block that is the sole target of context-sensitive commands in the top-level PatternGeneration Phase of a modular TestKompress flow.

CoreThe original design without boundary scan or I/O pads.

Glossary

238August 2009


DecompressorThe component of the TestKompress logic that converts compressed patterns into normal scanpatterns and applies them to the scan-inserted design core.

EDTThe trademark representing the Embedded Deterministic Test technology developed by MentorGraphics. See also Embedded Deterministic Test Technology.

EDT BlockA design block in a modular TestKompress design that implements a full complement of theTestKompress hardware (decompressor, compactor, and optionally bypass logic). It is notnecessarily a module (entity) in the HDL, but rather is a decompressor/compactor/core group. AnEDT block’s EDT hardware drives all the scan chains within the block.

Testkompress LogicThe hardware synthesized into a design to implement the EDT technology. This hardwareconsists of two main components: A decompressor and a compactor.

TestKompress PatternsThe compressed patterns generated by TestKompress.

Effective CompressionThe ratio of the tester memory required with standard test patterns to the tester memory requiredwith compressed test patterns.

Embedded Deterministic Test TechnologyThe technology developed and patented by Mentor Graphics that uses on-chip hardware to allowhighly compressed data to be applied to a circuit under test (CUT) without being decompressedfirst by the tester (ATE).

First Compactor StageThe Compactor Stage closest to the scan chains.

Internal Scan ChainRefer to Scan Chain.

IP VersionThe version of the TestKompress hardware architecture. This is different than the softwareversion of the tool. A newer version of TestKompress, in which only the kernel is updated butthe architecture of the EDT logic it generates is the same as before, will have the same IP versionnumber. Only the software version would increment.

Joint Test Action Group (JTAG)The committee that formulated IEEE standard 1149.1 describing boundary scan.

JTAGRefer to Joint Test Action Group (JTAG).

Glossary


Pin SharingRefers 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 TestKompresschannel inputs and outputs, to improve signal propagation time.

Pipeline Stages (Compactor)Flip-flops (clocked by the leading edge of the TestKompress clock) that TestKompressoptionally inserts in the spacial compactor to improve the overall rate of data transfer through thecompactor logic.

Scan ChainA scan chain that is inside the core design; an internal scan chain.

Scan Chain MaskingThe mechanism whereby TestKompress records the actual measured value for each cell in aspecific scan chain in a compactor group, and changes the values to all Xs in all other chains inthe group, enabling the tool to observe the specific scan chain.

Scan ChannelA “virtual” scan chain that a chip incorporating EDT technology provides as the input/outputinterface to a channel of a tester. A chip design may include more than one scan channel, basedupon the number of channels available on the ATE, that will be used to test the chip.

Shared TestKompress PinA decompressor input or compactor output that, rather than being a dedicated TestKompress pin,is shared with a functional pin.

X BlockingThe X recorded by the tool in the pattern file in every position made unmeasurable as a result ofthe occurrence of an X in the corresponding cell of a different scan chain in the same compactorgroup.

Glossary

240August 2009


241

A B F GDC E H I J K L M N O P Q R S T U V XW Y Z

EDT Process Guide, V8.2009_3August 2009

— Symbols —.gz, 25.Z, 25

— A —Add edt block command, 181Add edt connections command, 181Add scan chains -internal, 70, 82, 83, 101Advanced topics, 113Architecture, EDT, 14, 58

— B —Batch mode, 23Boundary scan

BSDArchitectdescription, 95documentation, 94invoking, 122modifying BSDArchitect output, 122

circuitry, 95EDT and, 121 to 128EDT coexisting with, 122 to 126EDT signals driven by, 126 to 128flow overview, 121inserting, 94, 122modifying EDT dofile for, 41, 124modifying EDT test procedure file for, 41,

124pre-existing, 40prerequisites, 94synthesis, preparing for, 123top level wrapper for, 95

Bypass circuitry, 15, 19, 74customizing, 69diagram, 114

Bypass modecircuitry, 114generated files for, 84

Bypass patterns, EDTflow example, 118

using, 117Bypassing EDT logic, 113 to 121

— C —Chain-to-channel ratio

definition of, 14effective compression and, 14

Channel input pipeline stagesdefining, 129

Channel output pipeline stagesdefining, 129

Channel, see Scan ChannelClocking in EDT, 21, 58Commands

interrupting, 25running UNIX system, 24

Compactor, see Spacial compactorCompress files

.gz filename extension to, 25

.Z filename extension to, 25set file compression command, 25set gzip options command, 25

Compression, see Effective CompressionConserve disk space

UNIX utilities to, 25Control and channel pins

basic configuration, 59default configuration, 60sharing with functional pins, 61 to 66

channel input pin, 62channel output pin, 62EDT bypass pin, 63EDT clock pin, 62EDT configuration pin, 63EDT reset pin, 57, 62EDT scan enable pin, 63EDT update pin, 63example, 63reporting, 63requirements, 61

Index

242August 2009



summary, 59create_skeleton_design, 183

flow, 183, 184input file, 186

example, 188inputs, 186inputs and outputs, 185, 186interface file, 189, 193outputs, 186, 194

skeleton design, 194skeleton design ATPG library, 197skeleton design dofile, 196skeleton design test procedure file, 197

usage, 189

— D —Decompress files

.gz filename extension to, 25

.Z filename extension to, 25Decompressor, 15, 16, 19, 74, 238Delete edt blocks command, 181Delete edt connections command, 181Design Compiler synthesis script, 75, 93Design flow, EDT

design requirements, 31, 50FastScan and, 47introduction, 27 to 31steps, 32 to 33, 35 to 36tasks and products, 28, 29

Design input format, 31Design requirements, 31Design rules checks

EDT-specific rules (K rules), 20introduction, 20TIE-X message, 70transcript messages, 70upon leaving setup mode, 69verifying TK logic operation with, 102

DFTAdvisordofile for inserting scan chains, example,

45insert test logic command, 44, 45, 46

Dofilefor bypass mode (plain ATPG), 85, 102for generating EDT patterns, 58, 82, 101for inserting scan chains, 45

Dofiles, 23

— E —EDT

as extension of ATPG, 11clocking scheme, 21, 58compression, see Effective compressionconfiguration, reporting, 58control and channel pins, see Control and

channel pinsdefinition of, 11, 238design flow, see Design flow, EDTdiagnostics

flow example, 118with EDT bypass patterns, 118

EDT bypass patterns, 117, 118EDT internal patterns, 109, 110fundamentals, 11generating EDT test patterns, see Pattern

generation phaseI/O pads and, 31logic

conceptual diagram, 15, 160pattern generation, see Pattern generation

phasepattern size, 47pattern types supported, 22scan channels, see Scan channelssignals

bypass, see Pattern generation phaseclock, see Pattern generation phaseinternal control of, 20reset, 57update, see Pattern generation phase

EDT internal patterns, 109, 110EDT logic

creating, 49multiple configurations

configuration pin, 63parameters, 52

EDT reset signalspecifying, 57

Effective compressionchain-to-channel ratio and, 14, 234controlling, 23, 46estimating, 90

243EDT Process Guide, V8.2009_3August 2009


Embedded deterministic test, see EDTEnhanced procedure file

for bypass mode (plain ATPG), 102for generating EDT patterns, 101

Estimatingeffective compression, 90test coverage, 90

External IP location flowtasks and products, 28

External logic location flowdefinition of, 19steps, 33

— F —FastScan

command-line mode, emulating withTestKompress, 11, 33, 35, 47, 50

creating bypass patterns, 120EDT design flow and, 47, 48

Fault aliasing, 153Fault sampling, 144Faults, supported, 22File compression, decompression

.gz extension, 25

.Z extension, 25set file compression command, 25set gzip options command, 25

Filename extensions.gz, 25.Z, 25

— G —Generated EDT IP files, see Intellectual

property (IP)Generated files, 72 to 90

black box description of core, 74described, 72edt circuitry, 73, 74for bypass mode (plain ATPG)

dofile, 85, 102enhanced procedure file, 102test procedure file, 85

for use in EDT pattern generation phasedofile, 82, 101enhanced procedure file, 101test procedure file, 83

synthesis script, 75, 76, 93top-level wrapper, 73

Generating EDT test patterns, see Patterngeneration phase

— I —I/O pads

adding, 95managing pre-existing, 40requirements, 31

I/O pins, usage, 16Insert test logic -output new, 44, 45Intellectual property (IP)

blocksdetailed description of, 201 to 204integrating in design, 18 to 20

bypass circuitry, see Bypass circuitrycomponents of, 20creating, 71decompressor, see Decompressordefinition of, 14files

top-level wrapper, 19format of, 31overview, 18 to 21RTL description of, 71scan architectures supported, 32spatial compactor, see Spatial compactorspecification, 201synthesizing

Design Compiler and, 96overview, 93preparation, 94

verifying operation of, 102 to 106design rules checks, 102

wrapper for, 19Internal IP location flow

definition of, 20steps, 35tasks and products, 29

Interrupting commands, 25IP creation phase

in EDT design flow, 33, 35introduction, 30

IP locationinternal, 20

244August 2009



— L —Length of longest scan chain

specifying, 57Lockup cells

insertion, 134 to 142reporting, 134

Log files, 24logic location

external, 19

— M —Masking, see Scan chains, maskingMemories

handling of, 27, 232X values and, 150, 232

Modular TestKompressgenerating for a fully integrated design, 163

— P —Pattern generation phase, 99 to 109

adding scan chains, 100circuitry in, 107EDT signals, controlling

bypass, 100clock, 100update, 100

generating EDT patterns, 106 to 108in EDT design flow, 33, 36, 99introduction, 30optimizing compression, 108pattern post-processing, 109prerequisites, 100 to 101reordering patterns, 154setting up TestKompress, 100simulating EDT patterns, 110test procedure waveforms, example, 100verifying EDT patterns, 99, 110 to 111

Pattern generation, see Pattern generationphase

Pattern verification, 47Patterns

reordering, see Pattern generation phase,reordering patterns

types supported, 22Performance

establishing a reference point, 143

evaluation flow, 143improving, 145issues and analysis summary, 145measuring, 144

Pin sharingallowed, 44, 61, 73not allowed, 44, 73

Pipeline stagesdescription of, 128including, 57, 128

Pre-synthesis flow, 183

— R —Reduced netlist

role in Internal logic location flow, 86using to improve synthesis run time, 86writing, 86

Reorderpatterns, see Pattern generation phase,

reordering patternsscan chains, see Scan chains, reordering

Report drc rules command, 61Report edt blocks command, 181Report edt configuration command, 58, 59, 70,

101, 163, 180, 181Report EDT connections command, 181Report edt instances command, 181, 211Report edt lockup_cells command, 134Report edt pins command, 60, 63, 67Report scan volume command, 47, 107Reporting the EDT configuration, 58Reset signal, 57

— S —Scan architectures supported, 32Scan chains

chain-to-channel ratio and, 14custom masking of, 235determining how many to use, 43grouping requirement, 44length

longest, specifying range for, 57limitations on, 41, 73masking, 150 to 153

pattern file example, 153transcript example, 152

245EDT Process Guide, V8.2009_3August 2009


why needed, 150X blocking and, 151

prerequisites for inserting, 41reordering

impact on EDT patterns, 107impact on TK logic, 44, 72

scan and functional pin sharing, avoiding,44

synthesizing, 39, 41uncompressed

defining for EDT pattern generation,83, 101, 161

effect on test coverage estimate, 43including, 43, 83, 101leaving undefined during IP creation,

43modular flow and, 161

Scan channelschain-to-channel ratio and, 14conceptual diagram, 14controlling compression with, 14definition of, 14introduction, 13pins, sharing with functional pins, 44, 61

Scan grouprequirement, 44

Scripts, 23Set bypass chains command, 69Set compactor connections command, 69Set Current block command, 178Set current block command, 181Set edt command, 51 to 57Set edt instances command, 82, 181, 211Set edt pins command, 61, 64Shell commands, running UNIX commands,

24Skeleton flow, 183Spacial compactor

connections, customizing, 69Spatial compactor, 19, 74Supported pattern types, 22Synthesizing

scan chains, 39TK logic

preraring for, 93

with a reduced netlist, 86

— T —Test coverage

estimating, 90Test data volume, 143Test procedure file

for bypass mode (plain ATPG), 85for generating EDT patterns, 83

TestKompresscommands

add edt block, 181add edt connections, 181add scan chains, 70, 83, 101delete edt blocks, 181delete edt connections, 181report drc rules, 61report edt blocks, 178, 181report edt configuration, 58, 59, 70,

101, 180, 181report edt connections, 181report edt instances, 181, 211report edt lockup_cells, 134report edt pins, 60, 63, 67report environment, 51report scan volume, 47, 107set bypass chains, 69set compactor connections, 69set current block, 178, 181set dofile abort, 24set edt, 51 to 57set edt instances, 82, 181, 211set edt pins, 61, 64, 73set file compression, 25set gzip options, 25set logfile handling, 24write edt files, 71, 181see also ATPG and Failure Diagnosis

Tools Reference Manualcreating intellectual property with, 33, 35default flows, 27 to 36emulating FastScan with, 11, 33, 35, 47, 50generating EDT patterns with, 33, 36inputs and outputs, 37

external flow, 34internal flow, 37

246August 2009



invoking, 50pre-synthesis flow, 183skeleton flow, 183tool flows

external logic, 19, 33internal IP, 20, 35

user interface, 23TK logic

configuration, 57architecture, 58pipeline stages, 57

creating, 49version of, specifying, 58

Tools used in EDT flow, 28, 29Troubleshooting, 209 to 235

EDT aborted faults, 234incompressible patterns, 233K19 through K22 DRC violations, 211 to

215less than expected

compression, 233test coverage, 234

lockup cells in EDT IP, reporting, 134masking broken scan chains, 235simulation mismatches, 209, 210too many observable Xs, 232TSGEN, incorrect references to, 97, 231

— U —UNIX commands, running within tool, 24User interface

dofiles, 23interrupting commands, 25log files, 24running UNIX system commands, 24

using a reduced netlist with, 86

— V —Verification of EDT IP, 102 to 106Verification of EDT patterns, 99, 110 to 111

— W —Write edt files command, 71, 181

— X —X blocking, 150Xs, observable, 232

Third-Party Information

This section provides information on open source and third-party software that may be included in Design-for-Test softwareproducts.

• 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 associateddocumentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights touse, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons towhom 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 theSoftware.

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 APARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHTHOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OFCONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWAREOR 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., SunMicrosystems Inc., and Scriptics Corporation, none of whom are responsible for the results. The author thanks all ofthem.

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

I'd appreciate being given credit for this package in the documentation of software which uses it, but that is not arequirement.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUTNOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR APARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL HENRY SPENCER BE LIABLE FOR ANYDIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, ORPROFITS; 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 OFSUCH DAMAGE.

**********************************************************************

• wxWindows adopted the code out of Tcl 8.4.5. Portions of regc_locale.c and re_syntax.n were developed by Tcldevelopers 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., ScripticsCorporation, ActiveState Corporation and other parties. The following terms apply to all files associated with thesoftware unless explicitly disclaimed in individual files.

The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation forany purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim inany 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 THISSOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVEBEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUTNOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, AND THEAUTHORS 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 haveonly "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, thesoftware 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 termsspecified 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 <[email protected]>

All Rights Reserved

Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee ishereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation.

NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALLIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BELIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGESWHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OFCONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITHTHE 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 grantedwithout 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 orpublicity 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 OROTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESSFOR 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 WHATSOEVERRESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITYOF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USEOR 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 forany 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 itand 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. Ifyou use this software in a product, an acknowledgment in the product documentation would be appreciated but is notrequired.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the originalsoftware.

3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly Mark Adler

[email protected] [email protected]

If you use the zlib library in a product, we would appreciate *not* receiving lengthy legal documents to sign. The sourcesare provided for free but without warranty of any kind. The library has been entirely written by Jean-loup Gailly andMark Adler; it does not include third-party code.

If you redistribute modified sources, we would appreciate that you include in the file ChangeLog history informationdocumenting 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 PublicLicence as published by the Free Software Foundation; either version 2 of the Licence, or (at your option) any laterversion.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the impliedwarranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library GeneralPublic Licence for more details.

You should have received a copy of the GNU Library General Public Licence along with this software, usually in a filenamed COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA02111-1307 USA.

EXCEPTION NOTICE

1. As a special exception, the copyright holders of this library give permission for additional uses of the text containedin this release of the library as licenced under the wxWindows Library Licence, applying either version 3 of theLicence, or (at your option) any later version of the Licence as published by the copyright holders of version 3 of theLicence document.

2. The exception is that you may use, copy, link, modify and distribute under the user's own terms, binary object codeversions 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 LibraryGeneral Public Licence into a copy of this library, as this licence permits, the exception does not apply to the codethat you add in this way. To avoid misleading anyone as to the status of such modified files, you must delete thisexception 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 toyour modifications. If you do not wish that, you must delete the exception notice from such code and/or adjust thelicensing conditions notice accordingly.

****************************************************************************

• This software application may include GTK+ third-party software, portions of which may be subject to the GNU LibraryGeneral Public License. You can view the complete license at: http://www.gnu.org/copyleft/library.html, or find the file atmgcdft_tree/docs/legal/.

To obtain a copy of the GTK+ source code, send a request to [email protected]. This offer may beaccepted for three years from the date Mentor Graphics Corporation first distributed the GTK+ source code.

This software application may include freestdf third-party software that may be subject to the following copyright(s):

© 2004 Nelson Ingersoll <[email protected]>

© 2004-2005 Mike Frysinger [email protected]. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the followingconditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the followingdisclaimer in the documentation and/or other materials provided with the distribution.

Neither the name of the FREESTDF nor the names of its contributors may be used to endorse or promote products derivedfrom this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANYEXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENTSHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITEDTO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; ORBUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER INCONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANYWAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

****************************************************************************

• This software application may include LEF/DEF third-party software, which is distributed under the terms of the MentorGraphics End User License Agreement. You can view the complete license in the Mentor Graphics End User LicenseAgreement in this document. To obtain a copy of the LEF/DEF source code, or to obtain a copy of changes made to thesource code, if any, send a request to [email protected].

LEF/DEF software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANYKIND, either express or implied. See the License for the specific language governing rights and limitations under theLicense.

• This software application may include zlib version 1.1.4 third-party software. Zlib version 1.1.4 is distributed under theterms of the zlib/libpng license and is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, eitherexpress or implied. See the license for the specific language governing rights and limitations under the license. You canview a copy of the license at: mgcdft_tree/docs/legal//zlib_libpng.pdf. Zlib version 1.1.4 may be subject to the followingcopyrights:

© 1995-2005 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 forany 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 itand 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. Ifyou use this software in a product, an acknowledgment in the product documentation would be appreciated but is notrequired.

2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the originalsoftware.

3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly [email protected]

Mark Adler [email protected]

This software application may include wxglade version 0.6.3 third-party software, which is distributed on an "AS IS" basis,WITHOUT WARRANTY OF ANY KIND, either express or implied.

• This software application may include TKtreectrl version 2.2.7 third-party software, which is distributed on an “AS IS”basis, WITHOUT WARRANTY OF ANY KIND, either express or implied TKtreectrl version 2.2.7 may be subject to thefollowing copyrights:

This software is copyrighted by Tim Baker and other parties. The following terms apply to all files associated with thesoftware unless explicitly disclaimed in individual files.

The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation forany purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim inany distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications tothis software may be copyrighted by their authors and need not follow the licensing terms described here, provided thatthe 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 THISSOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVEBEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUTNOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN “AS IS” BASIS, AND THEAUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT,UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

• This software application may include tkcon version 2.4 third-party software, which is distributed on an “AS IS” basis,WITHOUT WARRANTY OF ANY KIND, either express or implied.

• This software application may include MiniSat version 1.14 third-party software, which is distributed on an “AS IS”basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.

This software application may include tcllib inifile version 1.0 third-party software, which is distributed on an “AS IS”basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. tcllib inifile v1.0 may be subject to thefollowing copyrights:

© 2003 Aaron Faupell [email protected]

All rights reserved.


Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the followingdisclaimer in the documentation and/or other materials provided with the distribution.

Neither the name of the organization nor the names of its contributors may be used to endorse or promote productsderived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANYEXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENTSHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITEDTO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; ORBUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER INCONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANYWAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

• This software application may include Boost version 1.39.0 third-party software. Boost version 1.39.0 is distributedunder the terms of the Boost Software License version 1.0 and is distributed on an "AS IS" basis, WITHOUTWARRANTY OF ANY KIND, either express or implied. See the license for the specific language governing rights andlimitations under the license. You can view a copy of the license at: <path to legal directory>/legal/ boost_1.0.pdf.Portions of this software may be subject to the Boost Artistic License. You can view a copy of the Boost Artistic Licenseat: <path to legal directory>/legal/boost_artistic_2000.pdf. Boost version 1.39.0 may be subject to the followingcopyrights:

© 2002-2003, Trustees of Indiana University.

© 2000-2001, University of Notre Dame.


Indiana University has the exclusive rights to license this product under the following license.

Software License, Version 1.0


* All redistributions of source code must retain the above copyright notice, the list of authors in the original source code,this list of conditions and the disclaimer listed in this license;

* All redistributions in binary form must reproduce the above copyright notice, this list of conditions and the disclaimerlisted in this license in the documentation and/or other materials provided with the distribution;

* Any documentation included with all redistributions must include the following acknowledgement:

"This product includes software developed at the University of Notre Dame and the Pervasive Technology Labs at IndianaUniversity. For technical information contact Andrew Lumsdaine at the Pervasive Technology Labs at IndianaUniversity. For administrative and license questions contact the Advanced Research and Technology Institute at 351West 10th Street. Indianapolis, Indiana 46202, phone 317-278-4100, fax 317-274-5902."

Alternatively, this acknowledgement may appear in the software itself, and wherever such third-party acknowledgmentsnormally appear.

* The name Indiana University, the University of Notre Dame or "Caramel" shall not be used to endorse or promoteproducts derived from this software without prior written permission from Indiana University. For written permission,please contact Indiana University Advanced Research & Technology Institute.

* Products derived from this software may not be called "Caramel", nor may Indiana University, the University of NotreDame or "Caramel" appear in their name, without prior written permission of Indiana University Advanced Research &Technology Institute.

Indiana University provides no reassurances that the source code provided does not infringe the patent or any otherintellectual property rights of any other entity. Indiana University disclaims any liability to any recipient for claimsbrought by any other entity based on infringement of intellectual property rights or otherwise.

LICENSEE UNDERSTANDS THAT SOFTWARE IS PROVIDED "AS IS" FOR WHICH NO WARRANTIES AS TOCAPABILITIES OR ACCURACY ARE MADE. INDIANA UNIVERSITY GIVES NO WARRANTIES AND MAKESNO REPRESENTATION THAT SOFTWARE IS FREE OF INFRINGEMENT OF THIRD PARTY PATENT,COPYRIGHT, OR OTHER PROPRIETARY RIGHTS. INDIANA UNIVERSITY MAKES NO WARRANTIES THATSOFTWARE IS FREE FROM "BUGS", "VIRUSES", "TROJAN HORSES", "TRAP DOORS", "WORMS", OR OTHERHARMFUL CODE. LICENSEE ASSUMES THE ENTIRE RISK AS TO THE PERFORMANCE OF SOFTWAREAND/OR ASSOCIATED MATERIALS, AND TO THE PERFORMANCE AND VALIDITY OF INFORMATIONGENERATED USING SOFTWARE.

© 2001-2003 William E. Kempf

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. William E. Kempf makes no representations about the suitabilityof this software for any purpose. It is provided "as is" without express or implied warranty.

© 1994, 2002 Hewlett-Packard Company

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Hewlett-Packard Company makes no representations about thesuitability of this software for any purpose. It is provided "as is" without express or implied warranty.

© 1996, 1997, 1998, 1999 Silicon Graphics Computer Systems, Inc.

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability ofthis software for any purpose. It is provided "as is" without express or implied warranty.

The Loki Library

© 2001 by Andrei Alexandrescu

This code accompanies the book:

Alexandrescu, Andrei. "Modern C++ Design: Generic Programming and Design

Patterns Applied".

© 2001. Addison-Wesley

Permission to use, copy, modify, distribute and sell this software for any purpose is hereby granted without fee, providedthat the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear insupporting documentation.

The author or Addison-Welsey Longman make no representations about the suitability of this software for any purpose. Itis provided "as is" without express or implied warranty.

© 2002-2003 David Moore, William E. Kempf

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. William E. Kempf makes no representations about the suitabilityof this software for any purpose.

It is provided "as is" without express or implied warranty.

© 2001 Ronald Garcia

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appears in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Ronald Garcia makes no representations about the suitability ofthis software for any purpose. It is provided "as is" without express or implied warranty.

© 2001 Jeremy Siek

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appears in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability ofthis software for any purpose. It is provided "as is" without express or implied warranty.

© 2002 CrystalClear Software, Inc.

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. CrystalClear Software makes no representations about thesuitability of this software for any purpose. It is provided "as is" without express or implied warranty.

© 1998, 2002-2006 Kiyoshi Matsui <[email protected]>



1. Redistributions of source code must retain the above copyright notice, this list of conditions and the followingdisclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the followingdisclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 THE AUTHOR BE LIABLE FORANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OFUSE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OFLIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OROTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THEPOSSIBILITY OF SUCH DAMAGE.

© 2000 Jeremy Siek, Lie-Quan Lee, and Andrew Lumsdaine

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appears in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. We make no representations about the suitability of this softwarefor any purpose. It is provided "as is" without express or implied warranty.

© 2005 JongSoo Park

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appears in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Jeremy Siek makes no representations about the suitability of thissoftware for any purpose. It is provided "as is" without express or implied warranty.

© 2006 Michael Drexl

Permission to use, copy, modify, and distribute this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appears in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Michael Drexl makes no representations about the suitability ofthis software for any purpose. It is provided "as is" without express or implied warranty.

© 1991 Massachusetts Institute of Technology

Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appear in all copies and that both that copyright notice and thispermission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicitypertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representationsabout the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.

© 2001, 2002 Indiana University

© 2000, 2001 University of Notre Dame du Lac

© 2000 Jeremy Siek, Lie-Quan Lee, Andrew Lumsdaine

© 1996-1999 Silicon Graphics Computer Systems, Inc.

© 1994 Hewlett-Packard Company

This product includes software developed at the University of Notre Dame and the Pervasive Technology Labs at IndianaUniversity. For technical information contact Andrew Lumsdaine at the Pervasive Technology Labs at IndianaUniversity. For administrative and license questions contact the Advanced Research and Technology Institute at 351West 10th Street. Indianapolis, Indiana 46202, phone 317-278-4100, fax 317-274-5902.

Some concepts based on versions from the MTL draft manual and Boost Graph and Property Map documentation, the SGIStandard Template Library documentation and the Hewlett-Packard STL, under the following license:

Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby grantedwithout fee, provided that the above copyright notice appears in all copies and that both that copyright notice and thispermission notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability ofthis software for any purpose. It is provided "as is" without express or implied warranty.

Fri Aug 15 16:29:47 EDT 1997

Harwell-Boeing File I/O in C V. 1.0

National Institute of Standards and Technology, MD.

K.A. Remington

NOTICE

Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee ishereby granted provided that the above copyright notice appear in all copies and that both the copyright notice and thispermission notice appear in supporting documentation.

Neither the Author nor the Institution (National Institute of Standards and Technology) make any representations aboutthe suitability of this software for any purpose. This software is provided "as is" without expressed or implied warranty.

End-User License AgreementThe latest version of the End-User License Agreement is available on-line at:

www.mentor.com/terms_conditions/enduser

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software (as defined in Section 2) between the company acquiringthe license (“Customer”), and the Mentor Graphics entity that issued the corresponding quotation or, if noquotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for licenseagreements related to the subject matter of this license agreement which are physically signed by Customer and anauthorized 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. IfCustomer does not agree to these terms and conditions, promptly return or, if received electronically, certifydestruction of Software and all accompanying items within five days after receipt of Software and receive a fullrefund of any license fee paid.

1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if and as agreed by Mentor Graphics, Customer’s appointed third party buying agent) places andMentor Graphics accepts purchase orders pursuant to this Agreement (“Order(s)”), each Order will constitute a contractbetween Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of thisAgreement, any applicable addenda and the applicable quotation, whether or not these documents are referenced on theOrder. Any additional or conflicting terms and conditions appearing on an Order will not be effective unless agreed inwriting by an authorized representative of Customer and Mentor Graphics.

1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of suchinvoice. Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-halfpercent per month or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight,insurance, customs duties, taxes or other similar charges, which Mentor Graphics will invoice separately. Unless providedwith a certificate of exemption, Mentor Graphics will invoice Customer for all applicable taxes. Customer will make allpayments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on paymentsby Customer hereunder will be Customer’s sole responsibility. Notwithstanding anything to the contrary, if Customerappoints a third party to place purchase orders and/or make payments on Customer’s behalf, Customer shall be liable forpayment under such orders in the event of default by the third party.

1.3. All products are delivered FCA factory (Incoterms 2000) except Software delivered electronically, which shall be deemeddelivered when made available to Customer for download. Mentor Graphics retains a security interest in all productsdelivered under this Agreement, to secure payment of the purchase price of such products, and Customer agrees to sign anydocuments that Mentor Graphics determines to be necessary or convenient for use in filing or perfecting such securityinterest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision of both a primaryand an alternate e-mail address.

2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement,including any updates, modifications, revisions, copies, documentation and design data (“Software”) are copyrighted, tradesecret and confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retainall rights not expressly granted by this Agreement. Mentor Graphics grants to Customer, subject to payment of applicablelicense fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form; (b) forCustomer’s internal business purposes; (c) for the term; and (d) on the computer hardware and at the site authorized by MentorGraphics. A site is restricted to a one-half mile (800 meter) radius. Customer may have Software temporarily used by anemployee for telecommuting purposes from locations other than a Customer office, such as the employee's residence, an airportor hotel, provided that such employee's primary place of employment is the site where the Software is authorized for use.Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid or services purchased,apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to execution of asingle session by a single user on the authorized hardware or for a restricted period of time (such limitations may be technicallyimplemented through the use of authorization codes or similar devices); and (c) support services provided, including eligibilityto receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer requests any changeor enhancement to Software, whether in the course of receiving support or consulting services, evaluating Software or

IMPORTANT INFORMATION

USE OF THIS SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THISLICENSE AGREEMENT BEFORE USING THE SOFTWARE. USE OF SOFTWARE INDICATES YOURCOMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH

IN THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS ANDCONDITIONS SHALL NOT APPLY.

http://www.mentor.com/terms_conditions/enduser

otherwise, any inventions, product improvements, modifications or developments made by Mentor Graphics (at MentorGraphics’ sole discretion) will be the exclusive property of Mentor Graphics.

3. ESC SOFTWARE. If Customer purchases a license to use development or prototyping tools of Mentor Graphics’ EmbeddedSoftware Channel (“ESC”), Mentor Graphics grants to Customer a nontransferable, nonexclusive license to reproduce anddistribute executable files created using ESC compilers, including the ESC run-time libraries distributed with ESC C and C++compiler Software that are linked into a composite program as an integral part of Customer’s compiled computer program,provided that Customer distributes these files only in conjunction with Customer’s compiled computer program. MentorGraphics does NOT grant Customer any right to duplicate, incorporate or embed copies of Mentor Graphics’ real-time operatingsystems or other embedded software products into Customer’s products or applications without first signing or otherwiseagreeing to a separate agreement with Mentor Graphics for such purpose.

4. BETA CODE.

4.1. Portions or all of certain Software may contain code for experimental testing and evaluation (“Beta Code”), which may notbe used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’ authorization, Mentor Graphics grants toCustomer a temporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Codewithout charge for a limited period of time specified by Mentor Graphics. This grant and Customer’s use of the Beta Codeshall not be construed as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not torelease commercially in any form.

4.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code undernormal conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’suse of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluationand testing, Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,weaknesses and recommended improvements.

4.3. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments thatMentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly onCustomer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, titleand interest in all such property. The provisions of this Subsection 4.3 shall survive termination of this Agreement.

5. RESTRICTIONS ON USE.

5.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include allnotices and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. Allcopies shall remain the property of Mentor Graphics or its licensors. Customer shall maintain a record of the number andprimary location of all copies of Software, including copies merged with other software, and shall make those recordsavailable to Mentor Graphics upon request. Customer shall not make Software available in any form to any person otherthan Customer’s employees and on-site contractors, excluding Mentor Graphics competitors, whose job performancerequires access and who are under obligations of confidentiality. Customer shall take appropriate action to protect theconfidentiality of Software and ensure that any person permitted access does not disclose or use it except as permitted bythis Agreement. Log files, data files, rule files and script files generated by or for the Software (collectively “Files”)constitute and/or include confidential information of Mentor Graphics. Customer may share Files with third partiesexcluding Mentor Graphics competitors provided that the confidentiality of such Files is protected by written agreement atleast as well as Customer protects other information of a similar nature or importance, but in any case with at leastreasonable care. Standard Verification Rule Format (“SVRF”) and Tcl Verification Format (“TVF”) mean MentorGraphics’ proprietary syntaxes for expressing process rules. Customer may use Files containing SVRF or TVF only withMentor Graphics products. Under no circumstances shall Customer use Software or allow its use for the purpose ofdeveloping, enhancing or marketing any product that is in any way competitive with Software, or disclose to any third partythe results of, or information pertaining to, any benchmark. Except as otherwise permitted for purposes of interoperabilityas specified by applicable and mandatory local law, Customer shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive from Software any source code.

5.2. Customer may not sublicense, assign or otherwise transfer Software, this Agreement or the rights under it, whether byoperation of law or otherwise (“attempted transfer”), without Mentor Graphics’ prior written consent and payment ofMentor Graphics’ then-current applicable transfer charges. Any attempted transfer without Mentor Graphics’ prior writtenconsent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the immediatetermination of the Agreement and licenses granted under this Agreement. The terms of this Agreement, including withoutlimitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in interest andassigns.

5.3. The provisions of this Section 5 shall survive the termination of this Agreement.

6. SUPPORT SERVICES. To the extent Customer purchases support services for Software, Mentor Graphics will provideCustomer with available updates and technical support for the Software which are made generally available by Mentor Graphicsas part of such services in accordance with Mentor Graphics’ then current End-User Software Support Terms located athttp://supportnet.mentor.com/about/legal/.

http://supportnet.mentor.com/about/legal/

7. LIMITED WARRANTY.

7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Software, when properlyinstalled, will substantially conform to the functional specifications set forth in the applicable user manual. MentorGraphics does not warrant that Software will meet Customer’s requirements or that operation of Software will beuninterrupted or error free. The warranty period is 90 days starting on the 15th day after delivery or upon installation,whichever first occurs. Customer must notify Mentor Graphics in writing of any nonconformity within the warranty period.For the avoidance of doubt, this warranty applies only to the initial shipment of Software under the applicable Order anddoes not renew or reset, by way of example, with the delivery of (a) Software updates or (b) authorization codes or alternateSoftware under a transaction involving Software re-mix. This warranty shall not be valid if Software has been subject tomisuse, unauthorized modification or improper installation. MENTOR GRAPHICS’ ENTIRE LIABILITY ANDCUSTOMER’S EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OFTHE PRICE PAID UPON RETURN OF SOFTWARE TO MENTOR GRAPHICS OR (B) MODIFICATION ORREPLACEMENT OF SOFTWARE THAT DOES NOT MEET THIS LIMITED WARRANTY, PROVIDEDCUSTOMER HAS OTHERWISE COMPLIED WITH THIS AGREEMENT. MENTOR GRAPHICS MAKES NOWARRANTIES WITH RESPECT TO: (A) SERVICES; (B) SOFTWARE WHICH IS LICENSED AT NO COST; OR (C)BETA CODE; ALL OF WHICH ARE PROVIDED “AS IS.”

7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NORITS LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TOSOFTWARE OR OTHER MATERIAL PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITSLICENSORS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FORA PARTICULAR PURPOSE AND NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.

8. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY WOULD BEVOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS OR ITSLICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDINGLOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, EVENIF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. INNO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS AGREEMENT EXCEEDTHE AMOUNT PAID BY CUSTOMER FOR THE SOFTWARE OR SERVICE GIVING RISE TO THE CLAIM. IN THECASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITYFOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THETERMINATION OF THIS AGREEMENT.

9. LIFE ENDANGERING APPLICATIONS. NEITHER MENTOR GRAPHICS NOR ITS LICENSORS SHALL BE LIABLEFOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITH THE USE OF SOFTWARE IN ANYAPPLICATION WHERE THE FAILURE OR INACCURACY OF THE SOFTWARE MIGHT RESULT IN DEATH ORPERSONAL INJURY. THE PROVISIONS OF THIS SECTION 9 SHALL SURVIVE THE TERMINATION OF THISAGREEMENT.

10. INDEMNIFICATION. CUSTOMER AGREES TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS ANDITS LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE OR LIABILITY, INCLUDINGATTORNEYS’ FEES, ARISING OUT OF OR IN CONNECTION WITH CUSTOMER’S USE OF SOFTWARE ASDESCRIBED IN SECTION 9. THE PROVISIONS OF THIS SECTION 10 SHALL SURVIVE THE TERMINATION OFTHIS AGREEMENT.

11. INFRINGEMENT.

11.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Softwareproduct infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics will pay anycosts and damages finally awarded against Customer that are attributable to the action. Customer understands and agreesthat as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics promptlyin writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend theaction; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.

11.2. If a claim is made under Subsection 11.1 Mentor Graphics may, at its option and expense, (a) replace or modify Software sothat it becomes noninfringing, or (b) procure for Customer the right to continue using Software, or (c) require the return ofSoftware and refund to Customer any license fee paid, less a reasonable allowance for use.

11.3. Mentor Graphics has no liability to Customer if the claim is based upon: (a) the combination of Software with any productnot furnished by Mentor Graphics; (b) the modification of Software other than by Mentor Graphics; (c) the use of other thana current unaltered release of Software; (d) the use of Software as part of an infringing process; (e) a product that Customermakes, uses, or sells; (f) any Beta Code; (g) any Software provided by Mentor Graphics’ licensors who do not provide suchindemnification to Mentor Graphics’ customers; or (h) infringement by Customer that is deemed willful. In the case of (h),Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs related to the action.

11.4. THIS SECTION IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTORGRAPHICS AND ITS LICENSORS AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY WITH RESPECT TOANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR TRADE SECRET MISAPPROPRIATION BYANY SOFTWARE LICENSED UNDER THIS AGREEMENT.

12. TERM.

12.1. This Agreement remains effective until expiration or termination. This Agreement will immediately terminate upon noticeif you exceed the scope of license granted or otherwise fail to comply with the provisions of Sections 2, 3, or 5. For anyother material breach under this Agreement, Mentor Graphics may terminate this Agreement upon 30 days written notice ifyou are in material breach and fail to cure such breach within the 30 day notice period. If a Software license was providedfor limited term use, such license will automatically terminate at the end of the authorized term.

12.2. Mentor Graphics may terminate this Agreement immediately upon notice in the event Customer is insolvent or subject to apetition for (a) the appointment of an administrator, receiver or similar appointee; or (b) winding up, dissolution orbankruptcy.

12.3. Upon termination of this Agreement or any Software license under this Agreement, Customer shall ensure that all use of theaffected Software ceases, and shall return it to Mentor Graphics or certify its deletion and destruction, including all copies,to Mentor Graphics’ reasonable satisfaction.

12.4. Termination of this Agreement or any Software license granted hereunder will not affect Customer’s obligation to pay forproducts shipped or licenses granted prior to the termination, which amounts shall immediately be payable at the date oftermination.

13. EXPORT. Software is subject to regulation by local laws and United States government agencies, which prohibit export ordiversion of certain products, information about the products, and direct products of the products to certain countries and certainpersons. Customer agrees that it will not export Software or a direct product of Software in any manner without first obtainingall necessary approval from appropriate local and United States government agencies.

14. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. All Software is commercialcomputer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to US FAR 48 CFR12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. Government or a U.S.Government subcontractor is subject solely to the terms and conditions set forth in this Agreement, except for provisions whichare contrary to applicable mandatory federal laws.

15. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporationand other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.

16. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice andduring Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm toreview Customer’s software monitoring system and records deemed relevant by the internationally recognized accounting firmto confirm Customer’s compliance with the terms of this Agreement or U.S. or other local export laws. Such review may includeFLEXlm or FLEXnet (or successor product) report log files that Customer shall capture and provide at Mentor Graphics’request. Customer shall make records available in electronic format and shall fully cooperate with data gathering to support thelicense review. Mentor Graphics shall bear the expense of any such review unless a material non-compliance is revealed. MentorGraphics shall treat as confidential information all information gained as a result of any request or review and shall only use ordisclose such information as required by law or to enforce its rights under this Agreement. The provisions of this section shallsurvive the termination of this Agreement.

17. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of the Mentor Graphics intellectualproperty rights licensed under this Agreement are located in Ireland and the United States. To promote consistency around theworld, disputes shall be resolved as follows: This Agreement shall be governed by and construed under the laws of the State ofOregon, USA, if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of Northor South America. All disputes arising out of or in relation to this Agreement shall be submitted to the exclusive jurisdiction ofPortland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the laws of Ireland apply. Notwithstanding theforegoing, all disputes in Asia (except for Japan) arising out of or in relation to this Agreement shall be resolved by arbitration inSingapore 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 thedispute, which rules are deemed to be incorporated by reference in this section. This section shall not restrict Mentor Graphics’right to bring an action against Customer in the jurisdiction where Customer’s place of business is located. The United NationsConvention on Contracts for the International Sale of Goods does not apply to this Agreement.

18. 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 fullforce and effect.

19. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes allprior or contemporaneous agreements, including but not limited to any purchase order terms and conditions. Some Softwaremay contain code distributed under a third party license agreement that may provide additional rights to Customer. Please seethe applicable Software documentation for details. This Agreement may only be modified in writing by authorizedrepresentatives of the parties. All notices required or authorized under this Agreement must be in writing and shall be sent to theperson who signs this Agreement, at the address specified below. Waiver of terms or excuse of breach must be in writing andshall not constitute subsequent consent, waiver or excuse.

Rev. 090402, Part No. 239301

edt_gd

Documents

consent of mentor graphics

proprietary information

government restricted

restricted rights legend

software pursuant

unauthorized use

service marks marks

government subcontractor