Dft Common

Tessent Common Resources Manual forATPG Products

Software Version v9.2

November 2010

© 1999-2010 Mentor Graphics CorporationAll rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of thisdocument may duplicate this document in whole or in part for internal business purposes only, provided that this entirenotice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonableeffort to prevent the unauthorized use and distribution of the proprietary information.

This document is for information and instruction purposes. Mentor Graphics reserves the right to makechanges in specifications and other information contained in this publication without prior notice, and thereader should, in all cases, consult Mentor Graphics to determine whether any changes have beenmade.

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

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

MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, ORCONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,EVEN IF MENTOR GRAPHICS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OFSUCH DAMAGES.

RESTRICTED RIGHTS LEGEND 03/97

U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirelyat private expense and are commercial computer software provided with restricted rights. Use,duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to therestrictions set forth in the license agreement provided with the software pursuant to DFARS 227.7202-3(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - RestrictedRights clause at FAR 52.227-19, as applicable.

Contractor/manufacturer is:Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777.Telephone: 503.685.7000

Toll-Free Telephone: 800.592.2210Website: www.mentor.com

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

TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property ofMentor Graphics Corporation or other third parties. No one is permitted to use these Marks without theprior written consent of Mentor Graphics or the respective third-party owner. The use herein of a third-party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended toindicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’trademarks may be viewed at: www.mentor.com/terms_conditions/trademarks.cfm.

http://www.mentor.com

http://supportnet.mentor.com/

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

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

Tessent Common Resources Manual for ATPG Products, v9.2 3November 2010

Table of Contents

Chapter 1About Common Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2Design Rule Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

DFTAdvisor Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Troubleshooting Rules Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Setting the Handling of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Turning on ATPG Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Setting the Level of Gate Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Setting the Gate Information Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Reporting Gate Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Flattening Rule Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

The Design Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24RAM Rules (A Rules). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24BIST Rules (B Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Clock Rules (C Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Scan Cell Data Rules (D Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Extra Rules (E Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102EDT Finder (F Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Flattening (FN, FP, and FG) Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136General Rules (G Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145EDT Rules (K Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Procedure Rules (P Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Scannability Rules (S Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Scan Chain Trace Rules (T Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Power-Aware Rules (V Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Timing Rules (W Rules) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

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

Chapter 3Getting Started with DFTVisualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Opening DFTVisualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Understanding the DFTVisualizer Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Understanding the DFTVisualizer Quality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Performing Basic Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Saving and Restoring Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Searching for an Instance, Net, or Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Interrupting Operations from DFTVisualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Table of Contents

4November 2010

Tessent Common Resources Manual for ATPG Products, v9.2

Undocking and Docking Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Resizing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Repositioning Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Understanding Popup Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Adding Instances to a Display Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Cross-Selecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Selecting Objects in the Debug or Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Unselecting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Moving Objects in the Debug or Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Customizing Marking Colors in the Debug, Design, and Test Structures Windows . . . . . 263Marking and Unmarking Objects in the Debug, Design, and Test Structures Windows . . 263Copying Instances Between Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Tracing Signal Paths on a Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Tracing a Specific Signal Value to the Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Tracing Signal Paths in the Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Annotating Schematic Data in the Debug Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Displaying Multiple Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Analyzing a DRC Violation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Step 1 - Run an Analysis of the Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Step 2 - Find the Source of Problem Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Step 3 - Apply a Remedy and Rerun DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Assessing Test Coverage in the Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Performing Clock Domain Analysis in the Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Analyzing a Fault and Displaying its Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Executing Report Test Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Getting Oriented in a Large Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Setting DFTVisualizer Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Saving/Loading Session Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Understanding the DFTVisualizer Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . 292

Global Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Colors Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Schematics Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Browser Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Data Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Text Editor Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Objects Added to DFTVisualizer Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Task Manager Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Debug Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Format Guide Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324Global Search Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325Signals Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Test Structures Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327Text Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329Transcript Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Table of Contents


DFTVisualizer Command Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

Chapter 4Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Defining Scan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339Defining a Scan Cell Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Example Scan Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Defining a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Model_name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349List_of_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Model_source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350Interface Pins and Internal Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Cell_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Support of Arrays Within Library Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Defining Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Using Model Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Reading Multiple Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Verilog Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373Supported Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

AND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375NAND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376OR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377NOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Buffer With High Impedance Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381XOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382XNOR Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384Inverted Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Tri-State Buffer with Active High Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Inverted Tri-State Buffer with Active High Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389D Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392One Time Unit Delay Element (FlexTest Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Feedback Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Wire Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Pull-Up or Pull-Down Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Power Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Ground Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398Unknown Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399High Impedance Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Undefined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Unidirectional NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401Unidirectional PMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Table of Contents

6November 2010


Unidirectional Resistive NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Unidirectional Resistive PMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Unidirectional Feedback NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Unidirectional Feedback PMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406Unidirectional CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Unidirectional CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Unidirectional Resistive CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Unidirectional Resistive CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410Unidirectional Feedback CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411Unidirectional Feedback CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Pulse Generators with User Defined Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414RAM and ROM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Chapter 5Creating ATPG Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

Converting TetraMax Primitives to Verilog Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433Creating an ATPG Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434Finding Unsupported Constructs in Partial Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434Finding Black Boxes with Vectored Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435Reconciling System Verilog reg and Verilog Keyword Compiling Issues . . . . . . . . . . . . . . 436

Accounting for Reserved Verilog Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436Accounting for Reg and Wire for Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Support for Verilog Parameter Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437LibComp Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438LibComp Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439UDP Limitations and Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

2-1 Mux Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467LibComp Limitation - Complex Asynchronous Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . 471LibComp Limitation - Verilog Construct Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473DFF Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474D Latch Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

I/O Pad Limitations and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475I/O Pad Code Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Memory Limitations and Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478Verilog Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479$readmemh and $readmemb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479ROM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479RAM Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480

Chapter 6Verifying ATPG Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501Specifying which Tool Performs Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502Verification Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502Running Verification from the Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502Verifying a Single Model in an ATPG Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Table of Contents


Interpreting the Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503verify.results File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Debugging Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506Re-simulating Verilog Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Prerequisites for Simulating Verilog Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507Simulating Verilog Only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Fixing DRC Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508Improving Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Troubleshooting One Model at a Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508Assessing the Impact of Low Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Locating Low-Coverage Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509Re-running the Tessent FastScan Portion of Verification . . . . . . . . . . . . . . . . . . . . . . . . . 510

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

Chapter 7Test Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

What is a Test Procedure File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511When Do I Need to Create a Test Procedure File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511Procedure File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Using Tcl in the Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513Introductory Procedure File Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514#include Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515Set Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515Alias Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517Timing Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519Timeplate Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522Always Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525Procedure Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526Clock Control Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

The Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537Scan and Clock Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538Non-Scan Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

Procedure File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571FlexTest Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

Environment Variables in Procedure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572Merging Procedure Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573Default Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573Creating Test Procedure Files for End Measure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574Serial Register Load and Unload for LogicBIST and ATPG . . . . . . . . . . . . . . . . . . . . . . . . 576

Register Load and Unload Use Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576Static Versus Dynamic Register Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576Test Procedure File Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577Dofile Modifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580Adding a Register Value Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580Serial Load and Unload DRC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582

Table of Contents


Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585Supporting Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587Output Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587Parameter File Format and Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588

Appendix AGetting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Appendix BUsing the Tessent Tcl Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

Using Tcl Within the Tessent Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622Tcl Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622

Modifying Existing Tessent Dofiles for Use with Tcl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623Dollar Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Quotation Marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Set Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Brackets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Escape Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625Optional Single Quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

ATPG Accelerator Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Before and After LSF Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Before and After LSF Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

Special Tcl Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Tcl Comments Can Be Tricky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627Tcl Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

Index

Third-Party Information

End-User License Agreement


List of Tables

Table 2-1. Clocking that Can Result in a C3 Signal Race . . . . . . . . . . . . . . . . . . . . . . . . . . 55Table 2-2. Clocking that Can Result in a C4 Signal Race . . . . . . . . . . . . . . . . . . . . . . . . . . 62Table 3-1. Windows Between Which You Can Copy Instances . . . . . . . . . . . . . . . . . . . . . 264Table 3-2. Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Table 3-3. Set Gate Report Command Reference List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Table 3-4. Global Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Table 3-5. Color Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296Table 3-6. Debug Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Table 3-7. Browser Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Table 3-8. Data Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Table 3-9. Text Editor Window Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Table 3-10. What is Added to the Debug, Design and Data Windows . . . . . . . . . . . . . . . . 306Table 3-11. Browser Window Instance Type Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Table 3-12. Browser Window Data Menu Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Table 3-13. Debug Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Table 3-14. Design Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322Table 3-15. Signals Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327Table 3-16. Transcript Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Table 3-17. Wave Window Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334Table 3-18. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336Table 4-1. Supported Verilog Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Table 4-2. AND Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Table 4-3. NAND Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376Table 4-4. OR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Table 4-5. NOR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Table 4-6. Inverter Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Table 4-7. Buffer Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Table 4-8. BUFZ Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Table 4-9. XOR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Table 4-10. XNOR Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Table 4-11. TSL Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384Table 4-12. TSLI Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385Table 4-13. TSH Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Table 4-14. TSHI Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387Table 4-15. MUX Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Table 4-16. D Flip-Flop Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389Table 4-17. Alternative D Flip-Flop Primitive Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390Table 4-18. D Latch Primitive Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392Table 4-19. DELAY Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Table 4-20. INVF Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

List of Tables

10November 2010


Table 4-21. WIRE Truth Table (for two inputs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396Table 4-22. PULL Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Table 4-23. UNDEFINED Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399Table 4-24. NMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401Table 4-25. PMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402Table 4-26. RNMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Table 4-27. RPMOS Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Table 4-28. NMOSF Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Table 4-29. PMOSF Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406Table 4-30. CMOS1 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Table 4-31. CMOS2 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Table 4-32. RCMOS1 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409Table 4-33. RCMOS2 Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410Table 4-34. CMOS1F Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411Table 4-35. CMOS2F Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413Table 5-1. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438Table 5-2. Output Dominance Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447Table 6-1. Debugging Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506Table 7-1. Reserved Punctuation Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512Table 7-2. Vector Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597Table 7-3. Translation Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598Table 7-4. STIL Special Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605Table 7-5. STIL Pattern Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606Table 7-6. STIL Vector Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606Table B-1. Common Tcl Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

11November 2010


List of Figures

Figure 2-1. Example of Design Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 2-2. Example of Primitive Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 2-3. Data Reported for a Specific Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 2-4. Clock Cycle Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figure 2-5. Example Clock Cone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 2-6. Example Effect Cone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 2-7. Pin in Both Cones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figure 2-8. DFTVisualizer Debug Window View Showing Clock Cones . . . . . . . . . . . . . . 47Figure 2-9. C1 Violation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figure 2-10. C2 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Figure 2-11. C3 Violation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 2-12. Example Timing That Allows Sink to Capture Source’s New Data. . . . . . . . . 56Figure 2-13. C4 Violation Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 2-14. Example Where Actual Behavior Differs from Tool’s Prediction . . . . . . . . . . 63Figure 2-15. C5 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Figure 2-16. C6 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figure 2-17. C7 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 2-18. C8 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Figure 2-19. C9 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figure 2-20. C10 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 2-21. C13 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 2-22. C14 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 2-23. C15 Rule Example Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figure 2-24. Rule D10 Violation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Figure 2-25. Rule D11 Violation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Figure 2-26. Example E4 Violation Trace in Debug Window of DFTVisualizer . . . . . . . . . 106Figure 2-27. Example E10 Violation Trace in Debug Window of DFTVisualizer . . . . . . . . 115Figure 2-28. Blocked Decompressor Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Figure 2-29. Blocked Channel Input to Decompressor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Figure 2-30. Output Channel and Compactor Connection Blocked . . . . . . . . . . . . . . . . . . . 128Figure 2-31. Blocked Scan Chain Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Figure 2-32. Failing identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Figure 2-33. Common cell structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Figure 2-34. Failing identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Figure 2-35. Example S3 Rule Violation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Figure 2-36. Example of T25 Violation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Figure 2-37. Transparent Capture Handling Analysis Messages. . . . . . . . . . . . . . . . . . . . . . 252Figure 2-38. RAM Summary Results and Test Capability Messages . . . . . . . . . . . . . . . . . . 253Figure 3-1. DFTVisualizer Quality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Figure 3-2. Trace Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

List of Figures

12November 2010


Figure 3-3. Tracing Down One Hierarchical Level from a Selected Pin . . . . . . . . . . . . . . . 271Figure 3-4. Tracing Up One Hierarchical Level from a Selected Pin . . . . . . . . . . . . . . . . . 271Figure 3-5. Design Window Display with Net Bundling Off . . . . . . . . . . . . . . . . . . . . . . . . 272Figure 3-6. Same Display with Net Bundling On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Figure 3-7. DFTVisualizer Display Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Figure 3-8. Initial DRC Analysis Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Figure 3-9. Copying the Instance to the Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Figure 3-10. Instance Copied to the Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Figure 3-11. Tracing Back Using the Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Figure 3-12. Viewing Hidden Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Figure 3-13. Finding Xs on the Reset Input of a Memory Element on Trace Path . . . . . . . . 281Figure 3-14. Completing the Trace to a PI and Reconfirming It is X Source . . . . . . . . . . . . 281Figure 3-15. Viewing Additional Simulation Data for the PI . . . . . . . . . . . . . . . . . . . . . . . . 282Figure 3-16. Browser Default Display Showing the Top-level Design. . . . . . . . . . . . . . . . . 284Figure 3-17. Browser Showing a Block with Low Test Coverage . . . . . . . . . . . . . . . . . . . . 284Figure 3-18. Browser Display Showing the Clock Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Figure 3-19. Browser with Expanded Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Figure 3-20. Adding the Top Level Instance to the Design Window . . . . . . . . . . . . . . . . . . 290Figure 3-21. Tracing Down Fanout to See the Major Design Blocks . . . . . . . . . . . . . . . . . 290Figure 3-22. Global Preferences Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Figure 3-23. Colors Preference Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Figure 3-24. Schematics Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . 297Figure 3-25. Browser Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Figure 3-26. Data Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Figure 3-27. Text Editor Window Preferences Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . 304Figure 3-28. Initial Task Manager Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Figure 3-29. Task Manager Window with View Design Elements Task Highlighted . . . . . 309Figure 3-30. Browser Tabbed Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310Figure 3-31. Browser Window with Library Tab Active . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Figure 3-32. Data Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Figure 3-33. Debug Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Figure 3-34. Design Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321Figure 3-35. Format Guide Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324Figure 3-36. Global Search Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325Figure 3-37. Signals Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Figure 3-38. Test Structures Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328Figure 3-39. Text Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Figure 3-40. Transcript Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Figure 3-41. Wave Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334Figure 4-1. General Scan Definition Replacement Example. . . . . . . . . . . . . . . . . . . . . . . . . 344Figure 4-2. Mux-Scan Definition Replacement Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 345Figure 4-3. Clocked-Scan Definition Replacement Example . . . . . . . . . . . . . . . . . . . . . . . . 346Figure 4-4. LSSD Scan Definition Replacement Example . . . . . . . . . . . . . . . . . . . . . . . . . . 346Figure 4-5. Complex Scan Definition Replacement Example. . . . . . . . . . . . . . . . . . . . . . . . 348Figure 4-6. Bidirectional Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

List of Figures


Figure 4-7. Scan D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Figure 4-8. Design Example with Bus Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Figure 4-9. Simulation Model with ZHOLD Bus Keeper . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Figure 4-10. Combinational Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Figure 4-11. Creating an Internal Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363Figure 4-12. Tri-State Buffer7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Figure 4-13. Non-Inverting Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Figure 4-14. Two-input NAND Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Figure 4-15. Mux-DFF Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Figure 4-16. The MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Figure 4-17. The DFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Figure 4-18. Tri-State Gate (_buf primitive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366Figure 4-19. Tri-State Gate (_bufz primitive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Figure 4-20. Tri-State Gate (_wire primitive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Figure 4-21. Internal Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Figure 4-22. AND Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375Figure 4-23. NAND Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376Figure 4-24. OR Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377Figure 4-25. NOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378Figure 4-26. Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Figure 4-27. Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Figure 4-28. Buffer with High-Impedance Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Figure 4-29. XOR Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Figure 4-30. XNOR Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Figure 4-31. Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384Figure 4-32. Inverted Tri-State Buffer with Active Low Control . . . . . . . . . . . . . . . . . . . . . 385Figure 4-33. Tri-State Buffer with Active High Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Figure 4-34. Inverted Tri-State Buffer with Active High Control. . . . . . . . . . . . . . . . . . . . . 387Figure 4-35. Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Figure 4-36. D Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Figure 4-37. D Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393Figure 4-38. One Time Unit Delay Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Figure 4-39. Feedback Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395Figure 4-40. Wire Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Figure 4-41. Pull-Up or Pull-Down Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Figure 4-42. Undefined Functional Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400Figure 4-43. Unidirectional NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401Figure 4-44. Unidirectional PMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402Figure 4-45. Unidirectional Resistive PMOS Transistor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Figure 4-46. Unidirectional Resistive NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Figure 4-47. Unidirectional Feedback NMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Figure 4-48. Unidirectional Feedback PMOS Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . 406Figure 4-49. Unidirectional CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407Figure 4-50. Unidirectional CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408Figure 4-51. Unidirectional Resistive CMOS1 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . 409

List of Figures

14November 2010


Figure 4-52. Unidirectional Resistive CMOS2 Transistor . . . . . . . . . . . . . . . . . . . . . . . . . . 410Figure 4-53. Unidirectional Feedback CMOS1F Transistor . . . . . . . . . . . . . . . . . . . . . . . . . 412Figure 4-54. Unidirectional Feedback CMOS2F Transistor . . . . . . . . . . . . . . . . . . . . . . . . . 413Figure 4-55. ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416Figure 4-56. RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417Figure 4-57. Flattened RAM Model with oen Set to 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427Figure 7-1. Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541Figure 7-2. Timing Diagram for Shift Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542Figure 7-3. Load_Unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544Figure 7-4. Timing Diagram for Load_Unload Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 546Figure 7-5. Shadow_Control Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547Figure 7-6. Master_Observe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547Figure 7-7. Shadow_Observe Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548Figure 7-8. Sequential Transparent Circuitry Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549Figure 7-9. Skew_Load Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551Figure 7-10. Skew_load applied within Pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552Figure 7-11. Full Ram Sequential Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563Figure 7-12. Full Clock Sequential Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564Figure 7-13. Init_force Procedure Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565Figure 7-14. Introductory Example with Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567Figure 7-15. Introductory Example without Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . 569


Chapter 1About Common Resources

Tessent common resources are tools and file formats common to multiple tools. Examples ofcommon resources include Tessent DFTVisualizer (hereafter known as DFTVisualizer) anddesign rule checking. Examples of common file formats include the test procedure format andVerilog. For more information on any of these common resources, see the following topics:

• Design Rule Checking

• Getting Started with DFTVisualizer

• Design Library

• Creating ATPG Models

• Verifying ATPG Models

• Test Procedure File


About Common Resources

November 2010


Chapter 2Design Rule Checking

The following ATPG design rules are described in this chapter:

DFTAdvisor Rules CheckingPrior to scan insertion, Tessent DFTAdvisor (hereafter known as DFTAdvisor) performslimited rule checks on the design as you switch from Setup to Dft modes. Part of the checking itdoes is scannability checking. For more information, 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 TessentFastScan™ or FlexTest™.

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

• RAM Rules (A Rules)

• BIST Rules (B Rules)

• Clock Rules (C Rules)

• Scan Cell Data Rules (D Rules)

• Extra Rules (E Rules)

• EDT Finder (F Rules)

• Flattening (FN, FP, and FG) Rules

• General Rules (G Rules)

• EDT Rules (K Rules)

• Procedure Rules (P Rules)

• Scannability Rules (S Rules)

• Scan Chain Trace Rules (T Rules)

• Power-Aware Rules (V Rules)

• Timing Rules (W Rules)


Design Rule CheckingTroubleshooting Rules Violations

November 2010

Setting the Handling of RulesSome rules allow you to specify how a violation is handled either error, warning, note, orignore. For more information, see Set Drc Handling in the ATPG and Failure Diagnosis ToolsReference Manual.

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 the C1 rule, this analysis is enabled bydefault; for other rules, the tool does not perform the analysis unless you direct it to.

For example, assume that you select Atpg_analysis for clock rule C1 and the tool simulates aclock input to be X. The rule violation occurs when the analysis determines that it is, or may be,possible to turn the clock input on when all other defined clocks are off, and constrained pinsare at their constrained values.

NoteThe ATPG analysis rules checking process may requires additional CPU time andmemory.

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

d

sc_in

sc_en

clk

q

sc_out

sdff1



If the gate level is set to design, the Report Gate command displays the following information:

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

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

Figure 2-2. 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.

sdff1

A

B

CTL

OD0

SETQN

d

sc_in

sc_enclk

qsc_outCK0

RST

Q

BUF(_buff)

TIE0

DFF1MUX1 (_dff)(_mux)

(_tie0)



November 2010

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.

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 Reference Manualor 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 Debug window of DFTVisualizer.

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-3 shows a report with primitive-level information for a gate with an ID number of74493.

Figure 2-3. 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

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



November 2010

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.

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

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 Commands

Report 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 to the Report FlattenRules command in the ATPG and Failure Diagnosis Tools Reference Manual or theDFTAdvisor 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 to the Set Flatten Handling command in theATPG and Failure Diagnosis Tools Reference Manual or the DFTAdvisor Reference Manual.


Design Rule CheckingThe Design Rules

November 2010

The Design RulesMany error messages provide a line number and file name to help you resolve the errorcondition. However, some error messages may relate to problems with internally generated dataand do not provide a line number and file name.

For example, a syntax error (P1) in a test procedure file would produce the following message:

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

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.

A1Category: RAM

Tools Supported: DFTAdvisor, Tessent FastScan, FlexTest, Tessent TestKompress®,LBISTArchitect BIST-Ready, and LBISTArchitect Fault Sim

Default Handling: Warning

Report Drc Rules: Supported

Description

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.

The occurrence message is:

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.



The summary message is:

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.

A2Category: RAM

Tools Supported: DFTAdvisor, Tessent FastScan, FlexTest, Tessent TestKompress,LBISTArchitect BIST-Ready, and LBISTArchitect Fault Sim



Description

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


A3Category: RAM




November 2010



Description

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)


A4Category: RAM




Description

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 initialized



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


A5Category: RAM




Description

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.




November 2010

N RAMs are connected to RAMs. (A5)


A6Category: RAM




Description

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.


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)


A7Category: RAM






Description

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


A8Category: RAM

Tools Supported: FlexTest



Description

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.



November 2010

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)


A9Category: RAM

Tools Supported: Tessent FastScan and Tessent TestKompress



Description

A read-only RAM model should define an initialization file. If an initialization file is notdefined, the tool will treat instances of the RAM as TIEX, reducing test coverage.

The default handling for this rule violation is warning. To correct the problem, be sure theATPG library model of the RAM includes an init_file attribute that correctly specifies aninitialization file.


The initialization file is not defined for read-only RAM N (G).(A9-1)



N read-only RAMs do not have initialization file. (A9)




A10Category: RAM




Description

The content of a read-only RAM that does not have a write port must not be disturbed by anyprocedures except test_setup.

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the simulated values by setting the gate reporting to error_pattern and using the ReportGates command for the gate ID number displayed in the error message. This identifies the set orreset port that is not held off during simulation of a procedure, and by tracing back from thisinput, you can identify how to correct the problem. The usual cause of this error condition is notforcing the primary inputs, or not initializing the state elements, that control the RAM’s set orreset port to an appropriate value.

When the A10 and/or A11 rule is violated, the tool will treat the RAM as TIEX, which mayreduce fault coverage.


The content of read-only RAM N (G) can be disturbed through L line duringtime T of P procedure. (A10-1)

N is the instance name of the RAM gate, G is the gate ID number, L is the type of input (set orreset), T is the time, and P is the procedure name.


There were N occurrences of disturbed read-only RAMs during testprocedures. (A10)


A11Category: RAM






November 2010

Description

The content of a read-only RAM that does not have a write port must not be disturbed throughthe set or reset lines during capture.

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the simulated values by setting the gate reporting to error_pattern and using the ReportGates command for the gate ID number displayed in the error message. This identifies the set orreset port that is not held off during capture, and by tracing back from this input, you canidentify how to correct the problem. The usual cause of this error condition is not constrainingthe primary inputs or the state elements that control the RAM’s set or reset port.

When the A10 and/or A11 rule is violated, the tool will treat the RAM as TIEX, which mayreduce fault coverage.


The content of read-only RAM N (G) can be disturbed through L line incapture window.(A11-1)

N is the instance name of the RAM gate, G is the gate ID number, and L is the type of input (setor reset).


There were N occurrences of disturbed read-only RAMs in capture window.(A11)


A12Category: RAM




Description

The content of a read-only RAM that has a write port must not be disturbed by any procedureexcept test_setup (in order for the initialization file to be usable for test generation).

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the simulated values by setting the gate reporting to error_pattern and using the ReportGates command for the gate ID number displayed in the error message. This identifies the set orreset port that is not held off during a procedure, and by tracing back from this input, you can



identify how to correct the problem. The usual cause of this error condition is not defining thewrite, set or reset operation properly.

When rule A12 and/or A13 is violated, the tool will ignore the RAM’s contents initializedthrough the initialization file.


The initialization file of RAM N (G) cannot be used during test patterngeneration since RAM content can be disturbed through L line during time Tof P procedure.(A12-1)

N is the instance name of the RAM gate, G is the gate ID number, L is the type of input (write,set or reset), T is the time, and P is the procedure name.


There were N occurrences of disturbed RAM initialization file during testprocedures. (A12)


A13Category: RAM




Description

The content of a read-only RAM that has a write port must not be disturbed through the write,set or reset lines during capture (in order for the initialization file to be usable for testgeneration).

The default handling for this rule violation is warning. When an error condition occurs, you canaccess the simulated values by setting the gate reporting to error_pattern and using the ReportGates command for the gate ID number displayed in the error message. This identifies the set orreset port that is not held off during capture, and by tracing back from this input, you canidentify how to correct the problem. The usual cause of this error condition is not defining thewrite, set or reset operation properly.

When rule A12 and/or A13 is violated, the tool will ignore the RAM’s contents initializedthrough the initialization file.




November 2010

The initialization file of RAM N (G) cannot be used during test patterngeneration since RAM content can be disturbed through L line in capturewindow. (A13-1)

N is the instance name of the RAM gate, G is the gate ID number, and L is the type of input(write, set or reset).


There were N occurrences of disturbed RAM initialization file in capturewindow. (A13)


A14Category: RAM




RAM should be observable. The tool performs this check by forcing all pin constraints and tiedcells and check if there is any sensitizable path from the outputs of a RAM to any observationpoint. The rule violation occurs if there is none.

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 use the ReportGates command for the gate ID number displayed on the error message.

// Warning: RAM N (G) is unobservable. (A14-1)

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

This identifies the RAM gate that cannot be observed. The usual cause of this error condition isconstraints blocking the output of the RAM.

A15Category: RAM




RAM should be able to read. The tool performs this check by forcing all pin constraints and cellconstraints and check the simulation values at the read enable and read clock lines of each read



control port of a RAM. The rule violation occurs if the simulation values indicate that all readcontrol ports are off.


// Warning: RAM N (G) cannot read because its read control ports are// constrained off. (A15-1).


This identifies the RAM gate that cannot be observed. The usual cause of this error condition isconstraints that prevent the read enable or read clock lines of a RAM to be turned ON.

A16Category: RAM




RAM should be able to write. The tool performs this check by forcing all pin constraints andcell constraints and check the simulation values at the write enable and write clock lines of eachwrite control port of a RAM. The rule violation occurs if the simulation values indicate that allwrite control ports are off. This rule checking will not be performed for read-only ROMs.


// Warning: RAM N (G) cannot write because its write control ports are// constrained off. (A16-1).


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 rulesfrom their default conditions of either error or warning—with the exception of rule B2. Thefollowing subsections describe each of the BIST rules.

B1Category: BIST



November 2010

Tools Supported: LBISTArchitect Fault Sim

Default Handling: Error

Report Drc Rules: Not Supported

Description

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.

B2Category: BIST

Tools Supported: DFTAdvisor, LBISTArchitect BIST-Ready, and LBISTArchitect Fault Sim



Description

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.

The error message is:

Input of chain C has no LFSR connection. (B2-1)

C is the name of the scan chain.

B3Category: BIST




Description

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)


B4Category: BIST

Tools Supported: Tessent FastScan, LBISTArchitect Fault Sim, and Tessent TestKompress



Description

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)


B5Category: BIST




Description

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)


B6Category: BIST



November 2010




Description

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.

B7Category: BIST




Description

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.

B8Category: BIST




Description

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.

B9Category: BIST




Description

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.

B10Category: BIST




Description

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.

B11Category: BIST






November 2010

Description

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.

B12Category: BIST




Description

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.

B13Category: BIST

Tools Supported: DFTAdvisor, FlexTest, LBISTArchitect BIST-Ready, and LBISTArchitectFault Sim



Description

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.

B14Category: BIST






November 2010

Description

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 violationoccurs, 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.

B15Category: BIST




Description

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

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

B16Category: BIST



November 2010




Description

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.

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


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.

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

Tessent FastScan, FlexTest, and Tessent TestKompress consider any signal to be a clock if itcan change the state of a sequential element, including system clocks, sets, and resets. Whenyou define each clock primary input (a required setup step you perform using the Add Clockscommand or “analyze control signals -Auto_fix”), a key piece of information specified witheither of these commands is the pin value that represents the clock’s off state. Two importantterms arise out of this definition, as shown in Figure 2-4.

Figure 2-4. 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.

Clock Cones and Effect Cones

A gate pin or output pin is considered to be in the clock cone of a clock signal when they areconnected through combinational logic gates and transparent latches (TLAs) to the clockprimary input.

Leading Edge (LE)

CLK1

Trailing Edge (TE)

CLK2

SETUP> add clocks 1 CLK2

SETUP> add clocks 0 CLK1

Off state

Clock Cycle



November 2010

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-5 are all inCLK2’s clock cone.

Figure 2-5. 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-6, pin Y is in the effectcone of CLK2.

Figure 2-6. Example Effect Cone

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

DCLK2

CLK

B

Q

CA

CLK2_INV

Y

DCLK2

CLK

B

Q

CA

CLK2_INV

Y



Figure 2-7. Pin in Both Cones

You can get the Debug window of DFTVisualizer to show a “C”, “E” or “B” near device pinsthat are in the clock (C), effect (E), or both (B) cones of a particular clock by issuing the SetGate Report command with the Clock_cone option after the tool has flattened the design. Forexample:

flatten modelset gate report clock_cone CLK

Alternatively, you can choose Data > Clock Cone from the DFTVisualizer menu (with theDebug window active) and in the dialog box specify the clock. Figure 2-8 shows an example ofhow this might look for a circuit fragment in the Debug window of DFTVisualizer.

Figure 2-8. DFTVisualizer Debug Window 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 I (-)1-/C

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



November 2010

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



C1Category: Clock




Description

A scan or non-scan cell must not capture data when all specified clocks are set to their off states.

When all clocks are at their off state as defined with the Add Clocks command, all clock inputs(including sets and resets) of scan and non-scan cells must be at their off state. For non-scan cellviolations, the tool converts these to TIEX.

In the case of a DFF scan cell, the clock input must be a stable binary value (0 or 1).

NoteIf the clock input value of a DFF scan cell simulates as X, the tool by default performsadditional analysis to determine if the X represents a stable binary value. An X thatrepresents a stable binary value satisfies the C1 rule’s clock input requirement for a DFF.(To turn off the additional analysis, use the Set Drc Handling command’sNoatpg_analysis argument.)

The tool performs this check using the simulated values that result when all defined clocks areat their defined off states, constrained pins are set to their constrained values, initialized non-scan cells (initialized during test_setup or load_unload) are set to their stable states, and C0,C0DX, C1, and C1DX cell constraint values are applied. The rule violation occurs if any clockinput, including set and reset lines, of any scan or non-scan cell memory element is not at its offstate.

When the C1 violation occurs on a set/reset port or a level-sensitive latch port, the tool does notissue an error message and does not stop the DRC process. Instead, the tool issues the followingsummary messages to indicate such situation exist:

// Note: n scan cells whose clock ports are not off when all clocks are// off will be handled through additional ATPG effort.

// The scan cells have been excluded from the list of C1 DRC violations.// Use "report drc rules C1 -excluded" to report these C1 violations

If the number of such scan cells is large, ATPG runtime is increased. One common root cause ofthese C1 violations is a set/reset pin not defined as a clock. You can define a set/reset pin as aclock to fix the problem and avoid ATPG performance impact



November 2010

Figure 2-9 shows an example of a circuit segment that produces a C1 violation due to anindeterminate value (X) at the clk input of DFF1 when the off state of the clocks at the PIs isdefined as a logic 0 and all defined clocks are off.

Figure 2-9. 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.

Tip: If you change the handling to warning, Tessent FastScan and Tessent TestKompresswill automatically add a TX cell constraint to each scan cell that has a C1 violation. Thiswill lower coverage but ensure good patterns.

0

PI

ANDY

0 XX

XA1

X

OR

A0Y

X

0X

d

qclk

DFF1

mux_scan_dff

CLK

PI

EN

PI

X sc_enX sc_in

SET

0

PI

RESET

set

reset

0

PI

1 XX

XA1

X

A0

X

1X

d

qclk

DFF1

mux_scan_dff

CLK

PI

EN

PI

X sc_enX sc_in

SET

0

PI

RESET

set

reset



Effect on Testability

Failure to satisfy this rule can result in unstable scan and non-scan cell values going into orcoming out of load_unload, or between cycles, and can result in inaccurate test patternsimulation 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.

For debugging, be sure C1 handling is set to error (the invocation default setting) before youenter a “set system mode atpg” command to leave Setup mode. Use the following command tocheck the setting:

report drc rules -fails_summary

If the handling is other than error, you can change it back to error with:

set drc handling c1 error

When C1 handling is set to error, the first C1 violation that occurs will stop the DRC processand return the tool to Setup mode.

Tip: The C1 violation on which the tool stops is the C1 you must debug. Fixing the C1violations the tool singles out in this manner will often fix other C1’s with no extra efforton your part, so is very efficient.

The tool will transcript details about the violation and save the simulation data related to theviolation, so you can report it.

You can then debug the violation using DFTVisualizer or by issuing commands from the tool’scommand line. Examples of both methods follow.

How to Debug with DFTVisualizer

To view the location of a C1 DRC error using DFTVisualizer, use the following command:



November 2010

Open Visualizer

Then choose Tools > Analyze DRC from the DFTVisualizer menu, select the C1-1 ID of theC1 error occurrence in the dialog box and click Analyze. The scan cell affected by thatoccurrence is displayed in the Debug window.

Tip: Alternatively, you can issue the Analyze Drc Violation command with the C1-1argument at the tool’s command line. For example:

analyze drc violation c1-1

Once the offending scan cell is displayed, trace backward from the cell’s clock input to theprimary input that drives the clock. Ensure the clock’s off state, which you defined using theAdd Clocks command, is correct. To change the defined off state, delete the old definition withthe Delete Clocks command, then reissue Add Clocks. To see a clock’s current defined off state,use the Report Clocks command.

How to Debug from the Tessent FastScan Command Line

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

1. Set Drc Handling C1 Error

2. Set Gate Report Error_pattern

3. Set System Mode Atpg

4. Report Drc Rules C1-

5. Report Gates offending_gate’s_id#

6. 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 4:

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.

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. 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 Constraints command to constrain a primary input pin to a value thatremoves the X:

SETUP> add pin constraints 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

C2Category: Clock




Description

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-

Add Clocks Report Clocks

Add Pin Constraints Report Drc Rules

Analyze Drc Violation Report Gates

Delete Clocks Set Gate Report



November 2010

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)

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-10 shows an example circuit and circuit setup specified in DFTAdvisor, TessentFastScan, FlexTest, or Tessent TestKompress.

Figure 2-10. 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.

SETUP> add clock 1 PRESETUP> add clock 1 CLRSETUP> add clock 0 CKSETUP> add pin constraint EN1 c0SETUP> add clock 1 CK17

D

CLK

DCK17

CKEN1

Q

QB

CLR

PRE

CLR

PRE

Q

QB



C3Category: Clock




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-1 lists four clocking relationships that can produce this problem.

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” on page 59.

Figure 2-11 shows an example DFTVisualizer Debug window display of a circuit segment thatproduces a C3 violation when the off state of the clock at the PI is defined as a logic 0. (InTessent FastScan, FlexTest, and Tessent TestKompress, you define the off state of each clockwith the Add Clocks command or with Analyze Control Signals -Auto_fix as a part of requiredtool setups). DFF1 updates on the leading edge (LE) of the clock, while DFF2 updates on theclock’s trailing edge (TE) due to the inverter. Under certain timing conditions (if captured datapropagates through DFF1 to its q output in less than half a clock cycle for example), data willpass through both DFF1 and DFF2 in a single clock cycle.

Table 2-1. Clocking that Can Result in a C3 Signal Race

Source Sink

LS LS

LS TE

LE LS

LE TE



November 2010

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-12 shows a possible timing scenario for the preceding circuit segment.

Figure 2-12. 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”. The bounds for the clock cones are scan cells and circuitry set to a fixed value when the

CLK

PI

C

d

clkq

dff

E

DFF1

i0C CINV

out

C

d

clkq

dff

E

DFF2

C

-

E

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



constrained pins are set to their constrained values and the initialized non-scan cells are set totheir stable states. The clock cone stops at read ports of RAMs that have the read_off attributeset to hold, and then the effect cone propagates from its outputs.

NoteIn Figure 2-11, 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 Debug windowdisplay of DFTVisualizer.

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.

• 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 60.



November 2010


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:

report drc rules c3-1

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

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


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


2. Choose Tools > Analyze DRC from the DFTVisualizer menu and select the desired C3DRC violation in the dialog box. The gates between the source cell and the failing cell,including the clock cone data for the failing clock, are displayed in the Debug windowas shown in Figure 2-11.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# argument 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 Tessent FastScancommand line, use the following example command steps (FlexTest and Tessent TestKompresswould be similar):


2. Report Drc Rules C3-occurrence#

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



November 2010

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). This forces a second evaluationof the cells affected by C3 DRC violations. The additional evaluation allows the newdata to propagate and in turn be captured into the sink gate. If additional evaluation isrequired, a side effect of this command is an increase in simulation run time. If theincrease in run time is excessive, you may want to use the other method, capturehandling.

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

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.



November 2010

Related Commands

C4Category: Clock




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.

Table 2-2 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” on page 66.

Add Capture HandlingReport GatesSet Capture HandlingSet Drc Handling

Set Gate ReportSet Learn ReportSet Sensitization CheckingSet Split Capture_cycle

Table 2-2. Clocking that Can Result in a C4 Signal Race

Source Sink

LS LS

LS TE

LE LS

LE TE



Figure 2-13 shows an example DFTVisualizer Debug window display of a circuit segment thatproduces a C4 violation when the off state of the clock at the PI is defined as a logic 0. (InTessent FastScan, FlexTest, and Tessent TestKompress, you define the off state of each clockwith the Add Clocks command or with Analyze Control Signals -Auto_fix as a part of requiredtool setups).


Figure 2-14 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 apulse. 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-14. 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

dq

clk

DFF1

dff dq

clk

DFF2

dffCLK

PI

CE

Ci0i1C

NAND1EBout B

E

nand2

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



November 2010

(effect cones). For an introduction to clock and effect cones, refer to “Clock Cones and EffectCones”. The bounds for the cones are scan cells and circuitry set to a fixed value when theconstrained pins are set to their constrained values and the initialized non-scan cells are set totheir stable states.

NoteIn Figure 2-13, the clock input of DFF2 is in both the clock and effect cones of CLK asindicated by the “B” in the Debug window 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.

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.

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




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:

report drc rules c4-1

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

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


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


2. Open Visualizer

Then choose Tools > Analyze DRC from the DFTVisualizer menu and select the desired C4DRC violation in the dialog box. The gates between the source cell and the failing cell,including the clock cone data for the failing clock, are displayed in the Debug window as shownin Figure 2-13.

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




November 2010

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 Tessent FastScancommand line, use the following example command steps (FlexTest and Tessent TestKompresswould be similar):


2. Report Drc Rules C4-occurrence#

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). This forces a second evaluationof the cells affected by C4 DRC violations. The additional evaluation allows the newdata to propagate and in turn be captured into the sink gate. If additional evaluation isrequired, a side effect of this command is an increase in simulation run time. If theincrease in run time is excessive, you may want to use the other method, capturehandling.

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 othersink 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 “Description” on page 62 for additional details.



November 2010

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

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

C5Category: Clock




Description

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.

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

Add Capture HandlingReport GatesSet Capture HandlingSet Drc Handling

Set Gate ReportSet Learn ReportSet Sensitization CheckingSet Split Capture_cycle



November 2010





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

C6Category: Clock




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



Description

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 the forward cone of influence for a clockpin (clock cone). The bounds for the clock cone are scan cells and circuitry set to a fixed valuewhen constrained pins are set to their constrained values and initialized non-scan cells are set totheir stable states. The rule violation occurs on a clock pin when a clock input of a scannablememory element and its data line are in the same clock cone.

The default handling for this rule violation is warning. When a violation occurs, you can accessthe clock cone data by the command "set gate report drc C6-N", where N is the c6 failoccurrence number, then issuing the Report Gates command for the gate ID number displayedin the occurrence message. This identifies the problem input. By tracing back from this input,you can identify how to correct the problem. C indicates clock cone, E indicates effect cone, Bindicates both, and “-” indicates no cone.

NoteThe default C6 checking may miss some C6 violations when "set clock restriction off" isused. A more conservative analysis can be enabled by"set drc handling c6 -CONSERvative on" and will identify those C6 violations. However,it is generally recommended not to turn off clock restriction such that the -conservativeswitch does not usually need to be used.





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

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





November 2010


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 constraints SC_EN c0

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

In Tessent FastScan and Tessent TestKompress, you can handle C6 rule violations by issuing a“set clock_off simulation on” command prior to creating patterns. See the Set Clock_offSimulation command description in the ATPG and Failure Diagnosis Tools Reference Manualfor additional information.

C7Category: Clock




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



Description

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.


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





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



November 2010

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

C8Category: Clock




Description

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

C9Category: Clock




Description

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



PRE

SC_IN

CLK

CLRA

SC_OUT

CLRA

D Q

QB

CLR

PRE

CLK



November 2010

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


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 clock



PRE

SC_IN

CLK

CLRA

SC_OUT

CLRA

D Q

QB

CLR

PRE

CLK



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

C10Category: Clock

Tools Supported: Tessent FastScan, Tessent TestKompress, and LBISTArchitect Fault Sim



Description

A sequential element (latch or flip-flop) can only be clocked once in any one pattern cycle.Tessent FastScan and Tessent TestKompress will only pulse a clock primary input once in eachcycle, or apply a clock procedure only once, therefore a failure of this rule implies that thecircuit generates two or more internal pulses from a single clock pulse or clock procedure.

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-20 shows an example circuit which will generate a C10 error in Tessent 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.

delay=30, width=10

CLK

delay=10, width=10



November 2010

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

C11Category: Clock




Description

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)


C12Category: Clock




Description

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)


C13Category: Clock


Default Handling: Ignore


Description

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.




November 2010




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


Figure 2-21 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.

C14Category: Clock




Description

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:

clkA

clkB

EN

EN

D

DIN

OUT



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

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.

clkA

clkB

EN

EN

D

D

OUT



November 2010

C15Category: Clock




Description

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:

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

C16Category: Clock




Description

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 PinConstraints 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 violations.

clkA

clkB EN

D

IN

OUT



November 2010

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


C17Category: Clock

Tools Supported: DFTAdvisor, Tessent FastScan, FlexTest, and Tessent TestKompress

Default Handling: Note for Tessent FastScan, FlexTest, and Tessent TestKompress

Warning for DFTAdvisor


Description

By default, all internally-driven glitch sources in a design are identified and remodeled aspossible X sources during DRC and pattern generation. An internally driven glitch source



consists of either a two-input AND gate, or a two-input OR gate where both inputs are drivenfrom a common source (either directly or through buffers and inverters), such that one path isinverting and the other path is not. This type of circuit maintains the same constant output valueregardless of the state of the driving node, but the output will probably contain a glitch when thedriving node changes state.

With this rule, gates are identified as internally-driven glitch sources if they are both driven by asequential element and also drive the clock or set/reset line of a sequential element.

NoteInternally-driven is defined as a glitch generator driven from a sequential element, andnot from a primary output.

Remodeling these internally-driven glitch sources as a constant value (TIE0 or TIE1) may causefailures during scan chain tracing. For this reason, C17 identifies these internally-driven glitchsources and remodels them as an X source (TIEX gate).

By default, internally-driven glitch sources are remodeled and reported as a C17 violation. Thedefault handling for the C17 rule is warning. All identified glitch sources are remodeled and asummary message in the log file reports the total number of C17 violations.

You can set the DRC handing for C17 to note and internally-driven glitch sources are reportedin the log file, but the remodeling does not occur, and the learning process identifies the outputof the glitch source as a constant value (this ignores the glitches that occur during statetransitions).

You can then use the Report DRC Rules command to display a list of the internally-drivenglitch sources identified in your design.

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.

D1Category: Data






November 2010

Description

Checks for the possible disturbance of data values loaded or captured into scan cells.

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.


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


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


// 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 DFTVisualizer or by issuingcommands from the tool’s command line. Examples of both methods follow.


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

1. Open Visualizer

2. Set Gate Level Primitive

Then choose Tools > Analyze DRC from the DFTVisualizer menu, select the ID of the desiredD1 violation occurrence in the dialog box and click Analyze. DFTVisualizer will display thescan cell affected by that occurrence.

Tip: Alternatively, you can issue the Analyze Drc Violation command with therule_id-occurrence# argument at the tool’s command line. For example, to display thefirst occurrence of a D1 violation:

analyze drc violation d1-1

Once the offending scan cell is displayed, trace back from the cell’s clock input to the primaryinput that drives the clock. Ensure the clock’s off state, which you defined using the Add Clockscommand, is correct.



November 2010


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

1. Set Gate Report Error_pattern


3. Report Drc Rules D1-occurrence#


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



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)(stbl)// "S" I ( 0)( 0)(000~0)(000)( 0) 43-// R I ( 0)( 0)(000~0)(XXX)( X) 157-// CLK I ( 1)( 1)(101~1)(XXX)( X) 313- /dataot/ix104/Y// "D0" I ( X)( X)(XXX~X)(XXX)( X) 255-// "OUT" O ( X)( X)(XXX~X)(XXX)( X) 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


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.



November 2010

Related Commands

D2Category: Data




Description

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.

Failure to satisfy this rule usually reduces test coverage. You can avoid the coverage loss byusing the command, Set Split Capture_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.

Add ClocksAnalyze Drc ViolationDelete ClocksRead ProcfileReport Clocks

Report Drc RulesReport GatesSet Drc HandlingSet Gate Report




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


D3Category: Data




Description

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.


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



November 2010


D4Category: Data




Description

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)


D5Category: Data






Description

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 Tessent FastScan or Tessent TestKompress identifies a non-scan memory element, thetool classifies it into 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.



November 2010

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

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.

D6Category: Data




Description

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.

D7Category: Data




Description

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.



November 2010

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)


D8Category: Data




Description

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.

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)


D9Category: Data






November 2010

Description

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.



D10Category: Data



Report Drc Rules: Supported for Tessent FastScan and Tessent TestKompress only

Description

The transparent capture cells (see “Clock (Tessent FastScan and Tessent TestKompress,Optional)” section) in clock procedures must not propagate both old and new data to other stateelements. For example, a violation can occur when a clock procedure pulses two clocks, and amemory element clocked by the first applied clock feeds at least two other memory elements,clocked by each of the clocks. To illustrate this, 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 highlighted flip-flop in Figure 2-24, which gets old data from the firstflip-flop when A pulses, violates this requirement.

Figure 2-24. 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, Tessent FastScanand Tessent TestKompress always perform this check on model violating gates with TIEXbehavior.


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

A

B

flip-flop

dataflip-flop

flip-flop



November 2010

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.

D11Category: Data




Description

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-25, which gets data from the first latchwhen A pulses, violates this requirement.

Figure 2-25. 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.Tessent FastScan and Tessent TestKompress classify faults detectable only through these POsas AU faults. To change the default handling, use the Set Drc Handling command.



If you change the handling to ignore, Tessent FastScan and Tessent TestKompress do notperform this check and continue to use the primary outputs for observation. You may want toignore this rule if you are running ATPG on a sub-block whose POs will eventually feed scancells. In this case, a D10 violation may occur instead. If you ignore this violation, the reportedfault coverage does not consider reconvergence through transparent capture cells, and ATPGcould produce an invalid pattern 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.

D12Category: Data




Description

In the state stability analysis stage, DRC simulates a number of shift cycles to calculate thestable value (load value) of nonscan memory elements at the beginning of capture.

If some nonscan memory elements need more than one shift cycle to be initialized, and its loadvalue is observed into a scan cell, the parallel simulation test bench may have simulationmismatches. This is because in parallel simulation test bench the tool generally only has one“parallel shift” cycle, leading to insufficient shift cycles to initialize those nonscan elements.

If state stability analysis takes more than one cycle to calculate nonscan load value, then the toolissues the following warning message:

// Warning: DRC simulated N shift cycles to initialize some non-scan// memory elements to their load values. (D12-1)// Note: This may lead to simulation mismatches in the parallel simulation// testbench unless M shifts are explicitly added to the testbench using// the SIM_POST_SHIFT parameter keyword (or "apply shift 1" statements are// added to the load_unload procedure). To avoid slowing down the parallel// simulation, the number of cycles DRC simulates can be restricted// using "set stability check -max_shift_cycles 1". However, initializing// fewer non-scan memory elements may lead to slightly lower test



November 2010

// coverage.

N is number of shift cycles and M is the number of shifts required.

If you receive this warning, you can perform one of the following to avoid simulationmismatches:

• Explicitly add additional independent shift cycles into their load_unload procedure tomatch the number suggested by the warning message. This can, however, generate avery large parallel test bench and can slow down Verilog simulation. To add theindependent shift cycles, do one of the following:

o Use the SIM_POST_SHIFT parameter keyword in test bench. See “Parameter FileFormat and Keywords.”

o Replicate a number of “apply shift 1” statements in load_unload procedure.

• Limit the number of shift cycles the state stability analysis simulates, resultingpessimistic load values for those nonscan cells (for example, INIT-X, instead of INIT-0or INIT-1). This may lead to slightly lower test coverage because ATPG cannot takeadvantage of those INIT-0 or INIT-1 loading values of nonscan.

To limit the number of shift cycles, use the -max_shift_cycles switch to the Set StabilityCheck command.

Extra Rules (E Rules)Extra rules identify potential design requirement problems. The following subsections describethe extra rules.

E1Category: Extra




Description

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.



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.

E2Category: Extra




Description

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)




November 2010

E3Category: Extra




Description

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)


E4Category: Extra




Description

Checks for conflicting values driving the same net during evaluation of the test procedures.

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.

The default handling for this rule violation is warning.




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 the Set GateReport command with the Drc_pattern argument, then using the Report Gates command toreport the gate whose ID number is displayed in the error message. If this is the only DRCviolation, or if you have changed the default handling to error, you can also view simulatedvalues of the gate of interest by issuing Set Gate Report with the Error_pattern argument prior tousing Report Gates. Gate reporting with the proper simulation data helps you identify theconflicting inputs; by tracing back from these inputs, you can identify how to correct theproblem.

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. Asthese 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” on page 107 for more information.


To view the location of an E4 DRC violation using DFTVisualizer, use the following commandsteps:


2. Open Visualizer

Then choose Analyze > DRC Violation from the DFTVisualizer menu, select the violation IDof the desired E4 DRC violation in the dialog box and click Analyze. The tool willautomatically change the gate reporting to “drc_pattern load_unload” and display the bus gateaffected by that violation in the Debug window of DFTVisualizer.



November 2010

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, trace backward from the bus gate. Figure 2-26 showsan example DFTVisualizer display of such a trace, where the starting point of the trace is theoffending gate, /tsdo.

Figure 2-26. Example E4 Violation Trace in Debug Window of DFTVisualizer


To view the location of the first occurrence of an E4 DRC violation from the Tessent FastScancommand line, you can use the following command steps (FlexTest and Tessent TestKompresswould be 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-26, 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// 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.


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 E4



November 2010

checks 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

E5Category: Extra


Default Handling: Note for Tessent FastScan and Tessent TestKompress; Ignore otherwise


Description

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.

NoteTessent TestKompress can handle the X states, but they typically increase the number ofpatterns generated, lowering the effective compression.

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.

Set Abort LimitSet Drc Handling



• 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 Tessent FastScan and Tessent TestKompress isnote; in other tools it is ignore. When a violation occurs, you can access the tied/constrainedsimulated values by setting the gate reporting to “constrain_value” and using the Report Gatecommand for the gate ID 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 theviolation 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)


E6Category: Extra




Description

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 tools consider ascan cell to have multiple memory elements if the cell contains, for example, a shadow element



November 2010

or copy element (refer to Slave Element and Shadow Element in the Scan and ATPG ProcessGuide for detailed information about these memory elements and their use in scan cells).

The application performs this check by tracing the forward cones of influence of all scan cellmemory elements through unconstrained and untied circuitry. The rule violation occurs whenany gate is in the cone 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)


E7Category: Extra




Description

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)


E8Category: Extra




Description

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.



November 2010

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.

E9Category: Extra




Description

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)


E10Category: Extra




Description

Checks for bus contention mutual-exclusivity during measure_po events in test procedures.

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



November 2010


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” on page 116 for more information.


To view the location of an E10 DRC violation using DFTVisualizer, use the followingcommand steps:


2. Open Visualizer

Then choose Tools > Analyze DRC from the DFTVisualizer 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 the Debug window of DFTVisualizer. Think of “parallel_pattern 0” as an exampleof 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# argument at the tool’s command line. For example, to display thefirst occurrence of an E10 violation:

analyze drc violation e10-1



Once the offending bus gate is displayed, trace backward from the bus gate. Figure 2-26 showsan example DFTVisualizer display of such a trace, where the starting point of the trace is theoffending gate, /tsdo. Notice that TSDs /ix145 and /ix149 have conflicting values and both areenabled.

Figure 2-27. Example E10 Violation Trace in Debug Window of DFTVisualizer

You could use DFTVisualizer 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 Tessent FastScancommand line, you can use the following command steps (FlexTest and Tessent TestKompresswould 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



November 2010

The following transcript excerpts show, for the design segment of Figure 2-26, 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.

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 many



patterns 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 Constraints — 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 generatepatterns 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.



November 2010

• 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

E11Category: Extra




Add Atpg ConstraintsAdd Atpg FunctionsAdd Pin ConstraintsAnalyze Drc Violation

Set Abort LimitSet Contention CheckSet Drc Handling



Description

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.

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


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.

E12Category: Extra




Description

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



November 2010


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.

E13Category: Extra




Description

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.

E14Category: Extra






Description

The expected simulation values listed in the test_setup procedure must match the actualsimulated values.

E14 ensures the test_setup procedure is correct.

This DRC simulates the test_setup procedure when setup mode is exited and compares thesimulated values with the expected values listed in the test_setup procedure.

Exception

Not applicable.

Messaging

If the test_setup procedure file fails E14, the following message displays:

Expect failed on <signal name> at time <time>. Expected <logic value>,simulated <logic value>. (E14-#)

This rule does not issue a summary message.

Troubleshooting

1. Use DFTVisualizer to compare the DRC simulated values from the test_setup procedurewith the simulated values for associated nodes in the design.

2. Correct the expect statements in the test_setup procedure to match the DRC simulationvalues.

EDT Finder (F Rules)F rules verify the EDT logic connectivity and operation prior to scan chain tracing.

F1Category: EDT

Tools Supported: Tessent TestKompress


Scope: Pattern Generation Phase




November 2010

Description

EDT channel pins must be defined for each EDT logic block.

F1verifies the existence of the EDT channel pins.

You cannot change the handling with the Set Drc Handling command.

Messages

If EDT mapping is disabled or enabled and no EDT block is found in the location defined in thedofile, the channel pins must exist at the top level of the design. If F1 is violated in this manner,the following error message is reported.

Defined channel input|output pin P (N) [of EDT block E] cannot be found.(F1-1)

If EDT mapping is enabled (Set EDT Mapping On) and the EDT block instance is found, thechannel pins must exist at that instance. If F1 is violated in this manner, the following errormessage is reported.

Defined channel {input|output} pin P (N) [of EDT block E] cannot be foundon module boundary of instance B. (F1-1)

Where P is the channel index and N the pin name, E is the name of an EDT block, and B is theinstance name of the EDT block.

Related Topics

F2Category: EDT

Tools Supported: TestKompress


Scope: Top-level Pattern Generation Phase of modular TestKompress when EDT mapping isenabled


Description

Block-level channel pins must be connected to primary inputs/outputs.

F2 traces the connectivity between specified block-level signals (ports) and primary input oroutput pins is traced to verify channel input and output signals specified in the block-leveldofiles are consistent with the top-level signals.


Set EDT Mapping



Messages


Defined channel {input|output} pin P (N) [of EDT block E] on instance B isnot {driven by a primary input| driving a primary output} pin. Tracestopped at state element(s) S (G). (F2-1)

Where:

• P is the channel index and N the pin name.

• E is the name of the EDT block and B is the instance name of the EDT block.

• S is the instance name and G the gate ID number.

• Multiple state elements might be listed in case of fan-outs.

Related Topics

F3Category: EDT





Description

The design must contain at least one state element able to change states during shift.

F3 verifies that at least one state element in the design is clocked and not constrained to a fixedvalue.


Messages


At least one state element should be able to change its state duringshift. None were found. (F3)

Set EDT Mapping



November 2010

F4Category: EDT





Description

EDT requires a design containing at least one decompressor.

F4 verifies there is a decompressor in the design.


Messages


No decompressors found. (F4)

F5Category: EDT





Description

All defined channel inputs must drive a decompressor.

F5 verifies that all defined input channels are driving an identified decompressor by tracing thepath from the channel input to the decompressor. Figure 2-28 shows an error condition.



Figure 2-28. Blocked Decompressor Input

Messages


Channel input P (N) [of EDT block E] is not driving a decompressor.Either no structural connection exists, or the path is blocked.Trace stopped at state element(s) S (G). (F5-1)

Where P is the channel index and N the pin name, E is the name of an EDT block, S is aninstance name and G is the corresponding gate ID number. Multiple state elements may belisted in case of fan-outs.

Troubleshooting

Check the procedure file for incorrect or missing shift procedure settings.

Related Topics

F6Category: EDT





Description

Channel input pins that control the decompressors must be defined.

Test Procedure File



November 2010

F6 traces each decompressor input pipeline to verify that decompressors are controlled bychannel input pins. Figure 2-29 shows an error condition.

Figure 2-29. Blocked Channel Input to Decompressor

This check is performed even when F5 violations exist.

Messages

If the decompressor is driven by one or more defined channel inputs, each blocked inputpipeline is reported as follows:

The input pipeline of decompressor D [of EDT block E] is broken betweendecompressor state element L (G1) and the channel input after tracing Nstate elements. The last state element reached is: M (G2). (F6-1)

If all input pipelines of a decompressor are blocked the following message is reported once perdecompressor.

All input pipelines of decompressor D are blocked. One of the inputpipelines is broken between decompressor state element L (G1) and thechannel input after tracing N state elements. The last state elementreached is: M (G2). (F6-1)

Where D is the internal identification number of the decompressor, E is the name of an EDTblock, L is the instance name of the decompressor state element and G1 is the correspondinggate ID number, N is the number of found pipeline stages, M is the instance name of the lasttraced state element and G2 is its gate ID number.



F7Category: EDT





Description

Decompressors must be controlled by defined channel inputs.

F7 traces all inputs to the decompressor to verify that they are connected to channel input pins.

Messages

If the decompressor is driven by at least one defined channel input, each rule violation isreported as follows:

The pin P is not a channel input but drives decompressor state element L(G) of decompressor D [of EDT block E]. (F7-1)

If the decompressor is only driven by pins not defined as channel inputs, the following errormessage is reported once per decompressor:

None of the primary input pins driving decompressor D is defined as achannel input. One of the traced pins is P. (F7-1)

Where P is a pin name, D is the internal identification number of the decompressor, E is thename of an EDT block, L is the instance name of the decompressor state element and G is thecorresponding gate ID number.

NoteIn the EDT mapping flow, the reported pins are channel inputs mapped to the top level ofthe design.

F8Category: EDT





Description

All channel outputs must be driven by compactor.



November 2010

F8 traces all channel outputs to verify that they are driven by a compactor. Figure 2-30 showsan error condition.

Figure 2-30. Output Channel and Compactor Connection Blocked

Messages


The channel output P (N) [of EDT block E] is not driven by a compactor.Either no structural connection exists, or the path is blocked. The laststate element reached while tracing back is: M (G). (F8-1)

If a primary input was reached the message is:

The primary input pin PI was reached while tracing back from channeloutput P (N) [of EDT block E]. (F8-1)

If the tracing problem is caused by a defined value on a channel output, the message is:

The channel output P (N) [of EDT block E] cannot be traced back because itis constrained to V. An unconstrained simulation value of X is expected.(F8-1)

If the tracing problem is caused by wrong values in mask hold registers, the message is:

Wrong values detected in mask hold registers after disabling EDT X maskinglogic and simulating load_unload until first clock event in apply shift.One of the failing state elements is: M (G). Simulated value: V1. Expectedvalue: V2.(F8-1)

Where P is the channel index and N is the pin name, E is the name of the EDT block, M is theinstance name of the last traced state element, G is its gate ID number, PI is the name of thereached primary input pin, and V, V1, V2 are gate values.



F9Category: EDT





Description

All compressed scan chains must be connected to a decompressor.

F9 traces all channel outputs to verify they connect to a decompressor. Figure 2-31 shows anerror condition.

Figure 2-31. Blocked Scan Chain Path

Messages


Compressed scan chain driving channel output P (N) [of EDT block E]blocked at gate M (G) after tracing C cells. (F9-1)

Where P is the channel index and N the pin name, E is the name of an EDT block, M is theinstance name, G is its gate ID number, and C is the number of scan cells traced in the scanchain.



November 2010

F10Category: EDT





Description

The EDT logic found must match the EDT logic expected by the tool.

Messages

Examples of error messages:

The size I1 of decompressor D [of EDT block E] does not match the expectedsize I2. (F10-1)

The input tabs of decompressor D [of EDT block E] do not match the onesexpected by the tool. For details about the found decompressor use 'REPortEDt Finder -Decompressors -Id D -Verbose'. (F10-2)

The expected decompressor taps of scan chain S [of EDT block E] do notmatch with the taps of any found scan chain. (F10-3)

Where S is the name of the scan chain, E is the name of an EDT block, and D is the name of thedecompressor.

F11Category: EDT


Default Handling: Note



Description

F11 verifies that all decompressors connect to at least one scan chain and that the path from thedecompressor to the scan chains is not blocked due to wrong or missing shift procedure settings.

No correction is required if the decompressor is not needed for testing.



Messages


Decompressor D has been found but is not used in the current mode. Itcontains S state elements, one of which is N (G). (F11-1)

Where D is the internal identification number of the decompressor and S is the number of itsstate elements, N is the instance name of a decompressor state element and G is thecorresponding gate ID number.

F12Category: EDT





Description

F12 verifies that all uncompressed scan chains are defined with the Add Scan Chains command.

Messages

The warning message is:

An uncompressed scan chain has been found that was not defined with the"add scan chain" command. Its scan input is P1, scan output is P2, and itcontains S state elements. (F12-1)

Where P1 is a primary input pin, P2 is a primary output pin and S is the number of stateelements in the scan chain.

F13Category: EDT





Description

F13 verifies that the decompressor and Xpress mask shift register state elements are resetcorrectly prior to shift.



November 2010

Messages


The decompressor [of EDT block E] is not reset correctly prior to shift.Simulated value: V1. Expected value: V2.One of the failing decompressor state elements is: M (G). (F13-1)

In case of an Xpress compactor, the state elements of the mask shift registers are checked in thesame way. The error message is:

The mask shift register driven by channel input P (N) [of EDT block E] isnot reset correctly prior to shift. One of the failing mask shift registerstate elements is: M (G). (F13-1)

Where P is the channel index and N the pin name, E is the name of the EDT block, M is thename of the failing state element, and G is the gate ID number.

F14Category: EDT





Description

F14 verifies that the state elements of the mask shift registers hold their value during capture.

Only one violation per EDT block is reported.

Messages

The error message for mask shift registers (Xpress compactor) is:

The mask shift register driven by channel input P (N) [of EDT block E]does not hold its value during capture. One of the failing mask/powershift register state elements is: M (G). (F14-1)

The error message for mask shift registers (basic compactor) is:

The mask shift register [of EDT block E] does not hold its value duringcapture. One of the failing mask shift register state elements is: M (G).(F14-1)

P is the channel index and N the pin name. E is the name of the EDT block. M is the name of thefailing state element and G its gate ID number.



F15Category: EDT





Description

Input pipeline state elements must be initialized correctly.

F15 verifies that any state elements that exist between a channel input and the EDT logic areinitialized to the right value so that 0s get propagated into the EDT logic during the first shift.



Messages


State elements in the input pipeline driven by channel input P (N) [of EDTblock E] are initialized to wrong values after test_setup and load_unload.One of the failing input pipeline state elements is: M (G). Simulatedvalue: V1. Expected value: V2. (F15-1)

Where P is the channel index and N the pin name, E is the name of the EDT block, M is thename of the failing state element, G is the gate ID number, and V1 and V2 are gate values.

F16Category: EDT




Description

Input pipeline state elements must preserve their value during capture and load_unload.

F16 verifies that any state elements between a channel input and the EDT logic preserve thevalue shifted into them during capture and load_unload procedure.




November 2010

Messages


State elements in the input pipeline driven by channel input P (N) [of EDTblock E] do not preserve their value during capture and load_unload. Oneof the failing state elements is: M (G). (F16-1)

Where P is the channel index and N the pin name, E is the name of the EDT block, M is thename of the failing state element, and G is the gate ID number.

F17Category: EDT




Description

F17 verifies that the state elements of the mask hold registers are clocked during load_unload.


Messages

The error message reported when mask hold registers violate this rule is:

Mask hold register state elements [of EDT block E] are not clocked duringload_unload. One of the failing mask hold register state elements is: M(G). (F17-1)

Where E is the name of the EDT block, M is the name of the failing state element of the maskhold registers and G is its gate ID number.

F18Category: EDT




Description

F18 verifies that the state elements of the mask hold registers load their values from the stateelements of the mask shift registers before shift in the load_unload procedure.




Messages

The error message reported for mask hold registers is:

Mask hold register state elements [of EDT block E] do not load values frommask shift registers before shift in the load_unload procedure.One of the failing mask hold register state elements is: M1 (G1).The driving mask shift register state element is: M2 (G2).Simulated value: V1. Expected value: V2.

Where:

• E is the name of the EDT block.

• M1 is the name of the failing state element of the mask hold registers and G1 is its gateID number.

• M2 is the name of the driving state element of the mask shift registers and G2 its gate IDnumber.

• V1 and V2 are gate values.

F19Category: EDT




Description

F19 verifies that the state elements of the mask hold registers preserve their values during shift.


Messages

The error message reported for mask hold registers is:

Mask hold register state elements [of EDT block E] do not preserve theirvalues during shift. One of the failing mask hold register state elementsis: M (G).(F19-1)

Where E is the name of the EDT block. M is the name of the failing state element of the maskhold register and G is its gate ID number.



November 2010

Flattening (FN, FP, and FG) RulesThe flattening rule violations and their identification literals are divided into the following threegroups:

• Net rules — FN1 through FN9.

• Pin rules — FP1 through FP13.

• Gate rules — FG1 through FG8.

You can use the Set Flatten Handling command to change the handling of the net, pin, and gateflattening rules.

FN1Category: Flattened Net



Report Drc Rules: Not Supported. Use Report Flatten Rules.

Description

This rule determines if a module net is floating.





Description

This rule determines if a module net has a driver and a constant value property. The constantvalue property is ignored.







Description

This rule determines if an instance net is floating.





Description

This rule determines if an instance net is not used.





Description

This rule identifies a wired net with multiple drivers.



November 2010





Description

This rule determines if a bus net attribute cannot be used.





Description

This rule determines if two connected nets have inconsistent net attributes. Both inconsistentattributes are ignored.





Description

This rule identifies parallel wired behavior.







Description

This rule determines if the bus net has multiple bus keepers. The effects of the bus keepers areadditive.

FP1Category: Flattened Pin




Description

This rule determines if the circuit has no primary inputs.





Description

This rule determines if the circuit has no primary outputs.



November 2010





Description

This rule determines if a primary input drives logic gates and switch gates.





Description

This rule determines if a pin was moved.





Description

This rule determines if a pin was deleted by merging.







Description

This rule identifies merged wired in/out pins.





Description

This rule identifies merged wired input and output pins.





Description

This rule determines if a module boundary pin has no name.





Description

This rule determines if an inout pin is used as output only.



November 2010





Description

This rule determines if an output pin is used as an inout pin.





Description

This rule determines if an input pin is used as an inout pin.





Description

This rule determines if an output pin has no fan-out.







Description

This rule determines if an input pin is floating.

FG1Category: Flattened Gate




Description

This rule determines if the defining model of an instance does not exist. If you reduce thehandling to warning or note, this primitive is treated as undefined.





Description

This rule determines if the feedback gate is not in feedback loop.





Description

This rule determines if the bus keeper has no functional impact.



November 2010





Description

This rule determines if the RAM/ROM read attribute is not supported.





Description

This rule determines if the RAM attribute not supported.





Description

This rule determines if the RAM type is not supported.







Description

This rule determines if the netlist module has a primitive that is not supported. If you reduce thehandling to warning or note, this primitive is treated as undefined.





Description

This rule determines if the library model has a primitive that is not supported. If you reduce thehandling to warning or note, this primitive is treated as undefined.

General Rules (G Rules)G rules are general rules that identify inconsistencies in scan data and other definitions. G rulesare the first rules checked during the DRC process and all violations generate error conditionsthat must be corrected. You cannot change the handling of these rules.

G1Category: General






November 2010

Description

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.

G2Category: General




Description

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)

G3Category: General




Description

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)

G4Category: General






Description

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)

G5Category: General




Description

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)

G6Category: General




Description

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)

G7Category: General



November 2010




Description

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.

G8Category: General




Description

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.

G9Category: General






Description

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.

G10Category: General




Description

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.





Description

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 should



November 2010

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





Description

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

EDT Rules (K Rules)EDT rules only apply to designs that incorporate EDT technology. They are generallyperformed by Tessent TestKompress when switching from Setup system mode. The tool alsoperforms some checks at other times such as in response to a Write EDT Files command orbefore writing EDT files. The rule checks find EDT design definition inconsistencies.

The following subsections describe each of the EDT rules and the special handling you can setfor them.

K1Category: EDT


Scope: IP Creation Phase and Pattern Generation Phase



Description

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.



K2Category: EDT





Description

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.

K3Category: EDT





Description

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.

K4Category: EDT


Scope: IP Creation Phase




November 2010


Description

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.

K5Category: EDT





Description

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.

K6Category: EDT





Description

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 functional



pin is of a type consistent with the functional pin. Sharing with bidirectional pins is not allowed,and is covered by other design rule checks.

The K6 rule check also verifies the EDT control and channel pins have valid names. To beconsistent with Tessent FastScan and to provide immediate feedback if you change the defaultpin names, Tessent TestKompress checks the validity of the pin names and pin directions whenyou enter a Set EDT Pins command. Because the default EDT pin names might also conflictwith names of existing pins, the tool performs all checks again when you switch from Setupmode to Atpg mode. 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 “Understanding EDT Control andChannel Pins” in the Tessent TestKompress User’s 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).



November 2010

K7Category: EDT





Description

EDT does not support either bidirectional or tristate scan channel output pins. This is becauseTessent TestKompress includes a multiplexer between the EDT IP and the output pad when ascan channel output pin is shared with a functional output pin. This rule check verifies thatneither bidirectional nor tristate scan channel output pins exist. The default handling for thisrule violation is error.

K8Category: EDT





Description

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.

K9Category: EDT





Description

Scan chain pins cannot be shared with a design’s functional pins. This is because TessentTestKompress connects the scan chain pins to the EDT IP and they are no longer available as



primary inputs or outputs in the new top level. This rule check verifies that scan chain pins arenot used as functional 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 TessentTestKompress to determine if there is pin sharing. For example, Figure 2-32 shows a designwhere the last cell of a scan chain drives functional logic as well as the scan output pin. It isimpossible to extract the information from the gate-level netlist about whether the pin was therebefore scan insertion or has been introduced for scan purposes.

Figure 2-32. Failing identification

Figure 2-33 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.

Dscise

logic

scoDscise



November 2010

Figure 2-33. Common cell structure

For the same reason, the design rule check would fail also for the circuit shown in Figure 2-34.

Figure 2-34. Failing identification

K10Category: EDT





Description

Internal scan chain pins should not be part of a functional bus. Scan chain pins that are part of afunctional bus are not connected to the EDT wrapper during pattern-generation phase. A DRCviolation is reported if scan chain pins are part of a functional bus.

NoteScan chain pins can be part of a pure scan bus.

K11Category: EDT



sco

D

se

sci

Dscise

logic

sco





Description

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.

K12Category: EDT





Description

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.

K13Category: EDT





November 2010



Description

This rule check reports all pins that will be added to the EDT top level wrapper in order toimplement the EDT hardware.

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.

K14Category: EDT





Description

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.

K15Category: EDT





Description

This rule verifies that all scan channels have the proper top-level pins. All scan channels, exceptfor identical blocks set up for input channel sharing, require a dedicated top-level pin. This rulealso verifies that all EDT control pin sharing is set up properly.



K16Category: EDT





Description

This rule check verifies that the EDT clock signal has been added as a clock using the AddClocks command.

K17Category: EDT





Description

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.

K18Category: EDT





Description

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, Tessent TestKompress creates the EDT IP such that all thecontrol signals are active high. This check verifies that all control signals are, in fact,active high.



November 2010

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.

K19Category: EDT





Description

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.



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 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 C in the Tessent TestKompress User’s Guide.

K20Category: EDT





Description

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.

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.



November 2010

K21Category: EDT





Description

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.

K22Category: EDT





Description

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.

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.

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 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 C in the Tessent TestKompress User’s Guide.



November 2010

K23Category: EDT





Description

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.

Tessent TestKompress can generate EDT IP based on either edge-triggered flip flops or level-sensitive latches. By default, it generates EDT hardware based on flip flops, with a single clock.The edge-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.



K24Category: EDT


Scope: Top-level Pattern Generation Phase of modular Tessent TestKompress when EDTMapping in enabled

Default Handling: Note, Warning, and Error


Description

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 performs this verification by tracing connectivity between specified block-level signals(ports) and primary input or output pins. The tool verifies clock off states and pin constraintvalues while compensating for inversions in the path. During this rule check, all EDT signalsthat exist as ports on the block, but not as top-level pins, are updated to refer to the top-levelinput or output pins as determined by the tracing algorithm.

The K24 rule check outputs three different types of messages depending on the severity level ofthe results:

• Note — K24 outputs an informational note in cases such as when an EDT channelpinname is provided and a pin of that name exists at the top-level but not at the block-level or, in the case where the number of traced pipeline stages along the channel I/O donot match user-specified values.

• Warning — K24 issues a warning in cases such as when the traced top-level signal isdifferent from the user-specified signal.

• Error — K24 issues an error message in cases such as when an I/O pin or clock portcannot be found.

For detailed information about the creating a top-level dofile for the modular TessentTestKompress flow, see the Modular Tessent TestKompress chapter in theTessent TestKompress User’s Guide.

K25Category: EDT


Scope: Integration phase for the modular flow




November 2010


Description

All block-level EDT pins must be functionally connected in the netlist or have a connectionspecified during the integration session.

K25 verifies that each block-level EDT pin is either functionally connected in the netlist or hasa connection specified. If no connection exists or is specified, an error is returned.


// Error: Update pin in block "B1" is not driven in the netlist and doesnot have a defined connection. (K25-2)

Procedure Rules (P Rules)The test procedure file for each scan chain group is checked to ensure adherence to the formatrules and accuracy of the test procedure data. All violations of procedure rules are treated aserror conditions and cannot be changed—with the exception of rules P30, P31, P32, and P33,which can be ignored.

P1Category: Procedure




Description

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.







Description

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.





Description

The P3 rule checks if there is any event in the load_unload procedure at the boundary of theapply shift procedure. You can correct this error by editing the time value on the indicated lineof 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.





Description

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)



November 2010

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





Description

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.





Description

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.







Description

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.





Description

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.







November 2010

Description

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.





Description

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.





Description

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.







Description

The pin name argument for a force or pulse statement must be a valid pin name of a primaryinput or clock signal.

Messages

The occurrence message for a force statement 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.

The occurrence message for a pulse statement is:

Incorrect pin [or path] name, P. (P12-1)P is not a valid clock pin.

Where P is the pin or path name.

Troubleshooting

Edit the pin or path name on the indicated line of the test procedure file.

If the pin or path name refers to a clock signal, the clock must be defined using the Add Clockscommand.







November 2010

Description

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.





Description

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)






Description

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)








Description

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)






Description

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)








November 2010

Description

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)






Description

You cannot have two apply shift statements with a value greater than 1 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.

NoteYou can repeat the apply shift statement for as many serial shifts as necessary; however,you must specify 1 for the value in the additional apply shift statements.





Description

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)






Description

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)






Description

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)






November 2010



Description

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.




Description

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.




Description

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)








Description

The instance name argument for the initialize statement must correspond to at least oneprimitive-level latch or flip-flop gate instance. Correct this error condition by editing thestatement on the indicated line of the test 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.





Description

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.







November 2010

Description

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.





Description

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.





Description

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.





Description

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.





Description

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.




November 2010




Description

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.





Description

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.







Description

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.





Description

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)





Description

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)





November 2010



Description

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)





Description

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)





Description

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)







Description

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.





Description

If there are multiple test procedure files, there can be no more than one test_setup procedure.Correct this error condition by deleting the extra test_setup procedures. The error message is:

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

If there are multiple test procedure files, there can be no more than one test_end procedure.Correct this error condition by deleting the extra test_end procedures. The error message is:

Multiple test_end procedure defined in test procedure files. (P42)






November 2010


Description

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.





Description

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.





Description

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:



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.





Description

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.


Tools Supported: Tessent FastScan, FlexTest, Tessent TestKompress, and LBISTArchitectFault Sim



Description

The statement mentioned is not allowed to be used in the type of procedure that is named. Forexample, it is not legal to have a measure statement in a load_unload procedure.

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

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




November 2010




Description

The “set strobe_window time” command specifies a bad value for the strobe_window time.

Negative or zero strobe window specified. (P48)





Description

The Set Time Scale command specifies a bad time value.

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





Description

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.







Description

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.





Description

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.







November 2010

Description

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.

Resolving P53 Errors for Analyze Simulation Mismatches

When using the Analyze Simulation Mismatches command for a pattern with a P53 violation,the tool will issues an error and stops the DRC checking with the following error:

// Error: P53 violation may produce incorrect "analyze simulation// mismatches" result.// Suggest to fix the test procedure timeplate to avoid P53.

The problem of the P53 error is due to an undefined clock waveform in the used timeplate.

This violation can be seen when saving STI patterns as in the following example:

// command: save pattern testcase_failing_patt.v -verilog -serial -all// -rep// Warning: No clock pulse found in timeplate tp_shift which matches// event /RESETN in procedure used in patterns, two cycle clock pulse// will be used. (P53)

This example shows that the P53 error is issued when saving the Verilog test bench.

The reason for this is the /RESETN is pulsed in some patterns, but the timeplate used for thepattern “tp_shift” does not contain a pulse time for /RESETN, which causes the pattern toexpand the capture cycle into two cycles. The P53 rule changes the timing of test patterns andcauses an unnecessary increase in test application.

It is recommended you fix any P53 issues first when you want to debug the mismatch issue.







Description

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)

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





Description

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.







November 2010

Description

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.





Description

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 too small in procedure P. (P58)

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





Description

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)







Description

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.





Description

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)





Description

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)



November 2010

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.





Description

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.





The P66 rule is used to check for missing statements within a load_unload_registers procedure.For example, if no Shift block is specified, or if an event statement using the ‘#’ character is notpresent for each shift_assigment passed to the load_unload_registers procedure, then a P66 isissued.

Error: Procedure procedure_name is missing required statement_stringstatement. (P66)

See “Serial Register Load and Unload for LogicBIST and ATPG” for complete information.







Description

Alternate (named) shift procedures cannot be applied with a repeat count greater than one.

Alternate shift procedure name is applied with a repeat count greater thanone. (P70)

P71Category: Procedure Rules


Default Handling: Error (cannot be changed with the Set DRC Handling command)

Report Drc Rules: Not supported

Description

The pin pathname listed in an internal clock definition must be the pin pathname of an existingclock.

This rule verifies that the pin pathname specified by the CLOCK_CONTROL keyword in theclock definition defines an existing clock. Clocks are added with the Add Clocks command.Internal clocks are added with the Add Clock -internal command.

Error: Name "p1" used in clock control is not defined as a clock. (P71)

Where P1 is the pin pathname of the clock.


Tools Supported: Tessent FastScan, Tessent TestKompress





November 2010

Description

The global control conditions and source clocks defined in multiple clock controls of the sameor equivalent clocks must be exactly the same.

If the global controls defined in the multiple clock controls are not exactly the same, thefollowing error message is reported.

Error: Unable to load clock control for clock "p1" due to multiple clockcontrols with different global controls defined for the same clock. (P72)

If the source clock list defined in the multiple clock controls are not exactly the same, thefollowing error message is reported.

Error: Unable to load clock control for clock "p1" due to multiple clockcontrols with different source clocks defined for the same clock. (P72)






Description

A FORCE statement cannot be used to force an on value on a clock pin.

P73 verifies that no clock pins are forced on in clock control definitions.

If a FORCE statement is used to force an on value at a clock pin, the following error message isreported.

Error: Cannot force clock "p1" to its on value in clock control for clock"p2".(P73)

Where both P1 and P2 are the pin pathnames of the clocks.







Description

When multiple clock control definitions are used, compatible conditions must exist to turn offother clock pins while the clock being controlled is pulsed.

Also, a clock pin cannot be forced off when it is defined as a source clock.

This rule check verifies that the clock control conditions defined by multiple clocks arecompatible and that the clock being forced to off is not defined as a source clock in the sameclock control definition.

If incompatible clock conditions exist, the following error message is reported.

Error: Clock “P1” is explicitly forced off in clock control for clock“P2”. However, there is no way to force “P1” off while pulsing “P2”.(P74)

If the clock that is turned off is defined as the source clock in the clock control definition of theequivalent clock, the following error message is reported.

Error: Clock “P1” is forced to be off explicitly in clock control forclock “P2” while it is defined as source clock at the same time. (P74)

Where P1 and P2 are the pin pathnames of the clocks.





Description

Clock control definitions cannot contain conditions that force the clock being controlled or anequivalent clock to an off state.

If a FORCE statement is used to force a controlled clock off, the following error message isreported.

Error: Clock "p1" cannot be forced off when defining clock control for thesame clock.(P75)

If a FORCE statement is used to force an equivalent clock off, the following error message isreported.

Error: Clock "p1" cannot be forced off when defining clock control for itsequivalent clock "p2".(P75)

Where P1 and P2 are the pin pathnames of the clocks.



November 2010



Default Handling: Warning (cannot be changed with the Set DRC Handling command)


Description

At least one of the following components must be defined in a clock control definition:

• ATPG_CYCLE #, END block

• ATPG_SEQUENCE, END block

• ATPG_SEQUENCE <N> <M>, END block

• FORCE statement that forces the non-clock pin to off

• CONDITION statement

If none of the statements/procedures listed are present, one of the following warnings display:

Warning: The clock control for clock “P1” is unconditional for ATPG_CYCLE"p2".(P76)

Warning: The clock control for clock “P1” is unconditional forATPG_SEQUENCE applied to all capture cycles.(P76)

Warning: The clock control for clock “P1” is unconditional forATPG_SEQUENCE "p1" "p2". (P76)

Where P1 is the pin pathname of a clock and P2 and P3 are capture cycle numbers. The toolassumes that the clock is always pulsed in the specified capture cycles when test patterns aregenerated.





Description

A non-clock pin cannot be defined as a source clock.

This rule check verifies that the pin pathname specified by the SOURCE_CLOCK keyword is aclock pin.



If the pin pathname specified by the SOURCE_CLOCK keyword is not a clock pin, thefollowing error message is reported.

Error: Cannot define non-clock pin "p1" as SOURCE_CLOCK. (P77)






Description

Multiple sequence blocks for a clock must contain local force or condition statements.

If a {ATPG_SEQUENCE, END} or {ATPG_SEQUENCE <N> <M>, END} block is declaredwithout any local force or condition statement, the following error message is reported.

Error: Multiple ATPG_SEQUENCE blocks without local condition are definedin clock control for clock “P1”.(P78)






Description

A clock control definition containing both sequence and per-cycle blocks must providemutually exclusive force and/or condition statements to control clock pins.

If an ATPG_SEQUENCE block is declared both with and without force or conditionstatements, the following error message is reported.

Error: ATPG_SEQUENCEs with and without local condition are defined inclock control for clock “P1”.(P79)

If an ATPG_SEQUENCE block is declared without force or condition statements and aATPG_CYCLE block declares force or condition statements, the following error message isreported.



November 2010

Error: Both ATPG_SEQUENCE mode without local condition and per-cycle modewith local condition are defined in clock control for clock "p1".(P79)






Description

Conditions defined to pulse clocks in multiple clock control block definitions must be mutuallyexclusive.

This rule check verifies that:

• Sequence clock control conditions that pulse the clock are mutually exclusive with theper-cycle clock control conditions that pulse the same clock.

• Sequence clock control conditions that pulse the clock are mutually exclusive of theclock control condition used to pulse the same clock in another sequence definition.

If the clock control condition to pulse a clock in sequence block is not mutually exclusive withthe clock control condition for the same clock in a per-cycle block a P80 violation is reported.Depending on the violation, one of the following error messages is reported.

Error: In clock control for clock “P1”, the conditions defined inATPG_SEQUENCE "p2" "p3" are not mutually exclusive with the conditionsdefinedin ATPG_CYCLE P4.(P80)

Error: In clock control for clock “P1”, the conditions defined inATPG_SEQUENCE "p2" "p3" are not mutually exclusive with the conditionsdefinedin ATPG_SEQUENCE P4 P5.(P80)

Error: In clock control for clock “P1”, the conditions definedinATPG_SEQUENCE "p2" "p3" are not mutually exclusive with the conditionsdefined in ATPG_SEQUENCE applied to all capture cycles.(P80)

Error: In clock control for clock “P1”, the conditions defined inATPG_CYCLE "p2" are not mutually exclusive with the conditions defined inATPG_SEQUENCE applied to all capture cycles.(P80)

Where P1 is pin pathname of the clock and P2, P3, P4, and P5 are capture cycles.







Description

There must be a disabled condition defined for sequence clock control definitions, either byapplying a clock control condition or setting the source clock to the off state.

This rule check verifies that a clock controlled by a sequence block can be disabled.

If there is no way to disable a clock controlled by a sequence block a P81 DRC violation isreported. Depending on the violation, one of the following warning messages is reported:

Warning: No way to disable sequence mode clock control for clock “P1”.(P81)

Warning: No way to disable sequence mode clock control for clock “P1” bydisabling clock control condition. (P81)






Description

There must be a way to disable clocks defined with per-cycle clock control.

If there is no way to disable a clock defined with per-cycle clock control by either applying acondition or setting the source clock to the off state, the following warning message is reported:

Warning: No way to disable cycle mode clock control for “P1”.(P82)

If there is no way to disable a clock defined with per-cycle clock control using a condition, butit can be disabled by setting the source clock to the off state, the following warning message isreported:

Warning: No way to disable cycle mode clock control for clock “P1” bydisabling clock control condition.(P82)



November 2010






Description

When using per-cycle clock control, there must be a way to disable a clock after the capturecycle.

This rule check verifies the on condition for the clock during the capture cycle is mutuallyexclusive with the off state condition for the same clock after the capture cycle.

If there is no source clock defined or the source clock cannot be suppressed (defined as freerunning), one of the following warning messages is reported, and the generated test patterns donot include P1 capture cycles while the clock under control is pulsed at P1.

Warning: No way to pulse clock “P1” at capture cycle"p2" while turning off the same clock after the capture cycle "p2" incycle mode clock control for clock “P1”. (P83)

Warning: No way to turn off clock “P1” after capturecycle "p2" in cycle mode clock control for clock “P1”. (P83)

If it is possible to suppress the clock under control by turning off the source clock, one of thefollowing warning messages is reported.

Warning: No way to pulse clock “P1” at capture cycle"p2" while turning off the same clock after the capture cycle "p2" incycle mode clock control for clock “P1” by disabling clock controlcondition. (P83)

Warning: No way to turn off clock “P1” after capturecycle "p2" in cycle mode clock control for clock “P1” by disabling clockcontrol condition. (P83)

Where P1 is the pin pathname of the clock and P2 is the capture cycle.







Description

When both sequence mode and cycle mode clock controls are defined for a clock, there must bea way to disable the internal clock for both definitions.

This rule check verifies that a clock running in both sequential and per-cycle mode can bedisabled.

If a clock running in both sequence and per-cycle cannot be disabled, the following warningmessage is reported.

Warning: No way to disable both sequence mode and cycle mode clock controlfor clock "p1" simultaneously.(P84)






Description

When clock controls exist for two clocks not defined as equivalent, there must be a way to turnoff both clocks simultaneously during a capture cycle.

If both clocks cannot be disabled simultaneously during a capture cycle, the following warningmessage is reported.

Warning: Clock control is unable to turn off clock “P1” and clock “P2”simultaneously at capture cycle "p3". (P85)

Where P1 and P2 are the pin pathnames of the clocks and P3 is the capture cycle.







November 2010

Description

When clock controls exist for two clocks that are not defined as equivalent and one clock ispulsed during a capture cycle, there must be a way to turn off the other clock during the samecapture cycle.

If there is no source clock defined or all source clocks are defined as free-running the followingwarning message is reported:

Warning: Clock control is unable to turn on clock “P1” while turning offclock “P2” during capture cycle “P3”. (P86)

If it is possible to suppress the clock under control by turning off the source clock, one of thefollowing warning messages is reported:

Warning: Clock control is unable to turn on clock “P1” while turning offclock “P2” during capture cycle “P3” by disabling clock controlcondition.(P86)

Where P1 and P2 are the pin pathnames of the clocks and P3 is the capture cycle.





Description

A clock control cannot be defined for a free running clock.

If a clock control is defined for a free running clock, the following error message is reported.

Warning: Cannot define clock control for free running clock “P1”.(P87)








Description

A CONDITION or FORCE statement cannot assign a value to a non-scan state element.

If a CONDITION or FORCE statement assigns a value to a non-scan state element, thefollowing error message is reported.

Error: Value is forced at non-PI and non-scan cell "p1" in clock controlfor clock “P2”. (P88)

Where P1 is the pin pathname of the gate a value is assigned to and P2 is the name of the clockunder control.





Description

When you use clock control definitions, all unconstrained internal clocks (defined using theAdd Clocks -Internal command) must have an associated clock control definition.

When no clock control is defined for an unconstrained internal clock, the tool displaysfollowing error message:

Error: Clock control is not defined for the internal clock “P1”. (P89)

Where P1 is the clock pin pathname.

Note that the only time an unconstrained internal clock need not have a clock control definitionis when that clock is defined as being pin-equivalent to a top-level clock.





Description

Internal clock controls cannot be dependant on source clocks defined by other internal clockcontrols.



November 2010

For example, when the clock control for clock clk1 defines clk2 as source clock, the clockcontrol for clock clk2 defines clk1 as source clock.

However, you can define the clock under control as the source clock for itself to unconditionallyforce itself to an off state.

When no clock control is defined for an unconstrained internal clock, the following warningmessage is reported.

Error: Clock controls for clocks “P1” and “P2” depend on each otherthrough source clocks.(P90)

Where P1 and P2 are pin pathnames of clocks.





Description

Mutually exclusive control conditions cannot exist for different ATPG_CYCLEs of the sameclock.

If mutually exclusive control conditions are defined in different ATPG_CYCLES for the sameclock, the following error message is reported:

Warning: In clock control for clock “P1”, the conditions defined inATPG_CYCLEs "p2" and "p3" are mutually exclusive.

Where P1 is the clock pin pathname and P2 and P3 are capture cycles.

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, TessentFastScan, FlexTest, and Tessent TestKompress all perform to determine the stability of definedscan chains. The C1 and C7 rules perform these same checks on sequential elements that arealready converted to scan. For more information on C1 and C7, refer to “Clock Rules (CRules)” on page 44.

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 are warnings and, with the exception of S3, their handling cannot bechanged with the Set Drc Handling command. The default handling of the S3 rule is warningbut you can change its handling to other handling types. The following subsections describe thescannability rules and the special handling you can set for them.

S1Category: scannability

Tools Supported: DFTAdvisor and LBISTArchitect BIST-Ready



Description

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.You can use this gate identification number with the Report Gates command or theDisplay > Add menu item in DFTVisualizer to display the failing gate and its associated data.

To debug a S1 DRC Violation without DFTVisualizer, use the command “Analyze DrcViolation <violation_number>”. This will run the DRC analysis for the specific violation andallow the simulation data to be displayed. In the following example, the failure is due to theclock pin “CP” being set to X. To pass the S1 DRC, the clock must be set to its off state of 0.The command sequence noted will work with or without DFTVisualizer.

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-



November 2010

// "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 on the C1 clock rule, refer to “C1” on page 49.





Description

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 Gates command or Display > Add in DFTVisualizer to display thefailing 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” on page 72.





Description

All non-clock primary input pins in the clock cone of non-scan memory elements must beconstrained. If these pins are unconstrained and made scannable, trace violations may occur.

Non-clock primary input pins in the clock cone of non-scan memory elements should beconstrained in the ATPG dofile or in the load_unload procedure to correctly sensitize the clockpath.



Figure 2-35 illustrates S3 violations where the pin ‘clk’ is defined as the shift clock with an offstate value of ‘0’. The non-clock pin ‘en’ is the cause for the violations if it is left un-constrained.

Figure 2-35. Example S3 Rule Violation

The total number of S3 violations are reported in the session transcript during the DRC rulechecking. Individual S3 violations can be reported with the Report Drc Rules and Report DftCheck 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.

If you want to include some of those memory elements back in scan insertion, you can issueDelete Nonscan Instances commands on them before using the Run command for scan cellidentification. Similarly, if the S3 rule handling is “Warning” (the default), you can obtain thelist of the violations using the Report Dft Check or Report Drc Rules commands and issue AddNonscan 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.





Description

scannability rule S4 identifies and determines the handling of non-scan memory elements thatsatisfy all of the following conditions:

• Meet requirements for use as scan elements.

D Q

clken

udff

clk

en

udff

clk

enudfflatch

(a) (b) (c)

D Q D QE Q

‘0’



November 2010

• Maintain constant output values during the shift and capture cycles.

• Are in the clock and set/reset paths of other flip-flops/latches, RAMs, and ROMs.

• Contribute to the data lines of the memory elements in the clock and set/reset paths ofother flip-flops/latches, RAMs, and ROMs.

NoteFlip-flop/latch elements that maintain constant output values during shift and capturecycles can potentially disturb the clock and set/reset signals of other flip-flops/latches,RAMs, and ROMs if their constant output values are not maintained.

If non-scan cells that maintain constant output values and are associated with clock and set/resetsignals are converted to scan cells, they can prevent the clock and set/reset signal paths frombeing sensitized properly. When this occurs, more test logic may be required to sensitize theclock path.

You can specify how these non-scan cells are handled by setting S4 to one of the followinghandling options:

• Note — reports the non-scan cells to the log file and leaves them as non-scan cells.Default handling.

• Warning — reports the non-scan cells to the log file and converts them to scan cells.The resulting scan cells will have an unknown value (TIEX) for the output during theremainder of the DRC.

• Ignore — leaves them as non-scan cells.

You can report on the S4 results with the Report Drc Rules command.


Tools Supported: DFTAdvisor



Description

scannability rule S5 identifies clock sources that drive set/reset ports as well as clock ports.

When a clock source (a top-level pin or an internally defined clock net) drives the set/reset portof one or more flip-flops while also driving the clock port of one or more flip-flops, the set/resetport driven by this signal is reported as an S5 violation.



You can optionally “fix” S5 violations by adding test logic at the set/reset ports driven by theclock. DFTAdvisor will then treat the set/reset ports as uncontrollable and insert the same testlogic that is used to fix the set/reset ports of flip-flops with an S1 violation.


Tools Supported: DFTAdvisor



Description

scannability rule S6 identifies pre-existing scan cells that have driven scan-in ports and are notpart of declared scan chains or subchains and reports them as an S6 violation.

You can optionally fix S6 violations by explicitly declaring the scan chains or subchains that theidentified scan cells belong to. DFTAdvisor will then use this information in the test procedurefile to validate the traceability of declared scan chains or subchains.

You can optionally choose to change the handling of this rule to Warning. In this case,DFTAdvisor ignores the scan cells identified by the S6 rule when stitching scan chains duringthe scan chains generation process.

You can optionally declare the identified scan cells to be non-scan instances using the AddNonscan Instances command. In this case, DFTAdvisor ignore these cells when stitching scanchains during the scan chains generation process.

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.

T1Category: Trace






November 2010

Description

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.

T2Category: Trace




Description

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.


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

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

T3Category: Trace




Description

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 the



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

T4Category: Trace




Description

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.

T5Category: Trace




Description

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;



November 2010

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.

T6Category: Trace




Description

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.

T8Category: Trace




Description

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)

T9Category: Trace




Description

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.

T10Category: Trace




Description

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



November 2010

T is the maximum time.

T11Category: Trace




Description

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)

T12Category: Trace




Description

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.

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.



T13Category: Trace




Description

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)

T14Category: Trace




Description

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.


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

T15Category: Trace






November 2010

Description

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)

T16Category: Trace

Tools Supported: DFTAdvisor, Tessent FastScan, Tessent TestKompress, LBISTArchitectBIST-Ready, and LBISTArchitect Fault Sim



Description

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.

T17Category: Trace

Tools Supported: DFTAdvisor, Tessent FastScan, Tessent TestKompress, LBISTArchitectBIST-Ready, and LBISTArchitect Fault Sim



Description

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.

T18Category: Trace




Description

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.


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.

T19Category: Trace




Description

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.



November 2010

T20Category: Trace




Description

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.

T21Category: Trace




Description

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.

T22Category: Trace






Description

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.

T23Category: Trace




Description

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.

T24Category: Trace

Tools Supported: DFTAdvisor, Tessent FastScan, Tessent TestKompress, and LBISTArchitectFault Sim





November 2010

Description

When two adjacent memory elements (source and sink) in a scan chain path are clocked bydifferent shift clocks, the sink must not capture data from the source at the same time (or after)the source changes its value. Failure to satisfy this rule can result in unwanted shoot-throughduring scan chain shifting when clock skew exists between the different shift clocks.


A lockup latch may be required between N1 (G1) of cell M1 and N2 (G2) ofcell M2 in scan chain S. (T24-1)

N1 and N2 are the instance names of the adjacent elements clocked by different clocks. G1 andG2 are the corresponding gate IDs. M1(M2) is the cell ID of the scan cell in which N1(N2) islocated. S is the name of the scan chain.

NoteIf N1(N2) is not within a scan cell, M1(M2) is the cell ID of the scan cell that is driven byN1(N2).

You can correct the violation by inserting a lockup latch between the adjacent memory elementsreported in the violation message. To find out which clocks are involved, use the command,Report Scan Cells -Range cell_id1 cell_id2.

T25Category: Trace

Tools Supported: Tessent FastScan, FlexTest, and Tessent TestKompress



Description

Scan chain tracing must be independent of whether or not a gate with an X value is initialized toa known value (either 0 or 1). Figure 2-36 is an example of a T25 violation.



Figure 2-36. Example of T25 Violation

In Figure 2-36, the scan path is from DFF gate 25 to PO gate 26. If PI gate 1 is initialized to 1,then the actual scan path is the upper path from gate 25 to gate 26. If PI gate 1 is initialized to 0,then the actual scan path is the lower path from gate 25 to gate 26. In either case, the scanshifting is successful; however, a simulation mismatch could occur in Verilog if PI gate 1 is notinitialized (remains an X value). The warning message is:

There is a T25 violation. Scan chain tracing has assumed that some gateswith X values are initialized to any non-X values. This is not a problemin silicon but may cause Verilog simulation mismatches. For moreconservative scan chain tracing, please use the command: “set drc handling-scan_chain_tracing conservative”.

You can display the T25 violation using the “report drc rule T25” command as shown in thefollowing example:

ATPG> rep drc rule T25

Warning: Scan chain tracing between scan output and scan cell 0 (fromgate 24 back to gate 14) in scan chain 0 assumes that some gates with Xvalues are initialized to any non-X values. (T25-1)

You can debug T25 violations by displaying the gate value in scan shift. To do this, use the SetGate Report command to set gate reporting to drc shift and use the Report Gates command withthe gate ID number displayed in the message.

The default handling for this rule violation is warning. If you do not want scan chain tracing topass with a T25 violation, use the “set drc handling -scan_chain_tracing conservative”command. For more information, see the Set Drc Handling command in the ATPG and FailureDiagnosis Tools Reference Manual.

T26Category: Trace





November 2010

Description

The shift procedure must create a sensitizable path through bidirectional pins at the scan chainoutput or EDT channel output. The improperly sensitized bidirectional pin causes an errorcondition.

For scan chain output, the tool issues the following error message:

Scan chain tracing failed at bidirectional scan chain output pin N inchain "C". The pin is not forced to Z during measure_sco. (T26-1)

For EDT channel output, the tool issues the following error message:

Scan chain tracing failed at bidirectional channel output pin N in block"B". The pin is not forced to Z during measure_sco. (T26-2)

N is the pin name, C is the corresponding chain name, and B is the corresponding EDT blockname.

You can avoid this rule violation by adding a force to Z for the reported pins in the shiftprocedure before measure_sco. Alternatively, you can force all bidirectional pins with a ‘force_ALL_BIDI Z’ in the shift procedure before measure_sco. The _ALL_BIDI is a macro thatselects all primary bidirectional pins.

You can also define the pin as an output pin instead of as an inout pin in your Verilog file. Bydoing this, then there is no need to force this pin to Z anymore.

Power-Aware Rules (V Rules)These are the DRC rules checked for power-aware designs. You must load power data (usingthe Read Cpf or Read Upf commands) before using the Report Drc Rules command for the VDRC rules.

When using the power-aware DRC rules, the following conditions apply:

• Rule V1 to V7 — Checked after reading a power data file.

• Rule V8 to V21 — Checked when switching from Setup mode to a non-Setup mode.

The tool displays a summary of the V rules when you load power data into the tool without anyparsing errors. For example:

SETUP> read upf my_design.upf

SETUP> report drc rules –summary

…T26: #fails=0 handling=error (bidirectional chain / channel outputs notforced to Z during chain tracing)V1: #fails=0 handling=ignore/verbose (no power modes are defined)



V2: #fails=0 handling=ignore/verbose (no default power modes aredefined)V3: #fails=0 handling=error (multiple default power modes are defined)V4: #fails=0 handling=error (no default power domains are defined)V5: #fails=0 handling=error (multiple default power domains are defined)V6: #fails=0 handling=warning (no restore_edge or default_restore_edgeis defined)V7: #fails=0 handling=warning (power mode is not reachable)V8: #fails=0 handling=error (scan data path is in a power-off domain)V9: #fails=0 handling=error (scan control path is in a power-off domain)V10: #fails=0 handling=error (power start/end/shutoff condition is Xduring the scan shift period)V11: #fails=0 handling=error (active power mode has changed during thescan shift period)V12: #fails=0 handling=warning (active power mode may change during thecapture cycle)V13: #fails=0 handling=warning (path crosses power domains without alevel-shifter cell)V14: #fails=0 handling=warning (path crosses power domains without anisolation cell)V15: #fails=0 handling=note (scan chain contains both retention andregular cells)V16: #fails=0 handling=note (scan chain contains both always-on andother types of cells)V17: #fails=0 handling=note (EDT channel contains both retention andregular cells)V18: #fails=0 handling=warning (power control signals are in a domainthat could be powered-off)V19: #fails=0 handling=warning (retention save signal is not off duringshift)V20: #fails=0 handling=note (non-scan retention cells are identified inthe design)V21: #fails=0 handling=error (power data assertions are detected)

V1Category: Power Aware


Default Handling: Error for CPF format


Description

No power modes are defined when there are multiple power domains. You cannot change thehandling. The violation message is:

At least one power mode is required when multiple power domains aredefined (V1).

Because power modes in UPF are implicitly learned through power switches control logic, theV1 rule is ignored in UPF format.



November 2010



Default Handling: Error for CPF format


Description

No default power modes are defined when there are multiple power modes. You cannot changethe handling. The violation message is:

A default power mode is required when multiple power modes are defined(V2).

The V2 rule is ignored for UPF format.





Description

Multiple default power modes are defined. You cannot change the handling. The violationmessage is:

Multiple default power modes are defined (V3).





Description

No default power domain is defined when there are multiple power domains. You cannotchange the handling. The violation message is:

A default power domain is required when multiple power domains are defined(V4).







Description

Multiple default power domains are defined. You cannot change the handling. The violationmessage is:

Multiple default power domains are defined (V5).





Description

Either restore_edge or default_restore_edge must be defined if the design contains any retentioncells; if this rule is violated, the state retention rule is ignored and no retention value is restored.

Note that missing both save_edge and default_save_edge is allowed on CPF as long asrestore_edge or default_restore_edge is defined. In this case, the inversion of restore_edge (ordefault_restore_edge when restore_edge is missing) will be used as save_edge. The violationmessage is:

No restore_edge is defined for the state retention rule name. (V6-n).







November 2010

Description

A defined power mode is not reachable from the default power mode with the defined powertransition rules. The violation message is:

Power mode name1 is not reachable from the default power mode name2 usingany defined power transition rule (V7-n).

The V7 rule is ignored for UPF format.





Description

The scan tracing should not propagate to a scan cell in a power domain that is in the shutoffstate. Note that the number of power OFF gates in a given scan chain can be large, so only oneV8 violation is recorded per scan chain and the first scan path gate from the sco pin is reported.Violation of the V8 rule can be due to at least one of the following reasons:

• The power mode definition is incorrect.

• The shutoff condition of the power domain is defined incorrectly.

• The test procedures (for example, load_unload or shift) for the scan chain operation aredefined incorrectly.

• The inserted scan logic of the design does not consider the power mode properly.

The violation message is:

The scan path of chain chain-name is in power off domain domain-name (thefirst power off scan path gate is N1 (G1) after tracing C cells ) (V8-n)







Description

All control logic for the scan operation must be in a power ON domain during the entire scanshift operation. Some popular control logic examples are listed below:

• If EDT logic exists in the design, it should stay at power ON mode during the scan testwhen the compression mode is used; otherwise the scan operation will fail.

• If scan_enable signal is derived from a JTAG controller, the JTAG controller shouldstay at power ON mode during the scan test.

• The shift clock control logic should remain at power ON mode during the scan test. Thetool performs the check by monitoring all test procedures except test_setup and ensuresthat the power domains where the scan control logic are located remain at the power ONmode after test_setup procedure.


The scan chain chain-name is blocked at N1 (G1) after tracing C cells dueto the control gate N2 (G2) in power off domain domain_name (V9-n).





Description

The expression used by mode_transition rule and shutoff condition should not be X during thescan shift period. The tool performs the rule by checking all events to ensure that no expressioncan be X during the scan shift operation. The expressions to be checked include the shutoffcondition of every power domain and the start and end conditions of every mode_transitionrule.

The violation messages are:

Case 1 — When shutoff condition of a power domain is X:

The shutoff condition of power domain name is X at time t of procedureprocedure-name (V10-n).

Case 2 — When the start condition of a mode_transition rule is X:

The start condition of mode transition rule name is X at time t ofprocedure procedure-name (V10-n).



November 2010

Case 3 — When the end condition of a mode_transition rule is X:

The end condition of mode transition rule name is X at time t of procedureprocedure-name (V10-n).

The handling of X is different based on the handling of the V10 DRC rule. When the handlingof the rule is set to warning, the condition of X will be treated as HI as if the condition issatisfied. When the handling is Note, the condition of X will be treated as LO as if the conditionis not satisfied. Note, the violation of this rule may cause the design to be in the wrong powermode and thereby cause a simulation mismatch.





Description

During scan chain shift operation, the design should not change power modes because this cancause some power domains to be switched between power OFF mode and power ON mode.This occurs because changing active power domains during the shift period may cause the scanchain configuration to be changed. The tool performs the rule by checking the shutoffexpressions of all power domains to ensure they remain false during the scan shift period.


Case 1 — When mode transition rules are defined:

Active power mode changed from mode1 to mode2 at time t of procedureprocedure_name (V11-n).

Case 2 — When mode transition rules are not defined:

The power domain name changed from state-1 to state-2 at time t ofprocedure procedure_name (V11-n).

When the handling of the violation is not error, the scan shift operation may be unreliable andthis can result in a simulation mismatch. Note that a mismatch may not be seen in the paralleltest bench and this can make the debugging process more complicated.







Description

ATPG should not create patterns that can turn off an active power domain during the capturecycle; turning off an active power domain during the capture period changes the scan chainconfiguration. The tool performs the rule by checking on active power domains with shutoffexpressions and ensuring they cannot be true during the capture period.


Case 1 — When mode transition rules are defined:

The power mode may change from name1 to name1 during the capture cycle(V12-n).

Case 2 — When mode transition rules are not defined:

The power domain name may change state during the capture cycle (V12-n).

When the shutoff condition is true and the handling of the violation is not error, the capturevalue of the scan cells in the shutoff power domain remains the same as if the power domain isstill active. This may cause some test patterns to fail in silicon that may not be detected duringthe logic simulation phase.





Description

A path should not cross different power domains without a level-shifter cell if the powerdomains can operate in different operation voltages. The following three situations can cause aV13 DRC violation:

• An instance is driven by another instance of a different voltage power domain.

• The scan_in pin or the EDT decompressor to the first scan cell crosses different voltagedomains.

• The last scan cell to the scan_out pin or EDT compactor crosses different voltagedomains.

• The scan cell (i+1) to scan cell i crosses different voltage domains.



November 2010


Case 1 — When violation is on a non-scan path:

Path from gate N1 (G1) to gate N2 (G2) crosses different voltage domainswithout a level-shifter cell (V13-n).

Case 2 — When violation is on a scan path:

Scan path from gate N1 (G1) of cell (i+1) to gate N2 (G2) of cell i of scanchain chain-name crosses different voltage domains without a level-shiftercell (V13-n).





Description

If a scan path crosses two power domains and the driving power domain contains the shutoffcondition, the path must include an isolation cell. Similar to rule V14, there are three situationsto be considered for this rule.


Case 1 — When violation is on a non-scan path:

Path from gate N1 (G1) to gate N2 (G2) crosses different power domainswithout an isolation cell (V13-n).

Case 2 — when violation is on a scan path:

Scan path from gate N1 (G1) of cell (i+1) to gate N2 (G2) of cell i of scanchain chain-name crosses different power domains without an isolation cell(V14-n).







Description

A scan chain should not include both retention cells and regular scan cells. A violation of thisrule will make retention test less efficient.


Scan chain chain-name contains both retention cells and regular cells(V15-n).





Description

Typically, always-on cells are used to program power mode and retention mode. To make thecontrol of the power mode more efficient, a scan chain should not include both always-on cellsand other types of scan cells.


Scan chain chain-name contains both always-on cells and other type ofcells (V16-n).





Description

An EDT scan channel should try to prevent the mix of scan chain with retention cells and,regular scan chain without retention cells. This rule prevents the retention cells from beingmasked by regular cells when the circuit is restored from the retention mode.


Scan channel channel-name contains both retention scan chain and regularscan chain (V17-n).



November 2010





Description

All power control signals, including retention save, retention restore, isolation_enable, andpower-domain shutoff conditions should be from always-on power domains that cannot beturned off.


Shutoff condition condition_expression for domain domain_name is in non-always-on power domain (V18-n).





Description

Retention save signals should be off during the scan shift period to prevent the loading valuefrom being overridden by the retention saved state.


Save signal condition_expression for retention rule rule_name is not offduring the scan shift period (V19-n).







Description

Only scanned retention cells are supported by the retention test to test the retentionfunctionality. So this rule checks if there are any non-scan retention cells.


Retention cell cell_name is a non-scan cell (V20-n).





Description

The design should never enter any illegal power configurations specified in CPF commandassert_illegal_domain_configurations during any test cycle.


The active power mode violates assert_illegal_domain_configurations nameat time t of procedure proc_name (V21-n).

NoteCPF and UPF power data parsers support the TCL scripting mechanism. The violation ofthe TCL format results in an error. Note, the format of the error message is not describedin this document.

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

W1Category: Timing

Tools Supported: DFTAdvisor, Tessent FastScan, FlexTest, Tessent TestKompress, andLBISTArchitect Fault Sim





November 2010

Description

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 than existing procedure. (W1)

P is the name of the new procedure.

W2Category: Timing




Description

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)


W3Category: Timing




Description

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)




W4Category: Timing




Description

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.

W5Category: Timing




Description

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

W6Category: Timing





November 2010


Description

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 “Creating Test Procedure Files forEnd 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.

W7Category: Timing




Description

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)


W8Category: Timing




Description

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)


W9Category: Timing




Description

The named procedure has no event statements, no apply statements, and no timeplatereferences.

No events in procedure P. (W9)


W10Category: Timing




Description

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)

W11Category: Timing






November 2010

Description

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.

W12Category: Timing




Description

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.

W13Category: Timing




Description

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)


W14Category: Timing




Description

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.

W15Category: Timing




Description

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 “Creating Test Procedure Files for 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.

W16Category: Timing



November 2010

Tools Supported: DFTAdvisor and FlexTest



Description

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 Constraints, Add Pin Strobes,Setup Pin 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.

W17Category: Timing




Description

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.

W18Category: Timing






Description

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)

W19Category: Timing




Description

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)

W20Category: Timing

Tools Supported: DFTAdvisor, Tessent FastScan and Tessent TestKompress



Description

This error occurs if, in a capture procedure, a force_pi event does not occur before the first clockpulse.



November 2010

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.

W21Category: Timing




Description

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.

W22Category: Timing




Description

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.

W23Category: Timing

Tools Supported: DFTAdvisor, Tessent FastScan, and Tessent TestKompress



Description

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.

W24Category: Timing




Description

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.



November 2010

W25Category: Timing




Description

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.

// Warning: External event pulse S at time T needs to have a matchinginternal event in procedure P or the signal needs to be disconnected frominternal sequential elements or observe points. (W25-1)

Where S is the signal name, T is the time of the event, and P is the procedure name.

In Tessent Diagnosis, these violations if uncorrected can cause pattern verification errors in thetool. See the Tessent Diagnosis User’s Guide for more information.

W26Category: Timing




Description

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.



W27Category: Timing




Description

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.

W28Category: Timing




Description

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.

W29Category: Timing




November 2010



Description

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.

W30Category: Timing




Description

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.

W31Category: Timing






Description

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:

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

W32Category: Timing




Description

A force_pi in a named capture procedure must not occur when a clock is in an on state.

W32 ensures the procedure file is valid.

This DRC checks the force_pi statement in named capture procedures in the procedure filewhen loading a new procedure file, which can occur during DRC, when the Read Procfilecommand is used, or when the Save Patterns command is used with a new procedure filespecified on the save patterns command line.

Messaging

If the procedure file fails W32, the following message displays:

A force_pi statement occurs while a clock or control is active inprocedure P (W32).

Where P is the name of the procedure file.

Troubleshooting

To correct this violation, edit the procedure file so the force_pi statement does not occur duringthe time that a clock is in its on state.



November 2010

W33Category: Timing




Description

The named capture procedure in the procedure file cannot be loaded using the-Append_or_timing_update switch in the Read Procfile command.

W33 ensures the procedure file is valid.

This DRC checks a new procedure file when it is loaded with the Read Procfile or Save Patternscommand. A W33 violation occurs when the new procedure file contains a new scan procedure(load_unload, alternate shift, master_observe, and so on) or a new named capture procedure.W33 is only issued for new named capture procedures if the -Append_or_timing_update switchis specified with the Read Procfile command.

Messaging

If the test_setup procedure file fails W33, the following message displays:

Cannot add new procedure P, procedure ignored (W33)

Where P is the procedure name.

Troubleshooting

To correct this violation, do one of the following:

• If the violation is for a named capture procedure, either change the Read Procfilecommand option from -Append_or_timing_update to -Replace or edit the procedure fileto remove the named capture procedure.

• If the violation is for a scan procedure, edit the procedure file to remove the scanprocedure.

• For both cases, you can return to Setup mode and load the procedure file with the AddScan Groups command.

W34Category: Timing






Description

This error occurs when saving patterns if a force event in the external mode conflicts with a pinconstraint in a named capture procedure.

//Error: Event E N at time T in external mode conflicts with pinconstraint on same pin in procedure P. (W34)

Where E is the event type, N is the name of the event pin, T is the time at which the conflictoccurs, and P is the name of the procedure that contains the conflicting pin constraint.

To resolve this issue, either the pin constraint or the named capture procedure must be changed.If this error is ignored, you will not be able to load external mode STIL or WGL patterns backinto the tool because the pattern data (using the force event) will not match the pin constraint.

W35Category: Timing




Description

This error occurs when a free running clock needs to be added to a cycle, and that cycle uses atimeplate that has no pulse timing for the clock.

//Error: The following occured at line N in file FFree running clock C is not pulsed in T. (W35)

Where N is the line number, F is the filename, C is the clock name, and T is the timeplate name.

The W35 rule is an error, and the handling cannot be changed.

W36Category: Timing






November 2010

Description

This error occurs when “offstate” statements in the timeplates used by a named captureprocedure are defined for a pin that has already been defined as a clock in the dofile. Theunnecessary “offstate” statements cause extra pulses in a cycle.

// Error: Offstate cannot be used with pin N already defined as a clock(W36)

Where N is the name of the clock pin.

To resolve this error, remove the unnecessary “offstate” statements from the timeplates.

W37Category: Timing

Tools Supported: DFTAdvisor, Tessent FastScan, DFTAdvisor, and Tessent TestKompress



Description

Each load cycle of a named capture procedure must include a force_pi event. The ATPG toolsrequire a force_pi event after each scan load. If there is no force_pi event in the load cycle of anamed capture procedure, the generated test patterns may be incorrect and produce errors whenread back into the ATPG tools.

The W37 violation does not override or mask a W20 violation. Therefore, if this error occurs inthe first cycle and there is no force_pi event before the first clock pulse, then both a W37 andW20 violation are issued.

The W37 rule can be reduced to a warning or note only if every signal having a force event in aload_unload procedure has a pin constraint defined with a matching value.

Messages


//Error: A force_pi statement does not exist in a scan load cycle inProcedure P. (W37-1)

Where P is the name of the procedure.

Troubleshooting

Edit the load cycle(s) of the named capture procedure to include a force_pi event.



W38Category: Timing




Description

This rule checks to see if free running clocks that are pulsed in the external mode of a namedcapture procedure and are internally connected also pulse in the internal mode of the namedcapture procedure at the same time.

//Error: The following occured at line N in file FEvent E on a free running internally connected in at time T in externalmode does not have matching event in internal mode in procedure P. (W38)

Where N is the line number, F is the filename, E is the event type, T is the time at which theconflict occurs, and P is the name of the procedure that contains the conflicting pin constraint.

A PLL clock going to a sequential cell can also produce a W38 violation.

This rule defaults to error handling. If you set the rule to warning handling, then the toolattempts to auto-correct the W38 problem by copying external mode event(s) to the appropriatetime in the internal mode. If the auto-correct fails (for example, a W35 violation in the internalmode), then the W38 rule’s handling is changed to an error.


Design Rule CheckingOther DRC Messages

November 2010

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, an analysis messagedisplays 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-37 describes each component of the messages.

Figure 2-37. Transparent Capture Handling Analysis Messages

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.

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

# of gates on path(s)

# of memory elements that might capture

CPU time to analyze (in seconds)

captured correctly without capture handling

between source(s) & sink(s)

incorrect values without capture handling



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-38 describes the information displayed after running RAM rules checking.

Figure 2-38. 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



November 2010


Chapter 3Getting Started with DFTVisualizer

DFTVisualizer provides a visual means of browsing and troubleshooting designs from thefollowing DFT tools:

• DFTAdvisor

• Tessent FastScan

• FlexTest

• LBISTArchitect

• Tessent TestKompress

• Tessent Diagnosis™

Opening DFTVisualizerDepending on your need, enter one of the following commands from within a tool to openDFTVisualizer:

• Any command that provides a -Display argument. For example:

open visualizer -display browser design data

• Analyze Drc Violation opens DFTVisualizer with the Debug window displaying aschematic of the parts of the design associated with the specified DRC violation.

For example:


Understanding the DFTVisualizer WindowsDFTVisualizer contains windows for viewing and debugging design and simulation data.Access these windows from the Windows pulldown menu.

• Task Manager Window — Displays a quick list of tasks to choose from.

• Debug Window — Displays a schematic representation of the flattened model of yourdesign. The schematic can be at the design or primitive level.


Getting Started with DFTVisualizerUnderstanding the DFTVisualizer Windows

November 2010

• Design Window — Displays a hierarchical schematic of the design as described in theinput netlist. Includes net names and hierarchical ports. Goes down to library levelinstances.

• Browser Window — Displays tabs for accessing multiple windows:

o Hierarchy Browser — Navigates the design hierarchy and displays coverage andDRC statistics for hierarchical blocks.

o Library Browser — Displays statistics on the ATPG library models used in adesign. By default, consolidated data for each ATPG library model displays. Eachlibrary model can then be expanded to display statistics for the individual instancesof the model.

o Clocks Browser — Displays all of the clocks in the design and their attributes. TheClocks Browser allows you to navigate through the design hierarchy and view thefaults for each individual clock and analyze the distribution of faults between clockdomains.

• Signals Window — Displays pins and signals for instance selected in any tab of theBrowser window.

• Data Window —Displays DRC and pattern data for specific instances and signals.

• Wave Window — Provides a waveform representation of test_setup data and namedcapture procedures (related to Data window).

• Global Search Window — Allows you to search for any instance, net, or pin in theactive design.

• Format Guide Window — Provides illustrative waveforms of what the pattern datadisplayed in the Data or Debug window means.

• Transcript Window — Displays notes, warnings, and errors applicable to the session.

• Test Structures Window — Displays graphical representation of the EDT logicinserted by Tessent TestKompress.

Getting Started with DFTVisualizerUnderstanding the DFTVisualizer Quality Agent


Understanding the DFTVisualizer Quality AgentWhen internal errors occur, it can be difficult to recall previous steps and recreate the problem.However, DFTVisualizer produces an error transcript that usually provides enough informationto enable our Customer Support team to identify the problem. The new Quality Agent, shown inFigure 3-1, enables you to do the following:

• Automatically send transcripted error information to Mentor Graphics by clicking abutton.

Sending this feedback ensures that the problem you experienced is addressed as quicklyas possible. This enables Mentor Graphics to provide the highest product quality.

• Choose whether you want to restart DFTVisualizer following the internal error.

You can use this option to automatically restart DFTVisualizer after the report is sent.This is usually the recommended action when an internal error occurs. If you want topreserve the displayed data for capturing screenshots or any other reason, you candecline this option and perform a manual restart using the open visualizer -restartcommand.

• Choose whether to be notified when the problem has been addressed.

Figure 3-1. DFTVisualizer Quality Agent

NotePlease be aware that when you send feedback, absolutely NO DESIGN DATA iscommunicated to Mentor Graphics.


Getting Started with DFTVisualizerPerforming Basic Tasks

November 2010

Performing Basic TasksTypically, you will open a number of windows as you explore the tool’s database, so developinggood window management and navigation technique is helpful.

Saving and Restoring DisplaysWhen you have a set of window and data displays you might like to restore later, use theFile > Create Dofile menu item. This enables you to write out a dofile containing commands torecreate the instances and data sets currently displayed in DFTVisualizer windows.

To restore the window and data displays, enter a Dofile command and specify the saved dofileas an argument.

NoteThe commands in this dofile do not replicate the entire command sequence used in thetool session. They simply add the instances and data sets that were present in theDFTVisualizer windows when you wrote out the dofile.

Searching for an Instance, Net, or PinYou can search the active window or the entire design for a specified instance, pin, or net usingthe search field on the toolbar window as follows.

1. Click in the search field and enter a string to search on. You can use the questionmark(?) or asterisk(*) as wildcard characters.

2. Depending on the desired search, click one of the following icons:

o — Searches the active window for the specified string.

o — Searches the entire design for the specified string.

Depending on the active window, a list of the components that match the specified stringdisplays.

Interrupting Operations from DFTVisualizerYou can interrupt some DFTVisualizer operations at any time by pressing Control-C in theactive DFTVisualizer window or, alternately, by pressing the Stop icon. The followingoperations can be interrupted/canceled:

• Data generation for faults, DRCs, gates and primitives in the Hierarchy browser

• Searching in the Global Search window

• Tracing forward/backward to endpoints for instances and pins in the Design window



• Tracing down in the Design window

• Pattern creation

Undocking and Docking WindowsEach special purpose window can be undocked from the main window. When undocked, youcan move the window around on your desktop independent of the main window.

• To undock a window, click the middle button of the three just outside the upper rightcorner of a window’s display area.

• To dock the window, click the middle button again.

Tip: You can also undock/dock a window by pressing the left mouse button over thecenter of the window’s header bar and simultaneously dragging it outside/back into themain window.

Resizing WindowsEach window can be resized using the little square in the upper left-hand area in the bar betweenthe displayed windows. Each special purpose window, when docked, also has a maximizebutton that expands to completely occupy the window. The maximize button is the left-mostbutton of the three just outside the upper right corner of the window’s display area.

• To expand a docked window, click its maximize button.

• To return a docked window to its former position and size within the main window,click the button again.

Repositioning WindowsUse this procedure to reposition windows in DFTVisualizer.

Prerequisites

DFTVisualizer is invoked and at least two windows are open. For more information, see the“Opening DFTVisualizer” section in this chapter.

Procedure

1. Press the left mouse button over the icon in the center of the window's header barand simultaneously drag it to the new location. A dynamic outline of the window in thenew location appears when you have moved the mouse sufficiently for the tool tosuccessfully determine the desired location.



November 2010

2. Release the mouse button. The window is anchored in the new location.

Understanding Popup MenusTo access items on a popup menu, press the right mouse button in the display area of anywindow. The menu options on the popup menu vary as follows.

• Debug and Design window

If no objects are selected and the cursor is not positioned directly over an object, themenu is a simple one for adding instances to the window’s display area. If an object isselected or the cursor is positioned over an object, the popup menu displays optionsneeded for tracing and debugging.

• All windows except for the Debug and Design window

The object the cursor is positioned over when you open the popup menu (press the rightmouse button) is automatically selected and the menu applies to it.

Copying an Object Name from a Popup Menu to the SystemClipboard

When you open a popup menu on a single selected object, the object’s pathname is listed as thefirst menu option. If you choose the name from the menu, it is copied to the system clipboard.

You can then paste the name into other desktop locations, such as a shell window, toolcommand line, or dialog entry box.

Adding Instances to a Display WindowAdd instances to a window display using one of the following methods.

Prerequisites

DFTVisualizer is invoked. For more information, see the “Opening DFTVisualizer” section inthis chapter.

Method 1

Copy the instances from another window. See “Copying Instances Between Windows” onpage 264 for details of this method.

Method 2

Use the Add Instances icon on the toolbar.



Related Topics

Add Display Instances command.

Selecting ObjectsSelect objects displayed in a window using one of the following methods:

Prerequisites

DFTVisualizer is invoked and objects are displayed in one or more windows. For moreinformation, see “Adding Instances to a Display Window” on page 260.

Method 1

To select a single object, move the cursor over the object and click the left mouse button. Whenselected, the object will be highlighted in a different color. You can customize the highlightcolor using the Edit > Preferences menu item.

Method 2

To select additional objects without simultaneously unselecting previously selected objects,press and hold the Shift key while selecting additional objects using the left mouse button.

Cross-Selecting ObjectsCross-selection occurs when you select objects in one window and they are simultaneouslyselected in all windows in which they are already displayed. You can optionally direct the toolto cross-select objects using one of the following methods:

Tip: Use cross-selection to flag an instance so you can identify it easily when viewinginformation about it in multiple windows.

Prerequisites

DFTVisualizer is invoked and objects are displayed in one or more windows. For moreinformation, see “Adding Instances to a Display Window” on page 260.

Method 1

Move the cursor over the object you want to select, press the right mouse button, and choose theCross Select option from the popup menu.



November 2010

Method 2

If one or more objects is already selected in a window, press the right mouse button fromanywhere in the window’s display area, and choose the Cross Select option.

If you prefer to have cross-selection occur by default whenever you select an object, withoutrequiring a menu pick, enable the Automatically Cross Select In All Windows option in theGlobal Preferences Dialog Box. Access the dialog box with the Edit > Preferences menu item.

Selecting Objects in the Debug or Design WindowThere are a couple of additional ways to select objects in the Debug and Design windows:

• To select one or more objects (nets, pins, and/or instances) on a schematic, press the leftmouse button and drag the cursor so the bounding box contains all the objects you wantselected.

• To select all displayed instances on a schematic, use the Edit > Select All (Ctrl + A)menu item.

Unselecting ObjectsTo unselect the selected objects in a window, click in a blank part of the display area of thewindow. You can also use the Edit > Undo menu item if available for the window.

Moving Objects in the Debug or Design WindowUse this procedure to move an object to a new location in either the Debug or Design window.

Prerequisites

DFTVisualizer is invoked and at least one object is displayed in the active window. For moreinformation, see “Adding Instances to a Display Window” on page 260.

Procedure

1. Position your cursor over the object you want to move.

2. Simultaneously, press and hold the Shift key while pressing and dragging the left mousebutton. A ghost image of the object(s) appears and moves across the screen as the cursormoves.

3. Release the left mouse button to anchor the object at the location of the cursor.

Note If you add or delete an instance after moving an object, DFTVisualizer will re-optimizethe view based on the new window content and your change will be lost.



Customizing Marking Colors in the Debug, Design, andTest Structures Windows

Use this procedure to specify the number of colors available to mark objects in the Debug,Design, and Test Structures windows and also to customize which colors are available. Thecolors set with this procedure are available on the cascading menus when you choose theDisplay > Marking (Ctrl + M) pulldown menu or Marked popup (RMB) menu.

Prerequisites

DFTVisualizer is invoked.

Procedure

1. Choose Edit > Preferences and click the Colors tab.

2. Click the window name in the Windows List field for which you want to customizecolors. The window name becomes highlighted.

3. Click Marked in the Options List. The No. of Colors and Color Index buttons, whichare only related to marking, display.

4. Click the No. of Colors and select a number to choose the number of colors you want touse when marking objects.

5. Click Color Index to select the number for which you want to assign a color and thenclick the desired color from the Color Palette.

6. Click OK to save your selections.

Marking and Unmarking Objects in the Debug, Design,and Test Structures Windows

Use this procedure to mark and unmark objects in the Debug, Design, and Test Structureswindows using multiple colors.

Prerequisites

DFTVisualizer is invoked, the Debug, Design, or Test Structures window is active, and at leastone object is displayed in the active window. For more information, see “Adding Instances to aDisplay Window” on page 260.

Procedure

1. Select the objects you want to mark.

2. Press and hold down the Ctrl key; press M. A colored rectangle shows the active markcolor in the upper left-hand corner of the window. Repeatedly press M until the



November 2010

rectangle shows the color you want to mark the selected objects with or shows gray toUnmark; release the Ctrl key.

NoteYou can also mark objects by selecting Display > Marking (Ctrl + M) from thepulldown menu or Marking (Ctrl + M) from the popup (RMB) menu.

3. Click the cursor in the active window to deselect the selected objects and display theobjects as marked.

Tip: You can select Display > Zoom > Marked to reposition the schematic view to showmarked objects.

Copying Instances Between WindowsYou can copy instances between certain windows as listed in the following table. This can savetime when instances display in one window and the data you want to view for the instancerequires a different window.

Table 3-1. Windows Between Which You Can Copy Instances

Source Window Destination Windows

Debug Window Data/Wave, Design, Hierarchy Browser, LibraryBrowser, Text Editor (Definition), and Text Editor(Instantiation)

Design Window Data/Wave, Debug, Text Editor (Definition), and TextEditor (Instantiation)

Browser, Hierarchy tab, see“Using the Hierarchy Browser”

Data/Wave, Debug, Design, Library Browser, TextEditor (Definition), and Text Editor (Instantiation)

Browser, Library tab, see“Using the Library Browser”

Data/Wave, Debug, Design, Hierarchy Browser, TextEditor (Definition), and Text Editor (Instantiation)

Browser, Clock tab, see“Using the Clock Browser”

Data/Wave, Debug, Design, Text Editor (Instantiation)

Signals Window Data/Wave, Debug, and Design

Data Window Debug, Design, Text Editor (Definition), and Text Editor(Instantiation)

Wave Window Debug, Design, Text Editor (Definition), and Text Editor(Instantiation)

Global Search Window Data/Wave, Debug, Design, Hierarchy Browser, LibraryBrowser, Text Editor (Definition), and Text Editor(Instantiation)



Use one of the following methods to copy an instance from one window (source) to anotherwindow (destination).

Prerequisite

Instances you wish to copy must display in the source window.

Method 1 - Drag-and-Drop

1. Move the cursor over an instance in the source window. To copy multiple instances atonce, select them in the source window, then move the cursor over one of the selectedinstances.

2. While simultaneously pressing the Control key and left mouse button, move the cursorinto the display area of the destination window. The cursor in the destination windownow includes a small box and plus (+) sign.

3. Release the left mouse button in the display area of the destination window to drop theinstances.

Method 2 - Right Mouse Menu

1. Move the cursor over an instance in the source window.

2. Press the right mouse button and use the View In option on the popup menu to specifythe desired destination window.

Tip: To copy multiple instances, first select them, then move the cursor over one of theselected instances and press the right mouse button to access the popup menu.

Method 3 - Main Menu

1. Select one or more instances in the source window, then choose the Edit > Copy menuitem.

2. To paste the selection into the destination window.

a. Click on the window header bar of the target window and choose the Edit > Pastemenu item, or

b. Press the right mouse button in the destination window and select the Add optionfrom the popup menu. The Make Additions to the Display dialog box displays.

c. Move the cursor over the entry box, press the right mouse button, and select Paste.

d. Click the Add button and OK the dialog box.



November 2010

Related Topics

Adding Instances to a Display Window

Tracing Signal Paths on a SchematicYou can often learn more about a circuit’s behavior by displaying instances along a specificsignal path (tracing).

Once one or more instances are visible in the Debug or Design window, you can trace from theinstances. As shown in Figure 3-2, a diamond symbol on a pin or net indicates circuitry isconnected there, is not yet displayed, and so can be traced. Table 3-2 summarizes the availabletrace options.

Figure 3-2. Trace Symbols

When tracing, be aware of the following:

• In the Debug window, buffers and certain inverters are not displayed by default in orderto reduce screen clutter. See Compacting Buffers and Inverters in Traced Circuitry formore information.

• In the Debug window, you can include annotated data. This is controlled by the Set GateReport command. See Annotating Schematic Data in the Debug Window for moreinformation.

• Instances added by the most recent trace are highlighted. You can control the highlightcolor using the Colors tab of the Preferences dialog box available from the Edit >Preferences menu.

To trace forward or backward, use one of the following methods.

Prerequisites

One or more instances must be visible in the Debug or Design window. To add instances to awindow, see “Adding Instances to a Display Window” on page 260.



Method 1

Move the cursor over the diamond on a pin and click the left mouse button.

Method 2

1. Move the cursor over a pin (between the diamond and the instance) and click the leftmouse button to select the pin. To select more than one pin, press the Shift key whilesimultaneously selecting the pins.

For a single pin, move the cursor over the pin (anywhere, including the diamond) andpress the right mouse button: this selects the pin and opens a popup menu.

2. Use the Trace menu or the popup menu to choose a trace option and initiate the trace.The trace will occur simultaneously from each selected pin.

Tip: When you open the popup menu for a single output pin (not instance), the totalnumber of fanouts is in parentheses at the end of the “Trace Forward Fanout” choice.

Method 3

1. Move the cursor over an instance and click the left mouse button to select it. To selectmore than one instance, press the Shift key while simultaneously selecting the instances.

2. Use the Trace menu or the right mouse popup menu to select a trace option and initiatethe trace. The trace will occur simultaneously from all applicable input or output pins onthe selected instances.

Related Topics

Tracing Signal Paths in the Design Window

Understanding Trace Options

Understanding Trace OptionsTable 3-2 summarizes the trace options available in the Debug window (or within the samehierarchical level in the Design window). When you click the diamond on a pin, rather thanusing the right mouse popup menu, you get the default trace behavior. You can change theforward trace default in the Preferences dialog box.

Table 3-2. Trace Options

Option Selected Trace Behavior

Backward (default) Pin Trace backward one instance.

Instance Trace backward one instance from each input pin.



November 2010

Compacting Buffers and Inverters in Traced CircuitryBy default, compaction of buffers and inverters is on. When compaction is on the following istrue.

• Buffers are not shown. When you trace from an instance connected to a buffer, you willtrace to the next non-buffer instance.

• An even number of inverters is compacted to zero inverters. An odd number of invertersis compacted to a single inverter. When you trace from one instance connected to aninverter, you will trace to the next non-inverter instance.

You can turn off compaction in the Schematics Preferences Dialog Box available from the Edit> Preferences menu.

Backward Endpoint Pin Trace backward to endpoints, showing all circuitry inbetween.1

Instance Trace from each input pin backward to endpoints andshow all circuitry in between.1

Forward One (default) Pin Trace forward one instance.

Instance Trace forward one instance from each output pin.

Forward Fanout Pin Trace forward one instance on each fanout.

Instance Trace forward from each output pin one instance oneach fanout.

Forward Endpoint Pin Trace forward to endpoints, showing all circuitry inbetween.1

Instance Trace from each output pin forward to endpoints andshow all circuitry in between.1

Trace BackwardValue

Pin Traces the value on a selected pin back to its source.The trace continues back from the selected pin untileither the origin cannot be distinguished due to acomplex path, or the origin is found.

1. An endpoint is defined as a primary input, primary output, scan cell, tie gate, or black box. RAMsand ROMs are also endpoints.

Table 3-2. Trace Options

Option Selected Trace Behavior



NoteThe maximum number of gates that can be inserted before requiring a conformationincludes the inverter buffer count. If you are displaying a large portion of circuitry with alot of compaction, you might see the warning that the threshold has been exceeded eventhough what ends up being displayed is less than the maximum number of gates.

Tracing a Specific Signal Value to the SourceUse this procedure to automatically trace a value on a selected pin to its source.

Prerequisites

• One or more instances is visible in the Debug window. See “Adding Instances to aDisplay Window” on page 260.

• Pin data is displayed. If necessary, select an option from the Data menu to display pindata.

Procedure

1. Right click on the pin displaying the value you want to trace. A popup menu displays.

2. Select Trace Backward Value. A pop menu displays all the values on the pin. The left-most value on the pin displays at the top of the menu.

3. Select a value to trace. The value is automatically traced back from the selected pineither until a point is reached where the origin cannot be distinguished due to a complexpath, or the origin is found.

Tracing Signal Paths in the Design WindowThe design window allows you to view and trace through the hierarchy in a multi-level designas follows:

• Add the top level instance (/) by using any of the methods described in Adding Instancesto a Display Window.

• When you add an instance, it is shown with all pins. Hierarchical modules added as aresult of tracing, however, are shown with only the pins that are connected to otherdisplayed instances. This allows you to trace up and down the hierarchy, displaying onlypins from or through which you are tracing.

To show all pins, move the cursor onto the instance, then press the right mouse buttonand choose Show Hidden (#) Pins from the popup menu. (The number in parentheses isthe number of pins that are currently hidden.)



November 2010

To hide pins for which there are no connections currently displayed, choose HideUnconnected Pins from the popup menu.

• Double-click on a hierarchical instance to display all instances inside it. The number ofinstances inside is shown in parentheses next to the name of the submodule.

To hide all instances currently displayed inside a hierarchical instance, select it, thenpress the right mouse button and choose Collapse from the popup menu.

• To clean up the schematic, select an instance and choose the Remove Other Instancesitem from the right mouse button menu. Everything is deleted except the selectedinstance. If the selected instance is a submodule displaying instances inside it, they arekept.

Tracing Up and Down the Design HierarchyTo trace up or down the design hierarchy, use one of the following methods.

Prerequisites

One or more instances must be visible in the design window.

If you need to add an instance, see “Adding Instances to a Display Window” on page 260.

Method 1

Select a hierarchical instance or a pin on a hierarchical instance, then use the Trace DownFanout or Trace Up option from the right mouse popup menu.

Method 2

You can also trace down by double-clicking a hierarchical pin or hierarchical instance.

Method 3

Select a hierarchical instance, then use the Trace Down Fanout or Trace Up One option fromthe right mouse popup menu.



Examples

Figure 3-3. Tracing Down One Hierarchical Level from a Selected Pin

Figure 3-4. Tracing Up One Hierarchical Level from a Selected Pin



November 2010

Bundling NetsIn some cases, you may not want to see all the nets that are connected between instances. Forinstances at higher levels of the hierarchy, where you typically have fewer instances with a largenumber of pins, you may be more interested in seeing between which blocks there areconnections, than in seeing all the connections themselves.

To gather signals between instances into bundles represented by single thick lines, select theDisplay > Net Bundle > On menu item.

Example

Figure 3-5. Design Window Display with Net Bundling Off



Figure 3-6. Same Display with Net Bundling On

Annotating Schematic Data in the Debug WindowData is automatically annotated to the schematic in the debug window based on the currentsetting of the Set Gate Report command, which also controls the Report Gates data output. Mostof the Set Gate Report options are available through the Data menu and the most commonlyused ones have buttons on the tool bar. The Data menu and tool bar are context sensitive:options shown might change depending on the availability of the associated data or procedure.

To clean up the schematic, select an instance and choose the Remove Other Instances itemfrom the right mouse button menu. Everything is deleted except the selected instance. If theselected instance is a submodule displaying instances inside it, they are kept.

For more information, refer to the Set Gate Report command for your tool as listed in thefollowing table.

Table 3-3. Set Gate Report Command Reference List

Tool Reference

DFTAdvisor Set Gate Report / DFTAdvisor Reference Manual

Tessent FastScan,FlexTest,Tessent TestKompress, andTessent Diagnosis

Set Gate Report / ATPG and Failure Diagnosis ToolsReference Manual


Getting Started with DFTVisualizerAnalyzing a DRC Violation

November 2010

NoteSome commands, such as Analyze Drc Violation will automatically issue a Set GateReport command, so you do not have to manually enter the command or use the Datamenu.

Displaying Multiple Data SetsThe Data window provides simultaneous access to the several types of information controlledby the Set Gate Report command. This is in contrast to the debug window and the commandline, where you can report only the data corresponding to the current setting of the Set GateReport command.

For example, you can display simulation data for the load_unload and shift procedures for aparticular pattern. The options are available through the Data menu and the buttons on the toolbar.

Analyzing a DRC ViolationYou can use the Analyze Drc Violation command from DFTVisualizer to report additionalinformation on any of the following DRCs:

A1-A16C1-C17D1-D12E2-E11, E14F rulesS1-S4T2-T6, T12, T16, T17,T24-26W20-W31, W34-W38

LBISTArchitect(BIST-Ready phase)

Set Gate Report / BIST-Ready Command Dictionary in theLBISTArchitect Reference Manual

LBISTArchitect(Fault Simulation phase)

Set Gate Report / Fault Simulation Command Dictionary inthe LBISTArchitect Reference Manual

Table 3-3. Set Gate Report Command Reference List

Tool Reference



NoteThe following DRC rules do not have additional information that can be displayed withDFTVisualizer:

B1-B16E1, E12, E13G rulesK rulesP rulesT1, T8-T11, T13-T15, T18-T23W1- W19, W32, W33

For more information on specific DRC rules, see “Design Rule Checking.”

Step 1 - Run an Analysis of the ViolationBuilt into the tools (except for Tessent Diagnosis) is the capability to analyze DRC violations.At the end of the analysis, a schematic of the circuitry and/or instance associated with theviolation displays in the Debug window. Data from the analysis, consistent with what theReport Gates command would report for the displayed gates, is annotated on the schematic.

Running the AnalysisUse this procedure to analyze a particular DRC violation.

Prerequisites

• The identification (rule_id) and specific occurrence number (occurrence#) of the DRCviolation.

The rule_id is provided in parentheses at the end of each DRC violation summarymessage in the tool’s session transcript. To get occurrence#s, enter a Report Drc Rulescommand with a rule_id argument. This displays each occurrence associated with thatrule_id rule. Each occurrence includes its rule_id-occurrence# in parentheses.

• DFTVisualizer is open.

Procedure

1. Select Tools > Analyze DRC. The Select a Violation ID dialog box displays.

2. Select a rule ID from the Failed DRCs list that you want to debug. All violationoccurrences for that rule ID are displayed.

3. Double-click on any of the occurrence#s of the DRC in the Specific IDs list to startanalyzing them in the Debug window. Alternatively, you can select the specificviolation occurrence and click Analyze or Analyze & Close to see the analysis of the



November 2010

violation. Be aware that you can also issue the Analyze Drc Violation command with therule_id-occurrence# argument at the DFT tool’s command line. For example:


Tip: With either of these DRC analysis methods, the DRC ID is highlighted as a pinkhyperlink in the Transcript window. However, if the DRC is a P (Procedure) or W(Timing) violation, clicking the DRC-ID-occurrence# opens the test procedure file in theDFTVisualizer Text Editor window and highlights the line generating the DRC violation.

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.

Example

The following graphic shows the DFTVisualizer display resulting from analysis of a C3violation:

Figure 3-7. DFTVisualizer Display Example

For some violations, the data annotated to the initial display will be enough for you to determinethe exact cause of the violation. In the preceding display, the clock cone data (Cs and Es) showthat under certain timing conditions (if captured data propagates through the .../reg_pstate_2_flip-flop to its Q output in less than half a clock cycle for example), data will pass through bothmemory elements in a single clock cycle.



Related Topics

Step 2 - Find the Source of Problem SignalsIf the cause of a DRC violation is not immediately apparent from reviewing the schematic in thepreceding step, there are several things you can do to improve your understanding of theviolation. These are primarily techniques for tracing the source of problem signals and arediscussed in the following topics under “Performing Basic Tasks” on page 258:

• Tracing Signal Paths on a Schematic

• Tracing Signal Paths in the Design Window

• Displaying Multiple Data Sets

Example

The following example shows one way to utilize DFTVisualizer to trace the source of a badsignal value that produced a T3 DRC violation.

A DRC error is reported in the tool’s session transcript:

...// Error: Scan chain chain1 blocked at gate/bsr_i1/bsc_edt_channels_out1/ix33 (972) after tracing 0 cells. (T3-1)// Error: Rules checking unsuccessful, cannot exit SETUP mode.// ’DOFile fs.do’ aborted at line 19

Run an analysis of the violation:

SETUP> analyze drc violation t3-1// command: open visualizer -display debug// Note: Gate report now set to trace.

C3



November 2010

Figure 3-8. Initial DRC Analysis Display

Because a trace error was generated (T3-1), the Analyze DRC Violation commandautomatically sets gate reporting to Trace. The trace report will show the identified scan pathnodes as 'S'.

Determine the source of the problem signal value:

• The Ss on the connection between the multiplexer (mux) and the primary output pinedt_channels_out1 indicate the scan path can successfully trace back to the mux.

• The Xs on the Select line of the mux result in Ss on the mux output regardless of the factthat the mux input is ambiguous.



Determine the cause of the Xs on the mux Select line, by selecting the Select line andperforming a backward trace. To maintain a netlist perspective, perform the trace in the Designwindow.

Figure 3-9. Copying the Instance to the Design Window

Figure 3-10. Instance Copied to the Design Window

As you pass each hierarchical boundary, by default, the tool hides any pins that are not in thetraced path.



November 2010

Figure 3-11. Tracing Back Using the Design Window

You can select a hierarchical instance and press the right mouse button to view how many pinsare hidden and to access an option for displaying the hidden pins.

Figure 3-12. Viewing Hidden Pins

When the trace reaches a memory element, check its simulation values by selecting it andviewing it in the Debug window. Note, the Xs on NOR gate .../ix124. As expected, there are Xson the output. We will trace the A0 pin of this instance.



Figure 3-13. Finding Xs on the Reset Input of a Memory Element on Trace Path

The Xs on either the clock (CLK) or reset (R) input of instance .../reg_pinst_0_ would cause Xson the output. Continue the backward trace from the reset input of the memory element.

Figure 3-14. Completing the Trace to a PI and Reconfirming It is X Source

Because the trst primary input is sourcing Xs, select the PI instance and add it to the Datawindow (right mouse button View In > Data/Wave). From the Data window, you can use the



November 2010

Data pulldown menu to look at simulation values during different test procedures. The Datawindow reveals that the trst pin is not initialized during the test_setup cycle.

Figure 3-15. Viewing Additional Simulation Data for the PI

Step 3 - Apply a Remedy and Rerun DRCOnce you have determined the reason for the DRC, you can make appropriate changes in yourtest procedure file, tool setups, or design to correct it.

Example

To remedy the erroneous signal of the preceding example, a force statement is added to thetest_setup procedure to initialize the trst pin. DRC is then rerun to confirm the fix:

procedure test_setup =timeplate bsda_timp1;cycle =...

force tck 0;force tdi 0;force tms 1;

end;

procedure test_setup =timeplate bsda_timp1;cycle =...

force tck 0;force tdi 0;

pulse tclk;

end;

force tms 1;

end;pulse tclk;

end;

force trst 0;

Before After

Getting Started with DFTVisualizerAssessing Test Coverage in the Browser


Assessing Test Coverage in the BrowserThe Browser Window allows you to display test coverage, fault, and DRC statistics forhierarchical design blocks using the Hierarchy, Library, and Clocks tabs.

Use this procedure to display test coverage statistics. (The steps are similar for fault and DRCstatistics.)

Prerequisites

An ATPG process is completed and DFTVisualizer is invoked. For more information, see the“Opening DFTVisualizer” section in this chapter and “The ATPG Process” in the Scan andATPG Process Guide.

Procedure

1. Choose the Windows > Browser menu item in DFTVisualizer. The Browser windowopens and displays the top level design instance in the Hierarchy tab as shown inFigure 3-16.

2. Optionally, select another Browser tab to use by selecting either the Library or theClocks tab.

3. Choose Data > Coverage Data > Test Coverage or click tc on the menubar. A testcoverage column containing statistics for the displayed instance is added to the activeBrowser tab.

4. Click the plus sign (+) next to the instance. library model, or clock name to expand thedesign hierarchy. You can see the blocks at the next level of hierarchy and the testcoverage for each as shown in Figure 3-17.

Tip: When showing high level statistics, it can be useful to just focus on the submodules(blue boxes). To do that, choose Display > Group Instances > On. This will group allgates (gray boxes) by themselves in a separate block marked $$Gates$$.

5. Repeat the preceding step for the additional blocks, looking for blocks with relativelylow test coverage.


Getting Started with DFTVisualizerAssessing Test Coverage in the Browser

November 2010

Example

Figure 3-16. Browser Default Display Showing the Top-level Design

Figure 3-17. Browser Showing a Block with Low Test Coverage

Getting Started with DFTVisualizerPerforming Clock Domain Analysis in the Browser


Performing Clock Domain Analysis in theBrowser

The Browser Window allows you to display test coverage, fault, and DRC statistics forhierarchical design blocks using the Hierarchy, Library, and Clocks tabs. Use this procedureto analyze the impact of individual clocks on total test coverage and fault statistics.

Prerequisites

An ATPG process is completed and DFTVisualizer is invoked. For more information, see the“Opening DFTVisualizer” section in this chapter and “The ATPG Process” in the Scan andATPG Process Guide.

Procedure

1. Choose the Windows > Browser menu item in DFTVisualizer. The Browser windowopens and displays the top level design instance in the Hierarchy tab.

2. Click the Clocks tab. The window displays a list of the clocks in the design indescending order of test coverage as shown in Figure 3-18. That is, the clock with thehighest percent of test coverage is listed at the top of the list and the clock with the leastcoverage is listed at the bottom of the list. By default, the window displays threecolumns of data for each clock:

o Clock attributes such as off state, constraints, and internal/external clock.

o Total faults in each clock domain and the percentage of all faults in the design.

NoteIf a fault is in multiple clock domains, the fault is attributed to each clock domain.Because of this, it is possible that the sum of all fault percentages (faults in a clockdomain as a percent of the total faults in the design) can exceed 100%.

o Test coverage.

3. Choose Data > Faults and select any additional faults you want to display from themenu. Columns containing the faults you specified are added to the active Browser tabas shown in Figure 3-19.

4. Choose Data > Coverage Data and select the additional statistics you want to displayfrom the menu. Columns containing the statistics you specified are added to the activeBrowser tab.

5. Click the plus sign (+) next to a clock name to expand the clock and see the individualinstances within that clock’s domain. You can see the instances at the next level ofhierarchy and the test coverage and additional statistics for each as shown inFigure 3-19. Only instances with faults in the expanded clock domain are displayed.


Getting Started with DFTVisualizerAnalyzing a Fault and Displaying its Location

November 2010

Example

Figure 3-18. Browser Display Showing the Clock Tab

Figure 3-19. Browser with Expanded Clock Domains

Analyzing a Fault and Displaying its LocationThe Analyze Fault command, which is supported by Tessent FastScan, FlexTest,LBISTArchitect and Tessent TestKompress, allows you to identify why a fault is not detected.You can execute this command, as well as several related reporting commands from theDFTVisualizer Fault Analysis dialog box. You also can add the instance where the fault islocated to the Debug window automatically, as part of the analysis.

Getting Started with DFTVisualizerAnalyzing a Fault and Displaying its Location


Prerequisites

You must have added faults to the current fault list and identified the instance where the pinwhose faults you want to analyze is located.

Procedure

1. Choose Tools > Analyze Faults from the DFTVisualizer main menu. The Debugwindow opens if not already open, along with the DFTVisualizer Fault Analysis dialogbox.

2. In the Faults & Statistics Options field, enter an instance pathname in the SpecificInstance entry box using one of the following methods:

• Select the instance in another window such as the Browser; the instance pathnamewill automatically appear in the entry box.

Tip: You can also select an instance in another window before you open the dialog boxand it will automatically appear in the entry box.

• Copy and paste the pathname from somewhere else (session transcript for example,or the right mouse button pathname selection in another window).

• Alternatively, select the Entire Design option if you want to report on all the faults inthe design.

3. In the Report Faults Options field, select an option for the Fault Type and choose theFault Class using the dropdown list. If you want to display the fault class for equivalentfaults, select that checkbox as well.

4. Click the Report Faults button to list faults of the selected type and class; the list appearsin the display area of the Reported Data field.

For convenience, there are also buttons for running the Report Statistics and ReportSequential Fault_depth commands.

5. In the Reported Data field, click the pin pathname of a fault you want to analyze. Thepathname appears in the Fault entry box at the bottom left side of the Reported Datafield.

6. Select a Stuck-at option, then click one of the Analyze buttons. The resulting analysisappears in the tool’s session transcript and is equivalent to the Analyze Fault command.If you chose the graphical analysis, the instance the pin is on is added to the Debugwindow automatically.


Getting Started with DFTVisualizerExecuting Report Test Stimulus

November 2010

Executing Report Test StimulusYou can use the Report Test Stimulus command to create “what if” scenarios when debuggingtest coverage and other issues in Tessent FastScan, FlexTest and Tessent TestKompress. Thiscommand attempts to generate a pattern that sets one or more pins to the value(s) you specify.You can execute this command graphically in the Debug Window using the followingprocedure.

Prerequisites

The instance(s) with the pins for which you want to specify values must be displayed in theDebug window.

Procedure

1. In the Debug window, select one or more pins as described in “Selecting Objects” onpage 261.

Tip: If you want to specify values for multiple pins on an instance, selecting the instanceis a fast way to automatically select all its pins; you can then get DFTVisualizer to ignoreunwanted pins in step 3 below.

2. From the right mouse button menu, choose Commands > Set Value. The Set Valuedialog box appears, with a Pin Name field for each selected pin filled in with the nameof the pin.

3. In the dialog box, select a value for each pin using the Pin Value dropdown lists. Leavethe Pin Value unspecified for any pins you want the tool to ignore.

4. Click OK. The schematic will then show the simulated values propagating the results tothe selected pins.

If the test generation is not successful, a message in the session transcript will indicate why. Ifthe test generation is successful, the session transcript reports the stimulus necessary to producethe pin values you specified.

Getting Started with DFTVisualizerGetting Oriented in a Large Design


Getting Oriented in a Large DesignSometimes you do not have a specific problem to debug but want to get a better idea of how thedesign is put together and what the main components are. A good way to do this is by looking athow instances displayed in the Hierarchy tab of the Browser window are interconnected in thehierarchical schematic displayed in the Design window.

Follow this procedure to begin getting oriented in a large design.

Prerequisites

DFTVisualizer is invoked. For more information, see the “Opening DFTVisualizer” section inthis chapter.

Procedure

1. Open the Browser Window from the Windows menu.

2. Choose View In > Design from the right mouse popup menu. The top level instance isdisplayed (and selected) in the Design Window.

3. In the Design window, choose Trace Down Fanout from the right mouse popup menu.

4. Click the Zoom All button on the tool bar.

5. You can now see the major design blocks one hierarchy below the design’s top level,along with their interconnecting nets.

6. Click and hold the right mouse button on objects of interest in the display to see theobject’s name.

To bundle nets connected between the same instances, choose the Display > NetBundle > On menu item. See “Bundling Nets” on page 272 for an example.

7. Trace down any of the displayed instances by clicking and holding the right mousebutton with the cursor on the instance, and using the controls described in the precedingsteps to maintain readability.

8. Open the menu on pins and try some of the other trace options to explore design detailsof interest.


Getting Started with DFTVisualizerGetting Oriented in a Large Design

November 2010

Example

Figure 3-20. Adding the Top Level Instance to the Design Window

Figure 3-21. Tracing Down Fanout to See the Major Design Blocks

Getting Started with DFTVisualizerSetting DFTVisualizer Preferences


Setting DFTVisualizer PreferencesUse this procedure to customize the DFTVisualizer session as follows:

• Specify colors for display components.

• Add/Remove toolbar components.

• Control text/data display.

• Specify editing behavior.

You can also save your preferences for use in subsequent sessions or to a special file that can beloaded after DFTVisualizer is invoked.

Prerequisites

• DFTVisualizer is invoked. For more information, see the “Opening DFTVisualizer”section in this chapter.

Procedure

1. Select Edit > Preferences. The Global Preferences Dialog Box displays. Specify thedesired global session attributes.

2. Click the Colors tab. The Colors Preferences Dialog Box displays. Specify the desiredobject colors.

3. Click the Schematics window tab. The Schematics Preferences Dialog Box displays.Specify the desired attributes for the Debug window, the Design window, or both.

4. Click the Browser Window tab. The Browser Window Preferences Dialog Box displays.Specify the desired attributes for the Browser window.

5. Click the Data Window tab. The Data Window Preferences Dialog Box displays.Specify the desired attributes for the Data window.

6. Click the Text Editor window tab. The Text Editor Window Preferences Dialog Boxdisplays. Specify the desired attributes for the Text Editor window.

7. When you have set the desired preferences, click OK.

The specified settings take effect and remain persistent for the current DFT tool session only.

Related Topics

Saving/Loading Session Preferences


Getting Started with DFTVisualizerSetting DFTVisualizer Preferences

November 2010

Saving/Loading Session PreferencesUse this procedure to save specified DFTVisualizer preferences as the default settings used byall subsequent DFT tool sessions or to a specified file that can be loaded by other users or asalternate set of preferences. You can also use this procedure to set your preferences back to thesystem defaults.

Prerequisites

• New session preferences are selected. See Setting DFTVisualizer Preferences.

Procedure

1. Select Edit > Preferences. The Global Preferences Dialog Box displays.

2. Click Write Preferences to save the current settings as default. This option writes a filenamed .DftVisualizerrc to your home directory. This file is used by subsequentinvocations of the tool to set default preferences for the session.

or

Click Save Preference File to save the current settings to a specified file in the currentworking directory and Click OK. Once the file is saved, you can use the associated LoadPreference File option to browse to and load it from any session.

or

Click Reset to System Defaults to change all preferences back to the systems defaults.

Related Topics

Setting DFTVisualizer Preferences

Understanding the DFTVisualizer Preferences Dialog BoxThis section describes each tab, left to right, of the DFTVisualizer Preferences dialog box. Thefollowing topics are available:

Global Preferences Dialog BoxColors Preferences Dialog BoxSchematics Preferences Dialog BoxBrowser Window Preferences Dialog BoxData Window Preferences Dialog BoxText Editor Window Preferences Dialog Box

Getting Started with DFTVisualizerGlobal Preferences Dialog Box


Global Preferences Dialog BoxThe DFTVisualizer Preferences (Global tab) dialog box allows you to set preferences associatedwith all display windows.

Accessing this Dialog Box

From DFTVisualizer, select Edit > Preferences and click the Global tab.

Figure 3-22. Global Preferences Dialog Box


Getting Started with DFTVisualizerGlobal Preferences Dialog Box

November 2010

Dialog Box Options

Table 3-4. Global Preferences

Option Description

Save Current WindowPositioning (after writingpreferences)

Determines if window size and location are saved on exit andused for the next DFTVisualizer session.

Word Wrap Transcript Text Determines if words wrap to the next line approximately every70 characters.

Automatically Cross SelectIn All Windows

Determines if objects you select are automatically cross selectedin all windows in which they are already displayed. See “Cross-Selecting Objects” on page 261 for more information.

Toolbar Options Specifies which tool icons are available from the toolbar on thetop of the display.

Show Full Names Displays complete hierarchical pathname for each instance whenthe instance is clicked with the right mouse button. Defaultsetting.

Show Partial Names ByOnly Showing The(Levels):

Specifies how many design levels display as part of instancenames. You can specify how many of the first or last designlevels are omitted. By default, full names display.

Show Partial Names ByOnly Showing The(Characters):

Specifies how many characters display in instance names whenthe instance is clicked with the right mouse button. By default,full names display.

Zoom Factor Specifies by what percentage a window magnifies when thezoom option is used.

Load Preference File Loads settings from a specified preference file into the currentsession.

Save Preference File Saves the current preference settings to a specified file.

Write Preferences Saves the current preference settings to a file named.DftVisualizerrc in your home directory. Preferences forsubsequent tool sessions are read from this file by default.

Reset to System Defaults Resets all preference settings to the factory default settings.

Getting Started with DFTVisualizerColors Preferences Dialog Box


Colors Preferences Dialog BoxThe DFTVisualizer Preferences (Colors tab) dialog box allows you to set color preferences forbackgrounds and graphical objects displayed in windows.


From DFTVisualizer, select Edit > Preferences and click the Colors tab.

Figure 3-23. Colors Preference Dialog Box


Getting Started with DFTVisualizerColors Preferences Dialog Box

November 2010

Dialog Box Options

Table 3-5. Color Preferences

Option Description

Windows List Determines the window to which the Options List applies.

Options List Displays a list of graphical window elements that you can selectand specify a color for.

Color Palette Palette that indicates the current color selection for the objecttype selected in the Windows List and Options List.

No. of Colors Specifies the number of colors that can be used to mark objectsin schematic windows (Debug and Design). This item is onlyavailable when Marked is selected in the Options List.

Color Index Specifies a color to be used when marking objects. You can setas many colors as are specified by the No. of Colors field. Bydefault, the following colors are used for marking:• Mark color 1: Green• Mark color 2: Blue• Mark color 3: Orange• Mark color 4: Yellow• Mark color 5: Red

This item is only available when Marked is selected in theOptions List. For more information, see “Customizing MarkingColors in the Debug, Design, and Test Structures Windows” and“Marking and Unmarking Objects in the Debug, Design, andTest Structures Windows.”

Copy Colors To AllWindows

Applies the colors currently defined for the selected window toall other windows.

Reset Colors To SystemDefaults

Resets the color preferences for the currently selected window tosystem defaults.

Getting Started with DFTVisualizerSchematics Preferences Dialog Box


Schematics Preferences Dialog BoxThe DFTVisualizer Preferences (Schematics tab) dialog box allows you to set preferencesassociated with the Debug and Design windows.


From DFTVisualizer, select Edit > Preferences and click the Schematics tab.

Figure 3-24. Schematics Window Preferences Dialog Box



November 2010

Dialog Box Options

Table 3-6. Debug Window Preferences

Option Description

Windows Indicates whether the changes specified in the dialog box will beapplied to the Debug window, Design window, or to both Debugand Design windows.

Compact Inverters AndBuffers

Determines whether buffers and inverters are compacted and/ordisplayed. When enabled, redundant buffers and inverters arecompacted and omitted from the display and the next non-buffer/non-inverter instance displays.

Require ConfirmationBefore Doing “Delete All”

Prompts for confirmation before a Delete All command isexecuted.

Display Ports In SameOrder As Report Gate

Connects and displays ports exactly as specified in the designnetlist. By default, port connections are flipped/manipulatedwhen possible to reduce clutter and optimize viewing.

“Highlight” Gates AddedDuring Tracing

Determines whether gates added in trace mode displayhighlighted.

Maximum Number OfGates That Can Be InsertedBefore Requiring AConfirmation

Specifies the maximum number of gates that can added beforeprompting for confirmation. Default is 500.

Number Of Undo/RedoLevels To Keep

Specifies how many levels of Undo/Redo can be recalled frommemory. Default is 20.

Forward Trace All PinFanouts

Displays all levels of pin fanouts when a fanout marker isclicked.

Forward Trace One PinFanout

Displays one level of pin fanout when a fanout marker is clicked.

Automatic Net Connection Determines how many nets display during tracing. You canchoose to display only explicitly traced nets, a set number of nets,or all nets.

Show Instance Names Determines whether instance names are displayed for eachinstance.

Show Full Names Displays complete hierarchical pathname for each instance whenthe instance is clicked with the right mouse button. Defaultsetting.

Show Partial Names ByOnly Showing The:(Characters)

Specifies how many characters display in instance names whenthe instance is clicked with the right mouse button. By default,full names display.



Show Partial Names ByOnly Showing The:(Levels)

Specifies how many design levels display as part of instancenames. You can specify how many of the first or last designlevels are omitted. By default, full names display.

Split Schematic IntoMultiple Pages

Determines whether the schematic is split into pages that displayone at a time or displayed in its entirety. By default, theschematic displays in its entirety.

Display Pins When AddingHierarchical SubmodulesTo The Schematic

Determines whether pins display when hierarchical submodulesare added to the schematic.

Display Net Names On TheSchematic

Determines whether net names display on the schematic.

Table 3-6. Debug Window Preferences

Option Description


Getting Started with DFTVisualizerBrowser Window Preferences Dialog Box

November 2010

Browser Window Preferences Dialog BoxThe DFTVisualizer Preferences (Browser Window tab) dialog box allows you to set preferencesassociated with the Browser Window.


From DFTVisualizer, select Edit > Preferences and click the Browser Window tab.

Figure 3-25. Browser Window Preferences Dialog Box

Getting Started with DFTVisualizerBrowser Window Preferences Dialog Box


Dialog Box Options

Table 3-7. Browser Window Preferences

Option Description

Show Primitives Determines if primitives can be displayed.

Show Hierarchical Data ForLibrary Models

Determines if the Library tab of the Browser windowdisplays the hierarchical names of instances.

Color The Cell When The RightMouse Button Is Pressed

Determines whether the part of the selection indicator in adata column cell displays highlighted when selected with aright mouse button press.

Display Coverage Data Determines whether test/fault coverage data displays as a bargraph (graphically) or as text number.

Show Coverage Data abovenn % in Green

Determines the display color for the test/fault coverage data.Values above the specified percentage display green, andvalues equal to or below the specified percentage display inred.

Display Faults/DRC Data Determines whether fault/drc data displays as a bar graph(graphically) and a text number or text number only.

Align Instance Names Determines whether the instance names display left or rightjustified.

Align Data Determines whether data associated with instance namesdisplay left or right justified in the columns.

Data Column Width Specifies the number of characters visible in the datacolumns. By default 50 characters display.


Getting Started with DFTVisualizerData Window Preferences Dialog Box

November 2010

Data Window Preferences Dialog BoxThe DFTVisualizer Preferences (Data Window tab) dialog box allows you to set preferencesassociated with the Data window.


From DFTVisualizer, select Edit > Preferences and click the Data Window tab.

Figure 3-26. Data Window Preferences Dialog Box

Getting Started with DFTVisualizerData Window Preferences Dialog Box


Dialog Box Options

Table 3-8. Data Window Preferences

Option Description

Align Names Determines whether the names display left or right justified.

Align Data Determines whether data associated with names display left orright justified in their columns.

Data Column Width Specifies the number of characters visible in the data columns. Bydefault 50 characters display.


Getting Started with DFTVisualizerText Editor Window Preferences Dialog Box

November 2010

Text Editor Window Preferences Dialog BoxThe DFTVisualizer Preferences (Text Editor Window tab) dialog box allows you to setpreferences associated with the Text Editor window.


From DFTVisualizer, select Edit > Preferences and click the Text Editor Window tab.

Figure 3-27. Text Editor Window Preferences Dialog Box

Getting Started with DFTVisualizerText Editor Window Preferences Dialog Box


Dialog Box Options

Table 3-9. Text Editor Window Preferences

Option Description

Key Stroke Mode Determines whether key strokes are interpreted to be Vi,Emacs, or Design Pad commands.

Font Size Specifies the font size used to display the contents of thewindow:• Small — 10• Medium — 13• Large — 16• X-Large — 19

Window State Specifies how windows display in the DFTVisualizer mainwindow:• Tabbed — Windows align side by side and are accessed

using a Tab at the bottom of the window. This is thedefault.

• Cascaded — Windows stack with the top portion of eachwindow visible.

Maximum Number of DesignFiles to Open at a Time

Specifies the maximum number of files that will be opened inthe Text Editor window when File > Open > Current DesignFiles is selected.

Write Prefs Saves the current preference settings to a file named.DftVisualizerrc in your home directory. Preferences forsubsequent tool sessions are read from this file by default.


Getting Started with DFTVisualizerObjects Added to DFTVisualizer Windows

November 2010

Objects Added to DFTVisualizer WindowsWhen you add an object to the Debug, Design or Data window, you can refer to the object byeither the hierarchical name (such as the port of a submodule, a net name, etc.) or the flattenedmodel name. The following table shows what will be added when you add a particular type ofobject to these windows.

Table 3-10. What is Added to the Debug, Design and Data Windows

Type of Object Debug Window Design Window Data Window

Library level instance Instance Instance All pins on instance

Pin on libraryinstance

Instance Instance Specified instance pin

Bus on libraryinstance

Instance Instance Specified bus

Primitive (gate ID) Primitive (if gatelevel set to primitive)Design level instancethe primitive is a partof (if gate level set todesign)

Instance the primitiveis a part of

All pins on primitive

Pin on Primitive Primitive (if gatelevel set to primitive)Design level instancethe primitive is a partof (if gate level set todesign)

Instance the primitiveis a part of

Pin on primitive

Hierarchical instance(submodule)

Not supported Hierarchical instance All ports on thehierarchical instance

Port on hierarchicalinstance

Library level instancedriven by the port(like Report Gates)

Hierarchical instance Port on hierarchicalinstance

Bus port onhierarchical instance

Library level instancedriven by allmembers of the bus

Hierarchical instance Bus on hierarchicalinstance

Net (wire) Library level instancedriving the net (likeReport Gates)

Instance driving thenet (hierarchical)

Net

Bus (wire) Library level instancedriving the bus

Instance driving thebus (hierarchical)

Bus

Getting Started with DFTVisualizerTask Manager Window


Task Manager WindowThe Task Manager window provides a graphical interface for displaying and analyzing DRCviolations, viewing the design netlist, viewing fault coverage data, identifying and analyzingfaults, debugging pattern simulation mismatches, viewing diagnosis report files, and accessingthe DFTVisualizer reference documentation.

Accessing this Window

From DFTVisualizer, choose Windows > Task Manager or click the button.

Figure 3-28. Initial Task Manager Window

Figure 3-28 shows the initial state of the Task Manager window. The context in which you areusing DFTVisualizer determines which buttons appear and whether or not they are active.Potentially, the Task Manager window has these task buttons:

• Debug DRC Violation — Analyzes DRC violations, reports the violations to thesession transcript, and graphically displays relevant gates and simulation data.

• View Design Elements — Displays the design hierarchy and schematics in theDFTVisualizer Browser, Design, Signals, and Test Structures (when applicable)windows enabling you to navigate visually through the design.

• View Fault Coverage Data— Displays test coverage, fault classification, and DRCstatistics for hierarchical design blocks.



November 2010

• Analyze Faults — Identifies why a specified fault is not detected.

• Debug Simulation Mismatches — Displays and highlights design, simulation, and testpattern data for the selected simulation mismatch.

• Diagnosis Report — Displays a dialog box that enables you to choose and view adiagnosis report file.

• Help — Provides access to the DFTVisualizer reference documentation.

Using this Window

Click the button in the DFTVisualizer window to toggle on and off the Task Managerwindow. Hovering over a task button highlights the button and displays both a description of thetask and, in the preview area, an example image of the window(s) that will open when you clickthe highlighted button.

Figure 3-29 shows an example of the Task Manager window with one of the task buttonshighlighted.



Figure 3-29. Task Manager Window with View Design Elements TaskHighlighted

The current context determines which task buttons appear and whether they are active.

• To use the Debug DRC Violation button, the tool must have checked the design rulesand reported a violation. See “Analyzing a DRC Violation” and “Design RuleChecking” for more information.

• To use the Analyze Fault button, fault simulation results must be available for thecurrent pattern set. For instructions on specifying input for fault analysis, see“Analyzing a Fault and Displaying its Location” or refer to the Analyze Fault commandin the ATPG and Failure Diagnosis Tools Reference Manual.


Getting Started with DFTVisualizerBrowser Window

November 2010

• To use the Debug Simulation Mismatch button, a mismatch must exist based on toolanalysis and the results of pattern simulation in Questa or a third-party simulator. Forinformation on debugging simulation mismatches, see “Automatically AnalyzingSimulation Mismatches” in the Scan and ATPG Process Guide.

• To use the Diagnosis Report button, you must be running either Tessent Diagnosis orTessent TestKompress.

Browser WindowThe Browser window displays three tabs that provide access to the following windows:

• Hierarchy Browser— Allows you to navigate through the design hierarchy and viewcoverage, fault and DRC statistics. DFTVisualizer displays faults in the HierarchyBrowser based on whether the Set Fault Mode setting specifies to show faults ascollapsed or uncollapsed.

• Library Browser — Displays statistics for the ATPG library models used in a design.DFTVisualizer displays data in the Library Browser based on whether the Set FaultMode setting specifies to show faults as collapsed or uncollapsed. When specified as:

o Collapsed — The tool does not include equivalent faults in the fault lists.

o Uncollapsed — The tool includes equivalent faults in the fault lists. This is thedefault mode upon invocation of the tool.

• Clocks Browser — Displays all of the clocks in the design and their attributes in adescending order of test coverage. Clocks and their attributes are displayed from allmodes. The Clocks Browser allows you to navigate the design hierarchy and view thefaults for each individual clock and analyze the distribution of faults between clockdomains.


From the DFTVisualizer window, choose Windows > Browser. By default, the HierarchyBrowser window is active as shown in Figure 3-30.

Figure 3-30. Browser Tabbed Window



The Browser window uses the following icons to represent different instance types:

Using this Window

• Add additional data columns to the Hierarchy, Library, and Clocks Browsers using theData pulldown menu and/or the buttons on the toolbar as described in Table 3-12. Menuoptions are disabled (greyed-out) if corresponding data is unavailable. In TessentFastScan, for example, fault classes that do not exist in the design are not available.

Table 3-11. Browser Window Instance Type Icons

Symbol Means the Instance is a...

Clock

Submodule (instance of a Verilog module)

Netlist/Verilog primitive

Library level instance

Primitive

Library level instance containing one or moreRAMs/ROMs

Library level instance containing one or more scan cells

Blackboxed instance

Table 3-12. Browser Window Data Menu Choices

Button Data Menu Description

Gates Total number of library level instances,including submodules.

Primitives Total number of primitives, includingsubmodules.

Total Faults Total number of faults, including submodules.

N/A Undetected Faults Total number of undetected faults.

Faults > Add All Number of faults for each available class; adds acolumn for each class.



November 2010

N/A Faults > <type> Number of faults for a specific class. Each classcan be expanded to display columns for each ofits sub-classes. For information on fault sub-classes, see the Set Relevant Coveragecommand in the ATPG and Failure DiagnosisTools Reference Manual.

N/A Testability Data > Add All Total number of circuitry connections that maycause test coverage problems for each availableclass. For more information, see the ReportTestability Data command in the ATPG andFailure Diagnosis Tools Reference Manual.

N/A Testability Data > <type> Total number of circuitry connections that maycause test coverage problems for a specific class.For more information, see the Report TestabilityData command in the ATPG and FailureDiagnosis Tools Reference Manual.

DRC > Add All Number of DRC violations; adds one column foreach violation that exists in the design.

N/A DRC > <type> Number of violation occurrences for a specificDRC rule.

Coverage Data > TestCoverage

Test coverage for each submodule.

Coverage Data > RelevantTest Coverage

Test coverage for each submodule afteruntestable faults have been added/deleted fromtest coverage calculations. For moreinformation, see the Set Relevant Coverage andReport Statistics commands in the ATPG andFailure Diagnosis Tools Reference Manual.

Coverage Data > TestCoverage Loss

Test coverage loss is the undetected faults in aninstance displayed as a percentage of the testablefaults in the entire design.

Coverage Data > FaultCoverage

Fault coverage for each submodule.

Coverage Data > ATPGEffectiveness

ATPG effectiveness for each submodule.





• To view sub-classes of faults, click in the column header of the fault type. A newcolumn is added for each sub-class. For undetected fault classes (AU, UC, and UO),percentage numbers displayed in the column represent the percentage of the design nottested as a result of the fault.

• Statistics data displays only for submodules, not library level instances or primitives. Beaware that when you display data, there is some processing time overhead (progress ofwhich you can check in the progress bar).

• If the data in a column becomes invalid due to the state of the tool, that column becomesunavailable and the Refresh Data menu item on the Data menu is enabled. Forexample, if test coverage data is displayed and you create additional patterns, the testcoverage column will no longer be available. Pushing the refresh button regenerates thedata. The data will always match what is reported by commands like Report Statisticsand Report Drc Rules.

• To make the display easier to read when viewing statistics, you can group all librarylevel instances into the artificial level of hierarchy called $$Gates$$. To enable instancegrouping, select the Display > Group Instances > On menu item.

• The Signals Window works together with the Browser Window, allowing you to browseand select ports and wires for the instance selected in the Browser.

• Use File > Save As or click to save a text or comma separated value (CSV) versionof the displayed hierarchical tree.

N/A Optimized NCPs (Named Capture Procedures)display in the Wave window. To seeunoptimized NCPs, click the UOP icon.Note: This icon is only available after you haveselected a NCP to view using the Data > NamedCapture menu; only NCPs defined in the testprocedure file are available from this menu.

N/A Unoptimized NCPs display in the Wavewindow. To see optimized named captureprocedures, click the OP icon.Note: This icon is only available after you haveselected a NCP to view using the Data > NamedCapture menu.





November 2010

Using the Hierarchy Browser

From DFTVisualizer, choose Windows > Browser. By default, the Hierarchy Browser displaysthe following columns:

• Instance Name — The name of the instance in the netlist. Instances of primitives includetheir gate ID. Instance types are shown with the icons listed in Table 3-11.

• Design Unit — What the instance is an instantiation of (Verilog module, ATPG librarymodel, or primitive type).

• Instances — Number of instances at this level of hierarchy. Does not include the numberof instances within each submodule.

In the Hierarchy Browser:

• Click the plus sign (+) next to an instance to display the gates and primitives for thatindividual instance.

• Double-click on any instance to automatically expand/collapse it.

• Click the right mouse button and use the View In popup menu option to add an object toanother window.

• Click the right mouse button over an object in hierarchy and use the View in TextEditor popup menu option to view the Verilog definition for the instance in a TextEditor.

• Use File > Save As or click to save a text or comma separated value (CSV) versionof the displayed library model to a file.

Using the Library Browser

From DFTVisualizer, choose Windows > Browser and click the Library tab. By default, theLibrary Browser displays the following columns:

• Library Model — ATPG library models used in the design. By default, consolidateddata for each ATPG model displays. Instance types are shown with the icons listed inTable 3-11.

• Number of Instances — Number of instances at this level of hierarchy. Does not includethe number of instances within each submodule.

In the Library Browser:

• Click on the (+) next to a library model to display statistics for the individual instancesof the model in the design.

• Click the right mouse button over an object and use the View In popup menu option toadd an object to another window.



• Click the right mouse button over an object and use the View in > Text Editor(Definition) popup menu option to view the Verilog definition for the instance in a TextEditor.


Figure 3-31. Browser Window with Library Tab Active

Using the Clock Browser

From DFTVisualizer, choose Windows > Browser and click the Clocks tab. By default, theClock Browser displays the following columns:

• Clock — The name of a clock in the design. Instance types are shown with the iconslisted in Table 3-11.

• Attributes — The attributes of each individual clock as reported by the Report Clockscommand. Specifically, the sub-columns Off State, Constraint, and Internal aredisplayed.

• Faults — The total faults for each clock domain and the percentage of all faults in thedesign.

NoteIf a fault is in multiple clock domains, the fault is attributed to each clock domain.Because of this, it is possible that the sum of all fault percentages (faults in a clockdomain as a percent of the total faults in the design) can exceed 100%.

• Test Coverage — Percentage of all testable faults detected by a pattern set for thatparticular clock.

In the Clock Browser:

• Click on the (+) next to a clock to display statistics of the individual instances for eachclock in the design. Only instances with faults in the expanded clock domain aredisplayed.



November 2010

• Click the right mouse popup menu and use the View In option to add an object toanother window.

• Click the right mouse button over an object in the clock’s hierarchy and use the View inText Editor popup menu option to view the Verilog definition of the instance in a TextEditor.


For more information on using the Clocks Browser, see section “Performing Clock DomainAnalysis in the Browser”.

Related Topics

Data Window

Debug Window

Design Window

Save Window command

Signals Window

Getting Started with DFTVisualizerData Window


Data WindowThe Data window provides a tabular presentation of the Report Gates command output thatallows you to see data for multiple instances and multiple data sets at the same time.


From the DFTVisualizer menu, choose the Windows > Data menu item.

Figure 3-32. Data Window

Using this Window

• Add any type of instance (submodule, library level instance, primitive) or signal(submodule port, instance port, wire) to the Data window using any of the followingmethods:

o Select one or more instances in another window. Then place the cursor over one ofthe selections, press the Control-left mouse button, and drag into the display area ofthe Data window and release.

o Select an instance from another window and use the View In option on the rightmouse button menu.

o Use a command that adds named instances to the display (Add Display Instances forexample).

o Click the Add Instances icon on the tool bar.

• Delete instances or signals from the Data window by selecting them, then using any ofthe following methods:

o Select the Display > Delete menu item.


Getting Started with DFTVisualizerData Window

November 2010

o Select Delete from the right mouse button popup menu in the window’s display area.

o Click the Delete Selected icon.

• To display data in the Data window use the Data pulldown menu, the correspondingbuttons on the tool bar, or a command that adds data to the display (Add Display Datafor example).

• To remove data from the Data window, move the cursor over the column header youwant to delete and select the column to delete from the right mouse button popup menu.

• To re-add data you have removed from the Data window, move the cursor over anycolumn header and select the column to re-add from the right mouse button popupmenu.

• To view the data for cycles that are out of view in a long test_setup procedure, use theDisplay > Test_Setup menu item (or Test_Setup from the right mouse popup menu inthe window’s display area).

• To open the Test_end procedure in a text editor, select Data > Test-End to display thedrc test_end column; then, click the left mouse button on the column header.

Related Topics

Debug Window

Design Window

Getting Started with DFTVisualizerDebug Window


Debug WindowThe Debug window displays a schematic representation of the flattened design. Refer to ModelFlattening in the Scan and ATPG Process Guide for more information about flattening.


From the DFTVisualizer menu, choose the Windows > Debug menu item. In FlexTest, theDebug window is only available when FlexTest is in DRC mode.

Figure 3-33. Debug Window

Table 3-13. Debug Window Contents

Window Area Description

Off Page Connector Allows you to trace from one sheet to another when the schematicis split into multiple sheets. Double click the connector on the netat the very right or very left of the schematic.

Selected Instance Shows the type of a selected instance (submodule or design levelgate) and its name.

Number of InstancesDisplayed (Selected)

Shows the number of instances in the display (and of those, thenumber selected)

Reporting Status Shows the current gate report setting.

Gate Level Setting The schematic is presented at design level by default but can beshown at primitive level (controlled by the Display > Gate Levelmenu item). See “Setting the Level of Gate Data” on page 18 formore information.

Sheet Number Entry Box Allows you to navigate to a specific sheet by entering thatnumber in the entry-box. Also displays which sheet you arelooking at and the total sheet count.


Getting Started with DFTVisualizerDebug Window

November 2010

Using this Window

• To add instances to the Debug window, use any of the methods described in “AddingInstances to a Display Window” on page 260. One or more instances may also be addedby the following menu selections:

o Tools > Analyze DRC — Automatically adds instances associated with a particularDRC violation. See “Analyzing a DRC Violation” on page 274 for moreinformation.

o Tools > Analyze Fault — You can have the instance where an analyzed fault islocated automatically added to the Debug window. See “Analyzing a Fault andDisplaying its Location” on page 286 for more information.

• Utilize callout markers on schematic objects to toggle the display of debugginginformation as follows:

o View the information in a callout (without expanding it) by hovering the mouse overthe callout marker.

o Expand a callout by clicking the callout marker using the left mouse button.

o Move a callout box by pressing the Shift key and using the right mouse button todrag the box to a new location.

o Close a callout by clicking the in the upper right corner of the callout box usingthe left mouse button.

• To toggle the display of false paths on or off, click the False Paths icon or select theData > False Paths On | Off menu item. These actions execute the Set Gate Reportcommand with the -false_path option enabled or disabled.

• To view Test_end data in the Debug window, select the Data > Test-End menu item.This action executes the Set Gate Report command with the test_end option enabled ordisabled.

• For information about navigating schematics in the Debug window, refer to “TracingSignal Paths on a Schematic” on page 266. In addition to tracing methods, this sectionalso covers:

o Compacting Buffers and Inverters in Traced Circuitry

o Annotating Schematic Data in the Debug Window

Callouts An expandable marker on the schematic associated with aspecific instance. The marker expands into a text box that displaysinformation about the object that helps in debugging issues such asDRC violations and simulation mismatches.

Table 3-13. Debug Window Contents


Getting Started with DFTVisualizerDesign Window


• To create “what if” scenarios when debugging test coverage and other issues in TessentFastScan, FlexTest and Tessent TestKompress, you can run the Report Test Stimuluscommand for pins you select on a displayed schematic. See “Executing Report TestStimulus” on page 288 for more information.

• To help improve performance, the schematic is automatically divided into multiplesheets when too many instances are visible. To navigate to a specific sheet enter itsnumber in the sheet number entry box. To continue a trace to another sheet, double-clickthe marker on the net at the very right or very left of the schematic.

• In Tessent Diagnosis and Tessent TestKompress, use the Tools > Diagnosis Reportmenu item to display diagnosis suspects on a schematic. Refer to “Displaying Suspectsin the Schematic View” in the Tessent Diagnosis User’s Guide for completeinformation.

Related Topics

Data Window

Design Window

Design WindowThe Design window displays a hierarchical schematic of the design as described in the inputnetlist. Includes net names and hierarchical ports. Goes down to library level instances.


From the DFTVisualizer menu, choose the Windows > Design menu item.

Figure 3-34. Design Window



November 2010

Table 3-14. Design Window Contents


Selected Instance Shows the type of a selected instance (submodule or designlevel gate) and its name.

Number of InstancesDisplayed (Selected)

Shows the number of instances being displayed (and how manyof that number are currently selected).

Net Bundling Status Shows whether net bundling (displaying nets connectedbetween the same instances as single thick lines) is enabled.Controlled by Display > Net Bundle menu item.

Sheet Number Entry Box Allows you to navigate to a specific sheet by entering thatnumber in the entry-box. Also displays which sheet you arelooking at and the total sheet count.



Using this Window

• To add instances to the Design window, use any of the methods described in “AddingInstances to a Display Window” on page 260.

• For information about navigating a schematic in the Design window, refer to:

o “Tracing Signal Paths on a Schematic” on page 266

o “Tracing Signal Paths in the Design Window” on page 269

o The example under “Step 2 - Find the Source of Problem Signals” on page 277

o “Getting Oriented in a Large Design” on page 289

• To help improve performance, the schematic is automatically divided into multiplesheets when too many instances are visible. To navigate to a specific sheet enter itsnumber in the sheet number entry box. To continue a trace to another sheet, double-clickthe marker on the net at the very right or very left of the schematic.

Related Topics

Data Window

Debug Window


Getting Started with DFTVisualizerFormat Guide Window

November 2010

Format Guide WindowThe Format Guide is used with the Data Window or the Debug Window to display a waveformrepresentation of selected test pattern data and provide a detailed explanation for each bit.


From the DFTVisualizer menu, choose the Windows > Format Guide menu item.

Figure 3-35. Format Guide Window

Using this Window

To view a waveform diagram of the capture cycle(s) for a test pattern:

• From the Debug window, select pattern data from the Data menu. The Format Guidewindow opens and displays a diagram that describes each bit of the selected data typefrom the Debug window. If the Format Guide window is already open, it is updated withthe relevant data.

• From the Data window, click on the column title for a pattern. The Format Guidewindow opens and displays a diagram that describes each bit in the selected pattern data.

Related Topics

Data Window

Getting Started with DFTVisualizerGlobal Search Window


Global Search WindowUse the Global Search window to search for any instance, net, or pin in the design.

NoteYou can use the Find icon on the menu bar to specify a search that is limited to theactive window.


From DFTVisualizer, choose Windows > Global Search or click the Search icon .

Figure 3-36. Global Search Window

Using this Window

• Enter a string in the Global Search text entry box and use a question mark(?) or anasterisk(*) as wild card characters if needed. Be aware that the search string applies tothe entire pathname of an instance. For example, in Figure 3-36, entering the string*ix17 returns the results shown but the string ix17* returns zero matches.

• Click the arrow next to the search field to display a search history.

• Click the Options button to toggle the display of additional search parameters.

• Click on a result to copy it to the copy/paste buffer or drag-n-drop (using Control-leftclick). For more information, see “Copying Instances Between Windows” on page 264.


Getting Started with DFTVisualizerSignals Window

November 2010

NoteYou can cancel the search operation by clicking Cancel in the Global Search dialog box.The Cancel button displays when the search operation starts to display results; you maynot see the button unless the Limit Displayed Matches To: field is set to a large number.

• Select an object(s) and choose the View In > menu item from the popup menu to viewobjects in one or more other windows. You can select multiple objects by holding downthe Shift key while clicking on the objects you want to select; when you release the Shiftkey, the set of objects you clicked on remains selected and available to View in anotherwindow.

• Use File > Save As or click to save a text or comma-separated value (CSV) versionof a global search to a file.

Signals WindowThe Signals window lets you view ports and signals for instances selected in the BrowserWindow.


From the DFTVisualizer window, choose Windows > Signals.

Figure 3-37. Signals Window

Getting Started with DFTVisualizerTest Structures Window


Using this Window

• To display signals in alphabetical order, click the Name column header; to view signalssorted by type, click the Type column header.

• To display wires (nets) that are inside a submodule selected in the Hierarchy tab of theBrowser window, choose the Display > Display Nets > On menu item. This option isvalid for submodules only.

• To show the names of individual bus pins, click the plus sign (+) next to the bus’s name.To remove the names of individual bus pins, click the minus sign (-) next to the bus’sname.

• The Signals window has the same right mouse popup menu options as the Browserwindow.

Related Topics

Browser Window

Test Structures Window

Use the Test Structures window to do the following:

• Browse a virtual graphical representation of the EDT logic. To display actual net and pinmapping information graphically, you must add the EDT component to the Debug orDesign window.

• Display textual information about components within the EDT logic.

• Debug DRC violations related to the EDT logic.

NoteYou must first run Set EDT Finder on a design to gather the EDT logic informationbefore you can display it in the Test Structures window.

Table 3-15. Signals Window Contents


Port Display Area Shows the name, type of each port, and constraints of theinstance selected in the Browser.

Wire Display Area Shows the names of wires inside the selected instance (if it is asubmodule and wire display is enabled) in the Browser.

Wire Display Status Shows whether the display of internal wires is enabled for theSignal window (Display > Display Nets > On).


Getting Started with DFTVisualizerTest Structures Window

November 2010


Open the Test Structures window by doing one of the following:

• From DFTVisualizer, choose Windows > Test Structures.

• From the command line within a tool session, enter the following command:

open visualizer -display test_structures

Figure 3-38. Test Structures Window

Using this Window

• Double-click graphic blocks to descend down and display internal components.

• Click on graphic objects to display information about the object in the text pane.

• Click callout boxes on graphic objects to toggle the display of DRC analysisinformation. Press the Shift key and use the right mouse button to move the callout boxmarkers.

• Click on the plus sign preceding a device in the text pane to expand text to includedevice pin information.

• Double-click on a device in the text pane to display it in the Design window.

• Search/Filter the contents of the text pane as follows: Click in the top of a text panecolumn, type a term to search/filter on, and click on the binoculars. The contents of the

Getting Started with DFTVisualizerText Editor Window


column is filtered so the specified term displays at the top. Click the magnifying glass atthe top of the first column to clear all filter entries.

Related Topics

Tessent TestKompress User’s Guide

Text Editor WindowUse the Text Editor window to do the following:

• View currently loaded design files: netlists, ATPG library, test procedure files, startupfiles, and dofiles.

• View the definition and instantiation of instances in a Verilog netlist or ATPG library.

• Create, edit, and save test procedure files, dofiles, and startup files.

• Troubleshoot test procedure files.

• Locate and debug test procedure file errors during DRC.

• Use built-in Verilog, VHDL, and test procedure file templates for making on-the-flychanges.

NoteDFTVisualizer supports all of these operations for compressed netlist and ATPG libraryfiles with any of the following file extensions: “.Z”, “.gz”, “.gzip”, and “.zip”.

Accessing this WindowOpen the Text Editor window by doing one of the following:

• Choose Windows > Text Editor from the DFTVisualizer pulldown menu.

• Execute the following command from the tool command line:

open visualizer -display text_editor

• Click the right mouse button (RMB) on an instance in any of the followingDFTVisualizer windows: Debug, Design, Data, Wave, Browser, or Global Search.Choose one of the View in Text Editor > Defining Text | Instantiating Text menuitems.

• Click on a hyperlink (pink underlined text) in the Transcript window.



November 2010

Figure 3-39. Text Editor Window

Using this Window

The Text Editor contains standard text editor functions. You access these functions from theFile and Edit menus and by clicking the right mouse button (RMB) to display the popup menu.

You can specify the type of syntax highlighting to be applied to the contents of the Text Editorby selecting the Display > Syntax Highlighting menu and choosing from the followingsyntaxes: Verilog, VHDL, ATPG Library, Test Procedure, or Dofile. By default, the Text Editorhighlights text using Verilog syntax.

The Text Editor also provides:

• Access to any design files currently loaded in DFTVisualizer. To view currently loadedVerilog netlist files, dofiles (including startup files), the ATPG library, and the testprocedure file, choose File > Open > Current Design Files.



o To open all currently loaded design files, choose All. Be aware that if the tool isinvoked on a flat model, the netlist, ATPG library, and test procedure file are notopened. If a dofile or startup file is specified, it is opened using this option.

o To open any subset of the currently loaded design files, choose from the individualfiles listed under the submenus: Netlist | ATPG Library | Dofiles.

• Display options such as window positioning options, font sizes, and line numbers. To setdisplay options, choose the Display > Windows | Font | Line Number menu items.

• Search and replace operations using ASCII text or regular expressions. To search and/orreplace, choose Edit > Search | Replace. To use regular expressions, click More andenable the Regular Expression option.

• Support for vi and emacs text editor key bindings. To access, choose Display > KeyStroke Mode.

• Support for viewing and modifying compressed netlist and ATPG library files. To opena ZIP file, choose File > Open > Other, select the compressed file to open from theOpen File dialog box, and click OK. Each compressed file you open displays as a tab inthe Text Editor.

NoteDFTVisualizer supports all of these operations for compressed netlist and ATPG libraryfiles with any of the following file extensions: “.Z”, “.gz”, “.gzip”, and “.zip”.

• Cross-highlighting between a selected instance and its description. To display a selectedinstance in the Debug, Design, Data, Wave, Browser, or Global Search window, chooseone of the View In Text Editor > Defining Text | Instantiating Text menu items:

o Defining Text — displays the Verilog module definition for gate instances or theATPG library model for library instances and primitives.

o Instantiating Text — displays the Verilog instantiation in the netlist.

If the tool is invoked on a flat model, the View in Text Editor option is disabled.

NoteSome designs contain multiple definitions of library models or Verilog modules in theATPG library and netlist files. The Text Editor will only display the definition that is inuse by the tool; this is determined by the priority used when the library and Verilog filesare parsed at tool invocation.

• Templates for DFT-specific operations. To access the templates, choose Display >Show Template and click a specific template item to insert the template into thecurrently-opened file.


Getting Started with DFTVisualizerTranscript Window

November 2010

Transcript Window

Use the Transcript window to do the following:

• Enter and execute tool commands.

• View color-coded log file information.

• View instances reported by tool in schematic windows.

• Open documentation for reported DRC violations.

• View notes, warnings, and errors applicable to the current session.


Open the Transcript window by doing one of the following:

• Choose Windows > Transcript from the DFTVisualizer pulldown menu.

• Execute the following command from the tool command line:

open visualizer -display transcript

NoteThe Transcript window opens by default when DFTVisualizer invokes.

Figure 3-40. Transcript Window

Using this Window

• All tool commands can be executed in the Transcript window. Tool responses aredisplayed in the Transcript window as well as in the shell window. Tool responses arecolor-coded for better readability and easy identification of important messages.

• A dofile of commands executed in the Transcript window can be created. To write adofile of the commands shown in the Transcript window, choose the File > CreateDofile menu item. Specify the name of the dofile to create in the Selection field of theCreate Dofile dialog box. All of the commands output by the Display > Filter >

Getting Started with DFTVisualizerWave Window


Command menu item are saved to the dofile with the exception of comment characters“// command:” which are omitted.

NoteThe dofile is saved to the path specified in the Selection field. If you do not specify anabsolute path, the dofile is saved in the current directory.

• The contents of the Transcript window can be filtered. To filter the contents of theTranscript window, choose one of the Display > Filter menu items described inTable 3-16.

• You can quickly view the contents of the Transcript window by clicking and holdingdown the middle mouse button while moving the mouse up and down to view thedesired text.

Related Topics

Save Visualizer Dofile command

Wave WindowThe Wave window displays a waveform representation of the simulation results for thetest_setup procedure, test_end, VCD, and named capture procedures.


From the DFTVisualizer menu, choose the Windows > Wave menu item.

Table 3-16. Transcript Window Contents

Filter Description

Error Only errors are displayed in the Transcript window. Errorsdisplay in red font.

Warning Only warnings are displayed in the Transcript window.Warnings display in green font.

Command Only commands are displayed in the Transcript window.Commands display in black font.

Show All All errors, warnings, and commands are displayed in theTranscript window and each displays in their respective fontcolor. Report output is also displayed in blue font.



November 2010

Figure 3-41. Wave Window

Using this Window

• To use the Wave window, first add instances and the test_setup column to the Datawindow using the Data > Test-Setup menu item; then, open the Wave window.

• To specify to display a specific time range in the Wave window, activate the Wavewindow and select Data > VCD from the pulldown menu.

• To view Test_end data in the Wave window, select the Data > Test-End menu item.

Tip: The Waveform window works together with Data window, automatically showingthe same instances and test_setup data as the Data window, but showing the data as awaveform with timing information.

Table 3-17. Wave Window Contents


Instance Pane Shows the same instances as the Data window.

Waveform Pane Shows a waveform representation of the same test_setupprocedure data shown in the Data window.



Related Topics

Data Window


Getting Started with DFTVisualizerDFTVisualizer Command Quick Reference

November 2010

DFTVisualizer Command Quick ReferenceThe following table provides a brief summary of tool commands that are specifically foroperating DFTVisualizer. The five columns that separate the command name and thedescription indicate the tools in which you can use the commands. The following tool acronymsare used in the table:

DFTA = DFTAdvisorFS = Tessent FastScanFT = FlexTestLABR = LBISTArchitect — BIST-Ready phaseLAFS = LBISTArchitect — Fault Simulation phaseTK= Tessent TestKompressYA = Tessent Diagnosis

Table 3-18. Command Summary

Command

DFTA

FS

FT

LABR

LAFS

TK

YA

Description

Add Browser Data • • • • • • • Adds data columns to the active tab ofthe Browser window of DFTVisualizer.

Add Display Data • • • • • • • Adds data columns to the Data windowof DFTVisualizer.

Add Display Instances • • • • • • • Displays instances in DFTVisualizerand enables you to trace visuallythrough the design using the Debug orDesign window.

Analyze Drc Violation • • • • • • Generates a netlist of the portion of thedesign involved with the specified ruleviolation number.

Close Visualizer • • • • • • • Closes the DFTVisualizer window.

Delete Browser Data • • • • • • • Removes data columns from theBrowser window of DFTVisualizer.

Delete Display Data • • • • • • • Removes a data column from the Datawindow of DFTVisualizer.

Delete Display Instances • • • • • • • Removes the specified instances from aDFTVisualizer display window.



Display Diagnosis Report • • Opens a diagnosis report in which youcan click symptoms and suspectlocations to add related gates to theDFTVisualizer Debug window.

Load Visualizer Preferences • • • • • • • Reads a DFTVisualizer preferences fileand sets current preferences asdescribed in the file.

Mark • • • • • • • Changes the color of the specifiedinstances in the Debug/Design window.

Open Visualizer • • • • • • • Opens the DFTVisualizer main window.

Report Display Instances • • • • • • • Lists netlist information for specifiedinstances displayed in the Debugwindow.

Save Visualizer Dofile • • • • • • • Writes a dofile containing commandsneeded to recreate current instance anddata displays.

Save Window • • • • • • • Saves a screen capture of aDFTVisualizer window.

Select Object • • • • • • • Selects the specified objects in theDebug and/or Design window.

Set Visualizer Logging • • • • • • • Writes the commands entered into theTranscript window to the file specifiedby the enhanced_dofile argument.

Set Visualizer Preferences • • • • • • • Controls a subset of DFTVisualizerpreferences for the Debug, and Design,Browser, and Data windows.

Unmark • • • • • • • Removes color highlighting and/ormarking from instances in the Debugwindow.

Unselect Object • • • • • • • Unselects the specified objects in theDebug and/or Design window.

Write Visualizer Preferences • • • • • • • Writes the current DFTVisualizerpreference settings to a file.

Table 3-18. Command Summary (cont.)

Command

DFTA

FS

FT

LABR

LAFS

TK

YA

Description



November 2010


Chapter 4Design Library

This chapter describes 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, Tessent FastScan, FlexTest, and Tessent TestKompress.

This chapter includes the following topics:

Defining Scan Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Defining a Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

Defining Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Using Model Aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Reading Multiple Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Verilog Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Supported Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

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

November 2010

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;length = integer;usage = <input|output|hol0|hol1>;non_scan_model = model_name(list_of_pins);scan_clock = pin_name;scan_master_clock = pin_name;scan_slave_clock = pin_name;offstate_inverted = pin_name, ...;tie0 = pin_name, ...;tie1 = pin_name, ...;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:

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

• data_inThe “data_in” attribute is an optional attribute that defines the name of the data input pinof the mux-DFF scan cell. Multiple data_in pins are not supported.



• 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. Multiple scan_in pins are not supported.

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

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

• lengthThe "length" attribute is an optional attribute that specifies the number of cascadedsequential cells in the scan cell library model. The integer value must be larger thanzero. If this attribute is not specified, the default value for the scan cell model is 1.DFTAdvisor uses this value to balance the scan chains during the scan cell distribution.

A scan cell with a length greater than 1 is referred to as a multi-bit scan cell. In amulti-bit scan cell, the number of scan cell ports do not change; there is still a singlescan input port, scan output port, and scan enable port. This is because the cascading ofthe sequential cells are assumed to be done by connecting the scan I/O ports of eachsequential cell to form an internal scan chain inside the multi-bit scan cell. The datainput and output ports, however, are multiplied by the length value.

DFTAdvisor does not check the connections of the sequential cells in the multi-bit scancell. You need to be sure that stitching multi-bit scan cells in scan chains will not causeDRC tracing rule violations.

If the sequential cells within the multi-bit scan cell are already stitched into scan chains,an alternate method for defining internal scan chains is to use the Add Sub Chainscommand with the -library_model switch. For more information on this method, see theDFTAdvisor Reference Manual.

• usageThe “usage” attribute describes the model usage when replacing non-scan cells withwrapper scan cells. More than one scan cell can map to a non-scan cell, and duringwrapper scan chain insertion, scan cell selection depends on whether DFTAdvisoridentifies the non-scan cell as an input wrapper cell, an output wrapper cell, a hold-0wrapper cell, or a hold-1 wrapper cell.



November 2010

• 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 theinterface 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_master_clockThe “scan_master_clock” attribute defines the name of the scan master shift clock of theLSSD cell.

• 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 mapped



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

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.



November 2010

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



November 2010

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.

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



An example of a double latch nonscan model is shown below:

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



November 2010


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



November 2010

Model_sourceThis statement is optional. It is used only for -model verification flows to ensure that anappropriate Verilog test harness netlist can be created to instantiate each model for exercisingby ATPG and ModelSim simulations.

The following statement must precede the model_source statement:

model model_name (list_of_pins)

The Verilog source that created the translated model is identified using exactly one of thefollowing four legal model_source statements within any model:

If the model was originally a User Defined Primitive table:

model_source = verilog_udp;

If the model was originally a Verilog module:

model_source = verilog_module;

If the model has one or more ports in the defining portlist that Verilog considers an unnamedport such as “A[0]” or “B[3:0]”, that instance must be instantiated positionally:

model_source = verilog_unnamed_port_module

If the model has no corresponding Verilog module and, therefore, cannot be instantiated for the-model verification, the translation is exercised when the overriding instance (which must existin the Verilog source for the module to have an override) is exercised:

model_source = verilog_parameter_override;

When a Verilog model is created, the generated instance uses pinnames in the portlist. Thisensures correct connections even if the Verilog simulation pin order differs from the Verilogtest view pin order that was used to create the ATPG library being verified. Because it is illegalto instantiate Verilog primitives by pinname (even UDPs), the test harness instantiates UDPs aspositional instances for verification.

If the model_source is from a parameter override, the model does not have an explicit Verilogmodule in the source that matches it because these models were uniquified to allow tests to becreated. Therefore, modules from a parameter override are not instantiated in the Verilog testharness created for verification simulation because there is no matching Verilog module forModelSim to compile for simulation. Although these modules cannot be tested as stand-alonefunctionality, they are tested in place when the Verilog module with the instance override istested: that is, both in the ATPG run using the uniquified model and in the Verilog simulationusing the Verilog override simulation mechanism.



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. Internal nodescan be used to define complex logical structures. An example of how these pins are defined is asfollows:

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

SDFF

TI

TE

D

CLK

Q

QN



November 2010

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:

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#”. In the ATPG library model, you should refer to that identifier without back slashes, butwith enclosing double-quotes. For example, given this very simple 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);)

)

In another example, given the following fragment of a netlist:

model special_chars // defining model ("clk#", d, o)...

If another model instantiates the instance above using named connections, the name containingthe special characters should be quoted, as shown:

instance = special_chars sp_ch_inst_1(."clk#"(clk_net), .d(data_net), .o(out_net) );

Note that only the characters of the name are quoted. The period which indicates that a definingpinname will follow is outside the double quotes because it is not part of the defining pin'sname. For more information on specifying the instance attribute statement, see the section“Intern Attributes” on page 356.

Cell_typeTest logic is added to a design to make certain flip-flops scannable. The models used for the testlogic must be defined in the DFT design library. Use the cell_type attribute to specify a librarymodel to be used in test logic circuitry with the following syntax:

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

You can also use the Add Cell Models command to specify test logic models.

NoteThe cell_type attribute cannot be used to specify a lockup cell model for lockup cellinsertion. Instead, the Add Cell Models command should be used to specify the lockupcell model. For more information, see the Set Lockup Cell command in the DFTAdvisorReference Manual.



November 2010

Example 1 — AND Gate

The following example shows a model description that states the AN2 cell can be used as anAND gate within test logic circuitry:

model AN2 (A, B, Z) ( cell_type = AND; input (A, B) () output (Z) (function = A * B;) )

Example 2 — Scan Cell

The following example shows a model description that uses the cell_type attribute to specify ascan cell component used within test logic circuitry. Note that the clock and data ports are alsospecified along with 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);) )

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 a pin is usedinternally. By default, a message is issued if an input pin or intern is unused. You canuse the statement used=false to suppress the warning message for a particular pin orintern. If this attribute is not used, the default is true and the message is issued. Thesyntax 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.



November 2010

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 356):

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 374 for all of the DFTAdvisor, Tessent FastScan, FlexTest, and TessentTestKompress supported primitives.

• 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>);

The model_name refers to another model name defined in the library. The list_of_netsrefers to the boundary pins of the model_name. Each boundary pin can be specified as



November 2010

either a positional or pinname connection; a pinname connection does not rely onposition at all as shown here:

instance = model_name (.pinX(net1), .pinY(net2),..., .pinZ(netN));

Instance pin connections are the default when Tessent LibComp (hereafter known asLibComp) translates Verilog modules. See the Set Instance Portlist command forinformation on how to obtain instance positional connections for backwardcompatibility with v8.2009_1 and earlier versions of the ATPG library parser.

Here is an example using the instance attribute statement:

model andnor2(A1, A2, A3, B1, B2, B3, ZN) ( input(A1, A2, A3, B1, B2, B3) () intern(N1) (instance = and3 (.A1(A1), .A2(A2), .A3(A3), .Z(N1));) intern(N2) (instance = and3 (.A1(B1), .A2(B2), .A3(B3), .Z(N2));) output(ZN) (instance = nor2 (.A1(N1), .A2(N2), .ZN(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 places faults beneath the instance, if the referencedmodel has internal faults. Faults are placed on the instance boundary, if the referencedmodel has no internal faults. This is the case if the model contains only functionstatements, or primitive or instance attribute statements with no instance names.

An instance attribute statement cannot have an instance name if there is a functionstatement described in the library model. If there is more than one instance attributestatement in a library model, either instance names must be given for all instanceattribute statements, or no instance names can be given. This also applies if there areprimitive and instance attribute statements in the same library model. Here is anexample of the instance attribute statement with instance positional connections:

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



November 2010

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

• 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 TessentFastScan and Tessent TestKompress, XX is used. In FlexTest, if this attribute is notused, the default value is 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, Tessent FastScan, or Tessent 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). In TessentFastScan and Tessent TestKompress, XX is used. In FlexTest, if this attribute is notused, the default 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, Tessent FastScan, or Tessent 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:



November 2010

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.

TIEZbus_keeper

Tri-StateDevice

Tri-StateDevice

Bus KeeperDevice

Bus ZHOLD

Tri-StateDevice

Tri-StateDevice



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

TNEN

A

PI

IO

ZI

PO

ETN

TNEN

ETN

intern(ETN) (function =!(TN * !EN);)



November 2010

• 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 Buffer7

• 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);) )

A IO

ETN

inout(IO) (primitive = _tsl(A, ETN, IO);)

IO ZI

output(ZI) (primitive = _buf(IO, ZI);)

PI POZI

output(PO) (primitive = _nand(ZI, PI, PO);)



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:

• 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

MUX

D

TI

DFF

ND

Q

QN

TE

CLK

MUX

D

TI

ND

TE

primitive = _mux(D, TI, TE, ND);)

DFFQ

QNCLK

ND

primitive = _dff(, , CLK, ND, Q, QN);)



November 2010

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

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

Z1

EN

A

Z2

PULL-UPOPTION



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

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.

Z1

EN

A

Z2

PULL-UP

OPTION

Z1

EN

A

Z2

PULL-UP

OPTION



November 2010

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:

Figure 4-21. Internal Faults

In this example, a netlist 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);) )

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



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

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



November 2010

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

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, square brackets “[]” 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) ); ) )


Design LibraryDefining Macros

November 2010

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:

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

Design LibraryReading Multiple Libraries


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 createdby 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 PrimitivesTessent FastScan, FlexTest, Tessent TestKompress, and DFTAdvisor understand Verilogprimitives, without requiring an ATPG model to be created. For example, the Verilog “and”directly maps to the built-in primitive “and” in DFT tools, and therefore no model is needed.Even if an ATPG library model named “and” is present, it will be ignored by the tool, since theVerilog reader will recognize this model as a primitive which the tool already understands.


Design LibrarySupported Primitives

November 2010

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.

Supported PrimitivesThe following pages contain descriptions, truth tables, and examples of the primitives supportedby DFTAdvisor, Tessent FastScan, FlexTest, and Tessent TestKompress. When defining aprimitive, you must understand the pin sequence of the primitive. The sequence of the pinnames is important to the primitive definition. A comma must be used as a separator to keep thefixed pin sequence format 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.

Table 4-1. Supported Verilog Primitives

and nand notif1 rcmos1 xnor

buf nmos1

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. The _pull primitive is unidirectional.LibComp cannot model a bi-directional resistive transfer in the general case.

or rnmos1 xor

bufif0 nor pmos1 rpmos1

bufif1 not pulldown rtran2

2. The _pull primitive is unidirectional. LibComp cannot model a bi-directionalresistive transfer in the general case.

cmos1 notif0 pullup tran



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



November 2010

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

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

I1I2I3

O



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)

Example:

model OR3(I1, I2, I3, O) ( input(I1, I2, I3) () output(O) (primitive = _or(I1, I2, I3, O);) )

Figure 4-24. OR Gate

Table 4-4. OR Truth Table

IN0 IN1 OUT

0 0 0

0 1 1

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

I1I2I3

O



November 2010

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



November 2010

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.

Table 4-8. BUFZ Truth Table

IN OUT

0 0

1 1

Z Z

X X

TN

EN

A

PI PO

ZI

IO

ETN



November 2010

XOR GateThe primitive used to model a XOR is _xor. The syntax of the primitive attribute statement is asfollows:

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



November 2010

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



November 2010

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



November 2010

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

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



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)

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 354. Tessent FastScan, Tessent TestKompress, andDFTAdvisor are not affected by these attributes. The default behavior of a single port D flip-flop is different for FlexTest, Tessent FastScan, and Tessent TestKompress and is shown in thefollowing 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 shows the truth table for D flip-flop primitive for Tessent FastScan, TessentTestKompress, and FlexTest. This is the default, that is the Set Simulation command’s -set_reset_dominate_port switch is set to ON.

Table 4-16. D Flip-Flop Primitives

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



November 2010

Table 4-17 shows the alternative truth table for the D flip-flop primitive for Tessent FastScan,Tessent TestKompress, and FlexTest when you disable set/reset port dominance using the SetSimulation command’s -set_reset_dominate_port OFF switch.

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,Tessent FastScan, and Tessent 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.

NoteYou can use the Set Xclock Handling command with the ‘X’ option to make the behaviorof the _dff and _dlat primtives more pessimistic when the clock is set to an X value. Thiscommand has no effect on other primitives.

Table 4-17. Alternative D Flip-Flop Primitive Table

D1 CLK1 SET RESET Q QN

0 ^ 0 ? 0 1

1 ^ ? 0 1 0

X ^ 0 0 X X

? - 0 0 Q QN

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



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.

R

D

CLK

Q

QN



November 2010

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, TessentFastScan, and Tessent TestKompress and is shown in the primitive table (Table 4-18).

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 01

1. Default value.

11

X2

2. Value if you disable set/reset port dominance by setting the Set Simulation command’s-set_reset_dominate_port switch to OFF.

X2

? 0 0 1 0 1

0 1 0 1 0 1

0 1 1 0 13

3. Default value.

03

X4

4. Value if you disable set/reset port dominance by setting the Set Simulation command’s-set_reset_dominate_port switch to OFF.

X4

1 1 1 0 1 0

? 0 1 0 1 0

? ? 1 1 X X



The default behavior for FlexTest, Tessent FastScan, and Tessent TestKompress of a multipleport D latch 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 for TessentFastScan and Tessent TestKompress, if the Set Simulation command’s-set_reset_dominate_port is set to OFF, then Q and QN are unknown.

NoteYou can use the Set Xclock Handling command with the ‘X’ option to make the behaviorof the _dff and _dlat primtives more pessimistic when the clock is set to an X value. Thiscommand has no effect on other primitives.

Example:

model DLAT1(CLK, D, Q, QN) ( input(D, CLK) () output(Q, QN) (primitive = _dlat(, , CLK, D, Q, QN);) )

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



November 2010

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



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 Tessent FastScan and Tessent TestKompress. Thisprimitive can only be used 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



November 2010

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



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.

Table 4-22. PULL Truth Table

IN OUT

1 Weak 1

0 Weak 0

N1

N4I O

NCNT

PCNT

I

O



November 2010

Power SignalThe primitive used to model a power signal is _tie1. The syntax of the primitive attributestatement is as follows:

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

Table 4-23. UNDEFINED Truth Table

IN0 IN1 ... INn OUT

? ? ... ? X



November 2010

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

Figure 4-42. Undefined Functional Block

A

B

C

D

O1

O2

O3



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



November 2010

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



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



November 2010

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



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 Tessent FastScan and Tessent TestKompress. Thisprimitive can only be used 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

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



November 2010

Unidirectional Feedback PMOS TransistorThe primitive used to model a feedback PMOS transistor is _pmosf. The syntax of the primitiveattribute statement is as follows:

primitive = _pmosf (I, CNT, O)

NoteThe previous state of “I” is X for Tessent FastScan and Tessent TestKompress. Thisprimitive can only be used 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

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



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:

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

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



November 2010

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:

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

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

I O

P

E



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)

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

Table 4-32. RCMOS1 Truth Table

I E P 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

Z ? 0 Z

X ? 0 Weak X

? 0 X Weak X

? X 1 Weak X

I O

P

E

resistive



November 2010

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)

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

Table 4-33. RCMOS2 Truth Table

I E P O

0 1 0 Weak 0

1 1 0 Weak 1

Z 1 0 Z

? 0 ? Z

? ? 1 Z

X 1 0 Weak X

? 1 X Weak X

? X 0 Weak X

I O

P

E

resistive



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

NoteThe previous state of I is X for Tessent FastScan and Tessent TestKompress. Thisprimitive can only be used in a feedback path.

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

Z ? 0 Z

X ? 0 Weak X

? 0 X Weak X

? X 1 Weak X



November 2010

Example:


Figure 4-53. Unidirectional Feedback CMOS1F Transistor

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 Tessent FastScan and Tessent TestKompress. Thisprimitive can only be used in a feedback path.

Example:


Figure 4-54. Unidirectional Feedback CMOS2F Transistor

Table 4-35. CMOS2F Truth Table

I (Previous State) NCNT PCNT O

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



November 2010

Pulse Generators with User Defined TimingTessent FastScan and Tessent TestKompress support pulse generators with multiple timedoutputs. This is useful in cases when pulse generators have only a single output, and user-specified delay and width attributes allow multiple pulses with different effective timing to begenerated. You can assume that the combinational delays of the circuit will be such that allpaths which need to stabilize between different pulses from choppers will have time to stabilize.The syntax of the primitive 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 RAM and ROM” in the Scan and ATPGProcess Guide. For information on RAM rules checking, refer to “RAM Rules (A Rules)” onpage 24.

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



November 2010

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



November 2010

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



November 2010

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 (CRAM) reading and writing capabilities is _cram.The syntax 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 zero or more write ports and one or more read ports. If it has nowrite ports, the tool treats the CRAM as a read-only CRAM during test pattern generation. Theport types are described in more detail in the section, “Attributes of RAM/ROM Primitives” onpage 423.



The content of the CRAM is provided through an initialization file. See “Initialization Files forRAM and ROM” on page 425 for more information.

Example CRAM:

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]) ); ) )

Example CRAM modeled using the array construct:

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

))



November 2010

Example CRAM with multiple ports:

model 2_port_ram (Clk1, WEN1, A1, Din1, Dout1, Clk2, WEN2, A2, Din2, Dout2) (

input (Clk1, WEN1, Clk2, WEN2) ()input (A1, A2) (array = 3:0;)input (Din1, Din2) (array = 3:0;)

intern (REN1) (primitive = _inv I1 (WEN1, REN1);)intern (REN2) (primitive = _inv I2 (WEN2, REN2);)

output (Dout1, Dout2) ( array = 3:0; data_size = 4; address_size = 4; min_address = 0; max_address = 15; edge_trigger = rw; read_write_conflict = xw;

primitive = _cram 2_port_cram (,,

//port 1 _write{,,} (Clk1, WEN1, A1, Din1), _read{,H,H,H} (,Clk1, REN1, A1, Dout1), //port 2 _write{,,} (Clk2, WEN2, A2, Din2), _read{,H,H,H} (,Clk2, REN2, A2, Dout2));

))

Example CRAM with write port definition removed to make it read-only:

model READ_ONLY_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 (,, _read{,H,H,H} (, Rclk1, REN1, RA1, Dout1) );

))



Another way to create a read-only CRAM is to tie the write ports of a regular CRAM to theinactive state. To be usable for test generation in Tessent FastScan or Tessent TestKompress, aread-only CRAM must meet the following requirements:

• The contents of the CRAM cannot be disturbed by any test procedures except test setup.

• The set and reset ports (and write ports when defined) must be inactive and stable duringcapture.

• The CRAM model in the ATPG library must define a valid initialization file. If themodel does not define an initialization file, the tool will treat the CRAM as TIEX forATPG, which will lower test coverage.

NoteTessent FastScan and Tessent TestKompress are the only tools that support read-onlyCRAMs for test generation.

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.

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



November 2010

• init_file = “file_name”;This optional attribute specifies the file, in Mentor Graphics modelfile format, defininginitial memory values. Specify the full path name to the initialization file if the file is notlocated in the directory from where you invoked Tessent FastScan or TessentTestKompress.

• 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 not set to true.This attribute defines the behavior when multiple ports are writing to the same address.If set to true, and if the addresses are different, both writes are carried out. If the addressis the same, precedence is given to the last port defined in the model (data at the otherwrite port 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, Tessent FastScan, FlexTest, and TessentTestKompress exhibit the same behavior.

Initialization Files for RAM and ROMAn initialization file may be used to define the initial values of the memory cells of the RAMand ROM. The supported format of this file is the Mentor Graphics ROM/RAM modelfileformat. For a detailed description of this format, refer to the Read Modelfile command in theATPG and Failure Diagnosis Tools Reference Manual. After you create the modelfile, you usean init_file attribute within the RAM or ROM model description to specify the file.Alternatively, you can use the Read Modelfile command to read in the 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 xclock handling does not affect ram or rom primitive simulation, even if the primitive isedge-triggered. This command affects _dff and _lat primitives only.



November 2010

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 inactive byusing the read_off attribute.

X handling for ram and rom primitives does not depend on triggering. The level and edgetriggered ports have the same X behavior.

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

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.

RAMout

oenwenadrdi0di1

do0do1

out



November 2010

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.

The xclock handling does not affect ram primitive simulation, even if the primitive is edge-triggered. This command affects _dff and _lat primitives only.

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, Tessent FastScan and Tessent TestKompress setthe memory cells that will be accessed by the address to X. FlexTest does the same if the inputdata value differs from the memory cell of the RAM. If the input data and the memory cell valueare the same, the memory cell value will not be changed.

X handling for the ram primitive does not depend on triggering. The level and edge triggeredports have the same X behavior.

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

The xclock handling does not affect cram primitive simulation, even if the primitive is edge-triggered. This command affects _dff and _lat primitives only.

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.

X handling for the cram primitive does not depend on triggering. The level and edge triggeredports have the same X behavior.

An X on a _cram write port control, clock or enable, will X the current address[es] even if theother control is off/0, and even if the triggering is edge. An X on an address bit covers both 0and 1 values, so at least two rows are Xd if any encoded write address bit and any write controlbit is X.

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



November 2010

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.

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.

NoteTessent FastScan and Tessent TestKompress will report an A5 rule violation in this case.

The xclock handling does not affect cram primitive simulation, even if the primitive is edge-triggered. This command affects _dff and _lat primitives only.

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.

X handling for the cram primitive does not depend on triggering. The level and edge triggeredports have the same X behavior.

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.



November 2010


Chapter 5Creating ATPG Models

This chapter describes how to create ATPG models using LibComp. LibComp translatesVerilog modules into ATPG models for use with DFTAdvisor, Tessent FastScan, FlexTest, andTessent TestKompress. This chapter includes the following topics:

Converting TetraMax Primitives to Verilog Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . 433

Creating an ATPG Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Finding Unsupported Constructs in Partial Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

Finding Black Boxes with Vectored Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

LibComp Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

LibComp Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

UDP Limitations and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

I/O Pad Limitations and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Memory Limitations and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Converting TetraMax Primitives to VerilogPrimitives

Although LibComp translates TetraMax primitives into a valid Mentor Graphics ATPG library,the primitives are undefined modules in Verilog and prevent simulation, which is needed toverify the translated ATPG library. LibComp provides an ATPG primitives definition file(atpg_lib_prims.v) that defines the mux (multiplexor), dlat (D latch), and dff (D flipflop) ATPG(or extended Verilog) primitives referenced in Verilog for simulation with ModelSim.However, some libraries contain different width Boolean primitives (and, or, and so on) that arenot defined in the atpg_lib_prims.v file. Therefore, if you want to verify ATPG libraries usingLibComp’s verification, you must either remove the ATPG primitives from the source librariesor run the tmax_to_verilog.pl script located inTessent_Tree_Path/bin/libcomp/tmax_to_verilog.pl. This script only converts the tieX andBoolean primitives into Verilog primitives. Limitations of the script are included in thetmax_to_verilog.pl file.


Creating ATPG ModelsCreating an ATPG Library

November 2010

Creating an ATPG LibraryTo create an ATPG library from a Verilog netlist or library of Verilog modules, invoke theLibComp tool on the Verilog source library/netlist using the default dofile provided byLibComp. For example:

Tessent_Tree_Path/bin/libcomp verilog_source -dofile -log log_file

For more information on the invocation arguments, see the libcomp shell command in theATPG and Failure Diagnosis Tools Reference Manual.

To get a quick reminder of the invocation arguments for LibComp before running it, enter thefollowing on the command line:

libcomp -help

Finding Unsupported Constructs in PartialModels

When unsupported constructs are encountered, the LibComp tool continues to translate thesupported pieces of the module into a partial model.

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 the LibComp tool on the Verilog library and create a logfile. For example:

Tessent_Tree_Path/bin/libcomp library_path -log log_file -replace

The library is translated and a log file detailing the output including unsupportedconstructs is generated.

2. From the UNIX/Linux command line, search the logfile for the unsupported message:

grep "not translated/supported." my.log

Each instance of the “not translated/supported” warning message in the logfile isdisplayed in the module name and the line number of the unsupported construct.

If an ATPG library model was partially translated, the following message is displayed inthe model:

"BlackBox"or

"EDIT & place_cram" ...

Creating ATPG ModelsFinding Black Boxes with Vectored Outputs


Also, the following message is displayed above the model (unless it was completedblack boxed):

"PARTIALLY TRANSLATED MODULE"

Finding Black Boxes with Vectored OutputsThe LibComp tool leaves vectored outputs on black boxes undriven. These undriven outputsdefault to _tiex in ATPG runs. In some cases, partial models with only some outputs blackboxed may result. Black boxes with vectored outputs are preceded with a “Blackboxed PO”message in the ATPG 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 ModelsReconciling System Verilog reg and Verilog Keyword Compiling Issues

November 2010

Reconciling System Verilog reg and VerilogKeyword Compiling Issues

You can encounter ModelSim compilation and loading errors with LibComp and lcVerifyoutput under the following conditions:

• System Verilog — Modules using reg as interconnect. LibComp does not supportSystem Verilog syntax or semantics except for using reg as interconnect, which the toolallows and handles correctly.

• Verilog — Source file contains Verilog reserved keywords, for example int or do.

You reconcile these either of these issues by using the -sv or -no_sv switch with one of thefollowing methods:

• The Set Verification command.

• The libcomp invocation.

• The lcverify invocation.

Accounting for Reserved Verilog KeywordsIf the Verilog source uses Verilog reserved words (for example, “int” or “do”), then ModelSimcan have compilation and loading errors. In this case, you must use the -no_sv switch soModelSim can compile and load.

Accounting for Reg and Wire for InterconnectIn normal Verilog, only a wire can be used for interconnect, but in System Verilog, either a wireor reg can be used. Often, ATPG library primitives are used in modules that also use reg asinterconnect.

In this case, the LibComp default is to use the -sv switch if -atpg_lib_prims are needed (theseoften use reg as interconnect) and the -no_sv switch otherwise, unless the you explicitly invokewith the -sv or -no_sv switch using one of the above three methods.

NoteIn the unlikely event that a reg is used for interconnect in Verilog libraries which do notcontain ATPG library primitives (for example, _MUX), then you must explicitly issue the-sv switch to allow ModelSim to compile and load.

Creating ATPG ModelsSupport for Verilog Parameter Overrides


Support for Verilog Parameter OverridesVerilog parameters are compile time definitions of constants that are typically used to define thewidth of the IO and internal variables. Parameter overrides allow users to widen or narrowhardware when instantiating their definition and are useful to prevent replicating functionalitywhere only the operand widths change.

LibComp now supports Verilog parameter overrides to widen and narrow operands. It creates amodule using the original module name, appended with the parameter name and override value,for each changed parameter. For example:

// Defining module with parameters

module ramcore_16x6 (wba, wa, din, ra, dout); parameter databits = 6;parameter addrbits = 4; parameter addrmax = (1<<addrbits) - 1; .... output [databits-1:0] dout; reg [databits-1:0] mymem [0:addrmax];...

// Instantiating module with overrides

module ram16x8( DO0, DO1, DO2, DO3, DO4, DO5, .. ramcore_16x6 #(8) u1 ( ...

This example re-defines the first parameter, databits, to be 8 rather than the originally defined 6;this causes the memory to be 8 bits wide rather than 6 bits. When LibComp translates ram16x8,it will define a model, mlc_ramcore_16x6__databits_6, whose name is created from theoriginal defining module name, with “mlc_” prepended to indicate this is a name LibCompgenerated (not found in the original Verilog), and with each changed parameter and its valueappended, as shown here:

model mlc_ramcore_16x6__databits_8 (wba, wa, din, ra, dout)( model_source = verilog_parameter_override; ...

LibComp outputs a model_source statement to indicate the model was created due to aparameter override. These type of models are not instantiated explicitly for verification becauseno corresponding Verilog module exists to verify against. However, it will be tested in situwhen the model ram16x8 is verified.

The following limitations exist for Verilog parameter overrides:

• Current support is for positional overrides only and not for Verilog-named overrides.

• Current support is limited to integers to widen hardware; it does not extend to otherconstant types such as overriding a $readmemb/h ROM initialization file or other uses ofoverrides.


Creating ATPG ModelsLibComp Command Summary

November 2010

LibComp Command SummaryThe following table contains a brief summary of the LibComp commands.


Command Description

Add Models Adds models from the currently loaded libraryinto the set of models for compilation.

Delete Models Removes a model from the current compilationset.

Dofile Executes the commands contained within thespecified file.

Exit Terminates the application session.

Help Displays the usage syntax for the specifiedcommand.

Report Models Reports the models that have been added but notdeleted.

Run Starts the compilation process.

Set Asynchronous Control_Logic Specifies whether output dominance logic is usedduring the translation of sequential UDP memorymodules.

Set Behavioral Processing Specifies whether the Verilog behavioral alwaysstatement and always block processing areprocessed.

Set BB Outputs Specifies whether LibComp drives each bit of abidi or output of a blackbox model from a _tiexgate or leaves those outputs as floating.

Set Dofile Abort Specifies whether the tool aborts or continuesdofile execution if an error condition is detected.

Set Empty_module Outputs Specifies whether LibComp leaves each bit of abidi or output of an empty module undriven(floating) or drives each bit from a _tiex gate.

Set Excessive Pull_delay Specifies a delay threshold for changing a weakdriver with excessive delay to either a _tiex or an_undefined ATPG library model.

Set Floating Net_type Specifies how LibComp translates floating nets.

Set Hold Check Specifies whether hold checks is performed.

Set Instance Portlist Specifies naming conventions used for moduleinstances.

Creating ATPG ModelsLibComp Command Descriptions


LibComp Command DescriptionsThis section describes each LibComp command in alphabetical order.

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.

Set MUX Nonconsensus_logic Specifies whether LibComp outputs logic thatprecisely matches the Verilog UDP for any muxthat does not have both consensus terms or,outputs _mux if either one or both consensusterms is missing from the UDP table.

Set System Mode Changes the tool mode.

Set Undefined Instance Specifies whether LibComp outputs an ATPGmodel or a black box when a Verilog instancereferences a module name for which there is nodefining module in the Verilog source.

Set Verification Specifies which tool is used for verification ordisables verification.

Set X_from_known Combinational_udp Specifies whether LibComp outputs an ATPGmodel or a black box for combinational UDPs thatoutput X from a known input combination.

System Passes the specified command to the operatingsystem for execution.

Write Library Writes the ATPG library format models to a file.


Command Description


Creating ATPG ModelsAdd Models

November 2010

Add ModelsScope: Setup mode

Prerequisites: The Verilog library that contains the cell model(s) that you want to add must beloaded.

Usage

ADD MOdels [model_name... | -ALl]

Description

Adds models from the currently loaded library into the set of models for compilation.

The Add Models 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 to add into the set of models forcompilation.

• -ALl

A switch that specifies to add all models from the currently loaded library into the set ofmodels for compilation.

Example

The following example adds all models from the loaded library into the set of models forcompilation.

add models -allset system mode translationrun

Related Commands

Delete ModelsReport Models

Run

Creating ATPG ModelsDelete Models


Delete ModelsScope: Setup mode

Usage

DELete MOdels [model_name... | -ALl]

Description

Removes one or more specified models or all models from the current 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.

Example

The following example adds all models from the currently loaded library and then deletes oneparticular model from that library.

add models -alldelete models ram8x4

Related Commands

Add ModelsReport Models

Run


Creating ATPG ModelsDofile

November 2010

DofileScope: All modes

Usage

DOFile filename

Description

Sequentially executes the commands contained in the specified file. This command is especiallyuseful to issue a series of commands. Rather than executing each command separately, you canplace them in a file and then execute them with the Dofile command. You can also placecomment lines in the file by starting the line with a double slash (//); lines preceded with adouble 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 an error is encountered due toany command, the Dofile command stops its execution and displays an error message. You canenable the Dofile command to continue regardless of errors with the Set Dofile Abortcommand.

The dofile your_tessent_software_tree/lib/tools/libcomp/libcomp.do.default can be copied andused as is or modified. For more information, see the “Finding Unsupported Constructs inPartial Models” topic in this manual.

Argument

• filename

A required string that specifies the name of the file that contains the commands to execute.

Example

The following example orderly executes all the commands from the command_file file:

dofile command_file

Related Command

Set Dofile Abort

Creating ATPG ModelsExit


ExitScope: All modes

Usage

EXIt

Description

Terminates the application session and returns to the operating system. Use this command forinteractive sessions and in dofiles.

Example

The following example quits the tool without saving the current compilation set.

add model -allset system mode translationrunexit


Creating ATPG ModelsHelp

November 2010

HelpScope: All modes

Usage

HELp [command_name]

Description

Displays the usage syntax for the specified command. The Help command provides quickaccess to either information about a specific command, to a list of commands beginning with atspecific key word, or to a list of all the commands.

Argument

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

Example

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 ModelsReport Models


Report ModelsScope: Setup mode

Prerequisites: The Verilog library that contains the cell model(s) that you want to add must beloaded.

Usage

ADD MOdels [model_name... | -ALl]

Description

Reports the models that have been added but not deleted; these models will be translated whenthe run command is issued.

Arguments

• model_name

A repeatable string that specifies the name of the model to add into the set of models forcompilation.

• -ALl

A switch that specifies to add all models from the currently loaded library into the set ofmodels for compilation.

Example

The following example adds all models from the loaded library into the set of models forcompilation.

add models -allset system mode translationrun

Related Commands

Add ModelsDelete Models

Run


Creating ATPG ModelsRun

November 2010

RunScope: Translation mode

Usage

RUN

Description

Starts the compilation process on all models currently in the compilation list. The list is createdusing the Add Models and Delete Models commands.

Example

The following example starts the compilation process on the models added to the compilationset.

Tessent_Tree_Path/bin/libcomp my_library.v -dofile -log my_log.log -repadd models -allset system mode translationrun

Related Commands

Add ModelsDelete Models

Creating ATPG ModelsSet Asynchronous Control_Logic


Set Asynchronous Control_LogicScope: Setup mode

Usage

SET ASynchronous Control_logic{-OUTput_dominance_logic | -NO_OUTput_dominance_logic}

Description

Specifies 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, the LibComp tool 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.

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

Example

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

November 2010

Tessent_Tree_Path/bin/libcomp my_library.v -dofile -log my_log.log -repadd model -allset asynchronous control_logic -NO_OUTput_dominance_logicset system mode translationrun

Related Commands

Run

Creating ATPG ModelsSet Behavioral Processing


Set Behavioral ProcessingScope: All modes

Usage

SET BEhavioral Processing ON | OFf

Description

Specifies whether or not the tool processes a Verilog behavioral always statement always blockprocessing, and black box modules containing such blocks.

Arguments

• ON

A required literal that translates simple memories, DFFs, latches, muxes, and TSDs impliedby simple behavioral constructs.

• OFf

A required literal that black boxes any module containing an always block, and skips anyattempt at translating code within those blocks. This is the default.

Example

The following example instructs the tool to not process any Verilog always block.

set behavioral processing off

Related Commands

Run


Creating ATPG ModelsSet BB Outputs

November 2010

Set BB OutputsScope: All modes

Usage

SET BB Outputs [ -Tiex | -Float ]

Description

Specifies whether LibComp drives each bit of a bidi or output of a blackbox model from a _tiexgate or leaves those outputs as floating.

Arguments

• -Tiex

An optional literal that specifies that each bidi or output bit of a blackboxed model is to bedriven from a _tiex gate and comments are placed in the blackbox model identifying it as ablack box.

• -Float

An optional literal that specifies that each bidi or output bit of a blackboxed model is to beleft undriven (floating).

Example

The following example instructs the tool to leave blackbox output or bidi floating.

set bb outputs -float

Related Topics

Set Empty_module Outputs

Creating ATPG ModelsSet Dofile Abort


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.

• OFF

A required switch that forces dofile processing to complete all commands in a dofileregardless of error detection.

Example

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 Empty_module Outputs

November 2010

Set Empty_module OutputsScope: All modes

Usage

SET EMpty_module Outputs [ -Float | -Tiex ]

Description

Specifies whether LibComp leaves each bit of a bidi or output of an empty module undriven(floating) or drives each bit from a _tiex gate.

If you specify the -Float option, you can use the Setup Tied Signals command in the TessentTestKompress/Tessent FastScan dofile to simulate these pins as Z; this behavior mimicsVerilog. The default in Tessent TestKompress and Tessent FastScan is to _tiex undrivenbidis/outputs.

If you specify the -Tiex option, you cannot simulate these pins as Z in TessentTestKompress/Tessent FastScan; this can sometimes cause bus contention issues around IOpads.

The default behavior in LibComp is -Float which preserves the ability to match Verilogsimulation without modifying the ATPG library using the Setup Tied Signals command in theTK/FS dofile.

Arguments

• -Float

An optional literal that specifies that each bidi or output bit of an empty module is to be leftundriven (floating); comments are placed at the end of the module indicating that it camefrom an empty module and is not a blackbox resulting from a failed translation.

• -Tiex

An optional literal that specifies that each bidi or output bit of an empty module is to bedriven from a _tiex gate.

Example

The following example specifies that the bidi or output bits of empty modules are to be drivenfrom a _tiex gate.

set empty_module outputs -tiex

Related Topics

Set BB Outputs

Creating ATPG ModelsSet Excessive Pull_delay


Set Excessive Pull_delayScope: All modes

Usage

SET EXcessive Pull_delay delay_time

Description

Specifies a delay threshold for changing a weak driver with excessive delay to either a _tiex oran _undefined ATPG library model. This can prevent tester issues and simulation mismatchesfrom appearing when drivers with excessive delay exceed the simulation cycle.

By default, LibComp detects excessive switching delay for weak pull-up and pull-down driverson an integrated circuit’s input or bidirectional pads. Using the Set Excessive Pull_delaycommand, you can specify a delay threshold in time units (delay_time) for these weak drivers. Ifa driver’s delay is excessive (equal or greater than the threshold), then LibComp converts thedriver to one of the following ATPG library models:

• _tiex — If the driver has no inputs.

• _undefined — If the driver has inputs.

The default delay is 100 time units, which converts weak drivers having a delay equal to orexceeding 100 time units. If you set the delay_time to 0 (zero), then LibComp converts anyweak driver or net to drive weak X values rather than known values.

NoteIf you set delay_time to a large integer (for example, 1000000), ATPG obtains inputvalues from a weak driver instead of an I/O pad. This setting potentially cause simulationmismatches if the drivers delay exceeds the simulation cycle.

Argument

• delay_time

A optional non-negative integer specifying weak drivers’ excessive delay in time units. Thedefault is 100 time units.

Example

The following example sets the delay to 1000 time units.

set excessive pull_delay 1000


Creating ATPG ModelsSet Floating Net_type

November 2010

Set Floating Net_typeScope: All modes

Usage

SET FLoating Net_type [NONE | X | Z ]

Description

Specifies how LibComp translates floating nets.

By default, LibComp leaves floating nets floating to provide flexibility. The default for ATPGis to treat floating nets as driven by _tiex; you can use the Setup Tied Signals to change that to_tiez without editing the library. You may need to do this for some IO pad models to preventunsolvable bus contention issues for ATPG.

If this command is set to X or Z, floating nets without a driver are driven by/tied to X or Z,respectively, in the LibComp library output; these nets are not affected by the Setup TiedSignals command.

Arguments

• NONE

A literal that specifies to translate floating (undriven) nets literally, leaving them floating.

• X

A literal that specifies to create an explicit _tiex primitive to drive undriven model outputand inout pins.

• Z

A literal that specifies to create an explicit _tiez primitive to drive undriven model outputand inout pins.

Example

The following example ensures that each net has a _tiex driver if no others.

set floating net_type X

Related Topics

Setup Tied Signals

Creating ATPG ModelsSet Hold Check


Set Hold CheckScope: All modes

Usage

SET HOld Check ON [-fix_asynch_fails | -black_box_asynch] | OFf

Description

Specifies how sequential UDPs with hold check violations are translated.

Arguments

• ON

A literal that enables asynchronous hold checks. This is the default.

• -fix_asynch_fails

A switch that fixes models that fail asynchronous hold check. LibComp creates a model thatoutputs an X to match the verilog. The data ports are usable on such models. This switchonly fixes asynchronous hold check failures. This is the default.

• -black_box_asynch

A switch that outputs a black box for models that fail a hold check. Prevents simulationmismatches, but causes fault coverage problems if black boxes are used for ATPG.

• OFf

A literal that disables hold checks and outputs models that may cause simulationmismatches when an input changes in the Verilog. Hold fails are output in the transcript.

Set Hold Check Functionality

It is common that Verilog UDPs are erroneously specified in that the rows saying that the stateshould hold when some UDP input changes is omitted.

This is especially prevalent for asynchronous set and reset deasserting (going from set or resetto off, or the deasserted value). This is not how the hardware really works, but the UDP errormay cause simulation mismatches if the offending input changes during simulation. This isbecause the ATPG model will correctly hold the state, and disagree with the incorrect Verilogresult. For an asynchronous input, often it is tied off outside, and so the error cannot cause asimulation mismatch, but the potential is there if an ATPG library is created which assumes thatwill be the case.

There are three possibilities if the hold check occurs on a set or reset (an asynchronous input).

• Do not make such a hold check but instead create a simple model (what was intendedbut not defined properly by the Verilog) and hope for no mismatches. That isaccomplished by using Set Hold Check Off.

• A safer option, and the default, is to create a remodel that will allow the data port(s) towork but will go to X if the erroneously defined asynch is ever asserted. This will matchthe Verilog and mask its error if it occurs. This is accomplished by a fanout from the


Creating ATPG ModelsSet Hold Check

November 2010

offending asynchronous input to both the set and reset of the ATPG model, so that ifasserted, both set and reset of the ATPG model assert, and it goes to X.

• Clock or data input hold fails cause black boxed models unless Set Hold Check Off isissued. There is no reasonable way to protect the model in those cases, so only thesimple, dangerous model, or the black box options are available for UDPs where one ormore of those inputs fail to hold. Clocks must hold when deasserting with all otherclocks and any asynchs at their off (nonasserted / hold) values. Data must hold for bothchanges (rise or fall) when all clocks and asynchs are at their off (hold) value.

The best solution is to fix the Verilog UDP, which is simply wrong in almost all cases(especially for asynchronous fails).

Example 1

The following example black boxes asynchronous modules that fail hold check.

set hold check on -black_box_asynch

Example 2

The following example turns off hold checks.

set hold check off

Related Commands

Run

Creating ATPG ModelsSet Instance Portlist


Set Instance PortlistScope: Setup mode

Usage

SET INstance Portlist {-PIN_names [-EXclude_udp]} | -POSitional

Arguments

• -PIN_names

A required literal that specifies that pinname connections should be used for instances ofmodules and undefined instances. This is the default.

• -EXclude_udp

A required literal that specifies that instances whose definition is a Verilog UDP should notbe pinname, but positional. This is the default.

• -POSitional

A required literal that specifies that all instance portlists should be positional. This isbackward compatible with pre-v8.2009_2 releases.

Description

Specifies naming conventions used for module instances.

Prior to the v8.2009_2 release, LibComp and the ATPG library were restricted to positionalconnections in the portlist of an instance. For example:

instance = zt8binv i1 ( rden1, rden1_b ); // first instance

In the v8.2009_2 and all subsequent releases, ATPG library syntax is extended to includepinname connections. For example:

instance = zt8binv i1 ( .a(rden1), .o1(rden1_b) ); // second instance

For a defining model with port (pin) names as shown here, the first instance connects rden1 tothe first pin in the defining model's portlist; the second instance connects rden1 to the port (pin)named “a” in the defining model's portlist, regardless of its position:

model zt8binv (a, o1)

By default, LibComp uses pinname connections for instances whose definition is missing (inwhich case automatic verification must be set off due to incomplete input), and for anyinstantiation of a defined module.

Instances of primitives remain positional. Instances defined by a Verilog UDP default topositional connections when translated by LibComp. However, because UDPs become an entiremodel rather than a single primitive, pinname portlist connections are legal and supported forthose instances as well.


Creating ATPG ModelsSet Instance Portlist

November 2010

Example 1

The following example shows the default setting at the time of tool invocation.

set instance portlist -pin_names -exclude_udp

Example 2

The following example specifies to use pinnames on all instances of modules, includingUDPs.

set instance portlist -pin_names

Example 3

The following example specifies to use positional connections for all instances. Thisbehavior is consistent with the behavior of pre-2009_2 releases.

set instance portlist -positional

Related Topics

Creating ATPG ModelsSet Model Source


Set Model SourceScope: All modes

Usage

SET MOdel Source ON |OFf

Description

Specifies whether LibComp outputs the Model_source statement for every model created.

This source statement is useful to guide automatic verification to avoid flow issues whencompiling libraries in the Verilog simulator.

In releases prior to v8.2009_3, the Tessent TestKompress/Tessent FastScan library parsercannot read models containing the model_source statement. When you specify the -Off option,LibComp eliminates this statement from the ATPG models it created which allows thosemodels to be used by pre-v8.2009_3 versions of Tessent TestKompress/Tessent FastScan.

Arguments

• ON

A required literal that specifies that LibComp outputs the Model_source statement for everymodel created.

• OFf

A required literal that specifies that LibComp eliminates the Model_source statement forevery model created.

Example

The following example instructs LibComp to create models that can be read by pre-v8.2009_3versions of Tessent TestKompress/Tessent FastScan.

set model source off

Related Commands


Creating ATPG ModelsSet MUX Nonconsensus_logic

November 2010

Set MUX Nonconsensus_logicScope: All modes

Usage

SET MUX NONconsensus_logic {EXPLicit | NONE | ALL}

Description

Specifies the LibComp behavior that occurs when all, none, or one consensus terms are omittedfrom the UDP or, specifies to always outputs _mux irrespective of which consensus terms arepresent.

Arguments

• EXPLicit

A required literal that specifies that LibComp issues a warning and outputs _mux when bothconsensus terms are omitted from the UDP; in this case, LibComp assumes the user forgotto include them. If only one consensus term is present, LibComp assumes the user intends aone consensus term implementation and uses nonconsensus logic for the remodel. If bothconsensus terms are explicitly stated to produce X out of the 2-1 mux in the UDP,nonconsensus logic is used.

• NONE

A required literal that specifies to return to pre-v8.2009_4 behavior and always outputs_mux irrespective of which consensus terms are present. Nonconsensus logic is never usedfor any 2-1 mux remodel.

• ALL

A required literal that can be specified if the simplified _mux model causes mismatcheswhen select is X and both data are known and agree, or if the user intended to produce an Xin these cases but did not explicitly state that in the UDP.

Example

The following example instructs LibComp to return to pre-v8.2009_4 behavior.

SET MUX NONconsensus_logic NONE

Related Commands

Creating ATPG ModelsSet System Mode


Set System ModeScope: All modes

Usage

SET SYstem Mode Setup | Translation

Description

Specifies whether the tool enters the Setup or Translation mode.

Arguments

• Setup

A required literal that specifies to enter the Setup system mode from translation. By defaultthe LibComp tool 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 to enter the Translation mode from Setup mode. When you enterTranslation mode, the tool performs model checking for compilation.

Example

The following example puts the tool in Translation mode.

set system mode translation

Related Commands

Add ModelsRun


Creating ATPG ModelsSet Undefined Instance

November 2010

Set Undefined InstanceScope: All modes

Usage

SET UNdefined Instance [-ATpg_model | -BLack_box]

Arguments

• -ATpg_model

An optional literal that specifies to output an ATPG model using a _tsh (tri-state buffer)ATPG primitive when a Verilog instance references a module name for which there is nodefining module in the Verilog source. This is the default.

• -BLack_box

An optional literal that specifies to output a black box model when a Verilog instancereferences a module name for which there is no defining module in the Verilog source.

Description

Specifies whether LibComp outputs an ATPG model or a black box when a Verilog instancereferences a module name for which there is no defining module in the Verilog source.

By default, LibComp outputs an ATPG model. You can specify the -black_box option whichcauses the module to be blackboxed.

When undefined instances are encountered, LibComp sets verification to off(Set Verification -OFf) because ModelSim will fail to load an incompletely defined simulationmodel and, therefore, verification is not possible.

Example

The following example specifies to output undefined modules as blackboxes.

set undefined instance -blackbox

Related Topics

Creating ATPG ModelsSet Verification


Set VerificationScope: Setup mode

Usage

SET VErification {FASTscan | FLEXtest | TESTKompress | OFf} [-SV | -NO_SV]

Description

Specifies which tool is used for verification or disables the verification of a generated ATPGlibrary after the initial compilation. 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”.

• FASTscan

A required literal that sets Tessent FastScan as the verification tool. This is the default.

• FLEXtest

A required literal that sets FLEXtest as the verification tool.

• TESTKompress

A required literal that sets Tessent TestKompress as the verification tool.

• OFf

A required literal that disables verification during compilation runs.

• -SV

An optional switch that invokes ModelSim with System Verilog compilation for .v files.Required when a reg is used as interconnect (such as in a port list). See “Reconciling SystemVerilog reg and Verilog Keyword Compiling Issues” for complete information.

• -NO_SV

Prevents invoking ModelSim with -sv (System Verilog) for .v files. Required when the -svswitch causes compile errors due to modules containing reserved Verilog keywords. See“Reconciling System Verilog reg and Verilog Keyword Compiling Issues” for completeinformation.

Example

The following example disables verification during compilation runs.

set verification off

Related Commands

DofileRun


Creating ATPG ModelsSet X_from_known Combinational_udp

November 2010

Set X_from_known Combinational_udpScope: All modes

Usage

SET X_from_known Combinational_udp {atpg_model | black_box}

Description

Specifies whether LibComp outputs an ATPG model or a black box for combinational UDPsthat output X from a known input combination.

By default, LibComp outputs an ATPG model that uses a buffered tri-state (_tsh) ATPGprimitive with the following attributes:

• The model’s enable logic matches the UDP’s X rows.

• The model’s data input logic matches the UDP’s known (Boolean) rows.

You override this default behavior by specifying the black_box argument with this command.

Arguments

• atpg_model

An optional literal specifying the outputting of an ATPG model using a _tsh (tri-statebuffer) ATPG primitive for combinational UDPs that output X from some known inputcombinations. This is the default.

• black_box

An optional literal specifying the outputting of a black box model for combinational UDPsthat output X from some known input combinations.

Example

The following example defaults to outputting an ATPG model:

set x_from_known combinational_udp

Creating ATPG ModelsSystem


SystemScope: All modes

Usage

SYStem os_command

Description

Executes one operating system command without exiting the currently running application.

Argument

• os_command

A required string that specifies any legal operating system command.

Example

The following example displays the current working directory without exiting the tool:

system pwd


Creating ATPG ModelsWrite Library

November 2010

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 models created during compilation to a specified filename.

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.

Example

The following example compiles the models in the Verilog library vlib.v then saves thecompiled models to a file.

Tessent_Tree_Path/bin/libcomp vlib.v -dofile -log my_log.log -repadd model -allset system mode translationrunwrite library vlib.atpg -replace

Related Commands

Run

Creating ATPG ModelsUDP Limitations and Examples


UDP Limitations and ExamplesLibComp focuses primarily on the translation of User-Defined Primitives (UDP) and gate-levelcomponent descriptions, such as combinational/sequential UDPs and gate-level andswitch-level constructs.

2-1 Mux TranslationLibcomp translates a 2-1 multiplexor UDP into a _mux that has consensus terms in itssimulation. Note: If select is X but the data agree on what the output value should be, the outputbecomes that value. When a UDP has a single consensus term, LibComp assume a _mux shouldnot be used and outputs logic gates implementing a one consensus term mux. Also, when bothterms are missing, LibComp assumes this is an oversight of the user and outputs a _mux. Youcan explicitly state that the two consensus terms should output X in the UDP or you can use theSet MUX Nonconsensus_logic command to change this behavior.

UDP With Both Consensus TermsThis is a UDP for a mux which has both consensus terms. This model is highly recommended.

You can use an “X” rather than a “?” for the S input value for the last two consensus rows. Theyare functionally equivalent, but the “?” makes it clear that S is a DontCare when data agree.

primitive mux_both_consensus_udp‘protect(Y, S, A, B);output Y;input S, A, B;

table// S A B : Y ;// ------------------ 0 0 ? : 0 ; // Select A 0 1 ? : 1 ; // Select A 1 ? 0 : 0 ; // Select B 1 ? 1 : 1 ; // Select B ? 0 0 : 0 ; // consensus term (both data in are 0) ? 1 1 : 1 ; // consensus term (both data in are 1)

endtable`endprotectendprimitive

LibComp outputs the following for this UDP:

model model mux_both_consensus_udp (Y, S, A, B)( model_source = verilog_udp;



November 2010

input (S, A, B) ( ) output (Y) ( primitive = _mux mlc_gate0 (A, B, S, Y); ))

Partial Mux Examples - Missing Consensus TermsFollowing are examples and default solutions.

Case 1 - Mux Missing 11 Consensus Term

primitive mux_missing_11_consensus_udp (Y, S, A, B); output Y; input S, A, B;

table// S A B : Y ;// ------------------ 0 0 ? : 0 ; // Select A 0 1 ? : 1 ; // Select A 1 ? 0 : 0 ; // Select B 1 ? 1 : 1 ; // Select B ? 0 0 : 0 ; // consensus term (both data in are 0) // consensus term MISSING (both data in are 1)

endtableendprimitive

LibComp outputs the following for this UDP which has only the 00 consensus term:

model mux_missing_11_consensus_udp (Y, S, A, B)( model_source = verilog_udp; input (S, A, B) ( ) output (Y) ( primitive = _inv mlc_not_S_gate (S, mlc_not_S); primitive = _and mlc_D0_gate (A, mlc_not_S, mlc_D0_net); primitive = _and mlc_D1_gate (B, S, mlc_D1_net); primitive = _or mlc_out_gate (mlc_D0_net, mlc_D1_net, Y); ))



Case 2 - Mux Missing 00 Consensus Term

primitive mux_missing_00_consensus_udp (Y, S, A, B); output Y; input S, A, B;

table// S A B : Y ;// ------------------ 0 0 ? : 0 ; // Select A 0 1 ? : 1 ; // Select A 1 ? 0 : 0 ; // Select B 1 ? 1 : 1 ; // Select B ? 1 1 : 1 ; // consensus term (both data in are 1) // consensus term MISSING (both data in are 0)


LibComp outputs the following for this UDP which has only the 11 consensus term:

model mux_missing_00_consensus_udp (Y, S, A, B)( model_source = verilog_udp; input (S, A, B) ( ) output (Y) ( primitive = _inv mlc_not_S_gate (S, mlc_not_S); primitive = _or mlc_D0_gate (A, S, mlc_D0_net); primitive = _or mlc_D1_gate (B, mlc_not_S, mlc_D1_net); primitive = _and mlc_out_gate (mlc_D0_net, mlc_D1_net, Y); ))

Case 3 - Mux Missing Both Consensus Terms

primitive mux_missing_both_consensus_udp (Y, S, A, B); output Y; input S, A, B;

table// S A B : Y ;// ------------------ 0 0 ? : 0 ; // Select A 0 1 ? : 1 ; // Select A 1 ? 0 : 0 ; // Select B 1 ? 1 : 1 ; // Select B // BOTH consensus terms MISSING !!


LibComp outputs the following for this UDP which has neither consensus term:



November 2010

model mux_missing_both_consensus_udp (Y, S, A, B)( model_source = verilog_udp; input (S, A, B) ( ) output (Y) ( // Warning: UDP appears to implement _mux function, but is missing // consensus. Both terms missing, but not explicitly X in UDP, so // risking use of _mux remodel. primitive = _mux mlc_gate0 (A, B, S, Y); ))

Case 4 -- Mux With Explicit X Terms

primitive mux_both_consensus_explicitly_x_udp (Y, S, A, B); output Y; input S, A, B;

table// S A B : Y ;// ------------------ 0 0 ? : 0 ; // Select A 0 1 ? : 1 ; // Select A 1 ? 0 : 0 ; // Select B 1 ? 1 : 1 ; // Select B X 0 0 : X ; // 00 consensus => X X 1 1 : X ; // 11 consensus => X


LibComp translates the preceding UDP as follows:

model mux_both_consensus_explicitly_x_udp (Y, S, A, B)( model_source = verilog_udp; input (S, A, B) ( ) output (Y) ( primitive = _inv mlc_not_S_gate (S, mlc_not_S); primitive = _or mlc_anticonsensus_gate (S, mlc_not_S,

mlc_anticonsensus_net); primitive = _or mlc_D0_gate (A, S, mlc_D0_net); primitive = _or mlc_D1_gate (B, mlc_not_S, mlc_D1_net); primitive = _and mlc_out_gate (mlc_anticonsensus_net, mlc_D0_net,

mlc_D1_net, Y); ))

Mux Example With Consensus Terms//// 2-1 Multiplexor (single select line)//



// CAVEAT: This mux *never* creates Z out (converted to X out).// Otherwise, function is equivalent to : mux_out = select?d1:d0;// select==1 => mux_out=d1// select==0 => mux_out=d0// Both consensus terms (select==X, but known out if data agree).

module mux (mux_out, select, d1, d0); input d0, d1, select; output mux_out; mux_primitive _mux_inst (mux_out, select, d0, d1); endmodule

primitive mux_primitive (mux_out, select, d0, d1); input select, d0, d1; output mux_out;

table // sel d0 d1 : out 0 0 ? : 0 ; // Select==0 => out = d0. 0 1 ? : 1 ;

1 ? 0 : 0 ; // Select==1 => out = d1. 1 ? 1 : 1 ;

? 0 0 : 0 ; // 0-consensus term ? 1 1 : 1 ; // 1-consensus term

endtable

endprimitive

LibComp Limitation - Complex Asynchronous LogicComplex asynchronous set/reset logic is not supported. You use structural gates external to theUDP in Verilog.

The LibComp tool only handles simple buffered or inverted sets and resets. If a scan cell hasboth an asynchronous set and asynchronous reset, and also uses scan_enable to gate off set andreset during shift, the asynchronous logic for scan_enable should be specified outside the UDP,and a simple (inverted or buffered) set and reset input should be all of the asynchronous gatinglogic that is included in the UDP table describing the scan cell’s function. You should run theLibComp tool on all UDPs and check for any messages in <logfile_name> if invoked using“...libcomp... -log <logfile_name>”, or check the ATPG library output for the string“BlackBox”. In most cases, when LibComp encounters a UDP that cannot be translated, a blackbox model is output rather than a bad model.

Mux Scan DFF With Complex Asynchronous LogicCreate a Mux Scan DFF with Simple Asynchronous Logic using a UDP. (The followingexample uses Mux UDP and DFF UDP rather than one mux-scan UDP to show an alternative tothe earlier single UDP mux-scan DFF.) Then implement complex asynchronous logic outside of



November 2010

the UDP in a module, and connect structurally to an instantiation of the simple-asynchronousUDP placed inside the module.

Example - Mux Scan DFFThe latch has the same asynchronous limitation.

DFF with active high reset and active high set. Neither is dominant, so asserting both producesan X state value.

primitive dff_activeHI_set_and_reset( q, s, r, c, d ); input s, r, c, d; output q; reg q;

table// s r c d : q : q+;//------------------

1 0 ? ? : ? : 1 ; // Assert asynchronous Set. 0 1 ? ? : ? : 0 ; // Assert asynchronous Reset. 1 1 ? ? : ? : x ; // Assert both set and reset result Unknown.

0 ? r 0 : ? : 0 ; // Clock in a 0 from d (cannot assert set). ? 0 r 1 : ? : 1 ; // Clock in a 1 from d (cannot assert reset). 0 0 0 ? : ? : - ; // Hold when controls & clock off. ? ? ? * : ? : - ; // Hold when data changes. ? 0 ? 1 : 1 : 1 ; // When d=q, next state same whether clocked 0 ? ? 0 : 0 : 0 ; // or not clocked if controls consistent.


Example - Mux Scan Cell With Asynchronous Gated Off By ScanEnable

module mux_scan_dff_with_complex_asynch_logic ( q, clk, d, si, sen, rst_,set_ ); input clk, d, si, sen, rst_, set_; output q;

wire rst_net, set_net, d_net;

// Use Verilog nor primitives for complex asynchronous logic // outside UDP. This cannot be placed inside UDP that the LibComp // tool automatically translates (current limitation). // The complex gating is used to gate off the asynchronous set and // reset while scanning (sen = 1). Using DFF UDP with activeHI set // and reset, so NOR each activeLO asynchronious input with sen // to disable asynchs when scanning (even if asynch inputs asserted).

nor rst_nor (rst_net, sen, rst_); // Reset if rst_ asserted in // system mode (sen = 0).nor set_nor (set_net, sen, set_); // Set if set_ asserted in // system mode (sen = 0).

// Use mux UDP defined near beginning of this file. Creating a // structural mux-scan DFF.



mux_x_consensus_udp mux_scan_gate (d_net, sen, d, si); // select si when sen=1 (scanning).

// Use DFF UDP defined earlier in this file (with activeHI set and // reset). dff_activeHI_set_and_reset dff_gate (q, set_net, rst_net, clk, d_net);

endmodule

LibComp Limitation - Verilog Construct SupportThe LibComp tool supports only a subset of Verilog constructs. When unsupported constructsare encountered, the supported pieces of the module are made into a partial ATPG model. Youcan then locate and complete the model. For more information, see “Finding UnsupportedConstructs in Partial Models”.

Behavioral ConstructsThe LibComp tool does not support Verilog constructs with the following behavioralconstructs:

• Always blocks

• Case statements

• Tasks

• Functions

• Initial blocks

• Loops

Structural ConstructsThe LibComp tool does not support Verilog constructs with the following structural constructs:

• Parameters that are expressions (For example, expression “a & b” in the actualparameter of a port)

• Modules or primitives with undefined instances

• Non-Logical operation in the continuous assign statement

• Array, Vector, $<functions> and integer data structures/calls

• Non-Assign operations and real types in the continuous assign statement



November 2010

DFF Example//// DFF// ActiveHI set ActiveHI reset posedge clock//

module dff (q, set, reset, clock, data); input set, reset, clock, data; output q; dff_primitive dff_inst (q, set, reset, clock, data); endmodule

primitive dff_primitive ( q, set, reset, clock, data ); input set, reset,clock, data; output q; reg q;

table // s r c d : q : q+; //------------------------- (01) 0 ? ? : ? : 1 ; // Assert asynchronous Set. 1 (10) ? ? : ? : 1 ; // Set/Reset asserted then Reset deasserts. 0 (01) ? ? : ? : 0 ; // Assert asynchronous Reset. (10) 1 ? ? : ? : 0 ; // Set/Reset asserted then Set deasserts. (01) 1 ? ? : ? : x ; // Assert both set and reset. 1 (01) ? ? : ? : x ; // Assert both set and reset. (10) 0 ? ? : ? : - ; // Hold when deassert set, reset inactive. 0 (10) ? ? : ? : - ; // Hold when deassert reset, set inactive. 0 ? (01) 0 : ? : 0 ; // Clock in 0 (set must be known inactive).

? 0 (01) 1 : ? : 1 ; // Clock in 1 (reset must be known inactive). ? ? (10) ? : ? : - ; // Clock falling can never change state. ? 0 ? 1 : 1 : 1 ; // d=q=1, reset deasserted, q remains 1. 0 ? ? 0 : 0 : 0 ; // d=q=0, set deasserted, q remains 0. ? ? ? * : ? : - ; // Data changing can never change DFF state. endtableendprimitive

D Latch Example//// D Latch// ActiveHI set ActiveHI reset ActiveHI clock//

module dlat (q, set, reset, clock, data); input set, reset, clock, data; output q; dlat_primitive _dlat_inst (q, set, reset, clock, data); endmodule

primitive dlat_primitive ( q, set, reset, clock, data ); input set,reset, clock, data; output q; reg q;

table // s r c d : q : q+; //------------------------- 1 0 0 ? : ? : 1 ; // Assert asynchronous Set. 0 1 0 ? : ? : 0 ; // Assert asynchronous Reset. 1 1 ? ? : ? : x ; // Assert both asynchs result Unknown.

Creating ATPG ModelsI/O Pad Limitations and Examples


0 ? 1 0 : ? : 0 ; // Clock in 0 from d (cannot assert set). ? 0 1 1 : ? : 1 ; // Clock in 1 from d (cannot assert reset). ? 0 ? 1 : 1 : 1 ; // When d=q=1, next state 1 if not reset. 0 ? ? 0 : 0 : 0 ; // When d=q=0, next state 0 if not set. 0 0 0 ? : ? : - ; // Hold when all controls & clock inactive. endtableendprimitive

I/O Pad Limitations and ExamplesThis section describes how switch level modeling, bidirectional primitives, and strengthconstructs are handled.

Almost all I/O pads are built upon the following basic building block. In this section, the term“I/O pad” refers to all the parts, but the term “PAD” is often the name of the bidirectional pin onan I/O pad. In this manual, all caps “PAD” means the pin, and lower case “I/O pad” means theentire module.

Port list pin order can vary arbitrarily, but the pin functions assigned to input, inout, and outputare always the same for a basic I/O pad. When an I/O pad is embedded in hardware (called the“core”), the I/O pad can output data from the core to the outside world using a bidirectionalPAD pin. The data and the output enable controlling it are inputs to the I/O pad. If enabled, theI/O pad is in output mode, and the external world should be high impedance at PAD, so thatPAD becomes the value of data is output from the I/O pad.

An I/O pad inputs data (when embedded in a core) into the bidirectional PAD and on into thecore through a data output pin of the I/O pad model (there is usually a buffer in the path from thebidirectional PAD pin to this output pin).

Often, there are pulls, resistors, capacitors, etc. all modeled in Verilog. Scan testing is not usedto test that hardware (parametric testing is best for that), so a simple model that is adequate to doI/O is typically best for scan testing.

As a result, this basic I/O pad model is often best to use even for much more complex I/O pads,once such pads are tied off by being embedded, or “programmed”. If the model is to be verifiedusing the lcVerify tool (a subsidiary of LibComp), then additional pins which can cause pulls toactivate, and/or other non-modeled functionality to be exercised, should all be pin constrainedin the dofile to restrict the ATPG from accidentally random filling these pins. Unlessconstrained, the tool will not know that exercising the pins can cause false simulationmismatches, and will therefore result in false simulation mismatches. See Pin ConstraintsRequired for Verification for how to accomplish this.

Strength PropagationOften, there are inputs that indicate an external supply. These inputs are often named “E3V” or“E2_5V” etc. Typically, if powered ON, the simpler I/O pad illustrated below emerges (or atleast is more closely approximated), with one or more switches effectively becoming wires



November 2010

(always ON). During scan test, everything should be powered ON, and tests will fail otherwise,so a simpler “powered ON” remodel for scan test can simplify ATPG. However, if you aregoing to verify such simplified remodels, see the Pin Constraints Required for Verification. Ifpulls are modeled, this becomes critical, due to the lack of strength propagation in ATPG. Anytransistors between an output driver node with a weak pull and the PAD node must be removedin the remodel to allow the strong output driver and PAD to correctly cause bus contention iffighting, but for the weak signal to yield to them both unless they are Z. This can only be done ifall the fighting drivers and weak ones are one node (or a set of wired nodes). Any interveningtransistors can be problematic.

Also, input pins which indicate legal differential (or other operation modes) can exist. Suchinputs are often only used to cause X output values, and/or to cause messages from alwaysblocks. Typically, these should be tied off outside during test to the appropriate values toprevent spurious unwanted events and/or messages, so a simple remodel ignoring them can beappropriate. However, if you are going to verify such simplified remodels, constrain such pins(see the Add Pin Constraints Note).

Once processed for ATPG stand alone verification (not embedded in the netlist yet), the toplevel module's inputs becomes PIs, its outputs becomes POs, and its inouts (bidirectional pins)become split into a PI and PO half with the same (original Verilog) pin's name used for both.When embedded, usually only the bidirectional PAD pin reaches the top level netlist, and theother pins are connected to core logic or tied off to “program” the I/O pad.

Pin Constraints Required for VerificationTo verify the library, you must add pin constraints to any model input that must be other than 0for proper operation. The lcVerify tool ties PIs that go nowhere to LO (0) currently, so pinswhich must be tied to 1, Z, or X for the model to be valid need be constrained to that value in theATPG dofile.

During verification, pin “pin_name” on module “module_name” will be represented by a fakewrapper pin using the string “module_name__pin_name” (separated by TWO underscores). So,after running LibComp to get an ATPG dofile “fastscan.do.cat” in your local directory, you editthat and at the top add a line such as:

add pin constraint module_name__pin_name C1 // Constant 1 (HI)// pin constraint

The following will constrain pin “ENBI” of module (model) “TUD1ZE1000” to HI (1) for allATPG patterns, after being added to the ATPG dofile used for verification.

add pin constraint TUD1ZE1000__ENBI C1For more information, see the Add Pin Constraints command in the ATPG and FailureDiagnosis Reference Manual.



I/O Pad Code Examplemodule module_name ( data_out, output_enable, PAD, data_in );

// The data being output from the core to the PAD (outside world) thru // this I/O pad. input data_out;

// The output enable for the data. Enabled in output mode. Disabled in // input mode. input output_enable;

// The bidirectional pad where data goes in/out. inout PAD;

// The data being input to the core from the PAD (outside world). output data_in;

// Connect the output TriState Driver (TSD) directly to the // bidirectional pin. Do not include intervening wired ON MOS // switches, etc. from the more complex Verilog simulation model. // Also do not include weak pullup loops (buskeepers), or any // other programmable functionality. However, remember to pin // constrain any inputs enabling such pulls to OFF for the // lcVerify library verification if it is to be used. // Alternatively, alter the dofile to "Set External Z Handling X". // It is "Z" in the verification dofile, which allows it to produce // and measure Z values at PAD. // This is undesireable if the pulls can be enabled, so either // disable them, or have it convert Z's to X at PAD for measures // by changing the dofile command option. One prevents the pull // from happening, and the other predicts X (don't measure) // in cases where no strong driver is driving (and therefore the // unmodeled pull could cause a mismatch with the predicted Z from // an ATPG pattern's PAD PO value). // // Will assume activeHI output enable. If activeLO, use bufif0 // instead of bufif1.

bufif1 output_driver (PAD, data_out, output_enable);

// Buffer the PAD input from the external world.

buf input_buffer (data_in, PAD);

endmodule


Creating ATPG ModelsMemory Limitations and Examples

November 2010

Memory Limitations and ExamplesLibComp has the following memory limitations:

• Memories

• Verilog Constructs

• Arrays

• $readmemh and $readmemb

MemoriesLibComp only supports memories with vector addresses; that is, addresses with an address linebit that is greater than 1.

For example, the following notation is not supported:

reg 7:0 my_mem [0:0]; // A one-word memory - 1 bit address linereg 7:0 my_mem [0:1]; // A two-word memory - 1-bit address line

The following notation is supported if j and k are both greater than 0 AND a greater than 1difference exists between j and k:

reg <anything> my_mem [j:k];

Verilog ConstructsLibComp does not translate Verilog models containing tasks, functions, case statements, orloops. For example, if the Verilog model contains the following conditional loop:

if (address_is_not_all_known)for all words in memory

memory[addr] = all X (Unknown)

an error message is issued indicating the model is not translated and the model may be blackboxed. You should create a simple, but simulatable, Verilog description that does not check forincorrect operation and X out the memory. The model should only contain control logic andsimple always blocks for the read and write ports. Initialization requirements (such as ignoringthe first j clocks in a memory) should not be included in the models, but instead, specified in atest_setup procedure that pulses the appropriate clocks j times before starting the test.

Before remodeling Verilog behavioral models, use LibComp to experiment with a construct orform of description to ensure the expression form can be translated by LibComp.



ArraysLibComp only recognizes an array as a memory if its index (address) is at least two bits.Therefore, it will not translate a memory with a single address line.

$readmemh and $readmembLibComp translates files containing $readmemh and/or $readmemb if:

• The system call contains the filename in the module with memory.

• The memory has at least a read always block.

• $readmemh and $readmemb are in an initial block as a simple statement or a simple if-else construct.

The following ROM and RAM examples show Verilog source that can be translated byLibComp. Some of the examples also contain comments about memory limitations.

ROM Example`timescale 1ns / 1ns

module example_ROM (Q, CK ,CSN, A);

parameter Words = 768, Bits = 8, Addr = 10;

parameter InitFileName = "user_init_file.dat";

output [Bits-1 : 0] Q;input [Addr-1 : 0] A;input CK, CSN;

reg [Bits-1 : 0] Mem [Words-1 : 0];reg [Bits-1 : 0] Qreg;

// Note: InitFileName "user_init_file.dat" should be translated and// provided in ATPG format if ROM will contain such data during scan// test, and you wish to exploit that known data.// Otherwise, all internal ROM bits are Unknown (X).

initialbegin $readmemb(InitFileName, Mem, 0, Words-1);end

// ROM is simply a Ram with only a Read Port.always @ (posedge CK)



November 2010

begin

if (CSN == 1'b0) begin Qreg <= Mem[A]; end

end

// Outside CK control, so only _wire / assignment relation, not DFF// or LATch.assign Q = Qreg;

endmodule

RAM Examples

Single Posedge Ports With Separate Port Clocks//// Simple RAM with edge triggered read and write ports,// and common (shared) address inputs.//module ram1024x8 (wclk, rclk, a, din, dout);

parameter databits = 8; parameter addrbits = 10; parameter addrmax = (1<<addrbits) - 1;

input wclk, rclk; input [addrbits-1:0] a; input [databits-1:0] din ; output [databits-1:0] dout;

// Memory is declared as a reg. reg [databits-1:0] mymem [0:addrmax];

reg [databits-1:0] dout ;

// Edge triggered write port clocked by wclk. always @ (posedge wclk) mymem[a] <= din;

// Edge triggered read port clocked by rclk. always @ (posedge rclk) dout <= mymem[a];

endmodule



Single Level Ports With Write-Thru and Trisate Output Enable//// RAM with tristateable output.// Common address for read/write, level sensitive for both read and// write ports, active HI chip select CS, active HI output// enable OE, and active low write enable WEB.//// Note that an event is used to cause write-thru (writing to// some address while reading from it causes output to immediately// reflect new data written if the output is enabled).//module ram128x32 (DO, DI, A, WEB, OE, CS);


output [databits-1:0] DO; input [databits-1:0] DI; input [addrbits-1:0] A; input WEB, OE, CS;

reg [databits-1:0] memory [0:addrmax]; reg [databits-1:0] DO;

and u0 (OEN, CS, OE); and u1 (WEN, CS,!WEB);

event WRITE_OP;

// Write Port // Level sensitive, so could respond to Address, data, or // clock (strobe). always @ (WEN or A or DI) if (WEN) begin // Active HI write clock memory[A] = DI; #0; ->WRITE_OP; // Causes write-thru (in case output is enabled) end

// Read Port// Always read. Output can respond to output enable, data (if enabled), // or write-thru event (if enabled). // Output TSD (Tristate Drivers pass memory output if OEN is HI, else // output high impedance (Z). always @ (OEN or A or WRITE_OP) if (OEN) // Active HI output enable (TSD enabled HI). DO = memory[A]; else DO = 32'hZ;

endmodule



November 2010

Single Posedge Write Level Read Ports With Write-Thru//// Simple RAM with common address, activeLO level// sensitive read, posedge write.// R/W contention behavior of this example is new, in// other words, if write to address being read from,// it will write-thru to the outputs immediately.//module ram500x8 (wclk, ren, a, din, dout);

parameter databits = 8; parameter addrbits = 9; parameter addrmax = 499;

input wclk, ren; input [addrbits-1:0] a; input [databits-1:0] din ;

output [databits-1:0] dout; reg [databits-1:0] dout ;

reg [databits-1:0] mymem [0:addrmax];

event WRITE_OP; // Used to cause write-thru to always read port

// posedge triggered write port always @ (posedge wclk) begin mymem[a] = din; #0; ->WRITE_OP; // Cause always read port below to awaken. end

// level clocked read port, reads when "ren" LO. always @ (ren or a or WRITE_OP) if (!ren) dout = mymem[a] ;

endmodule

Single Posedge Ports With Separate Port Clocks//// Simple RAM with separate R/W address, separate posedge// read and write clocks.//

module ram256x4 (wclk, wa, din, rclk, ra, dout);


input wclk, rclk; input [addrbits-1:0] wa, ra; input [databits-1:0] din ;





// write when "wclk" rises. always @ (posedge wclk) mymem[wa] = din;

// read when "rclk" rises. always @ (posedge rclk) dout = mymem[ra] ;

endmodule

Single Level Ports With Separate Port Clocks//// LIMITATION:// Only simple variables supported inside always if (expression).// If logical combination of enabling signals required, create// a structural logic gate or separate continuous assign// expression, and use that as the enabling signal.// The following example uses a Verilog "and" gate to create such// a signal.//// Posedge write, enabled by single input.// Posedge read, enabled by AND of two inputs.// Separate read and write addresses.//

module ram48x4 ( CS, // Chip Select -- activeHI wclk, // Posedge Write CLocK wen, // Write Enable -- activeHI wa, // Write Address DI, // write Data In RCLK, // Posedge Read CLocK REN, // Read Enable -- activeHI RA, // Read Address DO // read Data Out );


input wclk, RCLK, wen, REN, CS; input [addrbits-1:0] wa, RA; input [databits-1:0] DI ;

output [databits-1:0] DO; reg [databits-1:0] DO;


// Write when "wclk" rises if Enabled. always @ (posedge wclk) if (wen) // Enable condition. mymem[wa] = DI;



November 2010

and u2 (read_en, CS, REN); // Enable read only if both CS and REN HI. // Read when "rclk" rises if Enabled always @ (posedge RCLK) if (read_en) // Enable condition.0- DO = mymem[RA];

endmodule

Single Posedge Ports With Write Enable//// Separated posedge read and write clocks, separate// read and write addresses.// ActiveHI write enable. No read enable.//module ram256x8 (wclk, wen, wa, din, rclk, ra, dout);


input wclk, wen, rclk; input [addrbits-1:0] wa, ra; input [databits-1:0] din ;



// Write when "wclk"rises if "wen" is HI (1). always @ (posedge wclk) if (wen) mymem[wa] = din;

// Read when "rclk" rises. always @ (posedge rclk) dout = mymem[ra] ;

endmodule

Single Level Ports With Single Read/Write Control and Bit-Blasted Wrapper

//// RAM that uses a core and a wrapper to accomplish// bit-blasted address and data pins.//

// The original Verilog uses vectors. Need single bit interface.// Can simply create bit blasted wrapper below.// It has a shared readHI/writeLO level clock wba, but an// independent read port address and write port address.//module ramcore_16x6 ( wba, // write when wba LO, read when HI.



wa, // write address din, // data in ra, // read address dout // data out );


input wba; input [addrbits-1:0] wa, ra; input [databits-1:0] din ;

output [databits-1:0] dout; // dout is an output register. reg [databits-1:0] dout;


// wba causes a level sensitive write when LO (0), always @ (wba or wa or din) if (!wba) mymem[wa] = din;

// wba causes a level sensitive read when HI (1). always @ (wba or ra) if (wba) dout = mymem[ra];

endmodule

// The bit-blasted wrapper.//module ram16x6( DO0, DO1, DO2, DO3, DO4, DO5, WA0, WA1, WA2, WA3, RA0, RA1, RA2, RA3, DI0, DI1, DI2, DI3, DI4, DI5, WBA); input WA0, WA1, WA2, WA3, RA0, RA1, RA2, RA3, DI0, DI1, DI2, DI3, DI4, DI5, WBA; output DO0, DO1, DO2, DO3, DO4, DO5;

// Unblast (Concatenate) I/O bits into vector in portlist of ram // instance. // Could also use wire declaration continuous assign concatenation, // then reference vector wire name in portlist. ramcore_16x6 u1 ( .wba(WBA), .wa( {WA3,WA2,WA1,WA0} ), .din( {DI5, DI4, DI3, DI2, DI1, DI0} ), .ra( {RA3, RA2, RA1, RA0} ), .dout( {DO5, DO4, DO3, DO2, DO1, DO0} ) );

endmodule



November 2010

Single Level Ports With Read_Off 1 Output and Tristate OutputEnable

//// RAM that outputs Z if output disabled,// outputs 1 if enabled but not reading,// and memory contents if enabled and reading.// Level sensitive write and read ports.//module ram64x128 ( wen, // Write ENable (clock). activeHI level. wa, // Write Address. din, // Data IN. ren, // Read ENable (clock). activeHI level. ra, // Read Address. dout, // Data OUT. Z, or 1, or a word. oe // Output Enable -- activeHI );


input wen, ren, oe; input [addrbits-1:0] wa, ra; input [databits-1:0] din ;

output [databits-1:0] dout; reg [databits-1:0] dout, dout_reg ;


event WRITE_OP;

// always @ (wen or wa or din) if (wen) begin mymem[wa] = din; #0; -> WRITE_OP; /* signal event */ end

always @ (ren or ra or WRITE_OP) if (ren) dout_reg = mymem[ra] ; else dout_reg = 128'hFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF;

// activeHI output enable always @ (oe or dout_reg) if (oe) dout = dout_reg; else dout = 128'bZ;

endmodule



Single Posedge Ports With Memory Bypass//// RAM with Data In to Data Out MUX bypass implied.// Shared posedge clock. Separate read and write addresses.// Separate activeHI read and write enables.//module bypass_RAM ( DO, // Data Out RA, // Read Address WA, // Write Address DI, // Data In WE, // Write Enable -- activeHI RE, // Read Enable -- activeHI CLK, // posedge shared clock BYPASS // If 1, output DI rather than memory word. );

output [15:0] DO; input [15:0] DI; input [3:0] RA,WA; input CLK, WE, RE, BYPASS;

reg [15:0] memory [0:15];

reg [15:0] DO_REG;

// Posedge clock with activeHI write enable. always @(posedge CLK) if (WE) memory[WA] = DI;

// Posedge clock with activeHI read enable. always @(posedge CLK) if (RE) DO_REG = memory[RA];

// 2-1 mux per data bit implied by following. assign DO = BYPASS ? DI : DO_REG ;

endmodule

Single Level Bidirectional Ports With Write-Thru and OutputEnable

//// Bidirectional data bus ram.// Dual Posedge read & write ports. ActiveHI chip port selects.// ActiveHI write enables (read enabled if LO).// ActiveHI output enables (oen_0, oen_1).//module bidi_dual_port_ram (clk, cs_0, cs_1, wen_0, wen_1, addr_0, addr_1, data_0, data_1, oen_0, oen_1);

// Warning: Do *not* change parameters in instantiations// (not supported). Only use them for convenience of



November 2010

// creating differing width modules. Create one module// per unique physical memory (if addr_size, data_size,// or mem_size differ), and reference the appropriate// module name in Verilog memory instantiations of any// memory module definition (such as this one).

parameter data_0_size = 8 ;parameter addr_size = 8 ;parameter mem_size = 1 << addr_size;

input clk, cs_0, cs_1, wen_0, wen_1, oen_0, oen_1;input [addr_size-1:0] addr_0 ;input [addr_size-1:0] addr_1 ;

inout [data_0_size-1:0] data_0 ;inout [data_0_size-1:0] data_1 ;

reg [data_0_size-1:0] data_0_out ;reg [data_0_size-1:0] data_1_out ;reg [data_0_size-1:0] mem [0:mem_size-1];

// Port 0 writealways @ (posedge clk) begin if ( cs_0 && wen_0 ) begin mem[addr_0] <= data_0; endend

// Port 1 writealways @ (posedge clk) begin if (cs_1 && wen_1) begin mem[addr_1] <= data_1; endend

// Port 0 Read.always @ (posedge clk) begin if (cs_0 && !wen_0 && oen_0) begin data_0_out <= mem[addr_0]; end else begin data_0_out <= 0; endend

// Port 1 Read.always @ (posedge clk) begin if (cs_1 && !wen_1 && oen_1) begin data_1_out <= mem[addr_1]; end else begin data_1_out <= 0; endend

// If in output mode, drive memory out, else highZ. Both ports.assign data_0 = (cs_0 && oen_0 && !wen_0) ? data_0_out : 8'bz; assigndata_1 = (cs_1 && oen_1 && !wen_1) ? data_1_out : 8'bz;

endmodule



Single Posedge Ports With Port and Per-Bit Write Enables andWrite_Thru

//// ActiveLO write enable per bit ram with write thru (single read/write// port).// Port enable reads when HI, enables write when LO.// Writes data bit whose corresponding (LS to MS) position in the// write enable per bit (web) is LO, else web bit is HI and word retains// pre-write value in that bit.// If bypass is 1,module enable_per_bit_write_thru (data_out, csb, clk, port_web, addr, data_in, web, bypass);

parameter bit_size = 8; parameter addr_size = 9; parameter mem_size = 1<<addr_size;

output [bit_size-1 : 0] data_out;

input csb, clk, port_web, bypass; input [addr_size-1 : 0] addr; input [bit_size-1 : 0] data_in;

input [bit_size-1 : 0] web;

reg [bit_size-1 : 0] Mem [mem_size-1 : 0]; reg [bit_size-1 : 0] data_outreg;

// Note that the read and write can be in separate ports. always @ (posedge clk) begin if (csb == 1'b0) begin if (bypass == 1'b0) begin if(port_web == 1'b1) begin data_outreg <= Mem[addr]; end else begin // Write only data_in bits where web is LO.

// In Verilog, the Hold is implemented by a read then writeback. Mem[addr] <= (Mem[addr] & web) | (data_in & ~web);

// Express write-thru by immediately repeating RHS expression. // Can also use "Mem[addr]" on right rather than expression. data_outreg <= (Mem[addr] & web) | (data_in & ~web); end end end end

// if bypass, data_out = data_in; else data_out = last value read orwritten. assign data_out = bypass ? data_in : data_outreg;

endmodule



November 2010

Dual Posedge Ports With Separate Clocks//// Ports 1, 2 Write Ports. Ports 3, 4 Read Ports.// Each with its own posedge clock and own address.//module ram64x12 ( w1, // Write clock for port 1 (posedge) a1, // Address for port 1 d1, // Data into port 1

w2, // Write clock for port 2 (posedge) a2, // Address for port 2 d2, // Data into port 2

r3, // Read clock for port 3 (posedge) a3, // Address for port 3 d3, // Data out from port 3

r4, // Read clock for port 4 (posedge) a4, // Address for port 4 d4 // Data out from port 4 );


input w1,w2,r3,r4; input [addrbits-1:0] a1, a2, a3, a4; input [databits-1:0] d1, d2 ;

output [databits-1:0] d3, d4; reg [databits-1:0] d3, d4 ;


always @ (posedge w1) mymem[a1] = d1;

always @ (posedge w2) mymem[a2] = d2;

always @ (posedge r3) d3 = mymem[a3] ;

always @ (posedge r4) d4 = mymem[a4] ;

endmodule

Dual Posedge Write Level Read Ports With Separate Clocks//// RAM with dual READ/WRITE ports. Posedge write, level// sensitive read. All 4 ports have their own// clock and address.



// If either Write Port writes to address being read// by a Read Port, write-thru new data to output// (uses event WRITE to do this).//module ram64x6 ( w1, // posedge Write clock for port 1. a1, // write Address for port 1 d1, // Data into port 1

w2, // posedge Write clock for port 2. a2, // write Address for port 2. d2, // Data into port 2

r3, // level sensitive Read clock for port 3. a3, // read Address for port 3 d3, // Datat out from port 3

r4, // level sensitive Read clock for port 4. a4, // read Address for port 4 d4 // Data out from port 4 );


input w1,w2,r3,r4; input [addrbits-1:0] a1, a2, a3, a4; input [databits-1:0] d1, d2 ;

output [databits-1:0] d3, d4; reg [databits-1:0] d3, d4 ;


event WRITE;

// Port 1 posedge Write port. always @ (posedge w1) begin mymem[a1] = d1; #0; ->WRITE; // Cause write-thru if appropriate. end

// Port 2 posedge Write port. always @ (posedge w2) begin mymem[a2] = d2; #0; ->WRITE; // Cause write-thru if appropriate end

// Port 3 level sensitive Read port. always @ (r3 or a3 or WRITE) if (r3) d3 = mymem[a3] ;

// Port 4 level sensitive Read port. always @ (r4 or a4 or WRITE) if (r4) d4 = mymem[a4] ;

endmodule



November 2010

Dual Posedge Write Level Read Ports With Separate Clocks andTristate Output Enable

//// Falling edge sensitive write ports, level sensitive// read ports, separate tristate output, Chip Select//module ram50x20 (w1,a1,d1, w2,a2,d2, r3,a3,d3,oe3, r4,a4,d4,oe4, cs);


input w1,w2,r3,oe3,r4,oe4, cs; input [databits-1:0] d1, d2; input [addrbits-1:0] a1, a2, a3, a4;

output [databits-1:0] d3, d4; reg [databits-1:0] d3, d3_reg, d4, d4_reg;

reg [databits-1:0] mymem [0:addrmax]; event WRITE;

/* internal control logic terms */

and u1 (readena1, cs, !r3); and u2 (readena2, cs, !r4); and u3 (outena1, cs, !oe3); and u4 (outena2, cs, !oe4);

/* write ports, edge sensitive active high */

always @(posedge w1) if (cs) begin mymem[a1] = d1; #0; ->WRITE; end always @(posedge w2) if (cs) begin mymem[a2] = d2; #0; ->WRITE; end

/* read ports, level sensitive */

always @(readena1 or a3 or WRITE) if (readena1) d3_reg = mymem[a3]; always @(readena2 or a4 or WRITE) if (readena2) d4_reg = mymem[a4];

/* output enables, qualified by chip select */

always @(outena1 or d3_reg) if (outena1) d3 = d3_reg; else d3 = 20'bZZZZ_ZZZZ_ZZZZ_ZZZZ_ZZZZ ; always @(outena2 or d4_reg) if (outena2) d4 = d4_reg; else d4 = 20'bZZZZ_ZZZZ_ZZZZ_ZZZZ_ZZZZ ;

endmodule



Dual Level Ports With Separate Clocks and Write-Thru//// RAM with non-default contention behavior//module ram252x7 (w1,a1,d1, w2,a2,d2, r3,a3,d3, r4,a4,d4);

parameter addrbits = 8; parameter addrmax = 251; parameter databits = 7;

input w1,w2,r3,r4; input [addrbits-1:0] a1, a2, a3, a4; input [databits-1:0] d1, d2;

output [databits-1:0] d3, d4; reg [databits-1:0] d3, d4;


event WRITE_OP;

// Level sensitive Write port 1 always @ (w1 or a1 or d1) if (w1) begin mymem[a1] = d1; #0; ->WRITE_OP; /* signal event */ end

// Level sensitive Write port 2 always @ (w2 or a2 or d2) if (w2) begin mymem[a2] = d2; #0; ->WRITE_OP; /* signal event */ end

// Level sensitive Read port 3 always @ (r3 or a3 or WRITE_OP) if (r3) d3 = mymem[a3] ;

// Level sensitive Read port 4 always @ (r4 or a4 or WRITE_OP) if (r4) d4 = mymem[a4] ;

endmodule

Dual Posedge Bidirectional Ports With Read_Off 0 and OutputEnable

//// Bidirectional data bus ram.// Asynchronous read and write.// If chip selected then :// if wen HI writes, else if oen HI reads.



November 2010

//

module bidi_ram (cs, wen, addr, data, oen);

// Warning: Do *not* change parameters in instantiations// (not supported). Only use them for convenience of// creating differing width modules. Create one module// per unique physical memory (if addr_size, data_size,// or mem_size differ), and reference the appropriate// module name in Verilog memory instantiations of any// memory module definition (such as this one).

parameter addr_size = 8 ;parameter data_size = 8 ;parameter mem_size = 1 << addr_size;

input cs, wen, oen;input [addr_size-1:0] addr;

inout [data_size-1:0] data ;

reg [data_size-1:0] data_out ;reg [data_size-1:0] mem [0:mem_size-1];

// The data being output from the core to the PAD (outside world) thru //Level sensitive write.always @ (addr or data or cs or wen)begin if ( cs && wen ) begin // if writing/input mode.. mem[addr] = data; endend

// Level sensitive read.always @ (addr or cs or wen or oen)begin if (cs && !wen && oen) begin // if output mode.. data_out = mem[addr]; endend

// If output mode, drive bidi data port, else shut off drivers.assign data = (cs && !wen && oen) ? data_out : 'bz; //

endmodule

Dual Posedge Separate Clocks Ports With Port and Per-Bit WriteEnables

//// ActiveLO write Enable per Bit ram. Dual read / Dual write.// Separate posedge port clocks. Port enables write LO/ read HI.// Write enable per bit (web) controls which bits written when// writing. Bits of word where web LO are written, else hold.

module dual_port_enable_per_bit_ram ( Dout_0, Dout_1, csn_0, csn_1,



ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1);


output [bit_size-1 : 0] Dout_0; output [bit_size-1 : 0] Dout_1;

input csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, bypass_0, bypass_1;

input [addr_size-1 : 0] A_0; input [addr_size-1 : 0] A_1;

input [bit_size-1 : 0] Din_0; input [bit_size-1 : 0] Din_1;

input [bit_size-1 : 0] web_0; input [bit_size-1 : 0] web_1;

reg [bit_size-1 : 0] Dout_0_reg; reg [bit_size-1 : 0] Dout_1_reg;

reg [bit_size-1 : 0] Mem [mem_size-1 : 0]; reg [bit_size-1 : 0] Qreg_0, Qreg_1;

// Note that the Dout_0_reg can be in a separate always block. // Also, the Port0 read and write can be in separate blocks. always @ (posedge ck_0) begin Dout_0_reg <= Qreg_0; // Always update port's out pipe. if (csn_0 == 1'b0) begin // ActiveLO chip select if (bypass_0 == 1'b0) begin // ActiveHI memory bypass. if(wen_0 == 1'b1) begin // ActiveHI port read enable. Qreg_0 <= Mem[A_0]; // Port 0 read. end else begin // ActiveLO port write enable. // web_0 has one activeLO enable bit per data bit. // Following writes Din if corresponding bit is LO, // else it holds old value (reads then writes back). Mem[A_0] <= (Mem[A_0] & web_0) | (Din_0 & ~web_0); end end end end // If bypass, Dout = Din, else Dout = piped/registered mem out. assign Dout_0 = (bypass_0) ? Din_0 : Dout_0_reg;

// Port 1 is exactly like above port 0. See comments above. always @ (posedge ck_1) begin Dout_1_reg <= Qreg_1; if (csn_1 == 1'b0) begin if (bypass_1 == 1'b0) begin if(wen_1 == 1'b1) begin Qreg_1 <= Mem[A_1];



November 2010

end else begin Mem[A_1] <= (Mem[A_1] & web_1) | (Din_1 & ~web_1); end end end end

assign Dout_1 = (bypass_1) ? Din_1 : Dout_1_reg;

endmodule

Using Positional Parameter Overrides to Modify Above RAM// Rather than create a different module for each different data and/or// word size of an otherwise identical RAM, positional overrides can be// used and are supported in LibComp. The following modifies the previous// write enable per bit RAM to be two different sizes than the original// defining module, but otherwise they operate identically due to reuse// of the same Verilog functionality.// Because there is no explicit defining model as required by ATPG, such// a model is created and referenced in the translation. This requires// uniquifying the original module name. The changed parameters and// their new value are used to create a unique module name for each// different size of module encountered due to parameter overrides.// Unchanged parameters are not used in the uniquification of the name.// CAVEAT: Only positional parameter overrides are supported. Named// parameter overrides remain unsupported at this time.

module dual_port_enable_per_bit_ram_128x72 (Dout_0, Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1);

parameter bit_size = 72; parameter addr_size = 7; parameter mem_size = 1<<addr_size; output [bit_size-1 : 0] Dout_0; output [bit_size-1 : 0] Dout_1;





// Note that positional overrides used to change size of ram instantiated.// Named parameter overrides are not supported.// Defining module is shown in prior example, and must have the number of// bits as the first parameter, and the number of words as the second.

dual_port_enable_per_bit_ram #(bit_size, addr_size) override_inst(Dout_0,



Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1);

endmodule

// LibComp output excerpt from above Verilog module showing name// uniquification, and redeclaration of array sizes.

model dual_port_enable_per_bit_ram_128x72 (Dout_0, Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1)( model_source = verilog_module; input (csn_0) ( ) input (csn_1) ( ) ... output (Dout_1) (array = 71 : 0; instance = mlc_dual_port_enable_per_bit_ram__bit_size_72_addr_size_7 override_inst (.Dout_0(Dout_0), .Dout_1(Dout_1), .csn_0(csn_0),

.csn_1(csn_1), .ck_0(ck_0), .ck_1(ck_1), .wen_0(wen_0), .wen_1(wen_1), .A_0(A_0), .A_1(A_1), .Din_0(Din_0), .Din_1(Din_1), .web_0(web_0), .web_1(web_1), .bypass_0(bypass_0), .bypass_1(bypass_1) ); ))

model mlc_dual_port_enable_per_bit_ram__bit_size_72_addr_size_7 (Dout_0, Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1)( model_source = verilog_parameter_override; intern (Qreg_0) (array = 71 : 0;)

... input (A_0) (array = 6 : 0;) input (A_1) (array = 6 : 0;) input (Din_0) (array = 71 : 0;) ... primitive = _cram Mem_0 ( , , ... primitive = _cram Mem_71 ( , , // Following write port will Hold in-memory data when not writing. _write { , , } (ck_1, mlc_and_5[71], A_1, Din_1[71]), // Following write port will Hold in-memory data when not writing. _write { , , } (ck_0, mlc_and_6[71], A_0, Din_0[71]), // Following read port will Hold output data after reading. _read { ,H,H,H} ( , ck_1, mlc_and_3, A_1, Qreg_1[71]), // Following read port will Hold output data after reading. _read { ,H,H,H} ( , ck_0, mlc_and_1, A_0, Qreg_0[71]) ); ))

// Same defining module as above but RAM is different size. If it had// been same override values (same size), then above ATPG remodel would// have been reused. Only one model created per unique set of parameters// of the defining module.

module dual_port_enable_per_bit_ram_32x8 ( Dout_0, Dout_1, csn_0, csn_1,



November 2010

ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1);


output [bit_size-1 : 0] Dout_0; output [bit_size-1 : 0] Dout_1;





// Note that positional overrides used to change size of ram instantiated.// Named parameter overrides are not supported.// Defining module is shown in prior example, and must have the number of// bits as the first parameter, and the number of words as the second.

dual_port_enable_per_bit_ram #(bit_size, addr_size) override_inst(Dout_0, Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1);

endmodule

// LibComp output excerpt from above Verilog module showing name// uniquification, and redeclaration of array sizes.// This is remodel of uses above uniquified model for ATPG purposes.

model dual_port_enable_per_bit_ram_32x8 (Dout_0, Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1)( model_source = verilog_module; input (csn_0) ( ) input (csn_1) ( ) ... output (Dout_1) (array = 7 : 0; instance = mlc_dual_port_enable_per_bit_ram__bit_size_8_addr_size_5 override_inst (.Dout_0(Dout_0), .Dout_1(Dout_1), .csn_0(csn_0), .csn_1(csn_1), .ck_0(ck_0), .ck_1(ck_1), .wen_0(wen_0), .wen_1(wen_1), .A_0(A_0), .A_1(A_1), .Din_0(Din_0), .Din_1(Din_1),

.web_0(web_0), .web_1(web_1), .bypass_0(bypass_0), .bypass_1(bypass_1)); ))

model mlc_dual_port_enable_per_bit_ram__bit_size_8_addr_size_5 (Dout_0, Dout_1, csn_0, csn_1,



ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1)( model_source = verilog_parameter_override; intern (Qreg_0) (array = 7 : 0;) intern (Dout_0_reg) (array = 7 : 0;) ... input (A_0) (array = 4 : 0;) input (A_1) (array = 4 : 0;) input (Din_0) (array = 7 : 0;) ... primitive = _cram Mem_0 ( , , ... primitive = _cram Mem_7 ( , , // Following write port will Hold in-memory data when not writing. _write { , , } (ck_1, mlc_and_5[7], A_1, Din_1[7]), // Following write port will Hold in-memory data when not writing. _write { , , } (ck_0, mlc_and_6[7], A_0, Din_0[7]), // Following read port will Hold output data after reading. _read { ,H,H,H} ( , ck_1, mlc_and_3, A_1, Qreg_1[7]), // Following read port will Hold output data after reading. _read { ,H,H,H} ( , ck_0, mlc_and_1, A_0, Qreg_0[7]) ); ))

Dual Posedge Separate Clocks Ports With Port and Per-ByteWrite Enables

//// ActiveLO write Enable per Byte ram. Dual read / Dual write.// Separate posedge port clocks. Port enables write LO/ read HI.// Write enable per byte (web) controls which bytes written when// writing. Bytes of word where corresponding web is LO are written,// while bytes whose web is HI hold previously written value.

module dual_port_enable_per_byte_ram ( Dout_0, Dout_1, csn_0, csn_1, ck_0, ck_1, wen_0, wen_1, A_0, A_1, Din_0, Din_1, web_0, web_1, bypass_0, bypass_1);

output [31 : 0] Dout_0; output [31 : 0] Dout_1;


input [9:0] A_0; input [9:0] A_1;

input [31:0] Din_0; input [31:0] Din_1;

input [3:0] web_0; input [3:0] web_1;



November 2010

reg [31:0] Dout_0_reg; reg [31:0] Dout_1_reg;

reg [31:0] Mem [1023 : 0]; reg [31:0] Qreg_0, Qreg_1;

// Expand to enable per bit, so can express writes as Boolean // equation below. Each web bit controls a byte (8 bits) of // data -- so replicate each 8 times to create enable per bit. wire [31:0] web_0_int = { {8{web_0[3]}}, {8{web_0[2]}}, {8{web_0[1]}},{8{web_0[0]}} }; wire [31:0] web_1_int = { {8{web_1[3]}}, {8{web_1[2]}}, {8{web_1[1]}},{8{web_1[0]}} };

// Note that the Dout_0_reg output pipe register can be in a separatealways block. // Also, the Port0 read and write can be in separate blocks. always @ (posedge ck_0) begin Dout_0_reg <= Qreg_0; // Always update port's out pipe. if (csn_0 == 1'b0) begin // ActiveLO chip select if (bypass_0 == 1'b0) begin // ActiveHI memory bypass. if(wen_0 == 1'b1) begin // ActiveHI port read enable. Qreg_0 <= Mem[A_0]; // Port 0 read. end else begin // ActiveLO port write enable. // web_0_int has one activeLO enable bit per data bit. // Following writes Din if corresponding bit is LO, // else it holds old value (reads then writes back). Mem[A_0] <= (Mem[A_0] & web_0_int) | (Din_0 & ~web_0_int); end end end end // If bypass, Dout = Din, else Dout = piped/registered mem out. assign Dout_0 = (bypass_0) ? Din_0 : Dout_0_reg;

// Port 1 is exactly like above port 0. See comments above. always @ (posedge ck_1) begin Dout_1_reg <= Qreg_1; if (csn_1 == 1'b0) begin if (bypass_1 == 1'b0) begin if(wen_1 == 1'b1) begin Qreg_1 <= Mem[A_1]; end else begin Mem[A_1] <= (Mem[A_1] & web_1_int) | (Din_1 & ~web_1_int); end end end end

assign Dout_1 = (bypass_1) ? Din_1 : Dout_1_reg;

endmodule


Chapter 6Verifying ATPG Models

This chapter describes how to verify ATPG libraries and provides a few guidelines to improvethe quality of your ATPG libraries. This chapter includes the following topics:

Verification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Specifying which Tool Performs Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Verification Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Running Verification from the Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Interpreting the Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Debugging Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

Re-simulating Verilog Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

Fixing DRC Violations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Improving Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Modeling for Optimal Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

Verification OverviewATPG library verification consists of simulating and testing the library models, and comparingthese models to the Verilog source modules to confirm parallel functionality. When thefunctionality does not match, the ATPG model fails verification, and the application returnssimulation mismatches for the failing model.

Tip: You should verify ATPG libraries when you generate the libraries with LibComp(see “Creating ATPG Models”), or when you manually edit or add new models to anexisting 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 using the following steps:

1. Uses Tessent FastScan to generate and simulate test patterns for the ATPG library.

2. Uses ModelSim® to simulate the Verilog source library using the same Tessent FastScantest patterns.


Verifying ATPG ModelsSpecifying which Tool Performs Verification

November 2010

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.

To ensure a robust ATPG library, you should correct all simulation mismatches and raise testcoverage to as close to 100% as possible.

Specifying which Tool Performs VerificationBy default, Tessent FastScan performs the verification. You can change which tool is used forverification using the following utilities:

• LibComp — To change the verification tool LibComp uses, use the Set Verificationcommand in LibComp to specify FlexTest or Tessent TestKompress.

• lcVerify — To use Tessent FastScan for verification, use the lcVerify command fromLinux/UNIX shell. You specify FlexTest or Tessent TestKompress during lcVerifyinvocation. Tessent FastScan is the default.

Verification Prerequisites• Verilog source library must be available.

• Tessent FastScan or other specified verification tool 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 ShellWhen running verification from a shell, you should reuse the same verification arguments thatLibComp uses when verifying a library. LibComp outputs how the tool invokes the verificationas a comment in the transcript/log_file and to stdout.

For example, if you invoked LibComp using the following syntax:

$Tessent_Tree_Path/bin/libcomp design_verify.v -dofile -log my_log.log \-replace

then LibComp outputs the following invocation line in the my_log.log log file:

// Verifying ATPG Library using Invocation :// $Tessent_Tree_Path/bin/lcVerify -no_scan_rams -no_atpg_prims// tessent.mtCellLib// design_verify.v

Verifying ATPG ModelsVerifying a Single Model in an ATPG Library


Verifying a Single Model in an ATPG LibraryBy default, the verification process validates all models in an ATPG library. In some cases, youmight want to verify only a single model, for example verifying a simplified view of a memorymodule using LibComp with internal hierarchical modules that do not match this simplifiedview.

You direct lcVerify to verify a single model in an ATPG library using the following invocationsyntax:

Tessent_Tree_Path/bin/lcVerify my_dft_library.atpg my_verilog_source.v \-model model_name

In the ATPG tool you invoke with the -model switch, you can also use the Report Statisticscommand’s -model switch to report the statistics for this single named model.

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 or the differences between the values Tessent FastScansimulated for the ATPG library and the values simulated for the original Veriloglibrary by ModelSim

o DRC violations

o Fault and test coverage

• sim.log — Full transcript of the Tessent 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.


Verifying ATPG ModelsInterpreting the Verification Results

November 2010

The following example shows the contents of a verify.results file.

Library Verification RunVerifying tessent.mtCellLibRun at Wed Oct 1 12:29:23 2008

The following 1 Models were Completely BlackBoxed: nonsense_model

---------------------------------------------------------Summary Statistics for Library tessent.mtCellLib-----------------------------------------Fault Statistics for Library tessent.mtCellLib----------------------------------------- #faults #faultsfault class (coll.) (total)----------------------- ------- -------FU (full) 22 22----------------------- ------- -------DS (det_simulation) 12 12DI (det_implication) 1 1PT (posdet_testable) 1 1UU (unused) 6 6AU (atpg_untestable) 2 2----------------------- ------- -------test_coverage 81.25% 81.25%fault_coverage 59.09% 59.09%atpg_effectiveness 95.45% 95.45%-------------------------------------------Test Pattern Statistics for Library tessent.mtCellLib-------------------------------------------#test_patterns 6 #clock_sequential_patterns 6#simulated_patterns 6---------------------------------------------------------

---------------------------------------------------------Model : almost_xor_dff_no_controls---------------------Fault Statistics for instance almost_xor_dff_no_controls-----------------------------------------

#faults #faults almost_xor_dff_no_controlsfault class (coll.) (total) almost_xor_dff_no_controls----------------------- ------- ------- almost_xor_dff_no_controlsFU (full) 6 6 almost_xor_dff_no_controls----------------------- ------- ------- almost_xor_dff_no_controlsDS (det_simulation) 5 5 almost_xor_dff_no_controlsPT (posdet_testable) 1 1 almost_xor_dff_no_controls----------------------- ------- ------- almost_xor_dff_no_controlstest_coverage 83.33% 83.33% almost_xor_dff_no_controlsfault_coverage 83.33% 83.33% almost_xor_dff_no_controlsatpg_effectiveness 83.33% 83.33% almost_xor_dff_no_controls---------------------------------------------- almost_xor_dff_no_controls

---------------------------------------------------------Model : nonsense_model---------------------

Verifying ATPG ModelsInterpreting the Verification Results


Fault Statistics for instance nonsense_model----------------------------------------- #faults #faults nonsense_modelfault class (coll.) (total) nonsense_model----------------------- ------- ------- nonsense_modelFU (full) 8 8 nonsense_model----------------------- ------- ------- nonsense_modelUU (unused) 6 6 nonsense_modelAU (atpg_untestable) 2 2 nonsense_model----------------------- ------- ------- nonsense_modeltest_coverage 0.00% 0.00% nonsense_modelfault_coverage 0.00% 0.00% nonsense_modelatpg_effectiveness 100.00% 100.00% nonsense_model------------------------------------------- nonsense_model

---------------------------------------------------------Model : xor_dff_no_controls---------------------Fault Statistics for instance xor_dff_no_controls----------------------------------------- #faults #faults xor_dff_no_controlsfault class (coll.) (total) xor_dff_no_controls----------------------- ------- ------- xor_dff_no_controlsFU (full) 8 8 xor_dff_no_controls----------------------- ------- ------- xor_dff_no_controlsDS (det_simulation) 7 7 xor_dff_no_controlsDI (det_implication) 1 1 xor_dff_no_controls----------------------- ------- ------- xor_dff_no_controlstest_coverage 100.00% 100.00% xor_dff_no_controlsfault_coverage 100.00% 100.00% xor_dff_no_controlsatpg_effectiveness 100.00% 100.00% xor_dff_no_controls------------------------------------------- xor_dff_no_controls

***** Fault (pessimistic) Coverage Summary by Decile *****See file fault_coverage_0_to_10_percent_models for a list of models in 0 to 10% decile, etc. for each nonNULL decile. 0% to 10% --- 1 models.80% to 90% --- 1 models.90% to 100% -- 1 models.------------------------------------------------------------------------------------------------------------------Verification Summary: 3 Total ModelsALL PASSED for all patterns.All known model output values predicted by ATPG agreed with Verilog sim.

In some cases, this only means ATPG could not exercise the model. See below.

Always check transcript for model translation messages.Always check the output ATPG library file with remodels for the strings: “BlackBox”, “EDIT & place _cram”, and “PARTIALLY TRANSLATED MODULE”.Always check sim.log for untestable Ram & DRC messages.Always check low coverage models to see if low coverage is expected (IO

pads may have 40% coverage and be good, whereas 85% may be bad for a muxscan model).


Verifying ATPG ModelsDebugging Models

November 2010

See the Fault Coverage Summary above these messages and associated filesfor the model names with low coverage. For model specific coverages,check the sim.log file. Look for “// *** FINAL COVERAGE STATISTICS ***”in sim.log to find overall coverage. Also shown beside “SummaryStatistics for Library”. in screen/transcript output. Module specific(-instance) reports follow overall.

The following 1 Models were Completely BlackBoxed:nonsense_model

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

Tessent FastScan is unable to read amodel.

Fix the model or comment it out.

Duplicate modules in the Veriloglibrary.

Eliminate the duplicates or change their names.

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.

Verifying ATPG ModelsRe-simulating Verilog Only


For more troubleshooting information, see the “Debugging Simulation Mismatches in TessentFastScan” 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 <Tessent_Tree_Path>/bin/ run_verify script. The run_verify scriptcontains the commands 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

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 must be run initially on the Verilog source and ATPG library. For moreinformation, see “Assessing the Impact of Low Coverage”.

• Verilog source library must be available.

• lcVerify must be run using the -save_vsim switch, even if LibComp has been run earlier.This is necessary to preserve the files needed for Verilog simulation. By default, thesesimulation files are not saved by LibComp in lcVerify runs.

Simulating Verilog OnlyThe LibComp and lcVerify scripts output the Tessent FastScan invocation line in the sim.logverification output file. You can cut and paste this invocation line and substitute the

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

November 2010

<mgc_dft_tree> with your Tessent_Tree_Path to reinvoke only the Verilog simulation portionof a verification run and analyze coverage only. You can find this invocation line in the sim.logafter the ATPG section and before the Verilog simulation section.

The following shows an example Verilog simulation invocation line from the sim.log:

# Note: Invoking vsim with :# vsim -novopt MGC_DFT_LIB_ALL_pat_v_ctl -t 1ns -c -do# “run -all; quit” +nospecify +nowarnTSCALE

When copying and pasting this invocation, ensure you omit the leading pound sign (#).

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 Tessent FastScan run including the DRCmessages. These messages usually include a DRC identification number.

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.

Improving Test CoverageTest coverage loss due to ineffective models may 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 your troubleshooting efforts onone model at a time.

Run Tessent FastScan on each model file in turn, using the same commands used in the earlierlcVerify run.

Verifying ATPG ModelsImproving Test Coverage


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.

Locating Low-Coverage ModelsAfter verification, you can find information concerning low-coverage models either at the endof the transcript or log, or the verify.results file in a Fault Coverage Summary. This summary isuseful to locate low-coverage models in large libraries without searching the sim.log filemanually.

The following is an example Fault Coverage Summary:

***** Fault (pessimistic) Coverage Summary by Decile ***** See file fault_coverage_0_to_10_percent_models for a list of models in 0 to 10% decile, etc. for each nonNULL decile. 0% to 10% --- 2 models.60% to 70% --- 1 models.70% to 80% --- 4 models.80% to 90% --- 20 models.90% to 100% -- 705 models.------------------------------------------------------------------------------------------------------------------

Additionally, at the end you can find a list of BlackBoxes, if any, which will explain some 0percent coverages as in the following example:

The following 2 Models were Completely BlackBoxed:mxsdprbs1qmxsdprbs2q

The tool also writes out files (one per listed decile in the Fault Coverage Summary) in theresults directory containing this information as in the following example:

fault_coverage_0_to_10_percent_modelsfault_coverage_80_to_90_percent_modelsfault_coverage_60_to_70_percent_modelsfault_coverage_90_to_100_percent_modelsfault_coverage_70_to_80_percent_models

Each file has a list of the modules/models within that coverage decile. The following exampleshows the contents for the fault_coverage_70_to_80_percent_models file:

List of all 4 models with this coverage decile.mxiao31x1a_UDPOBglatmxdprbsb1qbmxdprbsb2qb


Verifying ATPG ModelsModeling for Optimal Test Coverage

November 2010

Re-running the Tessent FastScan Portion of VerificationThe LibComp and lcVerify scripts output the Tessent FastScan invocation line at the top of thesim.log verification output file. You can cut and paste this invocation line and substitute the<mgc_dft_tree> with your Tessent_Tree_Path to reinvoke only the ATPG portion of averification run and analyze coverage only.

The following shows an example invocation line from the sim.log:

# Note: Invoking fastscan with :# <Tessent_Tree_Path>/bin/fastscan -dof fastscan.do.cat -lib# tessent.mtCellLib -load_warnings -sensitive -scan_rams -model all

When copying and pasting this invocation, ensure you omit the leading pound sign (#).

Modeling for Optimal Test CoverageTypically, you want the test coverage to be as a high as possible. Also, the ATPG library shouldnot 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 a ScanCell Model”.

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 7Test Procedure File

What is a Test Procedure File?Test procedure files are used to specify how the scan circuitry within a design operates. Thescan circuitry operation is specified using previously-defined scan clocks and other controlsignals. In order to utilize the scan circuitry in your design, you must define the scan circuitryand provide a test procedure file to describe its operation. The design rules checking (DRC)process, which occurs when you exit Setup mode, performs extensive checking to ensure thescan circuitry operates correctly.

When Do I Need to Create a Test Procedure File?You can use DFTAdvisor to insert scan circuitry and create the test procedure files for ATPGwith Tessent FastScan, FlexTest, and Tessent TestKompress. If your design already containsscan circuitry, you will need to create a test procedure file, either by hand or with DFTAdvisor.

The following subsections describe the syntax and rules of test procedure files, give examplesfor the various types of scan architectures, and outline the checking that determines whether thecircuitry is operating correctly.

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 timingand procedure data is merged.

You can also have the stil2mgc tool translate STIL Test Procedure (STP) files into TessentFastScan, FlexTest, and DFTAdvisor dofiles and test procedure files. This tool produces adofile, which defines clocks, scan chains, scan groups, and pin constraints. This tool also createstest procedure 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. The following syntaxconventions are used in this chapter:

• Bold — Indicates a keyword. Enter the keyword exactly as shown.


Test Procedure FileProcedure File Syntax

November 2010

• Italic — Indicates lexical elements such as identifiers, strings, or numbers. Replace theitalicized word with the appropriate name or integer.

• | — A vertical bar or pipe character indicates a logical “OR” as in “select foo ORfoo_not”.

• [ ] — Square brackets indicate optional elements. Do not include the brackets.

• … — An ellipsis indicates a repeatable item or set.

• “ ” — If you have a pin or pathname that uses a reserved punctuation character, youmust enclose that name in double quotes. See Table 7-1 for a list of reserved punctuationcharacters.

For example, the following statement is illegal because it uses the exclamation pointoutside 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 (!), soit must be enclosed inside double quotes. The correct syntax would be:

force "/inst_my_adder_1/xclk_header!x1!x1/op1[9]" 1

Throughout the following sections, value = 0, 1, X, or Z.

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



Using Tcl in the Procedure FileThe procedure file syntax supports Tcl conditional statements “if”, “else”, and “elseif” using thefollowing syntax:

if { tcl_expr } { procedure file statements}elseif { tcl_expr } { procedure file statements}else { procedure file statements}

Where a “tcl_expr” is any boolean Tcl expression that uses Tcl variables, dofile variables, orenvironment variables. Just as when doing variable substitution in the procedure file, other Tclstatements and defining Tcl variables are not supported. All variables must be defined in thedofile or from the shell as environment variables.

The body of these Tcl conditional statements should contain only legal procedure file syntax,not any other Tcl statements. The Tcl conditional statements are treated as preprocessorstatements in the procedure file parser. They are not preserved in the tool after parsing isfinished; only the procedure file code selected by the evaluation of the Tcl “if” expression isstored in the tool. Therefore, when using “write procfile” to write the procedure file out, none ofthe Tcl conditional statements are present, and the procedure file code not used is also notpresent. For more information on using Tcl, see “Using the Tessent Tcl Interface” in thismanual.

Introductory Procedure File ExampleThe following is an example of a simple test procedure file. For more complex examples, seethe “Procedure File Examples” section.

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



November 2010

period 4;end;

// The shift and load_unload procedures define how the design// must be configured to allow shifting data through the scan// chains. The procedures define the timeplate that will be// used and the scan group that it will reference.

procedure shift = scan_group grp1; timeplate tp1; cycle = force_sci; measure_sco; pulse CLK8_15; pulse CLK0_7; end;end;

procedure load_unload = scan_group grp1; timeplate tp1; cycle= force CLEAR 0; force CLK0_7 0; force CLK8_15 0; force scen1 1; end; apply shift 8;end;

// The capture procedure is a "non-scan" procedure. This// procedure describes the timeplate that will be used for the// capture cycle. It also defines the number of cycles that// will be used in the capture cycle. In this example there is// just one cycle.

procedure capture =timeplate tp1; cycle = force_pi; measure_po; pulse_capture_clock; end;end;

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 befollowed 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 statements define specific parameters used throughout the procedure file. The followingstatements are available:

• set time scale tscale;

Defines the time scale and unit. The set time scale statement must be at the beginning of theprocedure file, before any timeplate or procedure definition. If you do not specify the timescale, the default value is 1 ns.

The tool applies the time scale and unit to the test procedure file and timeplates. The tscaleyou specify can be any real number. Time values in the timeplate, however, must beintegers, representing whole time scale units. If you find you are specifying fractional timesin the 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 the timevalue to meet the scale as follows:

set time scale 10 ps ;set strobe_window time 1 ;

timeplate fast_clk_tp =



November 2010

force_pi 0 ; measure_po 50 ; pulse CLKA 75 150 ; pulse CLKB 75 150 ; period 300 ; end ;

The units supported are ms, us, ns, ps, and fs.

Tessent FastScan and Tessent TestKompress translate the time scale in the procedure fileinto a Verilog ’timescale directive in the Verilog testbench they write out when you savepatterns in Verilog format. If the time scale number you specify in the test procedure file isone or larger, 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 time precisionin the ’timescale directive will be adjusted to fit the true time scale. For example, “set timescale 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.

• set strobe_window time window_width;

Defines the strobe-window width. The set strobe_window time statement must be at thebeginning of the procedure file, before any timeplate or procedure definition. If you do notspecify the strobe_window time, it will default to the maximum allowable size. Forexample, if you look at a timeplate, and if there is a 10 ns window between the measure_poevent and the next event (or end of timeplate), then that is what the strobe window will be. Ifthere are multiple timeplates, then the smallest strobe window from the timeplates is themaximum allowable strobe window.

Some tester formats measure primary outputs (POs) at the exact time that you specify withthe measure_po statement in the timeplate. However, other tester formats, such as STIL,require that output measurements occur during a specified window of time (window_width).For WGL, this statement changes the strobe window in the output file.

A strobe window can only stretch from the measure_po time to the end of the cycle or thenext force or pulse event. For example, if you issue a measure_po at time 10 and the risingedge of a pulse at time 30, the strobe window can only be a maximum of 20. Strobe_windowlets you know that, starting at the measure_po time, the primary output should be stable forthe time specified by the strobe window.

Note Strobe_window only affects the following formats: STIL, TSTL2, and WGL.



• set default_timeplate timeplate_name;

Specifies a timeplate that can be used for any procedure definition that does not explicitlyspecify a timeplate. The referenced timeplate_name must be defined prior to the SetDefault_timeplate statement in the procedure file.

• set autoforce off;

An optional statement that controls the behavior for automatically adding force events. Ifincluded, this statement must appear at the beginning of the procedure file, prior to anyprocedures.

By default (without this statement), if a constrained pin is not forced to the constrainedvalue in the test_setup procedure, a force event is automatically added to the first cycle ofthe test_setup procedure. If the test_setup procedure starts with a call to a sub-procedure,then the force event is added to the first cycle following the sub-procedure. If a force eventalready exists in the test_setup procedure for a constrained pin, then no additional forceevent will be added for that pin.

When you include the “set autoforce off” statement, if constrained pins are not forced toconstrained values in the test_setup procedure, the tool adds one cycle to the end of thetest_setup procedure and adds a force event to the new cycle for each constrained pin that isnot forced to the constrained value in the test_setup procedure.

Including the “set autoforce off” statement also prevents the tool from forcing clock pins to theinactive state at the beginning of the load_unload procedure.

The “set autoforce off;” statement also turns off auto forcing Z values on bidis in theload_unload procedure—see Load_Unload (Required).

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.

NoteWhen saving STIL2005, CTL, or Structural_STIL patterns with Tessent FastScan,FlexTest, or Tessent TestKompress, all aliases defined in the procedure file will bedefined as SignalGroups in the resulting STIL file.

There is a pre-defined alias available for specifying all bidirectional pins. The “_ALL_BIDI”keyword may be useful for forcing all bidirectional pins to a specified value without having toidentify each individual pin. For example:

force _ALL_BIDI Z;



November 2010

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 specified using an alias name, and if the second condition is specified without usingan Alias statement.

Tip: When using multiple named capture procedures where each procedure requiresmany condition 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_name

A string that specifies the name of the alias.

• pin_name

A repeatable string that specifies the pin name to associate with the alias name.

• cell_name

A repeatable string that specifies the cell name to associate with the alias name.

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 Verilog, WGL, and STIL supported formats, the waveform tablesin these formats will be written using the equations and variables, and the variables will bedefined in the appropriate definition blocks which exist in each format. When saving patterns in



November 2010

formats that don’t support equation-based timing, the equations will be computed and thetiming information will be specified as the resulting numeric values in the pattern file. Settingthe ALL_FLATTEN_TIMING parameter file keyword to 1 will cause Verilog, WGL, and STILoutputs to compute the timing equations and use only the resulting numeric values in the outputfiles. Any equation that does not compute to an integer value will be rounded to the nearestinteger 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.

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.

Example

The 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



November 2010

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. All clocks must be defined in the timeplatedefinition.The timeplate definition has the following format:

timeplate timeplate_name =timeplate_statement[timeplate_statement ...]period time;end;

The following list contains available timeplate_statement statements. The timeplate 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;force_pi time;bidi_force_pi time;measure_po time;bidi_measure_po time;force pin_name time;measure pin_name time;pulse pin_name time width [, time width];

NoteIn “timeplate_statement” definitions, timing_variables can be used instead of time values.See the Timing Variables section for more information.

• timeplate_name

A string that specifies the name of the timeplate.

• offstate pin_name off_state

A literal and double string that specifies the inactive, off-state value (0 or 1) for a specificnamed primary input pin that will be pulsed within this timeplate but is not defined as aclock pin by the Add Clocks command. The complex timeplates are most useful in the shiftprocedure where a non-clock pin must be pulsed while still maintaining a single cycle in theshift procedure.

This statement must occur before all other timeplate_statement statements. This statement isrequired for any pin that is not defined as a clock pin by the Add Clocks command but willbe pulsed within this timeplate.



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 time

A literal and string pair that specifies the force time for all primary inputs.

• bidi_force_pi time

A literal and string pair that specifies the force time for all bidirectional pins. This statementallows the bi-directional pins to be forced after applying the tri-state control signal, so thesystem avoids bus contention. This statement overrides “force_pi” and “measure_po”.

• measure_po time

A literal and string pair that specifies the time at which the tool measures (or strobes) theprimary outputs.

• bidi_measure_po time

A 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 time

A 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 time

A 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 width [, time width]…

A literal, string, and repeatable integer set that specifies the pulse timing for a specificnamed pin.

pin_name — String that refers to a pin in the design. Valid pins must meet one of thefollowing conditions:

o Defined as a clock pin using the Add Clocks command.

o Not defined as a clock pin, but has a pulse signal and an offstate specified by the“offstate” statement.



November 2010

time — Integer that defines the offset from time 0 to the leading edge of the pulse.

width — Integer that defines the width of the pulse.

To define a multiple-pulse waveform, include multiple time and width pairs separated by acomma.

All pulses must occur within the tester cycle period. You define this period using the periodkeyword.

NoteMultiple pulses are only supported for the following output formats: Verilog, WGL,STIL, STIL2005, CTL, FJTDL, MITDL, and TSTL2. Additionally, the TSTL2 outputformat does not support more than two pulses.

For MITDL format there is restriction that multiple pulse timing must be a cyclicalrepetition of the first pulse. Consequently, multi-pulse and double-pulse timing in theprocedure file only works in the MITDL output without an error if the timing fits therestrictions of the MITDL syntax.

• period time

A literal and string pair that defines the period of a tester cycle. This statement ensures thatthe cycle contains sufficient time, after the last force event, for the circuit to stabilize. Thetime you specify should be greater than or equal to the final event time.

Example 1

timeplate tp1 =force_pi 0;pulse T 30 30;pulse R 30 30;measure_po 90;period 100;

end;

Example 2

The following example shows a shift procedure that pulses b_clk with an off-state value of 0.The timeplate tp_shift defines the off-state for pin b_clk. The b_clk pin is not declared as 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 3

In 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;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;

Always BlockThis optional block definition is used to specify events that happen in all cycles of allprocedures. Because the always block specifies events for all cycles, it will be used with alltimeplates and does not require a timeplate to be referenced in the block. Also, any signal that ispulsed in the always block must have a pulse waveform in all timeplate definitions.

If you defined any free-running clocks using the Add Clocks command, an always block isautomatically created in the procedure file, if one does not already exist, and a pulse statementadded for each clock. Similarly, if you pulse a clock signal in the always block, the signal isautomatically defined as a free-running clock. For more information, see “Add Clocks” in theATPG and Failure Diagnosis Tools Reference Manual.

NoteFree-running clocks are not automatically pulsed in a named capture procedure. Theclocks must be pulsed explicitly.

All events specified in the always block will be subject to rules checks that apply to eachprocedure. In other words, the events in the always block will be added to each cycle of eachprocedure, and all DRC rules still apply to these events.



November 2010

When saving patterns that preserve the structure of the procedures as macros (such as the CTLpattern file, or structural STIL pattern file), the events in the always block will be placed in thecycles of each procedure. The always block will not be present in the structural pattern file as amacro or procedure.

Always Block SyntaxThe always block has the following syntax.

always = always_statement ; [always_statement ; ... ]end ;

The always_statement is defined as one of the following.

pulse pin_name ;force pin_name value ;

Always Block ExampleThe following is a partial example of an always block.

set time scale 1,0 ns ;

timeplate tp1 = force_pi 0 ; measure_po 10 ;pulse ref_clk 20 20, 60 20 ;

pulse shift_clk 50 20 ; period 100 ;end ;always = pulse ref_clk ;end ;

procedure shift = timeplate tp1 ; cycle = force_sci ; measure_sco ; pulse shift_clk ; end ;end ;

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 ...]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;



November 2010

force pin_name value;expect pin_name value;condition cell_name value;measure pin_name;initialize instance_name [value];pulse pin_name;timeplate timeplate_name;annotate “quoted string”;

• procedure_type

A string that specifies the type of procedure that follows. The following list contains validprocedures types:

For more information, refer to “The Procedures” section.

• proc_name

An 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 that youdefine.

• scan_group scan_group_name

A literal and string pair that specifies a scan group within a scan procedure. Since some ofthe 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 on theAdd Scan Groups command for each scan group in this file. If you use the Read Procfilecommand to read a procedure file, you must include this statement. However, if you use theAdd Scan Groups command, this statement is optional since the group is specified on thecommand line. When the tool writes out a procedure file, it produces the scan_groupstatement.

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



NoteThe scan_group_name argument is case-sensitive if the netlist used is case-sensitive.

• timeplate timeplate_name

A literal and string pair that specifies the name of the timeplate the procedure uses.

A timeplate statement at the beginning of the procedure, outside of the cycle definitions, isthe 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.

• annotate “quoted string”;

A literal and string pair that reports the Verilog testbench annotations during simulation.

This keyword can be used to create the annotate statement that can occur in the beginning ofa cycle along with the cycle timeplate statement, before any event statements as follows:

CYCLE = [ TIMEPLATE tp_name ; ] [ ANNOTATE “quoted string” ; ] event_statement; …END ;

The annotate statement is optional and must always use a quoted string. All procedures canbe annotated, including sub procedures.

The following is an example of an annotate statement used in a test_setup procedure, andhow this will appear in a STIL pattern file.

Procedure test_setup =timeplate tp1;cycle =

annotate “first cycle in test_setup” ;force reset 1;force clock 0;

end;cycle =

annotate “next annotation” ;force reset 0;

end;…

This is a segment of the resulting STIL pattern file:

W tset_tp1;V { _pi_ = 0X11XXX;

_po_ = XXXX;}Ann {* Begin chain test *}Ann {* first cycle in test_setup *}V { …



November 2010

}Ann {* next annotation *}V { …}

• apply proc_name #times

A literal and double-argument string that tells the tool to apply the specified procedure thespecified 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 the applyshift procedure statement, and you must set the #times argument to 1. The apply statement isonly valid outside of the cycle blocks because it specifies another group of cycles withinanother procedure to be added at that point.

The following list describes valid cycle_statement commands. Cycle_statements may notcontain time values.

• force_pi

A literal that specifies for the tool to force all primary inputs.

• bidi_force_pi

A literal that specifies for the tool to force all bidirectional pins.

• force_sci

A literal that specifies for the tool, in the shift procedure, to place values on the scan chaininputs, thus implementing scan cell controllability.

• force_sci_equiv

A 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 on theassociated differential pin of a scan input during scan loading. This statement is necessarybecause the test procedures do not consider pin equivalence relationships (those specifiedwith Add Pin Equivalence).

• measure_po

A literal that specifies for the tool to measure or strobe the primary outputs.

• bidi_measure_po

A literal that specifies for the tool to measure or strobe the bidirectional pins.

• measure_sco

A literal that specifies for the tool, in the shift procedure, to measure scan output values,thus implementing scan cell observability. In End Measure Mode, see “Creating TestProcedure Files for End Measure Mode” on page 574, measure_sco is also used in theload_unload procedure.



• restore_pi

A 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_bidi

A 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_off

A literal that specifies for the tool to force all unconstrained bidirectional pins off.

• pulse_capture_clock

A literal that specifies for the tool to pulse the capture clock.

• pulse_read_clock

A literal that specifies for the tool to pulse the RAM read clock.

• pulse_write_clock

A literal that specifies for the tool to pulse the RAM write clock.

• force pin_name value

A 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 value

A literal and double string that causes the tool to expect the specified value of 0, 1, X, or Zon the specified pin. The pin names you specify must be valid pin pathnames for primaryoutputs.

• condition cell_name value

A literal and double string that you use at the beginning of a seq_transparent procedure toidentify the necessary scan cell states (conditions) to establish transparency in non-scancells. For more information on transparency, refer to “Tessent 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 pin tothe scan cell must only contain buffers and inverters. The value argument sets the value atthe specified pin pathname, which may be inverted relative to the associated scan cell value.

• measure pin_name

A literal and string pair that specifies for the tool to measure the value of the named pin.

• initialize instance_name value

A literal and string pair that initializes the named memory element to the value given. Thisstatement is particularly useful for initializing the finite state machine in the TAP controllerof boundary scan circuitry, when the TAP does not contain the TRST signal. Once set to abinary state, the TCK and TMS pins can place the finite state machine in a desired state. Ifnot set, these pins remain at X.



November 2010

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_name

A literal and string pair that specifies for the tool to pulse the named clock pin.

• observe_method value

A literal and string pair set to a value of master, slave, or shadow, to specify for a specificobserve 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;

Clock Control DefinitionThis section provides information for creating clock control definitions manually in the testprocedure file. For complete information on when you use this definition, see “Support forInternal Clock Control” in the Scan and ATPG Process Guide.

ATPG RestrictionsThe following restrictions apply to ATPG when clock control definitions are enabled:

• Clock_PO patterns are disabled.

• In undefined cycles, the internal clock is assumed to be off, even if the source clockpulses.

• Source clocks are pulsed regardless of clock restrictions. Any false paths should beexplicitly defined with DC or the Add False Paths command.

• External clocks without clock control definitions are controlled through top-level pins.

• Clock control definitions applied to a clock defined as equivalent also applies to allassociated equivalent clocks.

• Timeplate definitions only apply to external clocks.

• If you use the Set Clock Restriction -same_clocks_between_loads command, you mustuse one of the following definitions to pulse the controlled clock:



o {ATPG_SEQUENCE, END}

o {ATPG_SEQUENCE <N> <M>, END} with N starting from 0. The generated testpattern includes M+1 capture cycles between the scan loading operation and the scanunloading operation.

o <ATPG_CYCLE <i>, END} with i=0 defined

If none of these statements are present a warning displays during ATPG about clockcontrols that cannot be applied due to clock restrictions.

RulesThe following rules apply to the clock control definitions in the test procedure file:

• Global control conditions and source clocks defined for equivalent clocks must be thesame.

• When a clock is forced off, it cannot be used as a source in the same definition.

• A FORCE statement cannot force a clock pin to an on state.

• Clock control can not be applied to a free running clock.

• Condition statements cannot be applied to non-scan state elements.

• A condition to turn on the internal clock must be specified, otherwise it is assumed to beoff.

• When multiple sequence clock control definitions are defined for the same clock, theymust use mutually exclusive pulse conditions as follows:

o The clock control condition to pulse a clock in sequence mode must be mutuallyexclusive with the clock control condition for the same clock in per-cycle mode.

o The condition to pulse a clock in sequence mode must be mutually exclusive withthe condition to pulse the same clock by using another sequence mode.

Keywords• ATPG_CYCLE cycle_number

A literal and integer that specifies a test pattern capture cycle to map the clock control to.The specified capture cycle values start from 0, which corresponds to the first capture cycleafter scan loading.

Multiple ATPG_CYCLE definitions can be declared to pulse the internal clock at the samecapture cycle with different sets of conditions.

Use a FORCE statement to turn the clock off, or the clock continues to pulse when theconditions are satisfied.



November 2010

The specified and actual capture cycles may to differ—see “Capture Cycle Determination”in the Scan and ATPG Process Guide.

• ATPG_SEQUENCE N M

A literal and an integer with a value between N and M that specifies a set of capture cyclesfor clock pulsing.

Define the condition to pulse the clock continuously from capture cycle N (N>=0) tocapture cycle M (M>=N) right after scan loading. If N is greater than 0, the clock isautomatically set to off state from the first capture cycle right after scan loading to thecapture cycle N -1. When the generated test pattern includes more than M capture cyclesafter scan loading, the clock is set to off state from the M +1 capture cycle to the last capturecycle.

Multiple ATPG_SEQUENCE definitions can be declared as necessary.

Use a FORCE statement to turn the clock off, or the clock continues to pulse when theconditions are satisfied.


• CLOCK_CONTROL pin_pathname

A literal and string value that specifies the pin pathname of the PI for the internal clock. Thespecified pin must be an existing clock. Internal clocks must also be defined with the AddClocks -internal command.

• CONDITION cell_name value

A optional literal and double string that specifies necessary scan cell states (conditions). Thescan cell is specified by the pin pathname associated with the output of its state element. Thevalue argument specifies the value loaded into the scan cell at the end of shift.


• FORCE pin_pathname value

A literal and double string that forces a value of 0, 1, or Z on a specified pin. The specifiedpin names must be valid pin pathnames for primary inputs. This keyword is used to forcenecessary pins off during capture cycles when the controlled clock is pulsed.

• SOURCE_CLOCK pin_pathname...

A literal and repeatable string that specifies one or more source clocks to drive the internalclock logic to pulse in the specified capture cycle(s). If no source clock is specified, thesource clock is assumed to be a free running clock that pulses in every capture cycle.

• END

Required literal the specifies the end of an ATPG_CYCLE or ATPG_SEQUENCE block, orat the end of the clock control definition.



Global Variable UsageA global variable is a variable that is accessible in every scope of a clock control definition. Youcan use global variables to define default conditions within a clock control definition.

For example, you can specify a CONDITION for all ATPG_CYCLE/ATPG_SEQUENCEblocks within a definition. Then define a CONDITION within individualATPG_CYCLE/ATPG_SEQUENCE blocks to override the global CONDITION variable whennecessary.

The following example defines global conditions (bolded) that ensure a 0 value is loaded intothe control bits of scan cells F0-F3 by default and then uses local conditions (italicized) todefine the control bits necessary for each scan cell to pulse the clock.

CLOCK_CONTROL /clk_ctrl/int_clk1 =SOURCE_CLOCK ref_clk;

CONDITION /clk_ctrl/F0/q 0; CONDITION /clk_ctrl/F1/q 0; CONDITION /clk_ctrl/F2/q 0; CONDITION /clk_ctrl/F3/q 0; ATPG_CYCLE 0 =

CONDITION /clk_ctrl/F0/q 1; END; ATPG_CYCLE 1 =



CONDITION /clk_ctrl/F3/q 1; ENDEND;

Per-Cycle Clock Control Definition ExampleThe following example defines per-cycle clock control for two internal clocks (/top/core1/clk1and /top/core1/clk2):

CLOCK_CONTROL /top/core1/clk1 =ATPG_CYCLE 0 =

CONDITION /pll_ctl/cell_0/Q 1;END;ATPG_CYCLE 1 =

CONDITION /pll_ctl/cell_1/Q 1;CONDITION /pll_ctl/cell_4/Q 0;

//both conditions must be satisfied for clock to pulse in//capture cycle 1

END;END;CLOCK_CONTROL /top/core1/clk2 =

ATPG_CYCLE 0 =CONDITION /pll_ctl/cell_2/Q 1;



November 2010

END;ATPG_CYCLE 1 =

CONDITION /pll_ctl/cell_3/Q 1;CONDITION /pll_ctl/cell_4/Q 1;

END;END;

Sequence Clock Control Definition ExampleThe following example defines sequence clock control for two internal clocks (/top/core/clk1and /top/core1/clk2) derived from the source clock clk_src:

CLOCK_CONTROL /top/core1/clk1 =SOURCE_CLOCK clk_src;ATPG_SEQUENCE 0 1 =

//pulses 2 consectutive cycles if either of the scan cells//are loaded with 1, and the source clock is pulsed.

CONDITION /pll_ctl/cell_1/Q 1;END;

END;CLOCK_CONTROL /top/core1/clk2 =

SOURCE_CLOCK clk_src;ATPG_SEQUENCE 0 1 =

CONDITION /pll_ctl/cell_2/Q 1;END;

END;

The following example pulses clock /top/core1/clk1 unconditionally in every capture cyclebetween scan loading:

CLOCK_CONTROL /top/core1/clk1 =ATPG_SEQUENCE =

// empty bodyEND;

END;

The following example defines a multi-sequence clock control definition:

CLOCK_CONTROL /top/core/clk1_int =SOURCE_CLOCK /clk1;ATPG_SEQUENCE 0 2 =

CONDITION /pll/ctl_1/Q 1;FORCE ENABLE_1 1;

END;ATPG_SEQUENCE 3 4 =

CONDITION /pll/ctl_1/Q 0;FORCE ENABLE_1 1;

END;END;

Test Procedure FileThe Procedures


Exclusive conditions ensure that only one sequence block is applied per capture cycle(otherwise, no sequence is applied). If no cycle numbers are specified for sequence clockcontrol, the clock pulses in every capture cycle when conditions are loaded.

Source Clocks with Different Frequencies ExampleThe following example defines source clocks that have different frequencies when using clockcontrol definitions:

timeplate _default_WFT_ = force_pi 0 ; measure_po 40 ; pulse clk1 45 10; pulse ref_clock 15 5, 40 5, 65 5, 90 5; pulse clocks_02/my_controller/U2/Z 45 10; pulse clocks_03/my_controller/U2/Z 45 10; pulse clocks_04/my_controller/U2/Z 45 10; period 100 ; end;

procedure capture = timeplate _default_WFT_; cycle = force_pi ; measure_po ; pulse_capture_clock ; end; end;

In this example, for one pulse of clk1, there are 4 pulses of ref_clock, specifically the ref_clockfrequency is 4 times the frequency of clk1.

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, unlessotherwise stated:

timeplate tp1 =force_pi 0;measure_po 10;pulse scan_clk 30 10;pulse sys_clk 30 10;period 50;

end;

timeplate tp2 =force_pi 0;measure_po 10;pulse scan_mclk 15 10;pulse scan_sclk 30 10;period 50;

end;



November 2010

timeplate tp3 =force_pi 0;measure_po 10;pulse clk1 20 10;pulse clk2 20 10;period 40;

end;

NoteFor MBISTArchitect, the only supported procedures are the Test_Setup and Clock_Runprocedures.

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.

When reading in a test procedure file, the tool will now automatically add force events to thebeginning of the load_unload procedure to force all bidi pins to Z. Bidi pins that are clocks, orare constrained pins are not forced to a Z, as they were already forced to the off-state or theconstrained values. Bidi scan in pins are also not forced to a Z. Any bidi pin already forced laterin the load_unload procedure will not be forced to a Z. Any bidi forced to a specific value in thetest_setup procedure will instead be forced to this value instead of a Z.

• Test_Setup (Optional)• Shift (Required)• Alternate Shift Procedure (Optional)• Load_Unload (Required)• Shadow_Control (Optional)• Master_Observe (Sometimes Required)• Shadow_Observe (Optional)

• Seq_Transparent (Tessent FastScan andTessent TestKompress, Optional)

• Clock (Tessent FastScan and TessentTestKompress, Optional)

• Skew_Load (Optional)• Clock_Run (MBISTArchitect, Optional)



Like previous automatic force values, these can be disabled by putting the “set autoforce off;”statement at the beginning of the procedure file.

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

For MBISTArchitect, a test_setup procedure can force, expect, and/or pulse any necessarysignals during a test, which enables you to apply initialization cycles prior to any read or writeoperation, or configure a bidirectional port as an input/output port by controlling thebidirectional port enable signal(s).

Example 1

The following is an example using a sub_procedure. In this example the signal named C willretain its value of 1 during the test unless it is forced to a different value in a later cycle, byanother procedure, or it is overwritten by WGL patterns.

procedure sub_procedure initialize = template soc_timeplate ; cycle = force C 1; end;end;

The following example code shows how to apply the previous sub_procedure.

procedure test_setup = timeplate soc_timeplate; cycle = force test_en 1; // force test_en 1 force chip_en 0; // force chip_en to 0 end; apply initialize 10 ; // force C to 1 for 10 cyclesend;

For more information, see “Sub_procedure” on page 570.



November 2010

Example 2

The following example shows a way to apply initialization cycles to a memory. The RST signalis active for the first 128 cycles, then it is deactivated in the next cycle (cycle 129).

procedure sub_procedure reset_mem = timeplate soc_timeplate ; cycle = force RST 1; end;end;procedure test_setup = timeplate soc_timeplate; apply reset_mem 128; cycle = force RST 0; // deactivate RST end;end;

Example 3

The following example shows a way to use an expect statement in a test_setup procedure. Theoutput signal (DFT) is expected to 1 in the first cycle and X in the remaining cycle. Please notethat “expect” statements do not work the same as a force or pulse statement. When none ispresent, it is assumed to mean do not measure.

procedure test_setup = timeplate soc_timeplate; cycle = expect DFT 1 ; end;end;

Example 4

This example shows a way to start pulsing a clock in a test_setup procedure. The SYSCLKstarts pulsing at cycle number 2 until the end of test.

timeplate soc_timeplate = force pi; measure_po 90; pulse SYSCLK 50 50; period 100;end;

procedure test_setup = timeplate soc_timeplate; cycle = force RST_L 0; end; cycle = pulse SYSCLK; end;end;



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 7-1 shows thedata flow process for the shift procedure.

Figure 7-1. 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 procedure. The measure_sco will occur at the measure_po time specified in thetimeplate. The force_sci will occur one timescale unit after measure_sco, regardless of theforce_pi time in the timeplate.

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

ScanCellsc_in sc_out

data transfer



November 2010

end;end;

Figure 7-2 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 7-2. 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,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.

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



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 ;

Example

The 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;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;



November 2010

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.

Offstate for clock pins, constrained pin values, and other pins that have values forced in thetest_setup procedure are automatically added as force statements to the beginning of theload_unload procedure (if not present); this helps reduce DRC failures.

Figure 7-3 shows the data flow for the load_unload procedure.

Figure 7-3. Load_Unload Procedure

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.

ScanCell

sc_in ScanCell

ScanCell

sc_outScanCell

N N-1 N-2 0

Data shifts down N scan cells



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;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 7-4.



November 2010

Figure 7-4. 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 7-5 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 7-5. 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 7-6 shows the data flow for the master_observe procedure.

Figure 7-6. 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



November 2010

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 7-7 shows the data flow of the shadow_observeprocedure.

Figure 7-7. Shadow_Observe Procedure

Seq_Transparent (Tessent FastScan and Tessent 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. Tessent FastScan and Tessent TestKompress treatnon-scan state elements 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 group name; the tool would expect the specified testprocedure file to contain only the timeplate and seq_transparent procedure. Refer to the “AddScan Groups” command reference page in the ATPG and Failure Diagnosis Tools ReferenceManual for more details. Figure 7-8 shows some circuitry that could benefit from aseq_transparent procedure.

Figure 7-8. Sequential Transparent Circuitry Example

The following example shows the seq_transparent procedure for Figure 7-8.

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;

Flip-Scan ScanCell

FlopCell

Clock2

Clock1

Non-Scan



November 2010

The basic stimuli necessary to create transparent behavior for the non-scan flip-flop shown inFigure 7-8 are:

• Force all clocks off

• Pulse non-scan cell clock Clock2

• Restore primary inputs to original values

In more complex situations, you may need to set primary inputs to certain values, 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 (Tessent FastScan and Tessent 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 7-9 shows the data flow of theskew_load procedure.

Figure 7-9. Skew_Load Procedure

SlaveMaster

Shadow

sc_in sc_out


Skew_LoadData Transfer



November 2010

Figure 7-10 shows where you apply the skew_load procedure and the master_observeprocedure within the basic scan pattern events.

Figure 7-10. Skew_load applied within Pattern

Clock_Run (MBISTArchitect, Optional)For every controller, or concurrent controller group, you can write a clock_run procedure, ifneeded. The clock_run procedure has both an internal mode as well as an external mode.

You can specify only one clock_run procedure per controller or concurrent group; however, youdo not need to specify a separate procedure for each controller instance. The same procedurecan be used for multiple controllers. You need to specify a separate procedure for a controllerinstance only if it maps to a different set of internal clocks.

In case of controllers running concurrently, and some of these controllers clocks are driven byPLL internal clocks, the clock_run procedure is required per concurrent group. It is not requiredfor every BIST controller participating in the group to have its clock driven by a PLL internalclock. For some controllers, their clocks can be driven by a PLL reference clock or even by asystem clock.

The tool relies on you to control the PLL control signal. This can be achieved by forcing thePLL control signal to a proper value in a test_setup procedure and in external mode ofclock_run procedure as well (it depends on the PLL model behavior).

A clock_run procedure has to have a N-to-1 or 1-to-N ratio between internal and externalcycles; that is, either the internal mode has to have only one cycle, or the external mode has tohave only one cycle. You cannot have, for example, two external cycles and three internalcycles.

Example

In this example consider a PLL model which has two clocks: a reference clock and an internalclock. Based on the PLL control signal:

• The internal clock is 2X faster than the reference clock when PLL control is 0.

Basic Scan Pattern

Load scan chainsForce primary inputsMeasure primary outputsPulse capture clockUnload scan chains

Skew_loadAppliedHere

Master_observeAppliedHere



• The internal clock is 4X faster than the reference clock when PLL control is 1.

If you wanted a PLL internal clock to drive the BIST controller clock, use the followingMBISTArchitect commands in your BIST insertion dofile to define the clocks and make theproper connection.

add clocks 0 PLL/int_clkadd clocks 0 topPLLclkadd pin map /PLL/int_clk /controller/bist_clk

The PLL control is set to 0 using a test_setup procedure as follows:

procedure test_setup =timeplate soc_timeplate;

cycle = force PLL_Control 0 ;

pulse topPLLclk; end;end;

The following snippet has a clock_run procedure that describes the PLL model behaviorassuming that the PLL_Control is set to 0 as described in the previous test_setup procedure.

timeplate timeplate_internal =force_pi 0 ;measure_po 90 ;

pulse PLL/int_clk 5 50 ; // speed is 2Xperiod 100 ;

end ;timeplate timeplate_external =

force_pi 0 ;measure_po 180 ;pulse topPLLclk 5 100 ;period 200 ;

end ;procedure clock_run pll_clk=

mode internal =timeplate timeplate_internal ;

cycle =pulse PLL/int_clk ;

end ;cycle =

pulse PLL/int_clk ;end ;

end ;mode external =

timeplate timeplate_external ;cycle =

pulse topPLLclk ; // connected to reference clockend ;

end ;end ;



November 2010

Non-Scan ProceduresThe following sections describe non-scan procedures that can represent any type of pattern thatTessent FastScan produces.

Non-Scan Procedure FileYou can use the non-scan procedure file to specify in which cycles of the procedure “potentialevents” happen. A potential event is an event that the ATPG engine may or may not havecreated to cover a certain fault. Each non-scan procedure must contain the proper statements inthe correct order for that procedure with the timing from the timeplate, or there is a DRC ruleviolation. The statements in a non-scan procedure can be spread over any number of cyclesusing a different timeplate for each cycle if needed.

A basic Tessent FastScan pattern consists of loading the scan chains, a default captureprocedure, followed by unloading the scan chains; however, you do not specify the loading andunloading of scan chains in non-scan procedures. The following shows the basic pattern fornon-scan procedures.

Capture Procedures (Optional, Tessent FastScan and TessentTestKompress)

There are two types of capture procedures:

• The default capture procedure is an optional capture procedure, without a name, thatprovides information on how the series of capture events are broken into cycles andwhich timeplates these cycles use. The default capture procedure is defined in procfileas part of the scan group definition or internally derived by the tool when you do notdefine one. If you need to create or edit a default capture procedure, see “Rules forCreating and Editing a Default Capture Procedure” in this chapter.

• Capture Procedures (Optional, TessentFastScan and Tessent TestKompress)

• Clock_po (Optional, Tessent FastScan andTessent TestKompress)

• Ram_sequential (Optional, TessentFastScan and Tessent TestKompress)

• Ram_passthru (Optional, TessentFastScan and Tessent TestKompress)

• Clock_sequential (Optional, TessentFastScan and Tessent TestKompress)

• Init_force (Optional, Tessent FastScan andTessent TestKompress)

• Test_end (Optional, all ATPG tools)• Sequential (Optional, FlexTest Only)• Sub_procedure

Basic Pattern

Force primary inputsMeasure primary outputsPulse capture clock



• The named capture procedure is an optional capture procedure, with a name, that is usedto define explicit clock cycles. You can create multiple named capture procedures, eachwith a unique name, using the Create Capture Procedures command. If you need tomanually create or edit named capture procedures, see “Rules for Creating and EditingNamed Capture Procedures” in this chapter. For information on using named captureprocedures to create at-speed test patterns, see “At-Speed Test Using Named CaptureProcedures” in the Scan and ATPG Process Guide.

The sequence of events in capture procedures must pass DRC. DRC results influence the ATPGkernel and how the ATPG engine generates test patterns. The basic pattern for the captureprocedure is as follows:

Viewing Optimized Named Capture Procedures (NCPs)

Use this procedure when creating or debugging NCPs in order to view optimized informationfor an individual NCP. For more information on the optimizing process, see the Report CaptureProcedures command in the ATPG and Failure Diagnosis Tools Reference Manual.

Prerequisites

• DFTVisualizer is invoked. For more information, see “Opening DFTVisualizer”.

The Wave window is open and active. For more information, see “Wave Window”.

• At least one NCP is defined in the test procedure file.

Method

1. Choose Windows > Data to open the Data window.

2. Choose Windows > Wave window to open the Wave window.

3. Select the Data > Named Capture menu item and choose the NCP you want to view.

4. Click the icon to view the optimized NCPs; click the icon to return to viewingunoptimized NCPs.

Rules for Creating and Editing a Default Capture Procedure

• The default procedure may only contain force_pi, measure_po, pulse_capture_clock,bidir_force, bidi_force_pi, bidi_force_off, and bidi_measure_po event statements thatrepresent the non-scan activity for a normal pattern. There is no overlap between thecapture procedure and the existing clock procedure.

Capture Procedure Pattern

Force primary inputsMeasure primary outputsPulse capture clock



November 2010

• Use the pulse_capture_clock statement in the default capture procedure to indicate inwhich cycle one or more capture clocks should be pulsed.

• Do not specify any complex clocking that needs to be described for capture clocks orother clocks in the default capture procedure; specify it in the clock procedure or byusing a named capture procedure.

• Do not specify any type of pin or ATPG constraint in the default capture procedure. Forexample, specifying that a certain pin is to be held at a certain state in the default captureprocedure does not restrict the ATPG engine from applying different values to that pin.However, you can use the bidi_force and bidi_force_pi statements in the default captureprocedure to force all bidirectional pins off in one cycle and force the ATPG values onthe bidirectional pins in the next cycle.

Rules for Creating and Editing Named Capture Procedures

• A named capture procedure may only contain force_pi, measure_po, observe_method,pulse (named clock), and condition statements.

• If you use mode definitions, all cycles in a procedure must be defined within modedefinitions. Use the keyword “mode” with two mode blocks: “internal” and “external”.Use the mode_internal definition to describe what happens on the internal side of the on-chip PLL. Use the mode_external definition to describe what happens on the externalside of the on-chip PLL.

• All events in a named capture procedure that use modes must be duplicated in bothmodes. The only difference is that the internal mode uses only internal clocks and theexternal mode uses only external clocks. The number of cycles and timeplates used canbe different as long as the total period of both modes is the same.

• Signal events used in both internal and external modes must happen at the same time.Examples of these events are force_pi, measure_po, and other signal forces, but alsoinclude clocks that can be used in both modes.

o If a measure_po statement is used, it can only appear in the last cycle of the internalmode and must occur before the last clock pulse. If no measure_po statement is used,the tool issues a warning that the primary outputs is not be observed.

o The cumulative time from the start of the first cycle to the measure_po must be thesame in both modes.

o The external mode cannot pulse any internal clocks or force any internal controlsignals.

o A force_pi statement needs to appear in the first cycle of both modes and occurbefore the first pulse of a clock.

o If an external clock goes to the PLL and to other internal circuitry, a C2 DRCviolation is issued.



o At-speed cycles need to be continuous; that is, a named capture procedure cannothave more than one at-speed clocking sub-sequence.

o All defined real clocks (excluding internal clocks) must be forced to off state first inthe mode_internal definition.

For more information, see “Defining Internal and External Modes” in the Scan andATPG Process Guide.

• Do not use the pulse_capture_clock statement in a named capture procedure. The clocksused are explicitly pulsed.

• If you want to specify the internal conditions that need to be met at certain scan cells inorder to enable a clock sequence, use the condition statement at the beginning of thecycle statement in the named capture procedure.

• If you want to define a specific observe method for each named capture procedure, usethe observe_method statement in the named capture procedure; otherwise, the ATPGengine automatically selects master, slave, or shadow observation.

NoteThe Save Patterns command allows you to save internal or external clock patterns.Internal clock patterns can be used to simulate the DUT without having the PLL modeled,while the external patterns only exercise the PLL external clocks and control signals.Internal patterns are the default for ASCII and binary formats, and external patterns arethe default for tester formats.

• If 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 to read them back into the tool (for example, touse in diagnosis). For more information, see the description of the -Mode_internal and-Mode_external switches for the Save Patterns command in the ATPG and FailureDiagnosis Tools Reference Manual.

DRC rules W20 through W36 check named capture procedures. If a DRC error prevents use ofa capture procedure, the run aborts.

Example Named Capture Procedure

Following is an example of a 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;force pll_clk 0; //external clock must be forced to off state



November 2010

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;

Slow and Load Types

Optionally, you can add a “slow” or a “load” type to the cycle definition:

cycle [slow] [load] =...end;

• The slow cycle indicates that at-speed faults cannot be launched or captured. The toolmust know which at-speed cycles are slow in order to get accurate at-speed faultcoverage simulation numbers; therefore, be sure to include “slow” when defining cyclesthat 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 is always preceded by an extra scan load. Thefirst cycle in a named capture procedure is always a load (with or without the load typedesignation), so you typically apply “load” to subsequent cycles. An at-speed launchcycle can be a load cycle; however, none of the cycles that follow in the at-speedsequence, up to and including the capture cycle, can be load cycles.



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>”. For more information, see “Multiple Load Patterns” in theScan and ATPG Process Guide.

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

launch_capture_pair Statement

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 you do not use the launch_capture_pair statement, the tool will launchand capture only in adjacent cycles. If at least one launch and capture clock pair is defined, thelaunch and capture points are derived from the defined 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 as follows:

launch_capture_pair <launch_clock_pin_path_name><capture_clock_pin_path_name>;

Where:

launch_clock_pin_path_name is the clock used to launch the transition.

capture_clock_pin_path_name is the clock used to capture the transition.



November 2010

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

The following is an example of 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. A valid capture can happen in cycle 3only with c1 as the capture clock. A launch in cycle 1 and a capture in cycle 2 is not used forfault detection. The faults to be tested by this named capture procedure are the faults that can belaunched and captured by clock c1.

Example PLL Model and Named Capture Procedure

NoteFor MBISTArchitect, this capture procedure is called a clock_run procedure. For moreinformation, see “Clock_Run (MBISTArchitect, Optional)” on page 552.

The following is an example of a PLL model and named capture procedure. In this example,consider a PLL model that has two clocks: a reference clock and an internal clock. Based on thePLL 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 a named capture procedure that describes the PLL model behavior, assumingyour PLL control is 0 (for example, the internal clock speed 2X faster than the reference clock).

timeplate timeplate_internal = force_pi 0 ;

measure_po 40 ; pulse PLL/int_clk 5 25 ; // 2X

period 50;end;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, Tessent FastScan and TessentTestKompress)

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.



November 2010

The following shows the pattern for the clock_po procedure pattern.

Ram_sequential (Optional, Tessent FastScan and TessentTestKompress)

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.

The following illustrates the basic ram_sequential procedure pattern format.

Figure 7-11 shows an entire RAM sequential pattern, which illustrates where theram_sequential and capture procedures are used.

Clock_po Procedure Pattern

Force primary inputs (including clocks)Measure primary outputs

Ram_sequential Procedure Pattern

Force primary inputsPulse write clockand/or Pulse read clock



Figure 7-11. Full Ram Sequential Pattern

Ram_passthru (Optional, Tessent FastScan and TessentTestKompress)

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 Tessent FastScan pattern. Use thisprocedure instead of the capture procedure.

The following shows the ram_passthru procedure pattern.

Clock_sequential (Optional, Tessent FastScan and TessentTestKompress)

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.

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

Ram_passthru Procedure Pattern

Force primary inputsPulse write clock

Pulse capture clockMeasure primary outputsPulse read clock



November 2010

The following shows the clock_sequential procedure pattern.

Figure 7-12 shows an entire clock sequential pattern, which illustrates where theclock_sequential and capture procedures are used.

Figure 7-12. Full Clock Sequential Pattern

Init_force (Optional, Tessent FastScan and TessentTestKompress)

This optional procedure, which may only contain force_pi event statements, represents the forcecycle that is used in a Tessent FastScan or Tessent TestKompress pattern which targets atransition fault. The transition must be launched off of the last scan chain shift. This is usedwhen the fault type is set to transition fault and either the depth is set to 2 or less or the ATPGengines fail to find a sequential pattern that can cover this transition fault. Use this procedurewith the capture procedure.

The following illustrates the format of the init_force procedure pattern.

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 Procedure Pattern

Force primary inputs



Figure 7-13 shows the pattern which uses the init_force procedure.

Figure 7-13. Init_force Procedure Usage

Test_end (Optional, 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.

The following shows the general pattern for the 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;

Init_force Usage

Force primary inputs


init_forceprocedure

captureprocedure

Test_end Procedure Pattern

Force primary inputsPulse clocks



November 2010

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

... cycle = // Scan out signature (MISR has length of 4) force TDI 1; force TMS 0; pulse TCK; end; cycle = force TDI 1; force TMS 0; pulse TCK ; end;...end;

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;

Figure 7-14 illustrates the time frames and timing that correspond to Example 1.

Figure 7-14. Introductory Example with Scan Chains

The Set Test Cycle 2 command sets up two time frames. Figure 7-14 shows that all primaryinputs are forced in Timeframe 1. This is the default for pins. The pin constraint for CLK states

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



November 2010

that 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:

timeplate tp1 = force_pi 0; pulse LE 100 100; measure_po 280; period 300; end;

procedure sequential = timeplate tp1;end;



Figure 7-15 illustrates the timeframes and timing that correspond to Example 2.

Figure 7-15. 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:

procedure sequential = cycle = timeplate tp1; end; cycle = timeplate tp4; end;end;

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



November 2010

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.

procedure sub_procedure my_subprocedure =timeplate tp1;cycle =

force_pi;measure_po;

end;end;

Test Procedure FileProcedure File Examples


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.

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;


Test Procedure FileEnvironment Variables in Procedure Files

November 2010

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;force CLK_2 200;period 500;

end;

procedure sequential =cycle =

timeplate tp0;end;cycle =

timeplate tp1;end;

end;

Environment Variables in Procedure FilesYou can reference any environment variable and “dofile variable” in the procedure file. Forexample, if a dofile contains the following:

$MY_CLOCK = clock1add clock 0 $MY_CLOCK

Test Procedure FileMerging Procedure Files


where $MY_CLOCK is a dofile variable, you can extend the use of this variable to theprocedure file as shown in the following example:

timeplate tp1 =...pulse $MY_CLOCK 10 10...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, the tool checks to make sure that all proceduresand timeplates needed to save the patterns in the specified format are present.

If there are any missing non-scan procedures, default procedures are created and a warning isissued. For example, in cases where there were ram_sequential patterns that need to be savedand no ram_sequential procedure was supplied, a default procedure is created automatically.


Test Procedure FileCreating Test Procedure Files for End Measure Mode

November 2010

For any procedures that are created or that do not have a timeplate specified, the defaulttimeplate is mapped to these procedures, if it is set. You can set the default timeplate by usingthe set default_timeplate statement previously described in the “Set Statement” section. If youuse this statement, the timeplate specified when creating default procedures is used. If thedefault procedure needs to be created and no default timeplate has been set, then the firsttimeplate specified is used. If no timeplates are specified, a default timeplate is created as well.

Creating Test Procedure Files for End MeasureMode

Use this procedure to create test procedure files that enable end measure mode. End measuremode refers to the special handling that the Vector Interfaces code needs to move the measure tothe end of the shift and capture cycle.

Prerequisites

A test procedure file.

Procedure

1. Create a new timeplate that measures the outputs after the clock pulse.

2. Change the timeplate for the shift and load_unload to point to the new timeplate.

3. Add the measure_sco statement to the load_unload procedure.

4. Make sure all shift procedures have the measure_sco statement after the shift clock.When end measure mode is enabled, the measure_sco statement measures the next valuefrom the output of the scan chain. The very first value for the output of the scan chain ismeasured by a measure_sco statement in the load_unload procedure.

5. Change the timeplate for the capture cycle by breaking it into two cycles. Move thecapture clock to the second cycle of the capture procedure to allow the measure at theend. In the first cycle, the force_pi and measure_po are performed. In the second cycle,the capture clock is pulsed. When using end measure mode, a measure cannot beperformed after the capture clock.

Example

set time scale 1.000000 ns ;set strobe_window time 10 ; timeplate gen_tp1 = force_pi 0 ; measure_po 10 ; pulse clk 20 10; pulse edt_clock 20 10; pulse ramclk 20 10; period 40 ; end;

Test Procedure FileCreating Test Procedure Files for End Measure Mode


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

measure_sco; //<<=== NEW MEASURE STATEMENT end ; apply shift 39; end; procedure test_setup = timeplate gen_tp1 ; cycle = force edt_clock 0 ; end;end;


Test Procedure FileSerial Register Load and Unload for LogicBIST and ATPG

November 2010

Serial Register Load and Unload for LogicBISTand ATPG

This section describes using the test_setup or test_end test procedure file procedures to seriallyload or unload control registers in the circuit under test. Additionally, this section discusses thecommands you must add to your Tessent FastScan or Tessent TestKompress dofile to use thisfunctionality.

Serial register load and unload targets the following flows:

• Logic BIST — Used to serially unload certain registers (for example, MISRs) using thetest_end procedure.

• Low Pin Count Test — Used to serially load registers with test information through aserial access port such as a JTAG TAP controller.

Register Load and Unload Use ModelsUsing serial register load and unload allows you to identify a load/unload register variable valuein the test procedure file and define this variable, either static or dynamic, using commands inyour Tessent dofile.

By using this new functionality, you can load control registers by using a type of load procedurewhere the data value for the register can be passed as a string of values, and the load registeruses a shift mechanism to show how this string of data values is shifted into the register.

To serially load/unload register value variables, you must make modifications to your testprocedure file and your Tessent dofile.

• Test Procedure File

• Tessent Dofile

The register value variable is used in the test procedure file to load the value into a registerthrough the data input pin, or unload a value from a register through the data output pin. Theload/unload procedures support pin inversions, but you must explicitly specify this.

The registers to be loaded/unloaded can be cascaded such that one load or unload operationloads or unloads multiple values, for example PRPG/MISR values.

Static Versus Dynamic Register VariablesYou can define both static and dynamic register value variables.

• Static Variable — A specific register value variable string you specify during Setupmode. Once set, you cannot change this variable.



• Dynamic Variable — A register value variable string that you can define or change later,and can use tool-specific switches.

Static VariableA static register variable is one where the value is assigned to the variable when the variable isdefined (using the Add Register Value), and this value then cannot be changed. This static valueis used by DRC when simulating the procedures. A static variable cannot be set using toolspecific switches to link the variable to tool computed values, as these may change.

Dynamic VariableA dynamic register value variable uses tool-specific switches and arguments to link the variableto a value computed by the tool. If you use a dynamic variable, then you must specify theregister’s width unless the tool knows this value at the time DRC is run (for example, PRPGsize).

This method is used for defining a variable that has a tool-specific computed value that isavailable when patterns are saved and needs to be loaded or unloaded by the test_setup ortest_end procedures. The value defaults to all X bits, and you can specify the actual value cannon-Setup mode by using the Set Register Value command—see “Dynamically Setting aRegister Value Variable” for complete information.

If no value is specified the first time DRC is invoked after adding a register value variable, thetool considers the variable to be dynamic for DRC and any future invocation of DRC.

Test Procedure File ModificationsIn the test procedure file, the following new procedure and keyword are used:

• load_unload_registers Procedure

• shift Keyword

load_unload_registers ProcedureThe load_unload_registers procedure is a new type of procedure. The load_unload_registersprocedure is a named procedure; consequently, you can have multiple occurrences of thisprocedure, corresponding to multiple groups of registers that need to be loaded and/or unloaded.

The load_unload_registers procedure can only be called from the following procedures:

• test_setup

• test_end



November 2010

The load_unload_registers procedure can load, unload, or both. Additionally, one applicationof the procedure can load/unload multiple cascaded registers.

When the test procedure file explicitly calls the load_unload_registers procedure from eitherthe test_setup or test_end procedures, the values to load or unload are passed to the procedureusing the string of binary values (value hard-coded in the procedure application) or the registervalue variables.

shift KeywordA new shift keyword allows the shifting to happen within the new procedures without using a anew type of shift procedure. This is similar to the IEEE STIL syntax where the shift keyworddefines a shift block within a load or unload procedure. It is analogous to embedding the shiftprocedure into the load_unload procedure.

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

Test Procedure File SyntaxThe following illustrates using the new procedure and keyword:

procedure load_unload_registers procedure_name = ... [ cycle blocks ]shift =cycle blocks

end ; [ cycle blocks ]end ;

The load_unload_registers procedure must have a shift block defined, which has one or morecycles used to shift the data into the data input pin or the data out of the data output pin. Theprocedure can also optionally have cycles which precede or follow the shift block, to be used toput the circuit into shift mode or finish the shift mode when done, similar to how a load_unloadprocedure is used.

Event StatementsWithin a shift block, at least one event statements in a load_unload_registers procedure mustuse the new “#” character to denote where the shift data passed into the procedure is used.



The event statement must be either a “force” event or an “expect” event. An event statementwith the “#” character can also occur in the cycles preceding or following the “shift” block inorder to express pre-shifts and post-shifts for loading the register. This event statement has thefollowing syntax:

<force | expect > pin_or_alias_name # ;

The apply statement which is currently used to call shift and sub_procedure procedures andalso calls the load_unload_registers procedure. When calling these procedures, however, thenumber of times argument in the apply statement is replaced with one or more valueassignments to the data in and/or data out pins.

apply procedure_name [ #times | shift_data_assignment[ , shift_data_assignment ...] ] ;

A shift_data_assignment has the following syntax:

identifier = < value_string | register_value_variable >[<value_string | register_value_variable>...]

where identifier is either a pin name or an alias name.

The identifier used in the shift_data_assignment must match an identifier used within theprocedure in one of the new event statements with the “#” character.

Register Value StringsA register value string (value_string) is one of the following:

• A binary string of 0’s, 1’s or X’s, where the length of the string determines the numberof shifts to load the register.

• A string of a different radix as long as the Verilog syntax of identifying the radix andwidth are used, such as “32’h” for a 32 bit hexadecimal value.

If a register_value_variable is used in the shift_data_assignment, then a value computed bythe tool for that register_value_variable (as bound within the dofile) or hard-coded in thedofile is loaded or unloaded at that time and the shift length is also provided by the tool. It ispossible for more than one value_string or register_value_variable to be assigned to anidentifier in one shift_data_assignment. In this case, the extra values are separated by spaces.This allows multiple shorter values to be shifted into one register group.

The typical usage is that each register_value_variable corresponds to one register beingloaded, and the specification of multiple variables is used when those registers are cascaded andloaded/unload on after another.



November 2010

Alias NamesIt is possible to use an alias name in the new procedure type for loading shift data, even if thatalias name refers to multiple pins. If this is the case, the number of bits assigned by the “#”character for each shift is equal to the width of the alias being used. The length of the valuestring being passed to the procedure must be a multiple of the width of the alias.

Loading or unloading an alias can be used if performing parallel load/unload and no shift isrequired. For example, if each MISR bit is connected to a separate primary output. Even if noshifting is required, the functionality is still useful to bind the expected values to the signaturecomputed by the tool.

If multiple shift_data_assignments are passed to a procedure, then all of them must have thesame shift length such that each pin being loaded/unloaded requires the same number of cyclesto load/unload all the data. No padding is performed by the tool.

If a “measure” event is used in one of these procedures to unload a register, then these measurevalues can be compared in the final patterns and the Verilog testbench.

Dofile ModificationsYou define register value variables using commands you issue to the tool interactively or in adofile. The value variables are subsequently referenced in the procedure file. You use thefollowing commands to perform these operations:

• Add Register Value — See “Adding a Register Value Variable”

• Set Register Value — See “Dynamically Setting a Register Value Variable”

• Delete Register Value — See “Deleting a Register Value Variable”

• Report Register Value — See “Reporting a Register Value Variable”

Adding a Register Value VariableThe Add Register Value command defines the register value variables. You can only use thiscommand in Setup mode.

You must define the register value variables in the dofile before the variables are used in a testprocedure file to load values into the registers.

You can define the register value variables as either Static Value Variables or Dynamic ValueVariables.



Static Value VariablesYou specify a static value variable (see “Static Variable”) by stating a specific value string. Thisvalue variable then has this value string as a constant value. You must specify this value inSetup mode, and the value is considered to be static by default and the value is present whensimulating procedures in DRC.

ADD REGister Value value_name{value_string [-Radix {Binary | Decimal | Octal | hexadecimal} -Width integer]}optional_arguments

The value_name is a user-specified identifier, and the value_string is a state string in aparticular radix. The default is binary radix.

If the –Radix switch is used to change this to a different radix, then a register width must also bespecified using the –Width switch.

Dynamic Value Variables

You specify a dynamic value variable using the following variation of the command:

ADD REGister Value value_name value_string -Width integer optional_arguments

The value_string is optional and defaults to all X bits if not specified.

You can subsequently enter the actual value once you have exited Setup mode using the SetRegister Value command If no value is specified the first time DRC is invoked after adding aregister value variable, it will be considered as dynamic in this and any future invocation ofDRC. See “Dynamically Setting a Register Value Variable” for more information.

Data Pin Inversions

When using either a static or dynamic variable, you can optionally specify inversions on theinput and output data pins by using the -INput_pin_inversion and -OUtput_pin_inversionswitches, respectively.

These are optional switches you use to specify that the data value in this variable should beinverted before it is loaded into the register through the load_unload_register procedure.

Dynamically Setting a Register Value VariableYou can define a dynamic register value variable by using tool-specific switches and argumentsto link the variable to a value computed by the tool. These variables are dynamic, and the widthmust be specified unless the width is known to the tool at the time DRC is run.

This method is used for defining a variable that has a tool-specific computed value that will beavailable when patterns are saved and needs to be loaded or unloaded by the test_setup ortest_end procedures.



November 2010

In this case, you use the Add Register Value command with the -Width switch and omit thevalue while in setup mode. Once you have exited Setup mode, you can use the Set RegisterValue command to set the variable:

SET REGister Value value_name value_string [ -RAdix { BInary | HEx | OCtal | Decimal } ]

The name of the register value and its width are known prior to parsing the procedure file andrunning DRCs. The value will be all X bits for DRC.

This command can only be used for a register value that was defined without a value string, andthe width of the value string must match the width specified in the Add Register Valuecommand.

If the value overflows the width specified, an error is issued.

By default, the bits extracted by force/measure “#” in the procedure are from MSB to LSB. Ifthe value specified should be shifted in/out in the opposite order, with the LSB bitsapplied/measured first, use the “-LSB_shifted_first” optional switch.

Deleting a Register Value VariableThe Delete Register Value command deletes all or a specified register value variable. You canonly use this command in Setup mode.

Reporting a Register Value VariableThe Report Register Value command provides a detailed report of the register value variables tostdout or, optionally, a file.

Serial Load and Unload DRC RulesFor this release, the following existing DRC rules are applied to these new procedures and newsyntax:

• P13 and P54

• P66

• W5

The P1 “syntax error” message will be used to catch many potential issues, such as specifying a“#times” value for applying a load_unload_registers procedure instead of theshift_data_assignment.

P13 and P54The P13 and P54 rules are used to check the shift assignment statements when calling aload_unload_registers procedure.



If the shift assignment uses a value string that is not properly formatted or contains illegalcharacters for that radix, then a P13 is issued.

Error: Invalid state value state string. (P13)

If the shift assignment references an undefined register value variable name, a P54 is issued.

Error: Undefined identifier identifier_string referenced by signal_name.(P54)

P66The P66 rule is used to check for missing statements within a load_unload_registers procedure.For example, if no Shift block is specified, or if an event statement using the ‘#’ character is notpresent for each shift_assigment passed to the load_unload_registers procedure, then a P66 isissued.

Error: Procedure procedure_name is missing required statement_stringstatement. (P66)

The following examples illustrate the types of P66 DRC errors you could encounter.

Example 1

In the following example, the tool issues this error if there is no shift block within theload_unload registers procedure:

Error: Procedure procedure_name is missing required shift statement.(P66)

Example 2

In the following example, the tool issues this error if there are no events in theload_unload_register procedure that use the ‘#’ substitute character.

Error: Procedure procedure_name is missing required substitute eventstatement. (P66)

Example 3

In the following example, the tool issues this error if an apply statement that uses aload_unload_registers procedure has a shift data assignment that uses a signal that does notappear in the load_unload_registers procedure with the substitute character ‘#’.

Error: Procedure procedure_name is missing event using shift assignsignal_name statement. (P66)



November 2010

W5The W5 DRC error is used to flag any extra events or statements in a load_unload_registersprocedure, or any events that are not legal.

For example, if an event type other than Force or Expect is used with the ‘#’ substitutecharacter, then a W05 rule will be issued. If the load_unload_registers procedure contains morethan one shift block, this rule will be issued. If there is a Force or Expect statement using a ‘#’character for a signal name that is not being passed to the procedure as a shift assignment, thisrule will be issued. The W05 rule is used when shift assignments for a particular Applystatement do not all have the same length.

Error: Procedure procedure_name has an illegal event statement or eventorder (event_statement_string) (W5)

Example 1

The following error is issued if an event in the load_unload_register procedure uses the ‘#’substitute character, but no shift data for this signal is passed into the procedure when it is called“extra shift block”:

<force | measure> signal_name # without matching shift assign data

Example 2

The following error is issued if there is more than one shift block in the load_unload_registersprocedure.

“extra shift block”

Example 3

The following error is issued if more than one event of the same type in the shift block uses thesame signal name with the ‘#’ substitute character.

“too many events using shift assign signal_name”

Example 4

The following error is issued for an apply statement that uses a load_unload_registers procedurebut has no shift data assignments in the apply statement.

“apply with no shift data assignment”



Example 5

The following error is issued for an apply statement that uses a load_unload_registers procedureand has more than one shift assignment, however, the target of the shift assignments are aliasesand they are not the same width.

“unmatched shift assign signal width”

Example 6

This is issued for an apply statement that uses a load_unload_registers procedure and has morethan one shift assignment and the assignments have different shift lengths.

“unmatched shift lengths”

ExamplesThe definition of the load_unload_registers procedure would look as follows. Notice how thisprocedure uses the “shift =” statement and the “force tdi #” statement to denote the shifting andwhere the string of data is applied, one bit at a time.

procedure load_unload_registers load_prpg1 = timeplate tp1 ;

cycle = force prpg_select 1 ; ... // setup tap controller to load prpg end; shift = cycle = force tdi # ; pulse tck ; end; end;end;

This procedure could then be applied in the test_setup procedure to initialize the PRPG,specifying the string of bits to apply to “tdi” during shifting.

procedure test_setup = timeplate tp1 ;

cycle = force clk1 0 ; force clk2 1 ; force tck 0 ; ... end; apply load_prpg1 tdi = 000000000000000000000001 ; cycle = ...

end;end;



November 2010

For loading a register with the shift length during test_setup, using the values computed by thetool, the procedure definition would look the same, but how the procedure is called is slightlydifferent. The following example both loads and unloads the register, as this same procedurecould be used in a test_end procedure to unload the shift length value. The dofile for thisexample contains the following command:

add register value length_val -shift_length -width 16

The procedure file would contain the following:

procedure load_unload_registers load_unload_length = timeplate tp1 ; cycle = force clk1 0 ; ... end; shift = cycle = force tdi # ; expect tdo # ; pulse tck ; end; end;end;procedure test_setup = timeplate tp1 ; cycle = ... end; apply load_unload_length tdi = length_val, tdo = XXXXXXXXXXXXXXXX; cycle = ... end;end;

This next example uses an alias to group three tdi signals into one alias, and also adds a postshift cycle to the load_unload_registers procedure. When this procedure is called, the datapassed to it will be consumed three bits at a time, with each bit being shifted into tdi1, tdi2, andtdi3 in order. The total number of shifts applied in the “shift” block will be the total length of thevalue string divided by three, and then minus one for the post shift. Each shift will consumesthree bits, and the final cycle adds a post shift which will assign the last three bits. The length ofthe value string being passed to this procedure must be a multiple of three.

alias TDI_GRP = tdi1, tdi2, tdi3 ;procedure load_unload_registers load_reg1 = timeplate tp1 ;

cycle = force clk1 0 ; ... end; shift = cycle = force TDI_GRP # ; pulse tck ;

Test Procedure FileSupporting Commands


end; end; cycle = force TDI_GRP # ; pulse tck; end;end;

This final example shows how to use a dofile commands to setup a user-defined register valuethat will be used to store total number of scan patterns when the final patterns are saved.

add register value scan_pat_count -pattern_count scan_test -width 24

Supporting CommandsThe following list contains commands that support the use of procedure files. For a detaileddescription of each command, refer to the corresponding command reference page in the“Command Dictionary” section of the ATPG and Failure Diagnosis Tools Reference Manual orthe “Command Dictionary” section of the DFTAdvisor Reference Manual.

Add Scan Groups — Adds a scan group using the scan procedures in the namedprocedure file.

Read Procfile — Reads a new procedure file in non-setup mode. Merges new procedureand timing data with existing data loaded from previous procedure files.

Write Procfile — Writes out existing procedure and timing data as the namedprocedure file.

Save Patterns — Loads a cycle before saving patterns and merges the new data with theexisting data.

Report Procedure — Reports (displays) a named procedure to the screen. The -Allswitch displays all procedures to the screen.

Report Timeplate — Reports (displays) a named timeplate to the screen. The -Allswitch displays all timeplates to the screen.

Output FormatsThe test procedure file format supports the following output formats:

Fujitsu TDLMitsubishi TDLSTILTI TDL

WGLTSTL2VERILOG


Test Procedure FileParameter File Format and Keywords

November 2010

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 andFailure Diagnosis Tools Reference Manual.

Parameter File Format and KeywordsThe parameter file specifies field names and values for use in certain Vector Interfaces outputformats. The tool references this file when you issue the -PARAMeter switch with the SavePatterns command.

A section is added at the beginning of STIL, WGL, and Verilog output files that captures theenvironment data and the switches specified with the Save Patterns command.

• In the STIL format, this information is added to the HEADER{} block as an annotation.

• In the WGL format, this information is added to the header block as a series ofannotation statements.

• In the Verilog format, this information is added to the beginning of the Verilogtestbench as a comment.

The parameter file is a text file containing a series of parameter statements. Each statement usesthe following format:

KEYWORD arguments;

Where:

• UPPERCASE — Indicates a keyword and must be entered exactly as shown.

• Italic — Indicates a user-supplied argument.

• {} — Indicates a multi-option argument. Include only one option and do not enter thebraces.

• Underline — Indicates the default setting for a multi-option argument.

The parameter file has the following rules:

1. All parameter statements must end with a semicolon.

2. Comments are marked with double slashes “//” at the beginning of a line. Everythingbetween the slashes and the end of line character is ignored.

3. Each parameter should only be specified once. If a parameter is specified twice, thelatter entry overrides the previous one.

4. Each parameter statement must occupy a single line. Carriage returns cannot beembedded within a parameter statement.



5. Each parameter statement line cannot exceed 2048 characters. There are no restrictionson the parameter file size.

NoteAll parameters are optional and may be included or excluded as needed. If a parameter isomitted, the default setting is used. Refer to each parameter description for the defaultbehavior.

The following is a list of the available parameter statements:

ALL_FIXED_CYCLES {2 | 1 | 0};ALL_FLATTEN_TIMING {1 | 0};ALL_IDDQ_TESTER_CYCLE {1 | 0};ALL_MIN_SCAN_LOAD {1 | 0};ALL_NO_CYCLE_OPT {1 | 0};ALL_NO_LOOP {1 | 0};ALL_NO_PATTERN_TYPE {1 | 0};ALL_NONSCAN_CONSTANT {1 | 0};ALL_ORIGINAL_INDEX {1 | 0};ALL_TIME_RESOLUTION integer;ALL_USE_CYCLE_LOOP {1 | 0};CTL_ONE_PAT {1 | 0};CTL_ONE_PROTO {1 | 0};CTL_STIL_0 {1 | 0};CTL_STIL_1 {1 | 0};FTDL_DESIGNER string;FTDL_MAX_PAT_BLOCK integer;FTDL_REVISION string;FTDL_TEST_NAME string;FTDL_TEST_NUM integer;FTDL_TEST_SUFFIX string;FTDL_ZMODE_MES {1 | 0};SIM_ANNOTATE_QUIET {1 | 0};SIM_DISTRIBUTED_PAT {1 | 0};SIM_FORCE_Z_AT_CYCLE {1 | 0};SIM_POST_SHIFT integer;SIM_PRE_SHIFT integer;SIM_PRECISION string;SIM_SHIFT_DEBUG integer;SIM_TIMEPLATE_COMM {1 | 0};SIM_VECTOR_COMM {1 | 0};SIM_VECTYPE_SIGNAL {2 (Verilog only) | 1 | 0};STIL_2005_SCAN {1 | 0};STIL_CHAIN_CELLS {1 | 0};STIL_CHANNEL_CELLS {1 | 0};STIL_FULL_CHAIN {1 | 0};STIL_MIN_QUOTE {1 | 0};STIL_NESTED_MACRO {1 | 0};STIL_NO_SCANSTRUCTURE {1 | 0};STIL_NO_SCANX {1 | 0};STIL_NOMEASURE_CLOCK {1 | 0};STIL_PAT_ANN string %special_keyword string2;STIL_PAT_CMT {1 | 0};STIL_PAT_LAB {1 | 0};STIL_QUOTE_ALL {1 | 0};



November 2010

STIL_SCAN_ANN1 string %special_keyword string2;STIL_STRUCTURAL {1 | 0};STIL_TI_TITLE {1 | 0};STIL_TRIM_PULSE {1 | 0};STIL_VECTOR_ANN string %special_keyword string2;STIL_VERG_ESC {1 | 0};TITDL_CHAIN_SETTYPE string;TITDL_CUSTOMER string;TITDL_GROUP_TIMING {1 | 0};TITDL_KEEP_SCANOUT {1 | 0};TITDL_LIBRARY string;TITDL_PARTNUM string;TITDL_PSEUDO_PREFIX string;TITDL_REVISION string;TITDL_SETNAME string;TITDL_SETTYPE string;TEST_SETUP_EXPECT {1 | 0};VERILOG_CHAIN_ERROR {1 | 0};VERILOG_CHANGE_PATH {1 | 0};VERILOG_COMPARE_X {1 | 0};VERILOG_DELAY_SCAN_RELEASE integer;VERILOG_DIAG_FILE {2 | 1 | 0};VERILOG_EARLY_RELEASE {1 | 0};VERILOG_EARLY_RELEASE_TIME integer;VERILOG_FILL_BIDISCAN {1 | 0};VERILOG_INCLUDE filename;VERILOG_INSTANCE_NAME string;VERILOG_KEEP_PATH {1 | 0};VERILOG_MASK_FILE {2 | 1 | 0};VERILOG_MIN_NAME_FILE {1 | 0};VERILOG_MODULE_INCLUDE filename;VERILOG_NO_CHAINNAME_FILE {1 | 0};VERILOG_NO_MEASURE_IN {1 | 0};VERILOG_PARALLEL_DELAY_SHIFT_CLOCKS {integer};VERILOG_PARALLEL_EARLY_FORCE_AND_MEASURE {1 | 0 | true | false};VERILOG_SERIAL_CHAIN {1 | 0};VERILOG_SIGNAL_SPY {1 | 0};VERILOG_SIM_STATUS integer;VERILOG_TOP_NAME string;VERILOG_UNCOMPRESS_PAT {1 | 0};WGL_ADD_LASTX {1 | 0};WGL_ALT_BIDI {1 | 0};WGL_ALT_VECT_ANN {1 | 0};WGL_EDGE_STROBE {1 | 0};WGL_FULL_CHAIN {1 | 0};WGL_FULL_SCANGROUP {1 | 0};WGL_GROUP_PIN {1 | 0};WGL_INV_SC {1 | 0};WGL_NO_SCANX {1 | 0};WGL_NOMEASURE_CLOCK {1 | 0};WGL_ONE_ILLINOIS {1 | 0};WGL_PATTERN_NAME string;WGL_TRIM_PULSE {1 | 0};WGL_VECTOR_ANN {1 | 0};WGL_VERG_ESC {1 | 0};WGL_VTRAN_PADSC {1 | 0};



• 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 being saved.Issuing a 1 with this keyword specifies that the patterns will contain an equal number ofnon-scan cycles between each scan chain loading. This non-scan cycle is applied before thefirst shift cycle. The default is 0.

This will add “Shift” cycles before the regular apply shift of the load_unload procedure. Itadds these additional cycles before the scan chain load to make all patterns have the sametotal number of cycles per pattern, taking into account the differences in the number ofcapture cycles. The number of capture cycles can still vary depending on what ATPGneeded or was directed with the Named Capture Procedures. However, no additional“Capture” cycles are added. The new cycles will use the timeplate that the “Shift” procedureuses.

• 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 result inany output format which can support equation-based timing using the equations as they arespecified.

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 Verilog, WGL, and STIL have the ability to express time values in thetiming blocks, as numerical values or as equations based on variables. Using equation-based timing allows one value to be specified for a global attribute, such as the test cycleperiod, while other values are derived from this using equations.

• ALL_IDDQ_TESTER_CYCLE {1 | 0};

Issuing a 1 with this keyword forces the IDDQ file to contain tester cycle counts and serialsimulation times even if the pattern file being saved is a parallel load pattern file. Not usingthe keyword, or using it with a 0 argument invokes the default behavior where the IDDQ fileuses tester cycle counts for serial pattern formats, and vector counts and parallel load timesfor parallel formats.

In the example, saving a parallel load pattern file for a particular design and using the-iddq_file, the IDDQ file has the following content:

/* Pattern # Cycle # Time */0 71 71001 76 7600...

Saving the same parallel load pattern file and using -iddq_file, but also usingALL_IDDQ_TESTER_CYCLE 1; produces an IDDQ file with the following content:

/* Pattern # Cycle # Time */



November 2010

0 195 195001 324 32400...

The cycle counts and times given now correspond to serially loaded tester cycle counts andsimulation time stamps

• ALL_MIN_SCAN_LOAD {1 | 0};

By default, all pattern outputs contain scan in and scan out data for each scan load. Settingthis keyword to 1 allows a scan load to specify only scan in or scan out when appropriate(first scan in). The default is 0.

• ALL_NO_CYCLE_OPT {1 | 0};

Issuing a 1 with this keyword specifies for all outputs to turn off cycle optimizations in non-scan areas of patterns and leave all cycles in the patterns. Issuing a 0 with this keyword (oromitting this keyword as it is the default), will allow the following optimization in cyclesthat are part of the Capture or Clock procedures: If any two identical cycles are generatedand do not measure any outputs, the duplicate cycles will be removed.

• ALL_NO_LOOP {1 | 0};

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 570 for more information.

• ALL_NO_PATTERN_TYPE {1 | 0};

If set to 1, this keyword eliminates the pattern type annotation. This keyword applies to allVector Interface formats. The default is 0.

CautionThis keyword should only be used if the pattern type annotations are causing problems. Ifyou set this keyword to 1, you will not be able to load the generated patterns back into theDFT tools.

• ALL_NONSCAN_CONSTANT {1 | 0};

Setting this keyword to 1 forces all non-scan pins, excluding control and clock pins, to theconstant value of the pad state for all scan patterns. This keyword may be useful, as analternative to procedure force statements, for testers that require constant pin values. Thedefault is 0.

• ALL_ORIGINAL_INDEX {1 | 0};

When set to 1, saved STIL pattern files use the original pattern index (from before filtering)for the annotations and comments prior to each pattern. When set to 0 (the default), thepattern numbering in the comments and annotations is numbered in order starting at 0 fromthe first pattern as if the filtered patterns are a new pattern set. Note that this has no effect onthe Verilog testbench because the testbench uses a built-in pattern count mechanism.



• 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_USE_CYCLE_LOOP {1 | 0};

Uses updated terminology in the generated pattern files to prevent confusion with TessentDiagnosis terms. The previous “cycle” and “loop” terms in the pattern files are replacedwith “simulation cycle” or “vector” and “tester cycle”. Set this keyword to 1 to revert backto the “cycle” and “loop” terminology.

• CTL_ONE_PAT {1 | 0};

This keyword, if set to 1, will cause all pattern data to be grouped into a single STIL patternblock, instead of one pattern block per ATPG pattern. The default is 0.

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

• 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 header willnot 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 leave theIEEE 1450.1 syntax. The default, if not specified, is 0, which produces the full 1450.6 and1450.1 syntax used in the CTL output.

The CTL_STIL_0 parameter file keyword can be used in the CTL output to eliminate thenew 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.



November 2010

• 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_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 is 5 million.

• FTDL_REVISION string;

String is an informational string to be used as the revision string in the REVISION statementat the top of the FTDL file. If not specified, the default is “0001”.

• FTDL_TEST_NAME string;

String is the root name to be used for the test block(s) within the FTDL file. If not specified,the default root name is “FN”. The root name is combined with a test number to create eachtest 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_TEST_SUFFIX string;

Use this keyword to add a suffix to the test block name. The total test block name isconstructed from FTDL_TEST_NAME, FTDL_TEST_NUM, and optionally,FTDL_TEST_SUFFIX. The required argument String is the suffix that will be added afterthe test block number. The default is to have no suffix.

• FTDL_ZMODE_MES {1 | 0};

This keyword controls whether or not the FTDL file will allow for Z values to be measuredon 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 FTDL file, and no Z values will beused on output pins. If set to 1, then the “ZMODE = MES” statement will be placed in allTEST blocks, and Z values will be allowed on output pins. The default is 0, NOMES.

Keywords FTDL_TEST_NAME and FTDL_TEST_NUM are used together to create thename(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;

• SIM_ANNOTATE_QUIET {1 | 0};

When set to 1, this keyword suppresses the Verilog testbench from displaying theannotations during simulation. The default behavior is to display the annotations.

• SIM_DISTRIBUTED_PAT {1 | 0};

When set to 1, this keyword allows you to run a subset of the saved patterns or pattern filesduring simulation. The pattern files are saved according to the pattern boundaries instead ofthe vector boundaries, with the test setup in a separate file. You can then use theSTARTPAT and ENDPAT PlusArgs keywords to specify the starting and ending patterns orthe STARTVECFILE and ENDVECFILE keywords to specify the starting and endingpattern files to use for simulation. For example, the following runs the simulation usingpattern files 2 through 10:

vsim simple_testbench_v_ctl -c -do vsim.do +STARTVECFILE=2 +ENDVECFILE=10

If you specify only the ENDPAT or ENDVECFILE keyword, the simulation will begin withthe first pattern or file and end at the specified pattern or file. For example, the followingruns the simulation for the first four patterns:

vsim simple_testbench_v_ctl -c -do vsim.do +ENDPAT=4

If you specify only the STARTPAT or STARTVECFILE keyword, the simulation will startwith the specified pattern or file and end at the last pattern or file. For example, thefollowing runs the simulation for pattern files 3 through 20, where 20 is the last pattern file:

vsim simple_testbench_v_ctl -c -do vsim.do +STARTVECFILE=3

To simulate a single pattern or pattern file, specify the same value both the start and endkeywords. For example, the following runs the simulation for only pattern 8:

vsim simple_testbench_v_ctl -c -do vsim.do +STARTPAT=8 +ENDPAT=8

You can save low-power EDT patterns with this keyword turned on, however, theSTARTVECFILE and ENDVECFILE PlusArgs variables are not included in the testbench.Only the STARTPAT and ENDPAT PlusArgs are included.

• SIM_FORCE_Z_AT_CYCLE {1 | 0};

Controls when a bidi pin switches to a Z state in the Verilog testbench. The default behavioris that when a bidi pin is going to change to a Z value during a given simulation vector, thenthe Z is forced at time 0 for that vector. However, when you set the keyword value to 0, theZ value applies to the bidi pin at the force time specified in the timeplate rather than at time0. Note that if the force time happens after the internal driver for the bidi pin turns on, buscontention is possible.



November 2010

• SIM_POST_SHIFT integer;

Specifies the number of independent post shifts to use during simulation. This is theabsolute number of post shifts that will be used, not an additive number. For example, if theload_unload procedure already has one post shift, setting this keyword to “2” causes twopost shifts to be used, not three.

If you specify a negative number or zero, this keyword is ignored. If you specify a numberlarger than the total number of shifts, the tool issues a warning and sets the number of postshifts to the total number of shifts minus one.

• SIM_PRE_SHIFT integer;

Specifies the number of independent pre shifts to the load_unload procedure (prior to mainshift) to use during simulation. This is the absolute number of pre shifts that will be used,not an additive number. For example, if the load_unload procedure already has one pre shift,setting this keyword to “2” causes two pre shifts to be used, not three.

If you specify a negative number or zero, this keyword is ignored. If you specify a numberlarger than the total number of shifts, the tool issues a warning and sets the number of preshifts to the total number of shifts minus one.

• SIM_PRECISION string;

A keyword and string pair that explicitly sets the timescale precision. The string is a numberand a unit, for example:

SIM_PRECISION 1ns;SIM_PRECISION 10ms;

The units supported are ms, us, ns, ps, and fs.

The tool checks this value to verify that it is less than or equal to the Timescale unit from theprocedure file and outputs this value in the test benches.

• SIM_SHIFT_DEBUG integer;

This keyword and integer pair specify for the serial Verilog testbench to use special testpatterns that contain a parallel observe of the entire scan chain for every shift, while seriallyshifting the patterns.

For debugging purposes only, this format makes it easier to pinpoint precisely which scancell in a chain is causing a problem. Issuing a 0, which is the default behavior, will cause theserial Verilog testbench to use test patterns that do not contain a parallel observe of theentire scan chain for every shift.

If an integer of 1 is used, it will shift serially and do a parallel compare for all shifts. If aninteger of 2 or greater is used, it will shift serially and do parallel compares on the first 2 orgreater shifts. This is done to reduce the amount of data in the pattern files.

The Verilog patterns you create using the keyword SIM_SHIFT_DEBUG typically takemore time for the tool to create than other kinds of patterns and contain large amounts ofdata (so file sizes tend to be huge). Also, because they simulate serially, the patterns will



take more time to simulate. Be sure these are acceptable trade-offs before trying to use thesepatterns.

The tools ignore the keyword SIM_SHIFT_DEBUG and issue a warning unless you includethe -Serial switch in the Save Patterns command line. Also, if you do not include the -End or-Chain_test switches, the tool defaults to “-End 0”, saving chain test patterns and the firstscan pattern. To save chain test patterns and a different set of scan patterns, use the -Beginand/or -End switches to specify the range of scan test patterns to save. To save just chain testpatterns, include the -Chain_test switch.

Note that this functionality is only available for Tessent FastScan patterns and TessentTestKompress bypass patterns (uncompressed).

• SIM_TIMEPLATE_COMM {1 | 0};

Parameter file keyword used to turn on timeplate comments in the vector file. The default isoff (0). Set this parameter to true (1), and comments for the timeplate will be added to thevector file. The format of the timeplate comment is:

// Timeplate: <timeplate_name>

• SIM_VECTOR_COMM {1 | 0};

Set this keyword to 1 to turn on vector type comments in the vector file, the default is off.The format of the vector type comment is:

// Vector type: <vector_type_string>

Where <vector_type_string> is one of the following:

Table 7-2. Vector Types

Vector Type Definition

TEST_SETUP Vector from test_setup procedure.

TEST_END Vector from test_end procedure.

SEQ_TRANSPARENT Vector from seq_transparent procedure.

CLOCK_PROCEDURE Vector from clock procedure.

CLOCK_PROCEDURE_RESTORE Vector from clock procedure that uses restore_bidievent.

LOAD_UNLOAD Vector from load_unload procedure.

SHIFT Vector from shift procedure.

SINGLE_SHIFT Single shift vector applied in load_unload procedure.

SHIFT_EXTRA Vector from multi-cycle shift procedure that does notcontain the force_sci and measure_sco events.

SHADOW_CONTROL Vector from shadow_control procedure.

MASTER_OBSERVE Vector from master_observe procedure.



November 2010

• SIM_VECTYPE_SIGNAL {2 (Verilog only) | 1 | 0};

Setting this keyword to 0 specifies that all vector types in the currently active procedure berepresented in the pattern file as a signal, and that these signals be on (in a 1 state) when thatvector type is active. This allows you to specify them in pattern tracing and viewing so youcan see what type of vector is currently active at any specified moment within a simulation.

If the keyword is set to 1 (default), it will add an encoded vector type to the Verilog orVHDL testbench in the bus MGCDFT_VECTYP[0-3]. The translation table, Table 7-3, willalso be added to the testbench. Issuing a 0 will cause the testbench to not include thesecapabilities. See Analyzing the Simulation Data section for an example of using thiskeyword.

SHADOW_OBSERVE Vector from shadow_observe procedure.

SKEW_LOAD Vector from skew_load procedure.

PRIMARY1 Vector from a non-scan procedure such as capture,named capture, clock_sequential, or ram_sequential.

PRIMARY_MEASURE1 Vector from a non-scan procedure that measuresprimary outputs.

PRIMARY_CLOCKPO1 Vector from a clock_po procedure.

1. In addition to the above, the “PRIMARY” vector types can have “_IDDQ” appended to the end toindicate a iddq measure point.

Table 7-3. 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

0110 mgcdft_shadow_control

0111 mgcdft_master_observe

1000 mgcdft_shadow_observe

1001 mgcdft_skew_load

1010 mgcdft_seq_transparent

1011 mgcdft_launch_capture

Table 7-2. Vector Types (cont.)

Vector Type Definition



NoteAdding signals indicating vector type to the Verilog testbench enables you to see whattype of vector is currently active at any specified moment within a simulation and cansimplify simulation mismatch debugging.

Setting this keyword to 2, which is available only with a Verilog test bench, also adds theencoded vector types (default behavior). Additionally, the test bench will have the following_procedure_strings, which can be added to your WAVE display to show the currently activeProcedure Type.

• STIL_2005_SCAN {1 | 0};

Issuing a 1 with this keyword is similar to the STIL_STRUCTURAL keyword except it willalso use the IEEE 1450.1 ScanStructures block. The default, if not specified, is 0, whichproduces 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 used inthe CTL output to eliminate the new 1450.1 features along with all of the 1450.6 syntax.The parameter file keyword CTL_STIL_1 can be used to eliminate all 1450.6 syntax butleave the 1450.1 syntax.

Note that the ScanStructures in your STIL structure must match the compressed structure.

In order to use this output, you must use the Save Patterns -STIL1999 command and switch.

The following is an example of the IEEE 1450.1 ScanStructures block in the new STILoutput:

STIL 1.0 { Design 2005;}

1100 mgcdft_shift

1101 mgcdft_clock_proc

1110 mgcdft_clock_proc_restore

1111 mgcdft_test_end

0000 mgcdft_unknown

CLOCK_PROCCLOCK_PROC_RESLAUNCH_CAPTURELOADMASTER_OBSERVE

SEQ_TRANSPARENTSHADOW_CONTROLSHADOW_OBSERVESHIFTSHIFT_EXTRA

SINGLE_SHIFTSKEW_LOADTEST_SETUPTEST_ENDUNKNOWN

Table 7-3. Translation Table (cont.)

MGCDFT_VECTYP[0-3] Encoding Signal/Variable



November 2010

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_CHAIN_CELLS {1 | 0};

Setting this keyword to 0 removes the ScanCells list from the ScanChain definition in theScanStructures block when saving non-compressed scan patterns that use scan chains. Thefollowing example shows a ScanStructures block without the ScanCells list:

ScanStructures {ScanChain chain1 {

ScanLength 100;ScanInversion 0;ScanIn "sci";ScanOut "sco";

}}

By default (1), the scan cell names are listed following the ScanLength statement.

For compressed patterns, see the STIL_CHANNEL_CELLS keyword.

• STIL_CHANNEL_CELLS {1 | 0};

Setting this keyword to 1 enables the listing of dummy scan cell names in theScanStructures block when saving compressed patterns that use EDT channels from TessentTestKompress. By default (0), the dummy scan cell names are not listed.

For non-compressed patterns, see the STIL_CHAIN_CELLS keyword.

• STIL_FULL_CHAIN {1 | 0};

Setting this keyword to 0 causes the tools to shorten the list of scan cells by the number ofpre shifts and post shifts. By default (1), all cells in the scan chain are listed in the STIL fileregardless the number of pre shifts and post shifts.



• STIL_MIN_QUOTE {1 | 0};

Issuing a 1 with this keyword is for STIL2005 and CTL outputs, and will cause the STIL fileto 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 quoting rules. Thedefault, if not specified, is 0 for the STIL1999 output.

• STIL_NESTED_MACRO {1 | 0};

Setting this keyword to 1 when saving STRUCTURAL_STIL, STIL2005, or CTL patternscauses sub procedures to be interpreted as Macros. As Macros, they will be nested inside thecalling Macros. Loop statements will be used, if necessary, to repeat the Macro. Thiskeyword is set to 0 by default.

• STIL_NO_SCANSTRUCTURE {1 | 0};

Setting this keyword to 1 removes the entire ScanStructures block from the STIL output.For design flows where the ScanStructures block is not required, removing the blocksignificantly reduces the size of the STIL file. The ScanStructures block is included bydefault (0).

• STIL_NO_SCANX {1 | 0};

If set to 1, this keyword replaces all X scan load values in the STIL pattern output with 0scan load values. The default is 0.

• 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 the commandprompt. 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_PAT_ANN string %special_keyword string2;

Specifies the string the tool outputs to the STIL pattern file just prior to each scan pattern.

annotation “string %keywords string”

The following example shows lines in a parameter file and the resultant text generated in theoutput pattern file.

o Parameter File Entry



November 2010

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 Tessent 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 eachTessent FastScan pattern. The default is 1.

• STIL_QUOTE_ALL {1 | 0};

Setting this keyword to 1 causes all user identifiers to be enclosed in double quotes in theSTIL output file. By default (0), user identifiers are not quoted.

If the STIL_QUOTE_ALL and STIL_MIN_QUOTE keywords are both active (1), the toolissues a warning and the STIL_MIN_QUOTE keyword is ignored.

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


The following example shows lines in a parameter file and the resultant text generated in theoutput 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_STRUCTURAL {1 | 0};

Issuing a 1 with this keyword will cause the STIL file to be written using a more structuralform. This keyword results in a STIL output form that uses some of the basic hierarchicalapproaches of CTL output, but not any of the IEEE 1450.6 CTL syntax extensions. As withCTL output, the structural STIL output will create STIL Macro definitions for all usedprocedures, and a STIL Procedure definition for the test_setup procedure, if present. Thestart of each pattern will still consist of an annotation statement and a pattern label. Eachpattern will consist of the calls to each specific Macro, passing all needed data. Unlike theCTL output, a new “pattern type” macro will not be created for each pattern, and the patterndata will not be placed in a separate file and 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; }



November 2010

Shift { V { "SE" = 1; "_chain_SDI_" = #;"_chain_SDO_" = #; "CLK" = 1; }

}}

capture {W tset_tp_shift;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_TI_TITLE {1 | 0};

Setting this keyword to true (1) turns on a TI specific title block in the STIL Header block.This title block contains all of the specific statements from the TITDL output file, and theTITDL specific parameter file keywords can be used to change the fields in the title block.The default if not specified is false (0).

These keywords include: TITDL_LIBRARY, TITDL_CUSTOMER, TITDL_PARTNUM,TITDL_SETNAME, TITDL_SETTYPE, TITDL_CHAIN_SETTYPE, andTITDL_REVISION.

• STIL_TRIM_PULSE {1 | 0};

Issuing a 1 with this keyword will cause the input timing to drop the leading 0 ns force, tothe off state of the clock. Removing the initial force to the off state of a clock may not beappropriate for all testers and translation processes, and you need to understand alldownstream processes that will use the resultant files. 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_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_VECTOR_ANN string %special_keyword string2;

Specifies the vector types to be added to the output pattern file.


NoteYou must not use the “%” symbol as the leading character to any string fragment inconjunction with the %special_keyword.

The STIL_SCAN_ANN1, STIL_PAT_ANN, and STIL_VECTOR_ANN parameter filekeywords use a (%special_keyword) that is translated at the specific time and place theannotation statement will be written. Table 7-4 lists the available special keyword

Table 7-4. STIL Special Keywords

Keyword Description

%chain The chain name of the current chain.



November 2010

• STIL_VERG_ESC {1 | 0};

Setting this keyword to 1 changes all vectored signal names to scalars. For example, the pinname “bus”[0] would change to “bus[0]”.

%cycle_num The current Tessent FastScan, FlexTest, or TessentTestKompress cycle number.

%length The length of the current chain.

%pat_num The current Tessent FastScan, FlexTest, or TessentTestKompress pattern number.

%pat_num_plus1 The current Tessent FastScan, FlexTest, or TessentTestKompress pattern number plus 1.

%pattern_type The pattern type, for outputting annotations in the patternfile. It causes one of the pattern types in Table 7-5 to bewritten into the pattern file.

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

%vector_type This keyword causes one of the vector types in Table 7-6 tobe written into the pattern file.

Table 7-5. STIL Pattern Types

basic macrotest ram_passthru

clock_po multi_load ram_sequential

clock_sequential

Table 7-6. STIL Vector Types

CLOCK_PROCEDURE PRIMARY_CLOCKPO SHADOW_CONTROL

CLOCK_PROCEDURE_RESTORE

PRIMARY_CLOCKPO_IDDQ SHADOW_OBSERVE

CORE_ACCESS PRIMARY_IDDQ SHIFT

CORE_INST_ISOLATE PRIMARY_MEASURE SINGLE_SHIFT

CORE_INST_TEST PRIMARY_MEASURE_IDDQ SKEW_LOAD

LOAD_UNLOAD SCAN_IN SEQ_TRANSPARENT

MASTER_OBSERVE SCAN_IO TEST_SETUP

PRIMARY SCAN_OUT

Table 7-4. STIL Special Keywords (cont.)

Keyword Description



• 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”. Toadd this to the specific title block, see the parameter file keyword STIL_TI_TITLE.

• 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. To add this to the specific title block, see the parameter file keywordSTIL_TI_TITLE.

• TITDL_GROUP_TIMING {1 | 0};

Issuing a 1 with this keyword in conjunction with the Save TITDL Patterns command, willgroup like timing information into a single statement. The default is off.

• 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 keep scanoutstatements whose scanout values are all X when writing TITDL format vectors.

• TITDL_LIBRARY string;


LIBRARY_TYPE=string

statement in the header of the TITDL output file. If not specified, the default is GS20. Toadd this to the specific title block, see the parameter file keyword STIL_TI_TITLE.

• TITDL_PARTNUM string;


TI_PART_NUMBER=string

statement in the header of the TITDL output file. If not specified, the default is F999999. Toadd this to the specific title block, see the parameter file keyword STIL_TI_TITLE.

• TITDL_PSEUDO_PREFIX string;

Specifies the string that will be prepended to the name of the clock pin to create the name ofthe 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 clock pin iscalled “clock”, and the added pseudo clock pin is called “ps_clock” because of the use of theabove parameter file keyword.



November 2010

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

• TITDL_REVISION string;


REVISION=string

statement in the header of the TITDL output file. If not specified, the default is 1.00. To addthis to the specific title block, see the parameter file keyword STIL_TI_TITLE.

• TITDL_SETNAME string;


PATTERN_SET_NAME=stringstatement in the header of the TITDL output file. The string can be a maximum of twentycharacters. If not specified, the default is the filename with no extension. To add this to thespecific title block, see the parameter file keyword STIL_TI_TITLE.

• TITDL_SETTYPE string;


PATTERN_SET_TYPE=string

statement in the header of the TITDL output file. If not specified, the default is SCAN. Toadd this to the specific title block, see the parameter file keyword STIL_TI_TITLE.

• 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) withthis keyword. For more information, refer to the -Test_setup format switch under the “SavePatterns” command in the ATPG and Failure Diagnosis Tools Reference Manual.

• VERILOG_CHAIN_ERROR {1 | 0};

Setting this parameter to 1 adds a register/signal per scan chain to the Verilog testbench.This signal may be monitored during simulation and goes to 1 when a mismatch is detectedon the scan chain. The name of the register/signal is mgcdft_chainname_error wherechainname is the chain name specified on the Add Scan Chains command line. The defaultis 0.



• VERILOG_CHANGE_PATH {1 | 0};

Setting this parameter to 1 will insert code into the test bench that allows you to change thepath to the files during simulation. Use the VERILOG PlusArgs keyword “NEWPATH=” topass a new file path to test bench. For example:

vsim top_CngP_v_ctl +NEWPATH=./results/ -c -do "run -all"

Verilog simulators run on different operating systems. You must supply the directorydelimiter appropriate for your operating system with the NEWPATH.

NoteVERILOG_CHANGE_PATH and VERILOG_KEEP_PATH are mutually exclusive.VERILOG_CHANGE_PATH will be ignored if VERILOG_KEEP_PATH is present.

• 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 Tessent FastScan, FlexTest, andTessent TestKompress, in both Serial and Parallel testbenches. Issuing a 0, the defaultbehavior, 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.

• VERILOG_DELAY_SCAN_RELEASE integer;

This keyword and positive integer pair specifies to delay the scan release by the specifiednumber. The unit of the specified integer is the same as the timescale units. If there aremultiple chains, each release is delayed by the specified integer.

• VERILOG_DIAG_FILE {2 | 1 | 0};

Controls the generation of the failure file in the test bench. The failure file name is generatedby appending the test bench file name with “.fail”. For example, a test bench file named“testbench.v” would generate a failure file named “testbench.v.fail”.

For Tessent FastScan and Tessent TestKompress, the default setting is 1. For all other tools,the default is 0.

o 0 — No Verilog code for generating the failure file is included in the test bench. Thissetting maintains backward compatibility with previous test bench versions.

o 1 — Verilog code for generating the failure file is included in the test bench, but thefile is not automatically generated. To activate generation of the failure file, youmust edit the test bench, setting the “_write_DIAG_file” parameter to 1.



November 2010

o 2 — Verilog code for generating the failure file is included and activated in the testbench. You can explicitly disable failure file generation by setting the“_write_DIAG_file” parameter to 0 in the test bench.

• 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 shift procedure.Issuing a 0, the default behavior, will place the “release” statement at the end of the cycle.

• VERILOG_EARLY_RELEASE_TIME integer;

Issuing an integer value with this keyword allows you to specify exactly what time you wantthe Verilog testbench “release” statement to happen using the time scale specified in theprocedure file. The integer value is a time value that is required to be in the same time scaleas that used in the timeplate for the shift procedure. The time specified must be later than thetime of the force_sci event, but not greater than the time of the end of the cycle that theforce_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, thenthe VERILOG_EARLY_RELEASE_TIME keyword takes precedence. If neither keywordis used, then the default behavior of putting the “release” statement at the end of the cycle isstill 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_FILL_BIDISCAN {1 | 0};

By default, the bidirectional scan_input pins are set to ‘X’ during parallel scan loading in theVerilog test bench. Setting this keyword to 1 sets the bidirectional scan_input pins to thescan in value of the first cell.

• VERILOG_INCLUDE filename;

Adds an include statement into the Verilog testbench after the comments and before the firstmodule. The contents of the filename specified must contain legal Verilog statements andsyntax. This statement is only used in the Verilog outputs. The Default behavior is to notadd any include statements.

• VERILOG_INSTANCE_NAME string;

Specifies the Instance name for your design, to be used within the testbench.

Example:



Your current design = simple_chain2

Then you specify the instance name = presy

Parameter File:

VERILOG_INSTANCE_NAME presy ;

Test Bench:

// top_module_name = simple_chain2_pat_par_v_ctlmodule simple_chain2_pat_par_v_ctl;

simple_chain2 presy (.reset(reset), .clk(clk), .in1(in1), .scan_in1(scan_in1), .scan_en(scan_en), .out0(out0), .out1(out1), .out2(out2), .out3(out3), .all0(all0), .all1(all1), .w1out(w1out), .scan_out1(scan_out1));

• VERILOG_KEEP_PATH {1 | 0};

Issuing a 1 with this keyword specifies for the Verilog testbench to use the full pathname tospecify the pattern data file. Issuing a 0, the default behavior, will cause the Verilogtestbench to specify the pattern data file without any path information.

NoteVERILOG_CHANGE_PATH and VERILOG_KEEP_PATH are mutually exclusive.VERILOG_CHANGE_PATH will be ignored if VERILOG_KEEP_PATH is present.

• VERILOG_MASK_FILE {2 | 1 | 0};

Controls the generation of the mask file, which captures simulation mismatches, in the testbench. The mask file name is generated by appending the test bench file name with “.mask”.For example, a test bench file named “testbench.v” would generate a mask file named“testbench.v.mask”.

For Tessent FastScan and Tessent TestKompress, the default setting is 1. For all other tools,the default is 0.

o 0 — No Verilog code for generating the mask file is included in the test bench. Thissetting maintains backward compatibility with previous test bench versions.

o 1 — Verilog code for generating the mask file is included in the test bench, but thefile is not automatically generated. To activate generation of the mask file, you mustedit the test bench, setting the “_write_MASK_file” parameter to 1.

o 2 — Verilog code for generating the mask file is included and activated in the testbench. You can explicitly disable mask file generation by setting the“_write_MASK_file” parameter to 0 in the test bench.



November 2010

NoteThe simulation mismatches for the ChainTest patterns are recorded in theVERILOG_MASK_FILE, but they are commented out.

• VERILOG_MIN_NAME_FILE {1 | 0};

Controls the number of .name output files generated when saving patterns as a Verilog testbench. Setting this keyword to 0 will cause the tool to generate a separate set of .name filesfor each test bench file. When using the -maxloads switch for large designs with many scanchains and patterns, this generates a very large number of files. Setting this keyword to 1will reduce the number of output files by generating only one set of .name files for a design.The same .name files can be used for all generated Verilog test benches for that design.

This parameter file keyword is on by default when you use the Save Patterns command withthe -maxloads switch. It is off by default otherwise.

• 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 before thefirst module. The filename can be any valid file path. The contents of the specified file mustcontain legal Verilog statements and syntax. This statement is only used in the Verilogoutputs. The default behavior is to not add any include statements.

• VERILOG_NO_CHAINNAME_FILE {1 | 0};

Setting this keyword to 1 prevents the tool from generating the filename.chain.name file.This file is generated by default.

• 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 pin when ameasure happens. Setting this to 1 will cause the testbench to not measure input values onthe 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 (1) automatically.

• VERILOG_PARALLEL_DELAY_SHIFT_CLOCKS {integer};

Delays the leading edge of all shift clocks in all shift procedures by the specified number oftimescale units. Any events occurring after the leading edge of the first shift clock will alsobe delayed to maintain the event order. The specified number must be a positive integer. Ifthe specified delay causes any event to occur beyond the period of the timeplate, a warningwill be issued and this keyword will be ignored.

This keyword is only valid for Verilog parallel test bench generation.

• VERILOG_PARALLEL_EARLY_FORCE_AND_MEASURE {1 | 0 | true | false};

Setting this keyword to 1 or true moves the measure_sco event to time 0 and the force_scievent to time 1. By default (0 or false), the measure_sco event occurs at the measure_po



time specified in the timeplate for the shift procedure. The force_sci event then occurs onetimescale unit later, regardless of the force_pi time specified in the timeplate.

This keyword is only valid for Verilog parallel test bench generation.

• VERILOG_SERIAL_CHAIN {1 | 0};

Setting this keyword to 1 creates a test bench that applies chain test patterns in serial modeand all other patterns in parallel mode. It is set to 0 by default.

• VERILOG_SIGNAL_SPY {1 | 0};

Setting this keyword to 1 creates a test bench that specifies to use the SignalSpy functions$signal_force, $signal_release, and $init_signal_spy (for observing the scan outs) to do aparallel load of the scan chain. There are three integer variables in the test bench that youcan change from "0" to "1" to get verbose messaging from the SignalSpy functions. Thevariables are _ssi_verbose for $init_signal_spy, _ssf_verbose for $signal_force, and_ssr_verbose for $signal_release. The default is 0, which specifies to use the standardverilog force and release to do a parallel load of the scan chain.

These functions are ModelSim only functions that only work with the ModelSim Verilogsimulator. The SignalSpyPathSeperator in the modelsim.ini file must not be set or be set tothe default of "/".

• 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’ numberof Tessent FastScan or FlexTest patterns. The simulation message will be “Simulated ‘X’patterns”.

• VERILOG_TOP_NAME string;

This keyword allows you to specify a new top level module name for the Verilog testbench.The default behavior is to generate a default top level module name based on the designname and the name of the pattern file.

• VERILOG_UNCOMPRESS_PAT {1 | 0};

If a compressed filename is specified on the Save Patterns -verilog command line,VERILOG_UNCOMPRESS_PAT will automatically be set to uncompress the patterns anduse them. The Verilog testbench will default to checking for the compressed file and usingit. If not found, it will then look for the same file uncompressed. The testbench still needs tobe uncompressed by you before it can be compiled and simulated.

If this keyword is set to 1, it will force the tool to add code to the testbench to automaticallycopy the compressed pattern file, uncompress it, and when the pattern file has been appliedto the simulation, remove the temporary uncompressed pattern file. You will still need touncompress the Verilog testbench before simulation.

Issuing a 0, the default behavior, will cause the testbench to not include these capabilities.

Note that all files are compressed; not just pattern files. Parallel testbench, scan chainnaming files, po naming files and patterns, as well as serial testbench files are compressed.



November 2010

• 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 same valueof the previous non-scan vector. To deactivate, issue a 0 (the default) with this keyword.

• WGL_ALT_BIDI {1 | 0};

Allows you to change the syntax of how bidirectional signals are represented in the vectorpin 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. There must betwo entries for the bidirectional pin, one specifying the input side and one specifying theoutput 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 only oneentry for the bidirectional pin with no direction, but with two states. Every state in the actualvector is currently separated by spaces. With the addition of this WGL_ALT_BIDI 1setting, the states for the bidirectional pin will be listed side-by-side with no spaceseparation. 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_ALT_VECT_ANN {1 | 0};

If set to 1, this keyword will use alternate annotation statements for beginnings of patternsand vector boundaries. These alternate annotations can help the WGL file be processed byother third party tools. The default is 0.

• 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 strobe timesspecified in timeplate definitions. Additionally, an output value showing the ‘X’ state willappear after the strobe time.

If the strobe_window is set to 0, then this additional output value showing the ‘X’ state afterthe 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_FULL_CHAIN {1 | 0};

When set to 1 (true, the default) this keyword alters the scancell and scanchain blocks of theWGL to reflect all cells in the chain, regardless of the number of pre- or post-shifts (numberof apply shifts). The group statements only reflect what is loaded minus the post shift. Thescanstate and group have to match. To deactivate, and for backwards compatibility, issue a 0(false).

WGL_FULL_CHAIN example follows.

Original WGL File (WGL_FULL_CHAIN false)... scancell { Group: grp1 } { Chain: REG1 } "u22"; "u23"; "u10"; "u11"; "u12"; groupgrp1REG1 ["u22", "u23", "u10", "u11", "u12"]; end scanchain { Group: grp1 } REG1_chain[ "sdi", "u12", "u11", !, "u10", "u23", "u22", "sdo"]; end ... scanstate OREG1_sts000000_000002 := groupgrp1REG1 (XXXXX); IREG1_sts000000_000002 := groupgrp1REG1 (11010); ... end ...

WGL_FULL_CHAIN default TRUE... scancell { Group: grp1 } { Chain: REG1 } "u22"; "u23"; "u10"; "u11"; "u12"; "u13"; groupgrp1REG1 ["u22", "u23", "u10", "u11", "u12"]; end scanchain { Group: grp1 } REG1_chain[ "sdi", "u13", "u12", "u11", !, "u10", "u23", "u22","sdo"]; end ... scanstate



November 2010

OREG1_sts000000_000002 := groupgrp1REG1 (XXXXX); IREG1_sts000000_000002 := groupgrp1REG1 (11010); ... end ...

• WGL_FULL_SCANGROUP {1 | 0};

This keyword when set to 1 (true) will create the Scan sections with the full chain. Thiskeyword will alter the scainchain, scancell, and scanstate blocks in WGL to reflect all cellsin the chain, regardless of the number of pre- or post-shifts. To deactivate, and forbackwards compatibility, issue a 0 (false, the default).

WGL_FULL_SCANGROUP example follows.

WGL_FULL_SCANGROUP true (default FALSE) (WGL_FULL_CHAIN true also)... scancell { Group: grp1 } { Chain: REG1 } "u22"; "u23"; "u10"; "u11"; "u12"; "u13"; groupgrp1REG1 ["u22", "u23", "u10", "u11", "u12", "u13"]; end scanchain { Group: grp1 } REG1_chain[ "sdi", "u13", "u12", "u11", !, "u10", "u23", "u22","sdo"]; end ... scanstate OREG1_sts000000_000002 := groupgrp1REG1 (XXXXXX); IREG1_sts000000_000002 := groupgrp1REG1 (X10100); ... end ...

• 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 statement andin actual patterns for grouping states. To deactivate, issue a 0 (the default) with thiskeyword.

• WGL_INV_SC {1 | 0};

If set to 1, this keyword will remove inversion data from scan chain definitions, and specifyscan data as it would appear to be shifted in, instead of parallel deposited. According to theWGL data model, a WGL file that uses this option no longer correctly matches the designnetlist. However, some third party tools work faster with the inversion data removed. Thedefault is 0.

• WGL_NO_SCANX {1 | 0};

If set to 1, this keyword replaces all X scan load values in the WGL pattern output with 0scan load values. The default is 0.



• 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 the commandprompt. To deactivate, issue a 0 (the default) with this keyword.

Note that the WGL_NOMEASURE_CLOCK keyword may cause some WGL readers tohave problems reading the file. The following warning message will be issued (once) if thekeyword is specified in the parameter file and if there is at least one signal using the alteredsyntax:

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

• WGL_ONE_ILLINOIS {1 | 0};

This keyword when set to 1 (or true) will cause the WGL output to have only one scan statedefined per pattern for multiple scan chains that share a single scan input pin. In otherwords, to force the tool to produce a single scan state for chains that share a common scaninput 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 states definedfor each scan chain, whether or not they share scan input pins. The default for scan stateswhen multiple scan chains share a common scan input is to list the scan states for each cellin each chain, the same as if the chains did not share a scan input.

• WGL_PATTERN_NAME string;

Changes the default name of the WGL pattern block from “Chain_scan_test” to the value ofthe string.

• WGL_TRIM_PULSE {1 | 0};

Issuing a 1 with this keyword will cause the input timing to drop the leading 0 ns force, tothe off state of the clock. Removing the initial force to the off state of a clock may not beappropriate for all testers and translation processes, and you need to understand alldownstream processes that will use the resultant files. To deactivate, issue a 0 (the default)with this keyword.



November 2010

Note that the WGL_TRIM_PULSE keyword will generate illegal syntax in the WGL filewhich may cause some WGL readers to have problems reading the file. The followingwarning message will be issued (once) if the keyword is specified in the parameter file andif there is at least one signal using the altered syntax:

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_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_VERG_ESC {1 | 0};

Issuing a 1 with this keyword specifies for busses to be expanded in the declaration sectionsof the WGL output. To deactivate, issue a 0 (the default) with this keyword.

• WGL_VTRAN_PADSC {1 | 0};

If set to 1, this keyword will pad all scan data to be same length. Padding all scan data to bethe 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.


Appendix AGetting Help

There are several ways to get help when setting up and using Tessent™ software tools.Depending on your need, help is available from documentation, online command help, andMentor 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:

http://supportnet.mentor.com

For more information on setting up and using Tessent documentation, see the “Using TessentDocumentation” chapter in the Managing Mentor Graphics Tessent Software 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://supportnet.mentor.com/about/

If you have questions about a software release, you can log in to SupportNet and searchthousands of technical solutions, view documentation, or open a Service Request online at:


If your site is under current support and you do not have a SupportNet login, you can register forSupportNet by filling out the short form at:

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

All customer support contact information can be found on our web site at:

http://supportnet.mentor.com/contacts/supportcenters/index.cfm


http://supportnet.mentor.com/about/


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

http://supportnet.mentor.com/contacts/supportcenters/index.cfm


Getting HelpMentor Graphics Support

November 2010


Appendix BUsing the Tessent Tcl Interface

A Tcl-based command interface is used by the following Tessent products:

• Tessent FastScan

• Tessent TestKompress

• Tessent Diagnosis

• DFTAdvisor

• FlexTest

The Tcl interface provides basic Tcl capabilities within the Tessent tool session, either at thecommand line or in dofiles. You can embed Tcl constructs in tool commands. You can alsoembed tool commands within Tcl constructs the same as any Tcl command.

If Tcl procedures are available in separate files, you can source these files from within the toolor dofiles. You can also place Tcl procedures in a .tool_startup file so that they are available foruse. Tcl file input/output is also supported.

The following sections explain using the Tcl interface:

Using Tcl Within the Tessent Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622Tcl Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622

Modifying Existing Tessent Dofiles for Use with Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623Dollar Sign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Quotation Marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Set Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Brackets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624Escape Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625Optional Single Quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

ATPG Accelerator Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Before and After LSF Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Before and After LSF Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

Special Tcl Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626Tcl Comments Can Be Tricky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627Tcl Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628


Using the Tessent Tcl InterfaceUsing Tcl Within the Tessent Tools

November 2010

Using Tcl Within the Tessent ToolsYou can use Tcl variables interchangeably with legacy Tessent tool variables and environmentvariables.

Mentor Graphics recommends using Tcl syntax for setting and referencing variables, includingusing $env(ENVARNAME) for accessing environment variables. For example, if the value ofenvironment variable ‘foo’ equals ‘mode1’ ($foo = mode1), you can compare this value to a Tclvariable value using the following syntax:

set bar mode2if {$env(foo) == $bar} {puts Match} else {puts "No match"}

In addition, the tool returns all output of tool commands, which you can assign to a variable. If acommand fails, then the command returns the string DFT_ERROR.

NoteYou should use Tcl namespaces to avoid any possibility of creating procedures thatconflict with existing tool or Tcl commands.

When embedding comments within a dofile, the tool processes as a comment any entrybeginning with a double slash (//) until the end of line. In Tcl files, the pound sign ( # ) specifiesa comment that goes to the end of line. When using dofiles containing Tcl constructs, the toolrecognizes both ‘//’ and ‘#’ as the start of a comment that extends to the end of the line.

Tcl Examples

Example 1In this example, the Add Scan Chains command is used to define every scan chain in the design.This command is sometimes used hundreds of times and makes the dofile very long. Using Tcl,you can shorten this action substantially by using a loop construct as shown in the followingexample:

for {set xx 1} {$xx < 257} {incr xx} { add scan chains int chain$xx group1 /top/edt_si$xx /top/edt_so$xx}

For the values of xx from 1 up to 256, the tool executes a separate Add Scan Chain command.The transcript and logfile will contain all 256 Add Scan Chain commands.

Example 2The following example controls the flow of creating test patterns and uses a variable to executedifferent commands based on the variable’s value:

if {$mode == stuck} {

Using the Tessent Tcl InterfaceModifying Existing Tessent Dofiles for Use with Tcl


set fault type stuck . . .} elseif {$mode == transition} { set fault type transition no_shift_launch set pattern type sequential 2 . . .}

Only the executed commands appear in the tool’s transcript and log file.

Example 3This example places the output from a report command in a variable for subsequent processing:

SETUP> set chain_report [report scan chain]

chain = chain1 group = grp1 input = /scan_in1 output = /scan_out1 length = unknown

. . .


SETUP> puts $chain_report


. . .


Modifying Existing Tessent Dofiles for Use withTcl

When using an existing Tessent tool dofile with the Tcl interface, you should evaluate the dofilefor issues that could cause incorrect evaluation by the Tessent Tcl interpreter. The mostcommon issue you can run across with an existing dofile is accounting for Tcl specialcharacters—see Table B-1, which provides a list of typically-used Tcl special characters.

The following sections provide guidance for correcting the most common issues you could runacross:

• Dollar Sign

• Quotation Marks

• Set Command

• Brackets

• Escape Identifiers

• Optional Single Quotes

• Environment Variables



November 2010

Dollar SignA dollar sign ($) in Tcl specifies variable substitution. In some netlists, path names (forexample, like foo/pin$p7) can contain the dollar sign. When using path names with dollar signs,enclose the path name with braces ({ }) to prevent the tool from substituting the value as shownin the following example:

report gates {foo/pin$p7}

Quotation MarksIn Tcl, quotation marks ( " " ) instruct the Tcl interpreter to treat the enclosed words as a singleargument. For example:

puts " Hello World "

If embedded quotes are required, then you must use backslashes ( \ ) to escape the embeddeddouble quotes. For example:

puts " Hello \"World\" "

Otherwise, the tool issues an error message.

Set CommandThe Tcl set command assigns a value to a variable, for example set color blue. Many DFT toolcommands use “Set ...” as part of the command, which can conflict with this syntax. Forexample, if you issue the command “Set Edt Foobar,” then the tool issues an error because thetool interprets this as the command “Set Edt”.

BracketsBrackets ([ ]) in Tcl enclose a command the tool evaluates. Valid vector subscript notation suchas “report gate A/B/in[0]” is correctly recognized by the tool as a vector element. Other usage ofbrackets in a tool command, however, can cause Tcl to attempt to evaluate the contents andresult in a command failure as demonstrated in the following usage of the Set Distributedcommand passing an option to LSF with brackets.

set distributed lsf_options -q $env(SPAWN_Q) -R select[opteron]

To address this, either enclose the end part with braces ({ }) or use a backslash ( \ ) to escape theopening bracket ( [ ) as shown in the following examples:

set distributed lsf_options -q $env(SPAWN_Q) -R {select[opteron]}

set distributed lsf_options -q $env(SPAWN_Q) -R select\[opteron]

If you put the entire argument in braces ({ }), then $SPAWN_Q is interpreted when the toolissues its bsub command with $SPAWN_Q as an argument.



Escape IdentifiersIn general, the Tessent tools recognized the following escape identifiers:

• The escape the bracket ([) for vector elements.

• The Verilog escape identifier ( \ ). Note, however, that the tool only recognizes thecharacter immediately following the escape identifier.

To escape a single character, use the backslash (\) immediately before the character you want toescape.

For dofiles, see “Quotation Marks.”

Optional Single QuotesOptional single quotes (’ ’) are no longer valid for Tessent commands.

For example, the following produces an error:

set distributed sge_options ‘ -p -50’

Correct this by using no quotes, double quotes, or braces:

set distributed sge_options -p -50

set distributed sge_options “-p -50”

set distributed sge_options {-p -50}

Environment VariablesTo preserve backward compatibility, all environment variables are set as Tcl variables atinvocation so the variables may be referenced as $var or $env(var). Subsequently, if you set aTcl variable with the same name as an existing environment variable, the tool returns the Tclvariable’s new value when you reference $var. You must use $env(var) to return the originalenvironment variable.


Using the Tessent Tcl InterfaceATPG Accelerator Variables

November 2010

ATPG Accelerator VariablesWhen using distributed Tessent FastScan or Tessent TestKompress, you must ensure yourATPG Accelerator variables contain the correct Tcl syntax for use by the Set Distributedcommand. The following examples show the before and after Tcl modifications for LSF andSGE options.

Before and After LSF Example 1In this example, several Set Distributed command variables contain data that the tool passes onas arguments to other shell commands. If this data contains characters that can be interpreted asTcl prior to being stored, then the data needs to be protected so that it can be passed oncorrectly.

The brackets ([ ]) embedded in the quoted string will cause the Tessent tool to incorrectlyevaluate the contents of the bracketed items:

set distributed lsf_options -R "select[type==LINUX64 && mem> 200 && swp > 200 ]"

Replace the double quotes (" ") with braces ({ }) to correct this.

set distributed lsf_options -R {select[type==LINUX64 && mem> 200 && swp > 200 ]}

Before and After LSF Example 2In this example, single quotes (’ ’) where previously used to specify the LSF use queue:

set distributed lsf_options ’-q myqueue’

Replace the single quotes with double quotes (" ").

set distributed lsf_options "-q myqueue"

Alternatively, you can remove the single quotes or uses braces ({ }).

Special Tcl CharactersIn Tcl scripts, you often see characters used for special purposes. For a complete list of specialcharacters, you should consult the a Tcl resource. Table B-1 lists and describes the more-common special characters you can encounter when reading the examples in this manual.

Table B-1. Common Tcl Characters

Character

; The semicolon terminates the previous command, allowing you to place morethan one command on the same line.

\ Used at the end of a line, the backslash continues a command on the followingline.

Using the Tessent Tcl InterfaceSpecial Tcl Characters


Tcl Comments Can Be TrickyIn Tcl, you create the equivalent of comments with the pound sign ( # ). When using the poundsign, you must use it where a command starts, and at the beginning of a command, not within acommand. The pound sign directs the Tcl compiler to not evaluate the rest of the line.

Tricky Point 1: Evaluate does not equal parse. Despite the pound sign, the comment belowgives an error because Tcl detects an open lexical clause.

# if (some condition) {if { new text condition } {...}

Tricky Point 2: The apparent beginning of a line is not always the beginning of a command:

\$ The backslash with other special characters, like a dollar sign, instructs the Tclinterpreter to treat the character literally.

\n The backslash with the letter “n” instructs the Tcl interpreter to create a new line.

$ The dollar sign in front of a variable name instructs the Tcl interpreter to accessthe value stored in the variable.

[ ] Square brackets group a command and its arguments, instructing the Tclinterpreter to treat everything within the brackets as a single syntactical object.You use square brackets to write nested commands.

Example:

set chain_report [report scan chain]

{ } Curly braces instruct the Tcl interpreter to treat the enclosed words as a singlestring. The Tcl interpreter accepts the string as is, without performing anyvariable substitution or evaluation.

Example:Create a string that contains special characters, such as $ or \:

set my_string {This book costs $25.98.}

" " Quotes instruct the Tcl interpreter to treat the enclosed words as a single string.However, when the Tcl interpreter encounters variables or commands withinstring in quotes, it evaluates the variables and commands to generate a string.

Example:Create a string that displays a final cost calculated by adding two numbers:

set my_string “This book costs \$[expr $price + $tax]”

Table B-1. Common Tcl Characters (cont.)

Character


Using the Tessent Tcl InterfaceSpecial Tcl Characters

November 2010

# This is a comment

In the following code snippet, the line beginning with “# -type” is not a comment, because theline right above it has a line continuation character (\). In fact, the “#” confuses the Tclinterpreter, resulting in an error when it attempts to create the tk_messageBox.

tk_messageBox -message "The diagnosis report was successfully written."\# -type ok

# and this is also a comment. This one will span \multiple lines, even without the # at the beginning \of the second and third lines.

In general, it is good practice to begin all comment lines with a #.

Tricky Point 3: The beginning of a command is not always at the beginning of a line:

Usually, you begin new commands at the beginning of a line. That is, the first character that isnot a space will be the first character of the command name. However, you can combinemultiple commands into one line using the semicolon “;” to signal the end of the previouscommand:

set myname “John Doe” ;set this_string “next command”

set yourname “Ted Smith” ; #this is a comment

See also “Example 3.”

Tcl ResourcesMentor Graphics Corporation recommends you take advantage of one or more of the excellentbooks and websites on the language. The following URL is provided to give you a place to startin your search for the reference material that works best for you. It is not an endorsement of anybook or website.

http://www.tcl.tk/

http://www.tcl.tk/

629

A B F GDC E H I J K L M N O P Q R S T U V XW Y Z

Tessent Common Resources Manual for ATPG Products, v9.2November 2010

— Symbols —#include statement, 515

— A —A rules, 24Add Models command, 440Alias statements, 518ALL_FIXED_CYCLES, 591ALL_FLATTEN_TIMING, 591ALL_MIN_SCAN_LOAD, 592ALL_NO_CYCLE_OPT, 592ALL_NO_LOOP, 592ALL_NO_PATTERN_TYPE, 592ALL_TIME_RESOLUTION, 593Always block, 525Always block example, 526Always block statements

always_statement, 526force, 526pulse, 526

Always block syntax, 526Array

delimiter, 371library model attribute, 371RAM example, 371, 421read-only RAM example, 422ROM example, 418

— B —B rules, 35BIST rules, 35

— C —C rules, 44Clock cone, 56, 57, 64Clock procedure, 550 to 551Clock_run procedure, 552Clocks

Browser window, 315domain analysis, 285viewing faults, 285, 315

CommandsAdd Models, 440Dofile, 442Help, 444Run, 446Set Asynchronous Control_logic, 447Set Behavioral Processing, 449Set Dofile Abort, 451Set Hold Check, 455Set System Mode, 461Set Verification, 463System, 465

Construct supportfor Verilog, 473

CTL_ONE_PAT, 593CTL_ONE_PROTO, 593CTL_STIL_0, 593CTL_STIL_1, 593CTL_TRIM_PULSE, 605Cycle statements

bidi_force_off, 531bidi_force_pi, 530bidi_measure_po, 530condition, 531expect, 531force, 531force_pi, 530force_sci, 530force_sci_equiv, 530initialize, 531measure, 531measure_po, 530measure_sco, 530observe_method, 532pulse, 532pulse_capture_clock, 531pulse_read_clock, 531pulse_write_clock, 531restore_bidi, 531restore_pi, 531

Index

630November 2010



— D —D rules, 85Design rules checking

basic troubleshooting, 17 to 23BIST rules, 35 to 40clock rules, 44 to 84data rules, 85 to 101EDT rules, 150 to 164extra rules, 102 to 120general rules, 145 to 150procedure rules, 166 to 193RAM rules, 24 to 34reporting gate data, 20scannability rules, 204 to 208setting gate data, 19setting gate level, 18setting rule handling, 18timing rules, 233 to 241trace rules, 209 to 221with ATPG analysis, 18within DFTAdvisor, 17

DFTVisualizerCommand Quick Reference, 336opening, 255overview, 255windows, 255

Dofile command, 442DRC messages

oscillation limitation, 252other DRC messages, 252RAM summary results and test capability,

253transparent capture handling analysis, 252

— E —E rules, 102Effect cone, 57Example

PLL model and named capture procedure,560

— F —FDTL_TEST_NAME, 594FDTL_TEST_NUM, 594FDTL_TEST_SUFFIX, 594FlexTest commands

report DRC rules, 23set trace report, 23

FTDL parameter file example, 594FTDL_DESIGNER, 594FTDL_MAX_PAT_BLOCK, 594FTDL_REVISION, 594FTDL_ZMODE_MES, 594

— G —G rules, 145group timing information, 607Group TITDL timing information, 607

— H —Help command, 444

— I —Include statement, 515Initialization files, 425Instance name, 610

— K —K rules, 150Keywords

ALL_FIXED_CYCLES, 591ALL_FLATTEN_TIMING, 591ALL_MIN_SCAN_LOAD, 592ALL_NO_CYCLE_OPT, 592ALL_NO_LOOP, 592ALL_NO_PATTERN_TYPE, 592ALL_TIME_RESOLUTION, 593CTL_ONE_PAT, 593CTL_ONE_PROTO, 593CTL_STIL_0, 593CTL_STIL_1, 593CTL_TRIM_PULSE, 605FTDL_DESIGNER, 594FTDL_MAX_PAT_BLOCK, 594FTDL_REVISION, 594FTDL_TEST_NAME, 594FTDL_TEST_NUM, 594FTDL_TEST_SUFFIX, 594FTDL_ZMODE_MES, 594SIM_SHIFT_DEBUG, 596SIM_TIMEPLATE_COM, 597SIM_VECTOR_COMM, 597SIM_VECTYPE_SIGNAL, 598

631Tessent Common Resources Manual for ATPG Products, v9.2November 2010


STIL_2005_SCAN, 599STIL_MIN_QUOTE, 601STIL_NOMESURE_CLOCK, 601STIL_PAT_ANN, 601STIL_PAT_CMT, 602STIL_PAT_LAB, 602STIL_SCAN_ANN1, 602STIL_STRUCTURAL, 602STIL_TI_TITLE, 605STIL_VECTOR_ANN, 605TEST_SETUP_EXPECT, 608TITDL_CHAIN_SETTYPE, 607TITDL_CUSTOMER, 607TITDL_GROUP_TIMING, 607TITDL_KEEP_SCANOUT, 607TITDL_LIBRARY, 607TITDL_PARTNUM, 607TITDL_PSEUDO_PREFIX, 607TITDL_REVISION, 608TITDL_SETNAME, 608TITDL_SETTYPE, 608VERILOG_COMPARE_X, 609VERILOG_EARLY_RELEASE, 610VERILOG_EARLY_RELEASE_TIME,

610VERILOG_INCLUDE, 610VERILOG_INSTANCE_NAME, 610VERILOG_KEEP_PATH, 611VERILOG_MASK_FILE, 611VERILOG_MODULE_INCLUDE, 612VERILOG_NO_MEASURE_IN, 612VERILOG_SIM_STATUS, 613VERILOG_TOP_NAME, 613VERILOG_UNCOMPRESS_PAT, 613WGL_ADD_LASTX, 614WGL_ALT_BIDI, 614WGL_ALT_VECT_ANN, 614WGL_EDGE_STROBE, 614WGL_FULL_CHAIN, 615WGL_FULL_SCANGROUP, 616WGL_GROUP_PIN, 616WGL_INV_SC, 616WGL_NOMEASURE_CLOCK, 617WGL_ONE_ILLINOIS, 617WGL_PATTERN_NAME, 617

WGL_TRIM_PULSE, 617WGL_VECTOR_ANN, 618WGL_VERG_ESC, 618WGL_VTRAN_PADSC, 618

— L —lcVerify

overview, 501results files, 503

sim.log, 503transcript, 503verify.results, 503

running from the shell, 502troubleshooting

DRC violations, 508impact of low coverage, 509one model at a time, 508test coverage, 508

Library compiler commandsadd model, 440delete model, 441dofile, 442exit, 443help, 444report environment, 446run, 446set dofile abort, 451set system mode, 461system, 465write library, 466

Library verification, 501

— M —Modeling for optimal test coverage, 510

— N —Named capture procedure, 555

— O —Oscillation limitation, 252

— P —P rules, 166Parameter file, 588Parameter file keywords

FTDL_DESIGNER, 594FTDL_MAX_PAT_BLOCK, 594

632November 2010



FTDL_REVISION, 594FTDL_TEST_NAME, 594FTDL_TEST_NUM, 594FTDL_TEST_SUFFIX, 594FTDL_ZMODE_MES, 594

Pattern fileuncompressing, 613

PLL model and named capture procedureexample, 560

Procedure statementsapply, 530cycle, 526scan_group, 528timeplate, 529

pulse generators, 414

— R —RAM

_cram model example, 420_ram model example, 419array example, 418, 421example, 417initialization files, 425library primitives, 417limitations, 431model attributes, 423modeling, 415 to 431port behavior, 425read_write port behavior, 429rules checking, 24 to 34

RAM summary results and test capability, 253Read-only RAM

array example, 422ROM

_rom model example, 418array example, 418example, 416initialization files, 425limitations, 431model attributes, 423modeling, 415 to 431port behavior, 425read_write port behavior, 429

Run command, 446

— S —Scan chain trace rules, 209 to 221Scannability rules checking, 204 to 208Sequential_transparent procedure, 548 to 550Set Asynchronous Control_logic, 447Set Behavioral Processing command, 449Set Dofile Abort command, 451Set Hold Check command, 455Set statement, 515Set statements

default_timeplate, 517strobe_window time, 516time scale, 515

Set System Mode command, 461Set Verification command, 463Shift procedure, 541

alternate, 542SIM_SHIFT_DEBUG, 596SIM_TIMEPLATE_COM, 597SIM_VECTOR_COMM, 597SIM_VECTYPE_SIGNAL, 598Simulation mismatches

for ChainTest patterns, 612STIL parameter, 588STIL_2005_SCAN, 599STIL_MIN_QUOTE, 601STIL_NOMESURE_CLOCK, 601STIL_PAT_ANN, 601STIL_PAT_CMT, 602STIL_PAT_LAB, 602STIL_SCAN_ANN1, 602STIL_STRUCTURAL, 602STIL_VECTOR_ANN, 605Strength propagation, 476Sub_procedure, 570Suffix

adding to the test block, 594System command, 465

— T —T rules, 209Tessent FastScan commands

report DRC rules, 23set trace report, 23

test block

633Tessent Common Resources Manual for ATPG Products, v9.2November 2010


adding a suffix, 594Test procedure file

comparison to old format, 571defined, 511DRC checking, 511procedures, 537statements, 515syntax rules, 511timing variables, 519

Test procedurescapture, 554clock_po, 561clock_sequential, 563init_force, 564load_unload, 544master_observe, 547ram_passthru, 563ram_sequential, 562sequential, 566shadow_control, 546shadow_observe, 548shift, 541skew_load, 551sub_procedure, 570test_end, 565test_setup, 538

Test_end procedure, 565TEST_SETUP_EXPECT, 608TI title block

changing with STIL_TI_TITLE, 605Time scale

setting, 515Timeplate statements

bidi_force_pi, 523bidi_measure_po, 523force, 523force_pi, 523measure, 523measure_po, 523offstate, 522period, 524pulse, 523

TITDL, 607TITDL parameters, 588TITDL_CHAIN_SETTYPE, 607

TITDL_CUSTOMER, 607TITDL_GROUP_TIMING, 607TITDL_KEEP_SCANOUT, 607TITDL_LIBRARY, 607TITDL_PARTNUM, 607TITDL_PSEUDO_PREFIX, 607TITDL_REVISION, 608TITDL_SETNAME, 608TITDL_SETTYPE, 608Title block

changing with STIL_TI_TITLE, 605Trace rules checking, 209 to 221Transparent capture handling analysis, 252Transparent_capture cells, 99, 100, 551tscale, 515

— V —Verilog

construct support, 473instance name, 610

Verilog parameters, 588VERILOG_COMPARE_X, 609VERILOG_EARLY_RELEASE, 610VERILOG_EARLY_RELEASE_TIME, 610VERILOG_INCLUDE, 610VERILOG_INSTANCE_NAME, 610VERILOG_KEEP_PATH, 611VERILOG_MASK_FILE, 611VERILOG_MODULE_INCLUDE, 612VERILOG_NO_MEASURE_IN, 612VERILOG_SIM_STATUS, 613VERILOG_TOP_NAME, 613VERILOG_UNCOMPRESS_PAT, 613

— W —WGL_ADD_LASTX, 614WGL_ALT_BIDI, 614WGL_ALT_VECT_ANN, 614WGL_EDGE_STROBE, 614WGL_GROUP_PIN, 616WGL_INV_SC, 616WGL_NOMEASURE_CLOCK, 617WGL_ONE_ILLINOIS, 617WGL_PATTERN_NAME, 617WGL_TRIM_PULSE, 617WGL_VECTOR_ANN, 618

634November 2010



WGL_VERG_ESC, 618WGL_VTRAN_PADSC, 618

Third-Party Information

• Third-Party Software for Tessent Products

End-User License AgreementThe latest version of the End-User License Agreement is available on-line at:

www.mentor.com/eula

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively“Products”) between the company acquiring the Products (“Customer”), and the Mentor Graphics entity thatissued the corresponding quotation or, if no quotation was issued, the applicable local Mentor Graphics entity(“Mentor Graphics”). Except for license agreements related to the subject matter of this license agreement whichare physically signed by Customer and an authorized representative of Mentor Graphics, this Agreement and theapplicable quotation contain the parties' entire understanding relating to the subject matter and supersede allprior or contemporaneous agreements. If Customer does not agree to these terms and conditions, promptly returnor, in the case of Software received electronically, certify destruction of Software and all accompanying itemswithin five days after receipt of Software and receive a full refund of any license fee paid.

1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places andMentor Graphics accepts purchase orders pursuant to this Agreement (“Order(s)”), each Order will constitute a contractbetween Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of thisAgreement, any applicable addenda and the applicable quotation, whether or not these documents are referenced on theOrder. Any additional or conflicting terms and conditions appearing on an Order will not be effective unless agreed inwriting by an authorized representative of Customer and Mentor Graphics.

1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of suchinvoice. Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-halfpercent per month or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight,insurance, customs duties, taxes or other similar charges, which Mentor Graphics will state separately in the applicableinvoice(s). Unless timely provided with a valid certificate of exemption or other evidence that items are not taxable, MentorGraphics will invoice Customer for all applicable taxes including, but not limited to, VAT, GST, sales tax and service tax.Customer will make all payments free and clear of, and without reduction for, any withholding or other taxes; any suchtaxes imposed on payments by Customer hereunder will be Customer’s sole responsibility. If Customer appoints a thirdparty to place purchase orders and/or make payments on Customer’s behalf, Customer shall be liable for payment underOrders placed by such third party in the event of default.

1.3. All Products are delivered FCA factory (Incoterms 2000), freight prepaid and invoiced to Customer, except Softwaredelivered electronically, which shall be deemed delivered when made available to Customer for download. MentorGraphics retains a security interest in all Products delivered under this Agreement, to secure payment of the purchase priceof such Products, and Customer agrees to sign any documents that Mentor Graphics determines to be necessary orconvenient for use in filing or perfecting such security interest. Mentor Graphics’ delivery of Software by electronic meansis subject to Customer’s provision of both a primary and an alternate e-mail address.

2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement,including any updates, modifications, revisions, copies, documentation and design data (“Software”) are copyrighted, tradesecret and confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retainall rights not expressly granted by this Agreement. Mentor Graphics grants to Customer, subject to payment of applicablelicense fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form (exceptas provided in Subsection 5.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on thecomputer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius.Customer may have Software temporarily used by an employee for telecommuting purposes from locations other than aCustomer office, such as the employee's residence, an airport or hotel, provided that such employee's primary place ofemployment is the site where the Software is authorized for use. Mentor Graphics’ standard policies and programs, which varydepending on Software, license fees paid or services purchased, apply to the following: (a) relocation of Software; (b) use ofSoftware, which may be limited, for example, to execution of a single session by a single user on the authorized hardware or fora restricted period of time (such limitations may be technically implemented through the use of authorization codes or similardevices); and (c) support services provided, including eligibility to receive telephone support, updates, modifications, andrevisions. For the avoidance of doubt, if Customer requests any change or enhancement to Software, whether in the course of

IMPORTANT INFORMATION

USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THISLICENSE AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES

CUSTOMER’S COMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS ANDCONDITIONS SET FORTH IN THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE

ORDER TERMS AND CONDITIONS SHALL NOT APPLY.

http://www.mentor.com/eula

receiving support or consulting services, evaluating Software, performing beta testing or otherwise, any inventions, productimprovements, modifications or developments made by Mentor Graphics (at Mentor Graphics’ sole discretion) will be theexclusive property of Mentor Graphics.

3. ESC SOFTWARE. If Customer purchases a license to use development or prototyping tools of Mentor Graphics’ EmbeddedSoftware Channel (“ESC”), Mentor Graphics grants to Customer a nontransferable, nonexclusive license to reproduce anddistribute executable files created using ESC compilers, including the ESC run-time libraries distributed with ESC C and C++compiler Software that are linked into a composite program as an integral part of Customer’s compiled computer program,provided that Customer distributes these files only in conjunction with Customer’s compiled computer program. MentorGraphics does NOT grant Customer any right to duplicate, incorporate or embed copies of Mentor Graphics’ real-time operatingsystems or other embedded software products into Customer’s products or applications without first signing or otherwiseagreeing to a separate agreement with Mentor Graphics for such purpose.

4. BETA CODE.

4.1. Portions or all of certain Software may contain code for experimental testing and evaluation (“Beta Code”), which may notbe used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’ authorization, Mentor Graphics grants toCustomer a temporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Codewithout charge for a limited period of time specified by Mentor Graphics. This grant and Customer’s use of the Beta Codeshall not be construed as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not torelease commercially in any form.

4.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code undernormal conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’suse of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluationand testing, Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,weaknesses and recommended improvements.

4.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods andconcepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to performbeta testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications ordevelopments that Mentor Graphics conceived or made during or subsequent to this Agreement, including those basedpartly or wholly on Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will haveexclusive rights, title and interest in all such property. The provisions of this Subsection 4.3 shall survive termination of thisAgreement.

5. RESTRICTIONS ON USE.

5.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include allnotices and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. Allcopies shall remain the property of Mentor Graphics or its licensors. Customer shall maintain a record of the number andprimary location of all copies of Software, including copies merged with other software, and shall make those recordsavailable to Mentor Graphics upon request. Customer shall not make Products available in any form to any person otherthan Customer’s employees and on-site contractors, excluding Mentor Graphics competitors, whose job performancerequires access and who are under obligations of confidentiality. Customer shall take appropriate action to protect theconfidentiality of Products and ensure that any person permitted access does not disclose or use it except as permitted bythis Agreement. Customer shall give Mentor Graphics written notice of any unauthorized disclosure or use of the Productsas soon as Customer learns or becomes aware of such unauthorized disclosure or use. Except as otherwise permitted forpurposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,reverse-compile, reverse-engineer or in any way derive any source code from Software. Log files, data files, rule files andscript files generated by or for the Software (collectively “Files”), including without limitation files containing StandardVerification Rule Format (“SVRF”) and Tcl Verification Format (“TVF”) which are Mentor Graphics’ proprietary syntaxesfor expressing process rules, constitute or include confidential information of Mentor Graphics. Customer may share Fileswith third parties, excluding Mentor Graphics competitors, provided that the confidentiality of such Files is protected bywritten agreement at least as well as Customer protects other information of a similar nature or importance, but in any casewith at least reasonable care. Customer may use Files containing SVRF or TVF only with Mentor Graphics products. Underno circumstances shall Customer use Software or Files or allow their use for the purpose of developing, enhancing ormarketing any product that is in any way competitive with Software, or disclose to any third party the results of, orinformation pertaining to, any benchmark.

5.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correctsoftware errors and enhance or modify the Software for the authorized use. Customer shall not disclose or permit disclosureof source code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees orcontractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source codein any manner except to support this authorized use.

5.3. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense or otherwise transfer theProducts, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior writtenconsent and payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transferwithout Mentor Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’option, result in the immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms

of this Agreement, including without limitation the licensing and assignment provisions, shall be binding upon Customer’spermitted successors in interest and assigns.

5.4. The provisions of this Section 5 shall survive the termination of this Agreement.

6. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer updatesand technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with MentorGraphics’ then current End-User Support Terms located at http://supportnet.mentor.com/about/legal/.

7. AUTOMATIC CHECK FOR UPDATES; PRIVACY. Technological measures in Software may communicate with serversof Mentor Graphics or its contractors for the purpose of checking for and notifying the user of updates and to ensure that theSoftware in use is licensed in compliance with this Agreement. Mentor Graphics will not collect any personally identifiable datain this process and will not disclose any data collected to any third party without the prior written consent of Customer, except toMentor Graphics’ outside attorneys or as may be required by a court of competent jurisdiction.

8. LIMITED WARRANTY.

8.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properlyinstalled, will substantially conform to the functional specifications set forth in the applicable user manual. MentorGraphics does not warrant that Products will meet Customer’s requirements or that operation of Products will beuninterrupted or error free. The warranty period is 90 days starting on the 15th day after delivery or upon installation,whichever first occurs. Customer must notify Mentor Graphics in writing of any nonconformity within the warranty period.For the avoidance of doubt, this warranty applies only to the initial shipment of Software under an Order and does notrenew or reset, for example, with the delivery of (a) Software updates or (b) authorization codes or alternate Software undera transaction involving Software re-mix. This warranty shall not be valid if Products have been subject to misuse,unauthorized modification or improper installation. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’SEXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICEPAID UPON RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION ORREPLACEMENT OF THE PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY, PROVIDEDCUSTOMER HAS OTHERWISE COMPLIED WITH THIS AGREEMENT. MENTOR GRAPHICS MAKES NOWARRANTIES WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETACODE; ALL OF WHICH ARE PROVIDED “AS IS.”

8.2. THE WARRANTIES SET FORTH IN THIS SECTION 8 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NORITS LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TOPRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORSSPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR APARTICULAR PURPOSE AND NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.

9. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY WOULD BEVOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS OR ITSLICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDINGLOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, EVENIF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. INNO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS AGREEMENT EXCEEDTHE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR SERVICE GIVINGRISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS LICENSORSSHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 9 SHALLSURVIVE THE TERMINATION OF THIS AGREEMENT.

10. HAZARDOUS APPLICATIONS. CUSTOMER ACKNOWLEDGES IT IS SOLELY RESPONSIBLE FOR TESTING ITSPRODUCTS USED IN APPLICATIONS WHERE THE FAILURE OR INACCURACY OF ITS PRODUCTS MIGHTRESULT IN DEATH OR PERSONAL INJURY (“HAZARDOUS APPLICATIONS”). NEITHER MENTOR GRAPHICSNOR ITS LICENSORS SHALL BE LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITHTHE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS APPLICATIONS. THE PROVISIONS OFTHIS SECTION 10 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.

11. INDEMNIFICATION. CUSTOMER AGREES TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS ANDITS LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE OR LIABILITY, INCLUDINGATTORNEYS’ FEES, ARISING OUT OF OR IN CONNECTION WITH THE USE OF PRODUCTS AS DESCRIBED INSECTION 10. THE PROVISIONS OF THIS SECTION 11 SHALL SURVIVE THE TERMINATION OF THISAGREEMENT.

12. INFRINGEMENT.

12.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Productacquired by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction.Mentor Graphics will pay costs and damages finally awarded against Customer that are attributable to the action. Customerunderstands and agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notifyMentor Graphics promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance

http://supportnet.mentor.com/about/legal/

to settle or defend the action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of theaction.

12.2. If a claim is made under Subsection 12.1 Mentor Graphics may, at its option and expense, (a) replace or modify the Productso that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the returnof the Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.

12.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware withany product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) theuse of other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) aproduct that Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software providedby Mentor Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; or(h) infringement by Customer that is deemed willful. In the case of (h), Customer shall reimburse Mentor Graphics for itsreasonable attorney fees and other costs related to the action.

12.4. THIS SECTION 12 IS SUBJECT TO SECTION 9 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTORGRAPHICS AND ITS LICENSORS FOR DEFENSE, SETTLEMENT AND DAMAGES, AND CUSTOMER’S SOLEAND EXCLUSIVE REMEDY, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENTOR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.

13. TERMINATION AND EFFECT OF TERMINATION. If a Software license was provided for limited term use, such licensewill automatically terminate at the end of the authorized term.

13.1. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon writtennotice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentialityprovisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation orwinding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of anyprovision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under thisAgreement upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination ofthis Agreement or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped orlicenses granted prior to the termination, which amounts shall be payable immediately upon the date of termination.

13.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in thisAgreement. Upon termination, Customer shall ensure that all use of the affected Products ceases, and shall return hardwareand either return to Mentor Graphics or destroy Software in Customer’s possession, including all copies anddocumentation, and certify in writing to Mentor Graphics within ten business days of the termination date that Customer nolonger possesses any of the affected Products or copies of Software in any form.

14. EXPORT. The Products provided hereunder are subject to regulation by local laws and United States government agencies,which prohibit export or diversion of certain products and information about the products to certain countries and certainpersons. Customer agrees that it will not export Products in any manner without first obtaining all necessary approval fromappropriate local and United States government agencies.

15. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. All Software is commercialcomputer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to US FAR 48 CFR12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. Government or a U.S.Government subcontractor is subject solely to the terms and conditions set forth in this Agreement, except for provisions whichare contrary to applicable mandatory federal laws.

16. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporationand other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.

17. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice andduring Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm toreview Customer’s software monitoring system and records deemed relevant by the internationally recognized accounting firmto confirm Customer’s compliance with the terms of this Agreement or U.S. or other local export laws. Such review may includeFLEXlm or FLEXnet (or successor product) report log files that Customer shall capture and provide at Mentor Graphics’request. Customer shall make records available in electronic format and shall fully cooperate with data gathering to support thelicense review. Mentor Graphics shall bear the expense of any such review unless a material non-compliance is revealed. MentorGraphics shall treat as confidential information all information gained as a result of any request or review and shall only use ordisclose such information as required by law or to enforce its rights under this Agreement. The provisions of this Section 17shall survive the termination of this Agreement.

18. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphicsintellectual property licensed under this Agreement are located in Ireland and the United States. To promote consistency aroundthe world, disputes shall be resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by andconstrued under the laws of the State of Oregon, USA, if Customer is located in North or South America, and the laws of Irelandif Customer is located outside of North or South America. All disputes arising out of or in relation to this Agreement shall besubmitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland whenthe laws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia arising out of or in relation to this Agreement shallbe resolved by arbitration in Singapore before a single arbitrator to be appointed by the chairman of the Singapore International

Arbitration Centre (“SIAC”) to be conducted in the English language, in accordance with the Arbitration Rules of the SIAC ineffect at the time of the dispute, which rules are deemed to be incorporated by reference in this section. This section shall notrestrict Mentor Graphics’ right to bring an action against Customer in the jurisdiction where Customer’s place of business islocated. The United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.

19. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid,unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in fullforce and effect.

20. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes allprior or contemporaneous agreements, including but not limited to any purchase order terms and conditions. Some Softwaremay contain code distributed under a third party license agreement that may provide additional rights to Customer. Please seethe applicable Software documentation for details. This Agreement may only be modified in writing by authorizedrepresentatives of the parties. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequentconsent, waiver or excuse.

Rev. 100615, Part No. 246066

Documents

Dft Common