Dft Common

Design-for-Test Common ResourcesManual

Software Version 8.2006_3

August 2006

© 1999-2006 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: www.mentor.com/supportnetSend Feedback on Documentation: www.mentor.com/supportnet/documentation/reply_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://www.mentor.com/supportnet

http://www.mentor.com/supportnet/documentation/reply_form.cfm

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

Design-for-Test Common Resources Manual, V8.2006_3 3August 2006

Table of Contents

Chapter 1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2Design Rules Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Design Rules Checking Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17FastScan Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25DFTAdvisor Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25FlexTest Rules Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25TestKompress Rules Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Troubleshooting Rules Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Setting the Handling of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Turning on ATPG Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Setting the Level of Gate Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Setting the Gate Information Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Reporting Gate Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Flattening Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

The Design Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33General Rules (G Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Procedure Rules (P Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Scan Chain Trace Rules (T Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Scan Cell Data Rules (D Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Clock Rules (C Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70RAM Rules (A Rules). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105BIST Rules (B Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109EDT Rules (K Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Extra Rules (E Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Scannability Rules (S Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Timing Rules (W Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Vector Interfaces Warning and Error Messages (AG Rules) . . . . . . . . . . . . . . . . . . . . . . . 154

Other DRC Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Transparent Capture Handling Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Oscillation Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156RAM Summary Results and Test Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Chapter 3Using DFTInsight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Overview of DFTInsight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161DFTInsight Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

The User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163The DFTInsight Session Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Table of Contents

4August 2006

Design-for-Test Common Resources Manual, V8.2006_3

Using Strokes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Setting and Saving Preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Using the Schematic View Area Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Selecting Objects in the Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Performing Basic Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Invoking DFTInsight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Interrupting Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Choosing the Design Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Specifying the Gate Data to View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Controlling the Displayed Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Forward Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Reverting to a Previous Schematic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Displaying Specific Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Floating Net Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Removing Instances from the Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Marking an Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Troubleshooting DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Reporting Object Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Saving and Recalling a Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Saving and Replaying the Session Transcript. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Printing the Displayed Schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Closing the DFTInsight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Chapter 4Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Defining Scan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Defining a Scan Cell Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Example Scan Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Defining a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Model_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191List_of_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Interface Pins and Internal Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Cell Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Support of Arrays Within Library Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Defining Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Using Model Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Reading Multiple Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Verilog Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Supported Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

AND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215NAND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216OR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216NOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Buffer With High Impedance Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Table of Contents


XOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221XNOR Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Inverted Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Tri-State Buffer with Active High Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Inverted Tri-State Buffer with Active High Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228D Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231One Time Unit Delay Element (FlexTest Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Feedback Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Wire Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Pull-Up or Pull-Down Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Power Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Ground Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Unknown Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237High Impedance Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Undefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Unidirectional NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Unidirectional PMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Unidirectional Resistive NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Unidirectional Resistive PMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Unidirectional Feedback NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Unidirectional Feedback PMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Unidirectional CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Unidirectional CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Unidirectional Resistive CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Unidirectional Resistive CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Unidirectional Feedback CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Unidirectional Feedback CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Pulse Generators with User Defined Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252RAM and ROM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Chapter 5Creating ATPG Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Understanding LibComp Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Creating an ATPG Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Finding Unsupported Constructs in Partial Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Finding Black Boxes with Vectored Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Chapter 6Verifying ATPG Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Verification Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Running Verification from the Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Interpreting the Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Table of Contents

6August 2006


verify.results File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Debugging Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Re-simulating Verilog Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Prerequisites for Simulating Verilog Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Simulating Verilog Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Fixing DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Improving Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Troubleshooting One Model at a Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Assessing the Impact of Low Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Re-running the FastScan Portion of Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Modeling for Optimal Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Handling Ignored or Blackboxed Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Anticipating the Effects of Internal Gating on Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Chapter 7Using VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Overview of VHDL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Reading VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Writing VHDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Chapter 8Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Procedure File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Introductory Procedure File Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314#include Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314Set Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Alias Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Timing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Timeplate Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Procedure Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

The Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329Scan and Clock Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Non-Scan Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Procedure File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Example TI TDL Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Example UTIC Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358FlexTest Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Merging Procedure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Default Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Automatic End Measure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Supporting Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362ASICVector Interfaces Output Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Parameter File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

Appendix A

Table of Contents


Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Online Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Index

End-User License Agreement

Table of Contents


9August 2006


List of Figures

Figure 2-1. Example of Design Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 2-2. Example of Low_Design Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 2-3. Example of Primitive Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 2-4. Data Reported for a Specific Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figure 2-5. Rule D10 Violation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Figure 2-6. Rule D11 Violation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Figure 2-7. Clock Cycle Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Figure 2-8. Example Clock Cone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 2-9. Example Effect Cone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 2-10. Pin in Both Cones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figure 2-11. DFTInsight View Showing Clock Cones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figure 2-12. C1 Violation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 2-13. C2 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 2-14. C3 Violation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Figure 2-15. Example Timing That Allows Sink to Capture Source’s New Data. . . . . . . . . 79Figure 2-16. C4 Violation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Figure 2-17. Example Where Actual Behavior Differs from Tool’s Prediction . . . . . . . . . . 86Figure 2-18. C5 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Figure 2-19. C6 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Figure 2-20. C7 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Figure 2-21. C8 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Figure 2-22. C9 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Figure 2-23. C10 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Figure 2-24. C13 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Figure 2-25. C14 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Figure 2-26. C15 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Figure 2-27. Failing identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Figure 2-28. Common cell structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Figure 2-29. Failing identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Figure 2-30. Example E4 Violation Trace in DFTInsight . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Figure 2-31. Example E10 Violation Trace in DFTInsight . . . . . . . . . . . . . . . . . . . . . . . . . . 138Figure 2-32. Example S3 Rule Violation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Figure 2-33. Transparent Capture Handling Analysis Messages. . . . . . . . . . . . . . . . . . . . . . 155Figure 2-34. RAM Summary Results and Test Capability Messages . . . . . . . . . . . . . . . . . . 157Figure 3-1. DFTInsight Process Within the DFT Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Figure 3-2. DFTInsight Inputs and Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Figure 3-3. DFTInsight Session Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Figure 3-4. DFTInsight Instance Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Figure 3-5. Trace Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Figure 3-6. DFF Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

List of Figures

10August 2006


Figure 3-7. Connected Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Figure 3-8. Floating Net Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Figure 3-9. MUX and DFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Figure 4-1. General Scan Definition Replacement Example. . . . . . . . . . . . . . . . . . . . . . . . . 186Figure 4-2. Mux-Scan Definition Replacement Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Figure 4-3. Clocked-Scan Definition Replacement Example . . . . . . . . . . . . . . . . . . . . . . . . 188Figure 4-4. LSSD Scan Definition Replacement Example . . . . . . . . . . . . . . . . . . . . . . . . . . 188Figure 4-5. Complex Scan Definition Replacement Example. . . . . . . . . . . . . . . . . . . . . . . . 190Figure 4-6. Bidirectional Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Figure 4-7. Scan D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Figure 4-8. Design Example with Bus Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Figure 4-9. Simulation Model with ZHOLD Bus Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Figure 4-10. Combinational Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Figure 4-11. Creating an Internal Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Figure 4-12. Tri-State Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Figure 4-13. Non-Inverting Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Figure 4-14. Two-input NAND Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Figure 4-15. Mux-DFF Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Figure 4-16. The MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Figure 4-17. The DFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Figure 4-18. Tri-State Gate (_buf primitive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Figure 4-19. Tri-State Gate (_bufz primitive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Figure 4-20. Tri-State Gate (_wire primitive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Figure 4-21. Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Figure 4-22. AND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Figure 4-23. NAND Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Figure 4-24. OR Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Figure 4-25. NOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Figure 4-26. Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Figure 4-27. Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Figure 4-28. Buffer with High-Impedance Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Figure 4-29. XOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Figure 4-30. XNOR Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Figure 4-31. Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Figure 4-32. Inverted Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . 225Figure 4-33. Tri-State Buffer with Active High Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Figure 4-34. Inverted Tri-State Buffer with Active High Control. . . . . . . . . . . . . . . . . . . . . 227Figure 4-35. Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Figure 4-36. D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Figure 4-37. D Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Figure 4-38. One Time Unit Delay Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Figure 4-39. Feedback Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Figure 4-40. Wire Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Figure 4-41. Pull-Up or Pull-Down Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Figure 4-42. Undefined Functional Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

List of Figures


Figure 4-43. Unidirectional NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Figure 4-44. Unidirectional PMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Figure 4-45. Unidirectional Resistive PMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Figure 4-46. Unidirectional Resistive NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Figure 4-47. Unidirectional Feedback NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Figure 4-48. Unidirectional Feedback PMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Figure 4-49. Unidirectional CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Figure 4-50. Unidirectional CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Figure 4-51. Unidirectional Resistive CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . 248Figure 4-52. Unidirectional Resistive CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . 249Figure 4-53. Unidirectional Feedback CMOS1F Transistor . . . . . . . . . . . . . . . . . . . . . . . . . 250Figure 4-54. Unidirectional Feedback CMOS2F Transistor . . . . . . . . . . . . . . . . . . . . . . . . . 251Figure 4-55. ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Figure 4-56. RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Figure 4-57. Flattened RAM Model with oen Set to 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Figure 7-1. Example dft.map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Figure 8-1. Procedure File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313Figure 8-2. Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Figure 8-3. Timing Diagram for Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Figure 8-4. Load_Unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334Figure 8-5. Timing Diagram for Load_Unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 336Figure 8-6. Shadow_Control Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Figure 8-7. Master_Observe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Figure 8-8. Shadow_Observe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Figure 8-9. Sequential Transparent Circuitry Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339Figure 8-10. Skew_Load Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Figure 8-11. Skew_load applied within Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342Figure 8-12. Non-Scan Procedure Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342Figure 8-13. Capture Procedure Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Figure 8-14. Clock_po Procedure Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Figure 8-15. Ram_sequential Procedure Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Figure 8-16. Full Ram Sequential Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Figure 8-17. Ram_passthru Procedure Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Figure 8-18. Clock_sequential Procedure Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Figure 8-19. Full Clock Sequential Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Figure 8-20. Init_force Procedure Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Figure 8-21. Init_force Procedure Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Figure 8-22. Test_end Procedure Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Figure 8-23. Introductory Example with Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Figure 8-24. Introductory Example without Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . 355


List of Tables

Table 2-1. DRC Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Table 2-2. Clocking that May Result in a Signal Race . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Table 2-3. Clocking that May Result in a Signal Race . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 3-1. Mode Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Table 4-1. Supported Verilog Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Table 4-2. AND Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Table 4-3. NAND Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Table 4-4. OR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Table 4-5. NOR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Table 4-6. Inverter Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Table 4-7. Buffer Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Table 4-8. BUFZ Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Table 4-9. XOR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Table 4-10. XNOR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Table 4-11. TSL Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Table 4-12. TSLI Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Table 4-13. TSH Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Table 4-14. TSHI Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Table 4-15. MUX Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Table 4-16. D Flip-Flop Primitive Table for FlexTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Table 4-17. D Flip-Flop Primitive Table for FastScan and TestKompress . . . . . . . . . . . . . 229Table 4-18. D Latch Primitive Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Table 4-19. DELAY Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Table 4-20. INVF Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Table 4-21. WIRE Truth Table (for two inputs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Table 4-22. PULL Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Table 4-23. UNDEFINED Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Table 4-24. NMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Table 4-25. PMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Table 4-26. RNMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Table 4-27. RPMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Table 4-28. NMOSF Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Table 4-29. PMOSF Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Table 4-30. CMOS1 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246Table 4-31. CMOS2 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Table 4-32. RCMOS1 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Table 4-33. RCMOS2 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Table 4-34. CMOS1F Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Table 4-35. CMOS2F Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Table 5-1. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

List of Tables


Table 5-2. Output Dominance Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282Table 6-1. Debugging Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Table 7-1. Legal VHDL Identifier Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Table 7-2. DFT Translation of Legal VHDL Identifier Names . . . . . . . . . . . . . . . . . . . . . . 303Table 8-1. Reserved Punctuation Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Table 8-2. Translation Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Table 8-3. STIL Special Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Table 8-4. STIL Pattern Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Table 8-5. STIL Vector Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384

List of Tables

14August 2006



Chapter 1Overview

Design-for-Test (DFT) common resources are tools and file formats common to multiple DFTtools. Examples of common resources include DFTInsight™, ASICVector™ Interfaces, anddesign rule checking. Examples of common file formats include the test procedure format,VHDL, and ASICVector Interfaces. For more information on any of these common resources,see the following topics:

• Design Rules Checking

• Using DFTInsight

• Design Library

• Creating ATPG Models

• Verifying ATPG Models

• Using VHDL

• Test Procedure File


Overview

August 2006


Chapter 2Design Rules Checking

Design Rules Checking SummaryDFTAdvisor, FastScan, FlexTest, TestKompress, and the BIST-Ready and Fault Simulationphases of LBISTArchitect all perform design rules checking. Design rules checking withinthese tools includes some or all of the rules checks:

Additionally, the Vector Interfaces code produces error and warning messages if necessarywhen attempting to save Vector Interfaces patterns. See “Vector Interfaces Warning and ErrorMessages (AG Rules)” on page 154. Plus, each tool displays various analysis and summarymessages upon completion of DRC. These are described in “Other DRC Messages” onpage 155.

Table 2-1 lists all of the rules and in which tools they are checked.

General (G rules) RAM (A rules)

Test procedure file (P rules) BIST (B rules)

Scan chain tracing (T rules) Extra user-specified (E rules)

Scan cell data (D rules) Scannability (S rules)

Clock (C rules) Timing Rules (W rules)

EDT (K rules)

Table 2-1. DRC Summary

Rule Violation Id.

A1 (RAM Rule #1) • • • • • • •

A2 (RAM Rule #2) • • • • • • •

A3 (RAM Rule #3) • • • • • • •

A4 (RAM Rule #4) • • • • • • •

A5 (RAM Rule #5) • • • • • • •

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t


Design Rules CheckingDesign Rules Checking Summary

August 2006

A6 (RAM Rule #6) • • • • • • •

A7 (RAM Rule #7) • • • • • • •

A8 (RAM Rule #8) •

B1 (BIST Rule #1) •

B2 (BIST Rule #2) • • •











B13 (BIST Rule #13) • • • • •

B14 (BIST Rule #14) • • • • •

B15 (BIST Rule #15) • • • •

B16 (BIST Rule #16) • • • •

C1 (Clock Rule #1) • • • • • • •

C2 (Clock Rule #2) • • • • • • •

C3 (Clock Rule #3) • • • • • • •

C4 (Clock Rule #4) • • • • • • •

C5 (Clock Rule #5) • • • • • • •

C6 (Clock Rule #6) • • • • • • •

C7 (Clock Rule #7) • • • • • • •

Table 2-1. DRC Summary (cont.)

Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t



C8 (Clock Rule #8) • • • • • • •

C9 (Clock Rule #9) • • • • • • •

C10 (Clock Rule #10) • • •

C11 (Clock Rule #11) •





C16 (Clock Rule #16) • • • • • • •

D1 (Scan Cell Data Rule #1) • • • • • • •

D2 (Data Rule #2) • • • • • • •

D3 (Data Rule #3) • • • • • • •

D4 (Data Rule #4) • • • • • • •

D5 (Data Rule #5) • • • • • • •

D6 (Data Rule #6) • • • • • • •

D7 (Data Rule #7) • • • • • • •

D8 (Data Rule #8) • • • • • • •

D9 (Data Rule #9) • • • • • • •

D10 (Data Rule #10) • • • •

D11 (Data Rule #11) • • • •

E1 (Extra Rule #1) • • • • • •

E2 (Extra Rule #2) • • • • • • •

E3 (Extra Rule #3) • • • • • • •

E4 (Extra Rule #4) • • • • • • •

E5 (Extra Rule #5) • • • • • • •

E6 (Extra Rule #6) • • • • • • •


Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t



August 2006

E7 (Extra Rule #7) • • • • • • •

E8 (Extra Rule #8) • • • • • • •

E9 (Extra Rule #9) • • • • • • •

E10 (Extra Rule #10) • • • • • •

E11 (Extra Rule #11) • • • • • •

E12 (Extra Rule #12) • • • • • •

E13 (Extra Rule #13) • • • • • •

G1 (General Rule #1) • • • • • •

G2 (General Rule #2) • • • • • •

G3 (General Rule #3) • • • • • •

G4 (General Rule #4) • • • • • •

G5 (General Rule #5) • • • • • •

G6 (General Rule #6) • • • • • •

G7 (General Rule #7) • • • • • •

G8 (General Rule #8) • • • • • •

G9 (General Rule #9) • • • • • •

G10 (General Rule #10) • • • • • •

G11 (General Rule #11) • • • • • •

G12 (General Rule #12) • • • • • •

K1 (EDT Rule #1) •








Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t




















P1 (Procedure Rule #1) through P29(Procedure Rule #29)

• • • • • •

P30 (Procedure Rule #30) • • • • • •

P31 (Procedure Rule #31) • • • • • •

P32 (Procedure Rule #32) • • • • • •

P33 (Procedure Rule #33) • • • • • •

P34 (Procedure Rule #34) throughP46 (Procedure Rule #46)

• • • • • •

P47 (Procedure Rule #47) • • • •


Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t



August 2006



















S1 (Scannability Rule #1) • • •




T1 (Trace Rule #1) • • • • • •

T2 (Trace Rule #2) • • • • • • •

T3 (Trace Rule #3) • • • • • • •

T4 (Trace Rule #4) • • • • • • •


Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t



T5 (Trace Rule #5) • • • • • • •

T6 (Trace Rule #6) • • • • • • •

T7 (Trace Rule #7) • • • • • • •

T8 (Trace Rule #8) • • • •

T9 (Trace Rule #9) • • • • • •

T10 (Trace Rule #10) • • • •

T11 (Trace Rule #11) • • • • • • •

T12 (Trace Rule #12) • • • • • •

T13 (Trace Rule #13) • • • •

T14 (Trace Rule #14) • • • •

T15 (Trace Rule #15) • • • •

T16 (Trace Rule #16) • • • • • •

T17 (Trace Rule #17) • • • • • •

T18 (Trace Rule #18) • • • • • •

T19 (Trace Rule #19) • • • • • •

T20 (Trace Rule #20) • • • • • •

T21 (Trace Rule #21) • • • •

T22 (Trace Rule #22) • • • •

T23 (Trace Rule #23) • • • •

W1 (Timing Rule #1) • • • •








Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t



August 2006



W10 (Timing Rule #10) • • • •

W11 (Timing Rule #11) • • • •

W12 (Timing Rule #12) • • • •

W13 (Timing Rule #13) • • • •

W14 (Timing Rule #14) • • • •

W15 (Timing Rule #15) • • • •

W16 (Timing Rule #16) •

W17 (Timing Rule #17) • • • •

W18 (Timing Rule #18) • • • •

W19 (Timing Rule #19)

W20 (Timing Rule #20) • •













Rule Violation Id.

DF

TA

dvi

sor

Fas

tSca

n

Fle

xTes

t

Tes

tKo

mp

ress

DF

TIn

sig

ht

BIS

T-R

ead

yL

BIS

TA

rch

itec

t

Fau

lt S

imL

BIS

TA

rch

itec

t

Design Rules CheckingFastScan Rules Checking


FastScan Rules CheckingFastScan performs extensive rules checking. Assuming your design has circuitry that requires it,FastScan performs rules checking for all rule types, except EDT rules. All the information in thesection “The Design Rules” applies to FastScan.

DFTAdvisor Rules CheckingPrior to scan insertion, DFTAdvisor performs limited rule checks on the design as you switchfrom Setup to Dft modes. Part of the checking it does is scannability checking. For moreinformation, refer to Scannability Rules (S Rules).

For primary clock inputs gated by other logic, a test procedure file describes the logicconditions that permit propagation of the clock signal through these gates. For uncontrollableclock circuitry, DFTAdvisor can assist you in modifying your circuit by inserting test logiccircuitry at these clock nodes whenever necessary. Refer to “Enabling Test Logic Insertion” inthe Scan and ATPG Process Guide for details.

If you specify existing scan circuitry, or if you have a test procedure file that sets up conditionsto allow some state elements to be scan candidates, DFTAdvisor performs more extensivechecking. After you add scan circuitry to your design and generate or write a test procedure file,you should go back to Setup mode and specify this information. Then you can return to Dftmode and perform extensive rules checking within DFTAdvisor, before using FastScan orFlexTest.

FlexTest Rules CheckingFlexTest performs all categories of checks except for RAM and BIST rules.

TestKompress Rules CheckingTestKompress performs extensive rules checking. Assuming your design has circuitry thatrequires it, TestKompress performs rules checking for all rule types. All the information in thesection “The Design Rules” applies to TestKompress.


Design Rules CheckingTroubleshooting Rules Violations

August 2006

Troubleshooting Rules ViolationsThis section provides useful information about handling design rules violations. Forinformation on specific rules violations, refer to “The Design Rules”.

Setting the Handling of RulesSome rules permit user-defined handling, allowing you to specify either error, warning, note, orignore as the handling for certain rules. To specify the handling of a specific rule, you issue theSet Drc Handling command at the Setup system mode prompt. This command’s usage is asfollows:

SET DRc Handling drc_id... [Error | Warning | NOTe | Ignore] [Verbose | NOVerbose][Atpg_analysis | NOAtpg_analysis] [-Mode A] [-Interval number] [ATPGC]

The following list describes the types of rule violation handling and their effective actions:

• Error - The rule checker displays the error occurrence message and immediatelyterminates rules checking.

• Warning - The checker displays the warning message and indicates the number ofviolations for that rule. If you selected the verbose option, it gives the warning messagefor each rules violation.

• Note - The checker displays the summary message, indicating the number of violationsfor that rule. If you selected the verbose option, it gives the occurrence message for eachrules violation.

• Ignore - The checker does not display a message for rules violations. However, it stillmust check certain rules for downstream processes.

The Verbose option tells the rules checker to print additional information for each violation.Noverbose is the default operation. The next section, “Turning on ATPG Analysis,” providesmore discussion of the ATPG_analysis option. Noatpg_analysis is the default operation formost rule types. The ATPGC option considers all current ATPG constraints when checkingrules C1, C3, C4, C5, C6, E10, and E11. For more information on the options of this command,refer either to the Set Drc Handling reference page in the ATPG and Failure Diagnosis ToolsReference Manual or to the Set Drc Handling reference page in the DFTAdvisor ReferenceManual.

Turning on ATPG AnalysisThe Atpg_analysis option to the Set Drc Handling command provides full test generationanalysis during rules checking for clock rules C1, C3, C4, C5, C6, some D rules and some Erules (such as E4, E5, E8, E10, E11 and E12). For example, assume you select Atpg_analysisfor clock rule C1 and the tool simulates a clock input to be X. The rule violation occurs when



the atpg_analysis determines that it is, or may be, possible to turn the clock input on when allother defined clocks are off, and constrained pins are at their constrained values.

NoteWhen you turn on ATPG analysis, be aware that the rules checking process requiresadditional CPU time and memory.

Setting the Level of Gate DataThe tools can report data at different levels; therefore, you should specify the level ofinformation before you issue the Report Gate command. You do this with the Set Gate Levelcommand. Setting the gate level to design (the default) reports information at the design cell(library model) level. Figure 2-1 depicts a scannable-equivalent DFF cell library model at thedesign level.

Figure 2-1. Example of Design Level

Setting the gate level to low_design reports information at the lowest level of library cells.Figure 2-2 depicts the sdff1 library model at the low_design level

Figure 2-2. Example of Low_Design Level

If the gate level is set to design or low_design, the Report Gate command displays the followinginformation:

instance_name cell_type input_pin_name I (data) pin_pathname ... input_pin_name I (data) pin_pathname ... . . . input_pin_name 0 (data) pin_pathname ...

d

sc_in

sc_en

clk

q

sc_out

sdff1

sdff1

a

b

s

o d

ck

qd

sc_in

sc_enclk

qsc_out

mux1 dff1



August 2006

Setting the gate level to primitive reports information at the simulation gate level. Figure 2-3depicts the sdff1 library model at the primitive level.

Figure 2-3. Example of Primitive Level

If you set the gate level to primitive, the Report Gate command displays the followinginformation:

instance_name (gate_id#) gate_type input_pin_name I (data) gate_id#-pin_pathname ... input_pin_name I (data) gate_id#-pin_pathname ... . . .

input_pin_name 0 (data) gate_id#-pin_pathname...

Setting the Gate Information TypeThe Set Gate Report command specifies the type of information that you want to appear whenyou report gate data with the Report Gate command. The multitude of options this commandsupports varies somewhat depending on which tool you are using. The common usage of the SetGate Report command is:

SET GAte REport {Normal | Trace | Error_pattern | TIe_value |Constrain_value | {Drc_pattern procedure_name [time | -All]}

o The Trace option displays the values of the gates obtained during scan chain tracing.That is, this option displays data obtained on an error condition (not warning) duringsimulation of the shift procedure. You can use this option to help determine why ascan chain was not properly sensitized.

o The Error_pattern option displays the simulated values of the gate and its inputs, forthe pattern (event) that had an error. This option displays such information as celldisturbances during the load_unload procedure or bus contention problems.

o The Normal option is the default. It displays only standard connectivity data.

sdff1

A

B

CTL

OD0

SETQN

d

sc_in

sc_enclk

qsc_outCK0

RST

Q

BUF(_buff)

TIE0

DFF1MUX1 (_dff)(_mux)

(_tie0)



o The Drc_pattern option displays an identified procedure’s simulated gate valuesduring the designated time. This option is similar to the Trace option, but is moreversatile because it allows access to the data obtained from simulation of any of thetest procedures.

o The Parallel_pattern option displays simulated values for a selected pattern in thelast simulation pass. A “pattern” is any time event that occurs during the testprocedure. When the ATPG tool encounters problems in generating patterns, youcan access the simulation data with this option.

For information on all the available options or tool-specific uses of this command, refer either tothe Set Gate Report reference page in the ATPG and Failure Diagnosis Tools ReferenceManual or to the Set Gate Report reference page in the DFTAdvisor Reference Manual.

Reporting Gate DataIf you encounter rules violations when you attempt to exit the Setup mode, you may need moreinformation about specific gates in the design for troubleshooting purposes. While the violationmessage may give some information as to the location of the problem, you may need to trackdown the source of the problem by reporting on a sequence of gates in the design. Report Gatesis a very powerful command you can use to report on netlist data.

The following subsections show how to use Report Gates to display various types ofinformation for troubleshooting purposes. For more information on this command, refer eitherto the Report Gates reference page in the ATPG and Failure Diagnosis Tools Reference Manualor to the Report Gates reference page in the DFTAdvisor Reference Manual.

You can usually report gate data using the schematic viewing tool, DFTInsight.

Reporting on a Specific GateYou can use the Report Gates command to display information for selected gates, which youidentify by either a gate index number or a pin pathname of a pin connected to the gate. Thiscommand reports the gate name, its gate type, and its connectivity to other gates. For example,to use Report Gates in this manner, you could specify:

SETUP> REPort GAtes 74493

Figure 2-4 shows a report with primitive-level information for a gate with an ID number of74493



August 2006

Figure 2-4. Data Reported for a Specific Gate

Reporting on All Gates of a Specified TypeYou can use Report Gates to report on all gates of a specified type. The Report Gates usage forthis case is:

REPort GAtes {-Type gate_type}...

The supported gate types are those listed as simulation primitives in the “Simulation Primitivesof the Flattened Model” section of the Scan and ATPG Process Guide.

The following example shows how to report on all TIE0 gates.

SETUP> rep ga -t tie0

// --------------------------------------------------------// List of TIE0 gates// --------------------------------------------------------// /u1/inst__565_ff_d_0__dff (13) TIE0// "OUT" O 267- 266-// /u1/inst__565_ff_d_1__13 (14) TIE0// "OUT" O 269- 268-// /u1/inst__565_ff_d_2__13 (15) TIE0// "OUT" O 271- 270-// Total number of tie0 gates = 3

Reporting a Histogram of All Gate TypesYou can use Report Gates to show a distribution (histogram) of all gates in the design. To useReport Gates in this manner, specify:

SETUP> report gates -type Histogram

The following example shows the type of data this command displays.

SETUP> rep ga 74493// /b5/u12.u1_0_M (74493) LA-IH// “S” I (000) 11426-// “R” I (000) 6694-// “C0” I (000) 36060-// d I (XXX) 53753-/b2/u4/Y// scnck I (010) 28049-/b5/BOS595/CK2// sd I (XXX) 11775-/b5/u12.u1_1_S/q// “OUT” O (XXX) 11427-// MASTER cell_id=0 chain+c1 group=g1 invert_data=FFFF

Instance Name Gate ID# Learned Behavior (Inactive High Latch)

Connectivity Data

Scan Chain Data

Pin Names Pin TypesPin Data



// --------------------------------------------------------// List of histogram of gates// --------------------------------------------------------// BUF=175 INV=30 AND=3 NAND=17 OR=7 NOR=5 XOR=2 LA=14// PI=12 PO=7 TIE0=7 MUX=7

Reporting on a Path Between Two GatesYou can also use Report Gates to display information on the circuitry between two specifiedgates. To use Report Gates in this manner, specify:

SETUP> report gates -path <gate1_ID#> <gate2_ID#>

Reporting on the First Input of a GateReport Gates can display data on the gate connected to the first input of the previously reportedgate. This lets you quickly and easily trace backward through circuitry. To use Report Gates inthis manner, first report on a specific gate and then enter:

SETUP> b

The following example shows how to use Report Gate and B to trace backward through the firstinput of the previously reported gate.

SETUP> rep gate 26

// /u1/inst__565_ff_d_1__13 (26) BUF// "I0" I 269-// "OUT" O 268- 75-

SETUP> b

// /u1/inst__565_ff_d_1__13 (269) LA// "S" I 14-// "R" I 145-// SCLK I 4-/clk// D I 265-/u1/_g32/X// ACLK I 2-/scan_mclk// SDI I 20-/u1/inst__565_ff_d_0__dff/Q2// "OUT" O 26- 27-

SETUP> b

// /u1/inst__565_ff_d_1__13 (14) TIE0// "OUT" O 269- 268-

Reporting on the First Fanout of a GateSimilar to tracing backward through circuitry, you can also trace forward through the firstfanout of the previously reported gate. To use Report Gates in this manner, first report on aspecific gate and then enter:

SETUP> f



August 2006

The following example shows how to use Report Gate and F to trace forward through the firstfanout of the previously reported gate.

SETUP> rep ga 269

// /u1/inst__565_ff_d_1__13 (269) LA// "S" I 14-// "R" I 145-// SCLK I 4-/clk// D I 265-/u1/_g32/X// ACLK I 2-/scan_mclk// SDI I 20-/u1/inst__565_ff_d_0__dff/Q2// "OUT" O 26- 27-

SETUP> f

// /u1/inst__565_ff_d_1__13 (26) BUF// "I0" I 269-// "OUT" O 268- 75-

SETUP> f

// /u1/inst__565_ff_d_1__13 (268) LA// "S" I 14-// "R" I 145-// BCLK I 1-/scan_sclk// "D0" I 26-// "OUT" O 24- 25-

Related CommandsReport Drc Rules - displays data associated with violated rules.Set Trace Report - displays all scan chain gates traced during rules checking.

Flattening Rule ViolationsIf you encounter flattening rule violations, you can use the Report Flatten Rules command todisplay either a summary of the flattening rule violations or the data for a specific violation, fortroubleshooting purposes. For more information on this command, refer either to the ReportFlatten Rules reference page in the ATPG and Failure Diagnosis Tools Reference Manual or tothe Report Flatten Rules reference page in the DFTAdvisor Reference Manual.

You can use the Set Flatten Handling command to change the handling of the net, pin, and gaterules. For more information on this command, refer either to the Set Flatten Handling referencepage in the ATPG and Failure Diagnosis Tools Reference Manual or to the Set FlattenHandling reference page in the DFTAdvisor Reference Manual.

Design Rules CheckingThe Design Rules


The Design RulesThis section lists and describes all the rules checked in each of the major rules categories:general rules, procedure rules, scan chain trace rules, scan cell data rules, clock rules, RAMrules, BIST rules, timing rules, extra rules, and scannability rules. There is also a sectionincluded for various Vector Interfaces warning and error messages.

Many error messages will be accompanied by a line number and file name to help you resolvethe error condition. However, some error messages may relate to problems with internallygenerated data, and will not have a line number and file name to report. In cases where it ispossible to identify this information, the following informational message will accompany theerror message to report the file name and line number:

The following occurred at line L in file F.

L is the line number and F is the file_name. For example, a syntax error (P1) in a test procedurefile would produce the following two messages:

The following occurred at line 10 in file testprocSyntax error in line number 10. (P1-1)

General Rules (G Rules)At the beginning of the rules checking, the tool runs general rules checks to find inconsistenciesin scan data and other definitions. All violations of general rules generate error conditions andyou cannot change the handling of these rules. The following subsections describe each of thegeneral rules.

G1 (General Rule #1)Each defined scan chain group, except for “dummy”, must contain at least one scan chain. Youcan correct this error condition by either adding a scan chain to the group or by deleting the scanchain group. The error message is:

No scan chains have been defined for group N. (G1-1)

N is the name of the scan chain group, and G1-1 indicates the rule and violation ID numbers.

G2 (General Rule #2)If you define scan chains and do not use the “dummy” scan chain option, you must define atleast one clock. You can correct this error condition by either defining a clock that controls thedefined scan chains or by deleting all scan chain groups. The error message is:

Scan chains exist but no clocks have been defined. (G2-1)



August 2006

G3 (General Rule #3)If the circuit has no memory elements, you cannot define clocks. You can correct this errorcondition by deleting all clocks. The error message is:

Clocks are defined but no memory elements exist in the circuit. (G3-1)

G4 (General Rule #4)If the circuit has no memory elements, you cannot define scan chain groups. You can correctthis error condition by deleting all scan chain groups. The error message is:

Scan groups are defined but no memory elements exist in the circuit. (G4-1)

G5 (General Rule #5)If there are no RAMs in the circuit, you cannot define write control lines. You can correct thiserror condition by deleting all write control lines. The error message is:

Write controls are defined but no RAMs exist in the circuit. (G5-1)

G6 (General Rule #6)If you define a linear feedback shift register (LFSR), you cannot use the “dummy” scan chainoption. You can correct this error condition by either deleting all LFSRs or deleting the dummyscan chain group. The error message is:

Cannot use dummy scan chain with BIST LFSRs. (G6-1)

G7 (General Rule #7)The RAM/ROM instance name given on a preceding Read Modelfile command must contain asingle RAM or ROM gate. You can correct this error condition by using the correct RAM orROM instance name for the Read Modelfile command. Or, you can do nothing and re-invokethe rules checker, in which case, the tool will not use a modelfile for the intended RAM orROM. The error message is:

Cannot use RAM/ROM modelfile M for invalid instance N. (G7-1)

M is the modelfile name, N is the instance name, and G7-1 indicates the rule and violation IDnumbers.

G8 (General Rule #8)All ROM gates must have a defined initialization file, unless you use the random initializationoption. You can correct this error condition by: specifying a modelfile in the model cell library,



using the Read Modelfile command to specify a modelfile, using random initialization, orchanging the model cell library to treat the ROM gate as undefined. The error message is:

ROM initialization file not defined for N (G). (G8-1)

N is the instance name of the ROM, G is the gate ID number, and G8-1 indicates the rule andviolation ID numbers.

G9 (General Rule #9)For all constrained scan cells identified by chain and position, the scan chain must be a validscan chain, the position must be less than the length of the chain, and the scan cell must not bethe same as another constrained scan cell. You can correct this error by identifying andcorrecting all invalid scan cell constraints. The error message is:

Invalid cell constraint position P for chain C. (G9-1)

P is the cell position number (0-based, where 0 is the scan cell closest to the scan-out pin), C isthe scan chain name, and G9-1 indicates the rule and violation ID numbers.

G10 (General Rule #10)For all constrained scan cells identified by pin pathname, the pin must be a valid output pin of acell, the pin must connect to a scan memory element through a path that only contains buffersand inverters, and the scan cell must not be the same as another constrained scan cell. To correctthis error, you must identify and correct all invalid scan cell constraints. The error message is:

Invalid cell constraint pin name P. (G10-1)

P is the pin pathname of an output pin of a cell, and G10-1 indicates the rule and violation IDnumbers.

G11 (General Rule #11)If you define a “dummy” scan chain group with a test procedure file, you cannot define any scanchains. The purpose of the dummy scan group is to provide the ability to use a test_setupprocedure when no scan cells exist. To correct this error (if scan cells do exist), you shouldplace the test_setup procedure in the test procedure file for a defined scan chain group. Theerror message is:

Scan chains may not be defined when using dummy scan group procedure file.(G11-1)

G12 (General Rule #12)General rule #12 reports Add Cone Blocks command pin-pathname violations because theirchecking is delayed until DRC is performed.



August 2006

Procedure Rules (P Rules)The tool checks the test procedure file for each scan chain group to ensure adherence to theformat rules and correctness of the test procedure data. It treats all violations of procedure rulesas error conditions and you cannot change the handling of these rules—with the exception ofrules P30, P31, P32, and P33, which you can change to “ignore”. The following subsectionsdescribe each of the procedure rules. For procedure rules specific to the enhanced procedurefile, see “Test Procedure File”.

P1 (Procedure Rule #1)Each statement in the test procedure file must have the proper syntax. A syntax error occurs fora statement if there is an incorrect number of arguments or an incorrect ending character (“=”for procedure statements and “;” for all other statements). You can correct this error conditionby editing the indicated line of the test procedure file. The error message is:

Error: syntax error near token (Token). (P1)

Where Token represents the token in the input file close to where the error occurred.

P2 (Procedure Rule #2)For statements inside a procedure, the time of the statement must not be less than the time of apreceding statement. You can correct this error condition by editing the time value on theindicated line of the test procedure file. The error message is:

Time value T less than preceding time value. (P2)

Where T is the time defined in the specified statement.

P3 (Procedure Rule #3)For statements inside a procedure, the time of an apply procedure statement must be greaterthan the preceding statement. You can correct this error by editing the time value on theindicated line of the test procedure file. The error message is:

Line number L, time value not greater than preceding time value for applyprocedure. (P3-1)

L is the line number in which the failure occurred.

P4 (Procedure Rule #4)All procedures must end with an end statement. To correct this error condition, add an endstatement at the indicated line of the test procedure file. The error message is:

Line number L, P procedure not ended. (P4-1)



L is the line number in which the failure, occurred and P is the procedure name.

P5 (Procedure Rule #5)Procedure definitions follow the syntax, procedure proc_type [proc_name] = …. For mostprocedures, the procedure name is optional and it is ignored. Procedures of typeseq_transparent, clock, and sub_procedure require a name. This error occurs if one of theseprocedures is missing its name. Also, this error occurs if the user tries to define more than 32clock or seq_transparent procedures.

Incorrect or missing name for procedure of type P. (P5)

Where P represents the procedure type that the error occurred on. Unknown procedure types donot cause a P1 violation.

P6 (Procedure Rule #6)You may define a procedure only once in a single test procedure file. You can correct this errorcondition by deleting the duplicated procedure at the indicated line of the test procedure file.The error message is:

Duplicate procedure P. Original procedure from file F. (P6)

Where F is the file that the first occurrence of the procedure P was found in.

P7 (Procedure Rule #7)Statements (except the procedure statement) can only execute when a procedure definition isstill active. To correct this error condition, add a procedure statement prior to the indicated lineof the test procedure file. The error message is:

Line number L, no active procedure for S statement. (P7-1)

L is the line number in which the failure occurred, and S is the type of statement.

P8 (Procedure Rule #8)The load_unload procedure must contain an apply shift statement. To correct this errorcondition, add an apply shift statement at the appropriate place in the load_unload procedureof the test procedure file. The error message is:

Line number L, no apply shift in load_unload procedure. (P8-1)

L is the line number of the end of the load_unload procedure.



August 2006

P9 (Procedure Rule #9)The shift procedure must contain a force_sci statement. To correct this error condition, add aforce_sci statement at the appropriate place in the shift procedure of the test procedure file. Theerror message is:

Line number L, no force_sci in shift procedure. (P9-1)

L is the line number of the end of the shift procedure.

P10 (Procedure Rule #10)The shift procedure must contain a measure_sco statement. To correct this error condition, adda measure_sco statement at the appropriate place in the shift procedure of the test procedurefile. The error message is:

Line number L, no measure_sco in shift procedure. (P10-1)

L is the line number of the end of the shift procedure.

P11 (Procedure Rule #11)If you define a period for a procedure, then the period time must not be less than the time of thelast procedure event. To correct this error condition, increase the period time for the indicatedprocedure. The error message is:

Period T for P is less than time of last statement. (P11)

T represents the period, and P specifies the name of the procedure or the procedure type if it hasno name.

P12 (Procedure Rule #12)The pin name you use as an argument for the force statement must be a valid pin name of aprimary input. To correct this error condition, edit the pin name on the indicated line of the testprocedure file. The error message is:

The following occured at T, incorrect pin name P. (P12-1)

Where T represents the token in the input file near to where the error occurred and P is the pinname.

P13 (Procedure Rule #13)For the force statement, you may only use the force values “0”, “1”, “X”, and “Z”. To correctthis error condition, edit the force value on the indicated line of the test procedure file. The errormessage is:



The following occured at T, incorrect force value V. (P13-1)

Where T represents the token in the input file near to where the error occurred and V is theincorrect value.

P14 (Procedure Rule #14)You may only use the force_sci statement in the shift procedure. To correct this error condition,delete the force_sci statement on the indicated line of the test procedure file. The error messageis:

Line number L, force_sci only allowed in the shift procedure. (P14-1)


P15 (Procedure Rule #15)You may only use the force_sci statement once in the shift procedure. To correct this errorcondition, delete the force_sci statement on the indicated line of the test procedure file. Theerror message is:

Line number L, duplicate force_sci statement. (P15-1)


P16 (Procedure Rule #16)You may only use the measure_sco statement in the shift procedure. To correct this errorcondition, delete the measure_sco statement on the indicated line of the test procedure file. Theerror message is:

Line number L, measure_sco only allowed in the shift procedure. (P16-1)


P17 (Procedure Rule #17)You may only use the measure_sco statement once in the shift procedure. To correct this errorcondition, delete the measure_sco statement on the indicated line of the test procedure file. Theerror message is:

Line number L, duplicate measure_sco statement. (P17-1)




August 2006

P18 (Procedure Rule #18)You may only use the apply statement in the load_unload procedure. To correct this errorcondition, delete the apply statement on the indicated line of the test procedure file. The errormessage is:

Line number L, apply only allowed in load_unload procedure. (P18-1)


P19 (Procedure Rule #19)You cannot have two apply shift statements with a repeat count on them in the load_unloadprocedure. The error message is:

Line number L, duplicate apply shift statement. (P19-1)

L is the line number in which the failure occurred and P19 is the rule ID number.

NoteAdditional apply shift statements are allowed only with a count of one. These arereferred to as 1-shift, or independent shift, statements.

P20 (Procedure Rule #20)You may only use the apply shadow_control statement in the load_unload procedure. Tocorrect this error condition, select the apply shadow_control statement on the indicated line ofthe test procedure file. The error message is:

Line number L, duplicate apply shadow_control statement. (P20-1)


P21 (Procedure Rule #21)The apply shadow_control statement may only be used immediately after the apply shiftstatement. To correct this error condition, move the apply shadow_control statement from itscurrent position on the indicated line of the test procedure file to the position following theapply shift statement. The error message is:

Line number L, apply shift must precede apply shadow_control. (P21-1)




P22 (Procedure Rule #22)You must set the number of repetitions for the apply shadow_control statement to 1. Tocorrect this error condition, change the repetition argument of the apply shadow_controlstatement on the indicated line of the test procedure file to the value of 1. The error message is:

Line number L, repetitions for apply shadow_control must be 1. (P22-1)


P23 (Procedure Rule #23)You may only use the apply statement for the shift and shadow_control procedures. To correctthis error condition, delete the apply statement on the indicated line of the test procedure file.The error message is:

Line number L, apply procedure P not allowed. (P23-1)

L is the line number in which the failure occurred and P is the procedure name.

P24 (Procedure Rule #24)The only allowed command names are procedure, force, force_sci, measure_sco, apply,period, initialize, and end. Correct this error condition by editing the statement on the indicatedline of the test procedure file. The error message is:

Line number L, incorrect command name C. (P24-1)L is the line number in which the failure occurred and C is the command name.

P25 (Procedure Rule #25)You may only use the initialize command at time 0 of the test_setup procedure. Correct thiserror condition by moving the statement, on the indicated line of the test procedure file, to thebeginning of the test_setup procedure. The error message is:

Line number L, initialize command can only be used at time 0 oftest_setup procedure. (P25-1)


P26 (Procedure Rule #26)The instance name argument for the initialize statement must correspond to at least one latch orflip-flop gate. Correct this error condition by editing the statement on the indicated line of thetest procedure file. The error message is:

Line number L, incorrect instance name N. (P26-1)

L is the line number in which the failure occurred and N is the instance name.



August 2006

P27 (Procedure Rule #27)The only allowed force values for a clock pin are 0 and 1. Correct this error condition bychanging the force value of the statement on the indicated line of the test procedure file. Theerror message is:

Line number L, clock C may not be force to a V. (P27-1)

L is the line number in which the failure occurred, C is the clock pin name, and V is theincorrect value.

P28 (Procedure Rule #28)The only allowed force value for a write control pin is its defined off-state value, unless it is alsodefined as a clock. Correct this error condition by changing the force value of the statement onthe indicated line of the test procedure file. The error message is:

Line number L, write control W may not be forced to a V. (P28-1)

L is the line number in which the failure occurred, W is the write control pin name, and V is theincorrect value.

P29 (Procedure Rule #29)All clocks must be at their off-state prior to any pattern which places a clock line at an on-state.Correct this error condition by changing force statements prior to and including the indicatedline of the test procedure file. The error message is:

Line number L, clock C not at off-state prior to clock_on pattern. (P29-1)

L is the line number in which the failure occurred and C is the clock pin name.

P30 (Procedure Rule #30)A procedure may not place a clock at its on-state at the same time it forces a non-clock pin to avalue or place another clock at its off-state. Correct this error condition by changing forcestatements prior to and including the indicated line of the test procedure file. The rules checkerignores this condition if you set the handling to “ignore” with the Set Drc Handling command.The error message is:

Line number L, clock C cannot be forced on at this time. (P30-1)

L is the line number in which the failure occurred, and C is the clock pin name.



P31 (Procedure Rule #31)A procedure may not force a non-clock pin to a value at the same time it forces a clock pin to avalue. Correct this error condition by changing force statements prior to and including theindicated line of the test procedure file. The rules checker ignores this condition if you set thehandling to “ignore” with the Set Drc Handling command. The error message is:

Line number L, non-clock pin N cannot be forced at this time. (P31-1)

L is the line number in which the failure occurred, and N is the non-clock pin name.

P32 (Procedure Rule #32)A procedure may not place a clock at its off-state at the same time it places another clock at itson-state. Correct this error condition by changing force statements prior to and including theindicated line of the test procedure file. The rules checker ignores this condition if you set thehandling to “ignore” with the Set Drc Handling command. The error message is:

Line number L, clock pin C cannot be forced off at this time. (P32-1)

L is the line number on which the failure occurred, and C is the clock pin name.

P33 (Procedure Rule #33)When a pattern places a clock at its off-state, all clocks must be at their off-state. Correct thiserror condition by forcing the indicated clock to its off-state at the same time as the indicatedline of the test procedure file. The rules checker ignores this condition if you set the handling to“ignore” with the Set Drc Handling command. The error message is:

Line number L, clock C not at off-state at end of clock_off pattern.(P33-1)

L is the line number in which the failure occurred, C is the clock pin name, and P33-1 is the ruleand violation ID number.

P34 (Procedure Rule #34)At the end of all test procedures (except test_setup procedure), all clocks must be at their off-state. Correct this error condition by forcing the indicated clock to its off-state prior to theindicated line of the test procedure file. The error message is:

Line number L, clock C not off at end of P procedure. (P34-1)

L is the line number in which the failure occurred, C is the clock pin name, and P is theprocedure name.



August 2006

P35 (Procedure Rule #35)At the end of the master_observe and shadow_observe procedures, all constrained pins mustbe at their constrained states. The tools assume they are at that state prior to the procedures.Correct this error condition by forcing the indicated pin to its constrained state prior to theindicated line of the test procedure file. The error message is:

Constrained pin L not at constrained value at end of P procedure. (P35-1)

L is the line number in which the failure occurred, and P is the procedure name.

P36 (Procedure Rule #36)The test procedure file must contain a load_unload procedure. Correct this error condition byadding a load_unload procedure to the test procedure file. The error message is:

No load_unload procedure in group procedure file. (P36-1)

P37 (Procedure Rule #37)The test procedure file must contain a shift procedure. Correct this error condition by adding ashift procedure to the test procedure file. The error message is:

No shift procedure in group procedure file. (P37-1)

P38 (Procedure Rule #38)If the test procedure file contains an apply shadow_control statement, the test procedure filemust contain a shadow_control procedure. Correct this error condition by adding ashadow_control procedure to the test procedure file or by deleting the apply shadow_controlstatement. The error message is:

No shadow_control procedure in group procedure file. (P38-1)

P39 (Procedure Rule #39)If the test procedure file contains a shadow_control procedure, the test procedure file must alsocontain an apply shadow_control statement. Correct this error condition by adding an applyshadow_control statement or by deleting the shadow_control procedure in the test procedurefile. The error message is:

Unused shadow_control procedure in group procedure file. (P39-1)

P40 (Procedure Rule #40)If you turn on the skew load option, the test procedure file must contain a skew_load procedure.Correct this error by adding a skew_load procedure to the test procedure file or by turning offthe skew load option with the Set Skewed Load command. The error message is:



Skewed_load may not be used without a skew_load procedure. (P40-1)

P41 (Procedure Rule #41)The values of all pins at the beginning of the shift procedure must be the same as at the end ofthe shift procedure. Correct this error condition by changing force statements in the shift orload_unload procedures. The error message is:

P initial value different from final value in shift procedure. (P41-1)

P is the pin name.

P42 (Procedure Rule #42)Even if there are multiple test procedure files, there can be no more than one test_setupprocedure. Correct this error condition by deleting the extra test_setup procedures. The errormessage is:

Multiple test_setup procedure defined in test procedure files. (P42-1)

P43 (Procedure Rule #43)You must place all write and read control lines at their off-state at time 0 of the load_unloadprocedure. Correct this error condition by adding the appropriate force statements to the testprocedure file or by deleting the write or read control lines. The error message is:

T control N not at off-state at time 0 of load_unload procedure. (P43-1)

T is the type of control (write or read) and N is the name of the control line.

P44 (Procedure Rule #44)You may only place the restore_pis statement at the end of a seq_transparent procedure.Correct this error condition by either removing the statement or by placing it at the end of avalid seq_transparent procedure. The error message is:

Line number L, restore_pis can only be used at the end of theseq_transparent procedure. (P44-1)

L is the test procedure file line number where the error occurred, and P44-1 is the rule andviolation ID number.

P45 (Procedure Rule #45)You may only place the condition statement at the beginning of a seq_transparent procedure.Correct this error condition by either removing the statement or by placing it at the beginning ofa valid seq_transparent procedure. The error message is:



August 2006

Line number L, conditions can only be used at time 0 of seq_transparentprocedures. (P45-1)

L is the test procedure file line number where the error occurred, and P45-1 is the rule andviolation ID number.

P46 (Procedure Rule #46)The condition statement must identify a pin pathname that connects to the output of a scan stateelement. The path between the two points can only contain buffers and inverters. Correct thiserror condition by either removing the condition statement or by correcting the pin pathnameThe error message is:

Invalid condition for nonscan cell N (G) during procedure P. (P46-1)

N is the name of the non-scan cell, G is the gate ID number, P is the seq_transparent procedurename, and P46-1 is the rule and violation ID number.

P47 (Procedure Rule #47)The statement mentioned is not allowed to be used in the type of procedure that isnamed. For example, it is not legal to have a measure statement in a load_unloadprocedure.

Statement S can not be used in P procedure. (P47)

Where S is the statement, and P is the name of the procedure.

P48 (Procedure Rule #48)The “set strobe_window time” command specifies a bad value for the strobe_window time.

Negative or zero strobe window specified. (P48)

P49 (Procedure Rule #49)The Set Time Scale command specifies a bad time value.

Negative or zero value specified for the time scale. (P49)

P50 (Procedure Rule #50)The pulse width value for the named pulse statement in a named procedure or timeplate is zeroor negative. This message can appear for either timeplates or procedures, and will use either theword “timeplate” or “procedure”.

Negative or zero pulse width for S specified in [ timeplate | procedure ]P. (P50)



Where S is the pulse statement, and P is the procedure name.

P51 (Procedure Rule #51)The named statement occurs more than once in the named timeplate. For example,forcing the same pin twice in a timeplate is not allowed. Pulsing a clock more than once in asingle timeplate is also not allowed.

Duplicate S statement in timeplate T. (P51)

Where S is the statement that occurs more than once, and T is the timeplate.

P52 (Procedure Rule #52)A pulse statement was used with a pin name which is not a clock pin. This message can alsoappear for either timeplates or procedures.

Non-clock pin P cannot be pulsed in [ timeplate | procedure ] S. (P52)Where P is the pin name, and S is the timeplate or procedure.

P53 (Procedure Rule #53)The named timeplate does not specify a pulse statement required by one of the procedureswhich uses this timeplate. For example, if a ram_sequential procedure contains apulse_read_clock statement, but the timeplate that the procedure uses does not contain a pulsestatement for any read clock, this warning will be issued. You can correct this warning byadding pulse statements for all needed clocks in the timeplate definitions.

No clock pulse timing in timeplate T which matches event E in procedure P,two cycle clock pulses will be used. (P53)

Where T is the timeplate statement, E is the pulse event, and P is the procedure.

NoteA P53 warning will not cause the Vector Interfaces outputs to create incorrect patterns,just larger patterns. During pattern output, if a timeplate does not contain a needed clockpulse statement, the clock pulse will be created by using two cycles and the force_pi timeof the timeplate.

P54 (Procedure Rule #54)Some statement has referenced a name that is not defined. For example, using the“timeplate” statement in a procedure to reference a timeplate that has not yet beendefined. Or, using the “force” statement on a pin name that the ATPG tool cannot find.

Undefined identifier N referenced by S. (P54)



August 2006

Where N is the undefined name and S is the statement referring to N.

P55 (Procedure Rule #55)This error message indicates that an old procedure type of statement is used within a cycle-based procedure, or that a cycle-based procedure statement is used in an old style procedure. Forexample, it would be illegal to put a break_repeat statement in a procedure that uses timeplatesand cycles; put a force statement with a time value in a cycle-based procedure; or use oldprocedure statements in a new procedure (for example, the capture procedure).

Illegal mix of time based and cycle based statements in procedure P. (P55)

Where P is the procedure name.

P56 (Procedure Rule #56)The named timeplate or procedure is empty. If it is a procedure, it has no statements, includingno timeplate references.

[ Timeplate | Procedure ] S has no statements. (P56)

Where S is the named timeplate or procedure.

P57 (Procedure Rule #57)Either a timeplate or an old style, time-based procedure is missing its period statement. Theperiod statement is not needed in cycle-based procedures.

[ Timeplate | Procedure ] S has no period statement. (P57)

Where S is the named timeplate or procedure.

P58 (Procedure Rule #58)The time specified for a break_repeat statement is too small to be useful, for example, it is equalto one or less.

Break_repeat time value T is to small in procedure P. (P58)

Where T is a number, and P is the name of the procedure in which T resides.

P59 (Procedure Rule #59)The “set time scale” statement in a procedure file specifies a different time scale then what wasalready specified in the same file or a previously parsed file. All files must specify the sametime scale.

New time scale does not match previous time scale. (P59)



P62 (Procedure Rule #62)In a definition statement, the identifier N has already been used in a previous definition. Forexample, if there is a pin name in the design called “GROUP1” and there is an “alias” statementwhich tries to define an alias called “GROUP1”, the user will receive the following P62message, “Alias name GROUP1 already in use as pin name.”

X name N already in use as Y. (P62)

Where X is the type of definition, and Y is the previous definition type.

P63 (Procedure Rule #63)Only one occurrence of a pin is allowed in an alias statement. Pin P occurs more than once inthe current alias statement.

Duplicate pin P in alias statement. (P63)

P64 (Procedure Rule #64)Pin P has a direction (input, output, bidirectional) that is not compatible with statement S.

Direction of pin P is not compatible with S statement. (P64)

For example, the following occurrence message:

Direction of pin Out1 is not compatible with force statement. (P64)Out1 is an output pin in the netlist that is not compatible with a force statement.

P65 (Procedure Rule #65)A duplicate statement S has been found in procedure P. The tool will ignore the first occurrenceof this statement. A duplicate statement is one that occurs at the same time and on the same pin(if applicable) as a previous statement.

For example, if a statement in a procedure causes pin “A” to be forced to a zero at time zero, andthen a subsequent statement causes pin “A” to be forced to a one at time zero, the user willreceive a P65 message and the first force statement will be ignored.

Duplicate S statement in procedure P, first statement being ignored. (P65)

S is the either just the event type or the event type and pin name when needed. P is theprocedure type.



August 2006

P70 (Procedure Rule #70)Alternate (named) shift procedures cannot be applied with a repeat count greater than one.

Alternate shift procedure name is applied with a repeat count greaterthan one. (P70)

Scan Chain Trace Rules (T Rules)Using the information in the test procedure files, the rules checker traces the scan chains toidentify the scan cells and all memory elements associated with the scan cells. It then classifiesthe scannable memory elements as either MASTER, SLAVE, SHADOW, COPY, or EXTRA.Violations of scan chain trace rules are error or warning conditions, and you cannot change thehandling of these rules—with the exception of rule T18, which you can set to ignore. Thefollowing subsections describe each of the trace rules.

T1 (Trace Rule #1)All defined scan chains must contain at least one scan cell. Correct this error condition bydeleting the indicated scan chains. The error message is:

No scan cells identified in scan chain C. (T1-1)

C is the scan chain name.

T2 (Trace Rule #2)A scannable memory element may not reside in more than one scan chain. You can display thecomplete paths of the scan chains by using the Set Trace Report command by turning tracereporting on and then repeating the rules checking. If you use all scan chains, you may need tomake netlist modifications to correct this error condition.

The error message is:

N (G) already used in chain trace. (T2-1)

N is the instance name, and G is its gate ID number.

T3 (Trace Rule #3)The shift procedure must create a sensitizable path from the scan chain output back to the scanchain input. An improperly sensitized gate in the scan path will cause an error condition.Correct this error condition by accessing the simulated values of all time periods of the shiftprocedure. To do this, set the gate reporting to trace, and use the Report Gate command for thegate ID number displayed in the error message. This can help you to identify where theblockage occurs; tracing back from the inputs helps you identify how to correct the problem.The error message is:



Scan chain blocked at gate N (G) after tracing C cells. (T3-1)

N is the instance name, G is its gate ID number, and C is the number of scan cells traced in thescan chain.

T4 (Trace Rule #4)A memory element in the scan path must have an active clock during some time period of theshift procedure. Correct this error condition by accessing the simulated values of all timeperiods of the shift procedure. You do this by setting the gate reporting to trace and using theReport Gate command for the gate ID number displayed in the error message. This can help youidentify where the problem occurred; tracing back from the inputs helps you identify how tocorrect the problem. The error message is:

Clock inputs of N (G) never set active during shift procedure. (T4-1)

N is the instance name and G is its gate ID number.

T5 (Trace Rule #5)During the shift procedure, you must never place an X value on a clock input or an active (X or1) value on a set or reset input of a memory element in the scan path. Correct this errorcondition by accessing the simulated values of all time periods of the shift procedure. You dothis by setting the gate reporting to trace and using the Report Gate command for the gate IDnumber displayed in the error message. This can help you identify where the problem occurred;tracing back from the indicated input helps you identify how to correct the problem. The errormessage is:

T input of N (G) set to V. (T5-1)

T is the type of input (clock, set, or reset), N is the instance name, G is its gate ID number, andV is the invalid state.

T6 (Trace Rule #6)During any time period of the shift procedure, a memory element in the scan path must neverhave more than one clock input turned on. Correct this error condition by accessing thesimulated values of all time periods of the shift procedure. You do this by setting the gatereporting to trace and using the Report Gate command for the gate ID number displayed in theerror message. This can help you identify where the problem occurred; tracing back from theindicated input helps you identify how to correct the problem. The error message is:

Multiple clock inputs of N (G) set active. (T6-1)

N is the instance name and G is the gate ID number.



August 2006

T7 (Trace Rule #7)Two adjacent latches in the scan chain path cannot capture data at the same time. Correct thiserror condition by displaying the complete paths of the scan chains by setting the trace report onand repeating the rules checking. You may need to make netlist modifications to correct thiserror condition if you must use the scan chain that contains these latches. The error message is:

Adjacent latches N1 (G1) and N2 (G2) capture data at the same time. (T7-1)

N1 is the instance name of one latch, G1 is its gate ID number, N2 is the instance name of theother latch, and G2 is its gate ID number.

T8 (Trace Rule #8)The measure_sco statement in the shift procedure must follow the successful observation of thescan cells. To guarantee the observation is successful, the time of the measure_sco statementmust meet the following conditions:

• It must not occur after exercising the first clock on the memory element closest to thescan chain output.

• It cannot be at time 0 if you capture the data into the last memory element at the end ofthe shift procedure.

• The states on all inputs at the measure_sco time must be the same as at the end of theshift procedure.

To correct the error condition, you must modify the shift procedure to meet the aboveconditions for the measure_sco statement. The error message is:

Invalid measure_sco time. (T8-1)

T9 (Trace Rule #9)The traced scan chain input pin must be the same as the scan chain input pin specified with theAdd Scan Chains command. You can correct this error condition by redefining the scan chaininput to be the traced pin. The error message is:

Chain input P1 doesn't match entered value P2. (T9-1)

P1 is the name of the traced scan chain input pin, and P2 is the name of the entered scan chaininput pin.

T10 (Trace Rule #10)The time of the force_sci statement in the shift procedure must occur before a clock input of thememory element (closest to the scan chain input) turns on. Correct this error condition by



changing the time of the force_sci statement to a value less than or equal to the indicated time.The error message is:

Force_sci must occur on or before time T. (T10-1)

T is the maximum time.

T11 (Trace Rule #11)A clock input of the memory element (closest to the scan chain input) must not turn on duringthe shift procedure prior to the time of the force_sci statement. Correct this error condition bychanging the times of the force_sci statement or force statements. The error message is:

Incorrect propagation of force_sci value to scan cell. (T11-1)

T12 (Trace Rule #12)If a scan cell contains a SLAVE element, the MASTER element is not directly observable. Theerror message is:

MASTER not observable, a master_observe procedure is required by scangroup G. (T12-1)

G is the scan group.

The default handling for this rule violation is warning.

When the handling is set to other than error, the tool automatically makes the necessaryMASTER unobservable to prevent a potential simulation mismatch. This applies only to theMASTER of the scan cell containing a SLAVE. The scan cell without a SLAVE retains itsoriginal observability. Due to the loss of observability on some MASTERs, test coverage maybe reduced. To correct this violation, you can define a master_observe procedure to propagatethe MASTER value to the SLAVE.

T13 (Trace Rule #13)If you define and try to use a master_observe procedure, there must be at least one scan cellthat contains a SLAVE. If there is no such cell, Correct this error condition by deleting themaster_observe procedure. The error message is:

Master_observe procedure defined but not used. (T13-1)

T14 (Trace Rule #14)If you define and try to use a shadow_control procedure, there must be at least one identifiedSHADOW memory element. Correct this error condition by either changing or deleting theshadow_control procedure.



August 2006


No SHADOWs identified using shadow_control procedure. (T14-1)

T15 (Trace Rule #15)If you define and try to use a shadow_observe procedure, the procedure must observe at leastone SHADOW. You can correct this error condition by changing or deleting theshadow_observe procedure. The error message is:

No observable SHADOWs identified using shadow_observe procedure. (T15-1)

T16 (Trace Rule #16)When clocks and write control lines are off and pin constraints are set, the gate that connects tothe input of a reconvergent pulse generator sink gate (PGS) in the long path must be at the non-controlling value of the PGS gate.

To correct this error condition, access the simulated values by setting the gate reporting toerror_pattern and using the Report Gate command. You can also avoid this error by setting thepulse generators to off, but that results in no pulse generator support. The error message is:

Input of pulse generator N (G) not at correct value when clocks are off.(T16-1)

N is the pulse generator instance name, and G is its gate ID number.

T17 (Trace Rule #17)Reconvergent pulse generator sink gates (PGS) cannot connect to any of the following: primaryoutputs, non-clock inputs of scan memory elements, ROM gates, non-write inputs of RAMs, ortransparent latches. To avoid this error, set the pulse generators to off, however note that thisresults in no pulse generator support. The error message is:

Pulse generator N1 (G1) connected to T N2. (T17-1)

N1 is the pulse generator instance name, and G1 is its gate ID number.

T18 (Trace Rule #18)The maximum number of traced cells in the longest scan chain of a group must equal theentered number of repetitions in the apply shift statement in the load_unload procedure. Youcan correct this warning by changing the repetition number on the apply shift statement. Thisrules violation has no adverse effects because the tool recalculates the actual number ofnecessary shifts based on the number of scan cells it encounters. The rules checker ignores thiscondition if you set the handling to “ignore” with the Set Drc Handling command.

The warning message is:



Traced number shifts (N1) doesn't match entered value (N2). (T18-1)

N1 is the traced number of shifts, and N2 is the entered number of shifts.

T19 (Trace Rule #19)If one scan cell has a SLAVE, then all scan cells must have a SLAVE. You must correct thiswarning by changing the netlist of the scan chains. The warning message is:

N scan cells do not have a SLAVE when some do. (T19-1)

N is the number of non-slave scan cells.

T20 (Trace Rule #20)The number of shifts specified using the Set Number Shifts command must be at least equal tothe length of the longest scan chain. To correct this error set a valid value using the Set NumberShifts command. The error message is:

Entered number of shifts N is too small. (T20-1)

N is the entered number of shifts, and T20 is the rule ID number.

T21 (Trace Rule #21)The number of independent shift applications in the load_unload procedure must be less thanthe scan chain length. Correct this error by removing a sufficient number of independent shiftapplications from the load_unload procedure or by deleting the short scan chain. The errormessage is:

Number of independent shifts N must be less than scan chain length L.(T21-1)

N is the number of independent shift applications, L is the scan chain length, and T21 is the ruleID number.

T22 (Trace Rule #22)If the rules checker traces a scan cell during the application of an independent shift, it must alsotrace that cell during the application of its associated general shift. Correct this error bychanging the sensitization for either the independent or general shift, so that they are sensitizingthe same scan cells.


N (G) was not used in general chain trace. (T22-1)

N is the scan cell instance name, G is its gate ID number, and T22 is the rule ID number.



August 2006

T23 (Trace Rule #23)The chain length calculated for an independent shift must be the same as that calculated for itsassociated general shift. Correct this error by changing the sensitization for either theindependent or general shift, so that they are sensitizing the same scan cells. The error messageis:

Chain length (L1) using independent shift not equal to chain length (L2).(T23-1)

L1 is the independent shift chain length, L2 is the general shift chain length, and T23 is the ruleID number.

Scan Cell Data Rules (D Rules)The DFT tools check scan cells to ensure they are able to properly control and observe theirdata. You may select the handling of these scan cell data rules to be error, warning, note, orignore. The following subsections describe these rules.

D1 (Scan Cell Data Rule #1)Checks for the possible disturbance of data values loaded or captured into scan cells.

Description

During the application of the test procedures, if other circuitry disturbs the data values loaded orcaptured into scan cells, those cells cannot be controlled or observed. The tool performs thischeck using the simulated values of each time period of the test procedures. A violation occursif any clock input (including set and reset lines) of any scan cell allows data capture at aninappropriate time, in which case the control value loaded or the capture value unloaded fromthe scan cell cannot be trusted. Common sources of D1 violations are undefined clocks,problems in the test procedure file, or possibly design errors.

The default handling for this rule violation is error.

Effect on Testability

Failure to satisfy this rule can result in simulation mismatches when you verify the test patternsin a timing-based simulator. If the violations occur during the shift procedure, you may seerelated simulation mismatches in the serial pattern test bench only, not the parallel test bench.

If the number of D1 violations is small compared to the number of scan cells in the design, youmay choose to handle this rule violation as a warning by issuing the Set Drc Handling D1Warning command prior to DRC. When “set drc handling d1 warning” is in effect for DRC, thetool automatically applies an XX cell constraint to each D1 failing scan cell. This prevents themismatches, but may reduce test coverage slightly. See the Add Cell Constraints commanddescription for information about the XX cell constraint.



NoteIf “set drc handling d1 note” is in effect for DRC, the tool will not apply any XX cellconstraints for D1 violations, which ensures test coverage is not affected. However, youshould use “note” handling only for cell architectures you know will not producemismatches.

If the number of D1 violations is large, you should isolate and resolve the source of thefailure(s) to avoid a major impact on test coverage.

How to Debug D1 Violations

The occurrence message is:

// N (G) disturbed during time T of P procedure. (D1-1)

N is the instance name of the scan cell memory element, G is the gate ID number, T is the timeperiod, and P is the group test procedure name.

The summary message is:

// There were N occurrences of scan cell disturbs. (D1)

N is the number of occurrences of rules violation D1.

Use the Report Drc Rules command to obtain additional information about the violations. Forexample, to view the occurrence messages for all D1s, use:

report drc rules d1

The occurrence messages list gate names and gate IDs you can copy and paste into commandsduring later debugging. You can report on a specific occurrence by issuing the command with“D1-” and the occurrence number. For example:

report drc rules d1-1

// Error: /dataout/reg_q_0_ (373) disturbed during time 0 of grp1 load_unload procedure. (D1-1)

When a D1 error occurs, you can access the simulated values at the gate where the erroroccurred by issuing the command, Set Gate Report Error_pattern, then using the Report Gatescommand to report the gate whose ID number is displayed in the error message. In the resultantdisplay, you can identify the clock input not held at its off state. By tracing back from this input,you can usually identify how to correct the problem.

You can debug a specific occurrence of a D1 violation using DFTInsight or by issuingcommands from the tool’s command line. Examples of both methods follow.



August 2006

How to Debug with DFTInsight

To view the location of a D1 DRC violation using DFTInsight, use the following commandsteps:

1. Open Schematic Viewer

2. Set Gate Level Primitive

Then choose Analyze > DRC Violation from the DFTInsight menu, select the ID of the desiredD1 violation occurrence in the dialog box and click Analyze. DFTInsight will display the scancell affected by that occurrence.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# and -Display arguments at the tool’s command line. For example, todisplay the first occurrence of a D1 violation:

analyze drc violation d1-1 -display

Once the offending scan cell is displayed, use the EZ-Trace Mode of DFTInsight (or theDFTInsight menu item, Display > Backward Trace > To End Points) to trace back from thecell’s clock input to the primary input that drives the clock. Ensure the clock’s off state, whichyou defined using the Add Clocks command, is correct.

How to Debug from the FastScan Command Line

To view the location of a D1 DRC violation from the FastScan command line, use the followingexample command steps (FlexTest and TestKompress would be similar):

1. Set Gate Report Error_pattern


3. Report Drc Rules D1-occurrence#

4. Report Gates offending_gate’s_id#

The following transcript excerpt shows an example of the use of this command sequence:

SETUP> set gate report error_patternSETUP> set gate level primitiveSETUP> report drc rules d1-1// ERROR: /dataot/reg_q_0_ (373) disturbed during time 0 of grp1// load_unload procedure. (D1-1)SETUP> report gate 373// /dataot/reg_q_0_ (373) DFF// "S" I (0) 43-// R I (0) 157-// CLK I (1) 313-/dataot/ix104/Y



// "D0" I (X) 255-// "OUT" O (X) 127- 128-

You would then trace back from the CLK input to try to determine why it is in an active state,which disturbed the cell’s value.

In some of the more complex cases, the problem can be a clock disturb early in the capturecycle. In these cases, the error report does not provide enough detail to isolate the failure. To getmore information, you can use the following command steps:

1. Set Gate Report Drc_pattern State_stability

2. Set System Mode Atpg


The following transcript excerpt shows an example of the use of this command sequence:

SETUP> set gate report drc_pattern state_stability// Creating schematic for 3 instances (0 were compacted).SETUP> set system mode atpg// ---------------------------------------------------------------------// Begin scan chain identification process, memory elements = 56.// ---------------------------------------------------------------------// Reading group test procedure file fast.testproc.// WARNING: Pin tclk is used for both write control and pulse clock// Simulating load/unload procedure in grp1 test procedure file.// Chain = chain1 successfully traced with scan_cells = 12.// Chain = chain4 successfully traced with scan_cells = 12.// Chain = chain3 successfully traced with scan_cells = 12.// Chain = chain2 successfully traced with scan_cells = 12.// 48 scan cells have been identified in 4 scan chains.// Longest scan chain has 12 scan cells.// WARNING: 8 edge-triggered clock ports set to stable high. (D7)// ERROR: /dataot/reg_q_0_ (373) disturbed during time 0 of grp1// load_unload procedure. (D1-1)// ERROR: Rules checking unsuccessful, cannot exit SETUP mode.SETUP> report gate 373// /dataot/reg_q_0_ (373) DFF// (ts)(ld)(shift)(cap)// "S" I ( 0)( 0)(000~0)(000) 43-// R I ( 0)( 0)(000~0)(XXX) 157-// CLK I ( 1)( 1)(101~1)(XXX) 313-/dataot/ix104/Y// "D0" I ( X)( X)(XXX~X)(XXX) 255-// "OUT" O ( X)( X)(XXX~X)(XXX) 127- 128-

The item to notice is the clock values during the capture cycle. In this case the value of the clockis (XXX). This indicates the clock is not at its off state at the beginning or end of the capturecycle. The correct values should be either:

• (0X0)—For a leading edge device with an off state of 0 for the clock, or

• (1X1)—For a trailing edge device with an off state of 1 for the clock



August 2006

Possible Resolutions

If your debugging effort shows an offending clock’s off state is incorrect, use the Add Clockscommand to redefine the clock with the correct off state. To change the defined off state, firstdelete the old definition with the Delete Clocks command, then reissue Add Clocks. To see aclock’s current defined off state, use the Report Clocks command.

If the clocks are working correctly, examine the test procedure file. By tracing through thedesign, you may find an incorrect constraint or force value that can be fixed in the testprocedure file.

NoteIf you make any changes in the test procedure file, execute the Read Procfile commandwith the correct filename before re-checking the design rule checks.

Related Commands

D2 (Data Rule #2)During system data capture, if the scan path from a MASTER or SLAVE element to its COPYis sensitized, it must be unique. The tool performs this check by comparing the inputs of theCOPY with its associated memory element. A violation occurs if there are multiple paths fromthe associated memory element (MASTER or SLAVE) to the COPY and these paths can besensitized at the same time. The application checks for the following conditions:

• The value on the data line of the COPY element must be able to be propagated back toits associated memory element along the scan path when constrained pins are set.

• The scan path, when sensitized from the associated memory element to the COPY, mustbe unique.

• The COPY and its associated memory element may have only a single clock port.

• For a COPY and its associated memory element, all non-tied clock, set, and reset inputsmust have the same or equivalent source.

NoteDRC does not consider it a D2 violation if a COPY element can capture a value through adifferent path other than from its associated memory element during system capture.

Add ClocksAnalyze Drc ViolationDelete ClocksRead ProcfileReport Clocks

Report Drc RulesReport GatesSet Drc HandlingSet Gate Report



The default handling for this rule violation is warning

Failure to satisfy this rule usually reduces test coverage and can result in inaccurate test patternsimulation results (simulation mismatches) during verification in a timing-based simulator. Youcan avoid the coverage loss and simulation mismatches by using the command, Set SplitCapture_cycle On.


COPY N (G) failed data capture check. (D2-1)

N is the instance name of the COPY memory element, and G is the gate ID number.


N COPY scan elements failed data capture check. (D2)


D3 (Data Rule #3)For all scan cells that contain a SLAVE, the master_observe procedure must propagate the datavalue of the MASTER memory element to the SLAVE. The application performs this checkusing the simulated values of each time period of the master_observe procedure to trace backfrom the SLAVE to the MASTER. The rule violation occurs if the master_observe proceduredoes not properly sensitize the path between the SLAVE and MASTER.

The default handling for this rule violation is error. You may ignore this error condition byissuing the command Set Drc Handling D3 Warning.

When the handling is set to other than error, the tool will automatically make the necessaryMASTER unobservable to prevent a potential simulation mismatch. This applies only to theMASTER of the scan cell containing a SLAVE. The scan cell without a SLAVE retains itsoriginal observability. Due to the loss of observability on some MASTERs, test coverage maybe reduced.

When an error condition occurs, you can access the simulated values by setting the gatereporting to drc_pattern (with the master_observe argument and the desired time) and using theReport Gates command for the gates in the SLAVE to MASTER path. This identifies thelocation of the blockage; by tracing back from the inputs, you can identify how to correct theproblem.


N (G) not successfully observed by master_observe procedure. (D3-1)

N is the instance name of the MASTER memory element, and G is the gate ID number.



August 2006


N MASTERs not successfully observed by master_observe procedure. (D3)


D4 (Data Rule #4)If you define the skew_load procedure, it must propagate the data value of the preceding scancell (or scan chain input pin) to a MASTER memory element. The application performs thischeck using the simulated values of each time period of the skew_load procedure to trace backfrom a MASTER to its preceding scan cell output or scan chain input pin. The rule violationoccurs if the skew_load procedure does not properly sensitize the path.

The default handling for this rule violation is error. Failure to satisfy this rule may result ininaccurate simulation results when you use the skew load option. The skew_load procedure isoptional and you can avoid rules violations by removing the procedure definition.

When an error condition occurs, you can access the simulated values by setting the gatereporting to drc_pattern (with the skew_load argument and the desired time) and using theReport Gate command for the gates in the path. This identifies where the blockage occurred; bytracing back from the inputs, you can identify how to correct the problem.


Skew_load procedure not successful for MASTER %N (G). (D4-1)

N is the instance name of the MASTER memory element and G is the gate ID number.


Skew_load procedure not successful for N MASTERs. (D4)


D5 (Data Rule #5)All memory elements (latches and flip-flops) must be scannable. The application performs thischeck after identifying all scan memory elements. The rule violation occurs for all memoryelements not identified as part of a scan cell.

NoteThe D5 check simulates the circuit as purely combinational by using a sequential depth of0 or 1 (as if the Set Pattern Type -Sequential command is set to 0 or 1), and no clock_offor split capture cycle simulation, which corresponds to the default settings of theSet Clock_off Simulation and Set Split Capture_cycle commands.



When FastScan or TestKompress identifies a non-scan memory element, the tool classifies itinto one of the following types:

• INIT-0: If it is at 0 at the beginning of the first capture cycle.

• INIT-1: If it is at 1 at the beginning of the first capture cycle.

• INIT-X: If its state is unknown at the beginning of the first capture cycle and it may goto any state during capture.

• TIE-0: If it is always at 0 during capture.

• TIE-1: If it is always at 1 during capture.

• TIE-X: If it is always at an unknown state during capture.

• TLA: If it is always transparent when its clock is at its off state.

The model used (and reported in the D5 violation message) is determined from the element’svalue in the D5 simulation, at the end of load_unload and before entering capture. For example,if the element’s value is 1 at that time, the tool will model it as a TIE-1. Latches modeled asTIE-X gates become candidates for transparent latches, sequential transparent cells, or clockedsequential cells if you set the pattern type appropriately with the Set Pattern Type command.

For FlexTest, the D5 rule will report non-sequential elements that are converted to TIE-1,TIE-0, or TIE-X. The warnings referring to TIE-X gates can be ignored. Because of itssequential capabilities, FlexTest will try to initialize nonscan cells. However, gates converted toTIE-0 and TIE-1 should be examined further. To debug, use “report nonscan cells”.

Following is a list of categories into which FlexTest classifies non-scan memory elements:

• tie-0 gate: If its output is always 0 between scan operations.

• tie-1 gate: If its output is always 1 between scan operations.

• init0: Latch with initial state 0 after each scan operation.

• init1: Latch with initial state 1 after each scan operation.

• initx: Latch with unknown initial state after each scan operation.

• hold: Latch holds its state during scan operation.

• initdata: Latch can capture its stable data input during scan operation.

The default handling for this rule violation is warning. Failure to satisfy this rule will result insome loss of test coverage.


N (G) is a non-scan T1 converted to T2. (D5-1)



August 2006

N is the instance name of the non-scan memory element, G is the gate ID number, T1 is the gatetype (latch or flip-flop), and T2 is the gate type that models it (TIEX, TIE0, or TIE1).


N non-scan memory elements converted to T gates. (D5)

N is the number of occurrences of rules violation D5, and T is the gate type that models the non-scan cell. The tool displays a summary message for each remodeled gate type.

D6 (Data Rule #6)All non-scan latches must behave as transparent latches. The application performs this check forall nonscan latches that are not set to a stable binary value. The rule violation occurs if acandidate latch fails one of the following conditions:

• If the latch creates a potential feedback path, that path must be broken by scan cells ornon-scan cells other than transparent latches. For more information, refer to the Set TlaLoop_handling command in the ATPG and Failure Diagnosis Tools Reference Manual.

• The latch must have a propagable path to an observable point.

• The latch must be capable of passing a value when all defined clocks are at their off-state.

• All clock, set, and reset inputs of the latch must either be set to a determinate state whenall clocks are off and pin constraints are set, or must not connect to defined clocks.

• The latch must not have more than one set/reset/clock input on when all defined clocksare at their off-state.

Failure to satisfy this rule can reduce test coverage. The default handling for this rule violationis warning. If you set the handling for this rule to ignore, the tool will not perform this check andthe design’s latches will not be checked for transparency.

For DFTAdvisor, if you want the tool to consider non-transparent latches as scan candidates,you must turn test logic on (with the Set Test Logic command) and do one of two things: 1) setthe handling of D6 to ignore, in which case DFTAdvisor does not perform the transparencycheck and automatically considers the non-scannable latches for scan insertion; or 2) use the SetLatch Handling Scan command, in which case DFTAdvisor performs the check and considersnon-transparent latches for scan insertion.


Latch N (G) not transparent due to R. (D6-1)

N is the instance name of the non-scan latch, G is the gate ID number, R is the reason it cannotbe transparent, and D6 is the rule ID number.




N latches not transparent due to R. (D6)

N is the number of occurrences of rules violation D6, and R is the reason. The applicationdisplays a summary message for each reason.

D7 (Data Rule #7)At the end of the shift procedure, the clock inputs of scan flip-flops must not be set to a onestate. The application performs this check using the simulated values of the last time period ofthe shift procedure. The rule violation occurs if any clock input (not including set and resetlines) of any scan flip-flop (except COPY) is set to 1. A possible cause of a rules violation is anincorrect definition of the off-state of a clock.

NoteSome design practices consider this condition acceptable.

The default handling for this rule violation is warning. Failure to satisfy this rule will result inscan cells capturing data on the trailing edge of the capture clock pulse, thus resulting in somerisk of race conditions.


Flip-flop N (G) has clock port set to stable high. (D7-1)

N is the instance name of the non-scan memory element, G is the gate ID number, and D7 is therule ID number.


N edge-triggered clock ports set to stable high. (D7)


D8 (Data Rule #8)If a MASTER latch only propagates to a SLAVE and can only capture data when the SLAVE isinactive, a clock input of the MASTER latch must not be active when all clocks are off. Thesystem uses the master_observe procedure to observe the values placed into the scan cell andno longer considers the SLAVE to be observable.

The application performs this check using the simulated values that result when all definedclocks are at their off-state, the constrained pins are set to their constrained values, and theinitialized non-scan cells are set to their stable states.



August 2006

The rule violation occurs if a clock input of a MASTER latch is not off, the MASTER latch onlypropagates to a SLAVE, and can only capture data when the SLAVE is inactive.

NoteSome design practices consider this condition acceptable.

When an error condition occurs, you can access the simulated values by setting the gatereporting to error_pattern and using the Report Gate command for the gate ID number displayedin the error message. This identifies the clock input not held off, and by tracing back from thisinput, you can identify how to correct the problem.

The default handling for this rule violation is error because for certain rare LSSD scan celldesigns it can result in a simulation mismatch during pattern verification in a timing-basedsimulator. Failure to satisfy this rule will result in data captured into the MASTER without theapplication of a capture clock.

NoteIf “set drc handling d8 warning” is in effect for DRC, the tool will automatically apply anSX cell constraint to each D8 failing master cell. This prevents the mismatches, but mayreduce coverage. See the Add Cell Constraints command description for informationabout the SX cell constraint.

If “set drc handling d8 note” is in effect for DRC, the tool will not apply any SX cellconstraints for D8 violations, which ensures test coverage is not affected. However, youshould use “note” handling only for cell architectures you know will not producemismatches.


MASTER latch N (G) allows data capture while clocks off. (D8-1)

N is the instance name of the non-scan memory element, and G is the gate ID number.


Clocks at off-state allow data capture for N MASTER latches. (D8)


D9 (Data Rule #9)Seq_transparent procedures must not disturb scan cells, primary outputs, or previouslycalculated seq_transparent cells. The default handling for this rule violation is warning. Theapplication performs this check during simulation of the seq_transparent procedure.



A rule violation occurs under any of the following conditions:

• If scan cell state elements change during the application of a seq_transparentprocedure. Unless these scan state elements capture new data at the application of thecapture clock, the system cannot observe them during patterns that apply the procedure.

• If disturbed scan cells supply the inputs of other scan cell state elements. The systemcannot observe these other scan cell state elements during patterns that apply theprocedure.

• If a primary output comes from disturbed circuitry, the system cannot observe theseprimary outputs during patterns that apply the procedure.

• If the application of the seq_transparent procedure disturbs a non-scan state elementthat previously captured an undisturbed value.

Failure to satisfy this rule results in restrictions on the use of these points for observation duringsimulation and test generation for patterns that apply the procedure. This can reduce testcoverage.

If a disturbed cell must support a valid seq_transparent cell, the tool identifies the disturbed cellas a seq_transparent cell and issues a violation of type seq_transparent cell disturb. Otherwise,the tool will not identify it as a seq_transparent cell, and will instead issue a D9 violation of typeunused seq_transparent cell disturb.


T disturb occurred on N (G) in procedure P. (D9-1)

T is the type of disturb, N is the instance name of the disturbed gate, G is the gate ID number, Pis the name of the seq_transparent procedure, and D9 is the rule ID number. The summarymessage is:

N T disturbs occurred in procedure P. (D9)

N is the number of occurrences of a disturbance type, T is the type of disturbance, P is the nameof the seq_transparent procedure, and D9 is the rule ID number. The tool issues a summarymessage for each disturbance type.

D10 (Data Rule #10)The transparent capture cells (see “Clock (FastScan and TestKompress, Optional)” section) inclock procedures must not propagate both old and new data to other state elements. Forexample, a violation can occur when a clock procedure pulses two clocks, and a memoryelement clocked by the first applied clock feeds at least two other memory elements, clocked byeach of the clocks. To illustrate this, assume the clock procedure is as follows:



August 2006

procedure clock clock_proc1 =force A 1 1;force A 0 2;force B 1 3;force B 0 4;

end;

Given this procedure, the highlighted flip-flop in Figure 2-5, which gets old data from the firstflip-flop when A pulses, violates this requirement.

Figure 2-5. Rule D10 Violation Example

The default handling for this rule violation is error. Failure to satisfy this rule will result in thesource gate being modeled as a TIEX gate. You can suppress reporting the results of this checkusing Set Drc Handling. However, regardless of how you set the handling, FastScan andTestKompress always perform this check on model violating gates with TIEX behavior.


Cell N (G) has invalid transparency (X/Y) in procedure P. (D10-1)

N is the cell name, G is the gate ID number of the cell, X is the ID number of the gate capturingold data, Y is the ID number of the gate capturing new data, and P is the clock procedure name.


There were N cells with invalid transparency.(D10)

N is the number of cells found to violate this rule.

A

B

flip-flop

dataflip-flop

flip-flop



D11 (Data Rule #11)The transparent capture cells in clock procedures must not propagate data to primary outputs.For example, assume the clock procedure is as follows:

procedure clock clock_proc1 =force A 1 1;force A 0 2;force B 1 3;force B 0 4;

end;

Given this procedure, the primary output in Figure 2-6, which gets data from the first latchwhen A pulses, violates this requirement.

Figure 2-6. Rule D11 Violation Example

The default handling of this violation is warning. Failure to satisfy this rule results in theaffected PO not being used for observation, as the expected value is always considered an X.FastScan and TestKompress classify faults detectable only through these POs as AU faults. Tochange the default handling, use the Set Drc Handling command.

If you change the handling to ignore, FastScan and TestKompress do not perform this check andcontinue to use the primary outputs for observation. You may want to ignore this rule if you arerunning ATPG on a sub-block whose POs will eventually feed scan cells. In this case, a D10violation may occur instead. If you ignore this violation, the reported fault coverage does notconsider reconvergence through transparent capture cells, and ATPG could produce an invalidpattern set.


Transparent_capture cell N (G) in procedure P hasconnectivity to POs.(D11-1)

N is the cell name, G is the gate ID number of the cell, and P is the clock procedure name.


There were N Transparent_capture cells with connectivity to POs.(D11)

N is the number of cells found to violate this rule.



August 2006

Clock Rules (C Rules)The application checks the scan clocks to ensure their proper definition and operation. You mayselect the handling of any clock rule to be error, warning, note, or ignore. The followingsubsections describe the clock rules and the special handling you can set for them.

Clock TerminologyThe clock rule information contains a couple of recurring concepts. To make optimal use of theinformation, you should understand these concepts as described in the following subsections.

Clock Signals

FastScan, FlexTest, and TestKompress consider any signal to be a clock if it can change thestate of a sequential element, including system clocks, sets, and resets. When you define eachclock primary input (a required setup step you perform using the Add Clocks command or“analyze control signals -Auto_fix”), a key piece of information specified with either of thesecommands is the pin value that represents the clock’s off state. Two important terms arise out ofthis definition, as shown in Figure 2-7.

Figure 2-7. Clock Cycle Terminology

The transition of the clock from the off state to the on state is considered the leading edge of theclock, while the transition from the on state to the off state is considered the trailing edge of theclock.

Leading Edge (LE)

CLK1

Trailing Edge (TE)

CLK2

SETUP> add clocks 1 CLK2

SETUP> add clocks 0 CLK1

Off state

Clock Cycle



Clock Cones and Effect Cones

Mentor Graphics DFT tools consider a gate pin or output pin to be in a clock signal’s clock coneif there is a path through combinational logic gates and transparent latches (TLAs) from theclock primary input to the gate pin or output pin.

NoteThe tools treat a latch as a transparent latch (TLA) rather than as a normal level-sensitivesequential element (LA) if it will be continuously enabled at the start of the capture cyclewhen all clocks are at their defined off values. This treatment therefore depends on toolsetups and how the latch is wired into the design. A TLA passes values without holdingstate and thus acts like a buffer. For more information, refer to “Simulation Primitives ofthe Flattened Model” in the Scan and ATPG Process Guide.

The clock cone is basically the fanout of the clock signal through strictly combinational logicand TLAs. Pins B, C, CLK and CLK2_INV in the circuit excerpt shown in Figure 2-8 are all inCLK2’s clock cone.

Figure 2-8. Example Clock Cone

The tools consider a gate pin or output pin to be in a clock’s effect cone if there is a sequentialelement between the clock net and the gate pin or output pin. In Figure 2-9, pin Y is in the effectcone of CLK2.

Figure 2-9. Example Effect Cone

DCLK2

CLK

B

Q

CA

CLK2_INV

Y

DCLK2

CLK

B

Q

CA

CLK2_INV

Y



August 2006

A pin can be in both the clock cone and the effect cone as shown for pin D on one of theflip-flops in Figure 2-10.

Figure 2-10. Pin in Both Cones

You can get DFTInsight to show a “C”, “E” or “B” near device pins that are in the clock (C),effect (E), or both (B) cones of a particular clock by issuing the Set Gate Report command withthe Clock_cone option after the tool has flattened the design. For example:

flatten modelset gate report clock_cone CLK

Alternatively, you can choose Setup > Reporting Detail from the DFTInsight menu and in thedialog box specify Clock Cone Data Based on Clock. Figure 2-11 shows an example of howthis actually looks for a circuit fragment in DFTInsight.

Figure 2-11. DFTInsight View Showing Clock Cones

When the Clock_cone option is in effect, the output of the Report Gates command also displaysclock cone data:

report gates /DFF1

// /DFF1 dff// clkI (C)2-/CLK

D

CCLK

QD

E

Effect cone

Clock cone

B

C

Pin D is in both cones

C

Q

CLK

PI

C

d

clkq

dff

E

DFF1

i0C CINV

out

C

d

clkq

dff

E

DFF2

C

-

E



// d I (-)1-/C// q O (E)5-

NoteThe tool shows clock and effect cone data for just one clock at a time—the clock whoseprimary input pin_name you specified in the last “Set Gate Report Clock_cone”command.

The ATPG Analysis OptionClock rules C1, C3, C4, and C5 can run full ATPG analysis during their checks. For moreinformation on ATPG analysis, refer to “Turning on ATPG Analysis” on page 26.

C1 (Clock Rule #1)A scan cell must not capture data when all specified clocks are set to their off states.

Description

When all clocks are at their off state as defined with the Add Clocks command, all clock inputs(including sets and resets) of scan cells must not capture data; that is, they must be at theirinactive states. The usual cause of a violation of this rule is not defining a clock or defining thewrong off state for a clock. The tool performs this check using the simulated values that resultwhen all defined clocks are at their defined off states, constrained pins are set to theirconstrained values, and non-scan cells, initialized during test_setup or load_unload, are set totheir stable states.

Figure 2-12 shows an example DFTInsight display of a circuit segment that produces a C1violation due to an indeterminate value (X) at the clk input of DFF1 when the off state of theclock at the PI is defined as a logic 0 and all defined clocks are off.

Figure 2-12. C1 Violation Example

The clock input value to the scan cell is X because the EN signal value is X. If EN is left at X,the signal arriving at the clk input of the scan cell cannot be held off.


0 XX

XA1

X

OR

A0Y

X

0X

d

qclk

DFF1

mux_scan_dff

CLK

PI

EN

PI

X sc_enX sc_in



August 2006


Failure to satisfy this rule can result in unstable scan cell values going into or coming out ofload_unload, or between cycles, and can result in inaccurate test pattern simulation results(simulation mismatches) during verification in a timing-based simulator.

How to Debug C1 Violations


// Clock PIs off failed to force off a clock line of T N (G). (C1-1).

T is the type of scan cell (MASTER, SLAVE, etc.), N is the instance name of the gate, and G isthe gate ID number.


// There were N clock rule C1 fails (unstable scan cells when clocks off).

N is the number of occurrences of rules violation C1.

Use the Report Drc Rules command to obtain additional information about the violations. Forexample, to report the occurrence messages for all the C1s, use:

report drc rules c1

The occurrence messages list gate names and gate IDs you can copy and paste into commandsduring later debugging. You can report on a specific occurrence by issuing the command with“c1-” and the occurrence number. For example:

report drc rules c1-1

// Error: Clock PIs off failed to force off a clock line of /DFF1 (14).// (C1-1)

You can debug a specific occurrence of a C1 violation using DFTInsight or by issuingcommands from the tool’s command line. Examples of both methods follow.


To view the location of a C1 DRC violation using DFTInsight, use the following command:

Open Schematic Viewer

Then choose Analyze > DRC Violation from the DFTInsight menu, select the ID of the desiredC1 violation occurrence in the dialog box and click Analyze. DFTInsight will display the scancell affected by that occurrence.



Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# and -Display arguments at the tool’s command line. For example, todisplay the first occurrence of a C1 violation:

analyze drc violation c1-1 -display

Once the offending scan cell is displayed, use the EZ-Trace Mode of DFTInsight (or theDFTInsight menu item, Display > Backward Trace > To End Points) to trace back from thecell’s clock input to the primary input that drives the clock. Ensure the clock’s off state, whichyou defined using the Add Clocks command, is correct. To change the defined off state, deletethe old definition with the Delete Clocks command, then reissue Add Clocks. To see a clock’scurrent defined off state, use the Report Clocks command.


To view the location of a C1 DRC violation from the FastScan command line, use the followingexample command steps (FlexTest and TestKompress would be similar):

1. Set Gate Report Error_pattern

2. Report Drc Rules C1-occurrence#


4. Report Gates -Endpoints -Backward id#_of_gate_connected_to_offending_gate’s_clock

The following transcript excerpt shows an example of the use of this command sequencestarting at step 2:

SETUP> report drc rules c1-1// Error: Clock PIs off failed to force off a clock line of /U$1/DFF1// (14). (C1-1)SETUP> report gates 14// /U$1/DFF1 (14) DFF// “S” I (0) 10-// "R" I (0) 11-// clk I (X) 12-/OR/Y// d I (X) 13-/MUX/out// "OUT" O (X) 8- 9-SETUP> report gates -endpoints -backward 12// ---------------------------------------------------------------------// Begin backward trace for gate /OR (12).// ---------------------------------------------------------------------// /CLK (3) PI// CLK O (0) 12-/OR/A0// /EN (4) PI// EN O (X) 12-/OR/A1// Number gates in trace = 2.



August 2006


If your debugging effort shows an offending clock’s off state is incorrect, use the Add Clockscommand to redefine the clock with the correct off state. If the off state is correct, the problemtypically is due to an indeterminate value (X) in related logic that causes the clock’s value at ascan cell to be X. This is the case in the example shown in the figure above. You can fix theseby using the Add Pin Constraint command to constrain a primary input pin to a value thatremoves the X:

SETUP> add pin constraint EN c0

This allows the tool to consider the CLK signal to be the only clock signal to the clk input of thescan cell.

For further explanation and examples of possible C1 rule violations, refer to the “Clock Gaters”appendix in the Scan and ATPG Process Guide.

Related Commands

C2 (Clock Rule #2)Each clock must be capable of statically turning on a clock input of at least one scan memoryelement when all other clocks are off. It is acceptable that this may require placing values onnon-clock primary inputs or scan cells. The application performs this check using the simulatedvalues that result when the checked clock is set to X, all other defined clocks are at their off-state, the constrained pins are set to their constrained values, and the initialized non-scan cellsare set to their stable states. The rule violation occurs if all clock inputs of all scan memoryelements are still off.

When an error condition occurs, you can access the simulated values by setting the gatereporting to error_pattern and using the Report Gate command. Defining a pin to be a clock,when it does not behave as a clock, is the most usual cause of this error condition. The defaulthandling for this rule violation is error. You can tell the system to ignore this error condition byusing the -Force switch of the Set System Mode command. Failure to satisfy this rule indicatesa defined clock cannot capture data, thus reducing test coverage.


Clock P cannot capture data with other clocks off. (C2-1)

Add ClocksAdd Pin ConstraintAnalyze Drc ViolationDelete Clocks

Report ClocksReport Drc RulesReport GatesSet Gate Report



P is the pin name of the clock.


There were N clock rule C2 fails (clock cannot capture ability check).


C2 Rule Violation Example

Figure 2-13 shows an example circuit and circuit setup specified in DFTAdvisor, FastScan,FlexTest, or TestKompress.

Figure 2-13. C2 Rule Example Circuit

If you run rules checking on this design, you will get a C2 rules violation because while theCK17 signal appears to be a clock (due to its name), it does not have the ability to capture datainto the flip-flop with all other clocks held off. To fix this problem, add the command:

SETUP> delete clock CK17

Then, you must re-run checks.

C3 (Clock Rule #3)

Description

When a sequential element (or RAM) source and sink are clocked by the same clock and thesink captures data from the source, a potential exists for the captured data to pass through boththe source and sink in the same clock cycle. That is, the sink might capture the source’s newdata (captured in the same cycle) instead of the source’s old data (captured in the previouscycle). Table 2-2 lists four clocking relationships that can produce this problem.

Table 2-2. Clocking that May Result in a Signal Race

Source Sink

LS LS

LS TE

LE LS

SETUP> add clock 1 PRESETUP> add clock 1 CLRSETUP> add clock 0 CK

SETUP> add pin constraint EN1 c0

SETUP> add clock 1 CK17

D

CLK

DCK17

CKEN1

Q

QB

CLR

PRE

CLR

PRE

Q

QB



August 2006

This condition violates the tool’s default assumption that the sink captures only old data fromthe source, so results in a C3 violation and may require special handling. Failure to address thisissue can result in simulation mismatches when you verify the test patterns in a timing-basedsimulator. Each sequential element is either level sensitive (LS), leading edge triggered (LE), ortrailing edge triggered (TE)

NoteAdequate special handling for most C3 situations is to simply issue “Set SplitCapture_cycle On” as explained under “Possible Resolutions” later in this section.

Figure 2-14 shows an example DFTInsight display of a circuit segment that produces a C3violation when the off state of the clock at the PI is defined as a logic 0. (In FastScan, FlexTest,and TestKompress, you define the off state of each clock with the Add Clocks command or withAnalyze Control Signals -Auto_fix as a part of required tool setups). DFF1 updates on theleading edge (LE) of the clock, while DFF2 updates on the clock’s trailing edge (TE) due to theinverter. Under certain timing conditions (if captured data propagates through DFF1 to its qoutput in less than half a clock cycle for example), data will pass through both DFF1 and DFF2in a single clock cycle.

NoteThe same situation would occur if the clock pin was connected directly (rather thanthrough an inverter) to DFF2, and DFF2 was negative-edge triggered.


Figure 2-15 shows a possible timing scenario for the preceding circuit segment.

LE TE


Source Sink

CLK

PI

C

d

clkq

dff

E

DFF1

i0C CINV

out

C

d

clkq

dff

E

DFF2

C

-

E



Figure 2-15. Example Timing That Allows Sink to Capture Source’s New Data

The tool performs this check by determining the forward cones of influence for a clock pin (itsclock cones). For an introduction to clock and effect cones, refer to “Clock Cones and EffectCones” on page 71. The bounds for the clock cones are scan cells and circuitry set to a fixedvalue when the constrained pins are set to their constrained values and the initialized non-scancells are set to their stable states. The clock cone stops at read ports of RAMs that have theread_off attribute set to hold, and then the effect cone propagates from its outputs.

NoteIn Figure 2-14, the data input for DFF2 is in the effect cone of CLK and its clock input isin the clock cone of CLK as indicated by the “E” and the “C” in the DFTInsight display.

The rule violation may occur for a clock if one of the following is true:

• The clock input of a DFF state element is in the clock cone, its input data is in the effectcone, the element is trailing edge triggered, and the effect data comes from an elementthat is leading edge triggered.

• The clock input of a LA state element is in the clock cone and its input data is in theeffect cone.

• The write input of a RAM is in the clock cone and a data input or address input of theassociated write port is in the effect cone.

NEW VALUE

CLK (INV/i0)

DFF1/q

DFF2/q

capture cycle

DFF1/d

Actual

LE TE

OLD VALUE

DFF2/d

Predicted

INV/out (DFF2/clk)

Propagation time of DFF1’s new data

...CLK pulse width.

to DFF2’s d input is less than...



August 2006

• The read input of a RAM is in the clock cone and an address input of the associated readport is in the effect cone.

The tool performs a mutual exclusivity check to determine if the clock/write/read inputsassociated with the failure can be active at the same time. To obtain the most benefit from thischeck, turn on ATPG analysis prior to DRC by issuing the Set Drc Handling command with theAtpg_analysis argument. By default, the rules checker performs a partial ATPG analysis to findpotential C3 rule violations. This partial analysis justifies clock/data conflicts in the affectedcircuitry, but stops at decision nodes, RAM, ROM, TIEX, TLA, and all other non-scan stateelement gates. With complete ATPG analysis explicitly turned on, the rules checker justifies theconflicting values back to PIs or scan cells.

The Set Sensitization Checking command provides another way to slightly modify the handlingof this rule check. With “set sensitization checking on”, the tool additionally verifies that thepath between the source and sink gates of a suspected C3 violation can be sensitized with theclock ports of both gates active while all other clocks are off. By default, the Set SensitizationChecking command is turned off. By turning it on, you force the C3 check to report a violationonly if the suspected violation path can be sensitized.


NoteIn some situations, violations of this rule may occur when there is no real problem withthe design. For information on performing enhanced checking to screen out these falseviolations, refer to “Screening Out False C3 Violations” on page 83.


Failure to satisfy this rule can result in inaccurate test pattern simulation results (simulationmismatches) during verification in a timing-based simulator and failing patterns on the tester.


For C3 violations, the tool transcripts a message similar to the following:

// Warning: There were N clock rule C3 fails (clock may capture dataaffected by its captured data).

N is the number of times a C3 violation occurred.

Use the Report Drc Rules command to obtain additional information about the violations. Forexample, to report the occurrence messages for all the C3s, issue “Report Drc Rules C3”. Theoccurrence messages list gate names and gate IDs you can copy and paste into commandsduring later debugging. You can report on a specific occurrence by issuing the command with“C3-” and the occurrence number. For example:




//Warning: Clock /CLK failed rule C3 on input 3 of /DFF2 (9). (C3-1)// Source of violation: input 3 of /DFF1 (8).



To view the location of a C3 DRC violation using DFTInsight, use the following commandsteps:



Then choose Analyze > DRC Violation from the DFTInsight menu and select the desired C3DRC violation in the dialog box. DFTInsight will display the gates between the source cell andthe failing cell, including the clock cone data for the failing clock, as shown in Figure 2-14.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# and -Display arguments at the tool’s command line. For example:


NoteIn some situations, the tool’s analysis may require significant CPU run time. You caninterrupt the process and return to the command prompt using the Control-C key(intermediate results are not retained if you interrupt the analysis), or you can displayperiodic progress using the -Interval switch with the Set Drc Handling command.


To view the location of the first occurrence of a C3 DRC violation from the FastScan commandline, use the following example command steps (FlexTest and TestKompress would be similar):



3. Set Gate Report Clock_cone pin_name

4. Report Gates source_gate_id sink_gate_id


ATPG> report drc rules c3-1// Warning: Clock /CLK failed rule C3 on input 3 of /DFF2 (9). (C3-1)



August 2006

// Source of violation: input 3 of /DFF1 (8)ATPG> set gate report clock_cone /CLKATPG> report gates /DFF1 /DFF2// /DFF1 dff// “IO”I (-)4-// “I1”I (-)3-// clkI (C)2-/CLK// d I (-)1-/C// “OUT”O(E)5-// /DFF2 (9) dff// “IO”I (-)4-// “I1”I (-)3-// clkI (C)7-/INV/out// dI (E)5-/DFF1/q// “OUT”O(E)6-ATPG>


NoteThere are special cases where C3 rule violations do not cause problems and can beignored. These cases are rare, however, so be sure you understand how your circuitbehaves versus what the tool simulates before deciding to ignore C3s.

There are two methods you can use to assure that valid C3 rule violations do not result insimulation mismatches:

• Split Capture Cycle

The first and preferred method is to enable the Set Split Capture_cycle command (thetool enables it automatically if you use Create Patterns -Auto). This forces a secondevaluation of the cells affected by C3 DRC violations. The additional evaluation allowsthe new data to propagate and in turn be captured into the sink gate. If additionalevaluation is required, a side effect of this command is an increase in simulation runtime. If the increase in run time is excessive, you may want to use the other method,capture handling.

NoteWhen you use “set split capture_cycle on”, you will still get C3 rule violations but youcan ignore them.

• Capture Handling

The second method of addressing C3 DRC violations is to use the Set Capture Handlingcommand. A side effect of this command is reduced test coverage if the number of C3sis significantly high. The item to consider is that only one simulation value is used for agiven source. As a result, the sink gates can only capture either new or old data. Giventhe case where a source drives two sinks and one sink captures old data and the other



sink captures new data, one of the sinks must capture X. The advantage of the SetCapture Handling command is there is no impact on ATPG run time.

Mentor Graphics recommends you use “set split capture_cycle on”. In cases where the impacton run time is severe and the number of C3 violations is small, then the use of capture handlingis recommended. Do not use both methods simultaneously, however.

Screening Out False C3 Violations

For performance reasons, the tool’s default DRC may occasionally report a false C3 violation.There are three additional analyses you can do to screen out these false C3s:

• Use the Set Drc Handling command with the Atpg_analysis option. This option causesDRC to additionally check the clocks of the source and sink to see if they are gated off.

• Enable the Set Sensitization Checking command. This checks if all paths from the Qoutput of the source to the sink are blocked when the source and sink clocks are on andall other clocks are off. When sensitization checking is on, the tool reports a C3 only ifsome path associated with the suspected violation is not blocked.

Tip: Use both commands to remove the maximum number of false C3 violations. Referto the “Description” section for additional details.

• For LSSD based designs, use the -Mode A option to the Set Drc Handling command.

When you specify this option for a selected clock, the rules checker evaluates all latchesassociated with the specified clock and categorizes their clock ports. It then uses thesecategories to determine if a violation exists. The following list describes each of theclock port categories:

o Inactive low (IL)When the selected clock is low, the clock port of the latch is inactive.

o Inactive high (IH)When the selected clock is high, the clock port of the latch is inactive.

o Active high slave (AHS)When the selected clock is high, the clock port of the latch is active. The data line ofthis latch connects (through buffers and inverters) to another latch called the datalatch. When the clock port of the latch is active, all clock inputs of the data latchmust be inactive. When the clock port of the latch is inactive, at least one clock inputof the data latch must be active. Finally, non-clock primary inputs must not affect theclock inputs of the data latch.

o Active low slave (ALS)When the selected clock is low, the clock port of the latch is active. The data line ofthis latch connects (through buffers and inverters) to another latch called the datalatch. When the clock port of the latch is active, all clock inputs of the data latch



August 2006

must be inactive. When the clock port of the latch is inactive, at least one clock inputof the data latch must be active. Finally, non-clock primary inputs must not affect theclock inputs of the data latch.

During this evaluation, the rules checker prints a summary message that identifies thenumber of latches with clock ports placed in each category. If you enable learn reportingwith “Set Learn Report On”, you can then use Report Gates to report on the individuallatches in these categories.

You can screen out false violations of the C3 rule by issuing the Set Drc Handlingcommand before rules checking. The command usage in this context is:

SET DRc Handling C3 [-Mode A clock_name]

The tool ignores violations of the C3 rule if the following conditions are true:

o The failing latch port is IL or AHS, and the source latch port is IH or ALS.

o The failing latch port is IH or ALS, and the source latch port is IL or AHS.

o All clock, set, and reset inputs of the failing latch are low in the case that all definedclocks are off, the violation source clock is high, and all other clock, set, and resetinputs of the source latch are low.

Related Commands

C4 (Clock Rule #4)

Description

When a sequential element (or RAM) source and sink are clocked by the same clock and theoutput of the source is connected through combinational logic to the clock port of the sink, apotential exists for the source’s captured data to alter the clocking of the sink in the same clockcycle. That is, the source’s new value (captured in the current cycle) might propagate throughthe connected logic and affect the clocking of the sink. By default, the tool expects the source’sold value (captured in the previous cycle) in the downstream combinational logic.

Add Capture HandlingReport GatesSet Capture HandlingSet Drc Handling

Set Gate ReportSet Learn ReportSet Sensitization CheckingSet Split Capture_cycle



Table 2-3 lists four clocking relationships that can produce this problem.

This condition violates the tool’s default assumption that the sink’s clocking is affected by onlyold data from the source, so results in a C4 violation and may require special handling. Failureto address this issue can result in simulation mismatches when you verify the test patterns in atiming-based simulator. Each sequential element is either level sensitive (LS), leading edgetriggered (LE), or trailing edge triggered (TE).

NoteAdequate special handling for most C4 situations is to simply issue “set splitcapture_cycle on” as explained under “Possible Resolutions” later in this section.

Figure 2-16 shows an example DFTInsight display of a circuit segment that produces a C4violation when the off state of the clock at the PI is defined as a logic 0. (In FastScan, FlexTest,and TestKompress, you define the off state of each clock with the Add Clocks command or withAnalyze Control Signals -Auto_fix as a part of required tool setups).


Figure 2-17 shows a possible timing scenario for the preceding circuit segment, where DFF1updates on the leading edge (LE) of the clock, while DFF2 updates on the clock’s trailing edge(TE) due to the gating of the CLK signal with the output of DFF1. Notice that the old value ofDFF1/q disables the clock input to DFF2. The tool’s default simulation will therefore predictthere will be no clock pulse to DFF2 and that it will hold its state as a result. But the leadingedge of CLK almost immediately enables the clock gate and DFF2’s clock port does receive a


Source Sink

LS LS

LS TE

LE LS

LE TE

dq

clk

DFF1

dff dq

clk

DFF2

dffCLK

PI

CE

Ci0i1C

NAND1EBout B

E

nand2



August 2006

pulse. So rather than holding state as the tool expects, DFF2 captures it’s D input value on theTE of the now enabled clock gate.

Figure 2-17. Example Where Actual Behavior Differs from Tool’s Prediction

The tool performs this check by determining the forward cones of influence for a clock pin (itsclock cones) and the forward cones of influence for each scan cell influenced by the clock pin(effect cones). For an introduction to clock and effect cones, refer to “Clock Cones and EffectCones” on page 2-50. The bounds for the cones are scan cells and circuitry set to a fixed valuewhen the constrained pins are set to their constrained values and the initialized non-scan cellsare set to their stable states.

NoteIn Figure 2-16, the clock input of DFF2 is in both the clock and effect cones of CLK asindicated by the “B” in the DFTInsight display. This is the main difference from a C3violation in which the clock input of the sink is in the clock cone but not in the effect coneand the data input is in the effect cone.

The rule violation occurs for a clock if one of the following is true:

• The clock input of a DFF state element is in both the clock and effect cones, the elementis trailing edge triggered, and the effect data comes from an element that is leading edgetriggered.

• The clock input of a LA state element is in both the clock and effect cones.

• The write input of a RAM is in both the clock and effect cones.

• The read input of a RAM is in both the clock and effect cones.

NEW VALUE

CLK

NAND1/out (DFF2/clk)

DFF1/q (NAND1/i0)

DFF2/q

capture cycle

DFF1/d

Actual

Predicted

LE TE

OLD VALUE

DFF2/d

Predicted

Actual



The tool performs a mutual exclusivity check to determine if the clock/write/read inputsassociated with the failure can be active at the same time. To obtain the most benefit from thischeck, turn on ATPG analysis prior to DRC by issuing the Set Drc Handling command with theAtpg_analysis argument. By default, the rules checker performs a partial ATPG analysis to findpotential C4 rule violations. This partial analysis justifies clock/data conflicts in the affectedcircuitry, but stops at decision nodes, RAM, ROM, TIEX, TLA, and all other non-scan stateelement gates. With complete ATPG analysis explicitly turned on, the rules checker justifies theconflicting values back to PIs or scan cells.

The Set Sensitization Checking command provides another way to slightly modify the handlingof this rule check. With “set sensitization checking on”, the tool additionally verifies that thepath between the source and sink gates of a suspected C4 violation can be sensitized with theclock ports of both gates active while all other clocks are off. By default, the Set SensitizationChecking command is turned off. By turning it on, you force the C4 check to report a violationonly if the suspected violation path can be sensitized.

The default handling of this rule violation is warning.

NoteIn some situations, violations of this rule may occur when there is no real problem withthe design. For information on performing enhanced checking to screen out these falseviolations, refer to “Screening Out False C4 Violations” on page 90.


Failure to satisfy this rule can result in inaccurate test pattern simulation results (simulationmismatches) during verification in a timing-based simulator and failing patterns on the tester.


For C4 violations, the tool transcripts a message similar to the following:

// Warning: There were N clock rule C4 fails (clock may be affected by itscaptured data).

N is the number of times a C4 violation occurred.

Use the Report Drc Rules command to obtain additional information about the violations. Forexample, to report the occurrence messages for all the C4s, use:

report drc rules c4

The occurrence messages list gate names and gate IDs you can copy and paste into commandsduring later debugging. You can report on a specific occurrence by issuing the command with“c4-” and the occurrence number. For example:




August 2006

//Warning: Clock /CLK failed rule C4 on input 3 of /DFF2 (9). (C4-1)// Source of violation: input 3 of /DFF1 (8).



To view the location of a C4 DRC violation using DFTInsight, use the following commandsteps:



Then choose Analyze > DRC Violation from the DFTInsight menu and select the desired C4DRC violation in the dialog box. DFTInsight will display the gates between the source cell andthe failing cell, including the clock cone data for the failing clock, as shown in Figure 2-16.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# and -Display arguments at the tool’s command line. For example:


NoteIn some situations, the tool’s analysis may require significant CPU run time. You caninterrupt the process and return to the command prompt using the Control-C key(intermediate results are not retained if you interrupt the analysis), or you can displayperiodic progress using the -Interval switch with the Set Drc Handling command.


To view the location of the first occurrence of a C4 DRC violation from the FastScan commandline, use the following example command steps (FlexTest and TestKompress would be similar):



3. Set Gate Report Clock_cone pin_name

4. Report Gates source_gate_id sink_gate_id


ATPG> report drc rules c4-1// Warning: Clock /CLK failed rule C4 on input 3 of /DFF2 (10). (C4-1)



// Source of violation: input 3 of /DFF1 (9)ATPG> set gate report clock_cone /CLKATPG> report gates /DFF1 /DFF2// /DFF1 dff// clk I (C)/CLK// d I (-) 1-// q O (E) 5-/DFF2/d /NAND1/i0// /DFF2 dff// clk I (B) 7-/NAND1/out// d I (-) 5-/DFF1/q// q O (-) 6-/q2ATPG>

You can see that the DRC violation is occurring because the clock input of /DFF2 is in both theclock and effect cones of /CLK.


NoteThere are special cases where C4 rule violations do not cause problems and can beignored. These cases are rare, however, so be sure you understand how your circuitbehaves versus what the tool simulates before deciding to ignore C4s.

There are two methods you can use to assure C4 rule violations do not result in simulationmismatches:

• Split Capture Cycle

The first and preferred method is to enable the Set Split Capture_cycle command (thetool enables it automatically if you use Create Patterns -Auto). This forces a secondevaluation of the cells affected by C4 DRC violations. The additional evaluation allowsthe new data to propagate and in turn be captured into the sink gate. If additionalevaluation is required, a side effect of this command is an increase in simulation runtime. If the increase in run time is excessive, you may want to use the other method,capture handling.

NoteWhen you use “set split capture_cycle on”, you will still get C4 rule violations but youcan ignore them.

• Capture Handling

The second method of addressing C4 DRC violations is to use the Set Capture Handlingcommand. A side effect of this command is reduced test coverage if the number of C4sis significantly high. The item to consider is that only one simulation value is used for agiven source. As a result, the sink gates can only capture either new or old data. Giventhe case where a source drives two sinks and one sink captures old data and the other



August 2006

sink captures new data, one of the sinks must capture X. The advantage of “set capturehandling” is there is no impact on ATPG run time.

Mentor Graphics recommends you use “set split capture_cycle on”. In cases where the impacton run time is severe and the number of C4 violations is small, then the use of capture handlingis recommended. Do not use both methods simultaneously, however.

Screening Out False C4 Violations

For performance reasons, the tool’s default DRC may occasionally report a false C4 violation.There are three additional analyses you can do to screen out these false C4s:

• Use the Set Drc Handling command with the Atpg_analysis option. This option causesDRC to additionally check the clocks of the source and sink to see if they are gated off.

• Enable the Set Sensitization Checking command. This checks if the path from the Qoutput of the source to the sink exists when the source and sink clocks are on and allother clocks are off. When sensitization checking is on, the tool reports a C4 only if thepath associated with the suspected violation meets these conditions.

Tip: Use both commands to remove the maximum number of false C4 violations. Referto the “Description” section for additional details.

• For LSSD based designs, use the -Mode A option to the Set Drc Handling command.

When you specify this option for a selected clock, the rules checker evaluates all latchesassociated with the specified clock and categorizes their clock ports. It then uses thesecategories to determine if a violation exists. The following list describes each of theclock port categories:

o Inactive low (IL)When the selected clock is low, the clock port of the latch is inactive.

o Inactive high (IH)When the selected clock is high, the clock port of the latch is inactive.

o Active high slave (AHS)When the selected clock is high, the clock port of the latch is active. The data line ofthis latch connects (through buffers and inverters) to another latch called the datalatch. When the clock port of the latch is active, all clock inputs of the data latchmust be inactive. When the clock port of the latch is inactive, at least one clock inputof the data latch must be active. Finally, non-clock primary inputs must not affect theclock inputs of the data latch.

o Active low slave (ALS)When the selected clock is low, the clock port of the latch is active. The data line ofthis latch connects (through buffers and inverters) to another latch called the datalatch. When the clock port of the latch is active, all clock inputs of the data latch



must be inactive. When the clock port of the latch is inactive, at least one clock inputof the data latch must be active. Finally, non-clock primary inputs must not affect theclock inputs of the data latch.

During this evaluation, the rules checker prints a summary message that identifies thenumber of latches with clock ports placed in each category. If you enable learn reportingwith “set learn report on”, you can then use Report Gates to report on the individuallatches in these categories.

You can screen out false violations of the C4 rule by issuing the Set Drc Handlingcommand before rules checking. The command usage in this context is:

SET DRc Handling C4 [-Mode A clock_name]

The tool ignores violations of the C4 rule if the following conditions are true:

o The source latch port is IL or AHS and all paths from the source latch to the failinglatch are blocked when the selected clock is high.

o The failing latch port is IH or ALS and all paths from the source latch to the failinglatch are blocked when the selected clock is low.

o The violation source clock input is high and all other clock, set, and reset inputs arelow for the source latch.

Related Commands

C5 (Clock Rule #5)A clock pin must not be capable of simultaneously capturing data on multiple ports of the samescannable memory element. The application performs this check by determining the forwardcone of influence for a clock pin (clock cone). The bounds for the cone of influence are scancells and circuitry set to a fixed value when constrained pins are set to their constrained value,and initialized non-scan cells are set to their stable state.

The rule violation occurs on a clock pin when multiple clock inputs of a scannable memoryelement are in the same clock cone and the clock inputs may be on at the same time. The toolperforms a mutual exclusivity check to determine if both clock inputs associated with the failurecan be active at the same time. If the justification results in a conflict without justifying decisionnodes, it will not be considered a rules violation.

Add Capture HandlingReport GatesSet Capture HandlingSet Drc Handling

Set Gate ReportSet Learn ReportSet Sensitization CheckingSet Split Capture_cycle



August 2006

The default handling for this rule violation is warning. Failure to satisfy this rule may result in arace condition that creates inaccurate simulation results. When an error condition occurs, youcan access the cone data by setting the gate reporting to error_pattern and using the Report Gatecommand for the gate ID number displayed in the error message. This identifies the probleminput, and by tracing back from this input, you can identify how to correct the problem. Cindicates clock cone, E indicates effect cone, B indicates both, and “-” indicates no cone.


Clock P failed rule C5 on input I of N (G). (C5-1)

P is the pin name of the clock, C5 is the rule ID number, I is the gate input number of the clockline, N is the instance name of the gate, and G is the gate ID number.


There were N clock rule C5 fails (clock is connected to multiple ports ofsame latch).





If you run rules checking on this design given the setup commands shown, you will get a C5rules violation. In this design, the RST signal connects to both the PRE and CLR pins of the

D Q

QBCLR

PRE Q

VCC

VCC

D

CLK

Q

QBCLR

PRE SC_OUT

SETUP> add clock 0 CLK

SETUP> add clock 0 RST

CLK

SC_IN

SC_EN

CLK

A

NOTA

RST



second flip-flop. If you examine the inputs, you should see that A and NOTA should alwayshave opposite values. If the tool knows this information, it knows that only one of the CLR orPRE signals can be active at any given time. To specify this information and fix the C5 rulesviolation, add the command:

SETUP> add pin equivalence a -inv nota

C6 (Clock Rule #6)A clock must not affect data that it is capturing. If it does, a race condition may result thatproduces inaccurate simulation results. The application performs this check by determining theforward cone of influence for a clock pin (clock cone). The bounds for the clock cone are scancells and circuitry set to a fixed value when constrained pins are set to their constrained valuesand initialized non-scan cells are set to their stable states. The rule violation occurs on a clockpin when a clock input of a scannable memory element and its data line are in the same clockcone.

The default handling for this rule violation is warning. When a violation occurs, you can accessthe clock cone data by setting the gate reporting to error_pattern, then issuing the Report Gatecommand for the gate ID number displayed in the occurrence message. This identifies theproblem input. By tracing back from this input, you can identify how to correct the problem. Cindicates clock cone, E indicates effect cone, B indicates both, and “-” indicates no cone.





There were N clock rule C6 fails (clock may capture data affected byitself).

N is the number of times a C6 rule violation occurred.





August 2006


If you ran rules checking on this design, given the setup commands shown, you would get a C6rules violation. The default handling for this rule violation is warning. In this design, the CLKsignal goes to both the CLK and D inputs of the first flip-flop. Thus, data can be captured in thisflip-flop that may be affected by the capturing clock. To prevent the CLK signal frominfluencing the data, add the command:

SETUP> add pin constraint SC_EN c0

Constraining the SC_EN signal to 0 ensures that changes in the clock will not change the data.

In FastScan and TestKompress, you can handle C6 rule violations by issuing a “set clock_offsimulation on” command prior to creating patterns. See the Set Clock_off Simulation commanddescription in the ATPG and Failure Diagnosis Tools Reference Manual for additionalinformation.

C7 (Clock Rule #7)Each clock input (not including set and reset lines) of a scan or non-scan cell memory elementmust be capable of capturing data when a single clock primary input line is on and all otherclocks are off. It is acceptable that this may require placing values on non-clock primary inputsor scan cells. The application performs this check using the simulated values that result whenone clock is set to X, all other defined clocks are at their off-state, the constrained pins are set totheir constrained values, and the initialized non-scan cells are set to their stable states. The ruleviolation occurs when a clock input of a scan cell always remains off.

The default handling for this rule violation is warning. Failure to satisfy this rule indicates ascan cell clock input cannot capture data, resulting in some loss of test coverage.

D Q

QBCLR

PRE Q

VCC

VCC

D

CLK

Q

QBCLR

PRE SC_OUT


SETUP> add clock 0 RST

CLK

SC_IN

SC_EN

CLK

A

NOTA

RST




Clock input I of N (G) cannot capture data with a single clock on. (C7-1)

I is the input number, N is the instance name, G is its gate index number, and C7 is the rule IDnumber.


There were N clock rule C7 fails (scan cell capture ability check).





If you run rules checking on this design given the setup commands shown, you will get a C7rules violation. This type of error commonly occurs when incorrect clock or set/reset gatingoccurs in the design. This design constrains the SCAN_MODE signal to a constant 0 duringATPG. This constraint prevents the first flip-flop from ever being clocked, and from evercapturing data. To fix this problem, delete the pin constraint:

SETUP> delete pin constraint -all

D Q

QB

CLR

PREQ Q

CLK

CLR

SCAN_CLKSCAN_MODE

D

PRE

SETUP> add clock 1 PRE CLR

SETUP> add clock 0 SCAN_CLK

SETUP> add pin constraint SCAN_MODE c0

D Q

QB

CLR

PRE

CLK



August 2006

C8 (Clock Rule #8)You may not directly connect a clock to a primary output (PO). The application performs thischeck by determining the forward cone of influence for a clock pin (clock cone). The bounds forthe cone of influence are scan cells and circuitry set to a fixed value when constrained pins areset to their constrained values, and initialized non-scan cells are set to their stable states. Therule violation occurs when a primary output is in the clock cone.

The default handling for this rule violation is warning. Failure to satisfy this rule will result inthe occasional usage of a different type of scan pattern, in which the tool observes only the POsdirectly connected to clocks. There will be no loss of test coverage or risk of inaccuratesimulation results. When an error condition occurs, you can access the cone data by setting thegate reporting to error_pattern and using the Report Gate command for the gate ID numberdisplayed in the error message. This identifies the problem input, and by tracing back from thisinput, you can identify how to correct the problem. C indicates clock cone, E indicates effectcone, B indicates both, and “-” indicates no cone.


Primary output P is connected to clock C. (C8-1)

P is the pin name of the primary output and C is the pin name of the clock.


There were N clock rule C8 fails (PO connected to a clock line).







If you run rules checking on this design given the setup commands shown, you will get two C8rules violation. This type of violation is not usually a problem.

In this example, the connection of the PRE and CLR lines (which the tool considers clock lines)to the design’s primary outputs causes the violations. The only way to get rid of these violationsis to deliberately hold CLR and PRE off, but this would result in a number of ATPG untestablefaults. A more acceptable solution is to accept this warning, or turn it off with the command:

ATPG> set drc handling c8 ignore

C9 (Clock Rule #9)Data captured by any clock with a direct path (through combinational logic only) to a primaryoutput must not affect the direct path to a primary output of that same clock. The applicationperforms this check by determining the forward cone of influence for a clock pin (clock cone)and for each scannable memory element influenced by the clock pin (effect cone). The boundsfor the cones of influence are scan cells and circuitry set to a fixed value when constrained pinsare set to their constrained values and initialized non-scan cells are set to their stable states. Therule violation occurs on a clock pin when a primary output is in both the clock cone and theeffect cone.

The default handling for this rule violation is warning. Failure to satisfy this rule may result in asmall loss in test coverage. There will be no risk of inaccurate simulation results. When an errorcondition occurs, you can access the cone data by setting the gate reporting to error_pattern andusing the Report Gate command for the gate ID number displayed in the error message. Thisidentifies the problem input, and by tracing back from this input, you can identify how to correctthe problem. C indicates clock cone, E indicates effect cone, B indicates both, and “-” indicatesno cone.




PRE

SC_IN

CLK

CLRA

SC_OUT

CLRA

D Q

QB

CLR

PRE

CLK



August 2006

PO P path from clock C is gated by scan cell that uses same clock. (C9-1)

P is the pin name of the primary output and C is the pin name of the clock.


There were N clock rule C9 fails (PO connected to a clock line gated byscan cell that uses same clock).





If you run rules checking on this design given the setup commands shown, you will get a C9rule violation. This type of violation is not usually a problem. However, a C9 violation canresult in reduced coverage because it may introduce sequential effects into the generated clockpatterns. In this case, the violation is at the SC_OUT line. The PRE signal can affect the data ofthe flip-flop and the gate at the output of the scan cell. The only way to get rid of this violationis to deliberately hold PRE off, but this would result in a number of ATPG untestable faults. Amore acceptable solution is to accept this warning, or turn it off with the command:

ATPG> set drc handling c9 ignore

C10 (Clock Rule #10)A sequential element (latch or flip-flop) can only be clocked once in any one pattern cycle.FastScan and TestKompress will only pulse a clock primary input once in each cycle, or apply aclock procedure only once, therefore a failure of this rule implies that the circuit generates twoor more internal pulses from a single clock pulse or clock procedure.



PRE

SC_IN

CLK

CLRA

SC_OUT

CLRA

D Q

QB

CLR

PRE

CLK



The default handling of this rule violation is error. Failure to satisfy this rule will result increation of patterns which are likely to be incorrect and to fail both in verification and on thetester.


Cell c might capture more than once by applying clock ck. (C10-1)

Figure 2-23 shows an example circuit which will generate a C10 error in FastScan.


In order to remove the violation, the circuit must be modified. Test logic can be added to blockthe path from one pulse generator to the OR gate during test mode.

NoteIt is also possible to violate this rule by OR-ing together two clocks which are pulsed atdifferent times in a clock procedure.

C11 (Clock Rule #11)Due to FlexTest, the Vector Interfaces code requires that every shift cycle uses one test cycle,all shift clocks (clocks in shift procedure) have to use returned waveform (SR0, SR1, R0, R1,CR0, CR1). This rule is only checked by FlexTest.

The default handling for this rule violation is error. The usual cause of this error condition is notdefining shift clock pin constraints properly.


Shift clock C has invalid pin constraint type T.(C11-1)

C is the pin name of the clock. T is the violating pin constraint type (NR, C0, C1, CX, CZ).


There were N shift clocks with invalid pin constraint. (C11)

delay=30, width=10

CLK

delay=10, width=10



August 2006


C12 (Clock Rule #12)FlexTest requires users to specify the pin waveform for every primary pin. In general everyclock should have returned waveforms (SR0, SR1, R0, R1, CR0, CR1). Since C11 checks shiftclocks already, C12 checks non-shift clocks only. Note that this rule is only checked byFlexTest.

The default handling for this rule violation is warning. The usual cause of this error condition isnot defining clock pin constraints properly.


Non-shift clock C has invalid pin constraint type T.(C12-1)

C is the pin name of the clock. T is the violating pin constraint type (NR, C0, C1, CX, CZ).


There were N non-shift clocks with invalid pin constraint. (C12)


C13 (Clock Rule #13)The C13 clock rule violation is intended to detect sequential loops involving multipleoverlapping clocks. This is an expansion of the C3 clock rule. This violation occurs if all of thefollowing statements are true:

• There exists a potential sequential loop involving one or more interacting clocks (forexample, back-to-back latches clocked at the same time).

• The clock inputs of all scan latches in the loop are in the clock cone and at least one ofthe data inputs of the latches are in the effect cone of a different, butinteracting/overlapping, clock.

• The tool's mutual exclusivity checking determines that the clock inputs associated withthe failure can be active at the same time.

The default handling for rule C13 is ignore. Failure to satisfy this rule may result in a racecondition involving multiple clocks that create inaccurate simulation results.

When an error condition occurs, you can access the cone data by setting the gate reporting toerror_pattern and using the Report Gate command for the gate ID number displayed in the errormessage. This identifies the clock input that has a problem. You can identify the source of theproblem by tracing back from this input.







There were N clock rule C13 fails (captured data affected by multipleinteracting clocks).


Figure 2-24 shows an example circuit which will generate a C13 error in FlexTest.


In this example, clkA is defined as a clock with off-state = 0 and a pin constrained waveformSR0 1 1 1; clkB is defined as a clock with off-state = 1 and a pin constrained waveform SR1 1 11. In timeframe 1, both clkA and clkB can potentially be on. Since a sequential loop canpossibly occur if both clocks are on, a C13 violation is reported. To correct this violation, thetwo clocks must not overlap; changing the pin constraint waveform for clock clkB to SR1 1 0 1fixes this violation.

C14 (Clock Rule #14)The C14 clock rule expands the C4 clock rule to handle multiple overlapping clocks. A C14 ruleviolation occurs on a group of clocks if all of the following statements are true:

• The clock input of a scan latch is in both the clock cone and the effect cone of anotherinteracting/overlapping clock.

• The tool's mutual exclusivity checking determines that the clock inputs associated withthe failure can indeed be active at the same time.

clkA

clkB

EN

EN

D

DIN

OUT



August 2006

The default handling for rule C14 is ignore. Failure to satisfy this rule may result in spuriouspulses on clock inputs that might latch invalid data which creates inaccurate simulation resultsand may cause the generation of invalid patterns.






There were N clock rule C14 fails (clock may be affected by a captureddata of one of multiple interacting clocks).




In this example, clkA is defined as a clock with off-state = 0 and a pin constrained waveformSR0 1 1 1; clkB is defined as a clock with off-state = 1 and a pin constrained waveform SR1 1 11. In timeframe 1, both clkA and clkB can potentially be on. This causes the effect cone of clockclkA and the clock cone of clkB to reach the clock input of the second latch; thus a C14violation is reported. To correct this violation, the two clocks must not overlap; changing the pinconstraint waveform for clock clkB to SR1 1 0 1 fixes this violation.

C15 (Clock Rule #15)The C15 clock rule expands the C6 clock rule to handle multiple overlapping clocks. A C15 ruleviolation occurs on a group of clocks if all of the following statements are true:

clkA

clkB

EN

EN

D

D

OUT



• The clock and data input of a scan latch are in the clock cone of two different, butinteracting/overlapping, clocks.

• The tool's mutual exclusivity checking determines that the clock inputs associated withthe failure can indeed be active at the same time.

The default handling for rule C15 is ignore. Failure to satisfy this rule may result in a racecondition where data may arrive before the clock; therefore creating inaccurate simulationresults and causing the generation of invalid patterns.






There were N clock rule C15 fails (clock may capture data affected by oneor more multiple interacting clocks).




In this example, clkA is defined as a clock with off-state = 0 and a pin constrained waveformSR0 1 1 1; clkB is defined as a clock with off-state = 1 and a pin constrained waveform SR1 1 11. In timeframe 1, both clkA and clkB can potentially be on. Since the data input of the latch isin the clock cone of clock clkA and the clock input of the latch is also in the clock cone of bothclkA and clkB, a C15 violation is reported. To correct this violation, the two clocks must notoverlap; changing the pin constraint for clock clkB to SR1 1 0 1 fixes the violation.

clkA

clkB EN

D

IN

OUT



August 2006

C16 (Clock Rule #16)When switching from the load_unload phase to the capture phase, sometimes the loading valuesof scan cells can be disturbed due to pin constraints specified in the capture phase. The C16clock rule checks for this situation and issues a violation if it occurs.

For example, consider a DFF scan cell with two clock ports: the first port is used for scanloading and the second is used for normal operation. Assume the second port’s clock signal(whose off state is defined as 1) is ANDed with an enable signal to produce the actual clockinput value. If in the load_unload procedure the enable is forced to 0, the load value cannot bedisturbed by the second clock port during scan loading. However, if you issued an Add PinConstraint command in Setup mode to set the enable signal to 1, the scan load value can bedisturbed at the start of the capture cycle when switching from load_unload to capture. This isbecause the clock input at the second port will change from 0 to 1 when the enable changes from0 to 1 as a result of the pin constraint.

NoteThe C16 rule check will ignore an X at a scan cell’s clock port, as it is possible to assigna proper value at the PIs to keep the scan cell stable at the beginning of the capture phase.Xs on scan cell clock ports will, however, cause C1 (Clock Rule #1) violations.

The default handling for rule C16 is error. Failure to satisfy this rule may result in simulationmismatches during verification.

To debug a C16 rule violation, issue a “set gate report error_pattern” command, then use ReportGates for the gate instance named in the C16 occurrence message.

CautionIf you choose to ignore C16 violations (not recommended), you should add a CX cellconstraint to each scan cell where a violation occurred—in order to avoid simulationmismatches. Be aware that each cell you constrain in this manner reduces test coverage.You can obtain the instance name of the scan cell from the occurrence message and usethe Add Cell Constraints command to apply the constraint to the cell’s output pin. Forexample:report drc rule c16// Warning: The load value of scan cell /dff2/dff1/Q_reg (47) is disturbed by clock input 3at the beginning of the capture phase when pin constraints are forced. (C16-1)add cell constraints /dff2/dff1/Q_reg/Q CX


The load value of scan cell N is disturbed by clock input I at thebeginning of the capture phase when pin constraints are forced. (C16-1)

N is the instance name of the gate, I is the gate input number of the clock line, and C16 is therule ID number.




There were N clock rule C16 fails (scan cell load value disturbed atbeginning of capture phase when pin constraints are forced).


RAM Rules (A Rules)The tool checks RAM gates to identify proper test methods. You can select the handling of anyRAM rule to be error, warning, note, or ignore. The following subsections describe each of theRAM rules.

A1 (RAM Rule #1)When all write control lines are at their off-state, all write, set, and reset inputs of RAMs mustbe at their inactive state. The tool performs this check using the simulated values that resultwhen all defined write control lines are at their off-state, the constrained pins are set to theirconstrained values, and the initialized non-scan cells are set to their stable states. The ruleviolation occurs if any write, set, or reset input of any RAM gate is not off.

The default handling for this rule violation is a warning. When an error condition occurs, youcan access the simulated values by setting the gate reporting to error_pattern and using theReport Gate command for the gate ID number displayed on the error message. This identifiesthe input that is not held off, and by tracing back from this input, you can identify how to correctthe problem. The usual cause of this error condition is not defining all write control lines(including those that are RAM set and reset lines) or defining the wrong off-state.


Write controls off failed to force off RAM T line of N (G). (A1-1)

T is the type of input (write, set, or reset), N is the instance name of the RAM gate, G is the gateID number, and A1-1 is the rule and violation ID number.


N RAM write/set/reset lines not forced off when write controls are off.(A1)

N is the number of occurrences of rules violation A1.

A2 (RAM Rule #2)A defined scan clock must not propagate to a RAM gate, except for its read lines. The toolperforms this check by determining the forward cone of influence for all clock pins (clockcone). The bounds for the cone of influence are scan cells and circuitry set to a fixed value when



August 2006

constrained pins are set to their constrained values and the initialized non-scan cells are set totheir stable states. The rule violation occurs when a RAM gate is in a clock cone.

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the cone data by setting the gate reporting to error_pattern and using the Report Gatecommand for the gate ID number displayed in the error message. This identifies the probleminput, and by tracing back from this input, you can identify how to correct the problem. Cindicates clock cone, W indicates write control line cone, B indicates both, and “-” indicates nocone.


Scan clock is connected to RAM N (G). (A2-1)

N is the instance name of the RAM gate and G is the gate ID number.


N RAMs are connected to a scan clock. (A2)


A3 (RAM Rule #3)A write or read control line must not propagate to an address line of a RAM gate. The toolperforms this check by determining the forward cone of influence for all write and read controllines (write/read cone). The bounds for the cone of influence are scan cells, RAM gates, andcircuitry set to a fixed value when constrained pins are set to their constrained values and theinitialized non-scan cells are set to their stable states. The rule violation occurs when an addressline of a RAM gate is in the write/read cone.

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the cone data by setting the gate reporting to error_pattern and using the Report Gatecommand for the gate ID number displayed in the error message. This identifies the probleminput, and by tracing back from this input, you can identify how to correct the problem. Cindicates clock cone, W indicates write/read control line cone, B indicates both, and “-”indicates no cone.


RAM control line connected to address input of RAM N (G). (A3-1)



N RAM address inputs are connected to a RAM control line. (A3)




A4 (RAM Rule #4)A write or read control line must not propagate to a data line of a RAM gate. The tool performsthis check by determining the forward cone of influence for all write and read control lines(write/read cone). The bounds for the cone of influence are scan cells, RAM gates, and circuitryset to a fixed value when constrained pins are set to their constrained value, and the initializednon-scan cells are set to their stable stated. The rule violation occurs when a data-in line of aRAM gate is in the write/read cone.

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the cone data by setting the gate reporting to error_pattern and using the Report Gatecommand for the gate ID number displayed in the error message. This identifies the probleminput, and by tracing back from this input, you can identify how to correct the problem. Cindicates clock cone, W indicates write/read control line cone, B indicates both, and “-”indicates no cone.


RAM control line connected to data input of RAM N (G). (A4-1)



N RAM data inputs are connected to a RAM control line. (A4)


A5 (RAM Rule #5)A RAM gate must not propagate to another RAM gate. The tool performs this check bydetermining the forward cone of influence for all RAM gates (RAM cone). The bounds for thecone of influence are scan cells, RAM gates, and circuitry set to a fixed value when constrainedpins are set to their constrained values and the initialized non-scan cells are set to their stablestates. The rule violation occurs when an input of a RAM gate is in the RAM cone.

The default handling for this rule violation is warning. The occurrence message is:

RAM N1 (G1) connected to RAM N2 (G2). (A5-1)

N1 is the instance name of one RAM gate, G1 is its gate ID number, N2 is the instance name ofthe other RAM gate, and G2 is its gate ID number.


N RAMs are connected to RAMs. (A5)



August 2006


A6 (RAM Rule #6)All the write inputs of all RAMs and all the read inputs of all data_hold RAMs must be at theiroff-state during all test procedures, except test_setup. The tool performs this check using thesimulated values that result when it simulates the test procedures. The rule violation occurs ifany write, set, or reset input of any RAM, or a read input of a data_hold RAM is not off.

The default handling for this rules violation is warning. Failure to satisfy this rule for writeinputs results in the RAM being unavailable to hold its contents during scan operation, whichmay cause a loss in test coverage. When an error condition occurs, you can access the simulatedvalues by setting the gate reporting to error_pattern and using the Report Gate command for thegate ID number displayed in the error message. This identifies the input that is not held off, andby tracing back from this input, you can identify how to correct the problem. The usual cause ofthis error condition is not defining all write or read control lines, or defining the wrong off-state.

NoteThis is the only rule that FlexTest runs for RAM checking.


L line of RAM N (G) not off during time T of P procedure. (A6-1)

L is the type of input (write, read, set, or reset), N is the instance name of the RAM gate, G is thegate ID number, T is the time, and P is the procedure name.


There were N occurrences of uncontrolled RAMs during test procedures.(A6)


A7 (RAM Rule #7)When all read control lines are at their off-state, all read inputs of RAMs with the read_offattribute set to hold must be at their inactive state. The tool performs this check using thesimulated values that result when all defined read control lines are at their off-state, theconstrained pins are set to their constrained values, and the initialized non-scan cells are set totheir stable states. The rule violation occurs if any read input of a data_hold RAM gate is notoff.

The default handling for this rules violation is warning. When an error condition occurs, youcan access the simulated values by setting the gate reporting to error_pattern and using the



Report Gate command for the gate ID number displayed in the error message. This identifies theinput that is not held off, and by tracing back from this input, you can identify how to correct theproblem. The usual cause of this error condition is not defining all read control lines or definingthe wrong off-state.


Read controls off failed to force off RAM read line of N (G). (A7-1)



N RAM read lines not forced off when read controls are off. (A7)


A8 (RAM Rule #8)Due to FlexTest, ATPG requires you to turn off write operations for each read operation. EveryRAM must have a way to turn-off its write operation. The tool performs this check using thesimulated values that result when all the constrained pins are set to their constrained values. Therule violation occurs if any write port of a RAM gate is active. This rule is only checked byFlexTest.

The default handling for this rules violation is warning. When an error condition occurs, youcan access the simulated values by setting the gate reporting to error_pattern and using theReport Gate command for the gate ID number displayed in the error message. This identifies theactive write port, and by tracing back from this input, you can identify how to correct theproblem. The usual cause of this error condition is not defining the write operation properly.


Write cannot be disabled for RAM N (G).(A8-1)



There were N RAM where write cannot be disabled. (A8)


BIST Rules (B Rules)Whenever LFSRs are defined, LBISTArchitect performs BIST rules checking to ensure properapplication of BIST patterns to the circuit. You cannot change the handling of the BIST rules



August 2006

from their default conditions of either error or warning—with the exception of rule B2. Thefollowing subsections describe each of the BIST rules.

B1 (BIST Rule #1)Every defined LFSR must have at least one specified tap position. Correct this error conditionby adding a tap position to the indicated LFSR. The error message is:

Tapping not defined for LFSR N. (B1-1)

N is the name of the LFSR.

B2 (BIST Rule #2)Every scan chain input pin must connect to an LFSR. Correct this error condition by connectingthe scan chain input pin of the indicated chain to an LFSR. You can change how the ruleschecker handles this check with the Set Drc Handling command.


Input of chain C has no LFSR connection. (B2-1)

C is the name of the scan chain.

B3 (BIST Rule #3)The LFSR that connects to a scan chain input pin must not be of type parallel. Correct this errorcondition by connecting the scan chain input pin of the indicated chain to an LFSR of type serialor both.


Input of chain C connected to parallel shift LFSR. (B3-1)


B4 (BIST Rule #4)Every scan chain output pin must connect to an LFSR. Correct this error condition byconnecting the scan chain output pin of the indicated chain to an LFSR.


Output of chain C connected to parallel shift LFSR. (B4-1)




B5 (BIST Rule #5)The LFSR that connects to a scan chain output pin must not be of type parallel. Correct thiserror condition by connecting the scan chain output pin of the indicated chain to an LFSR oftype serial or both.


Output of chain C connected to parallel shift LFSR. (B5-1)


B6 (BIST Rule #6)An LFSR that connects to a primary input that is not a scan chain input pin must not be of typeserial. Correct this error condition by connecting the indicated primary input pin to an LFSR oftype parallel or both. The error message is:

Non-scan-in pin PI N connected to serial PRPG L. (B6-1)

N is the name of the primary input, and L is the name of the LFSR functioning as a PRPG.

B7 (BIST Rule #7)An LFSR that connects to a primary output that is not a scan chain output pin must not be oftype serial. Correct this error condition by connecting the indicated primary output pin to anLFSR of type parallel or both. The error message is:

Non-scanout PO N connected to serial MISR L. (B7-1)

N is the name of the primary output and L is the name of the LFSR functioning as a MISR.

B8 (BIST Rule #8)A clock cannot connect to an LFSR. Correct this error condition by deleting the connectionbetween the indicated clock pin and the indicated LFSR. This rule is currently unnecessarybecause the tool checks these conditions when adding LFSRs or clocks.


Clock N cannot be connected to a PRPG L. (B8-1)

N is the name of the clock pin, and L is the name of the LFSR functioning as a PRPG.



August 2006

B9 (BIST Rule #9)A constrained pin cannot connect to an LFSR. Correct this error condition by deleting theconnection between the indicated pin and the indicated LFSR, or by deleting the pin constraint.The error message is:

Constrained pin N cannot be connected to a PRPG L. (B9-1)

N is the name of the constrained pin and L is the name of the LFSR functioning as a PRPG.

B10 (BIST Rule #10)An equivalent pin cannot connect to an LFSR. Correct this error condition by deleting theconnection between the indicated pin and the indicated LFSR, or by deleting the pinequivalence. The error message is:

Equivalent pin N cannot be connected to a PRPG L. (B10-1)

N is the name of the equivalent pin, and L is the name of the LFSR functioning as a PRPG.

B11 (BIST Rule #11)A primary output pin that connects to a clock cannot connect to an LFSR. Correct this errorcondition by deleting the connection between the indicated pin and the indicated LFSR. Theerror message is:

Clock_PO N cannot be connected to a MISR. (B11-1)

N is the name of the primary output pin.

B12 (BIST Rule #12)During simulation of 32 LFSR-generated patterns, the LFSR values must not repeat. Correctthis warning condition by creating a larger LFSR that is maximally configured. Sometimes, youmay be able to correct the condition by choosing a different seed for the indicated LFSR. Thewarning message is:

LFSR L repeats after N shifts. (B12-1)

L is the name of the LFSR, and N is the number of shifts before repeating.

B13 (BIST Rule #13)When the tool places constrained states on constrained pins and binary states on PIs and scancells, X states must not propagate to an observable point. Failure to satisfy this rule will result inthe risk of X states propagating to an observable point. This is a serious condition for BISTcircuits, but has no effect for deterministic testing.



The tool performs this check on gates that can create an X state with their inputs at binaryvalues. It will not consider gates that do not have a path to an observable point, or that have allpaths blocked by tied or constrained circuitry. The tool checks for the following conditions:

• A violation on a wired gate (WIRE) occurs if the tool can place different values on itsinputs and the net resolution is set to wire.

• A violation on a BUS gate occurs if more than one of the BUS-connected tri-statedrivers or switches turn on simultaneously, or all drivers turn off simultaneously and theZ state behaves as an X.

• A violation on a tri-state driver gate (TSD) or a switch gate (SW) occurs if it does notconnect to a BUS gate. You can turn off the enable line, and the Z state behaves as an X.

• A violation on a TIE-X gate occurs if the gate is locally sensitizable up to the pointwhere it has multiple fanouts (or observable points).

• A violation on a transparent latch (TLS) occurs if a single clock line is not set to its on-state, or the set and reset lines are not off.

• A violation on a ROM or RAM gate occurs if you can set a read line to off, the read_offvalue is X, and an output is sensitizable when the read line is off.

• A RAM/ROM violation also occurs if any memory element is uninitialized and anoutput is sensitizable to an observation point.

The default handling for this rule violation is warning, atpg_analysis. When an error conditionoccurs, you can access the tied/constrained simulated values by setting the gate reporting toparallel_pattern and using the Report Gate command for the gate ID number displayed in theerror message. By tracing back and forward from this gate, you can identify why the erroroccurred.


T gate N (G) may have an observable X-state. (B13-1)

T is the gate type, N is the instance/net name of the gate, and G is the gate ID number.


N gates may have an observable X-state. (B13)

N is the number of occurrences of rules violation B13.

B14 (BIST Rule #14)The drivers of wire gates must not be capable of driving opposing binary values. The toolperforms this check by attempting to satisfy the placement of opposing binary values on allcombinations of the two drivers of a wire gate. The rule violation occurs at a wire gate if it ispossible to satisfy those conditions for at least one combination of drivers. When a violation



August 2006

occurs, the tool identifies the failing wire gate and the drivers capable of being placed atopposing values.

This rule ensures that there is no possible contention (for the good machine) on wire gates. Thetool will not perform this rule check on wire gates whose behavior you changed to AND or ORusing the Set Net Resolution command. Also, the tool does not consider pin constraints andequivalences with this check.

The default handling for a violation of this rule is set to error. A violation of this rule indicatesthe possibility that patterns exist that have contention on wire gates. The occurrence message is:

WIRE gate N (G) has possible contention on drivers G1 and G2. (B14-1)

N is the gate name of the wire gate, G is its gate ID number, and G1 and G2 are the gate IDnumbers of the driver gates.


There were N WIRE gates which may have possible contention. (B14)

N is the number of occurrences of rules violation B14.

B15 (BIST Rule #15)This rule performs bus contention mutual-exclusivity checking. This checking differs from ruleE4 in that it does not check for this condition during test procedures. This check analyzes eachdominant strong bus to determine if it can cause contention. As a result, the analysis places eachbus in one of the following categories:

• Pass - Test generation analysis determines a contention condition cannot occur.

• Fail - Test generation analysis identifies a possible contention condition.

• Abort - Test generation analysis terminated while attempting to determine if acontention condition could occur.

• Bidi - Test generation determines that the bidirectional pin (which can only have asingle tri-state driver) can potentially create a contention condition.

NoteThe pass category generally contains bidirectional pins of buses with mutual exclusivity.Likewise, the fail category generally contains bidirectional pins of all other buses.

Buses in both the fail and abort categories violate this rule. Buses in the bidi category stillrequire checking in downstream processes because they do not exhibit natural mutual-exclusivity behavior and can potentiality cause contention. Buses in the pass category requireno further checking by downstream processes.



The default settings for this rule are error and atpg_analysis. You can change the handling withthe Set Drc Handling command. For more information on ATPG analysis, refer to “Turning onATPG Analysis” on page 26.

The Sequential option of the Set Drc Handling command considers the inputs to a single level ofsequential cells behaving as “staging” latches in the enable lines of tri-state drivers. All of thelatches found in a back trace must share the same clock. There must also be only a singleclocked data port on each cell, and both set and reset inputs must be tied (not pin constrained) tothe inactive state. This check ensure that there is no connectivity from the cells in the input coneof the sequential cells and enables of the tri-state devices except through the sequential cells.


BUS gate N (G) has possible contention on drivers G1 and G2. (B15-1-A)

N is the gate name of the bus gate, G is its gate ID number, and G1 and G2 are the gate IDnumbers of the driver gates. The -A following the violation ID number indicates the checkaborted.


There were N BUS gates which may have possible contention. (B15)

N indicates the number of buses failing the B15 rule.

A B15A rule violation indicates a rule failure where the ATPG analysis is aborted. In thisinstance, it may be useful to increase the ATPG effort to pass the possible “fails”.

B16 (BIST Rule #16)This rule checks for the ability of a bus gate to attain a Z state. This check analyzes eachdominant strong bus to determine if conditions can place a Z value on the bus gate. As a result,the analysis places each bus in one of the following categories:

• Pass - Test generation analysis determines that no condition could place a Z value on thebus gate.

• Fail - Test generation analysis determines that conditions could place a Z value on thebus gate.

• Abort - Test generation analysis terminated while attempting to determine if conditionscould place a Z value on the bus gate.

• Bidi - The bus is a bidirectional bus.

Buses in both the fail and abort categories violate this rule.



August 2006

The default settings for this rule are warning and atpg_analysis -mode z. You can change thehandling with the Set Drc Handling command. For more information on ATPG analysis, referto “Turning on ATPG Analysis” on page 26.


BUS gate N (G) is capable of attaining a Z state. (B16-1-A)

N is the gate name of the bus gate, and G is its gate ID number. The -A following the violationID number indicates the check aborted.


There were N BUS gates capable of attaining a Z state. (B16)

N indicates the number of buses failing the B16 rule.

EDT Rules (K Rules)EDT rules only apply to designs that incorporate EDT technology. They are generallyperformed by TestKompress when switching from Setup system mode. The tool also performssome checks at other times, such as in response to a Write EDT Files command, before writingEDT files. The rules checks find EDT design definition inconsistencies.

The following subsections describe each of the EDT rules and the special handling you can setfor them.

K1 (EDT Rule #1)Scope: IP Creation Phase and Pattern Generation Phase

EDT requires a circuit with scan chains. This rule check verifies that the design contains scanchains. The handling for this rule violation is error. You cannot change the handling with the SetDrc Handling command.


EDT does not support designs with more than one scan group. This rule check verifies that thedesign defines exactly one scan group. The handling for this rule violation is error. You cannotchange the handling with the Set Drc Handling command.




This rule check verifies that the scan chain input and scan chain output pin of each scan chainare both connected to either top level pins or to internal pins. The following are valid ways toconnect the scan chains:

• In the IP Creation Phase, all the scan chains must be connected to primary inputs (PIs)and primary outputs (POs).

• In the Pattern Generation Phase, the scan in and scan out pin of each chain must beconnected either to a PI and PO (for an uncompressed scan chain) or to internal nodes(for a compressed scan chain driven by and observed through the EDT logic).

The handling for this rule violation is error. You cannot change the handling with the Set DrcHandling command.

K4 (EDT Rule #4)Scope: IP Creation Phase

The EDT decompressor provides test patterns through unidirectional outputs to the inputs of theinternal scan chains. Similarly, the EDT compactor accepts test responses throughunidirectional inputs from the scan chain outputs. This rule check verifies that bidirectional scanchain pins do not exist. The default handling for this rule violation is error.

K5 (EDT Rule #5)Scope: Pattern Generation Phase

This rule check verifies the existence of all required EDT control and channel pins at the toplevel of the design. The default handling for this rule violation is error.

If K5 reports as nonexistent, an EDT control or channel pin you believe exists, it is typicallybecause the pin does not exist at the top level of the design from which the tool can control thepin, or because the pin’s current name differs from the pin name the tool expected. Thisdifference could occur, for example, if you manually edited the pin name within the netlist afterthe IP Creation Phase. Use the Set EDT Pins command to provide the tool with the correct pinname in these cases.


EDT pins, when shared with a design’s functional pins, must be shared with a functional pin ofthe same type. For example, when an EDT input pin is shared with a functional pin, thefunctional pin must be an input. Similarly, an EDT output pin must only be shared with afunctional output pin. This rule check verifies that each EDT pin that is shared with a functionalpin is of a type consistent with the functional pin. Sharing with bidirectional pins is not allowed,and is covered by other design rule checks.



August 2006

The K6 rule check also verifies the EDT control and channel pins have valid names. To beconsistent with FastScan and to provide immediate feedback if you change the default pinnames, TestKompress checks the validity of the pin names and pin directions when you enter aSet EDT Pins command. Because the default EDT pin names might also conflict with names ofexisting pins, the tool performs all checks again when you switch from Setup mode to Atpgmode. The default handling for this rule violation is error.

The tool performs K6 rule checks at three different times. The items checked at each time bythis rule are as follows:

These six requirements are checked immediately after the tool reads an EDT pin name. An errormessage results if the stated requirement is violated:

1. The pin name must not be hierarchical.

2. If the pin name is shared with a core pin, the directions must match.

3. If the pin is part of a bus, the base name for the pin must not be the same as the name ofa core pin.

4. The pin name must not be the same as the base name of a core bus.

5. If the pin name matches a core bus pin name, the index must be within the same range.

6. If a pin name is a bus bit, the bus must exist in the core. Presently, bus-based EDT pinsare not supported.

In addition to the preceding six requirements, the K6 rule checks the following requirementsduring DRC:

1. Each EDT pin must not be shared with either another EDT pin or with a restricted corepin. For information about restricted pins, refer to “Sharing Functional Pins with EDTControl and Channel Pins” in the EDT Process Guide.

2. Two EDT pins must not share the same name.

3. An EDT output channel pin must not be shared with a bidi.

Finally, when you write out the files that implement the EDT IP using the Write EDT Filescommand, the K6 rule results in a warning message for either of the following conditions:

1. The EDT clock pin is shared with a core bus pin.

2. An EDT pin is shared with a core pin that is empty (no fan-ins or fanouts).




EDT does not support either bidirectional or tristate scan channel output pins. This is becauseTestKompress includes a multiplexer between the EDT IP and the output pad when a scanchannel output pin is shared with a functional output pin. This rule check verifies that neitherbidirectional nor tristate scan channel output pins exist. The default handling for this ruleviolation is error.


This rule check verifies that neither bidirectional scan channel input pins nor bidirectional EDTcontrol pins exist. This is necessary because the EDT hardware has no control over the signaldirection of bidirectional pins, and they might be driven by the core logic during load_unload,resulting in contention problems. The default handling for this rule violation is warning.


Scan chain pins cannot be shared with a design’s functional pins. This is because TestKompressconnects the scan chain pins to the EDT IP and they are no longer available as primary inputs oroutputs in the new top level. This rule check verifies that scan chain pins are not used asfunctional pins. The default handling for this rule violation is warning.

The rule check assumes pin sharing in the following situations:

• Scan inputs—If a scan input drives a primary output, drives more than one scan cell, oris a bidirectional pin, pin sharing is assumed.

• Scan outputs—If the last scan cell of a scan chain does not drive other scan cells, andalso drives exactly one primary output, pin sharing is assumed.

NoteThe K9 rule check will not catch all cases of inappropriate pin sharing (the followingdiscussion describes why this is the case). Therefore, be sure during scan insertion thatyou insert dedicated scan pins. This is true even if the output of the last scan cell in a scanchain is connected directly to a primary output.

In some cases, a gate-level netlist does not contain the information to enable TestKompress todetermine if there is pin sharing. For example, Figure 2-27 shows a design where the last cell ofa scan chain drives functional logic as well as the scan output pin. It is impossible to extract theinformation from the gate-level netlist about whether the pin was there before scan insertion orhas been introduced for scan purposes.



August 2006

Figure 2-27. Failing identification

Figure 2-28 shows another case where the K9 rule check cannot determine if pin sharing occurs.The scan cell contains a logic gate that drives the scan output. By examining the netlist, itcannot be determined if the logic gate is part of the scan cell or part of functional logic.Therefore, the design rule check would not detect the sharing.

Figure 2-28. Common cell structure

For the same reason, the design rule check would fail also for the circuit shown in Figure 2-29.

Figure 2-29. Failing identification


Internal scan chain pins must not be part of a bus. If they were part of a bus, the pins would notbe connected to the EDT wrapper in the Pattern Generation Phase. This would leave somesignals of the bus unconnected. This rule check reports a violation if it finds that scan chain pinsare part of a bus.

Dscise

logic

scoDscise

sco

D

se

sci

Dscise

logic

sco



NoteNo violation is issued if all bus signals are scan chain pins.



The EDT clock, update, and bypass pins must not be shared with any other clock or RAMcontrol signal. The reasons for this restriction are as follows:

• If the EDT clock or EDT update are shared with a scan clock, the scan cells would bedisturbed during the load_unload procedure.

• If the EDT clock, update or bypass are shared with RAM control signals, RAMsequential patterns and multiple load patterns may not be applicable.

• If the EDT clock or EDT bypass are shared with a non-scan clock, the test coveragemight decrease because the EDT clock is constrained to its off state during the capturecycle.

This rule check verifies that the EDT clock, update, and bypass pins are not shared with anyother clock or RAM control signal. The default handling for this rule violation is error.


To guarantee that the EDT IP is not disturbed during capture, the EDT clock must beconstrained to its off-state during the capture cycle. This rule check verifies that the EDT clockpin does not drive any logic.

NoteIf the EDT clock is shared with a functional pin, the pin constraint may result in lowertest coverage.



This rule check reports all pins that will be added to the EDT top level wrapper in order toimplement the EDT hardware.



August 2006

NoteThe tool reports scan channel and control pins as new pins even if a scan chain pin withthe same name exists in the core circuit; otherwise that scan chain pin would not havebeen connected to the wrapper.

The default handling for this rule violation is note.


In order to prevent EDT from assigning values to the scan chain inputs during the capture cycle,all internal scan chain inputs are automatically constrained to X by EDT. This rule checkverifies that there are no user-defined constraints on the scan chain inputs that are different fromTIE-X. The default handling for this rule violation is error.


This rule check verifies that no EDT scan channel pin is shared with another EDT pin. It alsoverifies that there is no sharing between two EDT control pins that must not be shared. Thedefault handling for this rule violation is error.


This rule check verifies that the EDT clock signal has been added as a clock using the AddClocks command. The default handling for this rule violation is error.


This rule check verifies the EDT clock is constrained to its inactive state. This is required inorder to avoid disturbing the EDT IP during the capture cycle. The default handling for this ruleviolation is error.


This rule check verifies the following three required properties of the test procedure file:

1. Analyzes the off states of the EDT control signals



In the IP Creation Phase, TestKompress creates the EDT IP such that all the controlsignals are active high. This check verifies that all control signals are, in fact, activehigh.

NoteIf a control signal (EDT clock, for example) is inverted between the chip pin and the EDTIP, and you defined the inversion using the Set EDT Pins command in the IP CreationPhase, the signal at the chip level may be active-low.

2. Analyzes the EDT update control signal in the load_unload and shift procedures

In order to operate correctly, the EDT update signal is asserted during load_unloadbefore the leading edge of the EDT clock signal. EDT update must be reset after theleading edge of EDT clock in load_unload and before the leading edge of EDT clock inthe first shift procedure. It does not matter if EDT update is reset before or after thetrailing edge of EDT clock in load_unload.

3. Analyzes the EDT clock signal in the shift procedure

This check verifies that the EDT clock is pulsed in the shift procedure in order todecompress vectors provided at the scan channel inputs.



This design rule check simulates the EDT decompressor netlist by applying pseudorandompatterns and compares the results with the emulated values. If a simulation-emulation mismatchoccurs, the DRC performs diagnostic checks to narrow down the number of possible problemsources.


How to Debug K19 Violations

For most common K19 debug tasks, such as checking for correct values on EDT control signalsas well as sensitized paths from channel pins to the decompressor and from the decompressor tothe scan chains during shift, it is typically sufficient to use the Set Gate Report command tospecify Drc_pattern reporting:

set gate report drc_pattern procedure_name

Then use the Report Gates command to display simulated values for gates. The positions andvalues of mismatching monitor gates (certain gates used by the K19 rule check as referencepoints in its automated analysis of K19 mismatches) are reported as part of the K19 errormessage and provide clues to where the problem may lie.



August 2006

When you need to see the distinct simulation values applied in each shift cycle, you can viewthe simulated values for all K19-simulated gates, not just the monitor gates by setting the gatereport to K19:

set gate report drc_pattern k19

This is not commonly required, as most problems are usually due to setup problems such as pathsensitization and setting of control signals that are usually not pattern-specific or cycle-specific.

NoteUse “set gate report k19” reporting only when necessary. K19 reporting can slow EDTDRC run time and increase memory usage compared to Drc_pattern reporting becausethe tool has to log simulation data for all simulated setup and shift cycles.

For additional in-depth information on how to reduce the occurrence of K19 violations, refer tothe “K19 through K22 DRC Violations” and “Understanding K19 Rule Violations” sections ofAppendix B in the EDT Process Guide.


This design rule check identifies the number of pipeline stages within the compactors, based onsimulation. It also considers channel output pipelines; reporting any discrepancy between thenumber of identified and specified pipeline stages between the scan chains and pins (includingcompactor and channel output pipelines).

NoteIf the K19 rule check that verifies the operation of the decompressor fails, then the K20rule check will not be able to identify the number of pipeline stages.

If this rule check fails, you can still use diagnostic information from the K22 design rule checkto help identify a problem. Design rule K22 is checked whether the K20 rule check fails or not.The default handling for this rule violation is error.

NoteBe sure scan channel output pins that are bidirectional are forced to Z at the beginning ofthe load_unload procedure. Otherwise, the tool is likely to issue a K20 or K22 ruleviolation, without indicating the reason for the violation.




In the IP Creation Phase, this design rule check verifies that lockup cells will be synthesized ifthere is a scan chain whose first scan cell captures data at, or after, the rising edge of the EDTclock. The rule check also verifies that lockup cells will be synthesized if the output of the lastscan cell changes at, or before, the rising edge of the EDT clock. If bypass logic is included, therule verifies that lockup cells will be synthesized between the last scan cell of one chain and thefirst scan cell of another chain when they are connected by the bypass logic, and the output ofthe last scan cell changes before, or at the same time, the first scan cell captures.

In the Pattern Generation Phase, this rule check verifies the first scan cell of each chain does notcapture scan data at the same time the corresponding EDT decompressor output changes itssignal. If the EDT compactor is pipelined, the rule check also verifies the compactor does notcapture at the same time the output of the last scan cell in each chain changes. This could resultin clock skew problems, as the EDT and the core circuitry are part of different clock domains. Ifa violation is reported, you should add lockup cells or modify the timing. The default handlingfor this rule violation is warning.The K21 rule check will not be able to identify timingproblems in the Pattern Generation Phase if the K19 rule check, which verifies the operation ofthe decompressor, fails.


This design rule check simulates the EDT compactor fed by pseudorandom patterns, andcompares the results to the emulated values. Two different checks are performed, as follows:

1. The tool applies a pseudorandom pattern to the compactor inputs, with all scan chainsenabled.

2. The tool tests each compactor input separately. In this case, one pseudo-random patternis applied to the selected compactor input, and the compactor is programmed to mask allother inputs (scan chains). Decoder problems and scan chain permutations are detectedby this test.

If a simulation-emulation mismatch occurs, the tool automatically performs diagnostic checksto eliminate possible sources of the mismatch. Messages regarding K22 violations usuallyincorporate relevant information from these diagnostic checks to help you find the source of themismatch.

The default handling for this rule violation is error

NoteBe sure scan channel output pins that are bidirectional are forced to Z at the beginning ofthe load_unload procedure. Otherwise, the tool is likely to issue a K20 or K22 ruleviolation, without indicating the reason for the violation.



August 2006

How to Debug K22 Violations

For most common K22 debug tasks, such as checking for correct values on EDT control signalsas well as sensitized paths from the scan chains to the compactor and from the compactor to thechannel pins during shift, it is typically sufficient to use the Set Gate Report command andspecify Drc_pattern reporting:

set gate report drc_pattern procedure_name

Then use the Report Gates command to display simulated values for gates. The positions andvalues of mismatching monitor gates (certain gates used by the K22 rule check as referencepoints in its automated analysis of K22 mismatches) are reported as part of the K22 errormessage and provide clues to where the problem may lie.

When debugging incorrect compactor mask settings for specific patterns simulated by thedesign rule check, you can view the simulated values for any K22-simulated gate, not just themonitor gates, by setting the gate report to K22:

set gate report drc_pattern k22

This is not commonly required, as most problems are usually due to setup problems such as pathsensitization and setting of control signals that are usually not pattern-specific or cycle-specific.

NoteUse “set gate report k22” reporting only when necessary. K22 reporting can slow EDTDRC run time and increase memory usage compared to Drc_pattern reporting becausethe tool has to log simulation data for all simulated setup and shift cycles.

For additional in-depth information on how to reduce the occurrence of K22 violations, refer tothe “K19 through K22 DRC Violations” and “Understanding K22 Rule Violations” sections ofAppendix B in the EDT Process Guide.


This design rule check verifies (when the tool generates level-sensitive EDT hardware) thatthere is no scan chain whose first or last scan cell contains edge-triggered flip flops.

TestKompress can generate EDT IP based on either edge-triggered flip flops or level-sensitivelatches. By default, it generates EDT hardware based on flip flops, with a single clock. Theedge-triggered EDT hardware can operate with a design that has scan chains based on edge-triggered scan cells or level-sensitive scan cells. Depending on the clocks used by the first andlast scan cells in each chain, the tool generates lockup cells when necessary to prevent clockskew problems.



For pure LSSD designs, the tool can optionally generate EDT hardware based on level-sensitivelatches with a master clock and a slave clock. But the level-sensitive EDT hardware requires adesign that uses only level-sensitive scan cells, with an appropriate clock scheme for the masterand slave clocks. Such a scheme ensures there is no clock skew between the EDT hardware andthe first and last scan cells, so the tool does not add any lockup cells.

NoteIf you use level-sensitive EDT hardware with bypass logic, you must make sure that scanchain outputs connected to scan chain inputs via bypass logic do not require lockup cells.

K24 (EDT Rule #24)Scope: Top-level Pattern Generation Phase of modular TestKompress when“Set EDT Mapping On” is in effect.

This design rule check is performed when you have enabled the Set EDT Mapping commandand are reusing block-level dofiles for top-level pattern creation. The rule check verifies that theclock, read control, write control, and pin constraint signals specified in the block-level dofilesare consistent with the signals specified at the top level. The tool does this by tracingconnectivity between specified block-level signals (ports) and primary input or output pins. Thetool verifies clock off state and pin constraint values while compensating for inversions in thepath. During this rule check, all EDT signals that exist as ports on the block, but not as top levelpins, are updated to refer to the top level input or output pins as determined by the tracingalgorithm.

For detailed information about the reuse of block-level dofiles for top-level pattern creation in amodular TestKompress flow, refer to the “Automatic Block-level Dofile Integration” section ofthe Modular TestKompress chapter in the EDT Process Guide.

Extra Rules (E Rules)The extra rules have no effect on an application’s (DFTAdvisor, FastScan, FlexTest, andTestKompress) operations. You can use these rules to identify potential design requirementproblems. The default handling is ignore (except E4) and therefore, the application will notperform the rules checking unless you explicitly change the handling to be error, warning, ornote. The following subsections describe the extra rules.

E1 (Extra Rule #1)All scan cells must be LSSD scan cells that contain a master and a slave latch. They may alsocontain shadow latches. This rule is meant to enforce a strict LSSD architecture within a design.The application performs this check by inspecting the memory elements of all scan cells. Therule violation occurs when any memory element (that is not a latch or a scan cell) does notcontain a SLAVE.



August 2006

The default handling for this rule violation is ignore. Failure to satisfy this rule will have noeffect. The occurrence message is:

MASTER N (G) is not an LSSD latch. (E1-1)

N is the instance name of the MASTER gate, and G is the gate ID number.


N scan cells are not LSSD. (E1)

N is the number of occurrences of rules violation E1.

E2 (Extra Rule #2)There must be no data inversion between adjacent scan cells, the scan chain input pin (SCI) andits adjacent scan cell, and the scan chain output pin (SCO) and its adjacent scan cell. Theapplication performs this check by inspecting the inversion data for all scan cells. The ruleviolation occurs when any adjacent scan cells (including SCI and SCO) have an inversiondifference.


Scan chain has inversion between N1 (G1) and N2 (G2). (E2-1)

N1 is the instance name of one MASTER (or SCI) gate, G1 is its gate ID number, N2 is theinstance name of the other MASTER (or SCO) gate, and G2 is its gate ID number.


There were N scan chain inversions. (E2)


E3 (Extra Rule #3)There must be no inversion between MASTER and SLAVE for any scan cell. The applicationperforms this check by inspecting the inversion data for the memory elements of all scan cells.The rule violation occurs when the MASTER is inverted relative to its SLAVE.


SLAVE N (G) is inverted relative to MASTER. (E3-1)

N is the instance name of the SLAVE, G is its gate ID number, and E3 is the rule ID number.




There were N SLAVEs inverted relative to MASTER. (E3)


E4 (Extra Rule #4)Checks for conflicting values driving the same net during evaluation of the test procedures.

Description

Tri-state drivers must not have conflicting values when driving the same net during theapplication of the test procedures. The tool performs this check using the simulated values ofeach time period of all test procedures except the capture procedure. A rule violation occurs ifany bus gate is at an X state and two or more of its inputs are not at Z.



Failure to satisfy this rule does not affect coverage, but will result in the risk of bus contention.

How to Debug E4 Violations


Bus contention on N (G) occured at time T of P procedure. (E4-1)

N is the instance/net name of the bus gate, G is the gate ID number, T is the time period, and Pis the procedure name.


There were N occurences of bus contention in test procedures. (E4)

N is the number of times an E4 violation occurred.

You can access the simulated values at the gate where the error occurred by issuing theSet Gate Report command with the Drc_pattern argument, then using the Report Gatescommand to report the gate whose ID number is displayed in the error message. If this is theonly DRC violation, or if you have changed the default handling to error, you can also viewsimulated values of the gate of interest by issuing Set Gate Report with the Error_patternargument prior to using Report Gates. Gate reporting with the proper simulation data helps youidentify the conflicting inputs; by tracing back from these inputs, you can identify how tocorrect the problem.

If you see an “A” appended to the “E4” in the occurrence message (E4A-1 for example), itindicates the occurrence is due to the tool aborting the E4 check before it was completed. As



August 2006

these are “possible” but unproven E4s, the tool may be able to screen out some of them if youraise the abort limit. Refer to “Possible Resolutions” later in this section for more information.


To view the location of an E4 DRC violation using DFTInsight, use the following commandsteps:



Then choose Analyze > DRC Violation from the DFTInsight menu, select the violation ID ofthe desired E4 DRC violation in the dialog box and click Analyze. The tool will automaticallychange the gate reporting to “drc_pattern load_unload” and display the bus gate affected by thatviolation in DFTInsight.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# and -Display arguments at the tool’s command line. For example, todisplay the first occurrence of an E4 violation:

analyze drc violation e4-1 -display

Once the offending bus gate is displayed, use the EZ-Trace Mode of DFTInsight (or theDFTInsight menu item, Display > Backward Trace > To End Points) to trace back from thebus gate. Figure 2-30 shows an example DFTInsight display of such a trace, where the startingpoint of the trace is the offending gate, /tsdo.

Figure 2-30. Example E4 Violation Trace in DFTInsight




To view the location of the first occurrence of an E4 DRC violation from the FastScancommand line, you can use the following command steps (FlexTest and TestKompress wouldbe similar):


2. Report Drc Rules E4-occurrence#


4. Set Gate Report Drc_pattern Load_unload

5. Report Gates gate_id

The following transcript excerpts show, for the design segment of Figure 2-30, an example ofthe use of this command sequence starting at step 2:

ATPG> report drc rules e4-1// Warning: Bus contention on /tsdo/dout[0] (314) occurred at time 0 of// load_unload procedure. (E4-1)ATPG> set gate level primitiveATPG> set gate report drc_pattern load_unloadATPG> report gates 314// /tsdo (314) BUS// “I0” I (XX) 294-/tsdo/ix149/Y// “I1” I (XX) 286-/tsdo/ix145/Y// “OUT” O (XX) 396-/dout[0] 330-

The Xs on the two inputs to the bus gate in this example are the source of the problem. Areasonable way to proceed would be to choose one input and trace back through the gatesdriving it until you find the source of the Xs. For example, you might first look at where the “I0”input comes from:

ATPG> report gates 294// /tsdo/ix149 (294) TSD// E I (XX) 247-/ix310/Y// “D” I (XX) 221-// Y O (XX) 314-

Notice the Xs on the enable (E) input. This input is of particular interest because an X hereresults in an X on the TSD’s output regardless of the value on its D input. So tracing back fromthe enable would be a logical next step:

ATPG> report gates -endpoints -backward 247// ---------------------------------------------------------------------// Begin backward trace for gate /ix310 (247).// ---------------------------------------------------------------------// /tsden[1] (29) PI// tsden[1] O (XX) 160-/ix292/A// /scan_en (32) PI// scan_en O (11) 163-/ix140/A0 161-/ix138/A1 162-/senmux/ix9/A1// /e4 (34) PI



August 2006

// e4 O (XX) 163-/ix140/A1// Number gates in trace = 3.

If you could get a 0 on the net connected to this TSD’s enable, it would remove the Xs on itsoutput.


Bidirectional primary input pins that are not at a Z value during evaluation of the test procedureare a common cause of E4 DRC violations. For each such bidirectional pin, be sure to force thesignal to Z in both the test_setup procedure and the load_unload procedure.

Cell constraints and ATPG constraints (dynamic or static) have no impact on the E4 rule. Pinconstraints can have an impact because the tool may add extra cycles at the end of the test_setupprocedure if the procedure does not preserve the constrained value. The constrained value canbe overridden by another force value in the test procedure.

It is common during test_setup, when a design is being initialized, to have valid but momentarybus contention before the design reaches its initialized state. The E4 rule often detects thesemomentary occurrences of bus contention and as a result, the tool may report many E4violations for the test_setup procedure. If you know these momentary occurrences of buscontention are not a problem and do not wish to be reminded of them, you can disable the E4checks for the test_setup procedure by issuing the command, Set Drc Handling -Skip_procedureTest_setup.

Increasing the abort limit with the Set Abort Limit command can help screen out false E4violations by enabling the tool to perform more extensive contention checking. This works forE4A violations only.

Related Commands

E5 (Extra Rule #5)When the application places constrained states on constrained pins and binary states on PIs andscan cells, X states must not propagate to an observable point. Failure to satisfy this rule willresult in the risk of X states propagating to an observable point. This is a serious condition forBIST circuits, may reduce the effective compression obtainable with EDT, and has no effect onregular ATPG.

NoteTestKompress can handle the X states, but they typically increase the number of patternsgenerated, lowering the effective compression.

Set Abort Limit Set Drc Handling



The application performs this check on gates that can create an X state with their inputs atbinary values. It will not consider gates that do not have a path to an observable point, or thathave all paths blocked by tied or constrained circuitry. The tool checks for the followingconditions:

• A violation on a wired gate (WIRE) occurs if the tool can place different values on itsinputs and the net resolution is set to wire.

• A violation on a BUS gate occurs if more than one of the BUS-connected tri-statedrivers or switches turn on simultaneously, or all drivers turn off simultaneously and theZ state behaves as an X.

• A violation on a tri-state driver gate (TSD) or a switch gate (SW) occurs if it does notconnect to a BUS gate. You can turn off the enable line, and the Z state behaves as an X.

• A violation on a TIE-X gate occurs if the gate is locally sensitizable up to the pointwhere it has multiple fanouts (or observable points).

• A violation on a transparent latch (TLS) occurs if a single clock line is not set to its on-state, or the set and reset lines are not off.

• A violation on a ROM or RAM gate occurs if you can set a read line to off, the read_offvalue is X, and an output is sensitizable when the read line is off.

• A RAM/ROM violation also occurs if any memory element is uninitialized and anoutput is sensitizable to an observation point.

The default handling for this rule violation in FastScan and TestKompress is note; in other toolsit is ignore. When a violation occurs, you can access the tied/constrained simulated values bysetting the gate reporting to “constrain_value” and using the Report Gate command for the gateID number displayed in the DRC message. The tool needs to be in a non-Setup system mode.By tracing back and forward from this gate, you can identify why the violation occurred.


T gate N (G) may have an observable X-state. (E5-1)

T is the gate type, N is the instance/net name of the gate, and G is the gate ID number.


N gates may have an observable X-state. (E5)


E6 (Extra Rule #6)When the tool places constrained states on constrained pins, the inputs of a gate must not havesensitizable connectivity to more than one memory element of a scan cell. The applicationperforms this check by tracing the forward cones of influence of all scan cell memory elements



August 2006

through unconstrained and untied circuitry. The rule violation occurs when any gate is in thecone of influence of more than one memory element of a single scan cell.

The default handling for this rule violation is ignore. Failure to satisfy this rule may result insome loss of test coverage, but most faults should be detectable using a skewed load testprocedure.


Multiple memory elements of scan cell P (C) are connected to N (G). (E6-1)

P is the position number of the scan cell, C is the chain name, N is the instance name of the gate,and G is its gate ID number.


There were N scan cells with multiple memory element connectivity to agate. (E6)


E7 (Extra Rule #7)External bidirectional drivers must be at the high impedance (Z) state during the application ofthe test procedures. You can use this rule to ensure that no bus contention can occur atbidirectional pins independent of the force values on the bidirectional pins. The applicationperforms this check using the simulated values of each time period of all test procedures (excepttest_setup). The rule violation occurs if any bidirectional tri-state driver is not at a Z state.Using the -Mode option with the Set Drc Handling command and the Report Drc Rulescommand, you can check the value being forced on the bidirectional pins.

The default handling for this rule violation is ignore. If rule E4 (which ensures bus-mutualexclusivity) passes, a violation of rule E7 has no effect. Failure to satisfy this rule (normally)has no effect if there is no violation of rule E4, which ensures no bus contention actually occurs.

You can access simulated gate values using the Report Gate command with the gate data set toDRC_pattern. If this is the only DRC violation or if you have changed the default handling toerror, you can also view simulated values using Report Gate with gate reporting set toerror_pattern. Gate reporting with the proper simulation data helps you identify the bidirectional

NoteYou should set the gate data prior to any violation analysis, to ensure the gate datareported is for the correct violation.

pin that failed, and by tracing connectivity from this point, you can identify how to correct theproblem.




BIDI pin P not set to input mode at time T of P procedure. (E7-1)

P is the pin name of the bidirectional pin, T is the time period, and P is the procedure name.


There were N occurrences of BIDIs not set to input mode during scanning.(E7)


E8 (Extra Rule #8)All scan cell MASTER elements of a scan chain must use a single shift clock. If the scan cellscontain slaves, all slaves of all scan cells of a scan chain must also use a single shift clock. Youcan use this rule to ensure that the tester does not cause clock skew problems during the loadingand unloading of the scan chains. The application performs this check by inspecting thememory elements for all scan cells of a chain. The rule violation occurs when a chain usesmultiple clocks to shift master or slave data.

If multiple shift clocks pulse in the shift procedure and they are blocked from reaching the scanchain by the effects of pin constraints, you must specify the Set Drc Handling command withthe Atpg_analysis option to avoid an error. This checking considers only pin constraints thathave not been overridden by force statements during the shift and load_unload procedures.

The default handling for this rule violation is ignore. Failure to satisfy this rule will have noATPG effect. The occurrence message is:

Multiple clocks were used to shift T of scan chain C. (E8-1)

T is the type of scan cell memory element (MASTERs or SLAVEs), and C is the chain name.


There were N occurrences of multiply clocked scan chains. (E8)


NoteIf you set the DRC E8 handling to anything other than Ignore, the Report Scan Chaincommand additionally displays the clock of each scan cell. This enhanced report is onlyavailable in non-Setup mode.



August 2006

E9 (Extra Rule #9)The drivers of wire gates must not be capable of driving opposing binary values. Theapplication performs this check by attempting to satisfy the placement of opposing binaryvalues on all combinations of the two drivers of a wire gate. The rule violation occurs at a wiregate if it is possible to satisfy those conditions for at least one combination of drivers. When aviolation occurs, the tool identifies the failing wire gate and the drivers capable of being placedat opposing values.

This rule ensures that there is no possible contention (for the good machine) on wire gates. Thetool will not perform this rule check on wire gates whose behavior you changed to AND or ORusing the Set Net Resolution command. Also, the tool does not consider pin constraints andequivalences with this check.

The default handling for a violation of this rule is set to ignore. A violation of this rule indicatesthe possibility that patterns exist that have contention on wire gates. The occurrence message is:

WIRE gate N (G) has possible contention on drivers G1 and G2. (E9-1)

N is the gate name of the wire gate, G is its gate ID number, and G1 and G2 are the gate IDnumbers of the driver gates.


There were N WIRE gates which may have possible contention. (E9)


E10 (Extra Rule #10)Checks for bus contention mutual-exclusivity during measure_po events in test procedures.

Description

Tri-state drivers must not have conflicting values when driving the same net during themeasurement of primary output (PO) values (measure_po events in test procedures). This rulediffers from the E4 rule in that it is not checked during test procedure events other thanmeasure_po events. The tool performs this check by analyzing each dominant strong bus todetermine if it can cause contention. The analysis places each bus in one of the followingcategories:

• Pass - Test generation analysis determines a contention condition cannot occur.

• Fail - Test generation analysis identifies a possible contention condition.

• Abort - Test generation analysis terminated while attempting to determine if acontention condition could occur.



• Bidi - Test generation determines that the bidirectional pin (which can only have asingle tri-state driver) can potentially create a contention condition.

Buses in either the fail or abort categories violate this rule. Buses in the bidi category requirechecking during post-DRC ATPG processes because they do not exhibit natural mutual-exclusivity behavior and can potentially cause contention. You get the tool to perform thisadditional analysis by using the Atpg_analysis option with the Set Drc Handling command (seealso “Turning on ATPG Analysis” on page 2-10 for more information on the ATPG_analysisoption). Buses in the pass category require no further checking.

Refer to “Bus Mutual Exclusivity Analysis” in the Scan and ATPG Process Guide forbackground information about the tool’s bus mutual exclusivity checking. For more informationabout the measure_po statement, refer to the “Test Procedure File”.



Failure to satisfy this rule will result in the risk of bus contention during measurement of POvalues (measure_po events in test procedures).

How to Debug E10 Violations


Bus gate N (G) has possible contention on drivers G1 and G2. (E10-1)

N is the gate name of the bus gate, G is the gate ID number, and G1 and G2 are the gate IDnumbers of the driver gates.


There were N bus gates which may have possible contention (E10)

N indicates the number of bus gates failing the E10 rule.

If you see an “A” appended to the “E10” in the occurrence message (E10-1-A for example), itindicates the occurrence is due to the tool aborting the E10 check before it was completed. Asthese are “possible” but unproven E10s, the tool may be able to screen out some of them if youraise the abort limit. Refer to “Possible Resolutions” later in this section for more information.


To view the location of an E10 DRC violation using DFTInsight, use the following commandsteps:





August 2006

Then choose Analyze > DRC Violation from the DFTInsight menu, select the violation ID ofthe desired E10 DRC violation in the dialog box and click Analyze. The tool will automaticallychange the gate reporting to “parallel_pattern 0” and display the bus gate affected by thatviolation in DFTInsight. Think of “parallel_pattern 0” as an example of one possible pattern(created for DRC purposes only) that, if included in a test pattern set, would cause contention.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# and -Display arguments at the tool’s command line. For example, todisplay the first occurrence of an E10 violation:

analyze drc violation e10-1

Once the offending bus gate is displayed, use the EZ-Trace Mode of DFTInsight (or theDFTInsight menu item, Display > Backward Trace > To End Points) to trace back from thebus gate. Figure 2-30 shows an example DFTInsight display of such a trace, where the startingpoint of the trace is the offending gate, /tsdo. Notice that TSDs /ix145 and /ix149 haveconflicting values and both are enabled.

Figure 2-31. Example E10 Violation Trace in DFTInsight

You could use DFTInsight to trace back on the enable line of each TSD to the primary inputsand see that both tsden[1] and /scan_en are 1, causing the conflict.


To view the location of the an occurrence of an E10 DRC violation from the FastScan commandline, you can use the following command steps (FlexTest and TestKompress would be similar):

1. Set Drc Handling E10 Warning




3. Report Drc Rules E10-occurrence#

4. Analyze Bus gate_id

5. Set Gate Report Parallel_pattern pattern_number

6. Report Gates gate_id

The following transcript excerpts show, for the design segment of Figure 2-30, an example ofthe use of this command sequence starting at step 3:

ATPG> report drc rules e10-1// Warning: BUS gate /tsdo/dout[0] (314) has possible contention on// drivers 294 and 286. (E10-1)ATPG> analyze bus 314// ATPG bus checking performed on /tsdo/dout[0] (314) for 2 bussed TSDs.// Failure occurred while checking TSDs 294 and 286 (data in// parallel_pattern 0).ATPG> set gate report parallel_pattern 0ATPG> report gates 294 286// /tsdo/ix149 (294) TSD// E I (1) 247-/ix310/Y// “D” I (1) 221-// Y O (X) 314-// /tsdo/ix145 (286) TSD// E I (1) 161-/ix138/Y// “D” I (0) 213-// Y O (X) 314-

The conflicting values on the input (“D”) of each TSD in this example while both are enabled (1on the “E” input) is the source of the problem. Assuming the two TSDs should not be enabledsimultaneously, a reasonable way to proceed is to choose one enable input and trace backthrough the gates driving it until you find the source of the 1. For example, you might first lookat where the /tsdo/ix149 (294) input comes from:

ATPG> report gates -endpoints -backward 294// ---------------------------------------------------------------------// Begin backward trace for gate /tsdo/ix149 (294).// ---------------------------------------------------------------------// /tsden[1] (29) PI// tsden[1] O (1) 160-/ix292/A// /scan_en (32) PI// scan_en O (1) 163-/ix140/A0 161-/ix138/A1 162-/senmux/ix9/A1// /e4 (34) PI// e4 O (0) 163-/ix140/A1// /dataot/reg_q_0_ (373) DFF// “S” I (X) 43-// R I (X) 157-// CLK I (X) 313-/dataot/ix104/Y// “D0” I (X) 255-// “OUT” O (1 [X]) 127- 128-// MASTER cell_id=8 chain=chain3 group=grp1 invert_data=TFFT// Number gates in trace = 4.



August 2006

This shows that /tsden[1] is a 1. A similar backward trace from instance 286 to /tsden[0] showsthat it too is a 1. If you could get a 0 on one of the /tsden inputs, it would remove the contention.


Be aware you may not need to care about E10 violations in certain cases. If you are notconcerned about contention after the capture clock is pulsed and you are satisfied with testcoverage, you do not need to do anything. On the other hand, if the tool is rejecting manypatterns due to contention during simulation and as a result, run time is excessive and coveragelow, you may want to do something. By default, the tool will check for contention prior to thecapture clock pulse in the capture cycle. If you are concerned about contention after the captureclock is pulsed, you need to direct the tool to check for this type of contention. The key point toremember is you only need to do something if you are not happy with what the tool does bydefault or the run time or coverage is unacceptable, in which case the following commands arehelpful:

NoteThese command suggestions will not make E10 rule violations go away, but will help yougenerate contention free patterns when E10 violations are present.

• Add Pin Constraint — Adds a pin constraint to a primary input pin. This command isuseful if you determine from your troubleshooting and knowledge of the design thatforcing a particular primary input pin to a specific value would resolve a contentionissue. Typically, the need for such a constraint would have been anticipated during thedesign phase and perhaps simply overlooked when setting up for ATPG.

• Set Contention Check — Determines how much effort the tool makes to keepcontention-causing patterns out of the pattern set. By default, the tool makes nodeterministic effort to generate patterns free of contention, but simply checks patternsduring simulation for contention prior to the capture clock and rejects those that causecontention.

If a significant number of patterns are rejected with this command’s defaults, there arethree arguments (-Atpg, Capture_clock, and -Catpg) you can use to increase the tool’seffort in different ways. Each choice involves trade-offs between run time and coverage.A reasonable way to proceed is to issue the command with the -Atpg switch. The testgenerator will then generate patterns free of contention prior to the capture clock (anextra effort) and the tool will check the resultant patterns for contention duringsimulation.

If contention after the capture clock is a concern, use the Capture_clock option to checkfor contention before and after capture during simulation. If a significant number ofpatterns are rejected during simulation because they produce contention after capture,try including -Catpg with Capture_clock. This forces the test generator to generate



patterns free of contention both before and after capture (not just before as the -Atpgswitch does) and should reduce the number of patterns rejected during simulation.

NoteBecause -Atpg and -Catpg require additional effort by the test pattern generator, use themonly when necessary.

• Add Atpg Functions and Add Atpg Constraints —These commands allow you to createuser-defined ATPG function constraints. This can be useful if you know where in thedesign constraints can be applied to remove contention. Constraints you apply will savetime the tool would have to spend learning those locations through its own analysis.Following is an example of the use of these commands to specify constraints:

add atpg functions func1 select1 tsden[0] ~tsden[1]

add atpg constraint 1 func1

• Set Drc Handling E10 Atpg_analysis — Directs the tool to perform additional analysistoward the end of DRC to determine if buses that the initial E10 DRC placed in the bidicategory can cause contention. Increases the tool’s DRC effort.

• Set Drc Handling E10 -Mode Sequential — This command considers the inputs to asingle level of sequential cells behaving as “staging” latches in the enable lines of tri-state drivers. All of the latches found in a back trace must share the same clock. Theremust also be only a single clocked data port on each cell, and both set and reset inputsmust be tied (not pin constrained) to the inactive state. This check ensures that there isno connectivity from the cells in the input cone of the sequential cells and enable of thetri-state devices except through the sequential cells. Using this option will increase runtime.

• Set Abort Limit — Changes the abort limit. Increasing the abort limit can help screenout false E10 violations by enabling the tool to perform more extensive contentionchecking. This works for E10-occurrence#-A violations only.

Related Commands

E11 (Extra Rule #11)This rule checks for the ability of a bus gate to attain a Z state. This check analyzes eachdominant strong bus to determine if conditions can place a Z value on the bus gate. As a result,the analysis places each bus in one of the following categories:

Add Atpg ConstraintsAdd Atpg FunctionsAdd Pin ConstraintAnalyze Drc Violation

Set Abort LimitSet Contention CheckSet Drc Handling



August 2006

• Pass - Test generation analysis determines that no condition could place a Z value on thebus gate.

• Fail - Test generation analysis determines that conditions could place a Z value on thebus gate.

• Abort - Test generation analysis terminated while attempting to determine if conditionscould place a Z value on the bus gate.

• Bidi - The bus is a bidirectional bus.

Buses in both the fail and abort categories violate this rule.

The default settings for this rule are ignore, noverbose, and atpg_analysis. You can change thehandling with the Set Drc Handling command. For more information on ATPG analysis, referto “Turning on ATPG Analysis” on page 26.


BUS gate N (G) is capable of attaining a Z state. (E11-1-A)

N is the gate name of the bus gate, and G is its gate ID number. The -A following the violationID number indicates the check aborted.


There were N BUS gates capable of attaining a Z state. (E11)

N indicates the number of buses failing the E11 rule.

E12 (Extra Rule #12)This rule determines if the test procedures violate any ATPG constraints. The default handlingfor this rule is ignore. You can change the handling with the Set Drc Handling command. Formore information on ATPG analysis, refer to “Turning on ATPG Analysis” on page 26.


ATPG constraint violation on N (G) occurred at time T of P procedure.(E12-1-A)

N is the gate name, G is its gate ID number, T is the simulated time period, and P is theprocedure name. The -A following the violation ID number indicates the check aborted.


There were N occurences of ATPG constraint violations in test procedures.(E12)

N indicates the number of E12 rule violations.



E13 (Extra Rule #13)This rule determines if it is possible to satisfy both ATPG constraints and bus contentionprevention (for buses that fail rule E10). The default settings for this rule are ignore andnoverbose. You can change the handling with the Set Drc Handling command.


Contention prevention/ATPG constraints satisfiability check failed. (E13-1)

This rule does not issue a summary message.

Scannability Rules (S Rules)Scannability checking ensures that DFTAdvisor can safely convert a sequential element to ascan element. For each sequential element in the design, DFTAdvisor performs two mainchecks. The first check, S1, ensures that when all defined clocks—including sets and resets—are at their off-states, the sequential elements remain stable and inactive. The second check, S2,ensures that for each defined clock, sequential elements can capture data when all the otherdefined clocks are off. These scannability checks determine if DFTAdvisor can turn off all setand reset lines, and turn on and off all clock inputs of sequential cells from the design's primaryinput pins. Without this controllability, DFTAdvisor will not allow a sequential element to passscannability checks, which is a requirement to be considered for scan identification.

This checking is similar to the C1 (S1) and C7 (S2) rules checks, which DFTAdvisor, FastScan,FlexTest, and TestKompress all perform to determine the stability of defined scan chains. TheC1 and C7 rules perform these same checks on sequential elements that are already converted toscan. For more information on C1 and C7, refer to “Clock Rules (C Rules)” on page 70.

Once these scannability rules pass, the elements are considered “scannable” and the DRCprocess treats the non-scan elements as though they were scan elements for the remainder of theDRC rules.

All scannability rules, except the S3 rule, are warnings and their handling cannot be changedwith the Set Drc Handling command. The default handling of the S3 rule is warning and youcan change the handling to other handling types. The following subsections describe thescannability rules and the special handling you can set for them.

S1 (Scannability Rule #1)Scannability rule S1 checks all the clock inputs (including sets and resets) of each non-scanmemory element to ensure that these inputs can be turned off. This rule ensures that non-scanelements that may be converted to scan can be controlled to hold their current data. The ReportDft Check command provides information for troubleshooting these failures, by listing the cellsthat fail this check, the clocks that control them, and their associated gate identification number.



August 2006

You can use this gate identification number with the Report Gate command or the Add >Display > Instance menu item in DFTInsight to display the failing gate and its associated data

To debug a S1 DRC Violation without DFTInsight, use the command “Analyze DRC Violation<violation_number>”. This will run the DRC analysis for the specific violation and allow thesimulation data to be displayed. In the following example, the failure is due to the clock pin“CP” being set to X. To pass the S1 DRC, the clock must be set to it’s off state of 0. Thecommand sequence noted will work with or without DFTInsight.

DFT> anal dr viol S1-2// Gate report now set to display_sim_data.// Creating schematic for 3 instances (0 were compacted).DFT> rep drc rule s1-2// Warning: Unstable nonscan cell /AA/OUT_2_reg(32) when all clocks areoff. (S1-2)DFT> rep gate 32// /AA/OUT_2_reg (32) TIEX// "I0" I (0) 10-// "I1" I (0) 27-// CP I (X) 22-/AA/I_1/out// "I3" I (X) 13-// "OUT" O (X) 15-

Scannability rule S1 is a modified version of the C1 clock rule, in that it performs the same typeof checking on nonscan sequential elements that C1 performs on scan elements. For additionalinformation the C1 clock rule, refer to “C1 (Clock Rule #1)” on page 73.

S2 (Scannability Rule #2)Scannability rule S2 checks all clock inputs (not including sets and resets) of each non-scanmemory element to see whether they can capture data. This rules ensures that a non-scan cellcan capture data using one of the defined clocks. In order to be converted to scan, a non-scancell must be able to capture data when a single clock is on. The Report DFT Check commandprovides information for troubleshooting these failures, by listing the cells that fail this checkalong with their associated gate identification numbers. You can use the gate identificationnumber with the Report Gate command or Add > Display > Instance in DFTInsight to displaythe failing gate and its associated data.

Scannability rule S2 is a modified version of the C7 clock rule, in that it performs the same typeof checking on non-scan sequential elements that C7 performs on scan elements. For additionalinformation on the C7 clock rule, refer to “C7 (Clock Rule #7)” on page 94.

S3 (Scannability Rule #3)Scannability rule S3 checks for the existence of an un-constrained non-clock primary input pinin the clock cone of a non-scan memory element. Such a non-scan memory element, if madescannable, may cause trace violations unless the non-clock pin is constrained in the ATPGdofile to correctly sensitize the clock path, or it is forced similarly in the load_unload procedure.



S1 and S2 rules do not fail on the un-constrained non-clock primary inputs in the clock conebecause they assume that such PIs can be controlled using pin constraints in dofiles or forcestatements in test procedures during ATPG. Figure 2-32 illustrates the S3 violations where thepin ‘clk’ is defined as the shift clock with an off state value of ‘0’. The non-clock pin ‘en’ is thecause for the violations if it is left un-constrained.

Figure 2-32. Example S3 Rule Violation

DFTAdvisor reports the total number of S3 violations in the session transcript during the DRCrule checking. Individual S3 violations can also be reported with the Report Drc Rules andReport Dft Check commands.

The default DRC handling of the S3 rule is “Warning”, which means that memory elementswith S3 violations are kept in the pool of scannable candidates. The handling can be changed to“Error” using the Set Drc Handling command, in which case the memory elements with S3violations are excluded from the pool of scannable candidates automatically by the tool usingAdd Nonscan Instances commands. If the you want to include some of those memory elementsback in scan insertion, you can issue Delete Nonscan Instances commands on them before usingthe Run command for scan cell identification. Similarly, if the S3 rule handling is “Warning”(the default), you can obtain the list of the violations using the Report Dft Check or Report DrcRules commands and issue Add Nonscan Instances commands on a subset of the list explicitly.

Although the handling of the S3 DRC violation can be changed to “Error”, the effect of theviolation is different from that of the S1 and S2 rules. The tool does not insert test logic on theclock pins to correct an S3 violation even if the user turns on the test logic insertion using theSet Test Logic command.

S4 (Scannability Rule #4)Scannability rule S4 checks for non-scan memory elements that can be converted to scanelements, and that are also initialized to a static value during test setup. These cells are assumedto be in an uninitialized state during DRC. If these cells are not intended to become scan cells,then you should use the Add Nonscan Instance command for these memory elements. This willeliminate the S4 violation, and will convert these cells to TIE0 or TIE1 gates (based on thevalue initialized with the test setup procedure). This may eliminate some C1 or C3 violationswhen the outputs of these non-scan cells interact with clock lines or set/reset signals.

Individual S4 violations can also be reported with the Report Drc Rules command. The severityfor S4 rules is “Warning”, which cannot be changed.

D Q

clken

udff

clk

en

udff

clk

enudfflatch

(a) (b) (c)

D Q D QE Q

‘0’



August 2006

Timing Rules (W Rules)These rules apply to timeplates and the mapping of timeplates to procedures. This includesmaking sure that the order of events in a procedure is not changed after leaving setup mode. Fortiming rules specific to the enhanced procedure file, see “Test Procedure File”.

W1 (Timing Rule #1)This message can only occur when not in setup mode. After leaving setup mode, it is possible toload an enhanced procedure file using the Read Procfile command. It is also possible for theenhanced procedure file to load a new procedure which overwrites a procedure already loaded.This is fine as long as the event order in the new procedure matches that of the old procedure. Ifthe new procedure has additional events, the tool will issue this error message:

New procedure P has more events then existing procedure. (W1)

P is the name of the new procedure.

W2 (Timing Rule #2)Similar to rule W1, but this rule is violated if the new procedure has less events than the oldprocedure.

New procedure P has fewer events than existing procedure. (W2)


W3 (Timing Rule #3)Similar to rule W1, this rule is violated if the new procedure has a different event order than theold procedure.

New procedure P has a different event order then existing procedure. (W3)


W4 (Timing Rule #4)This message is similar to rule W1. Instead of an entire new procedure being loaded, theenhanced procedure file only specifies that a new timeplate is applied to an existing procedure.This is done by specifying a new procedure in the enhanced procedure file with only a timeplatereference statement. If that new timeplate causes the event order in the old procedure to change,the tool will issue this error message:

New timeplate T changes event order in procedure. (W4)

T is the name of the new timeplate.



W5 (Timing Rule #5)A new non-scan procedure has an event statement that either occurs in the wrong order, or is notallowed in that type of procedure. All non-scan procedures must conform to the event order thatis stated for them in “Non-Scan Procedures” on page 342. An example of this would be acapture procedure that has a “measure_po” statement before the “force_pi” statement.

Procedure P has an illegal event statement or event order S. (W5)

P is the procedure name, and S is the illegal statement or event order.

W6 (Timing Rule #6)If one shift procedure has the “measure_sco” statement occurring after the pulse of the shiftclock, then all shift procedures must place the “measure_sco” statement after the pulse of theshift clock, and all load_unload procedures must have a “measure_sco” statement occurring atthe end of the cycle right before the “apply shift” statement. Placing the “measure_sco”statement after the pulse statement enables end measure mode which affects the way the VectorInterfaces code writes out parallel load scan patterns. See the “Automatic End Measure Mode”section of the “Enhanced Procedure File”.

Shift procedure P [does | does not] use end measure, while previous ones[do | do not]. (W6)

P is the procedure name.

W7 (Timing Rule #7)No timing information has been specified for the named procedure. Either the procedure needsto reference a timeplate, or time values must be associated with the event statements.

No timeplate or times specified for procedure P. (W7)


W8 (Timing Rule #8)A scan procedure (shift, load_unload, ...) has been read in by the Read Procfile command, butno “scan_group” statement is in the procedure.

No scan group specified for procedure P. (W8)


W9 (Timing Rule #9)The named procedure has no event statements, no apply statements, and no timeplatereferences.



August 2006

No events in procedure P. (W9)


W10 (Timing Rule #10)This warning is issued during DRC checking. It indicates that none of the procedure filesspecified in the Add Scan Groups commands have any procedures in them.

No test procedures have been loaded. (W10)

W11 (Timing Rule #11)A cycle in a procedure that needs to be split into two cycles in order to use the timeplate that isspecified for that procedure. This could occur, for example, if the test_setup procedure containsa pulse statement on a specific clock pin, and yet the timeplate used referenced by thisprocedure does not contain a pulse statement for the clock. The user will receive a P53 rulemessage and then a W11 rule message to indicate that the cycle (where the pulse statement is)was split into two cycles in order to create the clock pulse.

Cycle S being split in procedure P. (W11)

S in the cycle, and P is the procedure name.

W12 (Timing Rule #12)A timeplate was loaded that is missing a required statement. For example, a timeplate must havea “force_pi” statement. If a required clock pulse statement is missing from the loaded timeplate,you will receive a P53 rule message.

No S statement in timeplate T. (W12)

S is the statement name, and T is the timeplate.

W13 (Timing Rule #13)The event order for the name procedure has changed while parsing an procedure file, but sincethe tool is still in setup mode, this change of event order is acceptable. This could happen if twoprocedure files in two different Add Scan Groups commands both have the same procedure(test_setup, for example), but one specifies a different event order than the other. The last oneloaded is what will be used.

Event order has changed in procedure P. (W13)




W14 (Timing Rule #14)This message indicates that a procedure has been replaced by a new procedure with the samename, same type, and same scan group if applicable. This message indicates that thereplacement didn’t violate any rules. Both procedures have the exact same event order, but theymight use different timeplates.

Procedure P replaces same procedure from file S. (W14)

P is the procedure name, and S is the filename.

W15 (Timing Rule #15)End measure mode is enabled but an illegal force or pulse statement occurs between themeasure_sco statement and the end of the procedure in a shift procedure, or the illegal statementoccurs between the measure_sco statement and the apply shift statement in a load_unloadprocedure. See the “Automatic End Measure Mode” section of the “Enhanced Procedure File”.

Statement S can not follow measure_sco in end measure procedure P. (W15)S is the illegal statement and P is the procedure name.

W16 (Timing Rule #16)The timing described in the timeplate used by the FlexTest sequential procedure does not matchup with the time frame boundaries described by the Add Pin Constraint, Add Pin Strobes, SetupPin Constraints, and Set Test Cycle commands.

Timing for pin P in timeplate T does not match timing from pin constraints(W16).

P is the name of the pin, and T is the timeplate.

W17 (Timing Rule #17)Clock_po procedures are used to hold clock pins at certain values. In order to obtain the correctfault coverage, it is important that the timeplates used in a clock_po procedure do not pulse theclock pins, but only force them. If this is not corrected before patterns are saved, the VectorInterfaces code places X values on the output pins for the clock_po procedure and faultcoverage decreases.

Timeplate T has clock pulses but is used in a clock_po procedure. (W17)

T specifies which timeplate has the clock pulses. To correct this, make sure you define adifferent timeplate that does not have clock pulses and use this in the clock_po procedure.



August 2006

W18 (Timing Rule #18)Many ASIC vendors require that shift procedures only be one cycle in length, and it is veryunusual to encounter a multiple cycle shift procedure. This warning alerts the user thatsomething might not be specified correctly in the shift procedure, such as forcing the same pinwith more than one value, or pulsing a clock twice.

Shift procedure has more than one cycle, please check if shift clocks aredefined properly. (W18)

W19 (Timing Rule #19)This message occurs when using the offstate option improperly. The offstate option is onlysupported when using the Enhanced Vector Interfaces. Also, the pin referenced with the offstateoption cannot be used in a capture, ram_sequential, or clock_sequential procedure. These areconsidered non-scan procedures.

Any timeplate that uses the offstate statement will be treated as a complex timeplate and will notbe allowed to be used in a non-scan procedure. Complex timeplates are most useful in shiftprocedures where a non-clock pin needs to be pulsed while still maintaining a single cycle in theshift procedure. If you attempt to pulse a signal specified with an offstate option in a capture orother non-scan procedure, you will encounter the following error message.

Timeplate gen_tp1 with complex waveforms cannot be used in non-scanprocedure capture. (W19)

W20 (Timing Rule #20)This error occurs if, in a capture procedure, a force_pi event does not occur before the first clockpulse.

A force_pi statement does not exist before the first clock pulse inProcedure P. (W20)


To correct this violation, add a force_pi statement to the beginning cycle of the procedure,before the first clock pulse. For a named capture procedure with internal and external modes,add a force_pi statement to the beginning cycle in each mode.

W21 (Timing Rule #21)In a named capture procedure, a measure_po statement is allowed only in the last cycle of theinternal mode. This error occurs if a measure_po statement is found in a cycle where it is notpermitted.

Procedure P has one or more measure_po statements which do not occur inthe cycle before the last clock pulse. (W21)




To correct this violation, remove the measure_po statements from the cycles where they are notallowed.

W22 (Timing Rule #22)In a named capture procedure, a measure_po statement is allowed only in the last “cyclized”ATPG cycle of the internal mode—before the last clock pulse. This warning alerts you that thetool did not find a measure_po statement in this location. A capture procedure with this warningwill not use any PO as a capture point.

Procedure P has no measure_po statement in the cycle before the last clockpulse. (W22)


To view the cyclized information for the procedure, use the Report Capture Procedurescommand.

W23 (Timing Rule #23)In a named capture procedure, the total period of the external mode must match the total periodof the internal mode. This warning alerts you that the external mode’s period is longer than theinternal mode’s period.

The total period for the external mode is longer than the total period forinternal mode in procedure P. (W23)


To eliminate this warning, modify the timeplate(s) so that the external mode period matches theinternal mode period.

W24 (Timing Rule #24)In a named capture procedure, the total period of the external mode must match the total periodof the internal mode. This error occurs if the internal mode’s period is longer than the externalmode’s period.

The total period for the internal mode is longer than the total period forexternal mode in procedure P. (W24)


To correct this violation, modify the timeplate(s) so that the external mode period matches theinternal mode period.



August 2006

W25 (Timing Rule #25)Event times in the external and internal modes of a named capture procedure should match. Thiswarning alerts you that an event in the external mode does not have a matching event in theinternal mode.

Event E N at time T in external mode does not have matching event ininternal mode in procedure P. (W25)

E is the type of event, N is the name of the pin to which the event applies, T is the time of theevent, and P is the procedure name.

W26 (Timing Rule #26)Event times in the external and internal modes of a named capture procedure must match. Thiserror occurs if an event (other than an internal pin event) in the internal mode does not have amatching event in the external mode.

Event E N at time T in internal mode does not have matching event inexternal mode in procedure P. (W26)

E is the type of event, N is the name of the pin to which the event applies, T is the time of theevent, and P is the procedure name.

To correct this violation, you need to do two things:

• Add the missing event to the external mode.

• Modify the timeplate(s) so that the event added to the external mode occurs at the sametime as in the internal mode.

W27 (Timing Rule #27)In a named capture procedure, the start time for the scan load cycle in the internal mode musthave a match in the external mode. This error occurs if there is not a match in the external mode.

Start time for scan load cycle in internal mode does not have a match inexternal mode in procedure P. (W27)


To correct this violation, adjust the timeplate(s) or procedure so that the internal scan load cyclehas a corresponding external cycle starting at the same time.

W28 (Timing Rule #28)In a named capture procedure, the measure_po time in the external mode must match theinternal mode. This error occurs if the measure_po time in the external mode does not match theinternal mode.



Measure_po time in external mode does not match internal mode in procedureP. (W28)


To troubleshoot this violation, check that there is a measure_po statement in both the internalmode and the external mode. If a measure_po exists in both modes, adjust the timeplate(s) toensure the measure_po occurs at the same time in both modes.

W29 (Timing Rule #29)In a named capture procedure, the force_pi time in the external mode must match the internalmode. This error occurs if the force_pi time in the external mode does not match the internalmode.

Force_pi time in external mode does not match internal mode in procedureP. (W29)


To troubleshoot this violation, check that there is a force_pi statement in both the internal modeand the external mode. If a force_pi exists in both modes, adjust the timeplate(s) to ensure theforce occurs at the same time in both modes.

W30 (Timing Rule #30)In a named capture procedure, an event on an internal pin is not allowed in the external mode.This warning alerts you that there is an internal pin event in the external mode of the procedure.

Event E N on internal pin is not allowed in external mode of procedure P.(W30)

E is the type of event, N is the name of the pin to which the event applies, and P is the procedurename.

The tool will ignore the internal pin event in the external mode; however, you can avoid theviolation by removing the internal pin event from the external mode.

W31 (Timing Rule #31)A named capture procedure that has an external mode must also have an internal mode. Thiserror occurs when an external mode exists without an accompanying internal mode.

Procedure P has an external mode but is missing an internal mode. (W31)


To correct this violation, do one of the following:



August 2006

• Add an internal mode definition to the named capture procedure, or

• Remove the “mode external =” statement and its corresponding “end;” statement fromthe named capture procedure.

Vector Interfaces Warning and Error Messages (AGRules)

This section provides information on Vector Interfaces General warnings and errors. These donot apply to the enhanced Vector Interfaces code. For more information on the enhanced VectorInterfaces, refer to “Test Procedure File” on page 311.

Vector Interfaces Warning #1A pin is specified as both a RAM write control and as a capture clock.

Pin P is used for both write control and pulse clock

Where P is the specified pin.

Vector Interfaces Warning #2A load_unload procedure has a period which is greater than the time of the last apply statement,and there are no other statements between the last apply and the end of the procedure.

Test procedure P for group G has no events between the last apply at timeT and the period V.

Vector Interfaces Warning #3Many ASIC vendors have a restriction on the number of timeplates to use in certain outputformats. Currently, two output formats have a restriction, FJTDL and TITDL. Therecommended number of timeplates for both FJTDL and TITDL is 1. If the number oftimeplates is exceeded, the user will receive a warning. However, the TITDL format allows anexception to this rule for timeplates used in clock_po procedures.

Use of N timeplates exceeds the recommended number for named format,please edit the procedure file to reduce the number of timeplates used.

Vector Interfaces Error #1The program has run out of virtual memory.

Out of Memory

Vector Interfaces Error #2A file which is to be written already exists and the you did not specify the -replace option.

Design Rules CheckingOther DRC Messages


File F exists already.

Vector Interfaces Error #3The Add Scan Group dummy command has been used to add a dummy scan group. Thedummy scan chain is used to add a test procedure when there are no scan chains in the design.You can’t save patterns with a dummy scan group and no scan chains in the design.

Patterns may not be saved for a design with dummy scan chain

Other DRC MessagesDRC generates various messages to indicate the status of various processes and state elements.Some of them are discussed here.

Transparent Capture Handling AnalysisIf you issue the Set Capture Handling command before running DRC, the tool generates ananalysis message upon completion of DRC.

Example// Begin capture handling analysis: LS=OLD,TE=OLD// (#C3=0 #C4=0), #user_pts=6/0// Capture handling analysis completed: #sources=6,// #int_gates=34, #sinks=4, CPU_time=0 sec

Figure 2-33 describes each component of the messages.

Figure 2-33. Transparent Capture Handling Analysis Messages

// Begin capture handling analysis: LS=OLD,TE=OLD

User-defined Set Capture Handling TE setting

// (#C3=0 #C4=0), #user_pts=6/0

# of C3 errors# of C4 errors# of source pts / # of sink pts

User-defined Set Capture Handling LS setting

// Capture handling analysis completed: #sources=6,// #int_gates=34, #sinks=4, CPU_time=0 sec

# of memory elements whose output value might not be captured

# of gates on path(s)

# of memory elements that might capture

CPU time to analyze (in seconds)

correctly without capture handling

between source(s) & sink(s)

incorrect values without capture handling



August 2006

Oscillation LimitationThe DRC simulator limits the maximum number of iterations performed to 500 whilestabilizing state changes. If state elements continue to change after the maximum number ofiterations is reached, the tool displays a message warning that the limit was reached.Additionally, the message reports each state element set to X to limit the iterations. Stateelements include latches, flip-flops, and feedback buffers.

S forced to X in procedure P at time T due to iteration limit.

Where S is the state element, P is the procedure type, and T is the time.

Example// latch1/Q (151) forced to X in procedure load_unload at// time 25 due to iteration limit.

RAM Summary Results and Test CapabilityUpon completion of RAM rules checking, DRC displays summary result information as well astest capability information.

Example// RAM Summary Results: #RAMs = 3 #TieXs = 0 #testable = 3// #data_hold = 3// Test Capability: #read_only = 0 #ram_sequential = 0// #seq_transparent = 0// Write stability: #unstable_control = 0 #unstable_load = 1// Read stability: #unstable_control = 0 #unstable_load = 3

Figure 2-34 describes the information displayed after running RAM rules checking.



Figure 2-34. RAM Summary Results and Test Capability Messages

// Test Capability: #read_only = 0 #ram_sequential = 0// #seq_transparent = 0

// RAM Summary Results: #RAMs = 3 #TieXs = 0 #testable = 3// #data_hold = 3

Number of clocked RAMs with hold for data_out

Number of testable RAMsNumber of RAMs replaced with TieXsNumber of detected RAMs

Number of RAMs which can be tested if treated as ROM (Read-only mode)

Number of RAMs testable with

Number of RAMs with sequential transparent (clock) procedures that

ram_sequential pattern

// Write stability: #unstable_control = 0 #unstable_load = 1// Read Stability: #unstable_control = 0 #unstable_load = 3

# of write ports with A6 violations except in seq transparent (clock) procedures# of write ports with A1 violations

# of read ports with A7 violations# of read ports with A6 violations except in seq transparent (clock) procedures

allow testing in dynamic pass-through mode



August 2006


Chapter 3Using DFTInsight

Overview of DFTInsightThe DFT tools, FastScan, FlexTest, TestKompress, DFTAdvisor, and YieldAssist, all usenetlist-based designs. Debugging DRC violations and other testability problems using theReport Gates command to navigate the netlist and textually display connectivity and simulationdata can be time-consuming. However, DFTInsight can translate a specified portion of a netlist-based design into schematic form. Therefore, DFTInsight complements the other netlist-basedDFT tools with its ability to generate and display schematics. DFTInsight adds to the DFT toolsuite the ability to graphically investigate and interact with designs, thus facilitating testabilitydebugging efforts.

DFTInsight is an optional product that you can invoke from within FastScan, FlexTest,TestKompress, DFTAdvisor, or YieldAssist. Figure 3-1 shows the use of DFTInsight within theFastScan, FlexTest, TestKompress, DFTAdvisor, and YieldAssist flows.

NoteWhen the schematic viewer is closed, the DFTInsight license is released. The windowand its context remain so that if the viewer is reopened, the license will be re-obtainedand the last viewed schematic will be shown.


Using DFTInsightOverview of DFTInsight

August 2006

Figure 3-1. DFTInsight Process Within the DFT Tools

To access DFTInsight, you must first invoke DFTAdvisor, FastScan, FlexTest, TestKompress,or YieldAssist. After setting up the appropriate parameters for either scan insertion or ATPG,you move out of Setup mode. When you do this, the tools perform a number of processes:model flattening, circuit learning, and DRC. You can invoke DFTInsight prior to this, but canonly utilize its capabilities after these processes complete.

If the rules-checking process encounters a violation, invoke DFTInsight to help investigate theproblem. In addition to DRC violations, you can also use DFTInsight to analyze the design forother testability problems you may want to explore, such as gate reporting to assist you withfault analysis.

Invoke Tool

DesignFlattened? Y

N

Flatten Model

Learn Circuitry

Perform DRC

PassChecks?

N

Setup Info

Invoke Tool

Setup Display List

Examine Circuit

DFTInsight

DFT Tools

Y

Perform OtherProcesses

DesignAnalysisNeeded?

Y

N

Fix Problem inCircuitry/Setup

DFT or Design Tool



NoteYou can only access DFTInsight from within Setup or DRC modes in FlexTest, fromwithin Setup or DFT modes in DFTAdvisor, or from any system mode in FastScan,TestKompress, or YieldAssist, once a flattened design exists.

Inputs and OutputsTo display a schematic, DFTInsight requires that the invoking tool creates a special netlist froma flattened design model and a list of display instances. If a flattened design does not exist whenyou invoke DFTInsight, or if there is not yet a list of display instances, the display withinDFTInsight appears empty.

A flattened model is an internal representation in which the tools flatten the design’s hierarchydown to its simulation primitives. This is the design representation that FastScan, FlexTest,TestKompress, DFTAdvisor, and YieldAssist use during their processes. The applicationscreate a flattened design model either during an attempt to exit Setup mode (as shown inFigure 3-1) or when you issue the Flatten Model command. “The Flattening Process” section inthe Scan and ATPG Process Guide discusses design flattening in more detail.

You can manually create the list of instances to display by issuing one of the DFTInsightcommands that add circuitry to the netlist, such as Add Display Instances. Commands thatanalyze circuitry, such as Analyze Drc Violation, also automatically change the list of displayinstances.

NoteDFTInsight does not require any special symbol library for its display purposes.

Figure 3-2 shows the inputs and outputs of DFTInsight and its interaction and dependency onDFTAdvisor, FastScan, FlexTest, TestKompress, and YieldAssist.

Once the invoking application creates a flattened model and establishes a display list, itgenerates and passes a netlist to DFTInsight. DFTInsight then displays the netlist-specifiedcircuitry. Each time the display list changes, DFTInsight updates the schematic viewaccordingly. This procedure repeats each time you want to examine a new piece of circuitry.



August 2006

Figure 3-2. DFTInsight Inputs and Outputs

You can set up parameters to control the information that the schematic view displays for thecircuit. You can also instruct DFTInsight to report additional design information in thetranscript.

DFTInsight FeaturesYou can invoke DFTInsight using either the Open DFTInsight button or executing the OpenSchematic Viewer command in FastScan, FlexTest, TestKompress, DFTAdvisor, andYieldAssist. Within these tools, you can use DFTInsight to troubleshoot DRC violations as wellas perform general analysis of the design. DFTInsight can:

• Display design, low-design, and primitive-level design information.

• Display a portion of circuitry centered around a specific gate.

• Display forward or backward tracing from selected circuitry.

• Display circuitry associated with numerous design rules violations.

• Display feedback paths.

• Display scan chain circuitry.

• Display circuitry between a starting and ending instance.

• Display defined paths for FastScan or TestKompress path-delay testing.

Info.Report

Display

DFT Tool

DFTInsight

DisplayList

Setup

FlattenedDesign

Netlist

SchematicDisplay

Using DFTInsightThe User Interface


• Display simulation values used to analyze DRC violations—in exactly the same way asthe Set Gate Report and Report Gates commands.

• Display other information including instance names, instance types, pin names, andinstance ID numbers.

• Display additional information, including scan cell, RAM/ROM, and learned data, in atextual format.

• Undo and redo previously-generated schematic views.

“Performing Basic Tasks” on page 167 describes the functionality common to all DFTapplications.

The User InterfaceThis section describes the various aspects of the DFTInsight user interface, which includesunderstanding the session window, setting preferences, and using the shortcuts.



August 2006

The DFTInsight Session WindowWhen you click on the Open DFTInsight button or issue the Open Schematic Viewercommand from FastScan, FlexTest, TestKompress, DFTAdvisor, or YieldAssist, theapplication invokes DFTInsight in a separate window. Figure 3-3 shows the DFTInsightwindow and its different components (which are described following the figure).

Figure 3-3. DFTInsight Session Window

• Schematic View Area — The area that displays the schematic defined by the currentlist of display instances. You can control the preferences for the displaying of objects,

Pulldown Menus Tool Bars

Message Area Schematic View Area



the color of objects, and the naming of objects using the Setup > Preferences menuitem.

• Message Area — The area that displays notes and warnings from any of the followingapplications: FastScan, FlexTest, TestKompress, DFTAdvisor, YieldAssist, andDFTInsight. This area also displays information on the selected objects when you clickon the Report palette button. You can control whether the information transcripts hereor in the session’s Transcript area by clicking on the Message Area button. The “<=” (tothe session) in the button shows you where the messages are transcripted. The default isto use the session transcript.

• Pulldown Menus — The area at the top of the session window that provides menuselections for common functionality.

• Popup Menus — Within the Schematic View and Message areas, popup menus areavailable by clicking with the right mouse button.

o Common popup menu — In the Schematic View area everywhere except over aninstance or pin

o Instance popup menu — In the Schematic View area over an instance

o Pin popup menu — In the Schematic View area over a pin

o Message popup menu — Anywhere in the Message area

• Tool Bar — The icons just below the pulldown menu bar and on the left side of theSchematic View area (by default) that provide quick access to a variety of commonly-used features. You can control the position of the Tool Bar items using the Setup >Preferences: Miscellaneous menu item.

Using StrokesWithin the Schematic View area of the DFTInsight window, you can use strokes to change theview, zoom in or out, and close the DFTInsight window. The middle mouse button is used todraw the stroke. To view the list of strokes, execute the Help > Mouse Button Strokes menuitem.

Setting and Saving PreferencesYou can set and save many different characteristics of the DFTInsight window. These includehow to display gate information, pin names, object colors, instance names, tool bar position,tool tips, and transcripting. To change one of these settings perform the following:

1. Execute the Setup > Preferences menu item. The Setup DFTInsight Preference dialogbox opens and displays four tabs.

2. Make your changes to the characteristics.



August 2006

3. Click the OK button to have the changes only affect this DFTInsight session, or clickthe Write Prefs button to write the changes to your home directory for use in allDFTInsight sessions.

The preferences are saved in the $HOME/.dftinsightrc file. Do not edit this file. If you want toreturn to the system defaults for all characteristics, delete the file by clicking the RemoveExisting Preferences File button under the Miscellaneous tab, or delete it using the windowenvironment setup.

Using the Schematic View Area ModesIn the Schematic View area, you have four different modes for selecting objects and changingthe contents of the window. Each of these modes affects the behavior of the mouse buttons, asdescribed in Table 3-1. The right mouse button always opens the Common menu when not overan instance or pin.

Selecting Objects in the Schematic ViewYou can select instances and nets within the Schematic View area of the DFTInsight applicationwindow. When an instance is selected, you can perform operations such as marking, forwardand backward tracing, deleting (from display), reporting, and centering the view. When a net isselected, you can center the view on the net.

To select a single object in the schematic (in the Select mode), click the left mouse button whilethe cursor is on the desired object. To select one or more items in the displayed schematic, pressthe left mouse button and drag the cursor so that the white bounding box at least partiallycontains all of the objects you want selected. While in the process of selecting multiple objects

Table 3-1. Mode Definitions

Mode Left Mouse Button Right MouseButton

Purpose

Select Click on an instance,net, or pin. Press,drag, and releaseover an area.

Opens the object-specific menu overan instance or pin.

Selects objects to perform otheroperations, such as marking,forward/backward tracing,deleting, and reporting. Default.

EZ-Trace Click on an instanceor pin to tracebackwards.

Click on an instanceor pin to traceforwards.

Makes schematic navigationeasier.

View Area Press, drag, and thenrelease over the area.

Opens the objectspecific menu overan instance or pin.

Views an area.

ViewCentered

Click to specifylocation.

Opens the objectspecific menu overan instance or pin.

Centers the view area around thelocation.

Using DFTInsightPerforming Basic Tasks


(bounding box active), you can cancel the operation by pressing the ESC key. You can select allobjects by executing the [Un]Select > Select All popup menu item.

Tracing is done using a right mouse button click over an instance or pin, or clicking on aninstance or pin in EZ-trace mode. This will select the instance or pin from which the trace isinitiated. Any previously selected object is deselected.

DFTInsight places selected objects in a selection set and displays them in white (by default). Toadd more items to the selection set, press the Shift key while simultaneously selecting one ormore additional objects. If you do not press the Shift key, each previous selection becomesunselected.

To unselect all items, you can click on the Unselect icon or use the [Un]Select > Unselect Allpopup menu item.

Performing Basic TasksThis section provides an introduction to using DFTInsight from within FastScan, FlexTest,TestKompress, DFTAdvisor, and YieldAssist. After specifying the basics tasks you canperform, this section shows a number of examples. For more detailed information on commandusage, refer the Command Dictionary of your tool’s reference manual.

Invoking DFTInsightYou can invoke DFTInsight at any time from within FastScan, FlexTest, TestKompress,DFTAdvisor, or YieldAssist. You can click on the Open DFTInsight button or issue the OpenSchematic Viewer command. The DFTInsight window opens, as shown in Figure 3-3 onpage 164.

DFTInsight must have a valid flattened model and an instance list in order to display graphicalinformation. From within FastScan and TestKompress, you can access DFTInsight functionalityat any time after flattening. From within DFTAdvisor, you can access DFTInsight functionalityafter flattening from either the Setup or DFT mode. And from within FlexTest, you can accessDFTInsight functionality after flattening, in either Setup or Drc system modes.

Interrupting OperationsYou can use the Ctrl-C key combination to interrupt lengthy schematic drawing processes. Thiskeystroke effectively cancels the current operation and reverts to the previously-displayedschematic.

You can use the Esc key to terminate a View Area or Select Area operation that involves adynamic bounding box. You can press the Esc key while the bounding box is active, toeliminate the box and cancel the operation.



August 2006

Choosing the Design LevelYou can specify the hierarchical level of circuitry you want DFTInsight to display. You set thedesign level to either Design or Primitive with the Setup > Design Level pulldown menu itemor the Set Gate Level command (discussed in more detail on page 27). This causes DFTInsightto immediately redraw to display the specified level of circuitry, if the Schematic View Area iscurrently displaying circuitry. At invocation, DFTInsight inherits the current design level(typically the Design level) of the invoking tool.

The Design level displays circuitry in true hierarchical blocks. The Low_design level displayscollections of primitive gates which exist within library cell boundaries. The Design andLow_design levels do not provide inverter/buffer compaction. The Primitive level displays thedesign flattened down to its primitive gates. DFTInsight displays combinational primitive gateswith their Boolean shapes and all other gates as boxes. The “Setting the Level of Gate Data”section gives examples of the circuitry it displays at each design level.

NoteDFTInsight shows gate identification numbers (ID#s) with displayed instances only if thedesign level is set to Primitive.

The process of design flattening can introduce a number of artificial, cascading, duplicated, andother gate types into the design. These gates model bidirectional circuitry, model gates withmany inputs, break feedback paths, replace non-scan design elements, and so on. When youchoose to view schematics at the Design level, DFTInsight does not directly display these gatetypes.

Artificial and cascading gates merge into either design-level instances themselves or theconnectivity between them. Artificial gates that model bidirectional translation do not display atall. Duplication or TIEX gates merge into the connectivity between instances in the feedbackloops. TIE gates that replace non-scan cells show only at the primitive level. For FastScan andTestKompress, TIE gate information appears as an attribute in the lower center of the displayedsymbol.

Figure 3-4 shows where DFTInsight places the artificial gate type within the displayed instanceinformation.



Figure 3-4. DFTInsight Instance Information

Specifying the Gate Data to ViewYou can specify the type of information you want DFTInsight to display. You set the displayinformation with the options of the Setup > Reporting Detail pulldown menu item.

For example in FastScan, if you want to set the displayed data type to include clock cone datafor the circuit clock, clk1, you would use the “Clock Cone Data Based on Clock” option in thedialog box and specify clk1 as the clock pin name. This causes an immediate redraw if theSchematic View Area is currently displaying circuitry.

NoteThis function is identical to the application command Set Gate Report. For details on thetypes of data you can specify with this functionality, refer to the Set Gate Reportreference page in the ATPG and Failure Diagnosis Tools Reference Manual or to the SetGate Report reference page in the DFTAdvisor Reference Manual or to “Setting the GateInformation Type” on page 28.

Controlling the Displayed InformationDFTInsight creates a visual display of the netlist segment that DFTAdvisor, FastScan, FlexTest,TestKompress, or YieldAssist passes to it. You can control the format of the displayedinformation from the netlist using the Setup > Preferences: Schematic pulldown menu item orthe Set Schematic Display command.

For example, if you want to streamline your schematic view by hiding all unused input andoutput connections, while increasing the pin data to five characters, you would:

1. Execute the Setup > Preferences menu item, then click on the Schematic tab.

/i1/i2/i3/data/i1/i2/d[3]

clk

“0101”

273

pin_data

pin_data

pin_data[net_name]

“X110”

CK

“1100”D

DFF

/i1/i2/i3/i4/i6

[ID#]

[net_name]pin_name

pin_name[net_name]

pin_name

type_nameinstance_name

Q

artificial typeTIEX

Instance Information Example



August 2006

2. Hide unused inputs and outputs by setting the button to Inputs and Outputs.

3. Specify the number of characters to use for pin data to “5”.

For more information on using this command, refer either to the Set Schematic Displayreference page in the ATPG and Failure Diagnosis Tools Reference Manual or to the SetSchematic Display reference page in the DFTAdvisor Reference Manual.

Forward TracingWhile debugging DRC violations in DFTInsight, it is often desirable to limit the displayedinstances and tracing to specific paths. DFTInsight allows you to either forward-trace allfanouts of a pin simultaneously or one fanout at a time (to be utilized in an incremental fashion).

DFTInsight allows forward tracing from a pin using two different Trace Modes:

• Forward Trace All Pin Fanouts — This is the default Trace Mode, which forward-traces all fanouts of a pin simultaneously.

• Forward Trace One Pin Fanout — This mode forward-traces only one fanout of a pinat a time. If a pin has more than one fanout, each subsequent request to forward-tracefrom a pin will display the next not-yet-displayed fanout of a pin, until all fanouts aredisplayed.

You can set the mode using the Setup > Preferences: Schematic Trace Mode menu item or theSet Schematic Display command. You can also override the Trace Mode on a per pin basisusing the pop-up menu items, Forward > Trace One and Forward > Trace All.

NoteThe Trace Mode controls only the forward-tracing from a pin, and only the tracing underthe EZ-Trace Mode.

Trace FlagsDFTInsight indicates whether all fanouts of a pin are currently displayed or some of the fanoutsare still to be forward-traced with a red triangle symbol, as shown in Figure 3-5. Pins with morefanouts to be displayed are marked with this triangle symbol when the Trace Mode is set toForward Trace One Pin Fanout. This triangle symbol disappears as soon as all fanouts of apin are displayed and reappears when a “to” instance, corresponding to any of the multiplefanouts, is removed from the schematic.



Figure 3-5. Trace Flag

In Forward Trace All Pin Fanouts mode, the red triangle symbol is not displayed, even whenthe Trace Mode is overridden for a particular pin through the Trace > Forward One menuitem.

For more information on using the Trace Mode, refer either to the Set Schematic Displayreference page in the ATPG and Failure Diagnosis Tools Reference Manual or to the SetSchematic Display reference page in the DFTAdvisor Reference Manual.

Reverting to a Previous Schematic ViewDFTInsight provides the facility to undo and redo operations. This feature lets you revert backto previous versions of the displayed schematic. You access this capability with the pulldownmenu items Display > Undo and Display > Redo, the Tool Bar buttons Undo and Redo, or theUndo Display and Redo Display commands.

DFTInsight keeps a history of the previous 19 schematic views drawn, allowing you to revisitany of these views with the Undo facility. Successive undo operations move you backwardthrough the display history of the last 19 schematic views. Successive redo operations move youforward through the display history up to the last (current) view in the history.

NoteIf you revert to a previous view using the undo capability, and then issue a DFTInsightcommand that creates and displays a new view, you create a new display history fromthat point forward. When this occurs, you can no longer move from that point forwardthrough the previous history with the Redo Display command.

Displaying Specific InstancesDFTInsight displays a schematic using a partial netlist that the invoking tool provides. You canexplicitly call out specific gates for this netlist or have the system generate the netlist based onanalysis of DRC violations. This section discusses how you can explicitly specify various typesof circuitry for display by using the Display > Additions menu item or the corresponding Add



August 2006

Display Instances command. Troubleshooting DRC Violations discusses netlist generationbased on DRC violations.

For complete Add Display Instances command syntax, refer either to the Add Display Instancesreference page in the ATPG and Failure Diagnosis Tools Reference Manual or to the AddDisplay Instances reference page in the DFTAdvisor Reference Manual.

Displaying Specific GatesYou can add specific instances to the netlist using the Display > Additions menu item (or Addicon), then clicking the Named Instances tab. You can specify a gate by either its ID number,the pathname of a pin connected to the gate, or the instance name of the gate itself.

NoteDFTInsight automatically marks the specified instance. For more information on markinginstances, refer to “Marking an Instance” on page 177.

For example, if you want to display an instance with ID number 15, you would enter “15” in theGate Id field of the Make Additions to Display dialog box.

Displaying Circuitry in a Backward Clock ConeYou can examine circuitry within a trace back cone of a specific gate by using the BackwardTrace tool bar button (for a single level back trace), the Display > Backward Trace menu(many options), or the Add Display Instances command. You can also enter the EZ-Trace modewhich lets you click the left mouse button on an instance or pin to backward trace one level, orclick the right mouse button to forward trace one level.

For example, assume that DFTInsight is currently displaying the circuitry in Figure 3-6

Figure 3-6. DFF Display

This circuitry includes a gate with ID number 14, but not the circuitry connected to the inputs ofthe gate. To examine the circuitry directly connected to the inputs, select the gate and click on

DFF

clk X

/I$1

0

0

X

X

*

*

d

14



the BackTrace toolbar button. DFTInsight displays the circuitry connected to the inputs asshown in Figure 3-7.

Figure 3-7. Connected Circuitry

Displaying Circuitry in a Forward Clock ConeYou can examine circuitry within a trace forward cone in the same way as a trace back cone.You can use the Forward Trace tool bar button (for a single level forward trace), the Display >Forward Trace menu (many options), or the Add Display Instances command.

For example, assume that DFTInsight is currently displaying circuitry that includes a gate withID number 12, but not the circuitry connected to the output of the gate. To examine the circuitrydirectly connected to the output of gate 12, select the gate and click on the Forward Trace toolbar button.

Displaying Levels of Input Circuitry for a Displayed GateYou can examine circuitry connected to the “nth” input of a displayed gate by selecting a gate,then executing the Display > Backward Trace > N Levels menu item. In the dialog box,specify the number of gates back from the input to trace and display.

For example, assume that DFTInsight is currently displaying some circuitry. This circuitryincludes a gate with ID number 10, and you would like to see the circuitry connected threelevels back from the first input of the gate. To get DFTInsight to display this circuitry, enter thefollowing command:

SETUP> add display instance 10 -i 0 -backward -level 3

DFF

clk X

/I$1

0

0

X X

*

*

d

14

X

0

0 1

1

0/I$2

/I$1

/I$1

12

X

1

10

11

X

X

/I$3

13



August 2006

NoteDFTInsight marks the gate directly connected to the specified input pin.

Displaying Levels of Output Circuitry for a Displayed GateYou can examine circuitry connected to the “nth” output of a displayed gate by selecting a gate,then executing the Display >Forward Trace > N Levels menu item. In the dialog box, specifythe number of gates back from the input to trace and display.

For example, assume that DFTInsight is currently displaying some circuitry. This circuitryincludes a gate with ID number 15, and you would like to see the circuitry connected two levelsforward from the first output of the gate.

To get DFTInsight to display this circuitry, enter the following command:

SETUP> add display instance 15 -o 0 -forward -level 2

NoteDFTInsight marks the specified gate.

Displaying Circuitry Between Two InstancesDFTInsight can display the circuitry that lies in a path between two specified instances. You usethis feature by selecting the Display >Additions: Path menu item or issuing the Add DisplayPath command.

If you specify two instances, DFTInsight displays the circuitry in the path between them,including and marking the instances you specify. If you specify only one instance, DFTInsightassumes this instance to be in a feedback loop and displays the loop, or issues an error messageif the instance does not reside within a loop.

NoteState elements and TIE gates block the display of the path in the Schematic View area.DFTInsight only displays complete paths that include these gate types if you issue the -Noblock switch.

For example, if you wanted to display the path between instances 2 and 21, which includes aDFF, you would enter:

SETUP> add display path 2 21 -noblock



Displaying Paths Defined for Path Delay Testing (FastScan andTestKompress)

DFTInsight can display the paths defined in a path definition file that you load into theapplication. You use this feature by selecting the Display > Addition: Path Delay menu itemor using the Add Display Paths command.

For example, if you want to display “path3” from a loaded path definition file, select the path inthe dialog box, or enter the command:

SETUP> add display path -delay_path path3

For more information on path delay testing and path definition files, refer to “The PathDefinition File” section in the Scan and ATPG Process Guide.

Displaying Scan Cells in a ChainDFTInsight can display the circuitry that lies in a path between two specified scan cells. Youuse this feature by selecting the Display > Addition: Scan Path menu item or issuing the AddDisplay Scanpath command.

You must specify the scan chain name, but optionally specify the scan cell positions. If you donot specify the scan cell positions, DFTInsight displays all the circuitry from the scan chain‘sprimary input pin (symbolized by “SCI”) to the scan chain’s primary output gate (symbolizedby “SCO”). If you want to display only a portion of the scan chain circuitry, you can specifyposition numbers from 0 to N for an N+1 bit chain. Position 0 indicates the scan cell closest tothe scan output pin.

NoteWhen DFTInsight displays the scan chain circuitry, it marks the starting and endinggates.

For example, on a small design, if you want to see the entire scan chain from the scan input pinto the scan output pin, select the chain name, input and output cells in the dialog box, or enterthe command:

SETUP> add display scanpath chain1 SCO SCI

As another example, assume you want to troubleshoot a larger, more complex design, focusingon the circuitry between the last scan cell and the scan output pin for the scan chain. In this case,you would enter:

SETUP> add display scanpath chain2 0 SCO



August 2006

Displaying Feedback LoopsDFTInsight can display the circuitry that lies in a feedback path. You use this feature byselecting the Display > Additions: Loop menu item or issuing the Add Display Loopcommand. You must specify either the pin pathnames of pins within loops, loop identificationnumbers (obtained from the Report Feedback Paths command), or all loops. For example, if youwant to report on loops in the design and then display loop 1, enter the following commands:

SETUP> report feedback paths

Loop = 1: not_duplicated (broken by constant value) mcontrol_pulcnt_cdet_sin10_5_i0_inv/in (INV) mcontrol_wms_uqsc_SYN__G26_inv/in (INV) mcontrol_wms_uqsc_SYN__G25_nand/ (INV) mcontrol_wms_uqsc_SYN__G25_nand/in[1] (AND) rom_ptec_rom0/ (ROUT) rom_ptec_rom0/read (ROM) rom_ptec_nor0/ (INV) rom_ptec_nor0/in[2] (OR) mcontrol_spt_bot_SYN__G4_inv/in (INV) mcontrol_spt_bot_SYN__G5_inv/in (INV) . . .

SETUP> add display loop 1

Floating Net SymbolIf a pin of an instance is not connected, DFTInsight connects a wire stub to the pin, along with asymbol (a circle with an X through it) to indicate there is no connection. Any unconnectedinstance is displayed in this manner.

Figure 3-8. Floating Net Symbol

Removing Instances from the DisplayYou can remove instances from the displayed circuitry in the Schematic View area. You canaccomplish this task by selecting an instance, then executing the Delete Instance > Selectedpopup menu item or clicking on the Delete toolbar button. The corresponding command isDelete Display Instances.

You can clear the entire display by executing the Delete Instance > All popup menu item orclicking on the Delete All toolbar button.



Marking an InstanceYou can mark or unmark the selected objects using the Mark and Unmark popup menu items.Marking an instance is used to later view the instance using the View Marked button. Whenyou click on the View Marked button, the marked instances are centered in the SchematicView area. Marked instances are highlighted in yellow. The corresponding commands are Markand Unmark.

Troubleshooting DRC ViolationsDFTInsight lets you investigate the cause of numerous DRC violations. DFTInsight supportsthis functionality for design rules:

A1 through A7C1 through C9D1 through D11E2 through E9S1 through S2T2 through T7, T11, T16, and T17

If the rules checker encounters violations, FastScan, FlexTest, TestKompress, DFTAdvisor, orYieldAssist display occurrence messages that each include a rule ID number and a violation IDnumber. Additionally, you can get more information on specific violations by using the ReportDrc Rule command. This command tells you which gates caused the violation.

The DFTInsight command Analyze Drc Violation goes one step further and creates a netlist ofthe circuitry associated with a violation ID. You can access this feature using the Analyze >DRC Violation menu item (which opens a dialog box listing the violations), or by issuing theAnalyze Drc Violation command as follows:

ANAlyze DRc Violation rule_id-occurrence#

This command immediately updates the netlist, and displays the circuitry and data relevant tothe specified violation. Additionally, if you are using the Analyze > DRC Violation menu item,it lists the associated DRC message (you would normally see with the Report Drc Rulecommand) at the bottom of the DFTInsight window.

The type of data DFTInsight displays depends on the particular rule violation. For example,analyzing a C3 rules violation automatically sets the gate reporting to clock_cone. The invokingtool transcripts a message indicating the gate report data type change. The set data type remainsuntil you either explicitly change the gate report type (using Set Gate Report) or you analyzeanother violation that displays a different type of data.

The following example shows the general use of Analyze Drc Violation. Assume rules checkingfailed on a D7 violation as follows:

// Warning: 1 edge-triggered clock ports set to stable high. (D7)



August 2006

To get a little more information within the invoking application, issue the following command:

ATPG> report drc rules d7-1

This command specifies the gate(s) causing the violation as such:

// Warning: Flipflop /I$3 (16) has clock port set to stable high. (D7-1)To display circuitry and data corresponding to this violation, execute the Analyze > DRCViolation menu item (selecting the D7-1 violation ID). DFTInsight displays a portion of thenetlist, marks the particular gate (16) associated with the specified D7-1 rules violation, and (ifyou are using the menu item) displays the text in the Report Display Area that the Report DrcRule command would normally provide. In this example, DFTInsight displays the circuit inFigure 3-9.

Figure 3-9. MUX and DFF

Troubleshooting ExampleThis example is designed to troubleshoot errors encountered during the DRC process. In thiscase, the design is a 1 flip-flop scan chain. FastScan has already added all the appropriate clocksand set up the scan information. At this point, the design has encountered a C1 (clock rule)violation and has failed the rules checking process.

Clock PIs off failed to force off a clock line of T N (G).(C1-1).

In this message, T is the type of scan memory element (MASTER, SLAVE, and so on), N is theinstance name of the gate, and G is the gate ID number.

FastScan automatically prompts you to troubleshoot this violation using DFTInsight. Fromwithin the DFTInsight application window:

1. Set the gate reporting to Error Pattern.

DFF

clk X

/I$3

*

*

d

16

1

1

X 1

14

/I$1

MUX

s0

i0

i1 out



Select the Setup > Reporting Detail pulldown menu item. Select the Simulated ValuesCausing DRC Error option. This sets the data to the type present when the erroroccurred.

2. Set the design level to Primitive.

Select the Setup > Design Level > Primitive pulldown menu item.

3. Analyze the gates pertinent to the rules violation.

Select the Analyze > DRC Violation pulldown menu item and select“C1-1” under “Failed DRCs...Qty,” then click the Analyze button.

This automatically creates a list of instances pertinent to the specified rules violation.

Look at the primary inputs to each gate. In this case, the C1 rules violation indicates thata “clk” signal is at an X state. This check examines the state of the circuit when all theclocks are off and pins are constrained. Thus, no clocks should be at X states—theyshould all be at their off-states.

4. Examine where this signal is coming from by tracing back to see the primary inputsignals feeding this gate.

Click on the X input of the gate to select this signal, then click on the BackTrace palettebutton. Do the same for the other input. You should see that one of the primary inputs isat an X value. You must place a value on this signal to pass the clock through the gate.

Reporting Object InformationYou can textually display information about the specific instances in the Message area byselecting an instance, then executing the Report menu item in the Instance popup menu, or byclicking on the Report tool bar icon. The full information reported for instances includes thefull instance name and the names, directions (input or output), and net connections of each ofthe pins.

When you click the right mouse button over an instance or pin, the popup menu displays thename of that object at the top of the menu.

If you turn on learn reporting (using Set Learn Report ON in FastScan and TestKompress), or ifthe selected instance is a scan cell or RAM/ROM, the information contains other pertinent data.The corresponding command is Report Display Instances.

Saving and Recalling a SchematicDFTInsight has the ability to save a schematic that is currently being displayed. You can viewthis schematic later, using DFTInsight. You can save the schematic by executing the File >Save > Schematic menu item. You can load a previously saved schematic using the File >Open > Schematic menu item.



August 2006

Saving and Replaying the Session TranscriptDFTInsight commands transcript in the invoking application (DFTAdvisor, FastScan, FlexTest,TestKompress, or YieldAssist). For example, if you invoke DFTInsight from FastScan, andthen proceed to perform operations within the DFTInsight application window, the FastScansession lists the commands associated with the operations you perform.

You can have the DFTInsight commands transcript in the DFTInsight Message area by clickingon the Message Area button. The “<=” on the button changes to “=>” to indicate where themessages are currently being transcribed.

To save the DFTInsight Message area transcript, you can use the File > Save > Message Areamenu with either the All Lines or Commands Only menu item. You can replay thesecommands using the Dofile button within the invoking application.

Printing the Displayed SchematicYou can use the File > Print menu item or the Print tool bar button to print the currentlyviewed contents of the Schematic View area to a printer, file, or both. When you select File >Print, DFTInsight opens a dialog box with several options. If you choose to send the job to theprinter:

• UNIX — The UNIX print command is shown in the Print Command field. DFTInsight,by default, uses the lp print command:

lp -s -d<default_printer>

The default_printer is set, by default, to the value of the LPDEST or PRINTERenvironment variable (in that order).

The rest of the print options include paper size and orientation of the image.

If you chose to send the job to a file, specify a pathname (or use the Browse button) and afilename in which to write the file. DFTInsight generates a postscript version of the displayedschematic.

Closing the DFTInsightTo close the DFTInsight window, use the File > Close menu item, the Close stroke, or issue theClose Schematic Viewer command from within DFTAdvisor, FastScan, FlexTest,TestKompress, or YieldAssist.


Chapter 4Design Library

This section shows you how to specify scan information, define models and macros, and readmultiple libraries. In addition, it gives descriptions and library information for the primitivessupported by DFTAdvisor, FastScan, FlexTest, and TestKompress.

For information on memory modeling for MBISTArchitect, refer to “DFT Library Modeling forMemories” in the MBISTArchitect Reference Manual.

The specific topics covered in this section include:

Defining Scan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Defining a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Defining Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Using Model Aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Reading Multiple Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Verilog Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Supported Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Defining Scan InformationBecause it is required for scan insertion, the design library should provide information formapping non-scan models to their associated scan cell models. This information is found in themodel or macro description of a scan cell. The specific scan information includes the scan input,scan output, scan enable (for Mux-scan style), scan clock (for Clocked-scan style), scan masterclock, scan slave clock (for LSSD-scan style), and the mapping of scan cell model to its non-scan cell model.


Design LibraryDefining Scan Information

August 2006

Defining a Scan Cell ModelAll scan information related to a scan cell model is grouped together in the model or macrodescription by the following syntax:

model model_name(list_of_pins) ( scan_definition ( type = scan_cell_type; data_in = pin_name; scan_in = pin_name; scan_out = pin_name, ...; scan_enable = pin_name; scan_enable_inverted = pin_name; scan_clock = pin_name; scan_master_clock = pin_name; scan_slave_clock = pin_name; offstate_inverted = pin_name, ...; tie0 = pin_name, ...; tie1 = pin_name, ...; usage = <input|output|hol0|hol1>; non_scan_model = model_name(list_of_pins);test_clock = pin_name;test_enable = pin_name;test_set = pin_name;test_reset = pin_name;set_disabled;reset_disabled;) <model or macro description> . . . )

The scan_definition keyword is followed by a list of scan model attributes. While someattributes need to be specified for all scan model types (such as: type, scan_in, scan_out, andnon_scan_model), others are more specific to a particular scan style. For example, scan_enableand scan_enable_inverted only apply to Mux-scan style; scan_clock is for Clocked-scan style;and scan_master_clock and scan_slave_clock are used only for LSSD-scan type.

The following list describes each of the scan definition attributes in more detail:

• data_inThe “data_in” attribute is an optional attribute that defines the name of the data input pinof the mux-DFF scan cell.

• non_scan_modelThe “non_scan_model” attribute is an optional attribute that defines the non-scan cellmodel name. The list_of_pins is the list of pins in the scan model which map to those inthe non-scan model. The number of pins in the list_of_pins is typically the same as thatin the non-scan model. If the number is not the same, you must tie the extra pins eitherhigh or low using the “tie1” or “tie0” attributes.

The pin names listed in the non-scan models map by position to pins in the originaldescription of the non-scan model, but use the names of the scan model to establish theproper connectivity. For example, the original model definition of a DFF might list the



interface pins (CK, D, Q, and QN), while the corresponding scan model SDFF lists theinterface pins (CP, D, SI, SE, Q, and QNOT). In this case, the non_scan_model attributeestablishes pin mapping between the DFF and SDFF by using the following syntax:

model SDFF (CP, D, SI, SE, Q, QNOT)...

scan_definition (...

non_scan_model = DFF(CP, D, Q, QNOT);...

In the case of multiple non-scan models mapping to one scan model, if you rip-upexisting scan circuitry, DFTAdvisor replaces the scan model in the netlist with the firstnon-scan model defined by the non_scan_model attribute.

The scan cell model definition can contain only one non_scan_model statement.However, you can map multiple non-scan models to one scan model by listing multiplenon-scan models and their pin lists, separated by commas as follows:

non_scan_model = model1(in1, in2, in3, out1, out2), model2(i1, i2, i3, o1, o2), model3(in1, in2, in3, out1);

If the scan definition section does not contain a non_scan_model attribute, this informsDFTAdvisor that while the cell is a scan cell, there is no equivalent non-scan cell in thelibrary.

• scan_clockThe “scan_clock” attribute defines the scan clock of the clocked-scan cell.

• scan_enableThe “scan_enable” attribute defines the name of the scan enable pin associated with themux-scan cell. When this pin is 1, the cell is in scan mode.

• scan_enable_invertedThe “scan_enable_inverted” attribute defines the name of the scan enable pin associatedwith the mux-scan cell. When this pin is 0, the cell is in scan mode.

• scan_inThe “scan_in” attribute, which is always required in the scan cell definition, defines thename of the scan input pin of the scan cell.

• scan_master_clockThe “scan_master_clock” attribute defines the name of the scan master shift clock of theLSSD cell.

• scan_outThe “scan_out” attribute, which is always required in the scan cell definition, defines thenames of the candidate scan output pins of the scan cell. During the scan stitchingprocess, the selection of the output pin is made based on the lowest fanout count of eachof the candidates.



August 2006

• scan_slave_clockThe “scan_slave_clock” attribute defines the name of the scan slave shift clock of theLSSD cell.

• offstate_invertedThe “offstate_inverted” attribute describes a change in off-state between a non-scanelement and its associated scan cell. This is useful when a non-scan flip-flop is mappedto a latch-based scan cell, and the off-state of the clock is different for the two models. Ifthis attribute is not used, DFTAdvisor can still perform scan insertion; however, thedesign will not pass the clock rules checks. The specified pin_name(s) must be clockpins.

• tie0The “tie0” attribute is used when a scan model has more pins, such as extra set or resetlines, than the non-scan model to which it maps. This attribute specifies that the extrapin should be tied low after the scan is inserted.

• tie1The “tie1” attribute is used when a scan model has more pins, such as extra set or resetlines, than the non-scan model to which it maps. This attribute specifies that the extrapin should be tied high after the scan is inserted.

• usageThe “usage” attribute describes the model usage when replacing non-scan cells withpartition scan cells. More than one scan cell can map to a non-scan cell, and duringpartition scan insertion, scan cell selection depends on whether DFTAdvisor identifiesthe non-scan cell as an input partition scan cell, an output partition scan cell, a hold-0partition scan cell, or a hold-1 partition scan cell.

• typeThe “type” attribute specifies the scan methodology. Mux_scan, clocked_scan, and lssdare the available options. Mux_scan should be used to specify mux-scan style,clocked_scan is used for the clocked-scan style, and lssd is used for LSSD-scan style. Ifthis line is missing from the attribute list, the type is defaulted to mux_scan.

To enable the scan replacement with the following attributes, use the DFTAdvisor command“Set Test Logic -clock on -set on -reset on.” See “Enabling Test Logic Insertion” in the Scanand ATPG Process Guide for more information.

• test_clockThe optional “test_clock” attribute describes a new test clock pin in the scan modelwhich doesn’t exist in the non-scan model. The test clock must be multiplexed with thefunctional clock.

• test_enableThe optional “test_enable” attribute defines a new test enable pin in the scan modelwhich doesn’t exist in the non-scan model. The test enable is used as a selector to chooseeither original clock, set and reset; or test clock, test set and test reset.



• test_setThe optional “test_set” attribute defines a new test set pin in the scan model whichdoesn’t exist in the non-scan model. The test set must be multiplexed with the originalset pin.

• test_resetThe optional “test_reset” attribute defines a new test reset pin in the scan model whichdoesn’t exist in the non-scan model. The test reset must be multiplexed with the originalreset pin.

• set_disabledThe optional “set_disabled” attribute specifies that the original set pin in the non-scanmodel is disabled by the test enable in the scan model. In order to use this attribute,test_enable must be defined.

• reset_disabledThe optional “reset_disabled” attribute specifies that the original reset pin in the non-scan model is disabled by the test enable in the scan model. In order to use this attribute,test_enable must be defined.



August 2006

Example Scan DefinitionsThe following subsections contain example scan definitions for various types of cells.

Basic ExampleThe following is a general example of the usage of several of the attributes:

model FD3SP(D, CP, TI, TE, CD, SD, Q, QN) ( scan_definition ( type = mux_scan; data_in = D; scan_in = TI; scan_enable = TE; scan_out = Q, QN; tie1 = SD; // SD is tied to a 1 after scan insertion non_scan_model = FD2P(D, CP, CD, Q, QN); )

<model or macro description> . . . )

Figure 4-1 shows the non-scan to scan cell replacement that is defined in the preceding scandefinition.

Figure 4-1. General Scan Definition Replacement Example

D

CLK

Q

FD2P

D

CLK

I0

I1 Z

FD3SP

Q

CD

QN QN

D

CP

TI

TE

Q

QN

CD

CD

D

CP

CD

Q

QN

SD

S



MUX-Scan CellThe following is an example definition for a MUX-Scan cell:

model FD1S(D, CP, SI, SE, Q, QN) ( scan_definition ( type = mux_scan; scan_in = SI; scan_enable = SE; scan_out = Q, QN; non_scan_model = FD1(D, CP, Q, QN); ) <model or macro description> . . . )

Figure 4-2 shows this non-scan to scan cell replacement defined above.

Figure 4-2. Mux-Scan Definition Replacement Example

Clocked-Scan CellThe following is an example definition for a Clocked-Scan cell:

model DP_SAFFD(D, CP, SI, SC, Q, QN) ( scan_definition ( type = clocked_scan; scan_in = SI; scan_clock = SC; scan_out = Q, QN; non_scan_model = SAFFD(D, CP, CD, Q, QN); ) <model or macro description> . . . )


D

CLK

Q

CLK

I0

I1

FD1S

Q

QN QN

D

CP

SI

SE

Q

QN

D

CP

Q

QN

FD1

S

DZ



August 2006

Figure 4-3. Clocked-Scan Definition Replacement Example

LSSD CellThe following is an example definition for a LSSD cell:

model LD1S2(D, CP, SI, MCLK, SCLK, SO, Q, QN) ( scan_definition ( type = lssd; scan_in = SI; scan_out = SO; scan_master_clock = MCLK; scan_slave_clock = SCLK; usage = input; non_scan_model = LD1(D, CP, Q, QN); ) <model or macro description> . . . )

In this example, the scan cell can also be used as an input partition scan cell.


Figure 4-4. LSSD Scan Definition Replacement Example

Double Latch Nonscan Model

The library compiler supports double latch, non-scan models using LSSD. This is useful inlibraries where double latch, non-scan models have corresponding scan models.

An example of a double latch nonscan model is shown below:

D

CLK

Q

QN

D

CP

Q

QN

SAFFD

CLK1

CLK2

DP_SAFFD

D2

D1

Q

QN

Q

QN

D

CP

SI

SC

LD1S2

D

CLK

Q

QN

D

CP

Q

QN

LD1

CLK1

CLK2

D2

D1

Q

QN

D

CLK

Q

D

SI

MCLK

SCLK

Q

QN

SO

CP



model latch2 (SCL, MCL, I1, O1) (input(SCL, MCL, I1) ()intern(int) (primitive = _dlat( , ,MCL, I1, int, );)output(O1) (primitive = _dlat( , ,SCL, int, O1, );)

)

A scan cell that maps to the above non-scan cell is described as follows:

model latch2s (I1, MCL, SI, SMCL, SCL, O1) (scan_definition (

type = lssd;scan_in = SI;scan_out = O1;scan_master_clock = SMCL;scan_slave_clock = SCL;non_scan_model = latch2(SCL, MCL, I1, O1);

)input(I1, MCL, SI, SMCL, SCL) ()output(O1) (function = IQ;)intern(__in_1) (primitive = _dlat(, ,MCL, I1, SMCL, SI, __in_1, ); )

intern(IQ) (primitive = _dlat(, , SCL, __in_1, IQ, ); ))

Complex Scan ModelThe following is an example of a non-scannable flip-flop due to uncontrollable set, reset, andclock pins. It can be made scannable by using “test_” attributes.

model FD4S(CLR, SET, CLK, D, SI, SE, TCLR, TSET, TCLK, TE, Q)(scan_definition (

type = mux_scan;scan_in = SI;scan_enable = SE;test_clock = TCLK;test_enable = TE;test_reset = TCLR;test_set = TSET;scan_out = Q;non_scan_model = FD4(CLR, SET, CLK, D, Q);)

<model or macro description> . . . )




August 2006

Figure 4-5. Complex Scan Definition Replacement Example

D

CLK

Q

RESET

D

CLK

CLR

Q

FD4

SET

SET

D

CLK

I0

I1Z

S

FD4S

Q

SET

Q

RESET

SET

I0

I1Z

S

I0

I1Z

S

I0

I1Z

S

TSET

TE

TE

TE

SE

D

SI

CLK

TCLK

CLR

TCLR

Design LibraryDefining a Model


Defining a ModelThe first step in creating a design library is to define a model. A model defines the name of asingle cell in the technology library. The library cell is defined with the model statement. Themodel statement requires two components: the model_name and the list_of_pins.

Model_nameThe model_name should be the cell name used in your design data. For example, the cell namecan be the name given by an ASIC vendor. The model_name field allows you to describe thecell name. The syntax is shown as follows:

model model_name (... ... )

List_of_pinsThe list_of_pins are interface pins on the cell boundary which include input, output, andbidirectional pins. The list_of_pins syntax appears as follows:

model model_name (list_of_pins) ( ... )

For example, the model name, BIBUF, for the bidirectional buffer and its interface pins IO, A,EN, TN, PI, ZI, and PO in the model statement as follows:

model BIBUF(IO, A, EN, TN, PI, ZI, PO) ( ...)

Figure 4-6. Bidirectional Buffer

Or, assign a model name SDFF to a scan D flip-flop and all its interface pins D,CLK,TI,TE,Qand QN in the model statement as follows:

model SDFF(D, CLK, TI, TE, Q, QN) ( ...... )

BIBUF

TN

EN

A

PI

IO

ZI

PO



August 2006

Interface Pins and Internal Nodes

Figure 4-7. Scan D Flip-Flop

The next step is to define interface pins as input, output and bidirectional pins. Furthermore,internal nodes can be used to define complex logical structures. An example of how these pinsare defined is as follows:

model model_name (list_of_pins) ( input (input_pins)... intern (intern_nodes)... inout (inout_pins)... output (output_pins)... )

Input StatementThe keyword input is used to define input pins. The input_pins in the input statement must bepins previously defined in the list_of_pins. Input pins are defined in the model as follows:

input (input_pins)...

Intern StatementThe keyword used to define internal nodes is intern. The internal nodes should not be specifiedin the list_of_pins field in the model statement. The intern_nodes field allows you to enter thenames of the internal nodes in the model.

intern (intern_nodes)...

Inout StatementWhen defining bidirectional pins, you should first predefine the bidirectional pin names in thelist_of_pins field. Bidirectional pins are defined using the keyword inout. The inout_pins in thestatement allows you to enter the names of the bidirectional pins in the model.

inout (inout_pins)...

Output StatementYou can designate pins, which have been predefined in the list_of_pins, as output pins by usingthe keyword output. The output_pins given in the statement allows you to enter the names ofthe output pins. Output pins are defined as follows:

SDFF

TI

TE

D

CLK

Q

QN



output (output_pins)...

Examples:

For BIBUF, assign A, PI, EN, and TN as input pins; IO as a bidirectional pin; ZI and PO asoutput pins; and the internal node ETN as follows:

model BIBUF(IO, A, EN, TN, PI, ZI, PO) ( input (A, PI, EN, TN)... intern (ETN)... inout (IO)... output (ZI)... output (PO)... )

For SDFF, define TI,TE, D, and CLK as input pins; XD, YD, and ND as internal nodes, and Qand QN as output pins as follows:

model SDFF(D, CLK, TI, TE, Q, QN) ( input (D, TI, TE)... input (CLK)... intern (YD)... intern (XD)... intern (ND)... output (Q,QN)... )

NoteThe legal characters that are allowed for user-defined names, such as model_names,input_pins, intern_nodes, inout_pins, output_pins, and so on are letters, numbers, and theunderscore character “_”. If any other character is used, the user-defined name must beenclosed in double quotes.

When an identifier contains special characters and needs to be escaped, the Verilog usage is“\a#”, and the VHDL usage is “\a#\”. In the ATPG library model, you should refer to thatidentifier without back slashes, but with enclosing double-quotes. For example, given this verysimple netlist “n.v”:

module test ( i1, o1);input i1;output o1;inv1b u1( .\a# (i1), .o (o1) );

endmodule

the ATPG library model should read:

model inv1b (“a#”, o) (input (“a#”) ()output (o) (primitive = _inv (“a#”, o:nf);)

)



August 2006

Cell TypeDFTAdvisor can add test logic to the design to make certain flip-flops scannable. The test logiccircuitry added consists of various existing library cells. To flag that a library cell can be used intest logic circuitry, you can use the cell_type attribute. The syntax for this attribute is as follows:

cell_type=<INV|BUF|AND|NAND|OR|NOR|XOR|INBUF|OUTBUF|CLKBUF MUX <sel d0 d1>|DFF <clk d>|DLAT <clk d> |SCANCELL <clk d>>;

For example, the following model description states that the AN2 component is a cell that canbe used as an AND gate within test logic circuitry:model AN2 (A, B, Z) (

cell_type = AND;input (A, B) ()output (Z) (function = A * B;)

)

The following example illustrates using the cell-type attribute to flag a scan cell component tobe used within test logic circuitry. Note that the clock and data ports are also specified alongwith the type of the cell (scancell).

model sff (D, SI, SE, CLK, Q, QB) (cell_type = SCANCELL CLK D;scan_definition (

type = mux_scan;data_in = D;scan_in = SI;scan_enable = SE;scan_out = Q, QB;non_scan_model = dff (D, CLK, Q, QB);

)input (D, SI, SE, CLK) ()intern(_D) (primitive = _mux (D, SI, SE, _D);)output(Q, QB) (primitive = _dff(, , CLK, _D, Q, QB);)

)

Instead of using the cell_type attribute in the library description, you can use the Add CellModels command within the tool session to specify the test logic models.

AttributesThe final step is to create internal connectivities in the model by assigning attributes to theinterface pins and internal nodes. The interface pins and internal nodes are connected toindividual elements such as combinational or sequential elements. You may use Booleanexpressions to create combinational elements, or primitive attributes to build sequentialelements. Additional attribute statements allow you to further define the internal structure of themodel precisely.

model model_name (list_of_pins) (



input (input_pins) (input attributes) intern (intern_nodes) (intern attributes) inout (inout_pins) (inout attributes) output (output_pins) (output attributes) )

Input AttributesThe input attributes are optional. The input attributes which can be defined are:

NoteIf no attribute is defined for pin groups, () must be entered after the pin field to indicatethe attribute field in the model.

• used Attribute Statement. The used attribute statement specifies whether to suppressthe warning message that states if the input pin or intern node is unused. If this attributeis not used, the default is true. If this attribute statement is not used, the default is true.The syntax is as follows:

used = <true | false>;

Here is an example of an unused pin, where the warning message will be suppressed:

model dummy(IN1, IN2, OUT) ( input (IN1) () input (IN2) (used = false;) output (OUT) (function = IN1;) )

• clock Attribute Statement. The clock attribute statement specifies that the input clockpin is connected to the rising edge clock (default) or the falling edge clock. The syntax isas follows:

clock = rise_edge;clock = fall_edge;

The clock attribute statement only applies to the clock pin of the D flip-flop and D latch.If the clock is from a generated signal and not from an input, an inverter can be usedwithout using the clock attribute statement.

• no-fault Attribute Statement for Model Pins. Each pin can have the characteristic ofstuck-at-1 and stuck-at-0 faults. This attribute allows you to exclude any stuck-at fault atspecified pins. The syntax is as follows:

no_fault = sa0 Specifies that no stuck-at-0 fault is considered atthe specified pin. Only stuck-at-1 will be considered.no_fault = sa1 Specifies that no stuck-at-1 fault is consideredat the specified pin. Only stuck-at-0 faults will be considered.no_fault = sa0 sa1 Specifies that no stuck-at-0 and stuck-at-1faults are considered at the specified pin.



August 2006

An example of the no-fault attribute statement is as follows:

model FD2(D, CP, CD, Q, QN) ( input (D) (no_fault = sa0;) input (CP) (clock = rise_edge;) input (CD) () ... )

Here is the same example, as above, using the no-fault attribute statement forinstance/primitive pins (This is described in “Intern Attributes” on page 196):

model FD2(D:nf0, CP, CD, Q, QN) ( input (D) () input (CP) (clock = rise_edge;) input (CD) () ... )

The examples describe the input signals as D, CP, and CD.

NoteIt is legal to separate the input statement per input pin. Only stuck-at-1 faults areconsidered at input pin D. The input pin CP is connected to a rising edge clock signal.The input pin CD is enabled when the input signal is low.

Intern AttributesAttribute statements that can be defined for internal nodes are:

• used Attribute Statement. Same as the input attribute.

• function Attribute Statement. The function attribute describes the function of internalnodes in terms of the model's input pins, output pins, bidirectional pins, and otherinternal nodes. You can define the function of internal nodes by using legal operators ina Boolean expression as follows:

function = boolean_expression;

Legal Boolean operators which can be used are:

! invert following expression * logical AND operation + logical OR operation

An example of the legal Boolean operators is as follows:

model BD4T(IO, A, EN, TN, PI, ZI, PO) ( input(A, PI, EN, TN) () output(ZI) (function = IO;) output(PO) (function = !(ZI * PI);) inout(IO) (primitive = _tsl(A, ETN, IO);) intern(ETN) (function = !(TN * !EN);)



)

In the above example, the internal node is ETN and the function of ETN is“!(TN*!EN)”. Furthermore, the function of the output ZI is defined with the functionattribute statement, “function = IO”. When the library model is compiled, acombinational buffer will be created.

• primitive Attribute Statement. The primitive attribute statement identifies elementssuch as latches and flip-flops, so that the system understands the functional behavior ofthe particular elements. The format and syntax for the primitive attribute statement is asfollows:

primitive = _primitive_name [instance_name] (<list_of_nets>);

The following is an example of the usage of a primitive attribute statement:

model BD4T(IO, A, EN, TN, PI, ZI, PO) ( input(A, PI, EN, TN) () output(ZI) (primitive = _buf(IO, ZI);) output(PO) (primitive = _nand(ZI, PI, PO);) inout(IO) (primitive = _tsl(A, ETN, IO);) intern(ETN) (function = !(TN * !EN);) )

The primitive attribute statement will place faults on the boundary pins of the primitiveif an instance name is given. The instance_name is a user-defined name and is optional.A primitive attribute statement cannot have an instance name, if there is a functionstatement described in the library model. Also, if there is more than one primitiveattribute statement in a library model, either instance names must be given for allprimitive attribute statements, or no instance names can be given. Here is an example ofthe primitive attribute statement with internal faulting:

model andnor1(A1, A2, B1, B2, ZN) ( input(A1, A2, B1, B2) () intern(N1) (primitive = _and an1(A1, A2, N1);) intern(N2) (primitive = _and an2(B1, B2, N2);) output(ZN) (primitive = _nor nr1(N1, N2, ZN);) )

The pin names for the internal faults on the primitive attribute statement will use theones described in the Supported Primitives section. Refer to “Supported Primitives” onpage 214 for all of the DFTAdvisor, FastScan, FlexTest, and TestKompress supportedprimitives.

• instance Attribute Statement. The instance attribute statement refers to anotherdefined library model. This attribute statement is very useful when internal faulting mustbe accomplished. The format and syntax for the instance attribute statement is asfollows:

instance = model_name [instance_name] (<list_of_nets>);



August 2006

The model_name refers to another model name defined in the library. The list_of_netsrefers to the boundary pins of the model_name. Here is an example using the instanceattribute statement:

model andnor2(A1, A2, A3, B1, B2, B3, ZN) ( input(A1, A2, A3, B1, B2, B3) () intern(N1) (instance = and3 (A1, A2, A3, N1);) intern(N2) (instance = and3 (B1, B2, B3, N2);) output(ZN) (instance = nor2 (N1, N2, ZN);) ) model and3(A1, A2, A3, Z) ( input(A1, A2, A3) () output(Z) (primitive = _and(A1, A2, A3, Z);) ) model nor2(A1, A2, ZN) ( input(A1, A2) () output(ZN) (primitive = _nor(A1, A2, ZN);) )

The instance_name is a user-defined name and is optional. If an instance name is given,the instance attribute statement will place faults beneath the instance, if the referencedmodel has internal faults. Faults will be placed on the instance boundary, if thereferenced model has no internal faults. This is the case if the model contains onlyfunction statements, or primitive or instance attribute statements with no instancenames. An instance attribute statement cannot have an instance name if there is afunction statement described in the library model. If there is more than one instanceattribute statement in a library model, either instance names must be given for allinstance attribute statements, or no instance names can be given. This also applies ifthere are primitive and instance attribute statements in the same library model. Here isan example of the instance attribute statement with internal faulting:

model andnor2(A1, A2, A3, B1, B2, B3, ZN) ( input(A1, A2, A3, B1, B2, B3) () intern(N1) (instance = and3 an1(A1, A2, A3, N1);) intern(N2) (instance = and3 an2(B1, B2, B3, N2);) output(ZN) (instance = nor2 nr1(N1, N2, ZN);) )

model and3(A1, A2, A3, Z) ( input(A1, A2, A3) () output(Z) (primitive = _and(A1, A2, A3, Z);) ) model nor2(A1, A2, ZN) ( input(A1, A2) () output(ZN) (primitive = _nor(A1, A2, ZN);) )

• fault Attribute Statement. The fault attribute statement precedes the instance orprimitive attribute statements, with instance names, which are to be faulted. The faultattribute statement allows the choice of faulting the instance boundary only, faulting theinstance internals only, faulting the instance internals and boundary, or nofaulting:



fault = <boundary | internal | boundary internal | none>;

If the fault attribute statement is not given, fault = internal is assumed for the instancesinstantiated from models that have internal faults. Fault=boundary is assumed for thoseinstances instantiated from models which have no internal faults. If the fault attributestatement is set to boundary, faults will be placed only on the boundary of the instanceor primitive specified by the instance or primitive attribute statement, regardless if thatname has internal faults. If the fault attribute statement is set to internal, faults will beplaced only on internal pins of the referenced library model that have internal faults. Ifthe fault attribute statement is set to boundary internal, faults will be placed on theboundary pins of the instances or primitives and be placed on any internal pins of thereferenced library model name that have internal faults. If the fault attribute statement isset to none, nofaults will be placed on the pins of the instances or primitives, regardlessif they have internal faults.

• no-fault Attribute Statement for Instance/Primitive pins. If the instance andprimitive attribute statements have instance names, they can be faulted or not faulted bythe fault attribute statement. Assume that somehow the instance and primitive attributestatements are faulted at the boundary, and the user wants to be able to not fault certaininstance pins or primitive pins.

For library instances, no-faults on pins can be controlled by its defining library model.The side effect is that no-fault on model pins will also affect other library instanceswhich are instantiated from the model, as in a hierarchical library description. Thesyntax is as follows:

node_name : <nf0 | nf1 | nf>

Here, node_name can be model pin names or internal node names which appear in theinstance or primitive attribute statements. The keywords nf0, nf1, and nf stand for no-fault at 0, no-fault at 1, and no-fault at 0 and 1, respectively.

Here is an example with the no-fault attribute statement within instance attributestatements:

model AO2(A, B, C, D, Z) ( input (A, B, C, D) () intern(AB) (fault=boundary instance=AN2 U1(A:nf0, B, AB);) intern(CD) (instance = AN2 U2(C, D:nf1, CD);) output(Z) (instance = NR2 U3(AB, CD, Z:nf);) )

Here is an example with the no-fault attribute statement on model pin names:

model AO2(A:nf, B, C, D, Z:nf1) ( input (A, B, C, D) () intern(AB) (fault = boundary; instance = AN2 U1(A, B, AB);) intern(CD) (instance = AN2 U2(C, D, CD);) output(Z) (instance = NR2 U3(AB, CD, Z);) )



August 2006

• set_clock_conflict Attribute Statement. For sequential primitive D flip-flops, whichcontain a single set pin, the values of Q and Qbar become unknown if the input data is 0when both the set and clock pins are active at the same time. This attribute statementallows users to force the values of Q and Qbar to 1 and 0 respectively, when the situationof unknown values occur. To accomplish this, the following attribute statement isprovided:

set_clock_conflict = q_qbar_value;The possible values of q_qbar_value are XX, and 10 (set-dominated clock). In FastScanand TestKompress, XX is used. In FlexTest, if this attribute is not used, the default valueis 10.

The set_clock_conflict statement should be placed before the sequential primitivestatement, and can only affect single data-clock port sequential primitives. Also, foreach sequential primitive, there can only be one conflict attribute given. This attributehas no effect in DFTAdvisor, FastScan, or TestKompress.

NoteThe set_clock_conflict and the reset_clock_conflict attributes are no longer applicable toD latches.

• reset_clock_conflict Attribute Statement. For sequential primitive D flip-flop, whichcontain a single reset pin, the values of Q and Qbar become unknown if the input data is1 when both the reset and clock pins are active at the same time. This attribute statementallows users to force the values of Q and Qbar to 0 and 1 respectively, when the situationof unknown values occur. To accomplish this, the following attribute statement isprovided:

reset_clock_conflict = q_qbar_value;

The possible values of q_qbar_value are XX, and 01 (reset-dominated clock). InFastScan and TestKompress, XX is used. In FlexTest, if this attribute is not used, thedefault value is 01.

The reset_clock_conflict statement should be placed before the sequential primitivestatement, and can only affect single data-clock port sequential primitives. Also, foreach sequential primitive, there can only be one conflict attribute given. This attributehas no effect in DFTAdvisor, FastScan, or TestKompress.



Example:

model FD2S(D, CP, CD, TI, TE, Q, QN) (input(D, TI, TE) ()intern(ND) (function = D * !TE + TI * TE;)input(CP) (clock = rise_edge;)input(CD) ()output(Q,QN) (

reset_clock_conflict = 01;primitive = _dff(, CD, CP, ND, Q, QN);

))

Inout and Output AttributesAttribute statements that can be defined for bidirectional and output pins are:

• function Attribute Statement. Same as the intern attribute.

• primitive Attribute Statement. Same as the intern attribute.

• instance Attribute Statement. Same as the intern attribute.

• fault Attribute Statement. Same as the intern attribute.

• no-fault Attribute Statement for Instance/Primitive Pins. Same as the internattribute.

• set_clock_conflict Attribute Statement. Same as the intern attribute.

• reset_clock_conflict Attribute Statement. Same as the intern attribute.

• bus_keeper Attribute Statement. This attribute models the ability of a bus to retain itsprevious binary state when it is not driven. The format of this attribute statement is:

bus_keeper = <zhold | zhold0 | zhold1>;

where zhold retains the previous binary state, zhold0 retains only a preceding 0 state,and zhold1 retains only a preceding 1 state. If the input value of the bus is not Z, then theoutput value is the same as the input value.

If the input value is Z, the following occurs: If the previous value is retained, the outputvalue is set to the previous value; if the previous value is not retained, the output is set toZ; and if the previous value is X, the output value is set to X.

If multiple bus_keeper attributes are used on a net, their effect is additive. If a non-tristate net is assigned a bus_keeper attribute, a warning message is issued. Forinformation on bus keeper analysis during rules checking, refer to “Bus KeeperAnalysis” in the Scan and ATPG Process Guide.

This attribute can be used in situations such as that shown in Figure 4-8:



August 2006

Figure 4-8. Design Example with Bus Keeper

When you use the bus_keeper attribute, during design flattening a ZHOLD gate is usedto model the bus keeper behavior, as shown in Figure 4-9:

Figure 4-9. Simulation Model with ZHOLD Bus Keeper

The following example shows the usage of the bus_keeper attribute statement within amodel definition:

model TSHZH(A,B,X)( input(A,B) () output(X) ( bus_keeper=zhold0; primitive=_tsh(A,B,X); ))

This cell is a tri-state buffer with active high control, whose output, X, can retain aprevious binary 0 state when undriven.

Primitive and Attribute ExamplesFigure 4-10 illustrates the inout and output attribute assignments with the bidirectional buffer,BIBUF and the scan D flip-flop, SDFF. The bidirectional buffer attribute assignment is asfollows:

model BIBUF(IO, A, EN, TN, PI, ZI, PO) (

TIEZbus_keeper

Tri-StateDevice

Tri-StateDevice

Bus KeeperDevice

Bus ZHOLD

Tri-StateDevice

Tri-StateDevice



input(A, PI, EN, TN) (no_fault = sa0;) intern(ETN) (function = !(TN * !EN);) inout(IO) (primitive = _tsl(A, ETN, IO);) output(ZI) (primitive = _buf(IO, ZI);) output(PO) (primitive = _nand(ZI, PI, PO);) )

Figure 4-10. Combinational Logic

First, you examine the internal structure of the model and identify two 2-input NAND gates, onetri-state buffer, and one non-inverting buffer. Based on the structures of individual elements,assign attributes as follows:

• For all input pins, exclude the stuck-at-0 fault at all input pins with a nofault attributestatement. In other words, only the stuck-at-1 fault is considered at the input pins duringfault simulation and test pattern generation processes.

• An internal node ETN can be created by a function attribute statement “!(TN * !EN)” forthe two-input NAND gate.

Figure 4-11. Creating an Internal Node

• For the tri-state buffer with input and active low pins, you can use a primitive attributestatement “_tsl(A,ETN,IO)” (tsl = tri-state low), to create the bidirectional pin IO. Notethat the internal node ETN is treated as the enable pin for the tri-state buffer.

Figure 4-12. Tri-State Buffer

TNEN

A

PI

IO

ZI

PO

ETN

TNEN

ETN

intern(ETN) (function =!(TN * !EN);)

A IO

ETN

inout(IO) (primitive = _tsl(A, ETN, IO);)



August 2006

• For the non-inverting buffer with an input pin IO, simply use the primitive attributestatement “primitive = _buf(IO, ZI)” to generate the output pin ZI. In this example, withthe function attribute statement, it cannot propagate a Z state to ZI. Therefore, ZI will bean X state, if IO is a Z state.

Figure 4-13. Non-Inverting Buffer

If a Z state is required at ZI, the _bufz primitive should be used instead of the _bufprimitive.

• For the two-input NAND gate, use the primitive attribute statement “primitive =_nand(ZI, PI, PO)” to generate the output pin PO.

Figure 4-14. Two-input NAND Gate

The scan D flip-flop attribute assignment is as follows:

model SDFF(D, CLK, TI, TE, Q, QN) ( input(D, TI, TE) () input(CLK) (clock = rise_edge;) intern(ND) (primitive = _mux(D, TI, TE, ND);) output(Q,QN) (primitive = _dff(, , CLK, ND, Q, QN);) )

Figure 4-15. Mux-DFF Scan Cell

Based on the internal structure of SDFF, you will have to create one multiplexer and one D flip-flop as follows:

IO ZI

output(ZI) (primitive = _buf(IO, ZI);)

PI POZI

output(PO) (primitive = _nand(ZI, PI, PO);)

MUX

D

TI

DFF

ND

Q

QN

TE

CLK



• Requires no input attribute for input pin D, TI, and TE. The edge-triggered clock signalCLK can be specified with a clock attribute statement “clock = rise_edge.”

• Use the primitive statement “_mux(D, TI, TE, ND)” to describe the multiplexer. Syntax:primitive =_mux(I0, I1, CNT, OUT).

Figure 4-16. The MUX

• Use the primitive statement “_dff(, , CLK, ND, Q, QN)” to describe the D flip-flop.Syntax: primitive =_dff(SET, RESET, CLK, DATA, Q, QN). SET and RESET pins arenot required in this example.

Figure 4-17. The DFF

NoteThere is a clarification for the usage of a single input _wire primitive, _bufz primitive,and the _buf primitive attribute statement. The following example, which is a tri-stategate feeding two primary output pins, will be used to explain the differences whendifferent attribute statements are chosen for describing cell function.

• Here is an example using the function statement:

model TS(A, EN, Z1, Z2) (input(A, E) ()output(Z1) (primitive = _tsh(A, EN, Z1);)output(Z2) (primitive = _buf(Z1, Z2);))

MUX

D

TI

ND

TE

primitive = _mux(D, TI, TE, ND);)

DFFQ

QNCLK

ND

primitive = _dff(, , CLK, ND, Q, QN);)



August 2006

Figure 4-18. Tri-State Gate (_buf primitive)

When this model is compiled, a combinational buffer will be created between output pinZ1 and output pin Z2. The effect of modeling this way will stop a Z state of output pinZ1 from propagating to output pin Z2. If there is an external pull up/down gateconnected to output pin Z2, the effect of the pull up/down will not show up at output pinZ1.

• Here is an example using the _bufz primitive:

model TS(A, EN, Z1, Z2) (input(A, E) ()output(Z1) (primitive = _tsh(A, EN, Z1);)output(Z2) (primitive = _bufz(Z1, Z2);))

Figure 4-19. Tri-State Gate (_bufz primitive)

When this model is compiled, a Z transferable buffer will be created for output pin Z2,and a Z state of output pin Z1 will always show up at output pin Z2. However, if there isan external pull up/down gate connected to output pin Z2, the effect of the pull up/downwill not show up output pin Z1.

• Finally, here is an example using the _wire primitive:

model TS(A, EN, Z1, Z2) (input(A, E) ()output(Z1) (primitive = _tsh(A, EN, Z1);)output(Z2) (primitive = _wire(Z1, Z2);))

Z1

EN

A

Z2

PULL-UPOPTION

Z1

EN

A

Z2

PULL-UP

OPTION



Figure 4-20. Tri-State Gate (_wire primitive)

When this model is compiled, buses will be created for output pin Z1 and output pin Z2,respectively. If there is an external pull up/down gate connected to output pin Z2, theeffect of the pull up/down will show up at output pin Z1.

Internal FaultsBy default, faults are placed on all interfaced pins of a cell model. Any of these interfaced pinscan be selected not to be faulted. If the cell model is complex and the user wants to fault some ofthe pins inside the cell, this can be accomplished with primitive and instance attributestatements.

There are three attribute statements to describe the connectivity of the cell models: function,primitive, and instance. Since, there is no instance name and pin name associated with thefunction attribute statement, there is no way to place faults on the function. The primitive andinstance attribute statements allow instance names in order to handle faulting internal pins.Also, the fault and no-fault attribute statements describe how to handle faulting or not faultinginternal pins.

Figure 4-21 is an example using internal faults:

Z1

EN

A

Z2

PULL-UP

OPTION



August 2006

Figure 4-21. Internal Faults

In this example, a net-list will model an adder and will contain one instance, U1, which refers tothe library name “adder”. The primary inputs are A, B, and CI. The primary outputs are S andCO. The library model description for the adder will be described with internal faulting asfollows:

model adder(CI, A, B, S, CO) (

input(A, B, CI) () intern(N4) (fault=internal;instance=xor2 xr1(A, B, N4);) output(S) (fault=boundary internal;instance=xor2 xr2(N4, CI, S);) intern(N1) (fault=internal;instance=and2 an1(A, B, N1);) intern(N2) (fault=internal;instance=or2 o1(A, B, N2);) intern(N3) (fault=boundary;primitive= _and an2(N2, CI, N3);) output(CO) (fault=boundary;instance=or2 o2(N1, N3, CO);) ) model xor2(A1, A2, Z) ( input(A1, A2) () intern(N1) (fault=none;instance= buff1 buf1(A1, N1);) intern(N2) (fault=boundary;primitive= _buf buf2(A2, N2);) output(Z) (primitive=_xor xr3(N1:nf, N2, Z);) )

model and2(A1, A2:nf0, Z) ( input(A1, A2) () output(Z) (fault = none; primitive = _and an3(A1, A2, Z);) ) model or2(A1, A2, Z) ( input(A1, A2) () intern(N1) (fault=internal;instance=buff1 buf3(A1, N1);) output(Z) (fault=boundary;primitive=_or o3(N1, A2, Z:nf1);) ) model buff1(I, Z) ( input(I) () output(Z) (fault = boundary; primitive = _buf buf4(I, Z);) )

A1

A2

buf1

buf2 xr3Z

xr1

A1

A2

buf3

o3Z

o1

an1N1

an2N2

N4 A1

A2

buf1

buf2 xr3Z

A2

A1 buf3

N3

Z

o2

xr2A

BCI

S

CO



When all faults are added to this example, using the Add Faults command, these faults areplaced as follows:

1. Stuck-at-0 and stuck-at-1 faults are placed on the primary inputs and primary outputs:

/A /B /CI /S /CO

2. For the first intern statement (N4) of the library model adder, faults are placed on theinternals of instance xr1. This instance name refers to the library model xor2. Withinlibrary model xor2, nofaults are placed on the instance name buf1. Stuck-at-0 and stuck-at-1 faults are placed on the boundary of the buffer primitive with instance name buf2.For the buffer primitive, IN is the input pin name, and OUT is the output pin name:

/U1/xr1/buf2/IN /U1/xr1/buf2/OUT

Since the output statement of library model xor2 has an instance name xr3, but hasnofault attribute statement, then by default, the fault attribute is set to boundary. For theXOR primitive, IN0 and IN1 are the input pin names, OUT is the output pin name.

However, a no-fault attribute statement is placed on the first pin of the XOR primitive(IN0). So, stuck-at-0 and stuck-at-1 faults are only placed on the IN1 and OUT pins ofthe XOR primitive:

/U1/xr1/xr3/IN1 /U1/xr1/xr3/OUT

3. For the first output statement (S) of the library model adder, faults are placed on theboundary and the internals of instance xr2. This instance name refers to the internals andboundary of library model xor2. Stuck-at-0 and stuck-at-1 faults are placed on theboundary of library model xor2:

/U1/xr2/A1 /U1/xr2/A2 /U1/xr2/Z

Within library model xor2, nofaults are placed on the instance name buf1. Faults areplaced on the boundary of the buffer primitive with instance name buf2. For the bufferprimitive, IN is the input pin name, and OUT is the output pin name:

/U1/xr2/buf2/IN /U1/xr2/buf2/OUT

Since the output statement of library model xor2 has an instance name xr3, but hasnofault attribute statement, then by default, the fault attribute is set to boundary. For theXOR primitive, IN0 and IN1 are the input pin names, OUT is the output pin name.However, a no-fault attribute is placed on the first pin of the XOR primitive (IN0). So,



August 2006

stuck-at-0 and stuck-at-1 faults are only placed on the IN1 and OUT pins of the XORprimitive:

/U1/xr2/xr3/IN1 /U1/xr2/xr3/OUT

4. For the second intern statement (N1), faults are placed on the internals of instance an1.The instance name refers to the library model and2. However, since the library modelcontains an AND primitive and a fault attribute statement set to none, nofaults areplaced for the second intern statement.

5. For the third intern statement (N2), faults are placed on the internals of instance o1. Thisinstance name refers to the library model or2. Within library model or2, the first internstatement places faults on the internals of instance buf3. This instance name refers to thelibrary model buff1. Within library model buff1, stuck-at-0 and stuck-at-1 faults areplaced on the boundary of the buffer primitive with the instance name buf4. For thebuffer primitive, IN is the input pin name, and OUT is the output pin name:

/U1/o1/buf3/buf4/IN /U1/o1/buf3/buf4/OUT

For the output statement of library model or2, faults are placed on the boundary of theOR primitive with instance name o3. For the OR primitive, IN0 and IN1 are the inputpin names, OUT is the output pin name. However, a stuck-at-1 no-fault attributestatement is placed on the output pin of the OR primitive (OUT). So, only a stuck-at-0fault is placed on the OUT pin of the OR primitive:

/U1/o1/o3/IN0 /U1/o1/o3/IN1 /U1/o1/o3/OUT (stuck-at-0 fault only)

6. For the fourth intern statement (N3), faults are placed on the boundary of the ANDprimitive with instance name an2. For the AND primitive, IN0 and IN1 are the input pinnames, OUT is the output pin name:

/U1/an2/IN0 /U1/an2/IN1 /U1/an2/OUT

7. Finally, for the second output statement (CO), faults are placed only on the boundary ofinstance o2. Though instance o2 refers to library model or2 and has internal faults,nofaults are placed within the library model. The boundary pins for library model or2are A1, A2, and Z:

/U1/o2/A1 /U1/o2/A2 /U1/o2/Z

Design LibraryDefining Macros


Support of Arrays Within Library ModelsTo support arrays in library models, an array attribute statement can be used in the input, output,inout, and intern statements. The syntax is as follows:

array = start : end;

Array is the keyword; start and end are integers greater than or equal to 0. If start is greater thanend, the array is in descending order; otherwise, the array is in ascending order. This attributestatement can be used in input, output, inout, and intern statements. Arrays should be declaredbefore they are referenced in the primitive, instance, or function statements. The symbols ‘<’and ‘>’ are reserved for the array delimiters. If the user wants to redefine the array delimiterafter the library models are parsed, the array_delimiter statement can be used. The syntax is asfollows:

array_delimiter = "<>" | "()" | "{}" | "[]";

Array_delimiter is the keyword, and this statement is only defined once and must be used beforeany library models with the array attribute statement are defined. If this statement is not definedin the library, “<>” will be assumed.

Here is an example using the array attribute statement and array_delimiter statement:

array_delimiter = "[]"; model RAM1(W1, A1, D1, R2, A2, D2) ( input(W1, R2) () input(A1, A2) (array = 4 : 0;) input(D1) (array = 0 : 4;) output(D2) ( array = 0 : 4; data_size = 5; address_size = 5; read_off = 0; min_address = 0; max_address = 31; primitive = _ram U1 (, , _write(W1, A1, D1), _read(R2, A2, D2) ); ) )

Defining MacrosDesign libraries for the DFT products support macro descriptions. The syntax for a macrodescription, which is similar to a model description, is as follows:

macro macro_name (list_of_pins)( input (input_pins) ... output(output_pins) ... inout (inout_pins) ... intern (internal_nodes) ... )

Macro descriptions support nearly all the statements that model descriptions support, with thefollowing restrictions:


Design LibraryUsing Model Aliases

August 2006

• Macros can be referenced by other macros, but not other models.

• Function attribute statements are not allowed.

• Primitive attribute statements are not allowed.

• Instance names are required.

If macros are used to describe scan cell models, DFTAdvisor expands the macro into moduleswhen writing Genie format output. When writing any other format, DFTAdvisor writes out themacro as a separate module.

Using Model AliasesMany times a library will include several components with the same function but differenttiming characteristics. The DFT library needs only the functional information for a cell, not thetiming. Therefore, to simplify model creation for cells with the same logic functions, you canuse the alias statement within the library file. The syntax of the statement is as follows:

alias string defined_model_name

The string argument specifies a cell name that is functionally equivalent defined_model_name,which is a model that is fully described elsewhere in the library.

NoteThe alias keyword must be lowercase, and must not appear inside a model description.

An example using the alias statement follows. Note that the TBUF model is fully described,while a functionally equivalent model, TBUFH, is aliased to it.

// =========================// fastscan model: tbuf// =========================model TBUF (X, A, ENB) ( input(A, ENB) () output(X) ( primitive = _tsl a (A,ENB, X); ))// =========================// fastscan model: tbufh// =========================alias TBUFH TBUF

Reading Multiple LibrariesIn the custom design environment, all design cells may not be created and maintained by asingle user or group. To avoid having to maintain one complete library (which may be created

Design LibraryVerilog Primitives


by concatenating all subsets of the libraries) and many subsets of libraries consistently, you canspecify reading multiple libraries within one main library, by adding the following statement tothe library:

#include "library_filename"

There should be no space between “#” and “include”, and the library filename should beenclosed in double quotes. This statement can only be placed between model descriptions andcannot be placed inside a model description.

Here is an example using the “#include” statement to read multiple libraries:

#include "/home/users/library/set1.lib"#include "/home/users/library/set2.lib"model an2(A1, A2, X) ( input(A1, A2) () output(X) (function = A1 * A2;))...

Verilog PrimitivesFastScan, FlexTest, TestKompress, and DFTAdvisor understand Verilog primitives, withoutrequiring an ATPG model to be created. For example, the Verilog “and” directly maps to thebuilt-in primitive “and” in DFT tools, and therefore no model is needed. Even if an ATPGlibrary model named “and” is present, it will be ignored by the tool, since the Verilog readerwill recognize this model as a primitive which the tool already understands.

A list follows of the Verilog primitives which the DFT tools handle directly without requiringan ATPG library model:

NoteUDPs can be parsed and synthesized by the DFT tools, however it is recommended thatLibComp be used to create ATPG library models from UDP tables.

Table 4-1. Supported Verilog Primitives

and nand notif1 rcmos1 xnor

buf nmos1 or rnmos1 xor

bufif0 nor pmos1 rpmos1

bufif1 not pulldown rtran

cmos1

1. The tool uses a built-in unidirectional ATPG model for this primitive; thus, theATPG behavior is not the same as the Verilog primitive. Take care that the built-in model is suitable for your purposes.

notif0 pullup tran


Design LibrarySupported Primitives

August 2006

Supported PrimitivesThe following pages contain descriptions, truth tables, and examples of the primitives supportedby DFTAdvisor, FastScan, FlexTest, and TestKompress. When defining a primitive, you mustunderstand the pin sequence of the primitive. The sequence of the pin names is important to theprimitive definition. A comma must be used as a separator to keep the fixed pin sequenceformat for any unused pin in the primitive.

The library supports regular and resistive primitives. The drive strength of the outputs forregular and resistive primitives are different. The possible output drive strengths of a regularprimitive are: 0, 1, X (unknown), and Z (high impedance). The possible output drive strengthsof a resistive primitive are: weak 0, weak 1, weak X (unknown), and Z (high impedance). Forthe truth tables in the primitive section, “?” represents “don't care” and “X” represents“unknown” logic values. A “^” character indicates a rising edge, while a “-” character indicatesa non-rising edge.

NoteUse transistor primitives only under carefully controlled conditions. Building modelsfrom transistors to match the simulation or actual gate representation does not guaranteethe models will be testable in ATPG. The best practice is to use the tool’s highest levelbuilt-in gate primitives.



AND GateThe primitive used to model an AND gate is _and. The syntax of the primitive attributestatement is as follows:

primitive = _and (IN0, IN1, ..., INn, OUT)

Example:

model AND3(I1, I2, I3, O) ( input(I1, I2, I3) () output(O) (primitive = _and(I1, I2, I3, O);) )

Figure 4-22. AND Gate

Table 4-2. AND Truth Table

IN0 IN1 OUT

0 0 0

0 1 0

1 0 0

1 1 1

X/Z 0 0

X/Z 1/X/Z X

0 X/Z 0

1/X/Z X/Z X

I1I2I3

O



August 2006

NAND GateThe primitive used to model a NAND gate is _nand. The syntax of the primitive attributestatement is as follows:

primitive = _nand (IN0, IN1, ..., INn, OUT)

Example:

model NAND3(I1, I2, I3, O) ( input(I1, I2, I3) () output(O) (primitive = _nand(I1, I2, I3, O);) )

Figure 4-23. NAND Gate

OR GateThe primitive used to model an OR gate is _or. The syntax of the primitive attribute statement isas follows:

primitive = _or (IN0, IN1, ..., INn, OUT)

Table 4-3. NAND Truth Table

IN0 IN1 OUT

0 0 1

0 1 1

1 0 1

1 1 0

X/Z 0 1

X/Z 1/X/Z X

0 X/Z 1

1/X/Z X/Z X

Table 4-4. OR Truth Table

IN0 IN1 OUT

0 0 0

0 1 1

I1I2I3

O



Example:

model OR3(I1, I2, I3, O) ( input(I1, I2, I3) () output(O) (primitive = _or(I1, I2, I3, O);) )

Figure 4-24. OR Gate

1 0 1

1 1 1

X/Z 1 1

X/Z 0/X/Z X

1 X/Z 1

0/X/Z X/Z X

Table 4-4. OR Truth Table

IN0 IN1 OUT

I1I2I3

O



August 2006

NOR GateThe primitive used to model a NOR gate is _nor. The syntax of the primitive attribute statementis as follows:

primitive = _nor (IN0, IN1, ..., INn, OUT)

Example:

model NOR3(I1, I2, I3, O) ( input(I1, I2, I3) () output(O) (primitive = _nor(I1, I2, I3, O);) )

Figure 4-25. NOR Gate

Table 4-5. NOR Truth Table

IN0 IN1 OUT

0 0 1

0 1 0

1 0 0

1 1 0

X/Z 1 0

X/Z 0/X/Z X

1 X/Z 0

0/X/Z X/Z X

I1I2I3

O



InverterThe primitive used to model an inverter is _inv. The syntax of the primitive attribute statementis as follows:

primitive = _inv (IN, OUT)

Example:

model INV1(I, O) ( input(I) () output(O) (primitive = _inv(I, O);) )

Figure 4-26. Inverter

Table 4-6. Inverter Truth Table

IN OUT

0 1

1 0

X/Z X

I O



August 2006

BufferThe primitive used to model a buffer is _buf. The syntax of the primitive attribute statement isas follows:

primitive = _buf (IN, OUT)

Example:

model BUF1(I, O) ( input(I) () output(O) (primitive = _buf(I, O);) )

Figure 4-27. Buffer

Table 4-7. Buffer Truth Table

IN OUT

0 0

1 1

X/Z X

I O



Buffer With High Impedance OutputThe primitive used to model a buffer, which is capable of transmitting a Z value to the output, is_bufz. The syntax of the primitive attribute statement is as follows:

primitive = _bufz (IN, OUT)

Example:

model BIBUF(IO, A, EN, TN, PI, ZI, PO) ( input(A, PI, EN, TN) (no_fault = sa0;) intern(ETN) (function = !(TN * !EN);) inout(IO) (primitive = _tsl(A, ETN, IO);) output(ZI) (primitive = _bufz(IO, ZI);) output(PO) (function = !(ZI * PI);) )

Figure 4-28. Buffer with High-Impedance Output

In this example, if IO is a Z state, it will propagate to ZI. If the function attribute statement wasused instead of this primitive and IO was an Z state, ZI will be an X state.

XOR GateThe primitive used to model a XOR is _xor. The syntax of the primitive attribute statement is asfollows:

Table 4-8. BUFZ Truth Table

IN OUT

0 0

1 1

Z Z

X X

TN

EN

A

PI PO

ZI

IO

ETN



August 2006

primitive = _xor (IN0, IN1, ..., INn, OUT)

Example:

model XOR1(A, B, Z) ( input(A, B) () output(Z) (primitive = _xor(A, B, Z);)

Figure 4-29. XOR Gate

Table 4-9. XOR Truth Table

IN0 IN1 OUT

0 0 0

0 1 1

1 0 1

1 1 0

X/Z ? X

? X/Z X

A

BZ



XNOR GateThe primitive used to model a XNOR is _xnor. The syntax of the primitive attribute statementis as follows:

primitive = _xnor (IN0, IN1, ..., INn, OUT)

Using this primitive is more efficient than using functions.

Example:

model XNOR1(A, B, Z) ( input(A, B) () output(Z) (primitive = _xnor(A, B, Z);) )

Figure 4-30. XNOR Gate

Table 4-10. XNOR Truth Table

IN0 IN1 OUT

0 0 1

0 1 0

1 0 0

1 1 1

X/Z ? X

? X/Z X

A

BZ



August 2006

Tri-State Buffer with Active Low ControlThe primitive used to model a tri-state buffer with an active low control is _tsl, and the syntaxof the primitive attribute statement is as follows:

primitive = _tsl (IN, CNT, OUT)

Example:

model TSL1(DATA, CNT, OUT) ( input(DATA, CNT) () output(OUT) (primitive = _tsl(DATA, CNT, OUT);) )

Figure 4-31. Tri-State Buffer with Active Low Control

Table 4-11. TSL Truth Table

IN CNT OUT

0 0 0

1 0 1

Z 0 X

? 1 Z

? X X

CNT

DATA OUT



Inverted Tri-State Buffer with Active Low ControlThe primitive used to model an inverted tri-state buffer with an active low control is _tsli. Thesyntax of the primitive attribute statement is as follows:

primitive = _tsli (IN, CNT, OUT)

Example:

model TSLI1(DATA, CNT, OUT) ( input(DATA, CNT) () output(OUT) (primitive = _tsli(DATA, CNT, OUT);) )

Figure 4-32. Inverted Tri-State Buffer with Active Low Control

Table 4-12. TSLI Truth Table

IN CNT OUT

0 0 1

1 0 0

Z 0 X

? 1 Z

? X X

CNT

DATA OUT



August 2006

Tri-State Buffer with Active High ControlThe primitive used to model a tri-state buffer with a active high control is _tsh, and the syntaxof the primitive attribute statement is as follows:

primitive = _tsh (IN, CNT, OUT)

Example:

model TSH1(I, EN, TN, O) ( input(I, EN, TN) () intern(X) (function = TN * EN;) output(O) (primitive = _tsh(I, X, O);) )

Figure 4-33. Tri-State Buffer with Active High Control

Table 4-13. TSH Truth Table

IN CNT OUT

0 1 0

1 1 1

Z 1 X

? 0 Z

? X X

I O

TN

EN

X



Inverted Tri-State Buffer with Active High ControlThe primitive used to model an inverted tri-state buffer with an active high control is _tshi, andthe syntax of the primitive attribute statement is as follows:

primitive = _tshi (IN, CNT, OUT)

Example:

model TSHI1(DATA, CNT, OUT) (

input(DATA, CNT) () output(OUT) (primitive = _tshi(DATA, CNT, OUT);) )

Figure 4-34. Inverted Tri-State Buffer with Active High Control

Table 4-14. TSHI Truth Table

IN CNT OUT

0 1 1

1 1 0

Z 1 X

? 0 Z

? X X

CNT

DATA OUT



August 2006

MultiplexerThe primitive used to model a two-to-one multiplexer is _mux, and the syntax of the primitiveattribute statement is:

primitive = _mux (IN0, IN1, CNT, OUT)

The output signal will be the same as input signal “IN0” when control signal CNT is low. Theoutput signal will be the same as input signal “IN1” when the control signal CNT is high. Usingthis primitive is more efficient than using functions.

Example:

model MUX1(A, B, C, O) ( input(A, B, C) () output(O) (primitive = _mux(A, B, C, O);) )

Figure 4-35. Multiplexer

D Flip-FlopThe keyword used to define a single or multiple port D flip-flop is _dff. The syntax of theprimitive attribute statement is as follows:

primitive = _dff (SET, RESET, CLK1, D1, CLK2, D2, ..., CLKn, Dn, Q, QN)

Table 4-15. MUX Truth Table

IN0 IN1 CNT OUT

0 ? 0 0

1 ? 0 1

? 0 1 0

? 1 1 1

1 1 X 1

0 0 X 0

0 1 X X

1 0 X X

CNT

IN0

IN1 OUTA

B O

C



This primitive allows users to define a D flip-flop with a single pair or multiple pairs of clockand data inputs. If this primitive is used to model a single port D flip-flop, the behavior inFlexTest may be modified by the attributes, reset_clock_conflict and set_clock_conflict, whichare defined in “Attributes” on page 194. FastScan, TestKompress, and DFTAdvisor are notaffected by these attributes. The default behavior of a single port D flip-flop is different forFlexTest, FastScan, and TestKompress and is shown in the following primitive tables:

NoteIn the next two tables, “^”, “-” and “?” are defined as follows:

^ 0-to-1 (01) rising edge, but not (0X) or (X1)

- 1-to-0 (10), (1X) or (X0) non-rising edge, but not (0X) or (X1)

? A constant, either 0, 1 or X

Table 4-16. D Flip-Flop Primitive Table for FlexTest

D1 CLK1 SET RESET Q QN

0 ^ 0 ? 0 1

1 ^ ? 0 1 0

X ^ 0 0 X X

? - 0 0 Q QN

? - 0 1 0 1

? ? 0 1 0 1

? - 1 0 1 0

? ? 1 0 1 0

? ? 1 1 X X

Table 4-17. D Flip-Flop Primitive Table for FastScan and TestKompress


0 ^ 0 ? 0 1

1 ^ ? 0 1 0

X ^ 0 0 X X

? - 0 0 Q QN



August 2006

If the primitive is used to model a multiple port D flip-flop, the behavior is not affected by theattributes set_clock_conflict and reset_clock_conflict. The default behavior for FlexTest,FastScan, and TestKompress of a multiple port D flip-flop is as follows:

1. If only one set, reset, or one of the clocks is active, Q and QN are well defined.

2. If more than one set, reset, or clock lines is active and if the values captured by the activeclocks, set, or reset are the same, Q and QN are well defined. Otherwise, Q and QN areunknown.

Example:

model DFF1(D, CLK, R, Q, QN) ( input(D) () input(CLK) (clock = rise_edge;) input(R) () output(Q, QN) (primitive = _dff(, R, CLK, D, Q, QN);) )

Figure 4-36. D Flip-Flop

In this example, the D flip-flop does not have a set pin; therefore, it is required to have a commaas the separator after the set pin field.

1 ^ 0 1 X X

? - 0 1 0 1

? ? 0 1 0 1

0 ^ 1 0 X X

? - 1 0 1 0

? ? 1 0 1 0

? ? 1 1 X X

Table 4-17. D Flip-Flop Primitive Table for FastScan and TestKompress


R

D

CLK

Q

QN



D LatchThe keyword used to define a single or multiple port D latch is _dlat. The syntax of theprimitive attribute statement is as follows:

primitive = _dlat (SET, RESET, CLK1, D1, CLK2, D2, ..., CLKn, Dn, Q, QN)

This primitive allows users to define a D latch with a single pair or multiple pairs of clock anddata inputs. The default behavior of a single port D latch is the same for FlexTest, FastScan, andTestKompress and is shown in the primitive table (Table 4-18).

The default behavior for FlexTest, FastScan, and TestKompress of a multiple port D latch is asfollows:

1. If only one set, reset, or one of the clocks is active, Q and QN are well defined.

2. If more than one set, reset, or clock lines is active and if the values captured by the activeclocks, set, or reset are the same, Q and QN are well defined. Otherwise, Q and QN areunknown.

Example:

model DLAT1(CLK, D, Q, QN) ( input(D, CLK) () output(Q, QN) (primitive = _dlat(, , CLK, D, Q, QN);) )

Table 4-18. D Latch Primitive Table

Di CLKi SET RESET Q QN

0 1 0 0 0 1

1 1 0 0 1 0

X 1 0 0 X X

? 0 0 0 Q QN

1 1 0 1 X X

? 0 0 1 0 1

0 1 0 1 0 1

0 1 1 0 X X

1 1 1 0 1 0

? 0 1 0 1 0

? ? 1 1 X X



August 2006

Figure 4-37. D Latch

The first two commas in the primitive statement are inserted because there is no set or reset pinin this D latch.

D Q

QNCLK



One Time Unit Delay Element (FlexTest Only)The keyword used to model one time-unit delay is _delay, and the syntax of the primitiveattribute statement is as follows:

primitive = _delay (IN, OUT)

Example:

model DEL1(IN, OUT) ( input(IN) () output(OUT) (primitive = _delay(IN, OUT);) )

Figure 4-38. One Time Unit Delay Element

Table 4-19. DELAY Truth Table

IN (Previous State) OUT

0 0

1 1

DIN OUT



August 2006

Feedback InverterThe primitive used to model a feedback inverter is _invf. The syntax of the primitive attributestatement is as follows:

primitive = _invf (IN, OUT)

NoteThe previous state of IN is X for FastScan and TestKompress. This primitive can only beused in a feedback path.

Example:

model INV_INVX(I, O) ( input(I) () intern(N4) (primitive = _wire(I, N1, N4);) intern(N1) (primitive = _invf(O, N1);) output(O) (function = !N4;) )

Figure 4-39. Feedback Inverter

Table 4-20. INVF Truth Table

IN (Previous State) OUT

0 Weak 1

1 Weak 0

N4

N1

I O



Wire ElementThe primitive used to model signals wired together is _wire. The syntax of the primitiveattribute statement is as follows:

primitive = _wire (IN0, IN1, ..., INn, OUT)

Note* If there is a 'Z' state at the input, then wire is treated as a bus.

NoteEven if an instance name is given, nofaults are placed on this primitive.

Example:

model MEM(I, O) ( input(I) () intern(N4) (primitive = _wire(I, N1, N4);) intern(N1) (primitive = _cmos2f(O, NCNT, PCNT, N1);) intern(NCNT) (primitive = _tie1(NCNT);) intern(PCNT) (primitive = _tie0(PCNT);) output(O) (function = N4;) )

Table 4-21. WIRE Truth Table (for two inputs)

IN0/IN1 0 1 X Z* Weak 0 Weak 1

0 0 X X 0 0 0

1 X 1 X 1 1 1

X X X X X X X

Z* 0 1 X Z 0 1

Weak 0 0 1 X 0 0 X

Weak 1 0 1 X 1 X 1



August 2006

Figure 4-40. Wire Element

Pull-Up or Pull-Down DeviceThe primitive used to model a pull-up or pull-down device is _pull. The syntax of the primitiveattribute statement is as follows:

primitive = _pull (IN, OUT)

Example:

model PULLX(I, O) ( input(I) () output(O) (primitive = _pull(I, O);) )

Figure 4-41. Pull-Up or Pull-Down Device

The tools simulate pull gate transitions in one tester cycle. If you desire slow behavior, leave thepull gate out.

Power SignalThe primitive used to model a power signal is _tie1. The syntax of the primitive attributestatement is as follows:

Table 4-22. PULL Truth Table

IN OUT

1 Weak 1

0 Weak 0

N1

N4I O

NCNT

PCNT

I

O



primitive = _tie1 (OUT)

Example:

model HOLD_CMOS2F(I, O) ( input(I) () intern(N4) (primitive = _wire(I, N1, N4);) intern(N1) (primitive = _cmos2f(O, NCNT, PCNT, N1);) intern(NCNT) (primitive = _tie1(NCNT);) intern(PCNT) (primitive = _tie0(PCNT);) output(O) (function = N4;) )

The _tie1 primitive is supported in macro descriptions. When writing out a netlist inDFTAdvisor, this primitive will be converted to language-specific descriptions.

Ground SignalThe primitive used to model a ground signal is _tie0. The syntax of the primitive attributestatement is as follows:

primitive = _tie0 (OUT)

Example:


The _tie0 primitive is supported in macro descriptions. When writing out a netlist inDFTAdvisor, this primitive will be converted to language-specific descriptions. For example,_tie0 will be converted to the supply0 declaration in Verilog.

Unknown SignalThe primitive used to model an unknown signal is _tiex. The syntax of the primitive attributestatement is as follows:

primitive = _tiex (OUT)

Example:

model UN1(N, P, X) ( input(N, P) () intern(N1) (primitive = _xnor(N, P, N1);) intern(U) (primitive = _tiex(U);) intern(N2) (function = N * !P * U;)



August 2006

intern(N3) (primitive = _xor(N1, N2, N3);) output(X) (primitive = _tshi(N, N3, X);) )

High Impedance SignalThe primitive used to model a high impedance signal is _tiez. The syntax of the primitiveattribute statement is as follows:

primitive = _tiez (OUT)

Example:

model HIGHZ(N, P, Z) ( input(N, P) () intern(N1) (primitive = _xnor(N, P, N1);) intern(U) (primitive = _tiez(U);) intern(N2) (primitive = _bufz(U, N2);) intern(N3) (primitive = _xor(N1, N2, N3);) output(Z) (primitive = _tshi(N, N3, Z);) )

UndefinedThe primitive used to model an undefined functional block is _undefined. The syntax of theprimitive attribute statement is as follows:

primitive = _undefined (IN0, IN1, ..., INn, OUT)

Example:

model UNKNOWN1(A, B, C, D, O1, O2, O3) ( input(A, B, C, D) () output(O1) (primitive = _undefined(A, B, C, D, O1);) output(O2) (primitive = _tiex(O2);) output(O3) (primitive = _tiex(O3);))

Table 4-23. UNDEFINED Truth Table

IN0 IN1 ... INn OUT

? ? ... ? X



Figure 4-42. Undefined Functional Block

A

B

C

D

O1

O2

O3



August 2006

Unidirectional NMOS TransistorThe primitive used to model a NMOS transistor is _nmos. The syntax of the primitive attributestatement is as follows:

primitive = _nmos (I, EN, O)

Example:

model NMOS1(I, EN, O) ( input(I, EN) () output(O) (primitive = _nmos(I, EN, O);) )

Figure 4-43. Unidirectional NMOS Transistor

Table 4-24. NMOS Truth Table

I EN O

? 0 Z

0 1 0

1 1 1

Z 1 Z

X 1 X

? X X

EN

I O



Unidirectional PMOS TransistorThe primitive used to model a PMOS transistor is _pmos. The syntax of the primitive attributestatement is as follows:

primitive = _pmos (I, EN, O)

Example:

model PMOS1(I, EN, O) ( input(I, EN) () output(O) (primitive = _pmos(I, EN, O);) )

Figure 4-44. Unidirectional PMOS Transistor

Table 4-25. PMOS Truth Table

I EN O

? 1 Z

0 0 0

1 0 1

Z 0 Z

X 0 X

? X X

EN

I O



August 2006

Unidirectional Resistive NMOS TransistorThe primitive used to model a resistive NMOS transistor is _rnmos. The syntax of the primitiveattribute statement is as follows:

primitive = _rnmos (I, EN, O)

Example:

model RNMOS(I, EN, O) ( input(I, EN) () output(O) (primitive = _rnmos(I, EN, O);) )

Figure 4-45. Unidirectional Resistive PMOS Transistor

Table 4-26. RNMOS Truth Table

I EN O

? 0 Z

0 1 Weak 0

1 1 Weak 1

Z 1 Z

X 1 Weak X

? X Weak X

EN

I Oresistive



Unidirectional Resistive PMOS TransistorThe primitive used to define a resistive PMOS transistor is _rpmos. The syntax of the primitiveattribute statement is as follows:

primitive = _rpmos (IN, PCNT, OUT)

Example:

model RPMOS1(IN, PCNT, OUT) ( input(IN, PCNT) () output(OUT) (primitive = _rpmos(IN, PCNT, OUT);) )

Figure 4-46. Unidirectional Resistive NMOS Transistor

Table 4-27. RPMOS Truth Table

IN PCNT OUT

? 1 Z

0 0 Weak 0

1 0 Weak 1

Z 0 Z

X 0 Weak X

? X Weak X

PCNT

IN OUTresistive



August 2006

Unidirectional Feedback NMOS TransistorThe primitive used to model a feedback NMOS transistor is _nmosf. The syntax of theprimitive attribute statement is as follows:

primitive = _nmosf (I, CNT, O)

NoteThe previous state of “I” is X for FastScan and TestKompress. This primitive can only beused in a feedback path.

Example:

model HOLD_NMOSF(I, O) ( input(I) () intern(N4) (primitive = _wire(I, N1, N4);) intern(N1) (primitive = _nmosf(O, CNT, N1);) intern(CNT) (primitive = _tie1(CNT);) output(O) (function = N4;) )

Figure 4-47. Unidirectional Feedback NMOS Transistor

Unidirectional Feedback PMOS TransistorThe primitive used to model a feedback PMOS transistor is _pmosf. The syntax of the primitiveattribute statement is as follows:

Table 4-28. NMOSF Truth Table

I (Previous State) CNT O

? 0 Z

0 1 Weak 0

1 1 Weak 1

Z 1 Z

X 1 Weak X

? X Weak X

N1

N4I O

CNT



primitive = _pmosf (I, CNT, O)

NoteThe previous state of “I” is X for FastScan and TestKompress. This primitive can only beused in a feedback path.

Example:

model HOLD_PMOSF(I, O) ( input(I) () intern(N4) (primitive = _wire(I, N1, N4);) intern(N1) (primitive = _pmosf(O, CNT, N1);) intern(CNT) (primitive = _tie0(CNT);) output(O) (function = N4;) )

Figure 4-48. Unidirectional Feedback PMOS Transistor

Unidirectional CMOS1 TransistorThe primitive used to model a CMOS transistor (which can be turned on when E is high or P islow) is _cmos1. The syntax of the primitive attribute statement is as follows:

Table 4-29. PMOSF Truth Table

I (Previous State) CNT O

? 1 Z

0 0 Weak 0

1 0 Weak 1

Z 0 Z

X 0 Weak X

? X Weak X

N1

N4I O

CNT



August 2006

primitive = _cmos1 (I, E, P, O)

Example:

model CMOSX1(I, E, P, O) ( input(I, E, P) () output(O) (primitive = _cmos1(I, E, P, O);) )

Figure 4-49. Unidirectional CMOS1 Transistor

Unidirectional CMOS2 TransistorThe primitive used to model a CMOS transistor (which can be turned on when E is high and P islow) is _cmos2, and the syntax of the primitive attribute statement is:

Table 4-30. CMOS1 Truth Table

I E P O

? 0 1 Z

0 1 ? 0

1 1 ? 1

Z 1 ? Z

X 1 ? X

0 ? 0 0

1 ? 0 1

Z ? 0 Z

X ? 0 X

? 0 X X

? X 1 X

I O

P

E



primitive = _cmos2 (I, E, P, O)

Example:

model CMOSX2(I, E, P, O) ( input(I, E, P) () output(O) (primitive = _cmos2(I, E, P, O);) )

Figure 4-50. Unidirectional CMOS2 Transistor

Unidirectional Resistive CMOS1 TransistorThe keyword used to define a resistive CMOS transistor (which can be turned on when E is highor P is low) is _rcmos1, and the syntax of the primitive attribute statement is:

primitive = _rcmos1 (I, E, P, O)

Table 4-31. CMOS2 Truth Table

I E P O

? 0 ? Z

? ? 1 Z

0 1 0 0

1 1 0 1

Z 1 0 Z

X 1 0 X

? 1 X X

? X 0 X

Table 4-32. RCMOS1 Truth Table

I E P O

? 0 1 Z

0 1 ? Weak 0

1 1 ? Weak 1

I O

P

E



August 2006

Example:

model RMOSX1(I, E, P, O) ( input(I, E, P) () output(O) (primitive = _rcmos1(I, E, P, O);) )

Figure 4-51. Unidirectional Resistive CMOS1 Transistor

Unidirectional Resistive CMOS2 TransistorThe primitive used to model a resistive CMOS transistor (which can be turned on when both Eis high and P is low) is _rcmos2, and the syntax of the primitive attribute statement is asfollows:

primitive = _rcmos2 (I, E, P, O)

Z 1 ? Z

X 1 ? Weak X

0 ? 0 Weak 0

1 ? 0 Weak 1

Z ? 0 Z

X ? 0 Weak X

? 0 X Weak X

? X 1 Weak X


I E P O

0 1 0 Weak 0

1 1 0 Weak 1

Z 1 0 Z


I E P O

I O

P

E

resistive



Example:

model RMOSX2(I, E, P, O) ( input(I, E, P) () output(O) (primitive = _rcmos2(I, E, P, O);) )

Figure 4-52. Unidirectional Resistive CMOS2 Transistor

Unidirectional Feedback CMOS1 TransistorThe primitive used to model a feedback CMOS transistor (which can be turned on when NCNTis high or PCNT is low) is _cmos1f, and the syntax of the primitive attribute statement is:

primitive = _cmos1f (I, NCNT, PCNT, O)i

? 0 ? Z

? ? 1 Z

X 1 0 Weak X

? 1 X Weak X

? X 0 Weak X

Table 4-34. CMOS1F Truth Table

I (Previous State) NCNT PCNT O

? 0 1 Z

0 1 ? Weak 0

1 1 ? Weak 1

Z 1 ? Z

X 1 ? Weak X

0 ? 0 Weak 0

1 ? 0 Weak 1


I E P O

I O

P

E

resistive



August 2006

NoteThe previous state of I is X for FastScan and TestKompress. This primitive can only beused in a feedback path.

Example:


Figure 4-53. Unidirectional Feedback CMOS1F Transistor

Z ? 0 Z

X ? 0 Weak X

? 0 X Weak X

? X 1 Weak X



N1

N4I O

NCNT

PCNT



Unidirectional Feedback CMOS2 TransistorThe primitive used to model a feedback CMOS transistor (which can be turned on when bothNCNT is high and PCNT is low) is _cmos2f, and the syntax of the primitive attribute statementis:

primitive = _cmos2f (I, NCNT, PCNT, O)

NoteThe previous state of I is X for FastScan and TestKompress. This primitive can only beused in a feedback path.

Example:


Figure 4-54. Unidirectional Feedback CMOS2F Transistor



0 1 0 Weak 0

1 1 0 Weak 1

Z 1 0 Z

X 1 0 Weak X

? 0 ? Z

? ? 1 Z

? 1 X Weak X

? X 0 Weak X

N1

N4I O

NCNT

PCNT



August 2006

Pulse Generators with User Defined TimingFastScan and TestKompress support pulse generators with multiple timed outputs. This isuseful in cases when pulse generators have only a single output, and user-specified delay andwidth attributes allow multiple pulses with different effective timing to be generated. You canassume that the combinational delays of the circuit will be such that all paths which need tostabilize between different pulses from choppers will have time to stabilize. The syntax of theprimitive attribute statement is:

primitive = _pulse_generator {delay, width} (clk_in,output);

• Delay and width variables are required attributes. The value of the delay must be in therange 0 <= delay < 64K and the width must be in the range1 <= width < 64K.

In the flattened data structure, for the primitive pulse generator:

primitive= _pulse_generator { 5, 10 } ( ck, a_clk )

the Report Gate command displays the pulse_generator as:

command: report gate -type pgen/test PGEN

IN I OUT O delay = 5 width = 10

The same checks will apply:

• Any sequential element can be clocked at most once in any cycle (C10).

• Intermediate values (from transparent capture cells) cannot be propagated to a PO(D11).

• Each sequential element has only a single state value, so it can only be captured by sinksthat are either always clocked before or always clocked after the source. (not a mixture)(D10).

A limitation to this feature is that any clock pin driving pulse generators will not be able to beused in a clock procedure with other clocks. The output of a pulse generator must not propagateto a PO. (Any such PO will be classified as a clock PO. However, as the output of a pulsegenerator will be at X during clock PO pattern simulation, it is likely that some test coveragewill be lost in this case.)

The output of a pulse generator must not connect to the input of a pulse generator through anypath. The existing T17 rule will be used to cover this situation, too.

There can be no more than 31 unique events associated with the pulsing of any one clock pin.This means that after counting the rising and falling edge events of the clock, 29 additionaldiscrete times may be used for rising and falling edge events generated from pulse generators.



For simulation of test procedures, a pulse generator outputs a 1 when there is a rising edge eventat its input. The rising and falling edge events at the output of the pulse generator are scheduledto create events in the order defined by their delay and width. Additional simulation steps aregenerated to simulate the output changes of pulse generators. All internally generated events arestabilized before the next test procedure event is simulated and the time advanced. In this sense,the delay and width attributes are in units of deltas which are infinitesimally small compared tothe time units used to define test procedures.

The input to a pulse generator at a binary value is required when all clock pins are in theirinactive state, and constrained PIs are placed at the constrained value. In the event that the inputvalue is a 1 under these conditions, the pulse generator is flagged with the “inactive-high”property, and the parallel pattern simulator will consider an input 0 to be the pulse generatingevent.

There is the potential in this capability to significantly increase the amount of DRC simulationrequired, by creating many different edge times from different pulse generators. This isimportant when assigning delays and widths.

There is an increased risk that you may encounter scan chain tracing limitations using thiscapability, due to the ability to generate large numbers of different timed events from only asmall number of shift procedure events. To work around this, additional workspace memory canbe allocated.

In order to model the effect of timed outputs, Design Rules Checking identifies sequentialelements as having transparent capture capability. DRC and simulation behave as if the outputsof the pulse generators are external clock pins, which are pulsed in sequence by a clockprocedure.

RAM and ROMBecause the RAM and ROM primitives have some similar characteristics, they are combinedinto this subsection. However, a ROM is a subset of the functionality of a RAM. Because ROMis somewhat simpler than RAM, it is described first. The added complexities of RAM primitivesare discussed following the description of ROM.

This section discusses RAM and ROM behavior and modeling concerns. For information ontest strategies for RAM and ROM, refer to “Testing with RAM and ROM” in the Scan andATPG Process Guide. For information on RAM rules checking, refer to “RAM Rules (ARules)” on page 105.

RAM and ROM BasicsA ROM is an array of memory cells whose contents are accessible through the activities of oneor more read ports. Each of these read ports has an associated set of inputs. The set of inputs foreach read port includes one or more read control lines, N read address lines, and M data output



August 2006

lines. Each read port must have the same number of address lines, as well as the same number ofdata outputs.

Figure 4-55 shows a ROM.

Figure 4-55. ROM

Address lines identify which column of cells (set of values) to be placed on the data outputlines. A ROM can store values into ((2**N)*M) memory cells. M values at a time are placed onthe outputs. The possible values you can place on the address lines are within the range of 0 to((2**N)-1). The example in Figure 4-55 uses addresses in the range 0-511 and can access 5128-bit words.

Before you read values from a ROM, the contents of the ROM must be initialized. This isaccomplished through the use of a ROM initialization file. This is discussed in “BasicROM/RAM Rules Checking” in the Scan and ATPG Process Guide.

To turn on the read operation, activate the read control line(s). This places the value stored at thelocation specified by the address lines on the data output lines. When the read operation is off(not activated), X's are placed at the outputs, unless you specify a different behavior for the readoff state, using the read_off attribute.

ROMs are modeled as strictly combinational gates; that is, they do not contain any sequentialbehavior. Two simulation gates, ROM and OUT, model the behavior of a ROM once the ROMmodel is flattened. ATPG simulation gates and model flattening are discussed in “ModelFlattening” in the Scan and ATPG Process Guide.

A RAM is similar to a ROM, with the addition of data write capabilities. Like a ROM, a RAMcontains read ports and data output lines. However, it also contains write ports and data inputlines. A RAM can have any number of read and write ports. Each port has its own separateinputs and outputs. All ports must have the same number of address lines, A1…AN, and theymust also have the same number of data lines, D1…DM. Figure 4-56 shows a block diagram ofa RAM.

9-bitaddress

bus

8-bitdatabus

read

ROM

(512 x 8)

control



Figure 4-56. RAM

The read operation of a RAM is identical to that of a ROM. However, to read a RAM value, youmust first write a value to the specified location. To perform a write operation, you must placethe proper address on the write address lines, place the proper data on the data in lines, andactivate the write operation (typically, turn on write enable and pulse write clock). To modelRAM behavior, the tools use RAM and OUT simulation gates in the flattened design. Theflattened model may require additional gates, depending on how you define the output enable(oen) signal (see page 263). Often, oen is not needed to model the RAM of interest, so this inputwas not shown in Figure 4-56.

RAM/ROM Library PrimitivesThis section discusses the library primitives used to model ROM and RAM. In each of theprimitive descriptions that follow, the items inside the () denote pins that comprise the specifiedport. Additionally, within the _cram primitive, the items inside the {} denote optional portattributes. Read and write port behavior specified in the model description, is described in moredetail in the next section.

ROM Library Primitive

The library primitive used to model ROM is _rom. The syntax of the primitive attributestatement is:

primitive = _rom (_read(REN, Aij, ..., Ai1, Ai0, Dij, ..., Di1, Di0));

writeaddress

RAM

writeport

readport

data in

write clkwrite en

readaddress data

out

read clkread en



August 2006

NoteThe address and data line ordering specified from left to right must match the left to rightordering of the lines specified in the ROM init file. The DFT tools do not make anyassumptions about ordering (for example, MSB to LSB).

Example:

model ROM2(Ren1, A1[2], A1[1], A1[0], D1[2], D1[1], D1[0], Ren2, A2[2], A2[1], A2[0], D2[2], D2[1], D2[0]) ( input(Ren1, A1[2], A1[1], A1[0]) () input(Ren2, A2[2], A2[1], A2[0]) () output(D1[2], D1[1], D1[0], D2[2], D2[1], D2[0]) ( data_size = 3; address_size = 3; read_off = X; min_address = 0; max_address = 7; init_file = "rom.init_file"; primitive = _rom( _read(Ren1, A1[2], A1[1], A1[0], D1[2], D1[1], D1[0]), _read(Ren2, A2[2], A2[1], A2[0], D2[2], D2[1], D2[0]) ); ) )

Or, you can model the same ROM using the array construct as follows:

model ROM2 (Ren1, A1, D1, Ren2, A2, D2) ( input(Ren1, Ren2) () input(A1,A2) (array = 2:0;) output(D1,D2) ( array = 2:0;

data_size = 3; address_size = 3; read_off = X; min_address = 0; max_address = 7; init_file = "rom.init_file"; primitive = _rom( _read(Ren1,A1,D1), _read(Ren2,A2,D2) ); ) )

This example shows a 2-port ROM with three address lines and three data lines. The read enablefor the first port is named Ren1. The address lines for the first port, given with highest orderfirst, are A1[2], A1[1], and A1[0]. The data lines for the first port are D1[0], D1[1], and D1[2].The read enable for the second port is named Ren2. Likewise, the address lines are A2[2],A2[1], and A2[0], and the data lines are D2[0], D2[1], and D2[2].



When the read operation is off, X's are placed on the out gates. The addresses allowed on theaddress lines are in the range of 0 to 7. The initialization values to be placed on the ROM arefound in a file called rom.init_file in the library directory.

The attributes data_size and address_size are required. The attributes read_off, min_address,max_address, and init_file are optional.

Basic RAM Library Primitive

The library primitive used to model simple RAM is _ram. The syntax of the primitive attributestatement is:

primitive = _ram (SET, RESET, _read(REN, An, ..., A1, A0, Dn, ..., D1, D0), _write(WEN, Aij, ..., Ai1, Ai0, Dij, ..., Di1, Di0))

NoteThe address and data line ordering specified from left to right must match the left to rightordering of the lines specified in the RAM init file. The DFT tools do not make anyassumptions about ordering (for example, MSB to LSB).

Example 1:

model RAM1(W1, A1[2], A1[1], A1[0], D1[2], D1[1], D1[0], R2, A2[2], A2[1], A2[0], D2[2], D2[1], D2[0]) ( input(W1, A1[2], A1[1], A1[0], D1[2], D1[1], D1[0]) () input(R2, A2[2], A2[1], A2[0]) () output(D2[2], D2[1], D2[0]) ( data_size = 3; address_size = 3; read_off = 0; min_address = 0; max_address = 7; edge_trigger = w; init_file = "ram.init_file"; primitive = _ram(, , _write(W1, A1[2], A1[1], A1[0], D1[2], D1[1], D1[0]), _read(R2, A2[2], A2[1], A2[0], D2[2], D2[1], D2[0]) ); ) )

This example shows a RAM gate with one write port and one read port, and no set or reset lines.The edge-triggered enable line of the write port is W1. The three-bit address includes linesA1[2], A1[1], and A1[0]. The three-bit data input includes lines D1[2], D1[1], and D1[0]. Theaddress space is 0 to (2**3)-1.

The read port enable line is R2. The read port address lines are A2[2], A2[1], and A2[0]. Thedata out lines include D2[2], D2[1], and D2[0].



August 2006

Example 2:

array_delimiter = "<>";

// RAM128 modelmodel ram128 (DOUT,ADD,CS,DIN,RD,WR) ( input(ADD) (array = 7 : 0;) input(DIN) (array = 15 : 0;) input(CS, RD, WR) () intern(DATAIN) ( array = 15:0; primitive = _dlat D1 (,,RD,DIN<15>,DATAIN<15>,); primitive = _dlat D2 (,,RD,DIN<14>,DATAIN<14>,); primitive = _dlat D3 (,,RD,DIN<13>,DATAIN<13>,); primitive = _dlat D4 (,,RD,DIN<12>,DATAIN<12>,); primitive = _dlat D5 (,,RD,DIN<11>,DATAIN<11>,); primitive = _dlat D6 (,,RD,DIN<10>,DATAIN<10>,); primitive = _dlat D7 (,,RD,DIN<9>,DATAIN<9>,); primitive = _dlat D8 (,,RD,DIN<8>,DATAIN<8>,); primitive = _dlat D9 (,,RD,DIN<7>,DATAIN<7>,); primitive = _dlat D10 (,,RD,DIN<6>,DATAIN<6>,); primitive = _dlat D11 (,,RD,DIN<5>,DATAIN<5>,); primitive = _dlat D12 (,,RD,DIN<4>,DATAIN<4>,); primitive = _dlat D13 (,,RD,DIN<3>,DATAIN<3>,); primitive = _dlat D14 (,,RD,DIN<2>,DATAIN<2>,); primitive = _dlat D15 (,,RD,DIN<1>,DATAIN<1>,); primitive = _dlat D16 (,,RD,DIN<0>,DATAIN<0>,); ) intern(WR_CS) ( primitive = _and AN1 (CS,WR,WR_CS); ) output(DOUT) ( array = 15:0; min_address = 0; max_address = 128; data_size = 16; address_size = 8; primitive = _ram RAM1 (,, _read(CS,ADD,DOUT), _write(WR_CS,ADD,DATAIN)); )

Comprehensive RAM Primitive

The primitive used to model complex RAM reading and writing capabilities is _cram. Thesyntax of the primitive attribute statement is:

primitive = _cram (SET, RESET, _read{w,x,y,z}(oen,rclk,ren,address,out_data) _write{x,y,z}(wclk,wen,address,in_data)

The _cram primitive may have any number of write and read ports. However, it must have atleast one write port and at least one read port. The port types are described in more detail in thefollowing section.

Example 1:



model CRAM1(Wclk1, WA1[2], WA1[1], WA1[0],Din1[2], Din1[1], Din1[0],Rclk1, RA1[2], RA1[1], RA1[0],Dout1[2], Dout1[1], Dout1[0],

REN1, WEN1) ( input(Wclk1, WA1[2], WA1[1], WA1[0],

Din1[2], Din1[1], Din1[0]) () input(Rclk1, RA1[2], RA1[1], RA1[0], REN1, WEN1) () output(Dout1[2], Dout1[1], Dout1[0]) ( edge_trigger = r; data_size = 3; address_size = 3; read_off = h; min_address = 0; max_address = 7; init_file = "ram.init_file"; primitive = _cram(, , _write{,,} (Wclk1, WEN1, WA1[2], WA1[1], WA1[0], Din1[2], Din1[1], Din1[0]), _read{,H,H,H}(, Rclk1, REN1, RA1[2], RA1[1], RA1[0], D2[2], D2[1], D2[0]) ); ) )

Or, the same RAM can be modeled using the array construct as follows:

model CRAM1(Wclk1, WA1, Din1, Rclk1, RA1, REN1, WEN1, Dout1) ( input (Wclk1, Rclk1, REN1, WEN1) () input (WA1,RA1) (array = 2:0;) input (Din1) (array = 2:0;) output (Dout1) (

array = 2:0; edge_trigger = r; data_size = 3; address_size = 3; read_off = h; min_address = 0; max_address = 7; init_file = "ram.init_file"; primitive = _cram (,, _write{,,} (Wclk1, WEN1, WA1, Din1), _read{,H,H,H} (,Rclk1, REN1, RA1, Dout1) );

))

Attributes of RAM/ROM PrimitivesThe following attributes may be used within the RAM and ROM model descriptions:

• data_size = number;This required attribute specifies the width of the data outputs.

• address_size = number;This required attribute specifies the width of the address inputs.



August 2006

• primitive = [_rom | _ram | _cram];This required attribute specifies the library primitive used by the RAM or ROM beingdefined.

• array = start_number: end_number;This optional attribute specifies the width of wide address or data pins.

• min_address = number;This optional attribute specifies the minimum valid address. The default is 0.

• max_address = number;This optional attribute specifies the maximum valid address. The default is(2**address_size) - 1.

• read_off = [0 | 1 | X | H];This optional attribute specifies the data output values if the read enable line is off. Theoptions are 0, 1, hold, or X, which is the default. For the _rom primitive, this value mustbe X. For the _cram primitive, this attribute does not apply because the X,Y, Zattributes specify its read_off behavior. For more information on requirements of theread_off attribute relative to the _ram primitive, refer to the “Basic ROM/RAM RulesChecking” section of the Scan and ATPG Process Guide.

• init_file = “file_name”;This optional attribute specifies the file, in MGC model file format, defining initialmemory values.

• edge_trigger = [R | W | RW];This optional attribute specifies the edge trigger values of the read and/or write lines. Rindicates the read lines are positive edge-triggered whereas W indicates the write linesare positive edge-triggered. RW indicates both are positive edge-triggered. The defaultis neither read nor write are positive edge-triggered.

NoteThe _rom primitive does not support this attribute.

For the _cram primitive, only the 1st control (the read clock for _read ports and the writeclock for _write ports) can be edge triggered. The _cram read and write enables, if theyare used, are always level sensitive.

• address_type = <encode|decode>;This optional attribute is used only for the _cram primitive to specify whether theaddress lines are encoded or decoded. Encoded is the default.

NoteThe _cram primitive does not support decoded address buses for FlexTest.



• read_read_conflict = [R|X];This optional attribute specifies the behavior when two or more _read ports are activeon the same address at the same time. If this attribute is set to R, the normal read iscarried out. If the attribute is set to an X, X is placed at the outputs. R is the default.

NoteFlexTest does not support this attribute because it simulates each read operation. Thus, itsbehavior for this case is “R”, regardless of the value of the addresses.

• read_write_conflict = [NW|XW|OW|XX|OX];This optional attribute specifies the behavior when a _read and a _write port are bothactive on the same address. If the address is different, the normal read/write operationsare performed. If the address is the same, simulation is defined by the value of theattribute. The first character defines how the read is performed, and the second characterdefines how the write is performed. N=new, O=old, X=x values, and W= normal writeoperation. NW is the default. For example, if the attribute is set to NW, then the newvalue is read and the new value is written.

NoteFlexTest always does “NW” independent of addresses; that is, it does not supportXW|OW|XX|OX.

• write_contention = [true|false];This optional attribute specifies the behavior when two or more _write ports are activeat the same time. If set to true, all (independent of address) multiple writes are prohibitedby this attribute. False is the default.

• overwrite = [true|false];This optional attribute is used only if the write_contention attribute is set to false. Thisattribute defines the behavior when multiple ports are writing to the same address. If setto true, and if the addresses are different, both writes are carried out. If the address is thesame, precedence is given to the last port defined in the model (data at the other writeport is completely ignored).

If set to false, and if the addresses are different, all writes are carried out. If the addressis the same, the write that is performed depends on the data at the active write ports. Ifdata differs at the active ports, an X is written. Otherwise, the same data is at all ports, soit is written to them all. For this attribute, FastScan, FlexTest, and TestKompress exhibitthe same behavior.

Initialization Files for RAM and ROMThe init_file may be used to define the initial values of the memory cells of the RAM and ROM.The supported format of this file is the Mentor Graphics ROM/RAM modelfile format. For adetailed description of this format, refer to the Read Modelfile command page in the ATPG and



August 2006

Failure Diagnosis Tools Reference Manual. You use the Read Modelfile command to read inthe initialization file.

ROM and RAM Port BehaviorThis section describes the port behaviors for the _rom, _ram, and _cram library primitives.

Read Port Behavior for _rom and _ram

You use a _read keyword for each read port of the ROM or RAM. Each read port contains anordered list of pins separated by commas. If you omit a pin, you must still specify the commadelimiter. When you define the pins, the read control line(s) must be first, followed by theaddress lines, and then the data out lines.

The read enable line is optional for ROM. If it is not defined, it is assumed that the port isalways reading. If the read enable is defined, by default it behaves as follows. It is assumed tobe active high. When the read enable line is active, the values of the memory cells associatedwith the current port address are placed on the data outputs--if the address is valid. If the currentaddress is invalid, all outputs of the port are set to X. Additionally, when either the read enableline is at X or the read enable line is active and any address line is at an X state, all outputs of theport are set to X. If the read enable line is low (inactive), all outputs of the port are set to X. Youcan change some of this default behavior by using attributes in the RAM or ROM modeldescription. For example, you can change the behavior of the ROM when reading is inactiveby using the read_off attribute.

The number of address lines in each port must be equal to the number specified by theaddress_size attribute. The address lines must be ordered so that the most significant addresslines are given first. The number of data lines in each port must be equal to the number specifiedby the data_size attributes. The data lines must be ordered so that the first data input linecorresponds to the first data output line, and so on. The data line ordering must also beconsistent with the data ordering specified in the initialization file.

You can use the edge_trigger attribute to specify that the read lines of all RAM read ports areedge-triggered. This specifies for the RAM to only read during the rising edge of an edge-triggered read line. RAM with edge-triggered read lines must also set the value of the read_offattribute to hold. This indicates the read port is capable of holding the values at its outputs whenthe read line is off. Failure to satisfy this condition results in an error condition during designflattening.

You cannot use the edge_trigger attribute with ROMs; an error condition results during designflattening.

Read Port Behavior for _cram

_read{w,x,y,z}(oen,rclk,ren,address,out_data)



Each read port of a _cram can have up to five pins. The first three are the control pins, whichare described in the following list:

• oen - This is the output enable signal that is used to control accessibility of the _cramoutput. If the signal is high, the output is accessible. Otherwise, the output is disabled.You can assign a value to this signal using the w attribute that is within the {} of the_read statement. The choices are 0, 1, X (default), Z, or H (hold previous value).

If you specify 0, the tool adds AND gates after each OUT gate in the flattened model, asFigure 4-57 shows.

Figure 4-57. Flattened RAM Model with oen Set to 0

Likewise, if you specify 1, X, Z, or H, the tool adds OR, MUXed TieX, tri-stateabledriver, or D latch gates, respectively.

• rclk - This is the read clock, which is the signal that activates reading of the RAM data.You can use the edge_trigger attribute to specify whether the signal is edge triggered orlevel sensitive. You must specify this clock pin if the signal is edge triggered or if youspecified the read enable pin. If you do not specify this signal, the default behavior isalways active.

• ren - This is the read enable, a signal which can also activate reading of the RAM data.If the RAM has only one signal that activates reading, you must specify this signal as aread clock pin (rclk).

The read enable pin is assumed to be level sensitive. If you do not specify this pin, thedefault behavior is always active.

Normally, the RAM data is accessible when both the read enable and read clock signalsare active. You can use the x, y, and z attributes within the {} of the _read statement tospecify the desired behavior when either or both of these signals are inactive. The xattribute specifies the behavior when both are inactive, the y attribute specifies thebehavior when only ren is inactive, and the z attribute specifies the behavior when onlyrclk is inactive. The choices for behavior of the read port values are 0, 1, X, H (holdprevious values), H1 (hold previous values for one clock cycle, then become X), and PR(possible read, outputs that would change if a read were done are set to X).

RAMout

oenwenadrdi0di1

do0do1

out



August 2006

NoteFlexTest does not support the H1 and PR options.

Set and Reset Lines for _ram and _cram

The _ram and _cram primitives may have a set and/or reset input that is active high. If the setline is high, all the memory cells of the RAM are set to 1. If the reset line is high, all the memorycells of the RAM are set to 0. If either the set or reset input is at an X, or if both are high, all thememory cells of the RAM are set to X. If the set or reset lines are not used, the commadelimiters must still be inserted in the primitive definition.

Write Port Behavior for _ram

Each _write port contains an ordered list of pins. When you define the pins, you must specifythe write enable first, followed by the address lines, and then the data in lines.

By default, the behavior of the RAM write port is as follows. The write enable line is activehigh. When the write enable line is active, the memory location specified by the current portaddress is loaded with data present on the data in lines--if the address is valid. If the address isinvalid, the write operation is ignored. When the write enable line is at X or the write enable lineis active and any address line is at an X state, FastScan and TestKompress set the memory cellsthat will be accessed by the address to X. FlexTest does the same if the input data value differsfrom the memory cell of the RAM. If the input data and the memory cell value are the same, thememory cell value will not be changed.

When multiple write ports are active at the same time, and they attempt to write conflictingvalues to the same memory cell, those memory cells are set to X (unless the overwrite attributeis used). The overwrite attribute gives precedence to the last _write port defined within the_ram primitive.

The number of address lines in each port must be equal to the number specified by theaddress_size attribute. The address lines must be ordered so that the most significant addresslines are given first. The number of data lines in each port must be equal to the number specifiedby the data_size attributes. The data lines must be ordered so that the first data in linecorresponds to the first data out line, and so on. The data line ordering must also be consistentwith the data ordering specified in the initialization file.

You can use the edge_trigger attribute to specify that the write lines of all write ports are edge-triggered. This specifies for the RAM to only write during the rising edge of an edge-triggeredwrite line. For RAMs with edge-triggered write lines, the following rules apply:

• Static pass-through testing is not allowed.

• The RAM must successfully pass design rule A1 in order to be used during ATPG orfault simulation. Otherwise, it is treated as a tie-X gate.



• Patterns pulse the write control line after forcing the primary inputs to make sure theaddress and data in inputs are stable.

Write Port Behavior for _cram

_write{x,y,z}(wclk,wen,address,in_data)

You use a _write keyword for each write port of the _cram. The pin list for a write portcontains four pins separated by commas. If you omit a pin, you must still specify the commadelimiter. The first two are the control pins, which are described in the following list:

• wclk - This signal, which is not optional, activates writing to the RAM. You can use theedge_trigger attribute to specify whether the signal is edge-triggered or level sensitive.

• wen - This signal, which is assumed to be level sensitive, also activates writing. If notspecified, the default value is active.

When both the write enable and write clock signals are active, the normal write operation isperformed. Additionally, you can specify the behavior when either or both of these signals areinactive by using the x, y, and z attributes. The x attribute specifies the behavior when both areinactive; the y attribute specifies the behavior when wen is inactive; and the z attribute specifiesthe behavior when wclk is inactive. The choices for cell values are 0, 1, X, H (contents notchanged, the default), and PW (possible write--cells which would change if a write were doneare set to X).

It is possible to change the simulation behavior of RAM models with data hold capability. Incases where it is required to model a RAM, which has data hold capability that does notintroduce latency, you can use the Add Capture Handling command to define a data-hold RAMas a source of new data -- this will indicate that latency is to be removed. For more information,see the Add Capture Handling command description in the ATPG and Failure Diagnosis ToolsReference Manual.

Read_Write Port Behavior for _cram

You can use the _read_write port primitive, if a read port and a write port have the same addressand data lines. The primitive is defined as follows:

_read_write {rw, rx, ry, rz, wx, wy, wz} (oen, rclk, ren, wclk,wen, address, data);

Here, rw, rx, ry, and rz are attributes used to specify the read port behavior as described in _readport. However, rw (the attribute for specifying the behavior of output enable) has a differentdefault value if it is not specified, and the default is Z, which is the only legal value for rw. Thewx, wy, and wz are attributes used to specify the write port behavior.

The first five pins of the _read_write port are output enable (oen), read clock (rclk), read enable(ren), write clock (wclk), and write enable (wen). The order is significant. Also, the outputenable pin must be specified in the _read_write port.



August 2006

The behavior of the port will be to allow either read or write in each cycle (not both), but it willnot be possible to perform any form of passthru test using the RAM. In the case that multipleRAMs share a common data bus, it will not be possible to transfer data from one RAM toanother using the bus.

NoteFastScan and TestKompress will report an A5 rule violation in this case.

Provided contention checking is performed; there will be no danger of creating an incorrectpattern, although a certain amount of pessimism will be introduced into the simulation. In orderto support a bidirectional pin, exceptional behavior will be required in flattening.

For a read/write port, a read write conflict on the same port will always be treated as read X,write X. This is independent of the attribute controlling conflicts between the other ports of the_cram.

An example of a ram model that uses _read_write port is shown below:

model RAM1(W1,A1,R2,D1) ( input(W1,R2) () input(A1) (array = 4:0;) inout(D1) (

array = 0:4; data_size = 5; address_size = 5; min_address = 0; max_address = 31; primitive = _cram(,,

_read_write (R2,R2,,W1,,A1,D1) ); ) )

DRC for RAMs

Edge triggered ports: DRC will recognize the case where a RAM port is stable due to having anedge triggered clock. This supports using opposite edges of the same signal to clock multipleports of the same RAM. This is not supported for level sensitive ports.

RAM sequential patterns require that a RAM be kept stable across multiple scan loadoperations. (for example, no write can occur during scan shift). Further, if a RAM has data holdcapability at its read port, the read port must also not be clocked during scan shift. Theserequirements are also checked by existing DRCs.

ROM LimitationsThe following restrictions apply to ROM modeling:

• The _rom primitive does not support the edge_trigger attribute.



• The _rom primitive only supports the read_off attribute value of X.

RAM LimitationsTo simplify the ATPG process, there are two restrictions that should have an insignificantimpact on the test coverage.

1. If there is a read operation requirement at a RAM, all of its write operations must be atits off-state. This restriction reduces the efforts to make sure what is read will not beoverwritten at the same time during the ATPG process. However, if there is a writeoperation requirement, read operation can be at any state. This allows us to do ATPG fora RAM whose read enable lines are always active.

2. If there is a write operation requirement at one port, all the write operations of otherports must be at their off-states. This restriction reduces the efforts to make sure what iswritten at one port will not be overwritten by another port at the same time, during theATPG process.



August 2006


Chapter 5Creating ATPG Models

LibComp is a utility that translates Verilog modules into ATPG models for use withDFTAdvisor, FastScan, FlexTest, and TestKompress. For more information see the followingtopics:

Understanding LibComp Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Creating an ATPG Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Finding Unsupported Constructs in Partial Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Finding Black Boxes with Vectored Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Understanding LibComp LimitationsLibComp focuses primarily on the translation of User-defined Primitives (UDP) and gate levelcomponent descriptions, such as combinational/sequential UDPs and gate-level and switch-level constructs.

LibComp supports only a subset of Verilog constructs. When unsupported constructs areencountered, the supported pieces of the module into a partial ATPG model. You can thenlocate and complete the model. For more information, see “Finding Unsupported Constructs inPartial Models” section.

LibComp does not support the following Verilog constructs:

• UDPs

o SR latches constructed with complex logic

• Behavioral Constructs

o Always blocks

o Tasks

o Functions

o Initial blocks

o Loops

• Structural Constructs


Creating ATPG ModelsCreating an ATPG Library

August 2006

o Parameters that are expressions (For example, expression “a & b” in the actualparameter of a port)

o Modules or primitives with undefined instances

o Non-Logical operation in the continuous assign statement

o Array, Vector, $<functions> and integer data structures/calls

o Non-Assign operations and real types in the continuous assign statement

Creating an ATPG LibraryUse the following steps to compile an ATPG library from a Verilog netlist or library of Verilogmodules:

1. Invoke LibComp on the Verilog source library/netlist. For example:

<mgcdft_tree>/bin/libcomp <verilog_library_path> -log file <log_file>

For more information on using this command, see the libcomp shell command in theATPG and Failure Diagnosis Tools Reference Manual.

2. Specify which modules the Verilog source library/netlist to translate. You can specifyone or more modules by name or use the -ALl switch to translate all the modules in theVerilog source. For example:

add model model1 model2 model3

or

add model -all

3. Set libcomp to translation mode. For example:

set system mode translation

4. Begin module translation. For example:

run

The specified Verilog modules are translated into the ATPG library format.

5. When translation is complete, save the ATPG model library to a file. For example:

WRIte LIbrary my_atpg_library

Finding Unsupported Constructs in PartialModels

When unsupported constructs are encountered, LibComp continues to translate the supportedpieces of the module into a partial model.

Creating ATPG ModelsFinding Black Boxes with Vectored Outputs


Unsupported constructs contain a “not translated/supported” message in the partial model. Youcan then locate the unsupported construct and edit the partial model as needed to complete it.

To find the unsupported constructs within partial models:

1. Invoke Libcomp on the Verilog library and create a logfile. For example:

<mgcdft_tree>/bin/libcomp library_path -log file log_file -replace

The library is translated and a log file detailing the output including unsupportedconstructs is generated.

2. From the UNIX commandline, search the resulting logfile for the unsupported message:

grep "not translated/supported." my.log

Each instance of the “not translated/supported” warning message in the logfile displays,the module name and the line number of the unsupported construct.

Finding Black Boxes with Vectored OutputsLibComp leaves vectored outputs on black boxes undriven. These undriven outputs default to_tiex in ATPG runs. In some cases, partial models with only some outputs black boxed mayresult. Black boxes with vectored outputs are preceded with a “Blackboxed PO” message in theATPG library.

Use the following command to display a list of the black boxed models with vectored outputs inan ATPG library:

grep "Blackboxed PO." output.atpglib


Creating ATPG ModelsCommand Summary

August 2006

Command SummaryThis section provides descriptions of the LibComp commands. Each subsection is named for thecommand being described. For quick reference, the commands appear alphabetically with eachbeginning on a separate page. Table 5-1 contains a brief summary of the commands describedin this section.

Command DescriptionsThe remaining pages in this chapter describe, in alphabetical order, the commands available inLibComp.

Table 5-1. Command Summary

Command Description

Add Model Adds models from the currently loaded library into theset of models for compilation.

Delete Model Removes a model from the current compilation set.

Dofile Executes the commands contained within the specifiedfile.

Exit Terminates the application session.

Help Displays the usage syntax for the specified command.

Load Library Loads a specified Verilog library file for translation.

Report Environment Displays the current tool settings.

Run Starts the compilation process.

Set Asynchronous Control_Logic Determines whether output dominance logic is usedduring the translation of sequential UDP memorymodules.

Set Dofile Abort Specifies whether the tool aborts or continues dofileexecution if an error condition is detected.

Set Flextest Determines whether FastScan or FlexTest is used toverify the compiled models.

Set System Mode Specifies the system mode you want the tool to enter.

Set Partial Translation Determines whether partial models or black boxes areoutput when unsupported Verilog is encountered.

Set Verification Specifies whether the tool performs verification.

System Passes the specified command to the operating systemfor execution.

Write Library Writes the ATPG library format models to a file.

Creating ATPG ModelsCommand Descriptions


Use the line continuation character “\” when application commands extend beyond the end of aline in a dofile. The line continuation character improves the readability of dofiles and helpswith the command line entry of multiple-argument commands.


Creating ATPG ModelsAdd Model

August 2006

Add ModelScope: Setup mode

Prerequisites: You must first load the Verilog library that contains the cell model(s) that youwant to add.

Usage

ADD MOdel model_name... | -ALl

Description

Adds models from the currently loaded library into the set of models for compilation.

The Add Model command lets you specify one or more models to add to the compile list. Youcan also specify for the tool to add all models found in the netlist.

Arguments

• model_name

A repeatable string that specifies the name of the model that you want to add into the set ofmodels for compilation.

• -ALl

A switch that specifies to add all models from the currently loaded library into the set ofmodels for compilation.

Examples

The following example adds all models from the loaded library into the set of models forcompilation.

add model -allset system mode translationrun

Related Commands

Delete ModelLoad Library

Run

Creating ATPG ModelsDelete Model


Delete ModelScope: Setup mode

Usage

DELete MOdel model_name... | -ALl

Description

Removes a model from the current compilation set.

The Delete Model command lets you delete one or more models or set the tool to remove allmodels from the compilation set.

Arguments

• model_name

A repeatable string that specifies the name of the model to remove from the currentcompilation set.

• -ALl

A switch that specifies to remove all models from the current compilation set.

Examples

The following example adds all models from the currently loaded library and then deletes oneparticular model from that library.

add model -alldelete model ram8x4

Related Commands

Add Model Run


Creating ATPG ModelsDofile

August 2006

DofileScope: All modes

Usage

DOFile filename

Description

Executes the commands contained within the specified file.

The Dofile command sequentially executes the commands contained in a specified file. Thiscommand is especially useful when you must issue a series of commands. Rather than executingeach command separately, you can place them in a file and then execute them by using theDofile command. You can also place comment lines in the file by starting the line with a doubleslash (//); lines preceded with a double slash (//) are ignored.

The Dofile command sends each command expression (in order) to the tool which in turndisplays each command line from the file before executing it. If the tool encounters an error dueto any command, the Dofile command stops its execution and displays an error message. Youcan enable the Dofile command to continue regardless of errors due to setting the Set DofileAbort command to Off.

Arguments

• filename

A required string that specifies the name of the file that contains the commands that youwant the tool to execute.

Examples

The following example orderly executes all the commands from the file, command_file:

dofile command_file

Creating ATPG ModelsExit


ExitScope: All modes

Usage

EXIt

Description

Terminates the application session.

The Exit command terminates the tool session and return to the operating system. Use thiscommand for interactive sessions and in dofiles.

Examples

The following example quits the tool without saving the current compilation set.

add model -allset system mode translationrunexit


Creating ATPG ModelsHelp

August 2006

HelpScope: All modes

Usage

HELp [command_name]

Description

Displays the usage syntax for the specified command.

The Help command provides quick access to either information about a specific command, to alist of commands beginning with at specific key word, or to a list of all the commands.

Arguments

• command_name

An optional string that either specifies the name of the command for which you want help orspecifies one of the following keywords whose group of commands you want to list: ADD,DELete, LOAd, SET, REPort, or WRIte.

If you do not supply a command_name, the default is to display a list of all the commandnames.

Examples

The following example displays the usage and system mode for the Report Gate command.

help report gate

// Report gate// usage: REPort GAte <gateID | gateName>... | -All// legal system modes: TRANSLATION

Creating ATPG ModelsLoad Library


Load LibraryScope: Setup mode

Usage

LOAd LIbrary filename...

Description

Loads a specified Verilog library file for translation.

Use the Load Library command to specify the Verilog library to translate.

NoteThe Load Library command can only be used once per tool session.

Arguments

• filename

A required repeatable string that specifies the pathname of a file containing Verilogsimulation library cells.

Examples

The following example loads the Verilog library my_library.v and then adds all models fromthe library into the compilation set.

load library my_library.vadd model -all

Related Commands

Add Model


Creating ATPG ModelsReport Environment

August 2006

Report EnvironmentScope: All modes

Usage

REPort ENvironment

Description

Displays the current tool settings.

The Report Environment command displays the current tool environment settings.

Examples

The following example lists the current tool settings.

report environment

// Environment Report// Naming Prefix is mlc_// Translation Mode is SETUP_MODE// Learning is On// Optimization is On// Verification is On// Verbose UDP Rules is Off// NoFault setting is UDP// Report Nets setting is Off

Related Commands

None

Creating ATPG ModelsRun


RunScope: Translation mode

Usage

RUN

Description

Starts the compilation process.

The Run command starts the compilation process on all models currently in the compilation list.The list is created using the Add Model and Delete Model commands.

Examples

The following example starts the compilation process on the models added to the compilationset.

load library my_library.vadd model -allset system mode translationrun

Related Commands

Add ModelDelete Model


Creating ATPG ModelsSet Asynchronous Control_Logic

August 2006

Set Asynchronous Control_LogicScope: Setup mode

Usage

SET ASynchronous Control_logic{-OUTput_dominance_logic | -NO_OUTput_dominance_logic}

Description

Determines whether output dominance logic is used during the translation of sequential UDPmemory modules.

This command applies only to sequential UDP memory models when both the Set and Resetsignals are asserted. Use this command before the Run command to create the desired ATPGmodels.

There are four possible Q output values that a UDP can produce when both Set and Reset areasserted. By default, LibComp models each output as described in the following table.

• -OUTput_dominance_logic

Required switch that produces models that use dominance AND logic when both Set andReset are asserted on a sequential UDP modules. This is the default behavior.

• -NO_OUTput_dominance_logic

Required switch that produces models that output an X value for sequential UDP moduleswhen both Set and Reset are asserted, regardless of signal dominance.

Examples

The following example creates a model that always produces an X value for UDPs when bothSet and Reset are asserted.

Table 5-2. Output Dominance Logic

UDP Behavior Model Dominance Logic Q Output Value

Both Set and Reset dominant No AND gating dominance logicused.

X

Reset dominant AND gate used to de-assert Setwhen Reset is active.

0

Set dominant AND gate used to de-assert Resetwhen Set is active.

1

No dominance AND gates used to de-assert bothSet and Reset when other asserted.

Hold

Creating ATPG ModelsSet Asynchronous Control_Logic


load library my_library.vadd model -allset asynchronous control_logic -NO_OUTput_dominance_logicset system mode translationrun

Related Commands

Run


Creating ATPG ModelsSet Dofile Abort

August 2006

Set Dofile AbortScope: All modes

Usage

SET DOfile Abort ON | OFf

Description

Specifies whether the tool aborts or continues dofile execution if an error condition is detected.

The Set Dofile abort command stops processing and reports any line numbers causing errors inthe dofile. However, the Set Dofile Abort command enables you to turn this functionality off sothat the tool continues to process all commands in the dofile.

Arguments

• ON

A required literal that halts the execution of a dofile upon the detection of an error. This isthe default upon invocation of the tool.

• OFF

A required switch that forces dofile processing to complete all commands in a dofileregardless of error detection.

Examples

The following example sets the Set Dofile Abort command off to ensure that all commands intest1.dofile are executed.

set system mode translationset dofile abort offdofile test1.dofile

Related Commands

Dofile

Creating ATPG ModelsSet Fastscan


Set FastscanScope: Setup mode

Usage

SET FAstscan ON | OFf

Description

Determines whether FastScan or FlexTest is used to verify the compiled models.

If the FlexTest tool is available, you can use the Set Fastscan command to make your dofilescompatible with previous versions of LibComp that used FlexTest for verification.

Arguments

• ON

A required literal that enables FastScan for verification. This is the default setting.

• OFF

A required literal that enables FlexTest for verification.

Examples

The following example sets FlexTest as the verification tool used to verify the compiledlibraries:

set fastscan off

Related Commands

Set Flextest


Creating ATPG ModelsSet Flextest

August 2006

Set FlextestScope: Setup mode

Usage

SET FLEXtest OFf | ON

Description

Determines whether FastScan or FlexTest is used to verify the compiled models.

Arguments

• OFf

A required literal that enables Fastscan for verification. This is the default setting.

• ON

A required literal that enables FlexTest for verification.

Examples

The following example sets FlexTest as the verification tool used to verify the compiledlibraries:

set flextest on

Related Commands

Set Fastscan

Creating ATPG ModelsSet System Mode


Set System ModeScope: All modes

Usage

SET SYstem Mode Setup | Translation

Description

Specifies the system mode you want the tool to enter.

The Set System command specifies whether the tool enters the Setup or Translation mode.

Arguments

• Setup

A required literal that specifies for the tool to enter the Setup system mode from translation.By default LibComp invokes in the setup mode. Within this mode, you can open Veriloglibraries, select models for compilation, and setup options to control the compilationprocess. When you re-enter Setup mode from translation mode, the tool destroys anyexisting compiled network. When you leave Setup mode, the tool converts each addedmodel to a network. The tool also performs pre-compilation checks.

• Translation

A literal that specifies for the tool to enter the Translation mode from Setup mode. Whenyou enter Translation mode, the tool performs model checking for compilation.

Examples

The following example puts the tool in Translation mode.

set system mode translation

Related Commands

Add Model Run


Creating ATPG ModelsSet Partial Translation

August 2006

Set Partial TranslationScope: Setup mode

Usage

SET PArtial Translation ON | OFf

Description

Determines whether partial models or black boxes are output when unsupported Verilog isencountered.

By default, when unsupported Verilog constructs are encountered, LibComp outputs partialmodels. The partial models include the supported pieces of the construct, and the rest of themodel must be manually converted. For information on finding these partial models, see“Finding Unsupported Constructs in Partial Models”.

Arguments

• ON

A required literal that enables the partial translation during compilation runs. This is thedefault setting.

• OFf

A required literal that disables partial translation and outputs black boxes for models thatcontain unsupported Verilog during compilation runs.

Examples

The following example disables partial translation during compilation runs.

set verification off

Related Commands

Run

Creating ATPG ModelsSet Verification


Set VerificationScope: Setup mode

Usage

SET VErification ON | OFf

Description

Specifies whether the tool performs verification.

The Set Verification command specifies whether the tool performs verification on an ATPGlibrary generated from a Verilog file or directory during subsequent compilation runs. You mustexplicitly turn verification off in order for LibComp to not run verification (i.e. Set VerificationOff). This is most often done in a LibComp dofile.

NoteYou can run just the LibComp verification step with the lcVerify script. For moreinformation, see “Verifying ATPG Models”.

• ON

A required literal that enables verification during compilation runs. This is the defaultsetting.

• OFf

A required literal that disables verification during compilation runs.

Examples

The following example sets the tool to not perform verification during compilation runs.

set verification off

Related Commands

Run


Creating ATPG ModelsSystem

August 2006

SystemScope: All modes

Usage

SYStem os_command

Description

Passes the specified command to the operating system for execution.

The System command executes one operating system command without exiting the currentlyrunning application.

Arguments

• os_command

A required string that specifies any legal operating system command.

Examples

The following example displays the current working directory without exiting the tool:

system pwd

Creating ATPG ModelsWrite Library


Write LibraryScope: Translation mode

Prerequisite: You must perform a compilation run before you issue this command.

Usage

WRIte LIbrary filename [-Replace]

Description

Writes the ATPG library format models to a file.

The Write library command writes the ATPG models created during compilation to a specifiedfilename.

Arguments

• filename

A required string that specifies the name of the file to which the tool writes compiledmodels.

• -Replace

An optional switch that forces the tool to overwrite the compiled library file if a file by thatname already exists.

Examples

The following example compiles the models in the Verilog library vlib.v then saves thecompiled models to a file.

load library vlib.vadd model -allset system mode translationrunwrite library vlib.atpg -replace

Related Commands

Run


Creating ATPG ModelsWrite Library

August 2006


Chapter 6Verifying ATPG Models

This chapter describes how to verify ATPG libraries and provides a few guidelines to improvethe quality of your ATPG libraries. The specific topics covered in this chapter include:

Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Verification Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Running Verification from the Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Interpreting the Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Debugging Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Re-simulating Verilog Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Fixing DRC Violations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Improving Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Modeling for Optimal Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Verification OverviewATPG library verification consists of simulating and testing the library models and comparingthem with the Verilog source modules to confirm parallel functionality. When the functionalitydoes not match, the ATPG model fails verification, and the simulation mismatches are returnedfor the model.

ATPG libraries should be verified when they are generated with LibComp or when youmanually edit or add new models to an existing library.

By default, LibComp runs verification as it generates ATGP libraries. You can also runverification on an existing ATPG library from a UNIX/Linux shell.

A utility, lcVerify, performs the verification of the ATPG library as follows:

1. Uses FastScan to generate and simulate test patterns for the ATPG library.

2. Uses ModelSim® to simulate the Verilog source library using the same FastScan testpatterns.

3. Compares the simulation results of the ATPG library and the Verilog source and outputsa logfile detailing simulation mismatches and statistics you can use to improve thetestability and performance of the ATPG library.


Verifying ATPG ModelsVerification Prerequisites

August 2006

To ensure a robust ATPG library, you should correct all simulation mismatches and try to raisetest coverage to as close to 100% as possible.

You can set LibComp and lcVerify to use FlexTest for the verification as follows:

• LibComp — Use the Set Fastscan off command. For more information, see the SetFlextest command.

• lcVerify — Use the lcVerifyft command instead of the lcVerify command to runverification.

Verification Prerequisites• Verilog source library must be available.

• FastScan must be available.

• ModelSim® must be available.

• LibComp must be used to generate the initial ATPG library. LibComp generates setupfiles required by the lcVerify utility. The LibComp and lcVerify utilities used should befrom the same software release.

Running Verification from the ShellUse the following procedure to run verification from the UNIX/Linux shell.

1. Change to the directory containing the ATPG library. For example:

cd /network/dft_libs

2. Run the lcVerify utility. For example:

<mgcdft_tree>/bin/lcVerify my_dft_library.atpg my_verilog_source.v

Where:

my_dft_library.atpg is the ATPG library to verify.

my_verilog_source.v is the Verilog source library.

If the specified Verilog library contains multiple Verilog source files, you must includethe word null between the arguments. For example, if a library directory is namedmy_verilog_library, the shell command would be:

<mgcdft_tree>/bin/lcVerify my_dft_library.atpg null \my_verilog_library

The automated verification process takes over at this point. When the verificationfinishes, the shell transcript looks similar to the following:

Verifying ATPG ModelsInterpreting the Verification Results


shell> <mgcdft_tree>/bin/lcVerify my_dft_library.atpg \my_verilog_source.v

Running FastScanSimulating Designshell>

Interpreting the Verification ResultsThe verification process produces the following results files in the ATPG library parentdirectory:

• verify.results — Summary of the following key statistics for the run:

o Simulation mismatches — differences between the values FastScan simulated forthe ATPG library and the values simulated for the original Verilog library byModelSim®

o DRC violations

o Fault and test coverage

• sim.log — Full transcript of the FastScan and ModelSim runs

• transcript — Transcript of the ModelSim run

verify.results File ExampleYou should review this file first to identify ATPG models with low coverage, DRC violations,and simulation mismatches.

NoteThere are two metrics on the right side of the statistics -- first the collapsed statistics (coll)and then the full or total statistics (total). Only the (total) numbers should be used forcoverage assessment. The (total) numbers accurately reflect true coverage for singleinstances of smaller modules defined in libraries.

The following example shows the contents of a verify.results file.

Library Verification RunVerifying new.atpgRun at Mon Jul 24 22:34:58 2006

The following Models were BlackBoxed: dff_edge_table_posedge_no_controls_and_missing_x_terms

Summary Statistics for Library new.atpg---------------------------------------------------------Fault Statistics for Library new.atpg



August 2006

--------------------------------------------------------- #faults #faultsfault class (coll.) (total)----------------------- ------- -------FU (full) 232 476----------------------- ------- -------DS (det_simulation) 116 232DI (det_implication) 54 102PU (posdet_untestable) 1 2UU (unused) 4 8AU (atpg_untestable) 57 132----------------------- ------- -------Test Pattern Statistics for Library new.atpg---------------------------------------------------------test_coverage 74.56% 71.37%fault_coverage 73.28% 70.

---------------------Model : dff_edge_table_posedge_no_controls_but_x_termsFault Statistics for instancedff_edge_table_posedge_no_controls_but_x_terms--------------------------------------------------------- #faults #faultsfault class (coll.) (total)----------------------- ------- -------FU (full) 0 6----------------------- ------- -------DS (det_simulation) 0 5DI (det_implication) 0 1----------------------- ------- -------test_coverage 0.00% 100.00%fault_coverage 0.00% 100.00%atpg_effectiveness 0.00% 100.00%-------------------------------------------Test Pattern Statistics for instancedff_edge_table_posedge_no_controls_but_x_terms---------------------------------------------------------#test_patterns 67 #clock_sequential_patterns 67---------------------------------------------------------

---------------------Model : dff_posedge_dom_set_dom_reset_no_pessimism_termsFault Statistics for instancedff_posedge_dom_set_dom_reset_no_pessimism_terms--------------------------------------------------------- #faults #faultsfault class (coll.) (total)----------------------- ------- -------FU (full) 0 10----------------------- ------- -------DS (det_simulation) 0 5DI (det_implication) 0 3AU (atpg_untestable) 0 2----------------------- ------- -------test_coverage 0.00% 80.00%fault_coverage 0.00% 80.00%atpg_effectiveness 0.00% 100.00%



Test Pattern Statistics for instancedff_posedge_dom_set_dom_reset_no_pessimism_terms---------------------------------------------------------dff_posedge_dom_set_dom_reset_no_pessimism_terms#test_patterns 67---------------------------------------------------------

---------------------Model : dff_posedge_no_controls_no_pessimism_termsFault Statistics for instance dff_posedge_no_controls_no_pessimism_terms--------------------------------------------------------- #faults #faultsfault class (coll.) (total)----------------------- ------- -------FU (full) 0 6----------------------- ------- -------DS (det_simulation) 0 5DI (det_implication) 0 1----------------------- ------- -------test_coverage 0.00% 100.00%fault_coverage 0.00% 100.00%atpg_effectiveness 0.00% 100.00%-------------------------------------------Test Pattern Statistics for instancedff_posedge_no_controls_no_pessimism_terms---------------------------------------------------------#test_patterns 67 #clock_sequential_patterns 67---------------------------------------------------------

---------------------Model : dff_posedge_reset_only_no_pessimism_termsFault Statistics for instance dff_posedge_reset_only_no_pessimism_terms--------------------------------------------------------- #faults #faultsfault class (coll.) (total)----------------------- ------- -------FU (full) 0 8----------------------- ------- -------DS (det_simulation) 0 5DI (det_implication) 0 2AU (atpg_untestable) 0 1----------------------- ------- -------test_coverage 0.00% 87.50%fault_coverage 0.00% 87.50%atpg_effectiveness 0.00% 100.00%Test Pattern Statistics for instancedff_posedge_reset_only_no_pessimism_terms---------------------------------------------------------dff_posedge_reset_only_no_pessimism_terms#test_patterns 67---------------------------------------------------------

---------------------Model : dff_posedge_set_only_no_pessimism_termsFault Statistics for instance dff_posedge_set_only_no_pessimism_terms--------------------------------------------------------- #faults #faults


Verifying ATPG ModelsDebugging Models

August 2006

fault class (coll.) (total)----------------------- ------- -------FU (full) 0 8----------------------- ------- -------DS (det_simulation) 0 5DI (det_implication) 0 2AU (atpg_untestable) 0 1----------------------- ------- -------test_coverage 0.00% 87.50%fault_coverage 0.00% 87.50%atpg_effectiveness 0.00% 100.00%Test Pattern Statistics for instancedff_posedge_set_only_no_pessimism_terms---------------------------------------------------------dff_posedge_set_only_no_pessimism_terms#test_patterns 67---------------------------------------------------------

Key:--------------------------------------------------------- Value | Expected | Simulated-----------------+-------------+-------------------------Pessimistic Pass | X | Known ValueOptimistic Fail | Known Value | XHard Fail | Known Value | Different Known Value---------------------------------------------------------

Verification Detail-------------------------------------------

Verification Summary: 5 Total ModelsALL PASSED for all patterns.

Debugging ModelsBe aware that simulation mismatches can be caused by a number of errors.

Review the verify.results file and note the names of the models that failed verification and thecause of the failure, and then, use the information in the following table to debug the models.

Table 6-1. Debugging Models

Symptom Possible Solution

FastScan is unable to read a model. Fix the model or comment it out.

Duplicate modules in the Veriloglibrary.

Eliminate the duplicates or change their names.

Verifying ATPG ModelsRe-simulating Verilog Only


For more troubleshooting information, see the “Debugging Simulation Mismatches inFastScan” section in the Scan and ATPG Process Guide.

Re-simulating Verilog OnlyTo troubleshoot Verilog simulation issues, you can simulate just the Verilog portion of theverification with the <mgcdft_tree>/bin/ run_verify script. The run_verify script contains thecommands and arguments to perform just the ModelSim portion of verification.

See the following topics for more information on using run_veify to simulate the Verilog sourcelibrary:

• Prerequisites for Simulating Verilog Only

• Simulating Verilog Only

ModelSim compiler (vlog) cannotcompile a model.

This is usually due to a Verilog syntax error ormodeling issue. A transcript of the compiler’s run isrecorded in the sim.log file and typically containsenough information (line numbers and briefdescriptions of errors) for you to start debugging theVerilog.

The ModelSim simulator (vsim)cannot successfully load a model

This is usually due to a Verilog issue. Refer to thetranscript of the simulators run in the sim.log file fordebugging information. Check the vlog transcript toensure the model(s) compiled without errors; compileerrors will often result in load errors.

Verilog source is a Sequential UDPand the ATPG model is correct, butthe verification still fails.

The cause of the failure is very likely a missing addclocks definition for the clock input or a missing addpin constraint for a notifier input in the fastscan.do.catfile. Correct the definition in the fastscan.do.cat file andrerun verification.

Sequential Verilog UDP seems to be avalid Latch or DFF, but Libcompblack boxes it.

Search the LibComp transcript for HOLD CHECKmessages. The Hold Check message is output when aUDP modeling a latch or D Flip Flop fails to compilebecause of a minor error. When such a UDP isencountered, the HOLD CHECK message is output tothe transcript followed by a description of whatLibComp needs to successfully compile the model.

Table 6-1. Debugging Models

Symptom Possible Solution


Verifying ATPG ModelsFixing DRC Violations

August 2006

Prerequisites for Simulating Verilog OnlyThe following prerequisites must be satisfied before you can use run_verify to simulate theVerilog source library:

• ModelSim® must be available.

• lcVerify or run_fs must be run initially on the Verilog source and ATPG library. Formore information on run_fs, see “Assessing the Impact of Low Coverage”.

• Verilog source library must be available.

Simulating Verilog OnlyFrom the UNIX/Linux shell, run the run_verify script on the Verilog source library. Forexample:

shell> <mgcdft_tree>/bin/run_verify my_verilog_source.v

Where:


To save a transcript of the run_verify output, you must append a UNIX redirection operator (>)to the invocation command string, along with the name of the file in which to save the output.For example:

shell> <mgcdft_tree>/bin/run_verify my_lib.v >run_verify.log

Where:


> is a redirection operator that tells UNIX to save the output to a file.

run_verify.log is the file where the transcript is written.

Fixing DRC ViolationsYou can find detailed information about the DRC violations in your ATPG library in the sim.logfile. The sim.log file contains a transcript of the FastScan run including the DRC messages.These messages usually include a DRC identification number. Table 2-1 contains acomprehensive list of identifications numbers and detailed descriptions of each DRC.

You may decide a particular DRC violation is acceptable, but your decision should be based onan understanding of the violation and its effect on the testability of the model and the library.

Verifying ATPG ModelsImproving Test Coverage


Improving Test CoverageTest coverage loss due to ineffective models my hinder the test coverage for any design thatuses the library. A maximum attainable coverage for a design can only be achieved if a libraryhas maximum attainable coverage. It is normal for IO pad model coverage to be much lowerthan UDPs, so maximum attainable coverage is relative to the type of models being tested.

The results.verify file lists the overall fault statistics for the ATPG library. If the library wasgenerated using LibComp, V8.2003_1.10 or later, the results.verify file also lists the faultstatistics individually for each model in the library. In this case, the first step in troubleshootinglow coverage should be to determine from this list which models have less than desirablecoverage. For example, if most IO pad models have 40% to 60% coverage any models with only20% coverage would be suspect.

Troubleshooting One Model at a TimeAs an aid in troubleshooting, split out low coverage models into their own files. One way to dothis is to open the ATPG library in a text editor, and copy and paste each model description ofinterest into a new text editing window and save it as a file. Be sure to use a naming conventionfor the individual model files that indicates what each contains. For example,<model_name>.atpg. When each low coverage model is in its own file, you can focus yourtroubleshooting efforts on one model at a time.

Run FastScan on each model file in turn, using the same commands used in the earlier lcVerifyrun. The run_fs script, described in the next section, facilitates this process.

Assessing the Impact of Low CoverageIf you cannot raise coverage for a particular model in your library, use the UNIX grepcommand to find out how many instances of the model are used in your design(s). If there arerelatively few instances, the impact of the low coverage model on the design’s overall coveragemay be low enough to ignore.

Re-running the FastScan Portion of VerificationWhen troubleshooting coverage issues, you only need to run FastScan, not ModelSim. Therun_fs script is a utility, located in the <mgcdft_tree>/bin directory, that contains the necessaryFastScan invocation command and arguments to perform just the FastScan portion ofverification. This script saves you the time it takes to correctly type a longer invocationcommand string. It also results in shorter runtimes than with lcVerify because the ModelSimrun is eliminated.

To run FastScan on an ATPG library file named udp_dff.atpg, for example, you would enterthis command:


Verifying ATPG ModelsModeling for Optimal Test Coverage

August 2006

shell> <mgcdft_tree>/bin/run_fs udp_dff.atpg

FastScan must be available, and the ATPG library file and a copy of the fs.do.cat dofile mustexist in the invocation directory.

To save a transcript of the run_fs output, append a UNIX redirection operator (>) to theinvocation command string, along with the name of the file in which you want to save theoutput. To save the output of the preceding example to a file named run_fs.log, the invocationstring would look similar to this:

shell> <mgcdft_tree>/bin/run_fs udp_dff.atpg > run_fs.log

Modeling for Optimal Test CoverageTypically, you want to the test coverage to be as a high as possible. Also, the ATPG libraryshould not have any models that lcVerify is unable to process. See the following topics forrecommended practices to achieve high coverage, efficient ATPG models:

Handling Ignored or Blackboxed ModelsDue to the variety of design configurations possible with UDPs, there are UDPs that LibCompcannot process. Because black box outputs are tied to X, they generally result in some AU faultsduring ATPG.

To create valid models, you must manually convert UDP models that are blackboxed or ignoredby LibComp. For more information on creating ATPG models manually, see “Defining aModel”.

Anticipating the Effects of Internal Gating on ClocksBe aware, when you define clocks using the Add Clocks command, that the tool understands theoff state you specify to be the clock’s off value at a primary input to the model. If there is gatinglogic between this input and an instance within the model, take care that the off state youspecify produces the desired off state on the input to the internal instance after passing throughthe logic.


Chapter 7Using VHDL

Overview of VHDL SupportThe Mentor Graphics DFT products support a subset of the VHDL language by accepting aninput netlist written using the supported VHDL subset. DFTAdvisor, MBISTArchitect,LBISTArchitect, and BSDArchitect can additionally output a VHDL netlist.

The VHDL writer supports two possible flows. The first flow involves reading a VHDL netlistand writing another VHDL netlist. The second flow reads in a non-VHDL netlist and writes acorresponding VHDL netlist.

The VHDL language defines a strict rule that defines legal VHDL names:

In the first flow, the same rule applies to both the VHDL netlist read and the VHDL netlistwritten, therefore, the writer preserves the names read. However, for the second flow, someform of name translation is necessary since the written VHDL identifiers must conform to theVHDL syntactic rule. When a DFT tool needs to translate a name, it uses the following scheme:

The following are examples of how the DFT tools translate a non-legal character in an identifiername to legal VHDL characters:

• A non-legal character translates to the character’s hex representation escaped by anunderscore:

% ==> _xx (where, xx is the hex representation of %)

Table 7-1. Legal VHDL Identifier Names

Definition of Legal VHDL Identifier Name

A legal identifier must consist of:• Only digits, letters, and underscores

• Must start with a letter

• Cannot end with an underscore

• Cannot contain consecutive underscores

Table 7-2. DFT Translation of Legal VHDL Identifier Names

DFT Translation to Legal VHDL Identifier Names

Translate all non-legal characters to the character’s hexadecimal representationescaped by an underscore.


Using VHDLReading VHDL

August 2006

• A illegal trailing underscore character translates to 5F escaped by an underscore:

_ (underscore) ==> _5f)• An identifier which starts with a non-letter character is prepended with “V_V”.

Reading VHDLIn order for the VHDL netlist to be read, any packages referenced via a use clause must havetheir sources accessible to the VHDL reader. If every package referenced by the VHDL netlistis one of the following listed packages, then the VHDL reader will find the package sourceautomatically:

std.standardstd.textioieee.std_logic_1164ieee.std_logic_arithieee.std_logic_miscieee.std_logic_signedieee.std_logic_unsignedieee.numeric_bitieee.numeric_stdieee.std_logic_textioieee.vital_primitivesieee.vital_timingsynopsys.arithmeticsynopsys.attributessynopsys.types

The VHDL source for these standard packages are included in MGC Design-for-Test softwaretrees in the following location:

<mgcdft_tree>/mgc_home.<platform>/pkgs/dft.any/vhdl_src/...

where the software package extension, <platform>, is either hpu, ixl, iil, or ss5.

If custom packages are used, the source file must be made accessible by providing, in thecurrent working directory, either the source file or a link named <package_name>.vhd, or a filenamed “dft.map” which lists the source file pathname for each specified package. The dft.mapfile uses the format shown in Figure 7-1, where the first field is the name of the package, and thesecond field is the pathname to the VHDL source defining the package.

Figure 7-1. Example dft.map File

DFT tools support the following VHDL constructs when reading a VHDL netlist:

my_pkg /user/test_lib/my_pkg.vhd

Using VHDLWriting VHDL


• All the VHDL constructs that can possibly be generated by the VHDL writer asdescribed in “Writing VHDL” on page 305. These constructs have the same restrictionas stated for the writer.

• Context Clause: This can either be a library clause or a use clause, or both. You usethese clauses to define the initial name environment for a design unit. When the readerparses a library clause, it keeps track of all such logical library names. When a useclause is parsed, it specifies a package name.

If the package has not already been defined, the reader attempts to find and parse theVHDL source file containing the package. First, a dft.map file is searched, if present. Ifthe file specified for that package cannot be opened, the current working directory issearched for a file or link named <package_name>.vhd. If this also does not exist, andthe package is one of “standard”, “std_logic_1164”, or “std_logic_arith”, the parser willlook for the appropriate file in

<mgcdft_tree>/mgc_home.<platform>/pkgs/modeltech.any/vhdl_src

where the software package extension, <platform>, is either hpu, ixl, iil, or ss5. If nosuch file exists, the reader generates an error.

• Package Declaration: The package declaration must follow the IEEE STD 1076definition.

• Package Bodies: The package bodies must follow the IEEE STD 1076 definition.

If a package body is described inside the file read in by the VHDL reader, that packagebody is not written out in the output netlist generated by the VHDL writer. The packagereference is used in the output netlist. While reading this new (output) netlist, the VHDLreader will look for a VHDL file containing the package body, as described in theContext Clause bullet item.

You will need to ensure access to the source for this package in order to read the netlistwritten out by the VHDL writer.

• Scalar and composite types.

• Constant, signal, and variable object and interface type declarations.

• Signal and signal interface declarations can have any subtype indication.

• Port map aspects in component instantiation statements can either be named orpositional.

Writing VHDLDFT tools only generate the following VHDL constructs:

• Library clauses



August 2006

• Use clauses

• Entity Declarations

• Architecture Bodies

• Component Declarations

• Configuration Specifications

• Signal Declarations

• Component Instantiation Statements

• Conditional Signal Assignment Statements

The following paragraphs describe each of these VHDL constructs.

When writing out a VHDL netlist which originally was not read in as VHDL, the names for theentity, architecture, component, and instantiation labels must be constructed from the name ofthe HIE modules and/or instances. The following name construction scheme is followed:

• Names of entities correspond one-to-one to the HIE module names

• Names of architecture are always “dfta_arch”

• Names of components correspond, one-to-one, to the name of either the HIE modulename (for submodules) or the library model name (for library models)

• Instantiation labels use the name of the HIE instance

When writing out a VHDL netlist which originally was read in as VHDL, the names for theentity, architecture, component, and instantiation labels are preserved. In this case, no nameconstruct is necessary.

The VHDL writer generates a library clause and use clause pair prior to outputting an entitydeclaration and an architecture body. The outputted library and use clause take the followingform:

library ieee;use ieee.std_1164.all;

Furthermore, the following library and use clauses are implicit, and are present bydefault:

library std, work;use std.standard.all;

The VHDL writer only supports two VHDL design units. These design units are an entitydeclaration and a corresponding architecture body pair for each HIE module. The followingrestrictions apply when generating these two constructs:



• An entity declaration that the writer generates has an identifier name matching the nameof the HIE module unless the name is preserved from a read VHDL netlist. Within theentity header, the writer supports only a formal port clause for specifying the entity’sport interface list. Each element of this interface list is an interface signal declaration.The writer does not generate the optional keyword “SIGNAL” preceding the identifierlist of the interface signal declaration. Furthermore, the writer does not generate anyinitialization default static expression. The writer also does not generate the keyword“bus” used to specify a guarded interface signal declaration.

The subtype indications that the writer does support are either “std_ulogic” or“std_ulogic_vector”. If a VHDL netlist was read in, the writer preserves the originalsubtype indication outputs it as such.

The writer supports the IN, OUT, and INOUT port modes within an interface signaldeclaration The default port order by which an interface signal declaration is generatedfrom an HIE module is inputs first, followed by outputs, followed by io’s. The writerassumes the default port order unless an explicit port order is preserved from a readVHDL netlist. In the latter case, the pin order is generated accordingly.

Finally, the writer never generates an entity declarative part nor an entity statement part.

• An architecture body that the writer generates always has the fixed identifier name“dfta_arch”, unless the name is explicitly preserved from a read VHDL netlist. Withinthe architecture declarative part, the writer only allows the following VHDL constructs:component declaration, configuration specification, and signal declaration. Therestrictions on each of these constructs are described in separate list items below.

Within the architecture statement part, the writer only supports two types of concurrentstatements. These are the component instantiation statement and the concurrent signalassignment statement. Again, restriction on both of these constructs are described inseparate list items below:

• A component declaration is generated by the writer for each distinct componentinstantiation statement. This corresponds to the writer generating a single componentdeclaration for each type of an instance within an HIE module. This includes HIEinstances as well as library instances. The identifier name of the component declarationmatches the HIE module name of either an instantiated submodule or the library modelname of an instantiated library instance. If a VHDL netlist was read in, the writerpreserves the original identifier name of the component declaration.

Within a component declaration, the writer only supports a local port clause. Eachelement of the local port clause is an interface element. The writer only allows interfacesignal declarations as an element of the interface list. The same restriction as those forthe formal port clause of an entity declaration apply here. For an instantiated libraryinstance, the pin order of the generated local port clause will be the same as that for aninstantiated submodule (inputs, outputs, followed by io’s unless an explicit pin order ispreserved).



August 2006

• A configuration specification is generated by the writer for each component declarationof an HIE submodule. The writer does not generate a configuration specification for acomponent declaration of a library model. Since a single architecture body is associatedwith an entity declaration, within a configuration specification, the instantiation list ofthe component specification is always the reserved keyword “ALL”. The componentname matches that of the corresponding component declaration name. The bindingindication that the writer generates for a configuration specification is always in theform:

USE ENTITY <lib_name>.<entity_name>(<arch_name>).

The default library name is “WORK” unless explicitly preserved. The entity namematches the name of the HIE module, unless an explicit entity name is preserved. Thedefault architecture name is “dfta_arch” unless explicitly preserved.

• Multiple signal declarations are generated by the writer in an architecture body, onedeclaration for each internal net. The writer only generates signal declarations of thestd_ulogic or std_ulogic_vector subtypes, unless an explicit subtype is preserved. Theidentifier list of the signal declaration consists of a single identifier for each HIE internalnet of a module. The names of the signal identifiers match those of the HIE nets, unlessan explicit net name is preserved for an instantiated components.

• A component instantiation statement is generated by the writer for each instance of anHIE module within the architecture statement part for the module. The instantiationlabel of the statement matches the name of the HIE instance unless an explicit name ispreserved. The writer only supports one type of instantiation unit for the componentinstantiation statement. This is the component instantiated unit. The name of this unitmatches the name of the corresponding component declaration. The componentinstantiation statement that the writer generates may only have a port map aspect. Theport map aspect is a list of port associations. Each element of this list must be of theform: <formal_part> => <actual_part>. This means that the writer always generates thenamed (as opposed to positional) association. For the formal_part, the writer allows onlyformal port name designators. The name of such port is the corresponding pin name ofthe instantiated submodule or library model as stated in the port interface list of thecomponent declaration. For the actual_part, the writer allows only signal names (thisincludes explicitly declared signals or the formal port names of the module’s entitydeclaration).

• Since VHDL disallows the connection of a signal, which corresponds to an output of amodule port to another signal which corresponds to an input of an instantiatedcomponent, concurrent signal assignments are required to connect an intermediatesignal to the output of the module. Only the very simplest form of conditional signalassignment is ever generated by the writer. The form of such a signal assignment is:

<target> <= <intermediate_signal_name>



The name of the target corresponds to the name of the output pin of the module, whilethe name of the intermediate signal is by default <output module pin name>_int. Thisscheme has been adopted uniformly for every module output pin, regardless of whetherit connects to an instantiated instance input (for example, for every module’s output pin,the writer generates a signal assignment to the output from an internal signal).

The writer does not support any form of intelligent logical to physical filename mapping. AllVHDL clauses and design units are written to the file specified by the Write Netlist command.



August 2006


Chapter 8Test Procedure File

OverviewThis chapter shows you how to write test procedure files, which describe the scan circuitryoperation within a design for the ATPG tool. Test procedure files contain cycle-basedprocedures and timing definitions that tell the DFT tools how to operate the scan structureswithin a design. You specify scan circuitry operation using previously-defined scan clocks andother control signals. In order to utilize the scan circuitry in your design, you must define thescan circuitry for the tool and provide a test procedure file to describe its operation. The designrules checking (DRC) process, which occurs when you exit Setup mode, performs extensivechecking to ensure the scan circuitry operates correctly. Once the scan circuitry operation(specified by the test procedure file) passes DRC, other FastScan, FlexTest, and TestKompressprocesses assume the scan circuitry works properly.

After it inserts scan circuitry, DFTAdvisor can create test procedure files that you can use withFastScan, FlexTest, and TestKompress. If your design contains scan circuitry, and if you havenot already created a test procedure file, either by hand or by using DFTAdvisor, you must do sobefore running ATPG with FastScan, FlexTest, or TestKompress. The following subsectionsdescribe the syntax and rules of test procedure files, give examples for the various types of scanarchitectures, and outline the checking that determines whether the circuitry is operatingcorrectly.

To specify a test procedure file in setup mode, use the Add Scan Groups command. The toolscan also read in procedure files by using the Read Procfile command or the Save Patternscommand when not in Setup mode. When you load more than one test procedure file, the toolmerges the timing and procedure data.

You can also have the stil2mgc tool translate STIL Test Procedure (STP) files into FastScan,FlexTest, and DFTAdvisor dofiles and test procedure files. This tool produces a dofile, whichdefines clocks, scan chains, scan groups, and pin constraints. This tool also creates testprocedure files with a timeplate and the following standard scan procedures — test_setup,load_unload, and shift. For more information on this command, refer to the stil2mgc referencepage in the ATPG and Failure Diagnosis Tools Reference Manual.

Procedure File SyntaxThe following text describes the syntax of the test procedure file. Bold words denote keywords.Italicized words denote lexical elements such as identifiers, strings, or numbers. Plain words aresyntax rules, which are further described. Rules consist of the rule name, followed by a colon,


Test Procedure FileProcedure File Syntax

August 2006

and then the syntax elements of the rule. The rule ends with a semicolon. A ‘|’ character standsfor “or”.

Square brackets denote optional elements. Square brackets followed by “...” denote lists. Listsof one or more have the first element outside the square brackets. Lists of zero or more have thefirst element within the square brackets.

If you have a pin or pathname that uses a reserved punctuation character, you must enclose thatname in double quotes. For example, the following statement is illegal because it uses theexclamation point outside of double quotes.

force /inst_my_adder_1/xclk_header!x1!x1/op1[9] 1

The signal name contains a reserved punctuation character, the exclamation point (!), so it mustbe enclosed inside double quotes. The correct syntax would be:

force "/inst_my_adder_1/xclk_header!x1!x1/op1[9]" 1

The list of reserved punctuation characters follows:

NoteNot all procedure statements are valid in all procedures. The Vector Interfaces codeaccepts the syntax specified below, but the rules checking code only allows theappropriate procedure statements in particular procedures.

Throughout the following sections, value = 0, 1, X, or Z.

Table 8-1. Reserved Punctuation Characters

Name Character

Ampersand/AND &

Carot/Circumflex/XOR ^

Comma ,

Equals =

Exclamation mark !

Left/Opening brace {

Left/Opening parenthesis (

Right/Closing brace }

Right/Closing parenthesis )

Semicolon ;

Vertical bar/OR |



Introductory Procedure File ExampleThe following is an example of a simple test procedure file. For more complex examples, seethe “Procedure File Examples” section.

Figure 8-1. Procedure File Example

//// Comments use “//” characters//

// Set the base time increment for use in all timeplatesset time scale 1.0 ns;

// Define the strobe time for the measure statementsset strobe_window time 1;

// This design uses a single timeplate, named “tp1”, for all// vectors.

timeplate tp1 = force_pi 0; measure_po 1; pulse CLK0_7 2 1; pulse CLK8_15 2 1; period 4;end;

// The shift and load_unload procedures define how the design// must be configured to allow shifting data through the scan// chains. The procedures define the timeplate that will be// used and the scan group that it will reference.

procedure shift = scan_group grp1; timeplate tp1; cycle = force_sci; measure_sco; pulse CLK8_15; pulse CLK0_7; end;end;



August 2006

Procedure FileThe procedure file has the following format:

#include “<file_name>”;[set_statement ...][alias_definition ...][timing_variables ...]timeplate_definition [timeplate_definition]procedure_definition [procedure_definition]

#include StatementThe “#include” statement results in test procedure data being read from the file specified by thisstatement. All timeplates and procedure rules apply to the statements placed in #include files.Included files may use the “#include” statement to include other files, up to a maximum includedepth of 512. If the “Write Procfile” command is used later in the tool to write out proceduredata, the “#include” statements are not preserved, and all procedure data will be written to asingle file.

This feature is utilized by adding the “#include” statement to the syntax of the procedure file.The file name to be included must be enclosed in double quotes, and the statement must be

procedure load_unload = scan_group grp1; timeplate tp1; cycle= force CLEAR 0; force CLK0_7 0; force CLK8_15 0; force scen1 1; end; apply shift 8;end;

// The capture procedure is a "non-scan" procedure. This// procedure describes the timeplate that will be used for the// capture cycle. It also defines the number of cycles that// will be used in the capture cycle. In this example there is// just one cycle.

procedure capture =timeplate tp1; cycle = force_pi; measure_po; pulse_capture_clock; end;end;

Figure 8-1. Procedure File Example (cont.)



followed by a semicolon. The “#include” statement can occur anywhere in the file, and multiple“#include” statements can occur in one file. Example:

#include "foo.proc";

Set StatementThe Set statement defines specific parameters used throughout the procedure file. There arethree available Set statements: Set Time Scale, Set Strobe_window Time, and SetDefault_timeplate. You must specify the Set Time Scale and Set Strobe_window Timestatements at the beginning of the procedure file before any timeplate and procedure definitions.You can only specify the Set Default_timeplate statement after the timeplate that is referenced.Set statements have the following format:

set set_type;

The following list contains available set_type statements. Not all are required.

set_type:time scale tscale;strobe_window time window_width;default_timeplate timeplate_name;

• time scale tscaleA literal and string that sets the time scale and unit. The tool applies the time scale andunit you specify to the test procedure file and timeplates. If you do not specify the timescale, the default value is 1 ns.

The value you specify for the time scale can be a real number. Time values in thetimeplate, however, must be integers. If you find you are specifying fractional times inthe timeplate, you must reduce the time scale unit so you can specify integer time valuesin the timeplate. For example, the following would result in a syntax error:

set time scale 1 ns ;set strobe_window time 1 ;

timeplate fast_clk_tp = force_pi 0 ; measure_po 0.500 ; pulse CLKA 0.750 1.50 ; pulse CLKB 0.750 1.50 ; period 3.000 ; end ;

To correct the syntax, you could change the time scale to picoseconds, and adjust thetime value to meet the scale as follows:

set time scale 10 ps ;set strobe_window time 1 ;

timeplate fast_clk_tp =



August 2006

force_pi 0 ; measure_po 50 ; pulse CLKA 75 150 ; pulse CLKB 75 150 ; period 300 ; end ;

FastScan and TestKompress translate the time scale in the procedure file into a Verilog’timescale directive in the Verilog testbench they write out when you save patterns inVerilog format. If the time scale number you specify in the test procedure file is one orlarger, the Verilog ’timescale directive will specify the same time unit and timeprecision. If the time scale number in the procedure file is less than one, the timeprecision in the ’timescale directive will be adjusted to fit the true time scale. Forexample, “set time scale 1 ns ;” would result in this Verilog ’timescale directive:

‘timescale 1ns / 1ns

whereas “set time scale 0.5 ns ;” would produce:

‘timescale 1ns / 100ps

NoteIf you specify multiple procedure files, the Set Time Scale statement will not necessarilyspecify the same time scale in all procedure files.

• strobe_window time window_widthA literal and integer string that specifies the strobe-window width. Some tester formatsmeasure primary outputs (POs) at the exact time that you specify with the measure_postatement in the timeplate. However, other tester formats, such as UTIC, require thatoutput measurements occur during a specified window of time (window_width). Youcan set this strobe window using the Set Strobe_window Time command.

A strobe window can only stretch from the measure_po time to the end of the cycle orthe next force or pulse event. For example, if you issue a measure_po at time 10 and therising edge of a pulse at time 30, the strobe window can only be a maximum of 20.Strobe_window lets you know that, starting at the measure_po time, the primary outputshould be stable for the time specified by the strobe window.

If you do not specify the strobe_window time, it will default to the maximum allowablesize. For example, if you look at a timeplate, and if there is a 10 ns window between themeasure_po event and the next event (or end of timeplate), then that is what the strobewindow will be. If there are multiple timeplates, then the smallest strobe window fromthe timeplates is the maximum allowable strobe window.

NoteFor some formats, such as WGL, this command changes the strobe window in the outputfile.



NoteStrobe_window only affects the following formats: STIL, Utic, TSTL2, WGL, andZycad.

• default_timeplate timeplate_nameA literal and string pair that specifies a timeplate that can be used for any proceduredefinition that does not explicitly specify a timeplate.

Example:

set time scale 1.0 ns;set strobe_window time 100;

Alias DefinitionThe Alias definition groups multiple signal names or cell paths into a single alias name. SignalAlias statements are useful in procedures or timeplates where multiple signals need to beassigned to the same value at the same time. Cell Alias statements are used to group cell pathsinto a single alias name. You must define aliases before using them. The definition can occur atany place in the procedure file outside of a timeplate or procedure definition.

In using a cell Alias statement to group cell paths from condition statements into a single aliasname, it is possible to override a condition statement in a named capture procedure with asubsequent condition statement that occurs in the same place (global condition, or local to aspecific cycle). A condition statement can only override a previous condition if the firstcondition is specific using an alias name, and if the second condition is specified without usingan Alias statement.

NoteWhen using multiple named capture procedures where each procedure requires manycondition statements, it is helpful to group cells into a common name and apply thecondition statement once to the entire group of cells, and then override specific cells thatneed a different value than what was applied to the group. This frees you from having toenter numerous condition statements for each named capture procedure, while only ahandful of the cells require different values for each procedure.

The Alias definition has the following format:

alias alias_name = pin_name [, pin_name ...];

or

alias alias_name = cell_name [, cell_name ...];

• alias_nameA string that specifies the name of the alias.



August 2006

• pin_nameA repeatable string that specifies the pin name to associate with the alias name.

• cell_nameA repeatable string that specifies the cell name to associate with the alias name.

Examples:

This example groups two signal names into a single alias name.

alias my_group = T, U;

This next example shows how a named capture procedure should look when using an Aliasstatement for condition cells. The example sets each of four cells to a value of 0, and then thefourth cell (/inst_3/blockb/reg_2/Q) is overridden with a value of 1.

alias cond_cells = "/inst_0/blocka/reg_1/Q", "/inst_1/blocka/reg_1/Q","/inst_2/blocka/reg_1/Q", "/inst_3/blockb/reg_2/Q";

timeplate tp1 =force_pi 0;measure_po 10;pulse ref_clk 50 50;period 100;

end;procedure capture capture1 =

timeplate tp1;condition cond_cells 0;condition /inst_3/blockb/reg_2/Q 1;

// overrides condition in previous statementcycle =

force scan_en 0;force ctrl_a 1;force_pi;pulse ref_clk;

end;cycle =

force_pi;measure_po;pulse ref_clk;

end;end;

Timing VariablesTwo timing variable block definitions allow timing to be expressed using variables andequations in the procedure file, and to have this equation-based timing preserved in the tool andreproduced in the correct syntax in pattern output files.

Test data languages such as WGL and STIL have the ability to express time values in the timingblocks, as numerical values or as equations based on variables. Using equation-based timingallows one value to be specified for a global attribute, such as the test cycle period, while othervalues are derived from this using equations.



The two timing block definitions are called “timing_variables” and “variables”. In the“timing_variables” block, variables can be defined and assigned timing values. These valueswill be expressed in the time scale which is already specified by the Set Time Scale statement.The “timing_variables” block must be defined before the timeplate definitions.

The “variables” block is used to define variables that are not time values and have no unitsassociated with them. These variables can only be assigned integer numbers, and can be used asscaling multipliers in the timing equations.

The variables in the “timing_variables” block can also be assigned timing equations instead oftime values. These equations are simple mathematical equations which can use either timingvalues or previously defined variables or timing variables as operands.

NoteThe event statements in the timeplate definition block accept timing values and timingvariables.

When saving patterns in the WGL and STIL supported formats, the waveform tables in theseformats will be written using the equations and variables, and the variables will be defined inthe appropriate definition blocks which exist in each format. When saving patterns in formatsthat don’t support equation-based timing, the equations will be computed and the timinginformation will be specified as the resulting numeric values in the pattern file. Setting theALL_FLATTEN_TIMING parameter file keyword to 1 will cause WGL and STIL outputs tocompute the timing equations and use only the resulting numeric values in the output files. Anyequation that does not compute to an integer value will be rounded to the nearest integer value.

The “timing_variables” block has the following syntax:

variables =variable_name = integer;[variable_name = integer; ...]

end;

timing_variables =variable_name = time_or_equation;[variable_name = time_or_equation; ...]

end;

Note that time_or_equation can either be an integer time value or a time equation. A timeequation is expressed using operators and operands. An operator is one of +, -, *, or /. Anoperand can be a time value or a variable name (time or scaling variable). The multiplicationand division operators (* and /) take precedence over the addition and subtraction operators (+and -). Parenthesis can be used to group operations for precedence.



August 2006

NoteIn the timeplate definitions, any place where a time value can be used, a timing variable isalso allowed. A scaling variable from the “variables” block cannot be used in a timeplatedefinition. These can only be used in time equations.

Variable names can be any identifier except for reserved keywords used in the procedure filesyntax (such as “period” and “force_pi”). The variable names must conform to the rules thatapply to all identifiers used in the procedure file (alpha numeric string, starting with an alphacharacter, and no reserved punctuation marks). If reserved characters or reserved words are usedin a variable name, the name must be enclosed in quotes.

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

set time scale 1.0 ns;variables =

v_scale = 1;end;

timing_variables =t_period = 100;t_force = 0;t_meas = ((t_period * 0.1) * v_scale );t_rise = ((t_period / 2) * v_scale );t_width = ((t_period * 0.2) * v_scale);

end;

timeplate tp1 =force_pi t_force;measure_po t_meas;pulse ref_clk t_rise t_width;period t_period;

end;

This is how the timing example above would be represented in the STIL output:

Spec STUCK_spec {Category STUCK_cat {

v_scale = ’1’;t_period = ’100ns’;t_force = ’0ns’;t_meas = ’(t_period*0.1)*v_scale’;t_rise = ’(t_period/2)*v_scale’;t_width = ’(t_period*0.2)*v_scale;

}}

Timing STUCK_timing {WaveformTable tset_tp1 {

Period ’t_period’;Waveforms {

input_time_gen_0 { 01 { ’t_force’ D/U; }}



input_time_gen_1 { 01 { ’0ns’ D; ’t_rise’ D/U;’t_rise+t_width’ D;}}

_po_ { LHX { ’0ns’ X; ’t_meas’ l/h/x; ’t_rise’ X;}}}

}}

This is how the timing example would be represented in the WGL output:

equationsheet STUCK_sheetexprset STUCK_set

v_scale := 1.0;t_period := 100nS;t_force := 0nS;t_meas := (t_period * 0.1) * v_scale;t_rise := (t_period / 2) * v_scale;t_width := (t_period * 0.2) * v_scale;_tp1_fall_1 := t_rise + t_width;

endend

timeplate tp1 period t_period"input_a" := input [t_force:S];..."output_z" := output[0nS:X, t_meas:Q, t_rise:X];..."refclk" := input[0nS:D, t_rise:S, _tp1_fall_1:D];

end

Timeplate DefinitionThe timeplate definition describes a single tester cycle and specifies where in that cycle allevent edges are placed. You must define all timeplates before they are referenced. A procedurefile must have at least one timeplate definition. The timeplate definition has the followingformat:

timeplate timeplate_name =timeplate_statement[timeplate_statement ...]period time;end;

The following list contains available timeplate_statement statements. The timeplate definitionshould contain at least the force_pi and measure_po statements.

NoteYou are not required to include pulse statements for the clocks. But if you do not “pulse”any of the clocks, the Vector Interfaces code uses two cycles to pulse a clock, resulting inlarger patterns.

timeplate_statement:offstate pin_name off_state;



August 2006

force_pi time;bidi_force_pi time;measure_po time;bidi_measure_po time;force pin_name time;measure pin_name time;pulse pin_name time width;double_pulse pin_name time1 width1 time2 width2;

NoteIn “timeplate_statement” definitions, timing_variables can be used instead of time values.See the Timing Variables section for more information.

• timeplate_nameA string that specifies the name of the timeplate.

• offstate pin_name off_stateA literal and double string that specifies the inactive, off-state value (0 or 1) for aspecific named primary input pin that will be pulsed within this timeplate but is notdefined as a clock pin by the Add Clocks command. This statement must occur beforeall other timeplate_statement statements. This statement is required for any pin that isnot defined as a clock pin by the Add Clocks command but will be pulsed within thistimeplate.

NoteAn “offstate” statement does not automatically force pin_name to its off state at time 0.For that to occur, you must force or pulse pin_name appropriately in a procedure.

• force_pi timeA literal and string pair that specifies the force time for all primary inputs.

• bidi_force_pi timeA literal and string pair that specifies the force time for all bidirectional pins. Thisstatement allows the bi-directional pins to be forced after applying the tri-state controlsignal, so the system avoids bus contention. This statement overrides “force_pi” and“measure_po”.

• measure_po timeA literal and string pair that specifies the time at which the tool measures (or strobes) theprimary outputs.

• bidi_measure_po timeA literal and string pair that specifies the time at which the tool measures (or strobes) thebidirectional pins. This statement overrides “force_pi” and “measure_po”.

• force pin_name timeA literal and double string that specifies the force time for a specific named pin.



NoteThis force time overrides the force time specified in force_pi for this specific pin.

• measure pin_name timeA literal and double string that specifies the measure time for a specific named pin.

NoteThis measure time overrides the measure time specified in measure_po for this specificpin.

• pulse pin_name time widthA literal and triple string that specifies the pulse timing for a specific named pin. Thetime value specifies the leading edge of the pulse and the width value specifies the widthof the pulse. This statement can only reference two kinds of pins:

o Pins defined as clock pins by the Add Clocks command.

o Pins not defined as clock pins by the Add Clocks command but which do provide apulse signal and have an offstate specified by the “offstate” statement.

The sum of the time and width must be less than the period.

• double_pulse pin_name time1 width1 time2 width2A literal and quintuple string that specifies a double pulse waveform for a specificnamed clock pin. The time values time1 and time2 are the offsets to the leading edge ofeach pulse. The time values width1 and width2 are the widths of the two pulses. Thisstatement can only reference pins that have been declared as clocks by the Add Clockcommand or pins that have an offstate specified by the “offstate” statement. Thecomplex timeplates are most useful in the shift procedure where a non-clock pin needsto be pulsed while still maintaining a single cycle in the shift procedure.

NoteSome of the ASICVector Interfaces output formats are not able to support a double pulsein the waveform or timing definitions for a pin. If you try to save patterns that use atimeplate with a double_pulse statement in one these output formats, an error messagewill be issued. Currently, the double_pulse statement is supported in these outputformats: Verilog, VHDL, WGL, STIL, and TSTL2.

• period timeA literal and string pair that defines the period of a tester cycle. This statement ensuresthat the cycle contains sufficient time, after the last force event, for the circuit tostabilize. The time you specify should be greater than or equal to the final event time.



August 2006

Example 1timeplate tp1 =

force_pi 0;pulse T 30 30;pulse R 30 30;measure_po 90;period 100;

end;

Example 2The following example shows a shift procedure that pulses b_clk with an off-state value of 0.The timeplate tp_shift defines the off-state for pin b_clk. The b_clk pin is not declared as aclock in the ATPG tool.

timeplate tp_shift =offstate b_clk 0;force_pi 0;measure_po 10;pulse clk 50 30;pulse b_clk 140 50;period 200;

end;

procedure shift =timeplate tp_shift;cycle =

force_sci;measure_sco;pulse clk;pulse b_clk;

end;end;

Example 3In the following example, the pin b_clk is not declared as a clock in the ATPG tool. However, inthe shift procedure, the user needs the pin to be pulsed twice with an offstate of ‘0’.

timeplate tp_shift =offstate b_clk 0;force_pi 0;measure_po 10;pulse clk 50 30;double_pulse b_clk 40 50 140 50;period 200;

end;

procedure shift =timeplate tp_shift;cycle =

force_sci;measure_sco;



pulse clk;pulse b_clk;

end;end;

Procedure DefinitionThe procedure definition is the heart of the procedure file. The procedure defines precisely howthe scan circuitry operates. All procedure definitions contain one or more cycle definitions.Each cycle definition in the procedure specifies a vector; each statement in the cycle specifieswhich events occur in that vector. The timeplate being used specifies any timing associated withthat vector. The following is a list of rules for writing procedure definitions:

• If more than one timeplate is defined, you can assign a specific timeplate for eachprocedure definition or for each cycle within the procedure definitions. You must assigna timeplate at some point within a procedure definition.

• You must group all procedure statements, except scan_group, timeplate, and apply, intocycle statements.

• You cannot specify time values in cycle statements.

• The order of events within a cycle definition does not matter. The assigned timeplatespecifies the order.

• Within a procedure definition, you can specify a scan group.

• Each scan group needs a unique test procedure file. You associate the test procedure filewith the scan group when you specify the Add Scan Group command.

• Text following “//” is a comment and is ignored.

• You can include blank lines.

• You define a procedure type for a particular scan group (with the exception of theseq_transparent and clock procedures) only once in a test procedure file.

• You can only have a single test_setup procedure, even if you define multiple scangroups for your design.

The procedure definition has the following format:

procedure procedure_type [proc_name] =[scan_group scan_group_name;]proc_statement [proc_statement ...]

end;

proc_statement:[timeplate timeplate_name;]cycle =

cycle_statement [cycle_statement ...]



August 2006

end;apply proc_name #times;

cycle_statement:force_pi;bidi_force_pi;force_sci;force_sci_equiv;measure_po;bidi_measure_po;measure_sco;restore_pi;restore_bidi;bidi_force_off;pulse_capture_clock;pulse_read_clock;pulse_write_clock;force pin_name value;expect pin_name value;condition cell_name value;measure pin_name;measure_misr lfsr_name pin_name;initialize instance_name [value];pulse pin_name;timeplate timeplate_name;

• procedure_typeA string that specifies the type of procedure that follows. The following list containsvalid procedures types:

For more information, refer to “The Procedures” section.

• proc_nameAn optional string that specifies the user-defined name of the procedure. Since you canspecify multiple seq_transparent and clock procedures in a test procedure file, theseprocedure types require explicit procedure names, proc_name, for each procedure thatyou define.

o test_setup o capture

o shift o clock_po

o load_unload o ram_sequential

o shadow_control o ram_passthru

o master_observe o clock_sequential

o shadow_observe o init_force

o seq_transparent o test_end

o clock o sequential

o skew_load o sub_procedure



• scan_group scan_group_nameA literal and string pair that specifies a scan group within a scan procedure. Since someof the scan procedures are scan group specific, you can specify scan groups within scanprocedures. This makes it possible to define the scan procedures (shift, load_unload) formultiple scan groups within the same procedure file. You can then specify this file onthe Add Scan Groups command for each scan group in this file. If you use the ReadProcfile command to read a procedure file, you must include this statement. However, ifyou use the Add Scan Groups command, this statement is optional since the group isspecified on the command line. When the tool writes out a procedure file, it produces thescan_group statement.

NoteThe scan_group_name argument is case-sensitive if the netlist used is case-sensitive.

• timeplate timeplate_nameA literal and string pair that specifies the name of the timeplate the procedure uses.

A timeplate statement at the beginning of the procedure, outside of the cycle definitions,is the timeplate used by the entire procedure, if no other timeplates are referenced.

A timeplate statement within a cycle is the timeplate used for that cycle and all othersubsequent cycles until another timeplate statement is encountered.

• apply proc_name #timesA literal and double-argument string that tells the tool to apply the specified procedurethe specified number of times. You must use the apply shift statement at least once in theload_unload procedure. For the apply shift statement, you should enter a proper #timesparameter, otherwise you will get a warning message.

If required, you must enter the apply shadow_control statement immediately after theapply shift procedure statement, and you must set the #times argument to 1. The applystatement is only valid outside of the cycle blocks because it specifies another group ofcycles within another procedure to be added at that point.

The following list describes valid cycle_statement commands. Cycle_statements may notcontain time values.

• force_piA literal that specifies for the tool to force all primary inputs.

• bidi_force_piA literal that specifies for the tool to force all bidirectional pins.

• force_sciA literal that specifies for the tool, in the shift procedure, to place values on the scanchain inputs, thus implementing scan cell controllability.



August 2006

• force_sci_equivA literal that acts the same as the force_sci statement, except that it also forces all pinsequivalent to the scan input pins. Using this statement places the complement value onthe associated differential pin of a scan input during scan loading. This statement isnecessary because the test procedures do not consider pin equivalence relationships(those specified with Add Pin Equivalence).

• measure_poA literal that specifies for the tool to measure or strobe the primary outputs.

• bidi_measure_poA literal that specifies for the tool to measure or strobe the bidirectional pins.

• measure_scoA literal that specifies for the tool, in the shift procedure, to measure scan output values,thus implementing scan cell observability. In End Measure Mode, see “Automatic EndMeasure Mode” on page 362, measure_sco is also used in the load_unload procedure.

• restore_piA literal that returns primary inputs to their original states (prior to this procedure’sexecution). You use the restore_pi statement at the end of a seq_transparent procedure.

• restore_bidiA literal that returns bidirectional pins to their original states (prior to this procedure’sexecution). You use the restore_bidi statement at the end of a clock procedure.

• bidi_force_offA literal that specifies for the tool to force all unconstrained bidirectional pins off.

• pulse_capture_clockA literal that specifies for the tool to pulse the capture clock.

• pulse_read_clockA literal that specifies for the tool to pulse the RAM read clock.

• pulse_write_clockA literal that specifies for the tool to pulse the RAM write clock.

• force pin_name valueA literal and double string that forces the specified value of 0, 1, X, or Z on the specifiedpin. The pin names you specify must be valid pin pathnames for primary inputs.

• expect pin_name valueA literal and double string that causes the tool to expect the specified value of 0, 1, X, orZ on the specified pin. The pin names you specify must be valid pin pathnames forprimary outputs.

• condition cell_name valueA literal and double string that you use at the beginning of a seq_transparent procedureto identify the necessary scan cell states (conditions) to establish transparency in non-

Test Procedure FileThe Procedures


scan cells. For more information on transparency, refer to “FastScan Handling of Non-Scan Cells” in the Scan and ATPG Process Guide. You identify the scan cell by the pinpathname associated with the output of its state element. The path from the defined pinto the scan cell must only contain buffers and inverters. The value argument sets thevalue at the specified pin pathname, which may be inverted relative to the associatedscan cell value.

• measure pin_nameA literal and string pair that specifies for the tool to measure the value of the named pin.

• measure_misr lfsr_name pin_nameA literal and double string pair that specifies the pin onto which the final signature of aspecified MISR is to be shifted out.

• initialize instance_name valueA literal and string pair that initializes the named memory element to the value given.This statement is particularly useful for initializing the finite state machine in the TAPcontroller of boundary scan circuitry, when the TAP does not contain the TRST signal.Once set to a binary state, the TCK and TMS pins can place the finite state machine in adesired state. If not set, these pins remain at X.

If you do not specify a value, the tool chooses a random value to assign to all latches andflip-flops with the specified instance name.

• pulse pin_nameA literal and string pair that specifies for the tool to pulse the named clock pin.

• observe_method valueA literal and string pair set to a value of master, slave, or shadow, to specify for aspecific observe method to be defined for each named capture procedure.

Example:

procedure shift =scan_group grp1;timeplate tp1;cycle =

force_sci;measure_sco;pulse T;

end;end;

The ProceduresThe following sections describe the test procedures that comprise a test procedure file. Allexample procedures shown in the following sections use one of the following timeplates:

timeplate tp1 =force_pi 0;measure_po 10;



August 2006

pulse scan_clk 30 10;pulse sys_clk 30 10;period 50;

end;

timeplate tp2 =force_pi 0;measure_po 10;pulse scan_mclk 15 10;pulse scan_sclk 30 10;period 50;

end;

timeplate tp3 =force_pi 0;measure_po 10;pulse clk1 20 10;pulse clk2 20 10;period 40;

end;

Scan and Clock ProceduresThe following sections describe the various scan and clock-related procedures available. Theseprocedures inform the tool how to operate the scan chain and pulse clocks.

Test_Setup (Optional)This optional procedure, which may only contain force, pulse, init, and expect event statements,sets non-scan elements to the desired states for the load_unload procedure. You may use thisprocedure only once for all scan groups, and it appears only once at the beginning of the testpattern set.

This procedure is particularly useful for initializing boundary scan circuitry. For an exampleusing this procedure to set up boundary scan circuitry, refer to “Generating Patterns for aBoundary Scan Circuit” in the Scan and ATPG Process Guide.

If a scan out pin is bidirectional, you must force its value to the Z state (indicating it is operatingin “output” mode) to properly sensitize the scan chain.



NoteIf you use the Add Pin Constraint command to set pin constraints, be aware thiscommand only forces pins during test generation. To constrain these pins duringtest_setup, you should include the same pin constraints in the test_setup procedure. Thiswill ensure the pins are in the same state for loading the first pattern as for loading allsubsequent patterns.

If you do not properly constrain the pins prior to the end of the test_setup procedure, thetool automatically does this for you. However, the tool’s automatic handling may notinsert the events with the timing you want. Also, the automatic handling is not included inDRC. To see exactly how the events are added to the test_setup procedure, use theReport Procedure or the Write Procfile command

Shift (Required)This required procedure describes how to shift data one position down the scan chain bytoggling the clock(s), forcing the scan input, and strobing the scan output. Figure 8-2 shows thedata flow process for the shift procedure.

Figure 8-2. Shift Procedure

Within this procedure, you must use the force_sci, or force_sci_equiv, and the measure_scoevent statements. You can also use the force and pulse event statements. A shift procedure isrestricted to contain only one cycle. The times at which the timeplate used by the shiftprocedure applies the force_sci and measure_sco commands must allow proper operation of theload_unload process.

The following list shows examples of the shift procedure for both the mux-DFF and LSSDarchitectures:

• Mux-DFF

procedure shift =timeplate tp1;cycle =

// force scan chain inputforce_sci;// measure scan chain outputmeasure_sco;// pulse the scan clockpulse scan_clk;

end;

ScanCellsc_in sc_out

data transfer



August 2006

end;

• LSSD

procedure shift =timeplate tp2;cycle =

// force scan chain inputforce_sci;// measure scan chain outputmeasure_sco;// pulse master clockpulse scan_mclk;// pulse slave clockpulse scan_sclk;

end;end;

Figure 8-3 graphically displays the waveforms for the clock pin, the scan-in pin, and the scan-out pin derived from the Mux-DFF shift procedure example. This timing diagram shows onescan chain shift cycle, assuming the time unit is 1ns.

Figure 8-3. Timing Diagram for Shift Procedure

The procedure contains four scan events: forces scan input values at 0ns, strobes (or measures)scan output values at 10ns, pulses the scan clock scan_clk (turning it on at 30ns and off at 40ns),and holds the state of the last event until the procedure finishes at 50ns.

A timing clock monitors when each significant event occurs. If the timing clock is at X whenthe shift procedure begins, the timing clock assigns those four events with time values X, X+10,

scan_clk

SIN

SOUT

30NS 40NS

50NS0

End of shift procedure

10NS

0NS

Hold for 10ns

Measure scan

Force scan input values

Pulse clock

X+30 X+40 X+50 Timing ClockX X+10

output values

Start of shiftprocedure



X+30, and X+40. When the shift procedure finishes, the timing clock advances to X+50. Theshift cycle ending time becomes the starting time for the next shift cycle.

Alternate Shift Procedure (Optional)When using on-chip clock generators, such as programmable PLLs, it is sometimes necessary tochange values on input (control) signals to the clock generator a cycle or two before the changein generated clocking schemes is realized. When the shift clocks for a scan chain are alsoprovided by the on-chip clock generator, it is sometimes not possible to reprogram the clockgenerator near the end of the scan chain shifting in order to stop the shift clock and prepare forthe capture clocks. To accomplish this you might want to use an alternative shift procedure.

Alternate shift procedures have names, as described in the following paragraph. Alternate shiftprocedures can only be used for single shifts (a pre shift or a post shift), and there must be oneun-named normal shift (shift) as the main shift in the required load_unload procedure. SeeLoad_Unload (Required).

The shift procedure allows for an optional name following the shift procedure type. For eachscan group, one shift procedure must be defined that has the default name of shift. For each scangroup, additional alternate shift procedures can be defined as long as each has a unique name.

Each shift procedure is required to contain a force_sci or force_sci_equiv statement and ameasure_sco statement.

Syntax

procedure shift [ procedure_name ] =...end ;

ExampleThe following is a partial example of how the alternate shift procedure might be used in aprocedure file for a scan chain with a length of 100.

timeplate tp1 = force_pi 0; measure_po 10; pulse ref_clk 50 50; period 100;end;



August 2006

procedure shift = timeplate tp1; scan_group grp1; cycle = force ctrl_a 1; force_sci; measure_sco; pulse ref_clk; end;end;procedure shift shift_last = timeplate tp1; scan_group grp1; cycle = force ctrl_a 0; force_sci; measure_sco; pulse ref_clk; end;end;procedure load_unload = timeplate tp1; scan_group grp1; cycle = force ref_clk 0; force scan_en 1; force ctrl_a 1; end; apply shift 98; apply shift_last 1; apply shift_last 1;end;

Load_Unload (Required)This required procedure describes how to load and unload the scan chains in the scan group. Toload the scan chain, you must force the circuit into the appropriate state for the start of the shiftsequence. This includes forcing clocks, resets, RAM write control signals, and any other signalsthat need to be at their off states for scan chain loading. Also, If a reset signal is defined as aclock, and pin constrained to its off state in the dofile, it needs to again be forced to its off statein the load_unload and named capture procedures in order to avoid a P34 DRC.

Figure 8-4 shows the data flow for the load_unload procedure.

Figure 8-4. Load_Unload Procedure

ScanCell

sc_in ScanCell

ScanCell

sc_outScanCell

N N-1 N-2 0

Data shifts down N scan cells



If the scan out pin is bidirectional, you must force its value to the Z state (indicating it isoperating in “output” mode) to properly sensitize the scan chain. If there is a scan enable signal,you must force it on to enable the scan chain prior to the shift. You then use the apply shiftstatement to specify the number of shift cycles (which equals the number of scan elements in thechain). If you have optionally included the shadow_control procedure (which if used,immediately follows the shift procedure), you must also include the apply command.

The following list includes the basic statements in the load_unload procedure:

• Mux-DFF

procedure load_unload =timeplate tp1;cycle =

// force clocks offforce RST 0;force CLK 0;// activate scanning modeforce scan_en 1;

end;// shift data thru each of 7 cellsapply shift 7;

end;

• LSSD


// force all clocks offforce RST 0;force CLK 0;force scan_sclk 0;force scan_mclk 0;

end;// apply shift procedure 7 timesapply shift 7;

end;

The timing for the load_unload procedure is generally straightforward. The load_unloadprocedure contains the apply statement. Therefore, the total time for a load_unload procedureincludes the time specified by the timeplate being used plus the time required to execute theapply cycles.

For example, examine the following load_unload procedure, using the example shift procedurein the previous section.


force RST 0;force CLK 0;force scan_en 1;

end;



August 2006

apply shift 1;end;

The timeplate of the load_unload procedure specifies the period is 50ns. However, theload_unload procedure includes an apply statement that executes one shift procedure. The shiftprocedure requires an additional 50ns. Thus, the load_unload procedure actually requires a totaltime of 100ns, as shown in Figure 8-5.

Figure 8-5. Timing Diagram for Load_Unload Procedure

Within the load_unload procedure, after the completion of the cycle block, the shift procedurestarts at 50ns, executes for 50ns, and ends at 100ns. Thus, the load_unload procedure also endsat 100ns.

As with the shift procedure, the timing clock determines the event times for the load_unloadprocedure. If the timing clock is at Y when the load_unload procedure begins, the first threeevents happen at time Y. When the apply cycle executes, the timing clock advances to Y+50,which is when the shift procedure begins. As mentioned previously, the shift procedure requires50 time units. Therefore, when the apply cycle finishes, the timing clock reads Y+100.

Because it is the last event in the load_unload procedure, the end of the apply cycle determinesthe end of the load_unload procedure.

Shadow_Control (Optional)This optional procedure, which may only contain force and pulse event statements, describeshow to load the contents of a scan cell into the associated shadow. If you use this procedure, youmust also apply the shadow_control command in the load_unload procedure. This proceduremust not disturb the contents of any of the scan cells. Figure 8-6 shows the data flow for theshadow_control procedure.

Force RST 0

Force CLK 0

Force scan_en 1

0 50

Start shift cycle

100

shift cycle executes(50ns)

End shift cycle and

Start load_unload procedure

Y Timing ClockY+50 Y+100

load_unload procedure



Figure 8-6. Shadow_Control Procedure

Master_Observe (Sometimes Required)This procedure, which may only contain force and pulse event statements, describes how toplace the contents of a master into the output of its scan cell, where you can observe it by usingthe unload operation. Figure 8-7 shows the data flow for the master_observe procedure.

Figure 8-7. Master_Observe Procedure

You do not need to use this procedure if the master element’s output is the output of the scancell. The D1 rule ensures this procedure does not disturb master memory element’s contents.You can override this requirement by changing the D1 rule handling. The following exampleshows a master_observe procedure for the LSSD architecture:

// LSSD architecture exampleprocedure master_observe =

timeplate tp1;cycle =

// Force all clocks offforce scan_sclk 0;force scan_mclk 0;force rst 0;

SlaveMaster

Shadow

sc_in sc_out

Scan Cell NCell N+1 Cell N-1

Shadow_ControlData Transfer

SlaveMaster

Shadow

sc_in sc_out


Master_ObserveData Transfer



August 2006

force clk 0;// Pulse the slave clockpulse scan_sclk;

end;end;

Shadow_Observe (Optional)This optional procedure, which may only contain force and pulse event statements, describeshow to place the contents of a shadow into the output of its scan cell, assuming the circuitry ofthe scan cell allows the transfer of data in this way. Once the data is at the scan cell output, youcan observe it by applying the unload command. This procedure allows the shadow to be usedas an observation point in the design. Figure 8-8 shows the data flow of the shadow_observeprocedure.

Figure 8-8. Shadow_Observe Procedure

Seq_Transparent (FastScan and TestKompress, Optional)This optional procedure identifies how to make non-scan cells and RAM read ports functionallybehave transparently. This procedure activates the clock inputs of non-scan cell inputs, thuspulsing data through the cells “transparently”. All clocks must be at their off-states andconstrained pins at their constrained states before applying the seq_transparent procedure. Theprocedure must immediately follow a force of all the primary inputs. For more information onthe sequential transparent operation, refer to “Sequential Transparent Patterns” in the Scan andATPG Process Guide.

You can use multiple clock cycles to create the sequential transparent conditions. You maydefine up to 32 different seq_transparent procedures within a procedure file. When simulationmode is set to RAM_sequential, each force_all statement in the pattern file can use any of the

SlaveMaster

Shadow

sc_in sc_out


Shadow_ObserveData Transfer

MUX

SMUX

S



possible seq_transparent procedure choices. FastScan and TestKompress treat non-scan stateelements that cannot utilize the sequential transparent procedures as tie-X gates.

There may be occasions when you would want to use seq_transparent procedures when thedesign contains no scan chains. In this case, you would use the Add Scan Group command,specifying the name “dummy” for the chain name and the procedure filename (which containsonly the seq_transparent procedure). Refer to the “Add Scan Groups” command reference pagein the ATPG and Failure Diagnosis Tools Reference Manual for more details. Figure 8-9 showssome circuitry that could benefit from a seq_transparent procedure.

Figure 8-9. Sequential Transparent Circuitry Example

The following example shows the seq_transparent procedure for Figure 8-9.

timeplate tp1=force_pi 0;measure_po 0;pulse clock1 30 10;pulse clock2 30 10;period 50;

end;

procedure seq_transparent tran1=timeplate tp1;cycle=

force clock1 0;force clock2 0;force reset 1;

end;cycle=

pulse clock2;end;cycle=

restore_pi;end;

end;

The basic stimuli necessary to create transparent behavior for the non-scan flip-flop shown inFigure 8-9 are:

• Force all clocks off

• Pulse non-scan cell clock Clock2

Flip-Scan ScanCell

FlopCell

Clock2

Clock1

Non-Scan



August 2006

• Restore primary inputs to original values

In more complex situations, you may need to set primary inputs to certain values, placeconditions on scan cells, pulse multiple clocks, and so on.

You can use the Report Seq_transparent Procedures command to display data defined by theseq_transparent procedures. For more information, refer to the “Report Seq_transparentProcedures” command reference page in the ATPG and Failure Diagnosis Tools ReferenceManual.

Clock (FastScan and TestKompress, Optional)This optional procedure provides flexible clock handling during the test procedures. Usingclock procedures, instead of pulsing a single clock during a capture cycle, you can seriallyexercise multiple clocks and force non-clock pins that do not affect captured data.

The following example shows a clock procedure used to operate two clocks in sequence:

procedure clock clock_proc1 =timeplate tp3;cycle =

pulse clk1; // Pulse first clockend;cycle =

pulse clk2; // Pulse second clockend;

end;

Clock procedures must abide by the following rules:

• The procedure must activate at least one clock.

• If you define multiple clock procedures, only one of these procedures can activate aspecific clock.

• The procedure events cannot violate pin constraints or equivalence conditions.

• The procedure can only force non-clock pins, if they do not affect data captured intostate elements, whose clocks may activate later in the procedure.

• Multiple clocks that activate serially cannot logically interact.

• The procedure must follow all standard rules for both clock and non-clock pin usage.

• Each clock procedure must have a unique name.

• If a state element can change state during the procedure, the element must be stablewhen all clocks are off and pins are constrained.

• Transparent_capture cells are stable state elements that can capture data during theprocedure and whose new data can affect other state elements later in the procedure.



Design rules D10 and D11 ensure that these cells do not connect to state elements thatcapture old data or propagate data to primary outputs.

• The procedure must set all bidirectional pins to their input mode prior to executing therestore_bidis statement.

If a clock procedure contains a restore_bidis statement, the tool cannot use sequential ATPG.This may cause a problem if you set the tool for multiple clock compression because multipleclock compression uses sequential ATPG.

Skew_Load (Optional)This optional procedure propagates the output value of the preceding scan cell into the mastermemory element of the current cell without changing the slave, for all scan cells. Using onlyforce and pulse event statements, this procedure defines how to apply an additional pulse of themaster shift clock after the scan chains are loaded. Figure 8-10 shows the data flow of theskew_load procedure.

Figure 8-10. Skew_Load Procedure

Figure 8-11 shows where you apply the skew_load procedure and the master_observeprocedure within the basic scan pattern events.

SlaveMaster

Shadow

sc_in sc_out


Skew_LoadData Transfer



August 2006

Figure 8-11. Skew_load applied within Pattern

Non-Scan ProceduresThe following sections describe the various non-scan procedures available. These procedurescan represent any type of pattern that FastScan will produce. For example, FastScan cancombine one or more clock_sequential procedures with the capture procedure to representclock_sequential patterns. But you can define explicit clock cycles using a Named CaptureProcedure.

The loading and unloading of the scan chain is not specified in these procedures. A basicFastScan pattern consists of loading of the scan chains, a default capture procedure, followed byunloading the scan chains. Figure 8-12 shows the basic pattern for these procedures.

Figure 8-12. Non-Scan Procedure Pattern

The non-scan procedures should only be used to specify in which cycles of the procedure“potential events” are to happen, where a “potential event” is an event that the ATPG enginemay or may not have created to cover a certain fault. Each non-scan procedure must contain theproper statements for that procedure with the timing from the timeplate placing these statementsin the correct order, or there will be a DRC rule violation. However, the statements in a non-scan procedure can be spread over any number of cycles using a different timeplate for eachcycle, if needed.

Capture (Optional, FastScan and TestKompress)There are two forms of capture procedures. The default capture procedure is a single procedureyou use to provide information to Vector Interfaces on how the series of capture events are to bebroken into cycles, and which timeplates these cycles should use. This is the default captureprocedure.

Basic Scan Pattern

Load scan chainsForce primary inputsMeasure primary outputsPulse capture clockUnload scan chains

Skew_loadAppliedHere

Master_observeAppliedHere

Basic Pattern

Force primary inputsMeasure primary outputsPulse capture clock



You can also specify multiple named capture procedures, each with a unique name. Thesequence of events in these additional capture procedures must pass DRC. The results of theDRC will influence the ATPG kernel and the ATPG engine during pattern generation.

Figure 8-13 shows the basic pattern for the Capture procedure.

Figure 8-13. Capture Procedure Pattern

Default Capture Procedure

This optional procedure, which may only contain force_pi, measure_po, pulse_capture_clock,bidi_force_pi, bidi_force_off, and bidi_measure_po event statements, represents the non-scanactivity for a normal pattern.

There is no overlap between the capture procedure and the existing Clock procedure. Thecapture procedure should only use the pulse_capture_clocks statement to indicate in whichcycle one or more capture clocks should be pulsed. Any complex clocking that needs to bedescribed for capture clocks or other clocks should still be specified in the clock procedure (notin the default capture procedure) or by using a named capture procedure.

The capture procedure should not be used to specify any type of pin or ATPG constraint. Forexample, specifying that a certain pin is to be held at a certain state during the capture proceduredoes not restrict the ATPG engine from applying different values to that pin. These types ofstatements are not allowed in the capture procedure.

The only exception to this rule is the use of the bidi_force_off and bidi_force_pi statements inthe capture procedure. These statements can be used in the capture procedure to force allbidirectional pins off in one cycle, and force the ATPG values on the bidirectional pins in thenext cycle.

Named Capture Procedure

In addition to the default capture procedure, you can specify multiple named captureprocedures, each having a unique name. The sequence of events in these additional captureprocedures is passed on to the DRC and the ATPG kernel, and will influence how the ATPGengine generates patterns.

The named capture procedure, which may only contain force_pi, measure_po, bidi_force_pi,bidi_force_off, bidi_measure_po, observe_method, pulse (named clock), and conditionstatements, can be used to support on-chip clocks. These clocks may be generated on-chip by aPLL. In this situation, there are only certain clock waveforms that a PLL can support, and the

Capture Procedure Pattern

Force primary inputsMeasure primary outputsPulse capture clock



August 2006

named capture procedure is the mechanism for specifying the allowed set of clock waveforms tothe tool. If one or more named capture procedures is enabled with “set capture procedure on-all”, the tool does not use the default capture procedure; it uses the named capture procedure(s)exclusively. In this case, if the conditions to test a fault require a particular sequence of clocksor cycles that is not defined in one of the named capture procedures, the fault will not betestable. The internal tool patterns will identify to Vector Interfaces which capture procedure touse while saving patterns. This way, each named capture procedure can specify its own timingand cycle divisions.

The named capture procedure utilizes the keyword, “mode,” with two mode blocks: “internal”and “external.” If mode definitions are used, all cycles in a procedure must be defined withinmode definitions. The mode definitions are analogous to having two procedure definitionswithin one procedure. The internal mode is used to describe what happens on the internal side ofthe on-chip PLL, while the external mode is used to describe what happens on the external sideof the on-chip PLL. All events in a capture procedure that use modes must be duplicated in bothmodes. The only difference is that the internal mode should use only internal clocks and theexternal mode should use only external clocks. The number of cycles used and the timeplatesused can be different, as long as the total period of both modes is the same.

The pulse_capture_clock statement is not used in the named capture procedure. Instead, theclocks used are explicitly pulsed. The “condition” statement is allowed at the beginning of thecycle statement in the named capture procedure to specify what internal conditions need to bemet in order to enable this clock sequence, and the observe_method statement allows a specificobserve method to be defined for each named capture procedure. Otherwise, the ATPG willautomatically select between master, slave, or shadow observation.

The Save Patterns command line contains an option to allow the user to save “internal” or“external” clock patterns. Internal clock patterns can be used to simulate the DUT withouthaving the PLL modeled, while the external patterns only exercise the PLL external clocks andcontrol signals. “Internal” patterns are the default for ASCII and binary formats whereas“external” patterns are the default for tester formats.

NoteIf you generate patterns using a named capture procedure that has both internal andexternal modes and you save them in STIL or WGL format, you must use the SavePatterns command’s “internal” option if you intend to read them back into the tool (to usein diagnosis for example). See the description of the command’s -Mode_internal and-Mode_external switches for more information.

Following is an example named capture procedure:

procedure capture pll_1 =observe_method slave;mode internal =timeplate tp1_in;cycle slow =



condition /dut/cell1 0;force clk_cntr 1;force_pi;

end;cycle =

pulse /patha/int_clk;end;cycle =

force clk_cntr 0;measure_po;pulse /patha/int_clk;

end;

mode external =timeplate tp1_ex;cycle =

force clk_cntr 1;force_pi:measure_po;pulse pll_clk;

end;cycle =

force clk_cntr 0;end;

end;end;

Optionally, a “slow” or a “load” type can be added to the cycle definition:

cycle [slow] [load] =...end;

• The slow cycle indicates that at-speed faults cannot be launched or captured. It isimportant for the tool to know which at-speed cycles are slow (in order to get accurateat-speed fault coverage simulation numbers), so be sure to include “slow” when definingcycles that are not at-speed cycles in an at-speed capture procedure.

NoteAt-speed cycles need to be continuous; that is, a named capture procedure cannot havemore than one at-speed clocking sub-sequence.

• The load cycle indicates that the cycle will always be preceded by an extra scan load.The first cycle in a named capture procedure is always a load (with or without the loadtype designation), so you would typically apply “load” to subsequent cycles. An at-speed launch cycle can be a load cycle but none of the cycles that follow in the at-speedsequence, up to and including the capture cycle, can be load cycles.



August 2006

NoteTo get extra loads, you must enable the tool’s multiple load and clock sequentialcapabilities by issuing the Set Pattern Type command with “-multiple load on” and“-sequential <2 or greater>”. See “Multiple Load Patterns” in the Scan and ATPGProcess Guide for more information.

The following example illustrates the “slow” and “load” attributes:

procedure capture multi_load_example =timeplate tp1;// first cycle is always a load, with or without load type designationcycle slow =

force_pi;force wr_enable 1;pulse int_clk1;

end;cycle slow load =

pulse int_clk1;end;cycle =

force re_enable 1;pulse int_clk1; // launch clock

end;cycle =

pulse int_clk1; // capture clockend;

end; // end of capture procedure

Optionally, you can add one or more “launch_capture_pair” statements to the beginning of anamed capture procedure. This statement defines legal at-speed launch and capture points innon-adjacent cycles. If the launch_capture_pair statement is not used, the tool will launch andcapture only in adjacent cycles. If at least one launch and capture clock pair is defined, the toolwill derive the launch and capture points from the launch and capture clock pairs.

NoteThis statement is only supported when using a named capture procedure to perform testgeneration.

The syntax of the launch_capture_pair statement is defined as follows:

launch_capture_pair <launch_clock_pin_path_name><capture_clock_pin_path_name>;

The first clock defined in the statement is the launch clock and the second one is the captureclock. The defined launch clock is always the launch point. Valid capture points are the definedcapture clock and any other clock that has the same period as the defined capture clock. To be avalid launch and capture clock pair, the cycles between the launch clock and capture clock mustbe at-speed cycles. They cannot include any slow cycle between them.



The following example illustrates the launch_capture_pair statement:

procedure capture c1_c1 =launch_capture_pair c1 c1;

cycle = // cycle 1force_pi;force c1 0;force c2 0;force c3 0;pulse c1;

end;

cycle = // cycle 2pulse c2;

end;

cycle = // cycle 3pulse c1;pulse c3;

end;end; // end of capture procedure

In this example, a valid launch can happen in cycle 1 only. Valid capture can happen in cycle 3only, with either c1 or c3 as the capture clock. A launch and capture in cycles 1 and 2 is notvalid; nor is a launch and capture in cycles 2 and 3.

Example PLL Model and Named Capture Procedure

The following is an example of a PLL model and named capture procedure (used with theMBISTArchitect tool):

In this example, consider a PLL model which has two clocks: a reference clock, and an internalclock. Based on PLL control signal you know the following:

• The internal clock is 2X faster than the reference clock when the PLL control is 0.

• The internal clock is 4X faster than the reference clock when the PLL control is 1.

If you wanted a PLL internal clock to drive the BIST controller clock, the following examplecommand is loaded at the BIST insertion to make the proper connection.

add pin map /PLL/int_clk /controller/bist_clk

The following is the named capture procedure that describers the PLL model behavior,assuming your PLL control is 0, for example the internal clock speed 2X faster than thereference clock.

timeplate timeplate_internal = force_pi 0 ;

measure_po 40 ; pulse PLL/int_clk 5 25 ; // 2X

period 50;end;



August 2006

timeplate timeplate_external =force_pi 0 ;

measure_po 90 ; pulse topPLLclk 5 50; period 100 ;end;procedure capture PLL_1 = mode internal = timeplate timeplate_internal; cycle = pulse PLL/int_clk ;end;cycle = pulse PLL/int_clk ; end;end; mode external = timeplate timeplate_external ; cycle = pulse topPLLclk ; // connected to referecne clock end; end;end;

Clock_po (Optional, FastScan and TestKompress)This optional procedure, which may only contain force_pi, measure_po, bidi_force_pi, andbidi_force_off event statements, represents the non-scan activity for a clock PO pattern. Usethis procedure instead of the capture procedure.

NoteWith this procedure, you must use a timeplate that does not pulse the clocks.

Figure 8-14 shows the pattern for the clock_po procedure.

Figure 8-14. Clock_po Procedure Pattern

Ram_sequential (Optional, FastScan and TestKompress)This optional procedure, which may only contain force_pi, pulse_write_clock,pulse_read_clock, bidi_force_pi, and bidi_force_off event statements, represents the RAMsequential events in a RAM sequential pattern. Use this procedure with the capture procedure.

Clock_po Procedure Pattern

Force primary inputs (including clocks)Measure primary outputs



Figure 8-15 illustrates the basic ram_sequential procedure format.

Figure 8-15. Ram_sequential Procedure Pattern

Figure 8-16 shows an entire RAM sequential pattern, which illustrates where theram_sequential and capture procedures are used.

Figure 8-16. Full Ram Sequential Pattern

Ram_passthru (Optional, FastScan and TestKompress)This optional procedure, which may only contain force_pi, measure_po, pulse_write_clock,pulse_capture_clock, bidi_force_pi, bidi_force_off, and bidi_measure_po event statements,represents the non-scan activity for a RAM passthrough FastScan pattern. Use this procedureinstead of the capture procedure.

Figure 8-17 shows the pattern the ram_passthru procedure follows.

Ram_sequential Procedure Pattern

Force primary inputsPulse write clockand/or Pulse read clock

Load scan chainsForce primary inputsPulse write clock

(Repeat above up to two times)

Load scan chainsForce primary inputsPulse read clock


RAM Sequential Pattern

ram_sequentialprocedure

ram_sequentialprocedure

captureprocedure



August 2006

Figure 8-17. Ram_passthru Procedure Pattern

Clock_sequential (Optional, FastScan and TestKompress)This optional procedure, which may only contain force_pi, pulse_write_clock,pulse_read_clock, pulse_capture_clock, bidi_force_pi, and bidi_force_off event statements,represents the clock sequential events in a clock sequential pattern. Use this procedure with thecapture procedure.

Figure 8-18 shows the pattern for the clock_sequential procedure.

Figure 8-18. Clock_sequential Procedure Pattern

Figure 8-19 shows an entire clock sequential pattern, which illustrates where theclock_sequential and capture procedures are used.

Figure 8-19. Full Clock Sequential Pattern

Ram_passthru Procedure Pattern

Force primary inputsPulse write clock

Pulse capture clockMeasure primary outputsPulse read clock

Clock_sequential Procedure Pattern

Force primary inputsPulse write clockand/or Pulse read clockand/or Pulse capture clock

Load scan chainsForce primary inputsPulse clock

(Repeat above up to N times)


Clock Sequential Pattern

clock_sequentialprocedure

captureprocedure



Init_force (Optional, FastScan and TestKompress)This optional procedure, which may only contain force_pi event statements, represents the forcecycle that is used in a FastScan or TestKompress pattern which targets a transition fault. Thetransition must be launched off of the last scan chain shift. This is used when the fault type is setto transition fault and either the depth is set to 2 or less or the ATPG engines fail to find asequential pattern that can cover this transition fault. Use this procedure with the captureprocedure.

Figure 8-20 illustrates the format of the init_force procedure.

Figure 8-20. Init_force Procedure Pattern

Figure 8-21 shows the pattern which uses the init_force procedure.

Figure 8-21. Init_force Procedure Usage

Test_end (Optional, all ATPG tools)

All ATPG Tools

This optional procedure is used to add a sequence of events to the end of a test pattern set.

The test_end procedure may only contain force and pulse event statements (see the followingexception), and can only be defined once for all scan groups. When saving patterns, the test_endprocedure will be applied to the end of each pattern set saved.

LBISTArchitect Only

For the LBISTArchitect tool only, the test_end procedure may also contain a measure_misrevent statement at the end of the BIST test program to unload final signatures from the MISRs.

Figure 8-22 shows the general pattern for the test_end procedure.

Init_force Procedure Pattern

Force primary inputs

Init_force Usage

Force primary inputs


init_forceprocedure

captureprocedure



August 2006

Figure 8-22. Test_end Procedure Pattern

Example 1: Using test_end in a Procedure File

The following is a partial example of how the test_end procedure might be used in a procedurefile.

timeplate tp1 = force_pi 0; measure_po 10; pulse ref_clk 50 50; period 100;end;

procedure test_end = timeplate tp1; cycle = force ctrl_a 1; force tms 0; pulse ref_clk; end;end;

Example 2: Test_end Procedure with Timeplate

Following is an example test_end procedure with its corresponding timeplate:

timeplate tp4 = force_pi 0; pulse TCK 10 10; measure_po 30; period 40;end;

procedure test_end = timeplate tp4; cycle = // TMS = 1, change to select-DR state force TDI 1; force TMS 1; pulse TCK; end;

cycle = // TMS = 0, change to capture-DR state

Test_end Procedure Pattern

Force primary inputsPulse clocksMeasure_misr statement



... cycle = // Scan out signature (MISR has length of 4) force TDI 1; force TMS 0; pulse TCK; // Least significant bit of lfsr2 (misr) measure_misr lfsr2 TDO; end; cycle = force TDI 1; force TMS 0; pulse TCK ; measure_misr lfsr2 TDO; end;...end;

Sequential (Optional, FlexTest Only)This procedure only specifies which timeplate should be used for FlexTest sequential cycles.Because FlexTest can use any number of cycles to cover a fault, no events should be specifiedin this procedure.

The timing in the timeplate, used for the sequential procedures, needs to agree with the timingspecified using the Add Pin Constraints, Setup Pin Constraints, Add Pin Strobes, and Setup PinStrobes commands. In FlexTest, you create time frames and specify which pins are forced inwhich time frames. It is important that the timing in the sequential procedure timeplate matchthese time frames. The following examples illustrate this point.

• Example 1: Introductory Example with Scan Chains

From dofile:

add scan groups grp1 ...add scan chains chain 1 grp1 ...add clocks 0 CLKadd pin constraints CLK sr0 1 1 1set test cycle 2

From procedure file:

timeplate tp1 = force_pi 0; measure_po 50; pulse CLK 100 100; period 300; end;

procedure sequential = timeplate tp1 ; end;



August 2006

Figure 8-23 illustrates the time frames and timing that correspond to Example 1.

Figure 8-23. Introductory Example with Scan Chains

The Set Test Cycle 2 command sets up two time frames. Figure 8-23 shows that all primaryinputs are forced in Timeframe 1. This is the default for pins. The pin constraint for CLK statesthat the pin is a pulse that has an offset of one time frame and a width of one time frame.Therefore, CLK goes high at the beginning of the second time frame and goes low at the end.Since this is a scan design, all measures happen by default at the end of the first time frame.

The timeplate puts real timing values on these time frames. Force_pi happens at time 0,measure_po happens at time 50, which is within the first time frame, and after all forces in thefirst time frame. The rising edge of the clock denotes the beginning of the second time frame,whereas falling edge denotes the end of the second time frame. Because the period of thetimeplate is larger than the end of the second time frame, the second time frame is extended outto 300ns to act as a hold time for the clock pulse.

• Example 2: Introductory Example without Scan Chains

From dofile:

set test cycle 3add pin constraint LE sr0 1 1 1

From procedure file:

measure_po

300NS

0

50NS

0NS

Measure scan

Force primary

X+100 X+200 X+300

Timing Clock

X X+50

output values

input values

Timeframe1

Timeframe2

Extra

CLK100NS 200NS

Hold forPulse clock

100ns

force_pi



timeplate tp1 = force_pi 0; pulse LE 100 100; measure_po 280; period 300; end;

procedure sequential = timeplate tp1;end;

Figure 8-24 illustrates the timeframes and timing that correspond to Example 2.

Figure 8-24. Introductory Example without Scan Chains

This example is a non-scan example, thus the default pin strobe is at the end of the last timeframe. Therefore, the timeplate must put the measure_po time near the end of the last timeframe (280ns in this case).

It is possible that when a pin constraint has a period greater than one, you may need to specifytwo timeplates in the sequential procedure. For example, if you issue the command:

add pin constraint CLK sr0 2 1 1

You may need the following sequential procedure:

measure_po

300NS

0

280NS

0NS

Measure scan

Force primary

X+100 X+200 X+300Timing Clock XX+280

output values

input values

Timeframe1

Timeframe2

Timeframe

CLK100NS 200NS

Hold forPulse clock

100ns

3

force_pi



August 2006

procedure sequential = cycle = timeplate tp1; end; cycle = timeplate tp4; end;end;

This is because a pin constraint with a period of 2 or more specifies that the waveform of the pinextends over that many cycles. Multiple timeplates and cycles may need to be used to correctlycreate the waveform for the constrained pin.

If no sequential procedure is specified, the Vector Interfaces code creates a default sequentialprocedure and, if necessary, a default timeplate based on the test cycle and pin constraints.

Sub_procedureThis procedure eliminates the need to insert duplicate actions within a procedure. Once youhave defined a sub_procedure, you can specify this procedure within other procedures using theapply statement. You can also set the tool to reissue the sub_procedure as many times as neededby specifying the repeat_count. Because the repeat_count is required when using applysub_procedure, a minimum of 1 needs to be entered for this parameter.

Sub_procedure Looping

Sub_procedure looping is used to reduce the size of pattern files. The default behavior of thesub_procedure is to use “loops” or “repeats” in all applicable pattern formats to repeat thecontents of the sub_procedure N times, where N is greater than 1.

Disabling Sub_procedure Looping

In previous versions, the default behavior was that the event data in a sub_procedure wasexpanded and represented as N sets of vectors in the pattern file, where N is the number of timesthe sub_procedure is applied. For example, if the test_setup procedure has the followingstatement.

apply pulse_bclock 1000;

The vector data for the sub_procedure “pulse_bclock” would be expanded to be 1000 vectors. Ifthis is the behavior you want, and not the default loop behavior, then you can disable the use of“loop” or “repeat” statements by using the ALL_NO_LOOP <0 | 1> parameter file keyword.The default of this keyword is off (0).

Sub_procedure Definition Format

The sub_procedure definition has the following format.

Test Procedure FileProcedure File Examples


procedure sub_procedure my_subprocedure =timeplate tp1;cycle =

force_pi;measure_po;

end;end;

Using the Sub_procedure in a Procedure

The following is an example of how to use the sub_procedure in a procedure.

procedure shift =scan_group grp1;timeplate tp1;apply my_subprocedure 4;cycle =

force_sci;measure_sco;pulse T;

end;end;

NoteYou must first define a sub_procedure before using it in a procedure. Next, you can applya sub_procedure within any procedure type. Also, you cannot use a sub_procedure withinthe “cycle =” and “end;” statements.

Procedure File ExamplesThe following examples illustrate the test procedure file format.

Example TI TDL Test Procedure FileThe following is a typical FastScan test procedure file that creates a tester cycle of 500ns. In thisexample, the default period is 1000ns, but the SET SPLIT_MEASURE_CYCLE TIMEcommand splits the non-scan cycle in two at 500ns to ensure output measurement at the end ofthe test cycle.

set time scale 1 ns;

timeplate “tp0” =force_pi 2;bidi_force_pi 100;pulse CLK 100 100;pulse CLEAR 100 100;measure_po 490;period 500;



August 2006

end;

timeplate “tp_scan” =measure_po 0;force_pi 2;pulse CLK 100 100;pulse CLEAR 100 100;period 500;

end;

procedure shift =timepate tp_scan;cycle =

force_sci;measure_sco;pulse CLK;

end;end;

procedure load_unload =timeplate tp_scan;cycle =

force SE 1;force CLEAR 1;force CLK 0;measure_sco;

end;apply shift 10;

end;

procedure capture =timeplate “tp0”;cycle =

force_pi;bidi_force_pi;measure_po;

end;cycle =

pulse_capture_clock;end;

end;

NoteThe timeplate contains definitions for clocks called CLK and CLEAR. If there are morecapture clocks, you must pulse all of them in timeplate tp0.

Example UTIC Test Procedure FileThe following is a typical FastScan test procedure file that creates a tester cycle of 500ns. In thiscase, the non-scan cycle is split into two at 500ns to ensure output measurement at the end of thetest cycle.

set time scale 1 ns;set strobe window 30;



timeplate “tp0” =force_pi 2;bidi_force_pi 25;measure_po 50;pulse CLK 100 100;pulse CLEAR 100 100;period 500;

end;

timeplate “tp_scan” =force_pi 2;measure_po 50;pulse CLK 100 100;pulse CLEAR 100 100;period 500;

end;

procedure shift =timepate tp_scan;cycle =

force_sci;measure_sco;pulse CLK;

end;end;

procedure load_unload =timeplate tp_scan;cycle =

force SE 1;force CLEAR 1;force CLK 0;

end;apply shift 10;

end;

procedure capture =timeplate “tp0”;cycle =

force_pi;end;cycle =

bidi_force_pi;measure_po;pulse_capture_clock;

end;end;

NoteAlternatively, you can use the timeplate tp0 for the shift and load_unload procedures, andomit the timeplate tp_scan.



August 2006

FlexTest ExamplesThe following examples illustrate various FlexTest procedure files. Both examples use thefollowing dofile:

add clocks 0 CLK_1 CLK_2set test cycle 2setup pin constraints NR 1 0setup pin strobes 0add pin constraints CLK_1 sr0 1 1 1add pin constraints CLK_2 sr0 2 1 2setup pin constraints NR 1 0add pin constraints IN1 NR 1 1

FlexTest Example 1In the following example, the sequential procedure contains two cycles, using the timeplate tp0for both. CLK_2 rises at time 170 in the first cycle and falls at time 170 (total time 670) in thesecond cycle.

timeplate tp0 =force_pi 0;measure_po 80;force IN1 100;pulse CLK_1 150 100;force CLK_2 170;period 500;

end;

procedure sequential =timeplate tp0;

end;

FlexTest Example 2In the following example, the sequential procedure is still two cycles long, but now the firstcycle uses timeplate tp0 and the second cycle uses timeplate tp1. Therefore, clock CLK_2 risesat time 170 in the first cycle, but falls at time 200 (total time 700) in the second cycle.

timeplate tp0 =force_pi 0;measure_po 80;force IN1 100;pulse CLK_1 150 100;force CLK_2 170;period 500;

end;

timeplate tp1 =force_pi 0;measure_po 80;force IN1 100;pulse CLK_1 150 100;

Test Procedure FileMerging Procedure Files


force CLK_2 200;period 500;

end;

procedure sequential =cycle =

timeplate tp0;end;cycle =

timeplate tp1;end;

end;

Merging Procedure FilesIt is possible to specify more than one procedure file for a design. You can specify a procedurefile with the Add Scan Groups command or with the Read Procfile command. You need tosupply (to the ATPG tool) a minimum set of information in the procedure file with the AddScan Groups command. You must supply all event information for the scan procedures.

However, after leaving setup mode, it is possible to specify non-scan procedures, timeplates,and new timing for the scan procedures by reading in an additional procedure file with the ReadProcfile command. Specifying new information for the same design, from more than oneprocedure file, is known as “merging the procedure files.” To properly merge the informationfrom multiple procedure files, the Vector Interfaces code follows these rules:

• All scan procedures that you will use must be specified in the procedure file that youload with the Add Scan Groups command.

• If you load a procedure that contains nothing but the procedure name, a timeplate name,and an optional scan group, it is a template procedure. If a procedure already exists bythat name for that scan group (if it is a group specific procedure), then the timeplate ismapped onto the existing procedure. If no procedure already exists with that name, thetool stores the template procedure for future use.

• If you load a new complete procedure (not a template) and a procedure already exists bythat name for the specified scan group (if applicable), the new procedure overwrites theexisting one.

• In both cases, when a procedure overwrites an existing one, or if a new timeplate ismapped to an old procedure, the tool checks the procedures to make sure that thesequence of events in the new procedure does not differ from the old procedure.

Default InformationWhen you issue the Save Patterns command, Vector Interfaces code checks to make sure that allprocedures and timeplates needed to save the patterns in the specified format are present.


Test Procedure FileAutomatic End Measure Mode

August 2006

If there are any missing non-scan procedures, Vector Interfaces code creates default proceduresfor those that are missing, and issues a warning. For example, in cases where there wereram_sequential patterns that need to be saved and no ram_sequential procedure was supplied,the Vector Interfaces code creates a default procedure.

For any procedures that are created or that do not have a timeplate specified, the VectorInterfaces code maps the default timeplate to these procedures, if it is set. You can set thedefault timeplate by using the set default_timeplate statement previously described in the “SetStatement” section. If you use this statement, the Vector Interfaces code uses the timeplatespecified when creating default procedures. If the Vector Interfaces code needs to create adefault procedure and no default timeplate has been set, then it uses the first timeplate specified.If no timeplates are specified, then the Vector Interfaces code creates a default timeplate as well.

Automatic End Measure ModeEnd measure mode refers to the special handling that the Vector Interfaces code needs to do tohandle the measure_sco statement occurring after the pulse of the shift clock in a shiftprocedure.

There is no need for a keyword or a command to specify an “end_measure” mode for the VectorInterfaces code. If, in the shift procedure, the measure_sco happens after the pulse shift clock,then the Vector Interfaces code automatically turns on “end_measure” mode. In this mode, themeasure_sco statement actually measures the next value from the output of the scan chain. Thevery first value for the output of the scan chain should be measured by a measure_sco statementin the load_unload procedure.

In order for end measure to work, all shift procedures must have the measure_sco after the shiftclock.

If there is no measure_sco statement in the load_unload procedure, or if all shift procedures donot use end measure, the tool issues a rule W7 violation. Also, if there are any force or pulsestatements between the measure_sco and the end of the shift procedure, or between themeasure_sco and the apply shift in the load_unload procedure, the tool issues a rule W15violation.

Supporting CommandsThe following list contains supporting commands used for various purposes that relate toprocedure files. For a detailed description of each command, refer to the correspondingcommand reference page in the “Command Dictionary” section of the ATPG and FailureDiagnosis Tools Reference Manual or the “Command Dictionary” section of the DFTAdvisorReference Manual.

ADD SCan Groups group_name group_load_filename

• Adds a scan group using the scan procedures in the named procedure file.

Test Procedure FileASICVector Interfaces Output Formats


REAd PRocfile filename

• Reads a new procedure file in non-setup mode. Merges new procedure and timing datawith existing data loaded from previous procedure files.

WRIte PRocfile filename [-Replace] [-Full [-EXternal]]

• Writes out existing procedure and timing data as the named procedure file.

SAve PAttern filename [-AVI_format] procedure_file_name -procfile

• Loads a cycle before saving patterns and merges the new data with the existing data.

REPort PRocedure [procedure_name [group_name] | -All]

• Displays a named procedure to the screen. The -All switch displays all procedures to thescreen.

REPort TImeplate [timeplate_name | -All]

• Displays a named timeplate to the screen. The -All switch displays all timeplates to thescreen.

ASICVector Interfaces Output FormatsThe test procedure file format supports the following output formats:

The Save Patterns command format is as follows:

SAVe PAtterns pattern_filename [-Replace] [format_switch] [proc_filename -PROcfile [-NAme_match | -POsition_match] [-PARAMeter param_filename]] [-PARALlel | -Serial][-EXternal] [-NOInitialization] [-BEgin {pattern_number | pattern_name}] [-END{pattern_number | pattern_name}] [-TAg tag_name] [-CEll_placement {Bottom | Top |None}] [-ENVironment] [-One_setup] [-ALl_test | -CHain_test | -SCan_test] [-NOPadding |-PAD0 | -PAD1] [-Noz] [-PATtern_size integer] [-MAXloads load_number]

The -PROcfile switch causes the Save Patterns command to get its timing information from theprocedure file.

For more information, refer to the “Save Patterns” command in the ATPG and FailureDiagnosis Tools Reference Manual.

• Fujitsu TDL

• Mitsubishi TDL

• STIL

• TI TDL

• WGL

• TSTL2

• UTIC

• VERILOG

• VHDL

• ZYCAD


Test Procedure FileParameter File Format

August 2006

Parameter File FormatThe parameter file specifies field names and values for use in certain Vector Interfaces outputformats. The tool references this file when you issue the following command:

SAVe PAtterns pattern_filename proc_filename -PROcfile -PARAMeter param_filename [-ENVironment]

The general format of the entries in the parameter file is as follows:

OutModule_Parameter string;

All lines must end with a semicolon. Comment lines start with “//” at the beginning of a line andrun until the end of the line. You can specify any given parameter only once. If you set aparticular parameter twice, the latter entry overrides the previous one. AllOutModule_Parameter statements can only occupy a single line up to 2048 characters in thefile. Also, there cannot be any carriage returns embedded in the Out_Module Parameterstatement.

NoteA section has been added at the beginning of STIL, WGL, Verilog, and VHDL outputfiles that will capture the environment data and the switches used on the save patternscommand. In the STIL format, this information will be added to the HEADER{} block asan annotation. In the WGL format, this information will be added to the header block as aseries of annotation statements. In the Verilog format, this information will be added tothe beginning of the Verilog testbench as a comment. With VHDL, this information willbe added to the beginning of the VHDL testbench as a comment.

NoteThe specifying of a parameter file or any keyword within a parameter file is optional. Ifthere is no parameter file or a keyword is omitted, then see the keyword descriptions forthe default behavior.

The following list contains available OutModule_Parameter settings:

SIM_SHIFT_DEBUG integer;VERILOG_INCLUDE filename;VERILOG_MODULE_INCLUDE filename;VERILOG_KEEP_PATH {1 | 0};VERILOG_TOP_NAME filename;VERILOG_VECTOR_COMM {1 | 0};VERILOG_SIM_STATUS integer;VERILOG_EARLY_RELEASE {1 | 0};VERILOG_EARLY_RELEASE_TIME integer;VERILOG_NO_MEASURE_IN {1 | 0};



VERILOG_MASK_FILE {0 | 1 | 2};VERILOG_UNCOMPRESS_PAT {1 | 0};SIM_VECTYPE_SIGNAL {1 | 0};VERILOG_COMPARE_X {1 | 0};VHDL_SIM_STATUS integer;VHDL_SIGNAL_SPY {1 | 0};WGL_EDGE_STROBE {1 | 0};WGL_ADD_LASTX {1 | 0};WGL_VECTOR_ANN {1 | 0};WGL_ALT_BIDI {1 | 0};WGL_GROUP_PIN {1 | 0};WGL_VERG_ESC {1 | 0};WGL_TRIM_PULSE {1 | 0};WGL_NOMEASURE_CLOCK {1 | 0};WGL_ALT_VECT_ANN {1 | 0};WGL_INV_SC {1 | 0};WGL_PATTERN_NAME string;WGL_VTRAN_PADSC {1 | 0};TEST_SETUP_EXPECT {1 | 0};UTIC_LABEL string;TITDL_LIBRARY string;TITDL_CUSTOMER string;TITDL_PARTNUM string;TITDL_SETNAME string;TITDL_SETTYPE string;TITDL_CHAIN_SETTYPE string;TITDL_REVISION string;TITDL_PSEUDO_PREFIX string;ALL_NO_CYCLE_OPT {1 | 0};ALL_MIN_SCAN_LOAD {1 | 0};ALL_NO_PATTERN_TYPE {1 | 0};ALL_TIME_RESOLUTION integer;ALL_FIXED_CYCLES {1 | 0};ALL_FLATTEN_TIMING {1 | 0};CTL_STIL_0 {1 | 0};CTL_ONE_PAT {1 | 0};CTL_ONE_PROTO {1 | 0};STIL_TRIM_PULSE {1 | 0};STIL_NOMEASURE_CLOCK {1 | 0};STIL_SCAN_ANN1 “string %keyword string”;STIL_PAT_ANN “string %keyword string”;STIL_PAT_CMT {1 | 0};STIL_PAT_LAB {1 | 0};STIL_STRUCTURAL {1 | 0};STIL_VECTOR_ANN “string %keyword string”;

• SIM_SHIFT_DEBUG integer;This keyword and integer pair specify for the serial Verilog and VHDL testbench to usespecial test patterns that contain a parallel observe of the entire scan chain for everyshift, while serially shifting the patterns.

For debugging purposes only, this format makes it easier to pinpoint precisely whichscan cell in a chain is causing a problem. Issuing a 0, which is the default behavior, willcause the serial Verilog or VHDL testbench to use test patterns that do not contain aparallel observe of the entire scan chain for every shift.



August 2006

If an integer of 1 is used, it will shift serially and do a parallel compare for all shifts. Ifan integer of 2 or greater is used, it will shift serially and do parallel compares on thefirst 2 or greater shifts. This is done to reduce the amount of data in the pattern files.

The Verilog or VHDL patterns you create using the keyword SIM_SHIFT_DEBUGtypically take more time for the tool to create than other kinds of patterns and containlarge amounts of data (so file sizes tend to be huge). Also, because they simulateserially, the patterns will take more time to simulate. Be sure these are acceptabletrade-offs before trying to use these patterns.

The tools ignore the keyword SIM_SHIFT_DEBUG and issue a warning unless youinclude the -Serial switch in the Save Patterns command line. Also, if you do not includethe -End or -Chain_test switches, the tool defaults to “-End 0”, saving chain test patternsand the first scan pattern. To save chain test patterns and a different set of scan patterns,use the -Begin and/or -End switches to specify the range of scan test patterns to save. Tosave just chain test patterns, include the -Chain_test switch.

Note that VHDL uses the SIGNAL_SPY features of ModelSim, which does not allowfor the mixing of Verilog and VHDL netlists or libraries. Everything has to be VHDLlike the parallel output for VHDL.

Note that this functionality is only available for FastScan patterns and TestKompressbypass patterns (uncompressed).

• VERILOG_INCLUDE filename;Adds an include statement into the Verilog testbench after the comments and before thefirst module. The contents of the filename specified must contain legal Verilogstatements and syntax. This statement is only used in the Verilog outputs. The Defaultbehavior is to not add any include statements.

• VERILOG_MODULE_INCLUDE filename;Similar to the VERILOG_INCLUDE parameter, except it adds the include statementwithin the module definition for the testbench, instead of after the comments and beforethe first module. The contents of the filename specified must contain legal Verilogstatements and syntax. This statement is only used in the Verilog outputs. The Defaultbehavior is to not add any include statements.

• VERILOG_KEEP_PATH {1 | 0};Issuing a 1 with this keyword specifies for the Verilog testbench to use the full pathnameto specify the pattern data file. Issuing a 0, the default behavior, will cause the Verilogtestbench to specify the pattern data file without any path information.

• VERILOG_TOP_NAME filename;This keyword allows you to specify a new top level module name for the Verilogtestbench. The default behavior is to generate a default top level module name based onthe design name and the name of the pattern file.

• VERILOG_VECTOR_COMM {1 | 0};Issuing a 1 with this keyword will cause the Verilog testbench to include a comment in



the pattern file to denote the vector type. Issuing a 0, the default behavior, will cause theVerilog testbench to omit the comment to denote pattern type.

• VERILOG_SIM_STATUS integer;Specifies the frequency of status messages printed from the simulation testbenches, forVerilog. This keyword accepts an integer that it uses to output a message every ‘X’number of FastScan or FlexTest patterns. The simulation message will be “Simulated‘X’ patterns”.

• VERILOG_EARLY_RELEASE {1 | 0};This keyword allows you to specify that you want the Verilog testbench to put the“release” statement immediately after the trailing edge of the first clock pulse in the shiftprocedure. Issuing a 0, the default behavior, will place the “release” statement at the endof the cycle.

• VERILOG_EARLY_RELEASE_TIME integer;Issuing an integer value with this keyword allows you to specify exactly what time youwant the Verilog testbench “release” statement to happen using the time scale specifiedin the procedure file. The integer value is a time value that is required to be in the sametime scale as that used in the timeplate for the shift procedure. The time specified mustbe later than the time of the force_sci event, but not greater than the time of the end ofthe cycle that the force_sci event occurs in. The time is relative to the start of the cycle.

This keyword does not replace the VERILOG_EARLY_RELEASE keyword, but can beused as an alternative. If both the VERILOG_EARLY_RELEASE and theVERILOG_EARLY_RELEASE_TIME keywords are specified in the parameter file,then the VERILOG_EARLY_RELEASE_TIME keyword takes precedence. If neitherkeyword is used, then the default behavior of putting the “release” statement at the endof the cycle is still used.

NoteThe VERILOG_EARLY_RELEASE and VERILOG_EARLY_RELEASE_TIMEstatements are helpful when complex scan cells that use multiple clocks need the releaseto happen at a certain time prior to the end of the shift procedure, in order for the parallelload testbench to load the correct values. That is, if the forced value is held too long, asecond clock pulse will latch in the wrong value.

• VERILOG_NO_MEASURE_IN {1 | 0};In the Verilog testbench, when a value is being forced on a bidirectional pin (as in inputmode), the testbench will also try to measure the same value on the bidirectional pinwhen a measure happens. Setting this to 1 will cause the testbench to not measure inputvalues on the output side of bidirectional pins. The default is 0.

When -mode LSI is set on the command line and a Save Patterns Verilog command isexecuted, VERILOG_NO_MEASURE_IN will be set to TRUE automatically.



August 2006

• VERILOG_MASK_FILE {0 | 1 | 2};For parallel testbenches, used to control generation of a mask file (used by the FastScanand TestKompress tools).

Setting the value of VERILOG_MASK_FILE to 0 will cause the testbench to bebackward compatible.

Setting the value of VERILOG_MASK_FILE to 1 (default) will put the code into thetestbench, but does not make it active. (unless you edit the testbench and set the integer_write_MASK_file to 1); this way you do not have to rerun the Verilog output, but youwill have to change the value of the integer _write_MASK_file to 1, and then rerun thesimulation.

Setting the value of VERILOG_MASK_FILE to 2 will cause the file generation code tobe added and active. The integer _write_MASK_file will be set to 1.

Simulation Mismatches for the ChainTest PatternsIt is important to note that the simulation mismatches for the ChainTest patterns arerecorded in the VERILOG_MASK_FILE, but commented out.

• VERILOG_UNCOMPRESS_PAT {1 | 0};If this keyword is set to 1, it will force the tool to add code to the testbench toautomatically copy the compressed pattern file, uncompress it and when the pattern filehas been applied to the simulation, remove the temporary uncompressed pattern file.You will still need to uncompress the Verilog testbench before simulation. Issuing a 0,the default behavior, will cause the testbench to not include these capabilities.

• SIM_VECTYPE_SIGNAL {1 | 0};Specifies that all vector types in the currently active procedure be represented in thepattern file as a signal, and that these signals be on (in a 1 state) when that vector type isactive. This allows you to specify them in pattern tracing and viewing so you can seewhat type of vector is currently active at any specified moment within a simulation.

If the keyword is set to 1, the default behavior, it will add an encoded vector type to theVerilog or VHDL testbench, in the bus MGCDFT_VECTYP[0-3], and the translationtable, Table 8-2, will be added to the testbench. Issuing a 0 will cause the testbench tonot include these capabilities. See Analyzing the Simulation Data section for an exampleof using this keyword.

Table 8-2. Translation Table

MGCDFT_VECTYP[0-3] Encoding Signal/Variable

0001 mgcdft_test_setup

0010 mgcdft_load_unload

0011 mgcdft_shift

0100 mgcdft_single_shift

0101 mgcdft_shift_extra



NoteAdding signals indicating vector type to the Verilog or VHDL testbench enables you tosee what type of vector is currently active at any specified moment within a simulationand can simplify simulation mismatch debugging.

• VERILOG_COMPARE_X {1 | 0};If this keyword is set to 1, it will add code to the testbench to not mask X states, but tocompare for differences. This functionality is available in FastScan, FlexTest, andTestKompress, in both Serial and Parallel testbenches. Issuing a 0, the default behavior,will cause the testbench to not include these capabilities.

NoteWhile issuing a mismatch if we expect X is not required for ATPG, it is necessary forLibComp verification, to identify cases where the translation is pessimistic, otherwisemodeling something such as a Tie-X will not look like a problem since you won’t getmismatches.

• VHDL_SIM_STATUS integer;Specifies the frequency of status messages printed from the simulation testbenches, forVHDL. This keyword accepts an integer that it uses to output a message every ‘X’number of FastScan or FlexTest patterns. The simulation message will be “Simulated‘X’ patterns”.

• VHDL_SIGNAL_SPY {1 | 0};Specifies that the VHDL Parallel Testbench utilize the ModelSim® Signal Spy™ feature.Issuing a 1 (the default) with this keyword will produce a VHDL testbench that is simple

0110 mgcdft_shadow_control

0111 mgcdft_master_observe

1000 mgcdft_shadow_observe

1001 mgcdft_skew_load

1010 mgcdft_seq_transparent

1011 mgcdft_launch_capture

1100 mgcdft_shift

1101 mgcdft_clock_proc

1110 mgcdft_clock_proc_restore

1111 mgcdft_test_end

0000 mgcdft_unknown

Table 8-2. Translation Table

MGCDFT_VECTYP[0-3] Encoding Signal/Variable



August 2006

and efficient, however this testbench will only work with ModelSim v5.6 or later. Todeactivate this behavior, issue a 0 with this keyword.

• WGL_EDGE_STROBE {1 | 0};The default value of this keyword is 0. This keyword is only effected when thestrobe_window is set to 0, using the “set strobe_window time” command.

The WGL output will specify edge strobes by using the edge qualifier on the strobetimes specified in timeplate definitions. Additionally, an output value showing the ‘X’state will appear after the strobe time.

If the strobe_window is set to 0, then this additional output value showing the ‘X’ stateafter the strobe time can be eliminated from the outputted WGL by setting the keyword“WGL_EDGE_STROBE” to 1.

The following is an example of an edge strobe statement without and with usingWGL_EDGE_STROBE.

o WGL_EDGE_STROBE set to 0 (Default)

“outpin”:=output[0ns:X,300ns:Q’edge,350ns:X];

o WGL_EDGE_STROBE set to 1

“outpin”:=output[0ns:X,300ns:Q’edge];

• WGL_ADD_LASTX {1 | 0};Issuing a 1 with this keyword specifies for the WGL output module to add an additionalvector to the end of the pattern set. This vector will be a non-scan vector with all clocksturned off, all output pins set to “X” (not measuring), and all input pins set to the samevalue of the previous non-scan vector. To deactivate, issue a 0 (the default) with thiskeyword.

• WGL_VECTOR_ANN {1 | 0};Issuing a 1 with this keyword specifies for the WGL output module to add an annotationstatement to be generated in the pattern file, to denote the vector type. The default is 0.

• WGL_ALT_BIDI {1 | 0};Allows you to change the syntax of how bidirectional signals are represented in thevector pin list, and the actual states in the vector. The default representation specifies thebidirectional signal name, a colon, then an I or O, for the direction of that pin. Theremust be two entries for the bidirectional pin, one specifying the input side and onespecifying the output side. The vector lists a separate state for each. The default is 0.

The WGL_ALT_BIDI 1 setting changes the representation so that the pin list lists onlyone entry for the bidirectional pin with no direction, but with two states. Every state inthe actual vector is currently separated by spaces. With the addition of thisWGL_ALT_BIDI 1 setting, the states for the bidirectional pin will be listed side-by-sidewith no space separation. The input state will be listed first.

The default format of the vector order pin list and vector is as follows:



pattern test(“A”,”B”,”C”,”BiDi1:I”,”E”,”F”,”G”,”BiDi1:O”){Pattern 0 Cycle 0 Loop 0}vector(+,TP1):=[1 0 1 - 0 1 0 1];

The parameter file keyword “1” changes the vector order pinlist and vector to thefollowing:

pattern test(“A”,”B”,”C”,”BiDi1”,”E”,”F”,”G”){Pattern 0 Cycle 0 Loop 0}vector(+,TP1):=[1 0 1 - 1 0 1 0];

• WGL_GROUP_PIN {1 | 0};Issuing a 1 with this keyword specifies for the WGL output to create signal groups _PI_,_PO_, and _BIDI_ (if there are bidi’s). It then uses these groups in the pattern statementand in actual patterns for grouping states. To deactivate, issue a 0 (the default) with thiskeyword.

• WGL_ONE_ILLINOIS {1 | 0};This keyword when set to 1 (or true) will cause the WGL output to have only one scanstate defined per pattern for multiple scan chains that share a single scan input pin. Inother words, to force the tool to produce a single scan state for chains that share acommon scan input pin, use the WGL_ONE_ILLINOIS 1 parameter file keyword.

The default behavior when this keyword is set to 0 (or false) is to have scan statesdefined for each scan chain, whether or not they share scan input pins. The default forscan states when multiple scan chains share a common scan input is to list the scan statesfor each cell in each chain, the same as if the chains did not share a scan input.

• WGL_FULL_CHAIN {1 | 0};When set to 1 (true, the default) this keyword alters the scancell, scanchain, andscanstate sections of the WGL to reflect all cells in the chain, regardless of the numberof pre- or post-shifts (number of apply shifts). To deactivate, and for backwardscompatibility, issue a 0 (false).

• WGL_VERG_ESC {1 | 0};Issuing a 1 with this keyword specifies for busses to be expanded in the declarationsections of the WGL output. To deactivate, issue a 0 (the default) with this keyword.

• WGL_TRIM_PULSE {1 | 0};Issuing a 1 with this keyword will cause the input timing to drop the leading 0 ns force,to the off state of the clock. Removing the initial force to the off state of a clock may notbe appropriate for all testers and translation processes, and you need to understand alldownstream processes that will use the resultant files. To deactivate, issue a 0 (thedefault) with this keyword.

Note that the WGL_TRIM_PULSE keyword will generate illegal syntax in the WGLfile which may cause some WGL readers to have problems reading the file. Thefollowing warning message will be issued (once) if the keyword is specified in theparameter file and if there is at least one signal using the altered syntax:



August 2006

WGL_TRIM_PULSE:"WARNING: illegal WGL syntax, time 0 state removed from pulse(WGL_TRIM_PULSE) may not be compatible with all WGL readers"

Examples follow:

Parameter file : defaultIOclk := input [ 0ns:D, 200ns:S, 300ns:D ];IOclk := output [ 0ns:X, 300ns:Q, 400ns:X ];

Parameter file : WGL_TRIM_PULSE 1;IOclk := input [ 200ns:S, 300ns:D ];IOclk := output [ 0ns:X, 300ns:Q, 400ns:X ];

Parameter file : WGL_TRIM_PULSE 1;WGL_NOMEASURE_CLOCK 1;

IOclk := input [ 200ns:S, 300ns:D ];

• WGL_NOMEASURE_CLOCK {1 | 0};Issuing a 1 with this keyword will drop the measure timing from the timing statement forbidirectional clocks, and will also verify that this pin is never measured. If the pin ismeasured within the patterns, the output will generate an error and return to thecommand prompt. To deactivate, issue a 0 (the default) with this keyword.

Note that the WGL_NOMEASURE_CLOCK keyword may cause some WGL readersto have problems reading the file. The following warning message will be issued (once)if the keyword is specified in the parameter file and if there is at least one signal usingthe altered syntax:

WGL_NOMEASURE_CLOCK:"WARNING: questionable WGL syntax, no output timing for bidirect(WGL_NOMEASURECLOCK) may not be compatible with all WGL readers"

Examples follow:

Parameter file : defaultIOclk := input [ 0ns:D, 200ns:S, 300ns:D ];IOclk := output [ 0ns:X, 300ns:Q, 400ns:X ];

Parameter file : WGL_NOMEASURE_CLOCK 1;IOclk := input [ 0ns:D, 200ns:S, 300ns:D ];

Parameter file : WGL_TRIM_PULSE 1;WGL_NOMEASURE_CLOCK 1;

IOclk := input [ 200ns:S, 300ns:D ];

• TEST_SETUP_EXPECT {1 | 0};Issuing a 1 with this keyword specifies for the FlexTest Test Setup output module to put“expect” statements in the test_setup procedure. To deactivate, issue a 0 (the default)with this keyword. For more information, refer to the -Test_setup format switch underthe “Save Patterns” command in the ATPG and Failure Diagnosis Tools ReferenceManual.



• WGL_ALT_VECT_ANN {1 | 0};If set to 1, this keyword will use alternate annotation statements for beginnings ofpatterns and vector boundaries. These alternate annotations can help the WGL file beprocessed by other third party tools. The default is 0.

• WGL_INV_SC {1 | 0};If set to 1, this keyword will remove inversion data from scan chain definitions, andspecify scan data as it would appear to be shifted in, instead of parallel deposited.According to the WGL data model, a WGL file that uses this option no longer correctlymatches the design netlist. However, some third party tools work faster with theinversion data removed. The default is 0.

• WGL_PATTERN_NAME string;Changes the default name of the WGL pattern block from “Chain_scan_test” to thevalue of the string.

• WGL_VTRAN_PADSC {1 | 0};If set to 1, this keyword will pad all scan data to be same length. Padding all scan data tobe the same length violates the WGL syntax according to the TDS WGL documentation.However, some third party tools work better with the scan data padded. The default is 0.

• UTIC_LABEL string;Specifies a label string for use in the UTIC “FUNCTIONAL” block. This lets you writeout multiple smaller files where the functional bock label would be unique to the smallerfiles. The default is:

toolname_faulttype

For example, fastscan_stuck is the default label for stuck at patterns in FastScan.

• FTDL_TEST_NAME string ;String is the root name to be used for the test block(s) within the FTDL file. If notspecified, the default root name is “FN”. The root name is combined with a test numberto create each test block name.

• FTDL_TEST_NUM integer ;Integer is the starting test block number, to be appended to the root test block name. Foreach additional test block needed in the FTDL file, the test number is incremented. If notspecified, the starting test block number is 1.

• FTDL_MAX_PAT_BLOCK integer ;Integer is the maximum number of vector statements allowed in a single TEST block,including all shifted values and repeated vectors. If not specified, the default is5 million.

• FTDL_REVISION string ;String is an informational string to be used as the revision string in the REVISIONstatement at the top of the FTDL file. If not specified, the default is “0001”.



August 2006

• FTDL_DESIGNER string ;String is an informational string to be used as the designer name in the DESIGNERstatement at the top of the FTDL file. If not specified, the default is “ATPG”.

• FTDL_ZMODE_MES {0 | 1} ;This keyword controls whether or not the FTDL file will allow for Z values to bemeasured on output pins and output sides of bidi pins. If set to 0, then the“ZMODE = NOMES” statement will be placed in all TEST blocks within the FTDLfile, and no Z values will be used on output pins. If set to 1, then the “ZMODE = MES”statement will be placed in all TEST blocks, and Z values will be allowed on outputpins. The default is 0, NOMES.

Keywords FTDL_TEST_NAME and FTDL_TEST_NUM are used together to createthe name(s) of the TEST block(s) within the FTDL file.

Keyword FTDL_MAX_VEC_BLOCK is used to set the maximum number of vectorstatements allowed in a single TEST block within the FTLD file.

Keywords FTDL_REVISION and FTDL_DESIGNER simply supply informationalstrings to be used within the FTDL file.

Keyword FTDL_ZMODE_MES controls whether ZMODE = MES, orZMODE = NOMES, and is used in the FTDL file.

The following is an example parameter file for FTDL.

FTDL_TEST_NAME “MyTest” ;FTDL_REVISION “001.1” ;FTDL_DESIGNER “Smith” ;FTDL_ZMODE_MES 1 ;

• TITDL_KEEP_SCANOUT {1 | 0} ;Setting this keyword to 1 causes all SCANOUT statements to be issued, even if all of thescanout values for a specific pattern/chain are all X. The default is 0, do not keepscanout statements whose scanout values are all X when writing TITDL format vectors.

• TITDL_LIBRARY string;Specifies the string the tool uses in the

LIBRARY_TYPE=string

statement in the header of the TITDL output file. If not specified, the default is GS20.

• TITDL_CUSTOMER string;Specifies the string the tool uses in the

CUSTOMER=string

statement in the header of the TITDL output file. If not specified, the default is TEXASINSTRUMENTS.



• TITDL_PARTNUM string;Specifies the string the tool uses in the

TI_PART_NUMBER=string

statement in the header of the TITDL output file. If not specified, the default is F999999.

• TITDL_SETNAME string;Specifies the string the tool uses in the

PATTERN_SET_NAME=string

statement in the header of the TITDL output file. The string can be a maximum oftwenty characters. If not specified, the default is the filename with no extension.

• TITDL_SETTYPE string;Specifies the string the tool uses in the

PATTERN_SET_TYPE=string

statement in the header of the TITDL output file. If not specified, the default is SCAN.

• TITDL_CHAIN_SETTYPE string;Specifies the string used to set the chain type. If specified, the string will be used in theoutput of Chain_Test only patterns. If not specified, the default string is “SCANCHK”.

• TITDL_REVISION string;Specifies the string the tool uses in the

REVISION=string

statement in the header of the TITDL output file. If not specified, the default is 1.00.

• TITDL_PSEUDO_PREFIX string;Specifies the string that will be prepended to the name of the clock pin to create thename of the pseudo clock pin. If not specified, the default is “pseudo_”.

Example of the parameter file keyword to change the pseudo prefix:

TITDL_PSEUDO_PREFIX ps_ ;

Example of what the MUX_PIN statement looks like in the TITDL output. The clockpin is called “clock”, and the added pseudo clock pin is called “ps_clock” because of theuse of the above parameter file keyword.



August 2006

...CONNECT P,VAR =(in1, in2, clock, ps_clock, out1, out2),DEFPIN=(IN 4, OUT 2);PERIOD = 100 NS;CLOCK VAR=(clock),HOLD0 = 20 NS, HOLD1 = 10 NS, PATTERN = 010;CLOCK VAR = (ps_clock),HOLD0 = 60 NS, HOLD1 = 10 NS, PATTERN = 010;MUX_PIN clock, VAR=(clock, ps_clock);DELAY VAR = (in1),OFFSET = 0 NS;...

• ALL_NO_CYCLE_OPT {1 | 0};Issuing a 1 with this keyword specifies for all outputs to turn off cycle optimizations innon-scan areas of patterns and leave all cycles in the patterns. Issuing a 0 with thiskeyword (or omitting this keyword as it is the default), will allow the followingoptimization in cycles that are part of the Capture or Clock procedures: If any twoidentical cycles are generated and do not measure any outputs, the duplicate cycles willbe removed.

• ALL_NO_LOOP {0 | 1};Parameter file keyword to disable the use of “loops” or “repeat” statements to representsub_procedures. The default is off (0). See “Disabling Sub_procedure Looping” onpage 356 for more information.

• ALL_MIN_SCAN_LOAD {1 | 0};By default, all pattern outputs contain scan in and scan out data for each scan load.Setting this keyword to 1 allows a scan load to specify only scan in or scan out whenappropriate (first scan in). The default is 0.

• ALL_NO_PATTERN_TYPE {1 | 0};If set to 1, this keyword eliminates the pattern type annotation. This keyword applies toall Vector Interface formats. The default is 0.

• ALL_TIME_RESOLUTION integer;This keyword is used to specify the number of significant bits for floating point timenumbers. The maximum is 4, and the default is 3.

• ALL_FIXED_CYCLES {2 | 1 | 0};Issuing a 2 with this keyword causes the tool to compute the largest number of cyclesbetween scan loads by looking at all patterns in the pattern list, not just those beingsaved. Issuing a 1 with this keyword specifies that the patterns will contain an equalnumber of non-scan cycles between each scan chain loading. This non-scan cycle isapplied before the first shift cycle. The default is 0.

This will add “Shift” cycles before the regular apply shift of the load_unload procedure.It adds these additional cycles before the scan chain load to make all patterns have thesame total number of cycles per pattern, taking into account the differences in thenumber of capture cycles. The number of capture cycles can still vary depending on



what ATPG needed or was directed with the Named Capture Procedures. However, noadditional “Capture” cycles are added. The new cycles will use the timeplate that the“Shift” procedure uses.

• ALL_FLATTEN_TIMING {1 | 0};Issuing a 1 with this keyword will cause all outputs to compute existing timing equationsand use only the resulting numeric values in the output files. The default of 0 will resultin any output format which can support equation-based timing using the equations asthey are specified.

NoteThis keyword is intended for having pattern output files not contain equation-basedtiming that has been added to the procedure file and preserved in the tool. Test datalanguages such as WGL and STIL have the ability to express time values in the timingblocks, as numerical values or as equations based on variables. Using equation-basedtiming allows one value to be specified for a global attribute, such as the test cycle period,while other values are derived from this using equations.

• CTL_STIL_0 {1 | 0};This keyword, if set to 1, will cause the output to be backward compatible with theIEEE 1450.6 standard. The Environment block will be dropped and the STIL headerwill not mention the CTL extension. The default is 0.

NoteCTL (IEEE 1450.6) is an extension of STIL that creates a standard format to describe IPcore and SOC test information. IEEE 1450.6 is a Draft Standard. As of the date of thisrelease, the CTL output is in compliance with the “Complete Draft 0.3” version of thisstandard. As changes and upgrades are made to the standard, the output will be upgraded.

• CTL_STIL_1 {1 | 0};This keyword, if set to 1, will cause the output to eliminate all 1450.6 syntax, but leavethe IEEE 1450.1 syntax. The default, if not specified, is 0, which produces the full1450.6 and 1450.1 syntax used in the CTL output.

The CTL_STIL_0 parameter file keyword can be used in the CTL output to eliminatethe new 1450.1 features along with all of the 1450.6 syntax.

See also the Save Patterns -CTL command and switch. For more information on thiscommand and switch, see the Command Dictionary of the ATPG and Failure DiagnosisTools Reference Manual.

• CTL_ONE_PAT {1 | 0};This keyword, if set to 1, will cause all pattern data to be grouped into a single STILpattern block, instead of one pattern block per ATPG pattern. The default is 0.



August 2006

• CTL_ONE_PROTO {1 | 0};This keyword, if set to 1, will disallow protocol-level macros. The default of 0 allowsprotocol-level macros.

NoteIn addition to the three CTL parameter file keywords listed above, all parameter filekeywords for STIL output also work with CTL output. The tool-generated CTL outputcan be customized using the above three parameters to be a more structural STIL output.

• STIL_TRIM_PULSE {1 | 0};Issuing a 1 with this keyword will cause the input timing to drop the leading 0 ns force,to the off state of the clock. Removing the initial force to the off state of a clock may notbe appropriate for all testers and translation processes, and you need to understand alldownstream processes that will use the resultant files. To deactivate, issue a 0 (thedefault) with this keyword.

Examples follow:

Parameter file : defaultIOclk { LHX { ’0ns’ X; ’300ns’ H/L/X; ’400ns’ X; }

01 { ’0ns’ D; ’200ns’ U/D; ’300ns’ D } }

Parameter file : STIL_TRIM_PULSE 1;IOclk { LHX { ’0ns’ X; ’300ns’ H/L/X; ’400ns’ X; }

01 { ’200ns’ U/D; ’300ns’ D } }

Parameter file : STIL_TRIM_PULSE 1;STIL_NOMEASURE_CLOCK 1;

IOclk { 01 { ’200ns’ U/D; ’300ns’ D } }

• STIL_NOMEASURE_CLOCK {1 | 0};Issuing a 1 with this keyword will drop the measure timing from the timing statement forbidirectional clocks, and will also verify that this pin is never measured. If the pin ismeasured within the patterns, the output will generate an error and return to thecommand prompt. To deactivate, issue a 0 (the default) with this keyword.

Examples follow:

Parameter file : defaultIOclk { LHX { ’0ns’ X; ’300ns’ H/L/X; ’400ns’ X; }

01 { ’0ns’ D; ’200ns’ U/D; ’300ns’ D } }

Parameter file : STIL_NOMEASURE_CLOCK 1;IOclk { 01 { ’0ns’ D; ’200ns’ U/D; ’300ns’ D } }

Parameter file : STIL_TRIM_PULSE 1;STIL_NOMEASURE_CLOCK 1;

IOclk { 01 { ’200ns’ U/D; ’300ns’ D } }

• STIL_SCAN_ANN1 string %special_keyword string2;Specifies the string the tool outputs to the STIL pattern just prior to the first scan pattern.There is only one STIL_SCAN_ANN1 statement written for each pattern file generated.



annotation “string %keywords string”

The following example shows lines in a parameter file and the resultant text generated inthe output pattern file.

o Parameter File Entry

STIL_SCAN_ANN1 "Scan Chain:%chain, length:%length,SI:%scan_in, SO:%scan_out"

o Resultant Pattern File statement

Ann {*"Scan Chain:chain1, length:2, SI:scan_in1, SO:Q" *}

• STIL_PAT_ANN string %special_keyword string2;Specifies the string the tool outputs to the STIL pattern file just prior to each scanpattern.


The following example shows lines in a parameter file and the resultant text generated inthe output pattern file.

o Parameter File Entry

STIL_PAT_ANN "Pattern Number:%pat_num(%pat_num_plus1), Cycle Number:%cycle_num"

o Resultant Pattern File statement

Ann {* "Pattern Number:0 (1), Cycle Number:0" *}

• STIL_PAT_CMT {1 | 0};This keyword can be used to turn on or off (1 or 0) the pattern comment which precedeseach FastScan pattern. The default is 1.

• STIL_PAT_LAB {1 | 0};This keyword can be used to turn on or off (1 or 0) the pattern label which precedes eachFastScan pattern. The default is 1.

• STIL_2005_SCAN {1 | 0};Issuing a 1 with this keyword is similar to the STIL_STRUCTURAL keyword except itwill also use the IEEE 1450.1 ScanStructures block. The default, if not specified, is 0,which produces the existing IEEE 1450.0 ScanStructures block.

Using the STIL_2005_SCAN keyword, the CTL output will be using the 1450.1ScanStructures block by default. The CTL_STIL_0 parameter file keyword can be usedin the CTL output to eliminate the new 1450.1 features along with all of the 1450.6syntax. The parameter file keyword CTL_STIL_1 can be used to eliminate all 1450.6syntax but leave the 1450.1 syntax.

Note that the ScanStructures in your STIL structure must match the compressedstructure.



August 2006

In order to use this output, you must use the Save Patterns -STIL2005 command andswitch. For more information on this command and switch, see the CommandDictionary of the ATPG and Failure Diagnosis Tools Reference Manual.

The following is an example of the IEEE 1450.1 ScanStructures block in the new STILoutput:

STIL 1.0 { Design 2005;}Header { Title “pat.stil" ; Date "Wed Mar 22 12:37:30 2006" ; Source "FastScan v8.2006_2.01-prerelease" ; History { ... }}...ScanStructures { ScanChain chain { ScanLength 8; ScanInversion 1; ScanCellType {CellIn SI; CellOut Q; } ScanCellType CTSIQB { CellIn SI; CellOut ! QB; }

ScanCells { “reg[7]” ; “reg[6]” ; “reg[5]” ; “reg[4]” ; “reg[3]” CTSIQB; “reg[2]” CTSIQB ; “reg[1]” CTSIQB ; ! ; “reg[0]” CTSIQB ; } ... }}

...

• STIL_MIN_QUOTE {1 | 0} ;Issuing a 1 with this keyword is for STIL2005 and CTL outputs, and will cause the STILfile to be written using minimum quoting of signal names that use reserved characters.Further, the existing STIL1999 output can be changed to use the same minimum quotingrules. The default, if not specified, is 0 for the STIL1999 output.

• STIL_STRUCTURAL {1 | 0} ;Issuing a 1 with this keyword will cause the STIL file to be written using a morestructural form. This keyword results in a STIL output form that uses some of the basichierarchical approaches of CTL output, but not any of the IEEE 1450.6 CTL syntaxextensions. As with CTL output, the structural STIL output will create STIL Macrodefinitions for all used procedures, and a STIL Procedure definition for the test_setupprocedure, if present. The start of each pattern will still consist of an annotationstatement and a pattern label. Each pattern will consist of the calls to each specificMacro, passing all needed data. Unlike the CTL output, a new “pattern type” macro willnot be created for each pattern, and the pattern data will not be placed in a separate fileand included with the “Include” statement.

To produce a flat or non-hierarchical set of vector data, issue a 0 (the default) with thiskeyword.

The following is an example of the structural STIL output:

STIL 1.0 ;



Header { ... }

// Parameter File Keyword Settings// STIL_STRUCTURAL true ;

Signals {"IN"[3..0] In; "CLK" In; "SDI" In; "SE" In;"OUT"[3..0] Out; "SDO" Out;

}

SignalGroups {_pi_[6..0] = ’"IN"[3..0] + "CLK" + "SDI" + "SE"’;_po_[4..0] = ’"OUT"[3..0] + "SDO"’;PI_grp_0[5..0] = ’"IN"[3..0] + "SDI" + "SE"’;PI_grp_1 = ’"CLK"’;"_chain_SDI_" = ’"SDI"’ {ScanIn 10;}"_chain_SDO_" = ’"SDO"’ {ScanOut 10;}

}

Timing TRANSITION_timing {WaveformTable tset_tp_shift {

Period ’400ns’ ;Waveforms {

PI_grp_0 { 01X { ’0ns’ D/U/N; }}PI_grp_1 { 01 { ’0ns’ D; ’100ns’ D/U; ’400ns’ D;}}_po_ { LHXZ { ’0ns’ X; ’50ns’ l/h/X/t; ’52ns’ X;}}

}}WaveformTable tset_tp_capture {

Period ’400ns’ ;Waveforms {

PI_grp_0 { 01X { ’0ns’ D/U/N; }}PI_grp_1 { 01 { ’0ns’ D; ’100ns’ D/U; ’400ns’ D;}}_po_ { LHXZ { ’0ns’ X; ’50ns’ l/h/X/t; ’52ns’ X;}}

}}

}

ScanStructures { ScanChain chain { ... } }

Procedures {test_setup {

W tset_tp_shift;V { "SE" = 0; }

}}

MacroDefs {load_unload_grp1 {

W tset_tp_shift;V { "CLK" = 0; }Shift { V { "SE" = 1; "_chain_SDI_" = #;

"_chain_SDO_" = #; "CLK" = 1; }}

}

capture {W tset_tp_shift;



August 2006

V { _pi_ = %; _po_ = %; PI_grp_1 = %; }}

}

PatternBurst scanpats { PatList { scan_test } }

PatternExec scanexec {Timing TRANSITION_timing;PatternBurst scanpats;

}

Pattern "scan_test" {Call test_setup ;Ann {* Begin chain test *}Ann {* Chain Pattern:0 Cycle:1 Loop:1 *}...Ann {* End chain test *}Ann {* Pattern:0 Cycle:7 Loop:10 *}"pattern 0": Macro "load_unload_grp1" {

"_chain_SDI_" = 1010001110;"_chain_SDO_" = XXXXXXXXXX;

}Macro "capture" {

_pi_ = X101011;_po_ = LLHHH;

PI_grp_1 = 1;}

...Ann {* Pattern:7 Cycle:24 Loop:52 *}"pattern 0": Macro "load_unload_grp1" {

"_chain_SDI_" = 1010010000;"_chain_SDO_" = HHLHHLLLLL;

}

Macro "capture" {_pi_ = X000011;_po_ = LHHLL;PI_grp_1 = 1;

}

last_unload: Macro "load_unload_grp1" {"_chain_SDI_" = 1010010000;"_chain_SDO_" = LHLLLHLLLH;}

}

• STIL_VECTOR_ANN string %special_keyword string2;Specifies the vector types to be added to the output pattern file.




NoteThe parameter file keywords, STIL_SCAN_ANN1, STIL_PAT_ANN, andSTIL_VECTOR_ANN can use a (%special_keyword) that is translated at the specifictime and place the annotation statement will be written. Table 8-3 lists the availablespecial keyword

NoteYou must not use the “%” symbol as the leading character to any string fragment inconjunction with the %special_keyword.

Table 8-3. STIL Special Keywords

Keyword Description

%chain The chain name of the current chain.

%length The length of the current chain.

%scan_in The name of the Primary Input pin for the current chain.

%scan_out The name of the Primary Output pin for the current chain.

%pat_num The current FastScan, FlexTest, or TestKompress patternnumber.

%pat_num_plus1 The current FastScan, FlexTest, or TestKompress patternnumber plus 1.

%cycle_num The current FastScan, FlexTest, or TestKompress cyclenumber.

%pattern_type The pattern type, for outputting annotations in the patternfile. It causes one of the pattern types in Table 8-4 to bewritten into the pattern file.

%vector_type This keyword causes one of the vector types in Table 8-5 tobe written into the pattern file.

Table 8-4. STIL Pattern Types

clock_po clock_sequential ram_sequential

ram_passthru macrotest basic

multi_load



August 2006

Table 8-5. STIL Vector Types

TEST_SETUP LOAD_UNLOAD SHIFT

SINGLE_SHIFT SHADOW_CONTROL MASTER_OBSERVE

SHADOW_OBSERVE SKEW_LOAD SEQ_TRANSPARENT

PRIMARY PRIMARY_IDDQ PRIMARY_MEASURE

PRIMARY_MEASURE_IDDQ

PRIMARY_CLOCKPO PRIMARY_CLOCKPO_IDDQ

SCAN_IN SCAN_OUT SCAN_IO

CLOCK_PROCEDURE CLOCK_PROCEDURE_RESTORE

CORE_INST_TEST

CORE_INST_ISOLATE CORE_ACCESS


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 the following sources:

• Documentation

• Online Command Help

• Mentor Graphics Support

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:


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. For more information, see the Help command in theATPG and Failure Diagnosis Tools Reference Manual.

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://www.mentor.com/supportnet/options

http://www.mentor.com/supportnet/options



Getting HelpMentor Graphics Support

August 2006

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:


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://www.mentor.com/supportnet/quickaccess/SelfReg.do

All customer support contact information can be found on our web site at:

http://www.mentor.com/supportnet/support_offices.html


http://www.mentor.com/supportnet/quickaccess/SelfReg.do

http://www.mentor.com/supportnet/support_offices.html

387

A B F GDC E H I J K L M N O P Q R S T U V XW Y Z

Design-for-Test Common Resources Manual, V8.2006_3August 2006

— Symbols —#include statement, 314

— A —A rules, 105Alias statements, 317ALL_FIXED_CYCLES, 376ALL_FLATTEN_TIMING, 377ALL_MIN_SCAN_LOAD, 376ALL_NO_CYCLE_OPT, 376ALL_NO_LOOP, 376ALL_NO_PATTERN_TYPE, 376ALL_TIME_RESOLUTION, 376Array

delimiter, 211library model attribute, 211RAM example, 211ROM example, 256, 259

— B —B rules, 109BIST rules, 109

— C —C rules, 70Clock cone, 79, 86Clock procedure, 340 to 341CTL_ONE_PAT, 377CTL_ONE_PROTO, 378CTL_STIL_0, 377CTL_STIL_1, 377CTL_TRIM_PULSE, 378Cycle statements

bidi_force_off, 328bidi_force_pi, 327bidi_measure_po, 328condition, 328expect, 328force, 328force_pi, 327force_sci, 327

force_sci_equiv, 328initialize, 329measure, 329measure_misr, 329measure_po, 328measure_sco, 328observe_method, 329pulse, 329pulse_capture_clock, 328pulse_read_clock, 328pulse_write_clock, 328restore_bidi, 328restore_pi, 328

— D —D rules, 56Design rules checking

AVI warning and error messages, 154 to155

basic troubleshooting, 26 to 32BIST rules, 109 to 112clock rules, 70 to 105data rules, 56 to 69EDT rules, 116 to 127extra rules, 127 to 143general rules, 33 to 35procedure rules, 36 to 50RAM rules, 105 to 109reporting gate data, 29scannability rules, 143 to 145setting gate data, 28setting gate level, 27setting rule handling, 26timing rules, 146 to 150trace rules, 50 to 56troubleshooting with DFTInsight, 177 to

178with ATPG analysis, 26within DFTAdvisor, 25within FastScan, 25

Index

388August 2006



within FlexTest, 25DFTInsight

deleting instances from display, 176displaying delay paths, 175displaying feedback loops, 176displaying levels of input circuitry, 173displaying levels of output circuitry, 174displaying path between instances, 174displaying scan cells in a chain, 175displaying specific gates, 172displaying trace back cone, 172displaying trace forward cone, 173exiting, 180functionality, 162inputs and outputs, 161invoking session, 167loading schematic, 179marking instances, 177modes, 166overview, 159 to 163printing, 180reporting, 179saving schematic, 179saving the transcript, 180selecting objects, 166selection modes, 166session window, 164setting and saving preferences, 165strokes, 165tasks, 167 to 180troubleshooting DRC violations, 177user interface, 163viewing modes, 166

DRC messagesoscillation limitation, 156other DRC messages, 155RAM summary results and test capability,

156transparent capture handling analysis, 155

— E —E rules, 127Effect cone, 79Example

PLL model and named capture procedure,347

— F —FastScan commands

flatten model, 161report DRC rules, 32set DRC handling, 26set trace report, 32

FDTL_TEST_NAME, 373FDTL_TEST_NUM, 373FlexTest commands

flatten model, 161report DRC rules, 32set DRC handling, 26set trace report, 32

FTDL parameter file example, 374FTDL_DESIGNER, 374FTDL_MAX_PAT_BLOCK, 373FTDL_REVISION, 373FTDL_ZMODE_MES, 374

— G —G rules, 33

— I —Include statement, 314Initialization files, 261

— K —K rules, 116Keywords

ALL_FIXED_CYCLES, 376ALL_FLATTEN_TIMING, 377ALL_MIN_SCAN_LOAD, 376ALL_NO_CYCLE_OPT, 376ALL_NO_LOOP, 376ALL_NO_PATTERN_TYPE, 376ALL_TIME_RESOLUTION, 376CTL_ONE_PAT, 377CTL_ONE_PROTO, 378CTL_STIL_0, 377CTL_STIL_1, 377CTL_TRIM_PULSE, 378FTDL_DESIGNER, 374FTDL_MAX_PAT_BLOCK, 373FTDL_REVISION, 373FTDL_TEST_NAME, 373FTDL_TEST_NUM, 373

389Design-for-Test Common Resources Manual, V8.2006_3August 2006


FTDL_ZMODE_MES, 374SIM_SHIFT_DEBUG, 365STIL_2005_SCAN, 379STIL_MIN_QUOTE, 380STIL_NOMESURE_CLOCK, 378STIL_PAT_ANN, 379STIL_PAT_CMT, 379STIL_PAT_LAB, 379STIL_SCAN_ANN1, 378STIL_STRUCTURAL, 380STIL_VECTOR_ANN, 382TEST_SETUP_EXPECT, 372TITDL_CHAIN_SETTYPE, 375TITDL_CUSTOMER, 374TITDL_KEEP_SCANOUT, 374TITDL_LIBRARY, 374TITDL_PARTNUM, 375TITDL_PSEUDO_PREFIX, 375TITDL_REVISION, 375TITDL_SETNAME, 375TITDL_SETTYPE, 375UTIC_LABEL, 373VERILOG_COMPARE_X, 369VERILOG_EARLY_RELEASE, 367VERILOG_EARLY_RELEASE_TIME,

367VERILOG_INCLUDE, 366VERILOG_KEEP_PATH, 366VERILOG_MASK_FILE, 368VERILOG_MODULE_INCLUDE, 366VERILOG_NO_MEASURE_IN, 367VERILOG_SIM_STATUS, 367VERILOG_TOP_NAME, 366VERILOG_UNCOMPRESS_PAT, 368VERILOG_VECTOR_COMM, 366VERILOG_VECTYPE_SIGNAL, 368VHDL_SIGNAL_SPY, 369VHDL_SIM_STATUS, 369WGL_ADD_LASTX, 370WGL_ALT_BIDI, 370WGL_ALT_VECT_ANN, 373WGL_EDGE_STROBE, 370WGL_FULL_CHAIN, 371WGL_GROUP_PIN, 371WGL_INV_SC, 373

WGL_NOMEASURE_CLOCK, 372WGL_ONE_ILLINOIS, 371WGL_PATTERN_NAME, 373WGL_TRIM_PULSE, 371WGL_VECTOR_ANN, 370WGL_VERG_ESC, 371WGL_VTRAN_PADSC, 373

— L —lcVerify

invocation, 294overview, 293results files, 295

sim.log, 295transcript, 295verify.results, 295

running from the shell, 294troubleshooting

DRC violations, 300impact of low coverage, 301one model at a time, 301test coverage, 301

Library compiler commandsadd model, 274delete model, 275dofile, 276exit, 277help, 278load library, 279report gate, 280report model, 281run, 281set dofile abort, 284, 285, 286set gate report, 287set system mode, 287set verification, 288system, 290write library, 291

Library verification, 293

— M —Modeling for optimal test coverage, 302

— N —Named capture procedure, 343

390August 2006



— O —Oscillation limitation, 156

— P —P rules, 36Parameter file, 364, 383Parameter file keywords

FTDL_DESIGNER, 374FTDL_MAX_PAT_BLOCK, 373FTDL_REVISION, 373FTDL_TEST_NAME, 373FTDL_TEST_NUM, 373FTDL_ZMODE_MES, 374

PLL model and named capture procedureexample, 347

Preferences, DFTInsight setting and saving,165

Procedure statementsapply, 327cycle, 325scan_group, 327timeplate, 327

pulse generators, 252

— R —RAM

_cram model example, 258_ram model example, 257array example, 256, 259example, 255initialization files, 261library primitives, 255limitations, 267model attributes, 259modeling, 253 to 267port behavior, 262read_write port behavior, 265rules checking, 105 to 109

RAM summary results and test capability, 156ROM

_rom model example, 256array example, 256, 259example, 254initialization files, 261limitations, 266model attributes, 259

modeling, 253 to 267port behavior, 262read_write port behavior, 265

— S —Sequential_transparent procedure, 338 to 340Set statement, 315Set statements

default_timeplate, 317strobe_window time, 316time scale, 315

Shift procedure, 331alternate, 333

SIM_SHIFT_DEBUG, 365Simulation mismatches

for ChainTest patterns, 368STIL parameter, 364STIL_2005_SCAN, 379STIL_MIN_QUOTE, 380STIL_NOMESURE_CLOCK, 378STIL_PAT_ANN, 379STIL_PAT_CMT, 379STIL_PAT_LAB, 379STIL_SCAN_ANN1, 378STIL_STRUCTURAL, 380STIL_VECTOR_ANN, 382Sub_procedure, 356

— T —T rules, 50Test procedure file

comparison to old format, 357defined, 311DRC checking, 311procedures, 329statements, 315syntax rules, 311timing variables, 318

Test procedurescapture, 342clock_po, 348clock_sequential, 350init_force, 351load_unload, 334master_observe, 337ram_passthru, 349

391Design-for-Test Common Resources Manual, V8.2006_3August 2006


ram_sequential, 348sequential, 353shadow_control, 336shadow_observe, 338shift, 331skew_load, 341sub_procedure, 356test_end, 351test_setup, 330

Test_end procedure, 351TEST_SETUP_EXPECT, 372Time scale

setting, 315Timeplate statements

bidi_force_pi, 322bidi_measure_po, 322double_pulse, 323force, 322force_pi, 322measure, 323measure_po, 322offstate, 322period, 323pulse, 323

TITDL parameters, 364TITDL_CHAIN_SETTYPE, 375TITDL_CUSTOMER, 374TITDL_KEEP_SCANOUT, 374TITDL_LIBRARY, 374TITDL_PARTNUM, 375TITDL_PSEUDO_PREFIX, 375TITDL_REVISION, 375TITDL_SETNAME, 375TITDL_SETTYPE, 375Transcript DFTInsight, 180Transparent capture handling analysis, 155Transparent_capture cells, 67, 69, 340Troubleshooting rule violations, 177tscale, 315

— U —UTIC parameter, 364UTIC_LABEL, 373

— V —Verilog parameters, 364

VERILOG_COMPARE_X, 369VERILOG_EARLY_RELEASE, 367VERILOG_EARLY_RELEASE_TIME, 367VERILOG_INCLUDE, 366VERILOG_KEEP_PATH, 366VERILOG_MASK_FILE, 368VERILOG_MODULE_INCLUDE, 366VERILOG_NO_MEASURE_IN, 367VERILOG_SIM_STATUS, 367VERILOG_TOP_NAME, 366VERILOG_UNCOMPRESS_PAT, 368VERILOG_VECTOR_COMM, 366VERILOG_VECTYPE_SIGNAL, 368VHDL Support, 303VHDL_SIGNAL_SPY, 369VHDL_SIM_STATUS, 369

— W —WGL_ADD_LASTX, 370WGL_ALT_BIDI, 370WGL_ALT_VECT_ANN, 373WGL_EDGE_STROBE, 370WGL_GROUP_PIN, 371WGL_INV_SC, 373WGL_NOMEASURE_CLOCK, 372WGL_ONE_ILLINOIS, 371WGL_PATTERN_NAME, 373WGL_TRIM_PULSE, 371WGL_VECTOR_ANN, 370WGL_VERG_ESC, 371WGL_VTRAN_PADSC, 373

392August 2006



End-User License AgreementThe latest version of the End-User License Agreement is available on-line at:

www.mentor.com/terms_conditions/enduser.cfm

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software between you, the end user, as an authorizedrepresentative of the company acquiring the license, and Mentor Graphics Corporation and Mentor Graphics(Ireland) Limited acting directly or through their subsidiaries (collectively “Mentor Graphics”). Except for licenseagreements related to the subject matter of this license agreement which are physically signed by you 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. If youdo not agree to these terms and conditions, promptly return or, if received electronically, certify destruction ofSoftware and all accompanying items within five days after receipt of Software and receive a full refund of anylicense fee paid.

1. GRANT OF LICENSE. The software programs, including any updates, modifications, revisions, copies, documentationand design data (“Software”), are copyrighted, trade secret and confidential information of Mentor Graphics or itslicensors who maintain exclusive title to all Software and retain all rights not expressly granted by this Agreement.Mentor Graphics grants to you, subject to payment of appropriate license fees, a nontransferable, nonexclusive license touse Software solely: (a) in machine-readable, object-code form; (b) for your internal business purposes; (c) for the licenseterm; and (d) on the computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-halfmile (800 meter) radius. Mentor Graphics’ standard policies and programs, which vary depending on Software, licensefees paid or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may belimited, for example, to execution of a single session by a single user on the authorized hardware or for a restricted periodof time (such limitations may be technically implemented through the use of authorization codes or similar devices); and(c) support services provided, including eligibility to receive telephone support, updates, modifications, and revisions.

2. EMBEDDED SOFTWARE. If you purchased a license to use embedded software development (“ESD”) Software, ifapplicable, Mentor Graphics grants to you a nontransferable, nonexclusive license to reproduce and distribute executablefiles created using ESD compilers, including the ESD run-time libraries distributed with ESD C and C++ compilerSoftware that are linked into a composite program as an integral part of your compiled computer program, provided thatyou distribute these files only in conjunction with your compiled computer program. Mentor Graphics does NOT grantyou any right to duplicate, incorporate or embed copies of Mentor Graphics' real-time operating systems or otherembedded software products into your products or applications without first signing or otherwise agreeing to a separateagreement with Mentor Graphics for such purpose.

3. BETA CODE. Software may contain code for experimental testing and evaluation (“Beta Code”), which may not be usedwithout Mentor Graphics’ explicit authorization. Upon Mentor Graphics’ authorization, Mentor Graphics grants to you atemporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Code without chargefor a limited period of time specified by Mentor Graphics. This grant and your use of the Beta Code shall not be construedas marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not to releasecommercially in any form. If Mentor Graphics authorizes you to use the Beta Code, you agree to evaluate and test theBeta Code under normal conditions as directed by Mentor Graphics. You will contact Mentor Graphics periodicallyduring your use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of yourevaluation and testing, you will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,weaknesses and recommended improvements. You agree that any written evaluations and all inventions, productimprovements, modifications or developments that Mentor Graphics conceived or made during or subsequent to thisAgreement, including those based partly or wholly on your feedback, will be the exclusive property of Mentor Graphics.Mentor Graphics will have exclusive rights, title and interest in all such property. The provisions of this section 3 shallsurvive the termination or expiration of this Agreement.

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

4. RESTRICTIONS ON USE. You may copy Software only as reasonably necessary to support the authorized use. Eachcopy must include all notices and legends embedded in Software and affixed to its medium and container as received fromMentor Graphics. All copies shall remain the property of Mentor Graphics or its licensors. You shall maintain a record ofthe number and primary location of all copies of Software, including copies merged with other software, and shall makethose records available to Mentor Graphics upon request. You shall not make Software available in any form to anyperson other than employees and on-site contractors, excluding Mentor Graphics' competitors, whose job performancerequires access and who are under obligations of confidentiality. You shall take appropriate action to protect theconfidentiality of Software and ensure that any person permitted access to Software does not disclose it or use it except aspermitted by this Agreement. Except as otherwise permitted for purposes of interoperability as specified by applicableand mandatory local law, you shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive fromSoftware any source code. You may not sublicense, assign or otherwise transfer Software, this Agreement or the rightsunder it, whether by operation of law or otherwise (“attempted transfer”), without Mentor Graphics’ prior written consentand payment of Mentor Graphics’ then-current applicable transfer charges. Any attempted transfer without MentorGraphics' prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics' option, result inthe immediate termination of the Agreement and licenses granted under this Agreement. The terms of this Agreement,including without limitation, the licensing and assignment provisions shall be binding upon your successors in interestand assigns. The provisions of this section 4 shall survive the termination or expiration of this Agreement.

5. LIMITED WARRANTY.

5.1. Mentor Graphics warrants that during the warranty period Software, when properly installed, will substantiallyconform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrantthat Software will meet your requirements or that operation of Software will be uninterrupted or error free. Thewarranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Youmust notify Mentor Graphics in writing of any nonconformity within the warranty period. This warranty shall not bevalid if Software has been subject to misuse, unauthorized modification or improper installation. MENTORGRAPHICS' ENTIRE LIABILITY AND YOUR EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS'OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF SOFTWARE TO MENTORGRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF SOFTWARE THAT DOES NOT MEET THISLIMITED WARRANTY, PROVIDED YOU HAVE OTHERWISE COMPLIED WITH THIS AGREEMENT.MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B) SOFTWAREWHICH IS LICENSED TO YOU FOR A LIMITED TERM OR LICENSED AT NO COST; OR(C) EXPERIMENTAL BETA CODE; ALL OF WHICH ARE PROVIDED “AS IS.”

5.2. THE WARRANTIES SET FORTH IN THIS SECTION 5 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICSNOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, WITHRESPECT TO SOFTWARE OR OTHER MATERIAL PROVIDED UNDER THIS AGREEMENT. MENTORGRAPHICS AND ITS LICENSORS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OFINTELLECTUAL PROPERTY.

6. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITYWOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICSOR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES(INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHERLEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THEPOSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS' OR ITS LICENSORS'LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT PAID BY YOU FOR THE SOFTWARE ORSERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTORGRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THEPROVISIONS OF THIS SECTION 6 SHALL SURVIVE THE EXPIRATION OR TERMINATION OF THISAGREEMENT.

7. LIFE ENDANGERING ACTIVITIES. NEITHER MENTOR GRAPHICS NOR ITS LICENSORS SHALL BELIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITH THE USE OF SOFTWARE INANY APPLICATION WHERE THE FAILURE OR INACCURACY OF THE SOFTWARE MIGHT RESULT INDEATH OR PERSONAL INJURY. THE PROVISIONS OF THIS SECTION 7 SHALL SURVIVE THEEXPIRATION OR TERMINATION OF THIS AGREEMENT.

8. INDEMNIFICATION. YOU AGREE TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITSLICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE, OR LIABILITY, INCLUDINGATTORNEYS' FEES, ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF SOFTWARE AS

DESCRIBED IN SECTION 7. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THE EXPIRATION ORTERMINATION OF THIS AGREEMENT.

9. INFRINGEMENT.

9.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against you alleging thatSoftware infringes a patent or copyright or misappropriates a trade secret in the United States, Canada, Japan, ormember state of the European Patent Office. Mentor Graphics will pay any costs and damages finally awardedagainst you that are attributable to the infringement action. You understand and agree that as conditions to MentorGraphics' obligations under this section you must: (a) notify Mentor Graphics promptly in writing of the action;(b) provide Mentor Graphics all reasonable information and assistance to defend or settle the action; and (c) grantMentor Graphics sole authority and control of the defense or settlement of the action.

9.2. If an infringement claim is made, Mentor Graphics may, at its option and expense: (a) replace or modify Software sothat it becomes noninfringing; (b) procure for you the right to continue using Software; or (c) require the return ofSoftware and refund to you any license fee paid, less a reasonable allowance for use.

9.3. Mentor Graphics has no liability to you if infringement is based upon: (a) the combination of Software with anyproduct not furnished by Mentor Graphics; (b) the modification of Software other than by Mentor Graphics; (c) theuse of other than a current unaltered release of Software; (d) the use of Software as part of an infringing process; (e) aproduct that you make, use or sell; (f) any Beta Code contained in Software; (g) any Software provided by MentorGraphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; or (h) infringement byyou that is deemed willful. In the case of (h) you shall reimburse Mentor Graphics for its attorney fees and other costsrelated to the action upon a final judgment.

9.4. THIS SECTION IS SUBJECT TO SECTION 6 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTORGRAPHICS AND ITS LICENSORS AND YOUR SOLE AND EXCLUSIVE REMEDY WITH RESPECT TOANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR TRADE SECRET MISAPPROPRIATIONBY ANY SOFTWARE LICENSED UNDER THIS AGREEMENT.

10. TERM. This Agreement remains effective until expiration or termination. This Agreement will immediately terminateupon notice if you exceed the scope of license granted or otherwise fail to comply with the provisions of Sections 1, 2, or4. For any other material breach under this Agreement, Mentor Graphics may terminate this Agreement upon 30 dayswritten notice if you are in material breach and fail to cure such breach within the 30 day notice period. If Software wasprovided for limited term use, this Agreement will automatically expire at the end of the authorized term. Upon anytermination or expiration, you agree to cease all use of Software and return it to Mentor Graphics or certify deletion anddestruction of Software, including all copies, to Mentor Graphics’ reasonable satisfaction.

11. EXPORT. Software is subject to regulation by local laws and United States government agencies, which prohibit exportor diversion of certain products, information about the products, and direct products of the products to certain countriesand certain persons. You agree that you will not export any Software or direct product of Software in any manner withoutfirst obtaining all necessary approval from appropriate local and United States government agencies.

12. RESTRICTED RIGHTS NOTICE. Software was developed entirely at private expense and is commercial computersoftware provided with RESTRICTED RIGHTS. Use, duplication or disclosure by the U.S. Government or a U.S.Government subcontractor is subject to the restrictions set forth in the license agreement under which Software wasobtained pursuant to DFARS 227.7202-3(a) or as set forth in subparagraphs (c)(1) and (2) of the Commercial ComputerSoftware - Restricted Rights clause at FAR 52.227-19, as applicable. Contractor/manufacturer is Mentor GraphicsCorporation, 8005 SW Boeckman Road, Wilsonville, Oregon 97070-7777 USA.

13. THIRD PARTY BENEFICIARY. For any Software under this Agreement licensed by Mentor Graphics from Microsoftor other licensors, Microsoft or the applicable licensor is a third party beneficiary of this Agreement with the right toenforce the obligations set forth herein.

14. AUDIT RIGHTS. You will monitor access to, location and use of Software. With reasonable prior notice and duringyour normal business hours, Mentor Graphics shall have the right to review your software monitoring system andreasonably relevant records to confirm your compliance with the terms of this Agreement, an addendum to thisAgreement or U.S. or other local export laws. Such review may include FLEXlm or FLEXnet report log files that youshall capture and provide at Mentor Graphics’ request. Mentor Graphics shall treat as confidential information all of yourinformation gained as a result of any request or review and shall only use or disclose such information as required by lawor to enforce its rights under this Agreement or addendum to this Agreement. The provisions of this section 14 shallsurvive the expiration or termination of this Agreement.

15. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. THIS AGREEMENT SHALL BEGOVERNED BY AND CONSTRUED UNDER THE LAWS OF THE STATE OF OREGON, USA, IF YOU ARELOCATED IN NORTH OR SOUTH AMERICA, AND THE LAWS OF IRELAND IF YOU ARE LOCATEDOUTSIDE OF NORTH OR SOUTH AMERICA. All disputes arising out of or in relation to this Agreement shall besubmitted to the exclusive jurisdiction of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when thelaws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia (except for Japan) arising out of or in relation tothis Agreement shall be resolved by arbitration in Singapore before a single arbitrator to be appointed by the Chairman ofthe Singapore International Arbitration Centre (“SIAC”) to be conducted in the English language, in accordance with theArbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by referencein this section 15. This section shall not restrict Mentor Graphics’ right to bring an action against you in the jurisdictionwhere your place of business is located. The United Nations Convention on Contracts for the International Sale of Goodsdoes not apply to this Agreement.

16. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid,unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain infull force and effect.

17. PAYMENT TERMS AND MISCELLANEOUS. You will pay amounts invoiced, in the currency specified on theapplicable invoice, within 30 days from the date of such invoice. Any past due invoices will be subject to the impositionof interest charges in the amount of one and one-half percent per month or the applicable legal rate currently in effect,whichever is lower. Some Software may contain code distributed under a third party license agreement that may provideadditional rights to you. Please see the applicable Software documentation for details. This Agreement may only bemodified in writing by authorized representatives of the parties. Waiver of terms or excuse of breach must be in writingand shall not constitute subsequent consent, waiver or excuse.

Rev. 060210, Part No. 227900

Dft Common

Documents

Transcript of Dft Common