0% found this document useful (0 votes)

244 views

Modus Ug Testmodes

Uploaded by

Nitish Kumar

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

244 views

Modus Ug Testmodes

Uploaded by

Nitish Kumar

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 281

Modus: Guide 2: Testmodes

Product Version 19.12

December 2019
© 2003–2019 Cadence Design Systems, Inc. All rights reserved.
Portions © IBM Corporation, the Trustees of Indiana University, University of Notre Dame, the Ohio State
University, Larry Wall. Used by permission.
Printed in the United States of America.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Cadence(R) Modus(TM) may include third party software licensed under terms that require display of
notices included in Third Party Licenses and Technologies.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are
used with permission.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document
are attributed to Cadence with the appropriate symbol. For queries regarding Cadence’s trademarks,
contact the corporate legal department at the address shown above or call 800.862.4522. All other
trademarks are the property of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and
contains trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or
distribution of this publication, or any portion of it, may result in civil and criminal penalties. Except as
specified in this permission statement, this publication may not be copied, reproduced, modified, published,
uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence.
Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to
print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its
customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright,
trademark, and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like products or
software, whether for internal or external use, and shall not be used for the benefit of any other party,
whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does
not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such
information will not infringe any third party rights, nor does Cadence assume any liability for damages or
costs of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor
Modus: Guide 2: Testmodes

Contents
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Modus Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Getting Help for Modus and Diagnostics ................................... 12
Extended Command and Message Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Contacting Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Modus and Diagnostics Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Modus Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
What has Changed in this version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
19.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
19.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
19.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1
Build Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Build Testmode Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Database Inputs from Pre-requisite Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
User Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Buid Testmode Keywords of Interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Build Testmode Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Build Testmode Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Build Testmode Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Assignfile Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Unit or Zero Delay Simulations for Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Analyzing Build Testmode Log Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Mode Init and Scan Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Active Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Faults Not Active in any Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Troubleshooting Build Testmode Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

December 2019 3 Product Version 19.12

Reporting Testmode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Basic Command Syntax for report_test_structures . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Scan Chain Information Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Channel Mask Enable Pipeline Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2
Multiple Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Building Multiple Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Cross-Mode Markoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Building a Hierarchy of Testmodes (Parent Testmodes) . . . . . . . . . . . . . . . . . . . . . . . . . 36

3
Delete Testmode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Deleting a Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Deleting Committed Data from a Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4
Design Structures and Testmode Details . . . . . . . . . . . . . . . . . . . . . . 41
Delay Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Customizing a Mode Definition for Delay Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Assumed Scan Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Excluding Specific Flops from a Scan Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Assumed Scan Mode Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
OPMISR Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Introduction to OPMISR and OPMISR+ Compression . . . . . . . . . . . . . . . . . . . . . . . . 46
Generating OPMISR TestMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
OPMISR Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Channel Masking Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Implementing Channel Masking Logic in a Design . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Channel Masking on Pad Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Building a Testmode for OPMISR, OPMISR+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Inserting Block-Level Test Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Commands for Block Level Test Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

December 2019 4 Product Version 19.12

2-D Elastic Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2-D Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Elastic Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Modus ATPG Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Building a Testmode for 2D Elastic Decompression . . . . . . . . . . . . . . . . . . . . . . . . . 83
1149.1 Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
IEEE 1149.1 Boundary Scan Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Boundary Scan Design Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
1149.1 Testmode Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
1149.6 Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The 1149.6 Test Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Changes to the 1149.6 TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Changes to the Output Boundary Scan Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
IEEE 11496 Boundary Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Verifying the Boundary Scan Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
LBIST Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Testmode Statements for LBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Signature Observation Sequences for LBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
On-Product XOR Compression Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
SmartScan Compression Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5
Low Power Gating in XOR Compressions. . . . . . . . . . . . . . . . . . . . 121
Reporting Low Power Gating Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6
Build Testmode Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Testmode Definition File (Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Mode Definition Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Mode Definition Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Assign File (Usually Required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Assign File Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Test Function Attribute Definition ...................................... 163
Determining Which Test Functions to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

December 2019 5 Product Version 19.12

Valid Combinations of Test Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Specifying Test Function Pin Attributes in Design Source . . . . . . . . . . . . . . . . . . . . . . . 209
Tester Description Rules (TDRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
TDR Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Sample TDRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Boundary Scan Design Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
BSDL Extension - Port Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
BSDL Extension for Identifying Image Unwired Ports . . . . . . . . . . . . . . . . . . . . . . . 246
Sequence Definition File (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Mode Initialization Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Automatically Generated Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Writing an Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Custom Scan Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Automatically Generated Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Partition File (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

7
Testmode Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Active and Inactive Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Reporting Inactive Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Debugging Inactive Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Testmode Design States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Tie Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Test Inhibit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Test Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Test Constraint and Clocks Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Mode Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Scan States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Nonscanflush Design State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
MISR Observe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
MISR Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Channel Mask Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
OPCG Load State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

December 2019 6 Product Version 19.12

List of Figures
Figure 4-1 Normal FullScan ATPG Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 4-2 OPMISR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 4-3 OPMISR+ Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 4-4 OPMISR using Scan Fan Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 4-5 On-Product MISR Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 4-6 OPMISR in Functional Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 4-7 OPMISR Scan Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 4-8 OPMISR Read Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 4-9 Normal ATPG Scan Test using OPMISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 4-10 WIDE2 Channel Masking Logic for One Channel . . . . . . . . . . . . . . . . . . . . . . 60
Figure 4-11 WIDE1 Channel Masking with a Single CME Signal. . . . . . . . . . . . . . . . . . . . 61
Figure 4-12 WIDE0 Channel Masking without Mask Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 4-13 Mask Bits Loaded from the Scan-in Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 4-14 Variable Length Overlapped Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 4-15 Exposure from Overlapped Scans without Masking . . . . . . . . . . . . . . . . . . . . 65
Figure 4-16 Scan Overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 4-17 X-Mask Padding Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 4-18 X-Mask 0 Padding Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 4-19 X-Mask Channel Masking on Pad Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 4-20 Testmode Assign File for Full-Scan ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 4-21 Testmode Assign File for OPMISR Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 4-22 Testmode Assign File for OPMISR+ Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 4-23 OPMISR Waveform Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 4-24 Top-Level OPMISR+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4-25 One OPMISR+ Embedded Within a core and Another Within the UDL . . . . . 78
Figure 4-26 2-D Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 4-27 Elastic Decompression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 4-28 Doubling Elastic Decompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

December 2019 7 Product Version 19.12

Figure 4-29 Modus ATPG Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Figure 4-30 Scan Chain with Multiple Boundary Scan Devices . . . . . . . . . . . . . . . . . . . . . 86
Figure 4-31 IEEE 1149.1 Boundary Scan Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 4-32 Typical Boundary Scan Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 4-33 Test Receiver Configured with Input Boundary Cells for Observability and Con-
trollability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 4-34 Changes to Output Boundary Scan Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 4-35 Generation of an AC Test Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 4-36 Generation of an Initialization Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 4-37 JTAG_ACPSCLK, JTAG_ACPSEN, and JTAG_ACPULSE Implementation De-
tails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 4-38 Augmented Output Boundary Cell with 1149.6 Support . . . . . . . . . . . . . . . . 100
Figure 4-39 BC_11496_ACTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 4-40 BC_11496_BIDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 4-41 BC_11496_BIDIR_TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 4-42 BC_11496_BIDIR_TO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Figure 4-43 BC_11496_BIDIR_TO_OO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Figure 4-44 BC_11496_OUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 4-45 BC_11496_OUT_NT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 4-46 BC_11496_OUT_TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 4-47 BC_11496_OUT_TO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 4-48 BC_11496_OUT_TO_OO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 4-49 Internal View of XOR-Compression Macro . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Figure 4-50 XOR Compression Macro Connection to I/O Pins and Scan Channels of Design
117
Figure 4-51 Compression Mode with Both Spreader and Compactor Active . . . . . . . . . . 117
Figure 4-52 Compression Mode with Scan Fanout and Compactor Active . . . . . . . . . . . 118
Figure 4-53 XOR Compression in Full Scan Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 5-1 Low Power Gating Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 5-2 Vertical Striping in LPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure 6-1 Waveforms for Test Function Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Figure 6-2 SIGNATURES Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

December 2019 8 Product Version 19.12

Figure 6-3 TDR_DEFINITION Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Figure 6-4 TEST_PINS Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Figure 6-5 OSCILLATOR_PULSES_PER_TESTER_CYCLE Statement Syntax . . . . . 222
Figure 6-6 TERMINATION Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Figure 6-7 MEASURE Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Figure 6-8 PIN_TIMING Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Figure 6-9 DELAY_PROCESSING Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Figure 6-10 SCAN_REQUIREMENTS Statement Syntax . . . . . . . . . . . . . . . . . . . . . . . 241
Figure 6-11 Design that Requires Multiple Scan Sections . . . . . . . . . . . . . . . . . . . . . . . 255
Figure 6-12 Basic Scanop Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Figure 6-13 Advanced Scanop Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Figure 6-14 TAP Controller State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Figure 6-15 Example scanprecond sequence for TAP scan SPTG, TAP_TG_STATE=TLR
261
Figure 6-16 Example scansequence and scanlastbit sequences, TAP_TG_STATE=TLR262
Figure 6-17 Example scansectionexit and scanexit sequences, TAP_TG_STATE=TLR 262
Figure 6-18 Example misrobserve, misrreset and channelmaskload Sequence. . . . . . . 263

December 2019 9 Product Version 19.12

December 2019 10 Product Version 19.12

Preface

Typographic and Syntax Conventions

The Modus library set uses the following typographic and syntax conventions.
■ Text that you type, such as commands, filenames, and dialog values, appears in Courier
type.
Example: Type build_model -help to display help for the command.
■ Variables appear in Courier italic type.
Example: Use TECHLIB <string> to specify Technology Cell Definition File(s).
■ Optional arguments are enclosed in brackets.
Example: [-language stil|wgl|verilog|tdl]
■ User interface elements, such as field names, button names, menus, menu commands,
and items in clickable list boxes, appear in Helvetica italic type.
Example: Select File - Delete - Model and fill in the information about the model.

December 2019 11 Product Version 19.12

Modus Documentation Roadmap

The following figure depicts a recommended flow for traversing the documentation structure.

Getting
Started Overview and
New User
Quickstart

Models

Testmodes
Guides
Test Structures
Faults
ATPG
Test Vectors
Hierarchical Test

Flow PMBIST
Diagnostics

Modus Flows
Expert
Reference Legacy GUI Stylus Common UI
Documents
Test Pattern Formats GUI Glossary

Getting Help for Modus and Diagnostics

Use the following methods to obtain help information:
1. From the <installation_dir>/tools/bin directory, type cdnshelp and press
Enter. The installed Cadence documentation set is displayed.
❑ To view a book, double-click the desired product book collection and double-click the
desired book title in the lower pane to open the book.

December 2019 12 Product Version 19.12

2. For command and message help, use man <command_name> or man

<msgprefix>messages to display a man page with the requested information (for
example man build_model or man TSVmessages.

Click the Help or ? buttons on Modus forms to navigate to help for the form and its related
topics.

Refer to the following in the Modus: Reference: GUI for additional details:
■ “Help Pull-down” describes the Help selections for the Modus main window.
■ “View Schematic Help Pull-down” describes the Help selections for the Modus View
Schematic window.

Extended Command and Message Help

Messages
■ Display extended help information for a message by entering one of the following
commands either directly on the command line or in the GUI Command Input field:
❑ msgHelp <message_prefix-error_number1> <message_prefix-
error_number1> ...
For example,
msgHelp TSV-001 TSV-315

displays interactive help information for messages TSV-001 and TSV-315.

❑ Clicking on a highlighted message in the GUI Log pops up a window with the
extended help information. Refer to Using the Session Log to View Message Help
in the Modus: Reference: GUI for details.
■ Use man XXXmessages where XXX is the message id prefix. These man pages contain
all the messages for XXX. For example, man TSVmessages.
■ Use man MessageInfo to display general information about the format, severity codes,
and return codes for Modus messages.

Commands
■ Use help command to find all the available command lines. You can simply type help or
use help all to get the complete list. You can give help a portion of the command to find
all the commands that contain that string (for example, help fault will give you all the

December 2019 13 Product Version 19.12

commands that contain "fault" in the name; build_faultmodel, report_faults,

and prepare_fault_subset would all be included in the list along with other
commands that include "fault" in their name).
help <command_name>

will display the purpose of the command.

■ command -help reports all standard keywords that are available for use. The result is
a list of options with valid values, the default in parenthesis (if any), and a very brief
description.
■ man <command_name> provides a man page with all help text for the command and
its options. For example, man build_testmode or man report_chains.
■ command -help {option1 option2}... provides the help for any valid option that
you request. For example, build_model -help {designsource designtop} will
display the help for the designsource and cell options.
■ help_option <option_name> gives the list of commands for which the specified
option is valid along with syntax and default value.
■ <command_name> -help advanced provides help for all the advanced options of
the command.
■ For help on Perl Extension methods, use man perlext to display the list of all Perl
methods and man perlext_<method_name> to display help for a specific method.

Contacting Customer Service

Use the following methods to get help for your Cadence product.
■ Cadence Online Customer Support
Cadence online customer support offers answers to your most common technical
questions. It lets you search more than 40,000 FAQs, notifications, software updates,
and technical solutions documents that give step-by-step instructions on how to solve
known problems. It also gives you product-specific e-mail notifications, software updates,
service request tracking, up-to-date release information, full site search capabilities,
software update ordering, and much more. Go to http://www.cadence.com/support/
pages/default.aspx for more information on Cadence Online Customer Support.
■ Cadence Customer Response Center (CRC)
A qualified Applications Engineer is ready to answer all your technical questions on the
use of this product through the Cadence Customer Response Center (CRC). Contact the

December 2019 14 Product Version 19.12

CRC through Cadence Online Support. Go to http://support.cadence.com and click

Contact Customer Support link to view contact information for your region.
■ IBM Field Design Center Customers
Contact IBM EDA Customer Services at 1-802-769-6753, FAX 1-802-769-7226. From
outside the United States call 001-1-802-769-6753, FAX 001-1-802-769-7226. The e-
mail address is [email protected].

Modus and Diagnostics Tutorials

Modus and Diagnostics tutorials are provided through Rapid Adoption Kits (RAKs) that are
available on Cadence Online Support. To access the RAKs (Rapid Adoption Kits):
1. Login to Cadence Customer Online Support (COS) site.
2. Navigate to Resources > Rapid Adoption Kits.
3. Select the hyperlink Synthesis, Test and Verification Flow.

Modus Licenses
Refer to “ Modus and Diagnostics Product License Configuration” in What’s New for Modus
and Diagnostics for details on product license structure and requirements.

What has Changed in this version

19.12
Added subsection “Ordered CHIs and CHOs” in section “Test Function Attribute Definition”
on page 163.

19.11
There are no changes to this version of document.

19.10
Added a new section “Low Power Gating in XOR Compressions” on page 121.

December 2019 15 Product Version 19.12

December 2019 16 Product Version 19.12

1
Build Testmode

A testmode is a specific test configuration of the design. The configuration defines how the
test structures (such as parallel scan or IEEE 1149.1) are accessed and how clocking is
controlled. Each configuration is defined by the clocking and other test function pins, and the
current test methodology. When you build a testmode, you can specify the following
information:
■ The type of processing (test methodology) to be performed. This includes the type of
scan, the type of faults to be tested, and the type of ATPG to be performed.
■ The test function of pins (clocks, scan enables, test inhibits, etc.)
■ Tester limitations
■ Special sequences required for this design. Note that these sequences are generated by
build_testmode based on test function information and only need to be specified if
there are requirements that cannot be identified automatically. This can include:
❑ special testmode initialization sequences
❑ custom scan operation sequences
❑ special purpose sequences (such as channel masking, signature observation,
diagnostic observation),
■ Identification of On-Product Clock (OPC) logic (PLLs, clock domains, cutpoints, and
pseudo primary inputs)

The following information is identified for use by downstream applications:

■ The testmode initialization sequence (generated automatically or from user defined
sequence)
■ The scan sequence (generated automatically or from user defined sequence)
■ The scan structures (such as scan chains and compression structures)
■ Inactive logic (cannot be observed in the testmode)
■ Active logic (observable and testable via ATPG in the testmode)

December 2019 17 Product Version 19.12

■ OPC logic (PPIs and cutpoints)

In a typical ATPG flow, build_testmode occurs after the logic model has been built. Most
Modus applications require the testmode to exist (e.g., verify_test_structures and
ATPG applications). Although build_faultmodel may be run before a testmode is built, it
is recommended that you build all your testmodes before building the fault model to avoid any
locking issues. The function that identifies the faults per testmode is used by
build_faultmodel if any testmodes exist and is used by build_testmode if the fault
model does not exist; so the results are the same. Refer to Static ATPG Use Model in
Modus: An Overview and Quick Start for more information.
■ To build a testmode using the graphical interface, refer to "Build Testmode" in the
Modus: Reference: GUI.
■ Refer to build_testmode -H or man build_testmode for the command syntax and
supported options.

Example syntax for build_testmode is provided in “Build Testmode Command Examples”

on page 22.
■ workdir is the name of the working directory.
■ testmode is the name for the testmode being examined.

Build Testmode Inputs

The following inputs are used to build a testmode:

Database Inputs from Pre-requisite Tasks

■ Modus model from build_model (required).
■ Modus Fault Model from build_faultmodel (optional). It is recommended that you
build all testmodes before building the faultmodel, but if the faultmodel already exists the
testmode fault information will be calculated during build_testmode.
■ Modus Power Information from read_power_intent. Optional. This data is
automatically accessed for Low Power testmodes.

User Input Files

■ Testmode Definition File (Required) - The mode definition file (modedef) contains
statements that characterize the type of testmode such as the type of scan, the type of

December 2019 18 Product Version 19.12

tests to be generated, the type of faults to be included and the name of the tester
description rule. Modus includes a number of predefined Mode Definition Files in
$Install_Dir/defaults/rules/modedef. These include the following:

Testmode Purpose
FULLSCAN Static or Delay Test/Diagnostics using no compression
COMPRESSION Static or Delay Test/Diagnostics using XOR Compression
OPMISR Static or Delay Test/Diagnostic using OPMISR compression
OPMISRPLUS Static or Delay Test/Diagnostics using OPMISR+ compression
1149 JTAG testmode for 1149.1 verification
1149.mbist MBIST related testmode
2D Elastic Static or Delay Test/Diagnostics using Compression
Compression

❑ For details on how to customize a mode definition file, refer to “Mode Definition
Syntax” on page 127.
❑ Refer to “Design Structures and Testmode Details” on page 41 for details on
specialized testmodes including On-product clocking concepts, Assumed scan,
1149, Reduced Power, OPMISR and 2D Elastic concepts.
■ Assign File (Usually Required) - The assign file is used to specify test function pin
assignments and other design specific information for the build_testmode command.
This information can also be placed into the mode definition file, but this is not
recommended. Test function pin assignment information can also be included as
attributes in the netlist. If there is pin assignment information in your netlist or your mode
definition file, a pin assignment file can be used to augment or override previously
defined test function pin assignments and other design-specific data. When using one of
the predefined mode definition files included with Modus , an assign file is the most likely
place to add the test function pin assignment and other design-specific data.
❑ Test function information is a required input. If an assign file is not used, test
functions must be specified as assign statements in the mode definition file or as
attributes in the design netlist.
❑ When the Cadence Genus is used to insert the test structures, this information is
created automatically.

December 2019 19 Product Version 19.12

■ Specifying Test Function Pin Attributes in Design Source (Optional) - The test functions
of pins can be specified as attributes in the design source instead of using ASSIGN
statements in an assignfile or mode definition file.
■ Tester Description Rules (TDRs) (Required) - The TDR is used to identify capabilities of
the manufacturing tester (such as, number of pins, size of scan buffer, tester termination
of outputs, and bidirectional pins). This tester-specific knowledge allows Modus to both
effectively utilize the capabilities of the test equipment and to supply some of the
necessary tester setup information when writing vectors.
❑ The TDR name is specified in the mode definition file. If using a standard mode
definition file, check the specified TDR to ensure that it matches your tester
capabilities.
❑ The standard TDRs are found in $Install_Dir/defaults/rules/tdr and
are applicable to almost all testers, but may not take full advantage of any one
tester’s capabilities.
❑ For details on how to customize a TDR, refer to “Tester Description Rules (TDRs)”
on page 213.
■ “Sequence Definition File (Optional)” on page 247 - In some cases, Modus is unable to
automatically determine the proper testmode initialization sequence or scan sequence
for a design. When this occurs, a mode initialization and/or custom scan sequence must
be provided in the sequence definition file (seqdef). Possible reasons for creating custom
sequences are.
❑ Create a custom mode initialization sequence if:
❍ RAMs must be initialized
❍ Fixed value latches must be initialized
❍ OPC Logic (PPIs) have TI or TC test function attributes
For details on creating a custom mode initialization sequence see: “Sequence
Definition File (Optional)” on page 247.
❑ Create a custom scan sequence if:
❍ No single PI stim vector enables all scan paths
❍ The scan shift sequence is something other than pulsing in order all (EC1, EC,
EC2) clocks
❍ OPC Logic (PPIs) require values for scanning
For details on creating a custom scan sequence see: “Custom Scan Sequences” on
page 251.

December 2019 20 Product Version 19.12

■ STIL Pattern File (Optional) - Build Testmode accepts the Standard Test Interface
Language (STIL) pattern file, from which testmode information can be derived, as input.
STIL files can be used as input to Build Testmode, automatically creating scan protocol
sequences and test function pin assignments, to produce a testmode based on the STIL
data. In many cases, using a STIL pattern file eliminates the need for an Assign File or
Sequence File. You can also convert a STIL file to an Assign File and Sequence File in
a separate step so these files can be modified prior to running build_testmode.
To use a STIL file as input, add -stilmodefile <file name> to the command line.
When importing a STIL file, you may also need to add macrodomainname and
macroname parameters to help Modus correctly decipher the STIL data.
■ Partition File (Optional) - Use a partition file as input to reduce, or partition, portions of
active logic to accelerate ABIST simulation. Partitioning of ABIST logic causes Modus
fault simulation applications to simulate only the active logic defined by the partition file.
Either hierarchical blocks of interest or starting/stopping points for a backtrace may be
specified in the partition file. Refer to Build Testmode Restrictions on page 23 for
additional information.
■ Boundary Scan Design Language (for 1149.1 Testmodes) - A BSDL (Boundary Scan
Design Language) file is recommended by the IEEE 1149.1 standard to specify
boundary scan. Refer to “Boundary Scan Design Language” on page 244 for details.

Buid Testmode Keywords of Interest

Required Keywords:
■ WORKDIR - identifies the working directory. Defaults to the current directory.
■ TESTMODE - names the testmode you are building. This may also be the name of the
mode definition file. In many cases, the testmode is set to the name of one of the mode
definition files that are shipped with Modus in $Install_Dir/defaults/rules/
modedef directory.

Optional Keywords:
■ assignfile identifies the name of the assign file input (see Assign File on page19).
■ modedef is the name of the testmode definition file (see Testmode Definition File on
page 18). If the testmode name is the same as the testmode definition file name,
modedef is not required.
❑ By default, Modus searches for a testmode definition file that has the same name as
the testmode.

December 2019 21 Product Version 19.12

❑ Typically, the predefined testmode definition files cover most applications. However,
you may define your own files, if required.
❑ Sample testmode definition files are located in the defaults/rules/modedef
directory within the installation.
■ modedefpath is the directory path where the modedef file is located. Multiple
directories should be separated by a colon (:). This option is required only if you are using
a customized modedef.
■ seqdef is the name of the sequence definition file (see Sequence Definition File on
page 20). In many cases, a seqdef is not required.
■ seqpath can be used to specify a set of directories to search for the seqdef file (this is
only required if the seqdef is not a fully qualified filename).
■ tdrpath is the directory path where the TDR file is located. This option is required only
if you are using a custom TDR.
❑ Modus supplies a set of standard TDR files that are sufficient for most designs.
❑ TDR is referenced within the mode definition file. The default set of mode definition
files refer to the standard TDR file set. If using a default mode definition file, you will
not require this parameter.
❑ Sample tester description rules are located in the defaults/rules/tdr directory
within the installation.

Build Testmode Command Examples

Example 1: Defining a standard FULLSCAN testmode

build_testmode -workdir /my/work/dir -testmode FULLSCAN \
-assignfile /my/AssignFile

When using the FULLSCAN mode definition file, Modus automatically searches for the file in
defaults/rules/modedef. The modedefpath parameter need not be specified. The
FULLSCAN mode definition file references a standard TDR, therefore, there is no need to
specify the tdrpath option.

Example 2: Defining a standard FULLSCAN testmode with a different testmode name

build_testmode -workdir /my/work/dir -testmode testmode2 \
-modedef FULLSCAN -assignfile/my/AssignFile

The resultant testmode will be called testmode2.

December 2019 22 Product Version 19.12

Example 3: Defining a custom testmode with mode initialization sequence file

build_testmode -workdir /my/work/dir testmode -dtestmodedef dtest_mode \
-modedefpath /my/modedef -assignfile /my/AssignFile \
-seqdef /my/sequences/seqdef

In this example, the mode definition file (dtest_mode) has been customized. The testmode
name is different from the mode definition name, therefore, both modedef and testmode
must be specified. The mode initialization sequence file is specified with the seqdef option.
The custom mode definition references a standard TDR file, therefore, the tdrpath
parameter need not be specified.

Example 4: Defining a testmode for a core to be used in Hierarchical Test

build_testmode -workdir /my/work/dir -testmode COMPRESSION_INTEST \
-seqdef /my/sequences/seqdef.COMPRESSION_INTEST \
-assignfile /my/assignfile.COMPRESSION_INTEST

The COMPRESSION_INTESTMODE definition file is shipped with the product so modedef

and modedefpath do not need to be specified as long as the testmode has this name. This
mode definition file includes BOUNDARY=MIGRATE to indicate that this testmode will be used
to create tests that will be migrated to the higher level (Chip or SoC) that contains an instance
of this core.

The assignfile.COMPRESSION_INTEST would be created by Genus-DFT or manually. It

would contain the ASSIGN statements and any CUTPOINTS statements. It would also
include a COREMAXPIPEDEPTH=n specification to indicate the maximum number of
pipeline stages expected on the higher level (Chip or SoC).

Build Testmode Outputs

In addition to identifying scan chains, compression structures, and other DFT-related logic,
build_testmode creates additional information that is used not only by ATPG and
simulation, but also during interactive analysis. This information includes:
■ “Active and Inactive Logic” on page 269
■ “Testmode Design States” on page 272

Build Testmode Restrictions

A testmode cannot have a grandparent mode if the vectors are to be written as WGL, STIL,
TDL, or Verilog.

December 2019 23 Product Version 19.12

The following are additional limitations:

■ More than 256 Scan I/Os are not supported if the scan in/out pins are declared with
indexes in the assign file. Removal of pin indexes removes this restriction.
■ More than 128 clock pins in the TDR are not supported. To circumvent this condition,
correlate your clock inputs in the testmode definition. Refer to “ON_BOARD_MISR” on
page 191 for details.

Assignfile Examples
Refer to “ASSIGN” on page 147 for more information on the ASSIGN statement syntax.

Example 1: Correlated Input Pins

assign pin=D4 test_function=-TI;
CORRELATE D2 + D4;

The above-mentioned example correlates pin D2 to the representative pin D4. The statement
CORRELATE D2 - D4; will be used if the pins are out of phase.

Example 2: Scan Enable and Test Constrained Pin

assign pin=SE test_function=-SG,+TC;

Consider this pin as a 0 during scan, but as 1 during the release/capture of ATPG.

Unit or Zero Delay Simulations for Testmode

When using a custom mode initialization sequence, there might be situations where the type
of simulator being used affects the final simulation results. The default for building a testmode
is to use a unit delay simulation. Some designs might require zero delay simulation because
of unbalanced clock lines. The build_testmode command has the option -delaymode
zero to invoke a zero delay simulation.

For unit-delay simulation to work, you have to account for the flip-flops, latches, and RAMs in
the model, taking clock distribution unit-delay skews into consideration. If the number of gate
delays are not well balanced (a difference of 7 or more gates), you might have to modify the
model to make unit delay simulations work. For example, consider a case in which a single
clock feeds two flops A and B, where flop A feeds flop B. If flop B has 10 extra buffers on the
clock line, flop A will evaluated and its value will be propagated to flop B. In this case, flop B
would capture the input data to flop A. Under normal situation, flop B would have expected to
capture the original value in flop A instead of its input value. This is an example of how an

December 2019 24 Product Version 19.12

unbalanced clock path can cause incorrect simulation results. This situation can be resolved
by inserting more gates on the clock line to flop A to make the number of delays more
equivalent. In addition to balancing the clock distribution unit delays, you can also insert gates
(buffers) into the data inputs or outputs of all latch flip-flops or RAM models. This delays the
propagation of new data signals feeding to opposite phase latches until their clocks can turn
off.

Zero delay simulation predicts the clock always wins the clock/data race. That is, for clock
gating or data hold time races, zero-delay simulation makes calculations assuming that the
clock goes off before new data arrives.

When running zero delay simulation in NC-sim, you might need to add the option ncelab -
seq_udp_delay 10ps to add some unit of delay for latch and flip-flop calculations.

Analyzing Build Testmode Log Results

The build_testmode log contains the following messages of varying levels of severity.
Refer to the manpages by typing man <comp name in caps>messages or use the msgHelp
command for extended message help.

Mode Init and Scan Sequences

In most cases, mode initialization and scan sequences will be created automatically, as
indicated by the following messages:

INFO (TTM-391): A default modeinit sequence will be generated.

INFO (TTM-387): A default scanop sequence will be generated.

Use the following command to review the defined sequences for a specific testmode:
report_sequences -workdir <directory> -testmode <testmode name>

Active Logic
INFO (THM-814): Testmode contains 99.96% active logic, 0.04% inactive logic and 0.00%
constraint logic.

Check the percentage of active logic. Active logic is the logic that can be observed at a
primary output or scannable flop/latch. Faults in active logic are targeted for ATPG. In fullscan
testmodes, the percentage of active logic should be very high. Some reasons for low active
logic are:

December 2019 25 Product Version 19.12

■ Incorrect test function pin assignments such as Test Inhibits (TIs)

■ Dangling (untestable) logic included in some simulation libraries for timing

Constraint logic is not actually a part of the design. It is the logic that is added to the model
when constraints are specified during build_model for ATPG. The constraints are modeled so
that if any constraint is violated by a specific pattern, three-state contention occurs.

The following is an example of test function pin assignments listed in the log file:

Test Function Pin Information for Testmode: FULLSCAN

-------------------------------------------

3 SC (System Clock) Pins

2 EC (E Shift Clock) Pins

0 OSC (Oscillator) Pins

1 TI (Test Inhibit) Pins
3 SE (Scan Enable) Pins
0 CI (Clock Isolation) Pins
0 OI (Output Inhibit) Pins
14 SI (Scan Input) Pins
14 SO (Scan Output) Pins

Pin Index Type Test Function Pin Name / Net Name

--------- ---- ------------------------ --------------------
35 PI +SC port:I_CORE_RESET1 / I_CORE_RESET1
37 PI -EC -SC port:I_CORE_SYS_CLK / I_CORE_SYS_CLK
53 PI -EC -SC port:TEST_CLOCK / TEST_CLOCK
54 PI +TI port:TEST_ENABLE / TEST_ENABLE
0 PI -SE port:COMPACTOR_SCOMP / COMPACTOR_SCO
1 PI -SE port:COMPACTOR_SPREAD / COMPACTOR_SP
52 PI +SE port:SCAN_ENABLE / SCAN_ENABLE
38 PI SI port:SCANIN[0] / SCANIN[0]
39 PI SI port:SCANIN[10] / SCANIN[10]

The following is an example of fault status information:

Testmode Statistics: FULLSCAN

#Faults #Tested #Possibly #Redund #Untested #PTB

Total 151793 0 0 0 151793 21
Total Static 61029 0 0 0 61029 21
Total Dynamic 90764 0 0 0 90764 0
Collapsed 112223 0 0 0 112223 19
Collapsed Static 43675 0 0 0 43675 19
Collapsed Dynamic 68548 0 0 0 68548 0
Pin 143695 0 0 0 143695 21
Pin Static 53775 0 0 0 53775 21
Pin Dynamic 89920 0 0 0 89920 0
Collapsed Pin 104125 0 0 0 104125 19
Collapsed Pin Static 36421 0 0 0 36421 19
Collapsed Pin Dynamic 67704 0 0 0 67704 0
PI 217 0 0 0 217 2
PI Static 109 0 0 0 109 2

December 2019 26 Product Version 19.12

PI Dynamic 108 0 0 0 108 0

PO 368 0 0 0 368 0
PO Static 184 0 0 0 184 0
PO Dynamic 184 0 0 0 184 0
Pattern 8098 0 0 0 8098 0
Pattern Static 7254 0 0 0 7254 0
Pattern Dynamic 844 0 0 0 844 0
Shorted Net 0
Drvr/Rcvr 61029 0 61029
Path 0 0 0

A testmode can be built before or after the fault model. If the fault model is built first, the
build_testmode log contains a list of the fault status for the testmode. The number of faults
in a testmode is determined by the amount of active logic. The important thing here is to note
the number of faults in the testmode.

You can generate the same report with current fault status at any time using the command
report_fault_statistics. More information about the fault categories may be found in
the section Report Faults in Modus: Guide 4: Faults.

Tip
You can build all the testmodes simultaneously to save wall time. Refer to “Building
Multiple Testmodes” on page 35 for more information.

Faults Not Active in any Testmode

The build_testmode log also lists the faults that are defined in the fault model but are not
active in any testmode, and the maximum attainable global test coverage due to the inactive
faults. The following is an example of inactive fault information:
Statistics for faults that are not active in any testmodes and maximum test
coverage attainable with the current set of testmodes:

Definitions:
#Faults : Number of Faults defined (independent of testmodes).
#Active : Number of Faults Active in at least one mode.
#Inactive: Number of Faults Inactive in all modes.
%Active : #Active/#Faults = Maximum Test Coverage attainable.

There are 3 testmode(s) defined:

FULLSCAN
#Faults #Active #Inactive %Active
Total 69162 69117 45 99.93
Total Static 69162 69117 45 99.93
Total Dynamic 0
Collapsed 51808 51763 45 99.91
Pin 53804 53775 29 99.95

December 2019 27 Product Version 19.12

Collapsed Pin 36450 36421 29 99.92

PI 110 109 1 99.09
PO 184 184 0 100.00
Pattern 15358 15342 16 99.90
Shorted Net 0
Drvr/Rcvr 7168 0 7168 0.00

Troubleshooting Build Testmode Problems

Execute the following command for extended message help:
msgHelp <message number>

For example:
msgHelp TTM-031

Or execute the following command for manhelp,

man <component name in caps>messages

For example:
man TTMmessages

The following table lists some common problems during build_testmode and how to
troubleshoot those problems:

Table 1-1 Syntax or Content Problems

Problem Possible Cause/Solution

TTM-030 Pinname <pinname> not found on design.
The pin name specified does not exist in the design. View the
pin in the schematic viewer. Use a part of the name and the filter
option if you cannot determine the correct name.
TTM-031 Netname <netname> not found on design.
The net name specified does not exist in the design. View the
net in the schematic viewer. Use a part of the name and the
filter option if you cannot determine the correct name.
TTM-048 Illegal or missing <statement type> statement terminator.
All statements must end with a semicolon.
TTM-054 Missing <flag type> flag polarity value.

December 2019 28 Product Version 19.12

Problem Possible Cause/Solution

The specified test function pin/net assignment needs a polarity
(+/-).
TTM-055 Invalid <flag type> flag polarity value.
The polarity given for the specified test function flag is incorrect.
Generally this means a flag not requiring a polarity has been
assigned a polarity.
TTM-056 Conflicting <flag type> flag polarity value.
The specified test function pin/net assignment was entered
twice, each with a different polarity.
TTM-059 Unable to open MODEDEF assignfile<file name>.
Typo in the name of the assignfile or its directory.
TTM-451 Pin name <pinid> is a correlated pin and is not allowed to have
test function flags. The test function flags will be ignored.
Correlated pins cannot have test function flags. If you are
correlating a pin or set of pins, only the pin to which you are
correlating them can have a test function flag.
TTM-458 Net name <net name> is not found in the hierModel. This
Assign statement will be ignored.
The net name specified in the assign statement does not exist.
View the net in the schematic viewer using a part of the name
and the filter option if you cannot determine the correct name.
TTM-459 Pin name, <pin name>, is not found in the hierModel. This
Assign statement will be ignored.
The pin name specified in the assign statement does not exist.
View the pin in the schematic viewer using a part of the name
and the filter option if you cannot determine the correct name.

Table 1-2 Sequence Definition Problems

Problem Possible Cause/Solution

TTM-035 Sequence Definition file does not contain a modeinit sequence.

December 2019 29 Product Version 19.12

Problem Possible Cause/Solution

If a sequence file is supplied, it must contain a modeinit
sequence. If you have supplied special scan and clocking
sequences, then you must provide the set of stimulus to put the
design in the initial state required to be able to use those
sequences. The modeinit sequence is identified in the seqdef
file with a statement similar to the following:
[Define_Sequence INIT 1 (modeinit);
<set of patterns and events to define the required
stimulus>
]Define_Sequence 1;

Table 1-3 Other Error Indications

Problem Possible Cause/Solution

TTM-347 There is less than 96 percent active logic in this testmode.
The smaller the percentage of active logic, the more is its
impact on global test coverage. This percentage represents the
amount of logic of the design that is testable in the testmode.
Therefore, if it is 93% and you achieve test coverage of 100% in
the testmode then your global coverage would be 93%.
TTM-801 Testmode has NOT been defined - see preceding message(s)
for details.
Terminating errors existed that did not allow completion of build
testmode.

Reporting Testmode Information

The report_test_structures command prints the following information about a
testmode:
■ The list of test function pins
■ Information about scan chains
■ Lists of flops/latches with special characteristics (such as fixed value, inactive, and
floating)

December 2019 30 Product Version 19.12

■ Channel masking logic for compression modes

■ On Product Clock cutpoints and pseudo-primary inputs
■ Embedded pipeline structures for compression modes

Basic Command Syntax for report_test_structures

The basic command syntax for report_test_structures is as follows:
report_test_structures -workdir <directory> -testmode <modename>

where:
■ -workdir is the name of the working directory
■ -testmode is the name for the testmode being created (in some cases, the name of the
mode definition file is used, for example, FULLSCAN)

Most of the testmode reports are self-explanatory. Some of the information in the scan chain
listing is explained below:

Scan Chain Information Report

Control/Observe Scan Chain Information for Testmode: FULLSCAN
---------------------------------------------------------------
16 Controllable Scan Chains
16 Observable Scan Chains

Controllable Scan Chain 1

Load Pin Index / Pin Name 107848/
prim_pin:CORE_1.\counter_reg[11].__iNsT2.udp_1_mux.DOUT
Length 84
Scan Section Sequence Scan_Section_Sequence
Observable Register 1
Unload Pin Index / Pin Name 60695/pin:Inst_1.COMPACTOR.compressor.g_269.g42.Y
Length 84 Unload pin in phase with Load Pin
Scan Section Sequence Scan_Section_Sequence

Position LType Block Index IO PhaseObserveChn ObservePos Block Name

Clock Affiliation
-------- ------- ------------ -------- ---------- ---------- --------------------------
---------------------------------------- -------------------------------------------------
--------
1 rDFF_cS 936321 ++ 1127 17 inst:Inst_3.lx1.lx0.CORE1.
RALU1.REGFILE1.\Rfile_321p_reg[8][26] PAD_SYSCLK_3: -EC inPhase PAD_SYSCLK_3: -SC
inPhase
2 rDFF_cS 1264647 ++ 1524 17 inst:Inst_4.lx1.lx0.CORE1
.RALU1.REGFILE1.\Rfile_321p_reg[8][26] PAD_SYSCLK_4: -EC inPhase PAD_SYSCLK_4: -SC
inPhase

December 2019 31 Product Version 19.12

The preceding report shows that there are 16 controllable and 16 observable scan chains in
the design. If a scan chain is both controllable and observable, it will have a unique control
and observe register numbers. These numbers may not be the same.

Note the following in the report:

■ The Load Pin and Unload Pin normally indicate scanin and scanout, respectively. In
a compression or LBIST testmode, the load or unload pins may be internal to the design.
■ Length identifies the length of the chain.
■ Scan Section Sequence applies if a custom scan sequence is defined where all scan
chains do not shift in parallel.
■ The Position column (Control bit positions) is numbered from the scan input to the
scan output.
■ The LType column identifies the flop or latch type.
■ All correlated flops/latches (share a common bit position) are listed together.
■ The IO Phase field contains the block index of the representative block, flop/latch, and
its phase relationship with the scanin and scanout.
Relationship to ScanIn is character under the "I":
❑ + in phase with scanin and controllable
❑ ! in phase with scanin and NOT controllable (scan chain hole)
❑ - out of phase with scanin and controllable
❑ ~ out of phase with scanin and NOT controllable (scan chain hole)
Relationship to ScanOut is second character under the "O":
❑ + in phase with scanout and measurable
❑ ! in phase with scanout and NOT measurable (scan chain hole)
❑ - out of phase with scanout and measurable
❑ ~ out of phase with scanout and NOT measurable (scan chain hole)
❑ # loaded by scan, NOT measurable, NOT in scanout path
■ ObserveChn and ObservePos indicate the observe Chain and the bit position for this
flop/latch. Observe bit positions are numbered from the scan output to the scan input.
Observe only registers are listed separately.
■ Block name contains the block name for the flop/latch.

December 2019 32 Product Version 19.12

■ Clock Affiliation contains the scan state clock affiliation data for the scan port of
each reported latch. This information is displayed in the report only when you specify -
reportclockaffiliation scan for the report_test_structures command.

Channel Mask Enable Pipeline Report

Channel Mask Enable Pipeline Latch/Flops
---------------------------------------------------------------------------------
--------------------------------------
Block Index Block Name Clock Affiliation
----------- --------------------- -------------------------------------------
-------------------------------------
1010362 inst:Inst_4.COMPACTOR.in_pipe0.\pipe_reg[10] PAD_DFT_mask_clk: -EC
inPhase PAD_DFT_mask_clk: -SC inPhase
681606 inst:Inst_3.COMPACTOR.in_pipe0.\pipe_reg[10] PAD_DFT_mask_clk: -EC
inPhase PAD_DFT_mask_clk: -SC inPhase
352849 inst:Inst_2.COMPACTOR.in_pipe0.\pipe_reg[10] PAD_DFT_mask_clk: -EC
inPhase PAD_DFT_mask_clk: -SC inPhase
Report completed.

December 2019 33 Product Version 19.12

December 2019 34 Product Version 19.12

2
Multiple Testmodes

Building Multiple Testmodes

Modus allows you to define up to 500 different testmodes of operation for your design. You
can define different testmodes for many reasons. The following are examples of testmodes
that may be defined:
■ Fullscan testmode
■ XOR compression testmode
■ Reduced pin count, boundary scan internal testmode
■ Boundary scan external, interconnect testmode
■ Different testmodes may be needed if test data must be generated for two or more
substantially different testers

Tip
You can build multiple testmodes simultaneously to save time but make sure to build
the fault model after you have built all the testmodes. If you build the fault model first
and then run parallel build testmode, the jobs will conflict over the master fault list.
This file conflict will significantly impact/reduce the wall time savings or require
reprocessing of the jobs to ensure the fault files are correctly created.

Cross-Mode Markoff
A major benefit of using multiple testmodes is cross-mode markoff. Cross-mode markoff is a
technique in which faults tested in one testmode are marked as tested in another testmode
so they are not retargeted for ATPG.

December 2019 35 Product Version 19.12

Enabling Cross-Mode Markoff

Cross-mode markoff is controlled by the COMET statement in the Mode Definition File. By
default, all testmodes that use the same TDR will use cross-mode markoff. You can further
control the cross-mode markoff behavior of testmodes.

Example: Using Cross Mode Markoff

The following example script runs ATPG on a compression testmode (such as XOR
compression). If the test coverage is not as high as expected, top-off patterns are generated
using the FULLSCAN testmode.

There is cross mode markoff because both the COMPRESSION and FULLSCAN modedef files
reference the same TDR (Tester_Description_Rule=dummy.tdr)
build_model -workdir <directory> -designsource ...

# both testmodes must specify same TDR in modedef file

build_testmode -workdir <directory> -testmode COMPRESSION,FULLSCAN...
verify_test_structures -workdir <directory> -testmode FULLSCAN
verify_test_structures -workdir <directory> -testmode COMPRESSION

# make sure both modes can scan

create_scanchain_tests -workdir <directory> -testmode FULLSCAN
create_scanchain_tests -workdir <directory> -testmode COMPRESSION

# logic tests using compression mode

create_logic_tests -workdir <directory> -testmode COMPRESSION -experiment logic
commit_tests -workdir <directory> -testmode COMPRESSION -experiment logic

# top off with fullscan vectors

create_logic_tests -workdir <directory> -testmode FULLSCAN -experiment logic
commit_tests -workdir <directory> -testmode FULLSCAN -experiment logic

write_vectors -workdir <directory> -testmode COMPRESSION

write_vectors -workdir <directory> -testmode FULLSCAN

Building a Hierarchy of Testmodes (Parent Testmodes)

For a design that contains complex clocking schemes and/or a combination of test structures
such as LBIST, MBIST, 1149.1, and FULLSCAN, it may be easier to build a base testmode
and use that testmode as a starting point when building other testmodes. The base testmode
is referred as the parent testmode and each testmode that is created using that base
testmode is referred as its child, thus creating a testmode hierarchy.

The creation of a testmode hierarchy requires the introduction of custom mode initialization
sequences. A child testmode references its parent testmode within the custom mode
initialization sequence. The child testmode must have the following within the testmode
initialization section of its custom sequence:

December 2019 36 Product Version 19.12

[ Define_Sequence Mode_Initialization_Sequence (modeinit, user_defined) ;

[ Pattern 1 (pattern_type = static);
Event 1.1 Begin_Test_Mode (): <name of parent testmode> ;
] Pattern 1 ;
......

The parent testmode must exist before a child testmode using that parent is built.

December 2019 37 Product Version 19.12

December 2019 38 Product Version 19.12

3
Delete Testmode Information

Deleting a Testmode
This option removes all files and experiments associated with the testmode, as well as any
test data created, including any experiments that have been created but not yet committed.
The fault status is reset. Any testmodes that used this mode as a parent are also removed.

The basic command syntax to delete a testmode is as follows:

delete_testmode -workdir <directory> -testmode <modename>

where:
■ workdir is the name of the working directory
■ testmode is the name of the testmode being deleted

To remove a testmode using the graphical interface, refer to “Delete Testmode(s)” in the
Modus: Reference: GUI.

Refer to delete_testmode -H or man delete_testmode for the command syntax and

supported options.

Deleting Committed Data from a Testmode

This option removes all committed test data and resets the fault status information for an
existing testmode, without requiring that the testmode be re-created. This function saves
time, in the event you wish to decommit experiments that were previously committed, in that
the testmode is retained and does not require re-creation. Another time-saving characteristic
of deleting committed data is the retention of existing results from Testability Analysis
applications, thereby avoiding the need to re-run the application.

The default action of Delete Committed Tests is to remove all experiments dependent on
the testmode. If you wish to retain existing uncommitted data, you may specify an
uncommitted name to rename and re-register the committed vectors file as an uncommitted
vectors file.

December 2019 39 Product Version 19.12

The basic syntax for removing committed data is as follows:

delete_committed_tests -workdir <directory> -testmode <modename>

where:
■ workdir is the name of the working directory
■ testmode is the name of the testmode being deleted

To perform Delete Committed Tests using the graphical interface, refer to ”Delete
Committed Tests” in the Modus : Reference: GUI.

To perform Delete Committed Tests using command lines, refer to

delete_committed_tests -H or man delete_committed_tests for the command
syntax and supported options. Mode-dependent test pattern information and fault status
information are removed.

Example: Deleting a single testmode

delete_testmode -workdir /local/dlx -testmode FULLSCAN

Example: Deleting multiple testmodes

delete_testmode -workdir /local/dlx -testmode FULLSCAN,COMPRESSION

December 2019 40 Product Version 19.12

4
Design Structures and Testmode Details

Delay Testmodes
Several mode definition files are provided with Modus (in the $Install_dir/
tools.<ARCH>/tb/defaults/rules/modedef directory) that enable either timed or
untimed delay testing. You can use these testmodes as is, unless you have specific tester
information, or you need to customize the mode definition file for some other reason.
Following are the installed mode definition files:
■ FULLSCAN
■ COMPRESSION
■ OPMISR+

Customizing a Mode Definition for Delay Test

The following are required for a delay testmode:
1. Mode Definition File:
a. The test_types statement should include dynamic tests as follows:
test_types dynamic timed early (0,1,0) late (0,0,1) logic dynamic scan
shift_register

b. The faults statement should include dynamic faults as follows

faults static, dynamic;

c. The TDR statement must reference a TDR that supports timed tests:
Tester_Description_Rule = timed.tdr

2. Tester Description Rule

A PIN_TIMING statement must be specified that describes the capabilities of the target
tester. The TDRs provided with Modus will support many testers, but may not be optimal
as in the following example:

December 2019 41 Product Version 19.12

PIN_TIMING
TIMING_RESOURCE = SHARED_RESOURCE
CLOCKS=5 NON_CLOCKS=13 PO_STROBES=7
MAX_PULSES = 1
MAX_STIMS = 1
MAX_MEASURES = 1
MAX_CYCLE_TIME = 1 MS
MIN_CYCLE_TIME = 2500 PS
...

3. Copy the standard mode definition file from $Install_dir/tools.<ARCH>/tb/

defaults/rules/modedef and modify it.
4. Copy the standard TDR from $Install_dir/tools.<ARCH>/tb/defaults/
rules/tdr and modify it (make sure to use the same name as specified in the mode
definition file).
5. Run build_testmode:
build_testmode -workdir <directory> -testmode <modename> \
-modedef <modified_modedef> -modedefpath <directory> \
-tdrpath <directory>

Assumed Scan Testmodes

Assumed scan chain testmodes allow for the creation of testmodes prior to the insertion of
scan structures. This facilitates early assessment of design testability and fault coverage with
reasonable accuracy. Modus identifies existing functional latches/flip-flops and act as if a
single scan chain exists comprised of all the latches and flip-flops.

Assumed scan chain testmodes are identified by use of the assumed attribute on the SCAN
statement in the mode definition file. See “SCAN” on page 133 for details.

Example 4-1 Sample assumed_mode Definition File

Tester_Description_Rule = base_tester;
scan type = assumed gsd
boundary=no
in = pi
out = po;
test_types static logic signatures no
shift_register
static macro;
faults static;

Example 4-2 Example Command Invocation for an Assumed Scan Testmode

build_testmode -workdir <directory> -testmode assumed \
-moddef assumed_mode -modedefpath <directory>

December 2019 42 Product Version 19.12

Note: When creating or modifying your own mode definition file, specify the containing
directory using the modedefpath option.

Excluding Specific Flops from a Scan Chain

To remove specific flops/latches from consideration during creation of a scan chain for
Assumed Scan testmodes, create a file listing these latches and specify the file using the
option excludelatchfile for build_testmode.

Example 4-3 Exclude File Example

// Sample exclude file for Assumed Scan hierarchicalDelimiter=/
// . (dot) is always recognized as hierarchical delimiter
// so for this file . and / will be used as hierarchical delimiters
my2Alu_0.ADD1.co_reg my2Alu_0.ADD1.q_reg[0]
// my2Alu_0.ADD1.q_reg[1]/*
my2Alu_0.ADD1.q_reg[2] */
my2Alu_0/ADD1/q_reg[3]
my2Alu_0.ADD1.q_reg[4]
my2Alu_0.ADD1.q_reg[5]
my2Alu_0.ADD1.q_reg[6]
my2Alu_0.ADD1.q_reg[7]
// existing scan chain flop
my2Alu_0.MUL1.\q_reg[11]
// the hierarchical delimiter @ is not interpreted as such since / was given above
// therefore the block below will be read as the name of a block on the top
// level of the hierarchy my2Alu_0@MUL1@\q_reg[12]

Example 4-4 Example Command Invocation using the excludelatchfile option

build_testmode -workdir <directory> -testmode assumed \
-modedef assumed_mode -modedefpath <directory> \
-excludelatchfile <directory>/exclude_flops

Exclude File Syntax

The following are the elements of an exclude file:

The excludelatchfile option is only recognized for Assumed Scan testmodes and is
ignored for all other testmodes.
■ Line comments
Comments are denoted by lines starting with // or /*. Lines starting with either of these
comment delimiters are ignored during processing. Block comments (comments
spanning multiple lines) are not supported.
■ Specification of the Hierarchical Delimiter

December 2019 43 Product Version 19.12

Use the following format:

hierarchicalDelimiter=hierarchical delimiter

The default hierarchical delimiter used by Modus is . (a dot). The following are accepted
hierarchical delimiters::
❑ . (dot)
❑ / (forward slash)
❑ ^ (caret)
❑ | (vertical bar)
❑ @ (at-sign)
Therefore if the specified hierarchical delimiter is / (forward slash), the statement would
look like the following:
hierarchicalDelimiter=/

If no hierarchical delimiter is specified in the file or if an unsupported delimiter is

specified, a . (dot) will be interpreted as the hierarchical delimiter.
■ Specification of the flop/latch to be excluded in the form of a hierarchical flop block or
latch primitive.

Assumed Scan Mode Limitations

These limitations apply to the use of assumed scan:
■ Use of assumed scan is not supported for signature-based ATPG, including On-Product
MISR support.
■ Assumed scan requires the use of BOUNDARY=NO and excludes all signature-based
testing parameters and statements in the mode definition file.
■ Assumed scan chain testmodes cannot be mixed in the same MARKOFF comet as non-
assumed scan chain testmodes.
■ TSV checks associated with signature-based testing as well as checks, which verify scan
operation, should not be used.
■ Scan Chain tests cannot be generated.
■ ATPG results for an assumed scan chain testmode cannot be included on a TMD.
■ 1149.1 scan types are not supported as assumed.

December 2019 44 Product Version 19.12

■ At least one primary input and output pin must exist in the design.

December 2019 45 Product Version 19.12

OPMISR Testmodes
Modus Synthesis supports Test Compression by means of an On-Product Multiple-Input
Signature Register (OPMISR). A more advanced option of OPMISR technology called
OPMISR+ is supported if the Modus installation has an OPMISR+ option.

Introduction to OPMISR and OPMISR+ Compression

Using an On-Product MISR (scan-to-MISR) testmode can result in reduced test data volume.

It is recommended to first create a chip fullscan chain testmode for diagnostics, as specified
in the DIAGNOSTIC_MODE statement, and then create an On-Product MISR testmode.

The MISR test structure modifies the typical fullscan scan chain such that each Scan Data
Input internally drives many (~10-50) shorter chains. These shorter chains feed the inserted
MISR structure. The chain’s values are captured into the MISR during shift, generating a
resulting signature that can be shifted out. Also, Scan Data ports, both Outputs and Inputs,
can be configured to behave in unison to provide an additional 2X more compression.

Figure 4-1 on page 47 shows a traditional scan configuration for Automatic Test Pattern
Generation (ATPG) with N scan pins (N/2 scan-ins and N/2 scan-outs) and N/2 scan chains.

December 2019 46 Product Version 19.12

Figure 4-1 Normal FullScan ATPG Configuration

During the scan operation phase of ATPG test vectors, the Automatic Test Equipment (ATE)
will load test stimuli for the next test through the scan-in pins while concurrently scanning out
the test results from the current test via the scan-out pins. The number of scan pins is very
small (typically 16 to 128) relative to the number of scan elements. Since the number of scan
chains is equal to the number of scan-in pins, the test time, which is dominated by the time it
takes to scan into and out of the longest scan chain, will naturally increase along with the
increase in the number of scan elements.

Figure 4-2 on page 48 shows a typical OPMISR configuration that includes an embedded
MISR to compress the test vector responses. This is achieved by using N scan chains and N
bi-directional scan pins.

December 2019 47 Product Version 19.12

Figure 4-2 OPMISR Configuration

The N scan bi-directional pins are used for scan-in during the scan operation and as MISR
observe pins after the scan-out collects the response data into a MISR signature. By cutting
the chain lengths in half, the test time is cut by half and tester storage by 2 to 3 times. The
savings in test time are primarily due to the use of shorter scan chains while the savings in
storage are primarily due to the fact that only the MISR response values have to be stored on
the ATE instead of the values of all the scan elements. Although the MISR observe pins do
not have to be shared with the scan-in pins, this sharing of test functions allows the use of
reduced-pin count testers.

Further improvements can be achieved by using an enhancement called OPMISR+. Figure 4-

3 on page 49 shows an OPMISR+ implementation.

December 2019 48 Product Version 19.12

Figure 4-3 OPMISR+ Configuration

The N bi-directional pins are fanned out to NxM scan chains by broadcasting each scan pin
to M different scan chain inputs. The NxM wide MISR is composed of M MISRs, each of size
N, and is observed at the scan pins via an XOR space compactor. Since this cuts the scan
chain length by a factor of 2xM (if the internal scan chains are reasonably well balanced), it
reduces the test time by a factor of 2xM and storage by 2xM or 3xM. Because the scan chains
are channeled into a signature register it is customary to refer to them as channels instead of
scan chains.

OPMISR+ allows scan-in pins to fan out to multiple scan chains. The combined use of
OPMISR and fan out techniques produces shortened scan chain lengths, and thus shortened
scan time, that can result in significant test time reductions. An example of OPMISR with fan
out is depicted in Figure 4-4 on page 50.

December 2019 49 Product Version 19.12

Figure 4-4 OPMISR using Scan Fan Out

One limitation of embedded MISR based techniques is due to the presence of unknown
states (also known as X-states) in the design. During the test generation process, it is
possible that these X-states get captured in a scan flop and get scanned into the MISR. Once
an unknown (X) value is captured in a MISR, that MISR’s signature is corrupted and becomes
unpredictable. Modus has implemented a technique called Channel Masking which prevents
this corruption of signatures. This technique involves the use of masking logic at the end of
the channels that allows the ATPG to block the unknown (X) values from entering the MISR.
The OPMISR methodology supports both a full-scan ATPG mode as well as an OPMISR
mode. The full-scan mode is used to clean up faults that were not detected during the
OPMISR testmode such as faults in the test logic and faults whose tests were invalidated by
the X-states or masking. The full-scan mode may also be used for diagnostics.

The OPMISR+ methodology supports three testmodes: OPMISR+, OPMISR, and full-scan
ATPG. The OPMISR mode can be used to detect any faults that were not detected in the
OPMISR+ mode due to correlations caused by the fan-out of the scan in pins to the channels,
which adds additional constraints to the test generator. The full scan mode is primarily
intended to be used for diagnostics and can also be used for applying any other kinds of tests

December 2019 50 Product Version 19.12

that may not be applicable in the OPMISR or OPMISR+ testmodes, such as migrated test
vectors for internal Cores.

Generating OPMISR TestMode

To generate an On-Product MISR testmode:
■ Specify that scan-out data goes to TO_MISR in the SCAN mode definition statement
(OUT=TO_MISR).

Figure 4-5 On-Product MISR Configuration Example

■ Specify as appropriate, these test function pins:

❑ MISR_Observe
❑ MISR_Read

December 2019 51 Product Version 19.12

❑ MISR_Reset
❑ MISR_Reset_Enable (optional)
■ Specifying the test function pins allows automatic generation of corresponding
sequences of:
❑ MISR_Observe
❑ MISR_Reset
❑ Diagnostics_Observe_Sequence
❑ Diagnostics_Return_Sequence
Refer to the descriptions of “Define_Sequence” types in the Test Pattern Data
Reference for additional information.

Creating a chip full scan chain testmode for diagnostics, in addition to creating an On-Product
MISR testmode, ensures the completion of any processing that cannot be done in the On-
Product MISR mode.

Further reduction in test data volume can be achieved by the use of test structure
independent techniques such as Run-Length Encoding and more efficient algorithms for test
vector compaction.
Note: OPMISR is often referred to by its shorthand S2M which stands for Scan2MISR.
OPMISR+ is often referred to by its shorthand OPPLUS. These shorthand names are primarily
used for pins in the logic designs that implement these test structures.

December 2019 52 Product Version 19.12

OPMISR Building Blocks

There are two building blocks that are available to support the OPMISR methodology:
1. OPMISR_<N> where N is the size of the MISR and is equal to twice the number of scan
inputs (or scan outputs). The OPMISR block includes the embedded MISR and all the
control logic and scan path switching logic to support the OPMISR methodology for a
design with N/2 scan in and N/2 scan out pins. Table 4-1 describes the pins on the
OPMISR_<N> building block.

Table 4-1 OPMISR Description

Pin Name Direction Bit Width Purpose

S2M Input 1 Enables OPMISR mode
SE Input 1 Scan Enable
MRD Input 1 MISR Read Enable
MRC Input 1 MISR Reset Control/Enable
CK Input 1 Clock that operates MISR
TEST_CLOCK_IN Input 1 Dedicated Test Clock for scan
Elements in user logic
RSI_SI Input N/2 Signals from primary scan inputs
(bi-dir pin) used to scan in data
from ATE
RSI_SO Input N/2 Signals from primary scan outputs
(bi-dir pin) used to scan in data
from ATE
SWBOX_SO Input N Signals from channel tails or
SwitchBox scan out pins used to
feed test responses to MISR
SWBOX_SI Output N Signals feeding channel heads
from the RSI_SI and RSI_SO
signals
DSO_SI Output N/2 OPMISR output feeding the
primary scan in (bi-dir pin) during
MISR Observation

December 2019 53 Product Version 19.12

Table 4-1 OPMISR Description

Pin Name Direction Bit Width Purpose

DSO_SO Output N/2 OPMISR output feeding the
primary scan output (bi-dir pin)
during MISR Observation
ESO_SI Output N/2 scan pin Bi-dir enable control for
the Primary Scan Inputs
ESO_SO Output N/2 scan pin Bi-dir enable control for
the primary scan outputs
TEST_CLOCK_OUT Output 1 TEST_CLOCK_IN gated off during
MISR Reset or Channel Mask
scan. Serves as test clock input to
user's logic

2. SIO_SYS_S2M: This building block is used to interface the OPMISR block to the bi-
directional scan in and scan out pins. The following table describes the pins on the
SIO_SYS_S2M building block.

Table 4-2 SIO_SYS_S2M Pin Description

Pin Name Direction Purpose

RDI Input Receiver Data Input from I/O cell
DDI Input Driver Data Input from system logic
DSO Input Driver Scan Output from last scan cell
EDI Input Enable Data Input from system logic
ESO Input Enable Scan Output from test logic
SE Input Scan Enable
RDO Output Receiver Data Output to system logic
RSI Output Receiver Scan Input to first scan cell
DDO Output Driver Data Output to system logic
EDO Output Enable Data Output to system logic

December 2019 54 Product Version 19.12

Modes of Operation
Figure 4-6 on page 56 shows the interconnection between the OPMISR block,
SIO_SYS_S2M blocks, the I/O cells, the internal scan chains/channels, and the flow of data
during the functional mode. Essentially the RDI pin of the I/O cell feeds the system input logic,
the EDI pin of the I/O cell is driven by the internal driver enable logic, and the DDO pin of the
I/O cell is fed by the system output logic. The MISR data is not observable and no scan data
is being scanned into the MISR.

December 2019 55 Product Version 19.12

Figure 4-6 OPMISR in Functional Mode

Figure 4-7 on page 57 shows the flow of data during the OPMISR scan mode. The scan data
from the scan in and scan out pins feeds the RSI input pins of the OPMISR block from which
it is directly passed on to the scan channel heads via the SWBOX_SI pins. After the test is
completed the test results are scanned out through the scan channel tails to the SWBOX_SO
pins of the OPMISR block from where it is captured by the MISR. Every bit shift of the scan
channel is accompanied by a bit shift of the MISR and the new test data is added into the
accumulated signature. At the end of the test the scan phase is exited.

December 2019 56 Product Version 19.12

The MISR value can be read when the MRD pin is asserted as shown in Figure 4-8 on
page 58. The SIO_SYS_S2M cell forces the I/O cell to accept the MISR output values and
transport them to the I/O pads.

Figure 4-7 OPMISR Scan Mode

December 2019 57 Product Version 19.12

Figure 4-8 OPMISR Read Operation

Another mode that has to be considered is the full scan ATPG mode, shown in Figure 4-9 on
page 59. In this mode the multiplexing logic inside the OPMISR block sets up the channels to
form N/2 scan chains that are fed scan data from the N/2 scan in pins and the test responses
are collected from the N/2 scan out pins.

December 2019 58 Product Version 19.12

Figure 4-9 Normal ATPG Scan Test using OPMISR

Channel Masking Logic

Channel masking is a method that provides a way to ignore unknown (X) values that may
appear in measure register bits. The MISR signature is unpredictable without the ability to
mask these unknown values.

December 2019 59 Product Version 19.12

Typical scenarios where channel masking may be used are:

■ In an ASIC environment where automatic insertion of channel masking logic is desired.
■ In a custom environment where user-defined channel masking logic is desired.

Refer to “Implementing Channel Masking Logic in a Design” on page 62 for additional

information.

Channel mask registers are loaded from scan-in pins and allow some channels to be masked
out while others can be allowed into the MISR. A single channel mask bit may mask out one
or more channels. The Channel_Mask_Enable (CME) test function pin indicates whether the
channel mask bits should apply to the current scan cycle. When all CME pins are at their
specified (stability) value, no masking is performed. Two CME pins support a total of three sets
of channel mask bits plus one non-masking state. This implementation is called a WIDE2
channel mask and is illustrated in Figure 4-10.

Figure 4-10 WIDE2 Channel Masking Logic for One Channel

The preceding figure shows that one of the four CME encoding states (CME0, CME1 = 11) is
used to mask out all channels without the need to load any mask bits. Note that CME pins are
specified with a polarity. In Figure 4-10, both signals would have been specified as -CME to
denote that when they are both at 0, the channels should pass through unimpeded to the
MISR. This is also the state that is applied when first tracing backward from the MISR to look
for the measure registers (channels). The masking logic example shown in Figure 4-10 could

December 2019 60 Product Version 19.12

be shared with several channels so that all like channels would be masked in or masked out
simultaneously. For channels that can be independently masked, this logic is replicated for
each independent set of channels that can be masked, including a replication of the mask bit
memory elements.

The examples in Figure 4-11 and Figure 4-12 denote how a single CME pin may be used. In
Figure 4-11 , a single mask bit is applied when the CME pin is asserted. This implementation
is called a WIDE1 channel mask.

Figure 4-11 WIDE1 Channel Masking with a Single CME Signal

In Figure 4-12, there is no such mask bit; instead, when the CME is asserted, all channels are
masked out. This implementation is called a WIDE0 channel mask.

Figure 4-12 WIDE0 Channel Masking without Mask Bits

Modus supports any combination of the three channel masking implementations (WIDE0,
WIDE1, WIDE2) in the same testmode except that no CME pin state can unconditionally block
some channels while conditionally (under control of mask bits) blocking other channels.

December 2019 61 Product Version 19.12

Figure 4-13 shows channel mask bits loaded from the scan-in pins using the
Channel_Mask_Load (CML) clock. The Channel_Mask_Load_Enable (CLME) test function pin
defines how to enable the CML clocks to load values from the scan-in pins into the channel
mask register bits. This allows the CML clock function to be shared with an existing clock
function, but this is not required if a separate CML clock is defined that is used only for loading
the channel mask bits.

Use Channel Mask Load design state to analyze problems related to the loading of channel
masks. Channel_Mask_Input (CMI) pins indicate where mask bits are loaded from, however
if unspecified, Modus assumes that Scan_In (SI) pins serve this function. Refer to “Testmode
Design States” on page 272 for related information.

Figure 4-13 Mask Bits Loaded from the Scan-in Pin

Note: Note that each mask_enable signal will operate as if it was a scan input, as far as the
tester interface is concerned. This means that mask_enable signals will consume ATE scan
pin resources and thus will reduce the number of scan pins available for loading test data into
the design i.e., the masking-per-cycle information is considered to be additional test data.

Implementing Channel Masking Logic in a Design

To automatically insert channel masking logic, use Test Synthesis to select whether the
masking logic should be included. Test Synthesis inserts two CME pins and two sets of mask
bits with logic equivalent to that shown in Figure 4-10 on page 60.

After the masking logic is inserted, perform the following tasks:

1. Define the testmode, specifying at least one CME pin and one CML pin. Optionally,
Channel_Mask_Load_Enable (CMLE) pins may be defined that provide the state in which
the CML clock will load the mask bit data into the mask bit registers. CMI pins may also

December 2019 62 Product Version 19.12

be defined, however Modus assumes that all SI pins are also CMI pins when channel
masking is defined.
Refer to “ASSIGN” on page 147 for the syntax required to define the testmode using
these test function pins.
Note: If both CME and CML test functions are defined, the resulting sequence definition
file will contain these channel masking logic related sequence types:
❑ channelmaskprecond
❑ channelmaskload
❑ channelmaskcycle
❑ channelmaskexit
Refer to “Define_Sequence” in the Test Pattern Data Reference for descriptions of
these sequence types.
2. Analyze Test Structures to perform checking functions that validate masking logic.
3. Perform ATPG to determine fault coverage. If fault coverage is unacceptable due to
channel masking, submit another ATPG run and specify either:
❑ -Xprevent cycle to indicate that ATPG is to block all sources of X that can be
loaded onto any measure latch that scans out on the same scan cycle as the
measure latch used to observe the target fault.
or
❑ -Xprevent channel to indicate that ATPG is to block all Xs that can be loaded
into the same measure register (channel) as the measure latch used for the target
fault, and any other measure registers that are masked with the same mask register
bit.
Note: The fault coverage should improve using either method, however pattern counts
will likely increase.
If fault coverage is still unacceptable, specify -Xmask yes to allow all faults to be
detected, however this method produces higher data volumes.

Channel Masking on Pad Cycles

Channel masking signatures for OPMISR designs with unbalanced scan chains are
automatically calculated. Signature calculations for OPMISR+ designs with channel masking
differ in the following ways:

December 2019 63 Product Version 19.12

■ Short chains receive pre-padding zeros unless their scan-in also feeds longer chains.
■ OPMISR+ produces Fix_MISR events to account for non-zero padding and scan
overlap. This allows for tests to be reordered. Refer to “Fix_MISR” in the Test Pattern
Data Reference for details.

The preceding allows the possibility to mask out a scan cycle containing non-zero padding
and rendering the Fix_MISR event ineffective. The solution is to prevent masking on scan
cycles that may have a non-zero pad.

Figure 4-14 illustrates a channel masking scenario with variable length overlapped scans.

Figure 4-14 Variable Length Overlapped Scans

December 2019 64 Product Version 19.12

Figure 4-15 depicts a scenario of exposing the effectiveness of the Fix_MISR event due to
overlapped scans.

Figure 4-15 Exposure from Overlapped Scans without Masking

December 2019 65 Product Version 19.12

Figure 4-16 shows that the first shift in 1 of the second set of vectors (1 0 1) overlaps the
MISR for the shorter scan chain, while the MISR bit from the longer scan chain is still
unloading the previous scan unloads into the MISR.

Figure 4-16 Scan Overlap

For the shorter scan chain, the MISR for pattern 1 is affected by the second scan load in the
preceding figure.

The MISR signature is processed to properly calculate the extra value from the second cycle
of the MISR. In other words, the MISR Observe expected values are calculated considering
an extra bit from the next cycle.

In terms of tester hardware, this extra 1 from the next scan load would go inside the MISR
hardware and when misr observe attributes are applied it will affect the signature. In order to
account for this, the Fix_MISR event ensures that this extra bit has been considered when
determining the final MISR signature. The "Fix_MISR" signature is affiliated with the second
test pattern to allow for pattern reordering and ensuring correct MISR signatures.

Tip
The Fix_MISR event is not required if there is no scan overlapping; there are
constant 0’s instead of changing values in the second scan.

December 2019 66 Product Version 19.12

If an X value is propagated into a MISR, the signature is rendered invalid. The term X-mask
padding is the use of the channel mask unit to mask X values to avoid masking a value from
the next cycle in the shorter scan chain.

Figure 4-17 illustrates an X-mask padding problem caused by a two bit shift.

Figure 4-17 X-Mask Padding Problem

December 2019 67 Product Version 19.12

Figure 4-18 illustrates a solution to the X-mask problem in the preceding figure by using X-
mask 0 padding.

Figure 4-18 X-Mask 0 Padding Solution

Figure 4-18 illustrates why "X’s" must be masked by the channel mask unit before they can
propagate inside the MISR. The term X-mask 0 padding is the avoidance of masking a value
from the next cycle in the shorter scan chain by adding padding cycle "0" values. X-mask 0
padding is required to reorder patterns.

December 2019 68 Product Version 19.12

The amount of 0 padding is based upon where the X’s are found in the channels and the
presence of channel length differences feed by the same scan inputs as illustrated in
Figure 4-19 .

Figure 4-19 X-Mask Channel Masking on Pad Cycles

Tip
X-mask 0 padding is not required without scan overlapping because there will be
no second cycle following the first cycle.

An optimum OPMISR+ design goal is to ensure all scan channels fed by the same scan-In
are the same approximate length. Stated differently, for each scan-in pin where the pin fans
out, it is recommended that each fan-out have the same scan chain length

The following is a design example where 0 padding is required:

Controllable Scan Chain 5
Load Pin Index / Pin Name 211 / PI_Pin
Bit Length 493
Scan Section Sequence Scan_Section_Sequence
Observable Register 5
Unload Pin Index / Pin Name 2583136 / macro_pin1
Bit Length 493 Unload pin inverted from Load Pin
Scan Section Sequence Scan_Section_Sequence
Feeds MISR Register 1 Bit 5 Inverted
Observable Register 53
Unload Pin Index / Pin Name 2583412 / macro_pin2

December 2019 69 Product Version 19.12

Bit Length 43 Unload pin inverted from Load Pin

Scan Section Sequence Scan_Section_Sequence
Feeds MISR Register 1 Bit 53 Inverted

The preceding example is a 43 bit scan chain and a 493 bit scan chain within the same fan-
out group. Because the 43 bit scan chain will finish scanning before the 493 bit scan chain,
the scan in data must be padded with 0’s to ensure that values are going into the MISR for
the full length of the scan. This means the scan-in becomes approximately 900 bits as
opposed to approximately 500 bits. This is because for the 450 bits (493-43 bits) pad 0’s must
be padded to ensure the short 43 bit scan chain has consistent values into the MISR. The
scan data can be scanned in after the padding.

Building a Testmode for OPMISR, OPMISR+

The Modus testmodes will automatically be generated from Genus allowing users to process
a design containing an OPMISR or OPMISR+ module through Test Structure Verification and
ATPG. The assign file identifies the scan in and scan out data pins and the various test control
signals. Figures Figure 4-20 on page 72, Figure 4-21 on page 73, and Figure 4-22 on
page 74 show the ATPG, OPMISR and OPMISR+ testmode assign files for the DLX tutorial
design. Refer to Assign File for additional information on creating a testmode assign file. This
design uses an OPMISR+ macro with a misr size of 16, a fanout of 5, and included WIDE2
channel masking.

Configuring Pin Assignments for Scan

Scan is entered by the scanentry sequence, and exited by the scanexit sequence. In
between, in order, are the optional mask_load, scan load/unload, MISR_read, and
MISR_reset states. The +/-SE flag sets the value of a pin for all four of those states unless
overridden by one or more of the MRD, MRE, or CMLE flags for a specific state. Thus, the MRD,
MRE, and CMLE pins require an SE flag to set the default scan value and any necessary state
override. When not in scan (during test launch/capture), these can take any value unless
there is also a TC (Test Constraint) flag.

MRC is a port on the OPPLUS macro; MRE is the test flag associated with that port, MISR
Reset Enable is the function (it is not a clock, but a clock gate).

CK, the MISR_Clock, is assumed to be a test clock dedicated to the MISR/Mask logic and
not used elsewhere. It can be used elsewhere, but must be degated for at least the
Mask_Load and MISR_Reset states. This must be manually configured.

When using OPMISR+, the scan tests for FULLSCAN, OPMISR, and OPPLUS modes should
all be generated and committed first before starting ATPG on the rest of the logic. Verify that
FULLSCAN and OPMISR/OPPLUS are getting cross-mode markoff.

December 2019 70 Product Version 19.12

The following tables depict pin usage combinations for the FULLSCAN, OPMISR/OPPLUS, and
Channel Masking.

Table 4-3 FULLSCAN Mode Pin Matrix

Pin Type Direction Shareable Test Function

Test Clock Input Yes -ES (can be functional clock)
Scan Enable Input Yes +SE, -MRE (MRE for compression only)
Test Enable Input No +TI
Scan In (N) Input Yes SI
Scan Out (M) Output Yes SO

Table 4-4 OPMISR/OPMISR+ Mode Pin Matrix

Pin Type(s) Direction Shareable Test Function

S2M Input Yes +TI, -SE (optional if using OPMISR+
only)
OPPLUS Input Yes -TI, -SE
MISR Reset Input No MRST, -ES, -CML (CML for masking
MISR Clock only)
MISR Reset Enable Input Yes +MRE, -SE
MISR Read Enable Input Yes +MRD (optional if using unidirectional)

December 2019 71 Product Version 19.12

Table 4-5 Channel Masking Pin Matrix

Pin Type(s) Direction Shareable Test Function WIDE0 WIDE1 WIDE2

CME0 Input Yes -CME Yes Yes Yes
CME1 Input Yes -CME No Yes
CMLE Input Yes -CMLE No Yes Yes

Assign File Examples

The following are examples of ASSIGN files that configure scan-based testmodes. Refer to
“ASSIGN” for related information.

Figure 4-20 Testmode Assign File for Full-Scan ATPG

assign pin=DLX_CHIPTOP_TEST_ENABLE test_function= +TI;

assign pin=DLX_CHIPTOP_TEST_CLOCK test_function= -ES;
assign pin=DLX_S2M test_function= -TI;
assign pin=DLX_MRD test_function= -SE;
assign pin=DLX_MRE test_function= -SE;
assign pin=DLX_MRST test_function= -ES;
assign pin=DLX_OPPLUS test_function= -TI;
assign pin=DLX_CME0 test_function= -SE;
assign pin=DLX_CME1 test_function= -SE;
assign pin=DLX_CMLE test_function= +SE;
assign pin=DLX_CHIPTOP_TDI test_function= -TI;
assign pin=DLX_CHIPTOP_TCK test_function= +TI;
assign pin=DLX_CHIPTOP_TMS test_function= -TI;
assign pin=DLX_CHIPTOP_TRST test_function= -TI;
assign pin=DLX_CHIPTOP_SE test_function= +SE;
assign pin=DLX_CHIPTOP_RESET test_function= +SC;
assign pin=DLX_CHIPTOP_SYS_CLK test_function= -ES;
assign pin=SI0 test_function= BDY, SI;
assign pin=SI1 test_function= BDY, SI;
assign pin=SI2 test_function= BDY, SI;
assign pin=SI3 test_function= BDY, SI;
assign pin=SI4 test_function= BDY, SI;
assign pin=SI5 test_function= BDY, SI;
assign pin=SI6 test_function= BDY, SI;
assign pin=SI7 test_function= BDY, SI;
assign pin=SO0 test_function= BDY, SO;
assign pin=SO1 test_function= BDY, SO;
assign pin=SO2 test_function= BDY, SO;
assign pin=SO3 test_function= BDY, SO;
assign pin=SO4 test_function= BDY, SO;
assign pin=SO5 test_function= BDY, SO;
assign pin=SO6 test_function= BDY, SO;
assign pin=SO7 test_function= BDY, SO;

December 2019 72 Product Version 19.12

Figure 4-21 Testmode Assign File for OPMISR Mode

============================================================
/* Identify the feedback net of the OPMISR */
sig_reg="MISR_Register_1" {
Register=(
"comp_macro.m1.\misrbitsout_reg[0]",
……
"comp_macro.m8.\misrbitsout_reg[0]“);
Register_Cell_Equation=(
"comp_macro.m1.\misrbitsout_reg[0]"="comp_macro.m8.\misrbitsout_reg[0]",
……
"comp_macro.m4.\misrbitsout_reg[0]"="comp_macro.m3.\misrbitsout_reg[0]"+"comp_ma
cro.m8.\misrbitsout_reg[0]",
……
"comp_macro.m8.\misrbitsout_reg[0]"="comp_macro.m7.\misrbitsout_reg[0]");
};
assign pin=DLX_CHIPTOP_TEST_ENABLE test_function= +TI;
assign pin=DLX_CHIPTOP_TEST_CLOCK test_function= -ES;
assign pin=DLX_S2M test_function= +TI;
assign pin=DLX_MRD test_function= +MRD, -SE;
assign pin=DLX_MRE test_function= +MRE, -SE;
assign pin=DLX_MRST test_function= -ES, -MRST, -CML;
assign pin=DLX_OPPLUS test_function= -TI;
assign pin=DLX_CME0 test_function= -CME;
assign pin=DLX_CME1 test_function= -CME;
assign pin=DLX_CMLE test_function= +CMLE;
assign pin=DLX_CHIPTOP_TDI test_function= -TI;
assign pin=DLX_CHIPTOP_TCK test_function= +TI;
assign pin=DLX_CHIPTOP_TMS test_function= -TI;
assign pin=DLX_CHIPTOP_TRST test_function= -TI;
assign pin=DLX_CHIPTOP_SE test_function=+SE, -MRE;
assign pin=DLX_CHIPTOP_RESET test_function= +SC;
assign pin=DLX_CHIPTOP_SYS_CLK test_function= -ES;
assign pin=SI0 test_function= SI, MO;
assign pin=SI1 test_function= SI, MO;
assign pin=SI2 test_function= SI, MO;
assign pin=SI3 test_function= SI, MO;
assign pin=SI4 test_function= SI, MO;
assign pin=SI5 test_function= SI, MO;
assign pin=SI6 test_function= SI, MO;
assign pin=SI7 test_function= SI, MO;
assign pin=SO0 test_function= SI, MO;
assign pin=SO1 test_function= SI, MO;
assign pin=SO2 test_function= SI, MO;
assign pin=SO3 test_function= SI, MO;
assign pin=SO4 test_function= SI, MO;
assign pin=SO5 test_function= SI, MO;
assign pin=SO6 test_function= SI, MO;
assign pin=SO7 test_function= SI, MO;
assign pin=COMPACTOR.co[0] test_function= CHI;
assign pin=COMPACTOR.ci[0] test_function= CHO;

December 2019 73 Product Version 19.12

Figure 4-22 Testmode Assign File for OPMISR+ Mode

sig_reg="MISR_Register_1" {
Register=(
"comp_macro.m1.\misrbitsout_reg[0]",
……
"comp_macro.m8.\misrbitsout_reg[0]“);
Register_Cell_Equation=(
"comp_macro.m1.\misrbitsout_reg[0]"="comp_macro.m8.\misrbitsout_reg[0]",
……
"comp_macro.m4.\misrbitsout_reg[0]"="comp_macro.m3.\misrbitsout_reg[0]"+"comp_ma
cro.m8.\misrbitsout_reg[0]",
……
"comp_macro.m8.\misrbitsout_reg[0]"="comp_macro.m7.\misrbitsout_reg[0]");
};
assign pin=DLX_CHIPTOP_TEST_ENABLE test_function= +TI;
assign pin=DLX_CHIPTOP_TEST_CLOCK test_function= -ES;
assign pin=DLX_S2M test_function= -TI;
assign pin=DLX_MRD test_function= +MRD, -SE;
assign pin=DLX_MRE test_function= +MRE, -SE;
assign pin=DLX_MRST test_function= -ES, -MRST, -CML;
assign pin=DLX_OPPLUS test_function= +TI;
assign pin=DLX_CME0 test_function= -CME;
assign pin=DLX_CME1 test_function= -CME;
assign pin=DLX_CMLE test_function= +CMLE;
assign pin=DLX_CHIPTOP_TDI test_function= -TI;
assign pin=DLX_CHIPTOP_TCK test_function= +TI;
assign pin=DLX_CHIPTOP_TMS test_function= -TI;
assign pin=DLX_CHIPTOP_TRST test_function= -TI;
assign pin=DLX_CHIPTOP_SE test_function=+SE, -MRE;
assign pin=DLX_CHIPTOP_RESET test_function= +SC;
assign pin=DLX_CHIPTOP_SYS_CLK test_function= -ES;
assign pin=SI0 test_function= SI, MO;
assign pin=SI1 test_function= SI, MO;
assign pin=SI2 test_function= SI, MO;
assign pin=SI3 test_function= SI, MO;
assign pin=SI4 test_function= SI, MO;
assign pin=SI5 test_function= SI, MO;
assign pin=SI6 test_function= SI, MO;
assign pin=SI7 test_function= SI, MO;
assign pin=SO0 test_function= SI, MO;
assign pin=SO1 test_function= SI, MO;
assign pin=SO2 test_function= SI, MO;
assign pin=SO3 test_function= SI, MO;
assign pin=SO4 test_function= SI, MO;
assign pin=SO5 test_function= SI, MO;
assign pin=SO6 test_function= SI, MO;
assign pin=SO7 test_function= SI, MO;
assign pin=COMPACTOR.co[0] test_function= CHI;
assign pin=COMPACTOR.ci[0] test_function= CHO;
assign pin=COMPACTOR.co[1] test_function= CHI;
assign pin=COMPACTOR.ci[1] test_function= CHO;

December 2019 74 Product Version 19.12

Waveform Example

Figure 4-23 is an example waveform based on an OPMISR+ testmode with defined

MISR_Observe test function.

Figure 4-23 OPMISR Waveform Example

Insertin
g Block-Level Test Compression
The preceding sections describe the OPMISR+ methodology that has been automated for
insertion at the top-level of the design. With the standardization of core-based testing
methods by the IEEE 1500 standard (see IEEE 1500 Core Wrapping Logic), it may be
desirable to integrate cores that already have built-in test compression hardware. In a SoC
methodology the following are potential advantages of supporting OPMISR+ insertion at the
block or core-level:
■ An efficient bottom-up design flow is supported with the following features:

December 2019 75 Product Version 19.12

❑ Each core can be separately verified using Verify Test Structures. Refer to “Verify
Test Structures” in the Modus: Guide 3: Test Structures for additional
information.
❑ Core fault coverage can be analyzed before SoC is integrated.
❑ Independently verifying each core simplifies SoC-level DFT verification.
❑ Impact of late design changes and ECs on DFT is minimized.
■ Multiple embedded cores with OPMISRs can be concurrently tested.
■ Mutually exclusive Scan I/Os
■ The same test control inputs are shared
■ Tests are generated at the SoC-level (no test re-use / migration).
■ Cores with embedded OPMISRs can be concurrently tested with a global OPMISR for
glue logic and other user-designed logic (UDL).
■ Sequential testing of embedded cores can be easily supported by scheduling the test
session of each (group of) core(s) serially.
Note: Insertion of OPMISR+ compression logic is only supported on systems that have
Genus installed (when running Genus within Modus a separate Genus license is not
required).

Figure 4-24 on page 77 shows the top-level OPMISR+ used in a SoC design. One embedded
core is shown on the left and the UDL is shown on the right. An OPMISR block of size N is
embedded at the top-level. The core has NxM1 scan chains and the UDL has NxM2 scan
chains. The total number of internal scan chains is Nx(M1+M2). At the top-level of the chip
these may be connected to N/2 bi-directional scan in ports and N/2 scan out ports. Alternately,
these may be connected to N uni-directional scan input ports and N uni-directional scan out
ports.

December 2019 76 Product Version 19.12

Figure 4-24 Top-Level OPMISR+

An alternate approach that may be used in a core-based flow is to use an N1-sized OPMISR+
block within the core and an N2-sized OPMISR+ block within the UDL with fanouts of M1 and
M2 respectively. This results in N1xM1 scan chains within the core and N2xM2 scan chains
within the UDL. These can be connected to N1+N2 scan I/O ports at the top-level of the
design. If the scan I/Os are bi-directional then there can be (N1+N2)/2 scan in and scan
out ports each. If there are only uni-directional scan I/Os, then there will be (N1 + N2) scan
in and scan out ports respectively.

Currently there is no support for automatically connecting the top-level test access
mechanism (TAM) to the embedded OPMISR+ blocks

December 2019 77 Product Version 19.12

Figure 4-25 One OPMISR+ Embedded Within a core and Another Within the UDL

Commands for Block Level Test Compression

The Genus command compress_scan_chains creates scan chains beginning and ending
at the module boundary of the selected block. The command also supports embedding the
OPMISR+ logic within a block or core. Additionally, the command supports the configuration,
insertion, and connection of an embedded OPMISR+ block and creates scan channels
starting from the SWBOX_SI pins of the OPMISR+ module and terminating at the SWBOX_SO
pins of the OPMISR+ module.

December 2019 78 Product Version 19.12

2-D Elastic Decompression

The Modus 2-D Elastic Decompression consists of
■ 2-D Compression
■ Elastic Decompression

2-D Compression
The 2-D compression logic basically forms a two dimensional grid across the chip. This leads
to a lesser routing resource than the traditional single dimensional XOR compression.

Figure 4-26 2-D Compression

Elastic Decompression
In addition to enabling 2-D compression, Modus also supports the Elastic Decompression in
which the compression logic including registers and feedback loops are made sequential. It
enables compression ratios beyond 400X without the loss of fault coverage.

December 2019 79 Product Version 19.12

Figure 4-27 Elastic Decompression

As shown in Fig 4-27 the sequential elements have known feedback/loop structure. The scan
data is fed into the sequential blocks and the scan channels are fed by the output of the
sequential elements/spreader. The sequential elements shift in each scan cycle.

Using Elastic Decompression increases the ability to have more unique channel head XOR
equations. This allows for a larger number of channels without adding more correlation and
allows prior scan data to be used for current scan cycle. Sequential elements are reset
between each test to allow for unique patterns that can be sorted and exported. It supports
unique flexibility mode to allow more scan data to be used per pattern while keeping channels
of the same length.

For flexibility, Elastic Decompression supports two compression configurations. If Elastic

Decompression cannot achieve the desired coverage, scan input stages (Elasticity) can be
added. This reduces the compression ratio by increasing the scan bandwidth and shifting to
Elastic Decompression logic. This addition requires two additional pins i.e. doubling the Scan
Elastic Decompression. The Elastic Ratio determines the number of input stages. Fig 4-28
shows the Elastic Ratio in Elastic Decompression.

December 2019 80 Product Version 19.12

Figure 4-28 Doubling Elastic Decompression

An Elastic Ratio of 2 enables 2X the scan data to enter into sequential or Elastic
Decompressor. Doubling of scan inputs into the scan channels improves pattern generation
in Modus.

Modus ATPG Flow

The 2-D Decompression logic is natively integrated into the Genus™ physical synthesis flow
by using the set_2d_compression_options command that is typically run at beginning
of DFT setup.

The key options of the set_2d_compression_options include:

■ Specify the compression ratio
set_2d_compression_options -ratio 100

■ Specify elastic decompression

set_2d_compression_options -decompressor elastic

■ Enable masking
set_2d_compression_options -mask true -mask_sharing_ratio 1

■ Enable fullscan
set_2d_compression_options -fullscan true

When using 2D Compression, it is recommended to use multi-mode SDC processing in

Genus.
■ create_mode -name functional -default
■ read_sdc -mode functional <SDC file>
■ set_constraint_mode functional

December 2019 81 Product Version 19.12

When 2D compression is inserted, SCAN, Capture, Functional and other timing modes will
be generated to allow for all the different timing configurations required.

Prior to inserting 2-D compression, there is a verification checker to ensure that all the proper
pins and information has been defined.
check_dft_setup -2d_compression
syn_opt [-physical | -spatial] -2d_compression

For more information on the 2DE compression in Genus, refer to the section 2DE
Compression in Genus Design for Test Guide.

In Modus, ATPG can be performed using both Elastic as well as non-Elastic testmodes. The
standard ATPG flow is shown in Fig 4-29.

Figure 4-29 Modus ATPG Flow

The data required for building the 2D Elastic testmode is already written by Genus before
generating patterns in Modus ATPG.

To build the Elastic testmode in Modus specify the elastic testmode in the
build_testmode command.

Example:
build_testmode -workdir /my/work/dir -testmode ELASTIC \
-assignfile /my/AssignFile -modedef ELASTIC

December 2019 82 Product Version 19.12

Building a Testmode for 2D Elastic Decompression

The mode definition file that defines the Elastic testmode is shipped with Modus in
<$Install_Dir>/tb/defaults/rules/modedef directory.

In addition to the mode definition file to build the test mode, you need to specify the amount
of cycles needed to prime the elastic decompressor in the assign statement as shown below:

decompressorprimingcycles=10;

This value has been set based on the number of scan inputs and the width of the elastic
decompressor elements. It is recommended not to change this value as it can cause poor
coverages or excessive tester cycles if not done correctly.

For elastic decompression, the following are the unique test functions:
assign pin=DFT_comp_clk test_function= -ES,-CML; // compression_clock
assign pin=DFT_elastic_reset test_function= -PRST; // elastic_reset

The compression_clock is used as the clock to gate the elastic decompressor logic,
masking, and pipeline logic (if present). The elastic_reset signal resets the elastic
decompression.

The assign file contains definition of the Elastic Sequential elements and the channel head
and tails as shown below:
Elastic_Decomp="COMPACTOR" {
Register=("COMPACTOR.elastic_inst.elastic_out_reg_0_",
"COMPACTOR.elastic_inst.elastic_out_reg_1_",
"COMPACTOR.elastic_inst.elastic_out_reg_2_",
…
"COMPACTOR.elastic_inst.elastic_out_reg_52_");

Register_Cell_Equation=(
"COMPACTOR.elastic_inst.elastic_out_reg_0_"="COMPACTOR.elastic_inst.elastic_out_r
eg_52_"+"port_pad_data_in[0]"[2],
…
"COMPACTOR.elastic_inst.elastic_out_reg_52_"="COMPACTOR.elastic_inst.elastic_out_
reg_51_"+"port_pad_data_in[1]"[2]);
};

assign pin=COMPACTOR.int_co[0] test_function= CHI;

assign pin=COMPACTOR.int_ci[0] test_function= CHO;
…

December 2019 83 Product Version 19.12

compression_clock is used as the clock to gate the elastic decompressor logic, masking,
and pipeline logic (if present).

The elastic_reset signal resets the elastic decompressor sequential elements to a

known value when needed by ATPG.

Refer to “ASSIGN” on page 147 for more information on the ASSIGN statement syntax.

December 2019 84 Product Version 19.12

1149.1 Testmode
IEEE 1149.1 is the standard for boundary scan implementations. You design the core logic,
and the boundary scan is inserted along the periphery. Additional reference information is
contained in Supplement (B) to Standard Test Access Port and Boundary Scan
Architecture, IEEE Std. 1149.1-2001.

The JTAG macro inserted should conform to the IEEE 1149.1 1994 Standard. To observe and
control the functional I/O’s of a chip, independent of arbitrary system logic, Test Synthesis
creates a Boundary Register. The Boundary Register is comprised of boundary scan cells
inserted between each chip I/O and the system logic. By shifting values in and out of the
boundary register, via a standard 5 pin Test Access Port (TAP), you can observe the value of
each chip input and control the value of each chip output. This facilitates board level
interconnect testing independent of on-chip system logic.

If multiple boundary scan devices exist on a card, you can connect all Boundary Registers
into one large scan chain as shown in Figure 4-30 on page 86. By scanning appropriate test
data into, and capturing results out of this scan chain, the interconnections between the
devices can be tested. For additional information, see the IEEE Standard 1149.1, "IEEE
Standard Test Access Port and Boundary-scan Architecture".

December 2019 85 Product Version 19.12

Figure 4-30 Scan Chain with Multiple Boundary Scan Devices

IEEE 1149.1 Boundary Scan Features

In compliance with the IEEE 1149.1 standard, Modus supports the following mandatory
features:
■ Five pin TAP interface
■ TAP Controller (which controls the boundary scan architecture)
■ Instruction Register

December 2019 86 Product Version 19.12

■ Instruction Decode Logic

■ Bypass Register
■ Boundary Register
■ Test Data Output (TDO) logic

Modus also supports any number of optional data registers for control of other special test
structures. An example boundary scan architecture showing the mandatory design units,
both IDCODE and USERCODE registers, as well as a single optional test data register called
“Data Register 1” can be seen in Figure 4-31 on page 88.

December 2019 87 Product Version 19.12

Figure 4-31 IEEE 1149.1 Boundary Scan Architecture

December 2019 88 Product Version 19.12

In Figure 4-31 on page 88, the ENABLE line from the TAP Controller enables the output driver
of the TDO line. The SELECT line switches a multiplexor to select between the Instruction
Register and the bank of data registers that includes the Bypass Register and Boundary
Register. Each data register is selected through the Instruction Decode Logic and the data
register multiplexor. All registers use some subset of the DR, Common, and IR Control lines
from the TAP Controller.

The inputs to the TAP Controller are the Test Data Input (TDI), Test Clock (TCK), Testmode
Select (TMS), and an optional Test Reset (TRST). The output is the Test Data Output (TDO).
All test data is shifted from the TDI input to the TDO output through any one of the device's
registers, as selected by the current instruction.

When testing is performed, an instruction is serially loaded into each boundary scan device
on a card. Depending on the instruction, the Instruction Decode Logic selects which register
to connect between each device's TDI and TDO pins. Only one data register can be selected
at a time, however different instructions may select the same register. For example, the
EXTEST, SAMPLE, and INTEST instructions all select the Boundary Register. See the IEEE
1149.1 specification for further details on these instructions.

After the instruction is loaded, the test data is shifted in via TDI, and the test instruction is
executed. Upon completion the results can be obtained by shifting out the test data through
the TDO output. Once a test instruction is loaded, you can perform multiple tests by
repeatedly shifting test data through the TDI-TDO path.

Depending on the value of the TMS input, the state of the TAP Controller is changed on each
rising edge of the TCK. (The states and transitions of the TAP Controller are defined by the
IEEE 1149.1 Standard.) If the TAP Controller inputs include the optional TRST input, it can
be asynchronously reset to the Test-Logic-Reset state; otherwise, it can be synchronously
reset to the Test-Logic-Reset state by holding the TMS input high and clocking through at
least five cycles of TCK.

Boundary Register

A Boundary Register is typically made up of boundary scan flops and multiplexers which are
configured differently for different 1149.1 instructions. Figure 4-32 on page 90 shows a typical
boundary cell .This boundary cell contains 2 storage elements known as the capture and
update registers. The Capture element participates in shift operations for load/unload of the
boundary register and is connected between TDI and TDO (through other boundary
registers). The Update element is used to freeze a boundary cell output value such that

December 2019 89 Product Version 19.12

downstream logic can be isolated from the effects of switching capture data during load/
unload operations. The two multiplexers in this figure are used to select between shift data
(from/to other boundary cells) and functional data (from/to the users functional design).

Figure 4-32 Typical Boundary Scan Structure

Note: Test Synthesis requires appropriate synthesis rules for the boundary scan structures.

Boundary Scan Design Requirements

The most commonly recognized requirements for boundary scan design are described in the
IEEE 1149.1 Standard. However, two additional common test methodologies place additional
requirements on the boundary scan: Reduced Pin Count Testing, and Logic BIST.

Reduced Pin Count Testing (RPCT)

This is a test methodology being commonly adopted for chip manufacturing scan chain test,
particularly for larger chips. The I/O signal pins are divided into two groups: test pins, which
are contacted by full-function tester channels; and non-test pins, which are not contacted at
all during wafer test and may be contacted by inexpensive parametric test channels during
module test after packaging is complete.

Clearly, an I/O pin that is not contacted by a full function tester channel cannot be tested in
the normal way with digital test patterns. This is commonly resolved by what is called I/O

December 2019 90 Product Version 19.12

Wrap (IOW). All such non-test pins are provisioned with bidirectional driver/receiver designs,
even if the I/O is functionally input or output only. Boundary scan cells, accessible by the tester
during normal scan chain test, are used to drive patterns out the driver and then to receive
the signals back through the receiver without having to use tester facilities.

Logic BIST

Logic BIST is designed to take advantage of the boundary scan cells. The boundary scan
chain will be clocked with the rest of the STUMPS channels, and will be used to drive all inputs
to, and observe all outputs from, the functional logic. Boundary cells on inputs should not
capture data, and data scanned into boundary cells on outputs should not be visible at the
pads. This requires different designs for input and output boundary cells. An input to logic that
does not have the boundary scan cell controlling it can be tolerated only if the input is held to
a fixed, known, value at all times during logic BIST.

In the IEEE 1149.1 standard, some of the example boundary cells, for example BC-1, are
described as supporting the commands INTEST and RUNBIST, and other boundary cells, for
example BC-2, are described as not supporting INTEST and RUNBIST.

1149.1 Testmode Input Files

■ BSDL file (optional)
BSDL (Boundary Scan Design Language) is recommended by the IEEE 1149.1 standard
to specify boundary scan. Refer to “Boundary Scan Design Language” on page 244 for
details.
■ Package File(s)
A package file is an ASCII file which describes boundary scan cell definitions. The
package file is in the form of a standard VHDL package file definition.
One package file must be provided for each package reference in the BSDL file “USE”
statement. This normally includes an IEEE 1149.1 Standard package file (for example,
STD_1149_1_1994) and zero or more user defined package files (for example,
IBMDFT_1149_1_1998_V5).
The Standard package files are shipped with Modus ($Install_dir/
tools.<ARCH>/tb/defaults/bsdl) while the user-defined package file(s) are
provided by the technology provider or design team, in the case of custom boundary
scan cell designs.
For an example, refer to the package file that was shipped with Modus in directory
$Install_dir/tools.<ARCH>/tb/defaults/bsdl.

December 2019 91 Product Version 19.12

1149.6 Testmode
IEEE 1149.6 is the standard that addresses interconnect testing between chips. Two areas
are focused upon: differential circuits and AC coupled circuits. Additional reference
information is contained in "IEEE Standard for Boundary-Scan Testing of Advanced
Digital Networks", IEEE Std. 1149.6 -2003.

The IEEE 1149.1 boundary scan standard addressed the problem of static testing of
interconnects between chips on a board. Two topics that were not completely addressed by
the 1149.1 standard are the following:
1. Differential Circuits
The 1149.1 standard models differential circuits as single ended circuits ignoring a large
percentage of the potential defects that may occur on such a circuit.
2. AC Coupled Circuits
These are capacitatively coupled interconnects that do not permit static signals. This is
due to the difficulty in switching an output at much greater than 100 KHz using the
capabilities provided by the 1149.1 standard, which is virtually a DC level with respect to
a typical AC Coupled circuit.

The 1149.6 standard addresses both limitations. The 1149.6 standard requires that both legs
of a differential input are capable of being independently monitored. It also addresses passing
signals through capacitors by providing the following new capabilities.
1. Generation of Pulses of a period equal to one period of the Test Clock (TCK) input to the
TAP controller (the new EXTEST_PULSE instruction).
2. Generation of Trains of Pulses whose frequency is one half of the Test Clock (TCK) input
to the TAP controller (the new EXTEST_TRAIN instruction).
3. Definition of a test receiver that is able to detect the signals received by an AC coupled
receiver in the presence of a Pulse or Pulse Train and reconstruct the original signal.

The 1149.6 Test Receiver

The key to measuring AC signals in the 1149.6 standard is the Test Receiver. The truth table
for the Test Receiver is shown in Table 4-6 on page 93. This cell is a storage element that
stores a one whenever an input signal (A) is above a certain limit (VHIGH) and stores a zero
whenever the input signal (A) is below another limit (VLOW). When the input signal (A) is
between VHIGH and VLOW, the state can be set using a data signal (PD) and a clock (PC). To
detect for the input signal (A) exceeding the upper threshold, VHIGH, the state of the Test
Receiver is first set to zero using the PD and PC signals. A pulse is transmitted to the input (A)

December 2019 92 Product Version 19.12

and the output of the Test Receiver is examined. If the state is one, the pulse passed the
threshold. If it remains a zero, the pulse never passed the threshold. A similar test can be
used to detect for a pulse which pulls the input signal below VLOW. In this case, PD and PC are
used to first set the state of the Test Receiver to a one. During AC testing in 1149.6, failure to
detect such pulses is typically considered a fault in the circuit.

Table 4-6 Test Receiver Truth Table

Input Signal (A) PC PD OUTPUT (Z)

A > VHIGH X X 1
A < VLOW X X 0
VLOW < A < VHIGH 0 X Previous state
VLOW < A < VHIGH 1 (or rising) 0 0
VLOW < A < VHIGH 1 (or rising) 1 1

Test Receivers are typically employed on the inputs of circuits to measure AC signals arriving
at the chip inputs. By contrast, the capability to transmit AC signals on the chip outputs is
achieved by a slight addition to the boundary cell logic. Figure 4-33 on page 94 shows the
configuration of the test receiver and how it can be observed by a boundary cell.

December 2019 93 Product Version 19.12

Figure 4-33 Test Receiver Configured with Input Boundary Cells for Observability and
Controllability

Figure Figure 4-34 on page 95 shows the modification to the boundary cell’s output logic. As
in the 1149.1 standard, a Mode signal is used to switch the boundary cell output between
mission mode and the data in the update latch. Two additional signals have been added to
control behavior for AC signals. First, the AC mode signal selects the DC behavior and the
new 1149.6 AC behavior. When the AC mode signal is selected, the second new signal, the
AC Test Signal, is used to toggle the output of the boundary cell.

December 2019 94 Product Version 19.12

Figure 4-34 Changes to Output Boundary Scan Cells

Support for the Level Sensitive Test Receiver

The preceding description is for the edge-sensitive test receiver. IEEE Standard 1149.6-2003
was written assuming that the initialization of 1149.6 (ac) test receivers would be
accomplished at a particular clock edge, and the examples in the standard are based on an
assumption that test receivers are initialized in response to a rising transition of a preload
clock. However, in practice, many 1149.6 (ac) test receivers are initialized by a level-sensitive
enable signal; as long as the enable signal is active, the test receiver is held in its initialized
state.

The 1149.6 JTAG_MACRO supports both test receivers with edge-sensitive initialization and
those with level-sensitive initialization. Specifically, the JTAG_MACRO output JTAG_ACPSCLK
is created to supply a positive-active edge-sensitive clock signal to test receivers that have
edge-sensitive initialization. The JTAG_MACRO output JTAG_ACPSEN is created to supply a
positive-active level-sensitive enable signal to test receivers that have level-sensitive
initialization. Furthermore, the dft_pin_function attribute TR_PEN is used to identify a
pin on a test receiver cell that is initialized by a high level. The dft_pin_function attribute
TR_PC is used to identify a pin on a test receiver that is initialized by a rising transition.

Changes to the 1149.6 TAP Controller

Support of the 1149.6 standard requires very few changes to the TAP controller described in
the 1149.1 standard, These changes are intended to be upward compatible to the 1149.1
specification in order to permit 1149.1 to perform DC testing on 1149.6 compliant chips. The
following are the changes:
■ Introduction of the EXTEST_TRAIN and EXTEST_PULSE instructions. These instructions
must have unique opcodes but must cause the Boundary Scan Register to operate in a
manner that is identical to the EXTEST instruction described in the 1149.1 standard. This
implies that the existing boundary register mode control outputs of the 1149.1 controller

December 2019 95 Product Version 19.12

must behave in the same manner for these new instructions as they do for the 1149.1
EXTEST.
■ Addition of an output (referred to in the standard as "AC Test Signal") which is used by
the boundary scan cells of all AC Coupled output pins.
■ Addition of a clock output used to preset the storage circuitry that is part of the hysteretic
comparator in the Test Receiver cell. Addition of an output which is the logical OR of the
decode of the EXTEST_TRAIN and EXTEST_PULSE instructions. The output may either
directly drive or be ANDed with the output of an AC/DC selection cell to drive the AC
Mode input of a boundary scan cell which supports AC Test.

Figure 4-35 Generation of an AC Test Signal

December 2019 96 Product Version 19.12

Figure 4-36 Generation of an Initialization Clock

December 2019 97 Product Version 19.12

Figure 4-37 JTAG_ACPSCLK, JTAG_ACPSEN, and JTAG_ACPULSE Implementation

Details

Given the preceding requirements, modify the 1149.1 controller logic (called the
JTAG_MACRO if inserted by Test Synthesis) by adding the following four output ports:
1. JTAG_ACDCSEL
The logical OR of the EXTEST_PULSE and EXTEST_TRAIN being decoded. This should
be implicitly connected to the AC pin on all Test Receivers. This signal should also control
the multiplexer which is added to the output Boundary Scan cells.
2. JTAG_ACPSCLK
The Init clock signal shown in Figure 4-37 is an example implementation. This signal
should be implicitly connected to the PC pin of all test receivers.
3. JTAG_ACPSEN

December 2019 98 Product Version 19.12

The JTAG_ACPSEN signal shown in Figure 4-37 on page 98 is an example

implementation. This signal should be implicitly connected to the PEN pin of all level
sensitive test receivers.
4. JTAG_ACPULSE
The AC Test Signal output shown in Figure 4-35 on page 96. This signal should be
implicitly connected to one input of the XOR gate which is added to the Boundary Scan
Cell.
5. JTAG_ACTRENBL
Drives the RD pin of the Test Receiver if present. This signal is the logical OR of EXTEST,
EXTEST_PULSE and EXTEST_TRAIN and any other instruction which expects the Test
Receiver to be enabled.

Changes to the Output Boundary Scan Cell

Boundary Scan Cells which drive system outputs in support of the 1149.1 specification
normally contain logic similar to the logic shown on the left of Figure 4-34 on page 95. To
support the requirements of the IEEE 1149.6 standard, the Boundary Scan Cell must be
augmented as shown in Figure 4-34 on page 95 on the right for all output cells which are to
support AC Testing. The AC Mode signal is driven by the TAP controller or by the logic AND
of the TAP controller and a boundary scan cell. The AC Test Signal is generated by the logic
shown in Figure 4-35 on page 96. The 1149.6 standard requires that the coding of the BSDL
(Boundary Scan Description Language) specification of the AC Mode signal be done in a
manner to cause an 1149.1 compliant tool to set it to a zero value, leaving the Boundary Scan
logic effectively unchanged.

An example implementation of an augmented output boundary cell is shown in Figure 4-38

on page 100.

December 2019 99 Product Version 19.12

Figure 4-38 Augmented Output Boundary Cell with 1149.6 Support

IEEE 11496 Boundary Cells

Table 4-7 lists the names of the IEEE_11496 boundary cells and describes their usage.

December 2019 100 Product Version 19.12

Table 4-7 IEEE_11496 Boundary Cells and Usage

System Test Required

Cell Name Usage Reference
Function Function Pins
BC_11496_ACTR Input Any with Test I/O ADI, TDI, Figure 4-39
Clock appropriate CLOCKDR, on
Bidirectional sharing logic SHIFTDR, page 104
ADO, TDO
BC_11496_ Bidirectional Any with Test I/O OE, DDI, Figure 4-40
BIDIR appropriate or Non- RDI, TDI, on
sharing logic Test I/O CLOCKDR, page 104
SHIFTDR,
UPDATEDR,
MODE_A,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, RDO,
TDO
BC_11496_ Bidirectional Test input Test I/O OE, TE, DDI, Figure 4-41
BIDIR_TI RDI, TDI,, on
CLOCKDR, page 105
SHIFTDR,
UPDATEDR,
MODE_A,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, RDO,
TDO

December 2019 101 Product Version 19.12

System Test Required

Cell Name Usage Reference
Function Function Pins
BC_11496_ Bidirectional Test Output Test I/O SE, OE, Figure 4-42
BIDIR_TO DSO, DDI, on
RDI, TDI, page 106
CLOCKDR,
SHIFTDR,
UPDATEDR,
MODE_A,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, RDO,
TDO
BC_11496_ Bidirectional Test output; Test I/O OE, DSO, Figure 4-43
BIDIR_TO_OO also used OO, SE, on
for macro MTOC, DDI, page 107
test RDI, TDI,
observation CLOCKDR,
SHIFTDR,
UPDATEDR,
MODE_A,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, RDO,
TDO
BC_11496_OUT Output2 Any with Test I/O DDI, TDI, Figure 4-44
Output3 appropriate CLOCKDR, on
sharing logic SHIFTDR, page 108
UPDATEDR,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, TDO

December 2019 102 Product Version 19.12

System Test Required

Cell Name Usage Reference
Function Function Pins
BC_11496_ Output2 None Non- RDI, DDI, Figure 4-45
OUT_NT Output3 Test I/O TDI, on
CLOCKDR, page 109
SHIFTDR,
UPDATEDR,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, TDO
BC_11496_ Output2 Test input Test I/O DDI, TDI, Figure 4-46
OUT_TI Output CLOCKDR, on
SHIFTDR, page 110
UPDATEDR,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, TDO
BC_11496_ Output2 Test output Test I/O SE, DSO, Figure 4-47
OUT_TO Output3 DDI, TDI, on
CLOCKDR, page 111
SHIFTDR,
UPDATEDR,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, TDO
BC_11496_OUT_ Output2 Test output; Test I/O DSO, OO, Figure 4-48
TO_OO Output3 also used SE, MTOC, on
for macro DDI, TDI, page 112
test CLOCKDR,
observation SHIFTDR,
UPDATEDR,
MODE_C,
ACPULSE,
ACDCSEL,
DDO, TDO

December 2019 103 Product Version 19.12

Figure 4-39 BC_11496_ACTR

Figure 4-40 BC_11496_BIDIR

December 2019 104 Product Version 19.12

Figure 4-41 BC_11496_BIDIR_TI

December 2019 105 Product Version 19.12

Figure 4-42 BC_11496_BIDIR_TO

December 2019 106 Product Version 19.12

Figure 4-43 BC_11496_BIDIR_TO_OO

December 2019 107 Product Version 19.12

Figure 4-44 BC_11496_OUT

December 2019 108 Product Version 19.12

Figure 4-45 BC_11496_OUT_NT

December 2019 109 Product Version 19.12

Figure 4-46 BC_11496_OUT_TI

December 2019 110 Product Version 19.12

Figure 4-47 BC_11496_OUT_TO

December 2019 111 Product Version 19.12

Figure 4-48 BC_11496_OUT_TO_OO

Verifying the Boundary Scan Implementation

Due to the backward compatibility of the IEEE 1149.6 specification to IEEE 1149.1, a
substantial portion of the validation can be performed by using the existing 1149.1 Boundary
Scan Verification support. The selection of the boundary register during EXTEST_PULSE and
EXTEST_TRAIN is also verified. Currently no explicit checks verify the pure 1149.6
extensions. The following lists the specific limitations:
1. Verification of the connection of AC, PC, PD and other 1149.6 control pins is not
performed.
2. Verification of the additional JTAG TAP structures added in support of 1149.6 is not
performed.

Refer to “Verify 1149.1 Boundary Scan” in the Modus : Guide 3: Test Structures for details
on how to verify the 1149.1 and 1149.6 implementation.

December 2019 112 Product Version 19.12

LBIST Testmodes

Testmode Statements for LBIST

Refer to “Mode Definition Statements” on page 128 for more information on the following
LBIST Testmode Statements:
■ SCAN – indicates that the inputs and outputs are from on_board structures rather than
primary input/output pins.
■ TEST_TYPES – indicates that signature data is to be generated (SIGNATURES=yes)
■ ON_BOARD_PRPG / ON_BOARD_MISR – indicates the location of the PRPGs, MISRs,
and the polynomial that identifies the LFSR feedback (tap positions)
■ ASSIGN – indicates the test functions of pins used for clocks/controls. See previous task
flow for a list of commonly used test functions for LBIST.
■ SIGNATURE_OBSERVATION_MODE – identifies the name of an existing testmode to
be used to observe the MISR. Typically this is used if there is no parent testmode or the
parent testmode scan chains are very long.
Note: The ASSIGN and ON_BOARD_PRPG/ON_BOARD_MISR definitions may be
done through attributes in the netlist, or the Mode Definition statements which may be
coded in either a MODEDEF file or a separate ASSIGNFILE. If the same pin/net/block is
included in multiple places, the value in the MODEDEF overrides the value in the netlist
and the value in the ASSIGNFILE overrides both the netlist and the MODEDEF.

If using an on-product LBIST controller, you might also need to see the information on OPCG
(On-Product Clock Generation), CUTPOINTS, and ASSIGN PPI.

Signature Observation Sequences for LBIST

At the end of a LBIST test, it is usually desirable to observe the results as stored in the on-
board MISR. This observation is often done by means of a scan operation. Of course, the
scan operation requires switching to a different testmode because the MISR, by definition, is
not scannable when the product is configured to the LBIST mode. This points out the need
for a possibly non-trivial sequence to scan out the MISR contents.

Modus can automatically generate the signature observation sequence, given the name of
the scan mode to be used. In so doing, it assumes that the observation is by means of a scan
operation, and that switching to the scan mode can be accomplished by a single pattern that
switches some testmode control primary inputs. If either of these assumptions does not apply,
then you must code the signature observation sequence yourself.

December 2019 113 Product Version 19.12

For diagnostics, it is usually a requirement to scan out all the channel latch states, and the
diagnostic tests can save time by using a scan mode with many parallel scan chains. If the
mode initialization uses a parent mode having one long scan chain, the observation testmode
might be different from the LBIST mode's parent testmode.

If the observation testmode requires some sequencing to set up some control latches, there
may be some careful sequencing required to avoid disturbing the MISR or channel latch
states during the testmode switch. If the mode switching sequence is more than a broadside
pattern to set some control primary inputs, then you must define the observation sequence
yourself.

Another case where you would have to define the observation sequence is where you want
to read the MISR state directly in parallel to some primary outputs. When Modus creates the
observation sequence, it assumes the MISR (and channel latches) will be observed via a
scan operation.

The signature observation sequence definition is specified as type sigobs and consists of
two basic steps:
1. Switching to the observation testmode (if different from the LBIST mode)
2. Observing the MISR (this is simply the specification of a Scan_Load or Measure_PO
event)

In switching testmodes, you must tell Modus that the switching is happening by means of
[Going_To_Mode and [In_Test_Mode objects. Here is an example of a sigobs sequence:
[ Define_Sequence some_name (sigobs);
[ Pattern;
[ Going_To_Mode: some_other_name ];
# Setting up a control latch
Event Stim_PI: "Control_PI"=1;
Event Pulse : "Clock_Pin_Name"=+;
] Pattern;
[ Pattern;
# Completing the mode switch
[ In_Test_Mode: some_other_name ];
Event Stim_PI: "Another_Control_PI"=0;
] Pattern;
[ Pattern;
# Observe the latches. This Scan_Load event denotes a scan operation
# in the some_other_name testmode.
# No values needed here, they are filled in when the sequence is used
Event Scan_Load: ;
] Pattern;
] Define_Sequence some_name;

December 2019 114 Product Version 19.12

On-Product XOR Compression Testmode

See Modus: Flows document for introductory and flow information on On-Product XOR
Compression Testmode.

The data for the XOR compression testmode is provided by Genus when you write out the
Modus data. The following is some testmode specific information to help you understand that
data provided by Genus.

Table 4-8 XOR Compression Macro Pin Connectivity for X-Masking

Pin Name Direction Connection Shareable Purpose

CML Input Chip-level With any Clock to enable
Test clock functional top- loading of mask
level port. data during channel
Functional mask load state
compliance
value=0
CME Input Chip-level With any WIDE1 Mask enable
Test data functional top- data from tester.
input level port Exists only when
WIDE1 masking is
selected.
Operational during
scan load/unload.
One bit per scan
cycle.
CME0, Input Chip-level With any WIDE2 Mask enable
CME1 Testmode functional top- data from tester.
control level port. Exists only when
WIDE2 masking is
selected. Similar
purpose as above.
CMLE Input Chip-level With any Enables loading of
Testmode functional top- mask data during
control level port. channel mask load
Functional state.
compliance
value=0

December 2019 115 Product Version 19.12

Figure 4-49 on page 116 shows an internal conceptual view of the XOR-Compression Macro.
There are 4 conceptual blocks composed of the XOR-Spreader, XOR-Compactor, Scan
Multiplexing Logic and the optional X-Masking logic.

Figure 4-49 Internal View of XOR-Compression Macro

Modes of Operation
Figure 4-50 on page 117 shows an external view of the XOR Compression Macro. The XOR
compression macro has the following modes of test operation.
1. Compression Mode with both XOR-spreader and XOR-compactor active (See Figure 4-
51 on page 117). This is set up when both SPREAD and SCOMP are active.
2. Compression Mode with scan fanout spreader and XOR-compactor (See Figure 4-52 on
page 118). This is set up when SPREAD is inactive and SCOMP is active. Another
possibility is that the XOR-Compression Macro is configured without the SPREAD pin in
which case this is the only available Compression Mode. In this case the Scan Input pin
X will feed the scan channels connected to scan channels X, X+M, X+2M, X+3M etc.,
where M is the scan fanout.
3. Full-scan mode (see Figure 4-53 on page 118) is established when SCOMP is inactive
and SPREAD is inactive or absent. In this case multiple internal scan channels are
concatenated to form full scan chains. The scan chain X for example will be affiliated with
SCANIN(X), RSI_SI(X), and scan channels X, X+M, X+2M, X+3M... and finally
DSO_SO(X) and SCANOUT(X). Each internal scan channel (i) is affiliated with the pins
SWBOX_SI(i) and SWBOX_SO(i).

December 2019 116 Product Version 19.12

Figure 4-50 XOR Compression Macro Connection to I/O Pins and Scan Channels of
Design

Figure 4-51 Compression Mode with Both Spreader and Compactor Active

December 2019 117 Product Version 19.12

Figure 4-52 Compression Mode with Scan Fanout and Compactor Active

Figure 4-53 XOR Compression in Full Scan Mode

December 2019 118 Product Version 19.12

SmartScan Compression Testmode

Related Topics
■ Converting SmartScan Serialized Tester Fail Data to CPP in Modus: Guide 7:
Diagnostics
■ SmartScan Compression in the Modus: Flows.

SmartScan Testmodes

With SmartScan compression, Genus generates two SmartScan testmodes,

compression_smartscan and compression_decomp_smartscan for test generation.
If there is no XOR spreader on the input side, then only the compression_smartscan
testmode is generated.

Two control signals are required for SmartScan operation. These can be PI controlled or can
be internally generated test signals:
■ SMARTSCAN_ENABLE
❑ Will be at Active High value in SmartScan Testmodes
❑ Inactive value will cause SmartScan flops to be included within the scan chains
■ SMARTSCAN_PARALLEL_ACCESS
❑ Active High value will select Parallel interface; inactive value selects Serial interface

Build Testmode Input for Smartscan

■ Add pipeline information using pipeline_depth option to the Assign file. The
pipeline_depth value specified in the pinassign file to build_testmode must
include External pipelines that are visible to ATPG. Here is a sample syntax:
assign pin=PSI1 test_function=SI, CMI;
assign pin=PSO1 test_function=SO;
assign pin=PCME test_function=CME, pipeline_depth=3;
…

■ There may be cases where the external pipelines are bypassed in the parallel mode
(smartscan_parallel_access=1) and only participate during the Deserializer and
Serializer shifting in the serial mode (smartscan_parallel_access=0). In such
cases, such external serial pipelines will not be visible in the testmode or to the test
generation process. To facilitate the successful conversion of the ATPG patterns, the
testmode must be supplied with information about these external serial pipelines so that

December 2019 119 Product Version 19.12

the patterns are generated to account for the additional cycles needed to load through
these serial pipelines.
For the scenario mentioned above, use the new statement
smartscanMaxSerialPipeDepth=<integer> in the Assign file to specify the
maximum pipeline depth on the serial path to the SmartScan registers. This is the
maximum depth between the input and output side.
For example, consider a design where there are four external serial pipelines on the path
from SSI to the Deserializer and six external serial pipelines on the path from Serializer
to the SSO. These pipelines are bypassed in the testmode (that is, where
smartscan_parallel_access=1) but participate in the serial mode of operation
during the shifting of the Deserializer and Serializer registers. In this case, the Assign file
must contain the statement smartscanMaxSerialPipeDepth=6.
For scenarios where the external pipelines also participate in the parallel mode (that is,
visible in the testmode), there is no need to specify this option in the Assign file. It should
be sufficient to describe these pipelines in the SmartScan Description file using the
syntax described later (SERIAL_PIPE_DEPTH, PRE_DESERIALIZER_PIPE_DEPTH,
POST_SERIALIZER_PIPE_DEPTH).

December 2019 120 Product Version 19.12

5
Low Power Gating in XOR Compressions

This chapter discusses Low Power Gating (LPG) in Modus and includes identifying Low
Power Gate Registers, running TSV checks and finally the reporting of Low Power Gating
Structures.

Figure 5-1 depicts the LPG architecture in Modus.

Figure 5-1 Low Power Gating Architecture

The register is structurally similar to Channel Mask registers and loaded in scan, once per
pattern. The contents of the register holds the selected channel heads to a constant 0 or 1.

The following Test Functions identify the LP Scan Gate Register (+1 Optional):

December 2019 121 Product Version 19.12

Table 5-1 Test Functions Pin Attributes

Test Function Value Description

LPGI 0/1 System clock. Value is the
starting and ending state of
the clock pulse. During scan
all SC pins are held to this
value so that functional clocks
and resets are off during
scan.
LPGLE 0/1 Channel Input. Used to
denote a pin that is to be
considered as the starting
point of an internal scan chain
(channel).
LPGC 0/1 Channel Output. Used to
denote a pin that is to be
considered as the ending
point of an internal scan chain
(channel).
LPGE 0/1 Enable LP Scan Gating
(maybe internally controlled
from a state machine or WIR
bit or test register)
EO_LPGR End of Low Power Gating
Register (Optional)

Following are the test sequences to load the LPG registers. Out of the five sequences, two
are master sequences which in turn call the subsequences.
■ Low_Power_Gating_Load_Sequence (lowpowergatingload) - Protocol to load
the LP Gate register
❑ Low_Power_Gating_ Preconditioning_Sequence
(lowpowergatingprecon) - sequence to enter the load state
❑ Low_Power_Gating_ Cycle_Sequence (lowpowergatingcycle) - sequence
to push the bits through the register

December 2019 122 Product Version 19.12

❑ Low_Power_Gating_ Exit_Sequence (lowpowergatingexit) - sequence to

exit from register loading state & return to the scan state
■ Low_Power_Gating_Enable_Sequence (lowpowergatingenable) - Enable the
Low Power Gating of the scan channel during the scan sequence

A channel is gated and held to 0 or 1 for an entire pattern duration which means that only
vertical strips only are allowed as shown in Figure . Horizontal striping is not allowed which
means that there is no gating on a cycle by cycle basis. One LPG bit may gate off a group of
channels for an entire pattern duration.

Figure 5-2 Vertical Striping in LPG

The LPG Register can be loaded with every pattern or may hold its value across multiple
patterns. If the LPG register is corrupted after loading in scan or in test generation then it
needs to be reloaded every pattern. When LPGE pin is at stability, the LPG register will be
bypassed resulting in a no gate state where decompressor will feed the channels (similar to
No Mask state for Channel Masking). A TC flag of same polarity is used along with LPGE
(+LPGEN,+TC) to ensure that the LPG registers are not observed during test generation.

December 2019 123 Product Version 19.12

The following TSV checks are done:

TSV Message Description

TSV-089 Checks for identifying race conditions in the LPG register
TSV-358 Identifying if there are stim registers that are not LP Gated
TSV-326 Corruption of MISR elements during LPG register load
TSV-335 An observable latch or flop is corrupted by the LPG Load sequence
TSV-354 A LPG shift register element gets corrupted preventing the gating of
controllable chain
TSV-355 Corruption of LPG register in Scan if a LPG register load is desired
across multiple patterns
TSV-356 Corruption of LPG register in TG state if a LPG register load is
desired across multiple patterns

Reporting Low Power Gating Structure

To report the Low Power Gating use the report_test_structures command with the -
reportlowpowergatingchain yes as follows:
report_test_structures –testmode <TM> -reportlowpowergatingchain yes

The report contains the LPG data for the required testmode
Low Power Gating Data for Test Mode: ELASTIC
-----------------------------------
Low Power Gating Chain: 1
-------------------------
Load Point: port:DFT_compress_sdi_0
Length: 8

Position Block Index Phase Gating Val Block Name

-------- ----------- ----- ---------- --------------
1 13911 + inst:TestIC.\sdi_ppln_inst.[0].\pp
ln_reg[0][0] Gated Control Chains: NONE
2 13944 + inst:TestIC.\sdi_ppln_inst.[0].\pp
ln_reg[1][0] Gated Control Chains: NONE
3 13977 + inst:TestIC.\sdi_ppln_inst.[0].\pp
ln_reg[2][0] Gated Control Chains: NONE
4 2891 + 1 inst:COMPACTOR.grid_codec_r0_c0.lp
g_reg Gated Control Chains: 1 2 3
5 3677 + 1 inst:COMPACTOR.grid_codec_r0_c4.lp
g_reg Gated Control Chains: 5 6 7
6 4454 + 1 inst:COMPACTOR.grid_codec_r1_c4.lp

December 2019 124 Product Version 19.12

g_reg Gated Control Chains: 12 13

7 4190 + 1 inst:COMPACTOR.grid_codec_r1_c0.lp
g_reg Gated Control Chains: 8 9
8 4859 + 1 inst:COMPACTOR.grid_codec_r2_c0.lp
g_reg Gated Control Chains: 15 16

December 2019 125 Product Version 19.12

December 2019 126 Product Version 19.12

6
Build Testmode Inputs

Testmode Definition File (Required)

Each testmode that you create is described by a mode definition file, used as input to the
Build Testmode function on the File pull-down menu or the build_testmode command
line. This is a text file that can be created from scratch by using your own text editor or by
editing a copy of one of the testmode definition files included with Modus. These testmode
definition files are in the directory named $Install_Dir/tools.<ARCH>/tb/
defaults/rules/modedef.

The mode definition file (modedef) contains statements that characterize the testmode,
including:
■ The type of tests expected to be generated (such as static, dynamic, or signature based)
■ The type of scan implemented in the testmode (such as general scan design, or
boundary scan)
■ Tester Description Rule (TDR) for the testmode (describes tester capabilities and
limitations)
■ The type of faults to be included for the testmode.

There are a few statements that must be defined in the mode definition file; they are not
accepted in an assignfile. These statements are documented in this section. All statements
documented under Assign File (Usually Required) on page 146 may be specified in the mode
definition file instead. If a statement is specified for the same model object in both the mode
definition file and the assignfile, the value in the assignfile wins.

Mode Definition Syntax

The syntax for the Assign File Statements is shown in “railroad-style” syntax diagram format.

You may have as many comments as you wish in your file. The supported comment
characters are:

December 2019 127 Product Version 19.12

line comments:
❑ //
❑ --
❑ #
block comments:
❑ /*block of comments*/ - “/*” to start and “*/” to end block comments.
Comments spanning multiple lines per the following example:
❑ /* comment line1
❑ comment line 2
❑ comment line 3 */
A comment may precede, follow, or be imbedded within a statement, or it can be on a
separate line. There cannot be more than one comment on the same line. For example,
the following line is not supported:
/*comment*/ data /*comment*/

Mode Definition Statements

The following mode definition statement syntax diagrams and keyword descriptions are listed
in this section. These statements may not be included in an assignfile, they may be specified
only in a mode definition file
■ “COMETS” on page 129
■ “DIAGNOSTIC_MODE” on page 131
■ “FAULTS” on page 132
■ “FIXED_VALUE_DEFAULT” on page 191
■ “MACRO_MODE” on page 133
■ “ON_BOARD_MISR” on page 191
■ “RAM_INITIALIZE_VALUE” on page 133
■ “SCAN” on page 133
■ “SIGNATURE_OBSERVATION_MODE” on page 138
■ “SEQUENCE_DEFINITION” on page 208

December 2019 128 Product Version 19.12

■ “TEST_FUNCTION_PIN_ATTRIBUTES” on page 139

■ “TEST_TYPES” on page 140
■ “TESTER_DESCRIPTION_RULE” on page 146

COMETS

This optional statement specifies that the testmode belongs to one or more groups, called
comets (collection of modes for estimating test coverage). Two types of comets are defined.
One type, called a STATS_ONLY comet, allows the reporting of test coverage summaries for
the cumulative effect of all the tests for the member testmodes. The other type, called a
MARKOFF comet, has all the features of a STATS_ONLY comet but also allows cross-mode
fault markoff to occur. Cross-mode fault markoff is a time-saving technique used when faults
can be tested in more than one testmode, to prevent unnecessary work to test those faults in
every testmode. When a MARKOFF comet is defined, then the testing of a fault in one of its
member testmodes causes it to appear as tested in other testmodes belonging to that comet
if the fault is marked tested in some testmode for each markoff comet that the other
testmode belongs to.

See section Report Fault Coverlage Statistics in Modus : Guide 4: Faults for a more
detailed explanation of markoff comets.

A testmode may belong to several comets, although the maximum number of comets allowed
for a design is 64. By default, a testmode is always assigned to a markoff comet that has the
same name as the TDR for the testmode, unless FAULTS=NONE is specified or defaulted.

Care must be exercised in defining markoff comets or you will not get the results you expect.
Two of the points mentioned above often cause confusion:
■ tested in another mode applies only if for every MARKOFF comet the mode belongs
to, the fault is tested in some mode that belongs to that comet. Thus, in a complicated
case where there are multiple MARKOFF comets with overlapping member testmodes,
a fault may have to be tested in two or more modes before the cross-mode markoff can
take effect for that fault in the remaining testmodes.
■ By default, there is a MARKOFF comet defined for each TDR, whose members are all
testmodes that point to that TDR. This can get in the way, and the remedy is to disable
cross-mode markoff by defining a STATS_ONLY comet with the same name as the TDR.

To use cross-mode fault markoff, do the following while laying out the methodology and before
any testmodes are actually built:
1. Make a list of the TDRs you need.

December 2019 129 Product Version 19.12

2. Make a list of the MARKOFF comets you need.

3. Make a list of the testmodes you need.
4. Create a matrix to define which MARKOFF comet(s) each testmode belongs to, and
another matrix to define which TDR each testmode points to.
5. For each TDR, determine whether it is congruent with some MARKOFF comet (they have
exactly the same list of member testmodes). If a match is found, that TDR comet can be
the MARKOFF comet. If no match is found, then that TDR comet must be defined as
STATS_ONLY.
6. Explicitly define each MARKOFF comet that is not congruent with some TDR.

Example
Suppose a testmode belongs to two MARKOFF comets, “haleys” and “santas”, and uses
the “speedy” TDR. The testmode definition should contain the following COMET
statement:
COMETS = haleys MARKOFF,
santas MARKOFF,
speedy STATS_ONLY;

December 2019 130 Product Version 19.12

In this statement:

comet_name The name of the comet. This is an arbitrary name you assign
when building the first testmode that is a member of the comet.
Every testmode that belongs to the comet will refer to it by this
same name.
■ MARKOFF
Specifies that this comet supports cross-mode fault markoff.
■ STATS_ONLY
Specifies that this comet does not support cross-mode fault
markoff, and is useful only for test coverage statistics
reporting. There is no restriction on the number of
STATS_ONLY comets a testmode may belong to. There is
also a “virtual” STATS_ONLY comet for the global design.

DIAGNOSTIC_MODE

The DIAGNOSTIC_MODE statement identifies the testmode in which diagnostic scan-out is to

occur. This statement is used only when defining an On-Product MISR testmode.

DIAGNOSTIC_MODE mode_name ;
=

In this statement:

mode_name Specify a chip fullscan chain testmode for use in diagnostics.

December 2019 131 Product Version 19.12

FAULTS

This statement specifies the types of faults to be used for test generation in this testmode.
The default is to not include any faults.

NONE

FAULTS = STATIC ;

FLTS DYNAMIC

In this statement:

NONE Specifies that no fault model is to be created for this testmode. This is the
default.
STATIC Specifies that the fault model for this testmode is to include static (for
example, stuck-at) faults.
DYNAMIC Specifies that the fault model for this testmode is to include dynamic (for
example, transition or delay) faults. Even if dynamic faults, for example, are
defined for the design by Build Fault Model, they cannot be processed in
the testmode unless FAULTS=DYNAMIC is specified here.

December 2019 132 Product Version 19.12

MACRO_MODE

This optional keyword specifies whether a macro should be processed in Verify Macro
Isolation and Create MacroTests.

MACRO_MOD value ;
=

RAM_INITIALIZE_VALUE

This optional statement specifies that all arrays will be initialized to the specified value at the
start of the mode initialization sequence. The value used to initialize the arrays during gp or
hsscan simulation will be the value at the end of the simulation of the mode initialization
sequence. If this statement is not included, the default is to start the mode initialization
sequence simulation with the state of the arrays at X.

SCAN

This required statement specifies whether the design is to be scannable in this testmode, and
what form of scan design is used.

December 2019 133 Product Version 19.12

This statement uses the following keywords:

■ TYPE - This keyword indicates that the following keyword will specify the basic type of
scan operation to be used in this testmode. It can have the following values:
❑ NONE
Specifies that the design does not use scan design in this mode.
❑ ASSUMED
Specifies that an assumed scan chain testmode is to be used.
Note: The following are disallowed if specifying assumed scan:
IN=ON_BOARD/ONB and OUT=ON_BOARD/ONB/TO_MISR on the SCAN
statement
ON_BOARD_PRPG, ON_BOARD_MISR, and SIGNATURE_OBSERVATION_MODE
mode definition statements
❑ LENGTH

December 2019 134 Product Version 19.12

Specifies the length of the scan sequence. This defaults to the length of the longest
scan chain in the testmode, and n must be larger than this or it will be changed to
the length of the longest scan chain.
❑ GSD
Specifies that in this testmode the design uses “general scan design” and should
follow the Modus General Scan Design guidelines.
❑ 1149.1
Specifies that in this testmode the design uses the IEEE standard 1149.1, which
incorporates a TAP controller and boundary scan.
❍ INSTRUCTION
Specify instructions to be loaded into the IR to select test data registers (TDRs)
for scanning through the TAP. For stored pattern test generation this instruction
configures the design so that the test generator can work effectively in the TAP
controller state designated by TAP_TG_STATE, and analyze and determine
which latches are scanned by the set of instructions selected by the specified
instructions.
The instructions to be loaded are specified using one of the following methods:
❍ binary_string - specify the binary bit string to be loaded into the IR, with the
bit closest to TDI being the left-most bit and the bit closes to TDO being the
right-most bit.
Example: INSTRUCTION=10 (The IR is two bits long.)
❍ instruction_name - specify the name of the instruction whose bit
encoding is defined in the BSDL used as input to Build Testmode.
❍ TAP_TG_STATE
This is an optional parameter used to specify the TAP controller state in which
test generation is to be performed. Do not specify this parameter if the testmode
is not for the purpose of test generation or if test generation is to be performed
with GSD scan. Acceptable values are:
❍ RUN_TEST_IDLE (RTI) - test generation is to take place with the TAP controller
in the Run-Test/Idle state.
❍ TEST_LOGIC_RESET (TLR) - test generation is to take place with the TAP
controller in the Test-Logic-Reset state.
❍ SHIFT_DR (SDR) - test generation is to take place with the TAP controller in the
Shift-DR state.

December 2019 135 Product Version 19.12

❍ PAUSE_DR (PDR) - test generation is to take place with the TAP controller in the
Pause-DR state.
❍ CAPTURE_DR (CDR) - this option is intended for use only if you have
implemented parallel capture clocking via the CAPTURE_DR state. This is not a
recommended way to implement internal scan via an 1149.1 interface, but
Modus will support it in a limited fashion.
❍ UPDATE_DR (UDR) - this option is intended for use only if you have
implemented internal scan load via the UPDATE_DR state. This is not a
recommended way to implement internal scan via an 1149.1 interface, but
Modus will support it in a limited fashion. See 1149.1 Mode Initialization
Example with User-Supplied Custom Scan Sequence in the Modus :
Reference: Test Pattern Data Reference for additional information.
❑ scan_fill=n
This keyword is used to load non-scan latches and flip-flops are expected to be
loaded from scan bits during scan.
Specify the number of scan cycles required to completely load non-scan latches or
flip-flops. The default is zero (0). If a value greater than zero is specified, a
scan_fill sequence type is automatically generated and applied after every
Scan_Load even with ATPG generated tests. Refer to the definition for sequence
type scan_fill in the “Define_Sequence” section of the Modus: Reference:
Test Pattern Data Reference.
❑ REORDER
Specify whether converted tests can be reordered without need for resimulation.
The default is no if OUT=COMPACTOR is specified; otherwise the default is yes.
■ ScanData
❑ IN
Indicates that the allowed sources of scan data are to follow.
❍ PI
Specifies that the scan chains may be sourced from primary inputs.
❍ ON_BOARD
Specifies that the scan chains may be sourced from pseudo-random pattern
generators resident on the device under test.
❑ OUT

December 2019 136 Product Version 19.12

Indicates that the allowed destinations of scan output data are to follow.
❍ PO
Specifies that the scan chains may feed primary outputs of the design.
❍ ON_BOARD
Specifies that the scan chains may feed signature registers resident on the
device under test.
❍ TO_MISR
Indicates an On-Product MISR testmode is being used. Refer to On-Product
MISR (OPMISR) Testmode for related information.
❍ COMPACTOR
Indicates that scan chain outputs feed through a linear compactor before their
scan out data appears at the scan output pins.
IN and OUT define the type of scanchains that are allowed in the testmode and no other
types of scanchains are allowed to be defined in the same testmode. For example, you
cannot define in=PI out=TO_MISR and then have a scanchain in that testmode that
goes from PI to PO; all chains in that testmode must go from PI to MISR.
■ BOUNDARY
This keyword indicates that the boundary scan attributes of the testmode are to follow.
❑ NO
Specifies that no boundary scan processing is to be done in this testmode. Any tests
generated in this mode will not assume boundary scan.
❑ INTERNAL
This keyword indicates that the design uses boundary scan, and only internal test
data is to be generated in this testmode.
❍ For mixed analog/digital designs, specify this keyword in conjunction with
assign pin=<accessible non-test control digital pin> and
test_function=bdy (refer to Test Function pin Attributes on page 133 and
“RPCT Boundary Controls” on page 178 for more information) to identify the
digital pins that are accessible beyond test control signals.
❍ For a core that is to be used in hierarchical test, specify this keyword for the
INTEST testmode; the mode for which tests are going to be migrated.
❑ EXTERNAL

December 2019 137 Product Version 19.12

This keyword indicates that the design uses boundary scan, and only external test
data is to be generated in this testmode.
❑ MODEL
This keyword is required if this mode is to be used in building a boundary model for
this structure or for building an EXTEST testmode for a core that is going to be used
for hierarchical test. It is used together with EXTERNAL
(boundary=external,model).
❑ MIGRATE
This keyword indicates that the design uses boundary scan, and the tests for this
INTEST testmode are to be migrated for hierarchical test.
❑ BYPASS
This keyword indicates that the design uses boundary scan, and this testmode puts
the core in BYPASS state for hierarchical test.

■ EMBEDDED_PIPELINES
This keyword provides a method to identify compression testmodes in which pipelines
are embedded in the compression and decompression logic. The default value is no.

SIGNATURE_OBSERVATION_MODE

This statement is used in the automatic creation of a signature observation sequence. It tells
Modus the name of the testmode to use for scanning out the results of the MISR. If you are
supplying the signature observation sequence definition, then this mode definition statement
is not needed. You must supply the signature observation sequence definition if it does not
use a scan operation or if switching to the observation testmode requires any sequencing.
Modus can automatically create the signature observation sequence only if switching to the
scan mode is the trivial operation of switching (in any arbitrary order) a set of control pins
labeled as Clock, TI, and TC in the observation mode.

For OPMISR or OPMISRplus testmodes, this statement indicates that MISR observation
should be done serially by scanning out the MISR using the scan chains defined by the
specified testmode.

December 2019 138 Product Version 19.12

Refer to “Signature Observation Sequences for LBIST” on page 113.

SIGNATURE_OBSERVATION_MODE testmodenam ;
=

In this statement:

testmodename Specify the name of the observation testmode to be used for

scanning out the BIST results. The BIST results consist of the MISR
contents and, for diagnostics, the channel latch states.

TEST_FUNCTION_PIN_ATTRIBUTES

This optional statement specifies the names of any model attributes that carry the test
functions of the pins in this testmode. The default is to not get test function information from
the model data, but from the mode definition only.

TEST_FUNCTION_PIN_ATTRIBUTES = model_attribute_na ;

TFPA

In this statement:
model_attribute_name - The name of a pin attribute (keyword or property) used in
the model source that carries test function information.

If conflicting test functions are found, the one specified by the earlier appearing
model_attribute_name in the list is used. For example, if you specify
TFPA = TF_A, TF_B, TF_C

and some primary input has attributes

December 2019 139 Product Version 19.12

TF_D = +TI, TF_C = BDY, TF_B = +SE, TF_A = SI

then the test function attributes SI and BDY are kept for this PI in this testmode. The +TI is
ignored completely because TF_D was not included on the TFPA statement. +SE and SI
conflict, but TF_A appears first in the TFPA statement, so SI is used. BDY does not conflict,
so it is used also, even though TF_C was the last appearing name on the TFPA statement.

Refer to Test Function pin Attributes on page 133 for descriptions of test function pins.

TEST_TYPES

This required statement specifies the kinds of tests that are to be generated and applied in
this testmode.
Note: The time keyword is specified with a positive decimal number followed by one of
these parameters:
❑ ns
❑ ps
❑ us
❑ ms
❑ s

December 2019 140 Product Version 19.12

TEST_TYPES =
TESTS

NONE ;
TD_MIGRATION
,

STATIC LOGIC SIGNATURES

DYNAMIC
TIMED TEST Scan Shift Register
SR

Macro
IOWrap

ECID

OPCBIST LOGIC SIGNATURES ONLY

SIG =

IDDQ Propagate CELL_BOUNDARY

= PRIMITIVE_BOUNDARY

DRIVER_RECEIVER
D_R
DR

SIGNATURES:
SIGNATURES NO
SIG = YES
TYPE

ONLY

CHECK

December 2019 141 Product Version 19.12

TIMED TEST:
1.00 0.00 0.00
TIMED EARLY ( best , nominal , worst )

1.00 0.00 1.00

( best , nominal , worst )

0
MAX_PATH_LENGTH time MIN_PATH_LENGTH time

■ NONE
Specifies that no test data is to be generated in this mode.
■ TD_MIGRATION
Specifies that this testmode exists solely for the purpose of migrating pre-existing tests
from the boundary of an embedded macro to the package boundary.
■ LOGIC
Specifies that this testmode may be used to generate logic test data (for example, stuck
faults or transition faults).
■ STATIC
When used with the LOGIC or I/O wrap keywords, specifies that this testmode may
be used to generate tests that are largely delay-independent (for example, stuck-fault
testing). When used with the MACRO keyword, specifies that the design contains macros
that are delay-independent (design “settles” between patterns).
❑ MACRO
Specifies that the design may contain embedded macros for which in-place tests are
to be generated. This is commonly done for embedded RAM or ROM.
❑ I/O wrap
Specifies that static stuck driver tests are to be created for bi-directional chip I/Os.
■ DYNAMIC

December 2019 142 Product Version 19.12

When used with the LOGIC or I/O wrap keywords, specifies that this testmode may
be used to generate tests to be applied in a carefully timed sequence (for example, delay
testing). When used with the MACRO keyword, specifies that the test portion of the macro
contains events that occur in a carefully timed sequence.
❑ TIMED_TEST
Dynamic Timed Tests are dynamic tests that have associated timings. The
TIMED_TEST keyword controls whether timed tests can be imported or
automatically generated. This keyword also controls whether the test sequences
developed by the test generators will be timed. If the timings are already present for
the sequence, whether they were automatically or manually derived, new timings
are not created.
❍ EARLY
This path specifies to check for paths that are too fast.
❍ LATE
This path specifies to check for paths that are too slow.
❍ best
Specifies the delay through a chip or net under the best or fastest conditions.
Typically this delay is desired for early mode analysis.
❍ nominal
This delay is usually an average between the worst and best case delays and
thus, will give an average delay through the logic design.
❍ worst
The delay across a chip or net under the worst or slowest conditions. This is
typically the delay preferred for late mode analysis.
❑ TIMED TEST OPTIONS MAX_PATH_LENGTH
Specifies the maximum path length for which path timings are to be generated.
Paths on the product that are larger than the specified maximum are identified as
unobservable to the test generator and fault simulator. The paths that are
considered are latch to latch, PI to PO, PI to latch, and latch to PO.
❑ TIMED TEST OPTIONS MIN_PATH_LENGTH
Specifies the minimum path length for which path timings are to be generated. Paths
on the product that are smaller than the specified minimum will not have timings
generated for them.

December 2019 143 Product Version 19.12

■ SIGNATURES
Indicates that the allowed usage of signature analysis for tests generated in this mode is
to follow.
❑ NO
Specifies that signature analysis is not permitted in this testmode.
❑ YES
Specifies that signature analysis is permitted in this testmode.
❍ TYPE - specify one of the following:
TEST_RESET to provide independent signatures for each test. This is the
default for OPMISR and OPMISRplus testmodes.
RUNNING to indicate that the signature will be accumulated across all tests with
no resets between tests and that the current MISR state (signature) should be
provided at the end of each test.
FINAL to indicate that a final signature accumulated across all tests within a
Tester_Loop should be computed and be devoid of resets between tests.
If the testmode is not OPMISR or OPMISRplus, the default is RUNNING.
Note: OPMISR Signature types of RUNNING and FINAL mean that multiple ATPG
patterns will be accumulated into one final MISR Signature. Thus, during application
of the ATPG patterns, the MISR cannot be reset and there can be no destructive
Read of any intermediate signatures.
Note: For OPMISR testmodes, if a run time “checkpoint” is specified, this will trigger
the creation of a ‘Product_MISR_Signature (final)’ MISR signature at each
checkpoint interval for TYPE = RUNNING or FINAL. If no “checkpoint” is triggered
there will only be one ‘final’ MISR signature after applying all of the ATPG patterns.
❑ ONLY
Specifies that signature analysis is the only output observation method permitted in
this testmode (individual primary output or scan elements cannot be measured).
❑ CHECK
This is a “checking only” option that invokes Logic Test Structure Verification X-
state checking in this mode (check to insure that X-sources cannot be observed).
WRP test generation is not permitted in this mode if this option is specified.
■ OPCBIST

December 2019 144 Product Version 19.12

This keyword is specified for a testmode in which tests will be applied under the control
of an on-product finite-state machine such as a BIST controller, where the only required
external stimuli after initialization is a string of clock or oscillator pulses. OPCBIST can
be specified in combination with STATIC, DYNAMIC, DRIVER_RECEIVER, and IDDQ. It
must be accompanied by the modifier keywords LOGIC and SIGNATURES only.
■ SHIFT_REGISTER
Specifies that tests are to be generated that focus on verifying the integrity of the scan
operations for a GSD, or 1149.1 design. This test type is not valid if SCAN TYPE=NONE.
❑ Scan
Include only scan chain test portion of scan chain test.
■ IDDq PROPAGATE
Specifies the valid “observation points” for tests generated to be used for making power
supply current measurements (IDDq).
❑ CELL_BOUNDARY
Specifies that for IDDq tests, the fault effect must be propagated to the output of a
cell to be considered detected by an IDDq test. For purposes of generating IDDq
tests, the lowest level entities (above the primitive blocks) in the model hierarchy are
treated as cells. Use this option if your typical cell is designed such that the detection
of a defect by current measurement depends upon the state of cell inputs other than
those connected to the primitive block on which the defect is modeled. This is
commonly true for complex CMOS designs.
❑ PRIMITIVE_BOUNDARY
Specifies that for IDDq tests, the fault effect must be propagated to the output of the
primitive block to be considered detected by an IDDq test. Use this option if the
detection of defects by current measurement depends only upon the state of the
inputs of the primitive with which the defect is associated. You should specify this
option also if you imported a non-hierarchical model, because in that case Modus
would treat the entire design as a cell.
If IDDq PROPAGATE is not specified, it will default to primitive.
■ DRIVER_RECEIVER
Specifies that this testmode may be used to generate tests targeted specifically at faults
on drivers and receivers connected to the primary I/O pins of the design.

December 2019 145 Product Version 19.12

TESTER_DESCRIPTION_RULE

This required statement specifies the name of the tester description rule (TDR) to be used in
processing this testmode. Refer to “Tester Description Rules (TDRs)” on page 213.

TESTER_DESCRIPTION_RULE = tdrname ;

TDR

In the syntax:
tdrname - The file name of the TDR. The TDR specifies the characteristics of the tester
to which this testmode's data is targeted.

Additional related information is available in “Resolving Internal and External Logic Values
due to Termination” in the Modus: Guide 5: ATPG.

Assign File (Usually Required)

The assign file contains statements that characterize the test structures in the design for the
testmode, including:
■ Test function pin assignments for the Primary Inputs and Primary Outputs and Flops/
Latches
■ OPCG test structures expected in the testmode (such as PLL registers, clock domains,
cutpoints, or PPIs)

Although these statements may be included in a mode definition file, they are generally
included in an assign file. This allows you to use a single mode definition file for multiple
designs while including design specific characteristics in the assign file. If the same statement
is specified for the same model object in both the mode definition and the assign files, the
value in the assign file overrides the value in the mode definition.

Assign File Statements

The following assignfile statement syntax diagrams and keyword descriptions are listed in this
section:
■ “ASSIGN” on page 147

December 2019 146 Product Version 19.12

■ “HISNT” on page 185

■ “COREINSTANCE” on page 186
■ “COREMAXPIPEDEPTH” on page 187
■ “CORRELATE/UNCORRELATE” on page 187
■ “CUTPOINTS” on page 189
■ “DELETE” on page 190
■ “FIXED_VALUE_DEFAULT” on page 191
■ “IMPLICIT CHOPPERS” on page 191
■ “ON_BOARD_MISR” on page 191
■ “ON_BOARD_PRPG” on page 192
■ “OPCG” on page 193
■ “POWER_MODE” on page 207
■ “SEQUENCE_DEFINITION” on page 208
■ SMARTSCANMAXSERIALPIPEDEPTH on page 208
■ “TEST_REORDER” on page 209

ASSIGN

The ASSIGN statement is the most used statement in the assignfile. It is used to assign test
functions to specific Primary Inputs, Primary Outputs, Pseudo-PIs (PPIs) and flops/latches.
The basic syntax of the assign statement is:
assign pin ”<pinname>” test_function=tf[, tf?] ;

where:
■ pinname is the name of the pin being assigned a test function
■ tf is the test function of the pin. Refer to “Test Function Pin Attributes” on page 148 for
more information.
■ In many cases, the quotes around the pin name are not required, but it is recommended
to always quote the pin names.
■ One assign statement is needed for each PI or PO that has a test function.

December 2019 147 Product Version 19.12

■ A pin may have multiple test functions, but there are restrictions on how the test functions
may be combined. For more information on combining test functions, see “Valid
Combinations of Test Functions” on page 182.

Table 6-1 lists the most commonly used test function pin attributes.

The complete list of test functions and syntax is found in “Complete Information for Assign
Statement” on page 151

The valid values are:

■ 0 or - : means the value is logic 0
■ 1 or + : means the value is logic 1
■ Z : means the value is high impedance
■ X : means the value is unknown

Table 6-1 Test Function Pin Attributes

Test Function Value Description

SC 0/-, 1/+ System clock. Value is the
starting and ending state of
the clock pulse. During scan
all SC pins are held to this
value so that functional clocks
and resets are off during
scan.

December 2019 148 Product Version 19.12

Test Function Value Description

EC 0/-, 1/+ Edge Triggered Scan Clock.
Value is the starting and
ending state of the clock
pulse. Just prior to scan the
clocks to all flops/latches
should be known (either 0 or
1) based on the setting of this
test function and the scan
enable.
Clocks to latches should be at
0. If you think of a flop as a
master-slave pair, it is
recommended that the value
of the clock at the master be
0.
ES 0/-, 1/+ System Clock and Scan
Clock. Value is the starting
and ending state of the clock
pulse. The scan enable will
select the scan function of this
clock.
SI Scan Input

SO Scan Output

SE 0/-, 1/+, or Z Scan Enable.Value is held

constant during scanning.
The value should enable the
scan paths and the scan
function of any ES clocks.
Note that these pins may be
set to any value when testing.
TI 0/-, 1/+, X or Z Test Inhibit. Value held
constant during scanning and
testing. These pins are always
tied to the specified value in
this testmode.

December 2019 149 Product Version 19.12

Test Function Value Description

TC 0/-, 1/+, X or Z Test Constraint. Value held
constant only during testing.
During scan these pins are
not set to any value.
CHI Channel Input. Used to
denote a pin that is to be
considered as the starting
point of an internal scan chain
(channel).
CHO Channel Output. Used to
denote a pin that is to be
considered as the ending
point of an internal scan chain
(channel).

Example:
assign pin "scanin1" test_function=SI; // scanin for chain 1
assign pin "scanout1" test_function=SO; // scanout for chain 1
assign pin "scanin2" test_function=SI; // scanin for chain 2
assign pin "scanout2" test_function=SO; // scanout for chain 2
assign pin "clock" test_function=0ES; // scan and system clock
assign pin "reset" test_function=-SC; // asynchronous reset (clock)
assign pin "test_en" test_function=1TI; // test enable (constant)
assign pin "scan_en" test_function=+SE; // scan enable (constant during scan)
assign pin "test1" test_function =-TC // test constraint (constant during test)
assign pin=COMPACTOR.co[0] test_function= CHI;
assign pin=COMPACTOR.ci[0] test_function= CHO;

Figure 6-1 illustrates the behavior of various test function pins. Note that the waveforms for
the same test functions with the opposite values (e.g., +ES, -SC, -TI, -SE, +TC) would be the
mirror image (inverse) of those shown here.

December 2019 150 Product Version 19.12

Figure 6-1 Waveforms for Test Function Pins

Refer to “Assignfile Examples” on page 24 for more information on commonly-used assign

file configurations.

Complete Information for Assign Statement

The specified test function is placed on a primary I/O pin, a pseudo primary input (PPI), a
latch, or in rare instances, an internal node in Modus 's internal model. If a test function was
specified on this pin or block by a model attribute, that designation is replaced by the
information from this mode definition statement.

Three test functions, TI, FLH, and FSM, are recognized for latches.

When specifying a test function for a latch, the designated pin or net must be one of the
following:
■ Output pin of the latch primitive;
■ Net connected to the output pin of the latch primitive, but only if there are no other latches
directly connected to this net;
■ Output pin of a usage block which contains the latch, but only if exactly one latch within
this usage block can be reached by a backtrace from this pin;
■ Any net that is driven directly or indirectly by the latch, but only if the latch is contained
(possibly at a lower hierarchical level) within the same entity in which the net is visible
(i.e., the lowest level hierarchical entity that contains the net), and there is no other latch
that can be associated in this manner with the designated net.

December 2019 151 Product Version 19.12

■ Results of multiple ASSIGN statements are not cumulative for a given PIN. If two
ASSIGN statements are used for one PIN, the last statement seen will assign the pin flag
values.

Refer to “ASSIGN Statement Syntax Techniques” on page 161 for details on specifying
ASSIGN parameters and to view example syntax.

December 2019 152 Product Version 19.12

Note: Test function pins for an 1149.1 testmode are defined in the Boundary Scan
Description Language (BSDL). Refer to “Test Function Pins for an 1149.1 Mode” on page 180
for more information.

December 2019 153 Product Version 19.12

December 2019 154 Product Version 19.12

December 2019 155 Product Version 19.12

December 2019 156 Product Version 19.12

In this statement:
■ PIN - Indicates that the specified test function, that is, the data following the
TEST_FUNCTION keyword, is to be put on a specific pin identified by pinName.
❑ pinName
Identifies the pin whose test function is being specified.
Note: You must enclose pin names using a double quotes escaped identifier if the first
character is something other than:
A-Z or a-z
0-9

December 2019 157 Product Version 19.12

Or subsequent characters are something other than:

A-Z or a-z
0-9
_
( )
#
+
-
&
/
:
.
{ }
|
[ ]
@

For example:
abc
abc_
abc(0)
"&abc"
"01"
01(a)
"net a"

are all legal pin names.

&abc
abc?
a%5
abc ef

are not legal unless enclosed in double quotes.

Pin names themselves can never contain a double quote (") or a newline (ln) character.
■ NET - Indicates that the specified test function, that is, the data following the
TEST_FUNCTION keyword, is to be put on a specific net identified by netName.
❑ netname
Identifies the net whose test function is being specified.
Note: You must enclose netNames using a double quotes escaped identifier if the first
character is something other than:
A-Z or a-z
0-9

Or subsequent characters are something other than:

A-Z or a-z
0-9
_
( )
#

December 2019 158 Product Version 19.12

+
-
&
/
:
.
{ }
|
[ ]
@

For example:
abc
abc_
abc(0)
"&abc"
"01"
01(a)
"net a"

are all legal net names.

&abc
abc?
a%5
abc ef

are not legal unless enclosed in double quotes.

Netnames themselves can never contain a double quote (") or a newline (ln) character.
■ PPI - Indicates that the specified test function, that is, the data following the
TEST_FUNCTION keyword, is to be put on a specified ppi identified by ppiName.
PPI’s are identified with the CUTPOINTS statement.
■ BLOCK - Indicates that the specified test function, that is, the data following the
TEST_FUNCTION keyword, is to be put on a specified block identified by blockName.
■ PIPELINE_DEPTH - A pipeline depth value may be specified only on CME test function
pins, refer to CHANNEL_MASK_ENABLE
■ TEST_FUNCTION - Indicates that the test function will follow. The use of this keyword
is only for readability.
Note:
❑ You may use 1 and 0 in place of + and -, respectively, for any flag that has a sign
preceding it.
❑ A 1 or a 0 can have either a blank or non-blank following it, for example, 1 EC1 or
1AC (+AC is also valid). This is also true for the Z (high impedance) logic value as a
test function pin assignment, for instance, either Z SE or ZSE.

December 2019 159 Product Version 19.12

❑ The values are not case-sensitive.

The test function is one or more of the following, and the allowed combinations are
illustrated in the ASSIGN syntax diagram.
❑ NIL - Specifies that any existing test function should be removed from the pin.
❑ NO_INTERCONNECT (NIC) on page 178 for detail.
❑ BIDI_INHIBIT (BI) on page 173 for detail.
❑ BOUNDARY_DATA_PIN (BDY) on page 178 for detail.
❑ CONTROL_PIN (CTL) on page 178 for detail.
❑ P_SHIFT_CLOCK (EC3) on page 167 for detail.
❑ E_SHIFT_CLOCK (EC) on page 168 for detail.
❑ seq_order_number - see Scan Clock Sequence Number on page 168 for detail.
❑ SYSTEM_CLOCK (SC) on page 167for detail.
❑ P_SHIFT_SYSTEM_CLOCK (PS) on page 167 for detail.
❑ E_SHIFT_SYSTEM_CLOCK (ES) on page 168 for detail.
❑ CLOCK_ISOLATION (CI) on page 169 for detail.
❑ OUTPUT_INHIBIT (OI) on page 174 for detail.
❑ WEIGHT_SELECT (WS) on page 174 for detail.
❑ MISR_RESET_ENABLE (MRE) on page 175 for detail.
❑ OSCILLATOR (OSC) on page 169 for detail.
❑ SCAN_ENABLE (SE) on page 170 for detail.
❑ TEST_INHIBIT (TI) on page 171 for detail.
❑ TEST_CONSTRAINT (TC) on page 172 for detail.
❑ TEST_CLOCK (TCK) on page 179 for detail.
❑ TEST_MODE_SELECT (TMS) on page 179 for detail.
❑ TEST_RESET (TRST) on page 179 for detail.
❑ FINITE_STATE_MACHINE (FSM) on page 173 for detail.
❑ LINEHOLD (LH) on page 172 for detail.

December 2019 160 Product Version 19.12

❑ FIXED_VALUE_LATCH_LINE_HOLD (FLH) on page 173 for detail.

❑ SCAN_IN (SI) on page 164 for detail.
❑ TEST_DATA_INPUT (TDI) on page 179 for detail.
❑ Scan Chain Order Number - see Scan Chain Sequence Order on page 165 for
detail.
❑ SCAN_OUT (SO) on page 164 for detail.
❑ TEST_DATA_OUTPUT (TDO) on page 179 for detail.
❑ CHANNEL_INPUT (CHI) on page 164 for detail.
❑ CHANNEL_OUTPUT (CHO) on page 164 for detail.
❑ MISR_OBSERVE (MO) on page 174 for detail.
❑ MISR_RESET (MRST) on page 175 for detail.
❑ MISR_READ (MRD) on page 175 for detail.
❑ Channel_Mask_Input (CMI) on page 175 for detail.
❑ Channel_Mask_Enable (CME) on page 176 for detail.
❑ Channel_Mask_Load_Enable (CMLE) on page 176 for detail.
❑ Channel_Mask_Load (CML) on page 176 for detail.
❑ GO on page 177 for detail.
❑ OPCG_Load_Input (OLI) on page 177 for detail.

ASSIGN Statement Syntax Techniques

This section lists techniques, available syntax options, and examples for the ASSIGN
statement.

ASSIGN object_type = objectname assignmentInfo ;

Note: A semi-colon (;) is required for all statements.

object_type is REQUIRED and must be one of the following:

■ PIN - Must be fully spelled (mixed case is allowed)
■ NET - Must be fully spelled (mixed case is allowed)

December 2019 161 Product Version 19.12

■ BLOCK - Must be fully spelled (mixed case is allowed)

■ PPI - Must be fully spelled (mixed case is allowed)

Equals (=) is OPTIONAL. If specified, the “=” character must be used.

objectname is REQUIRED and must be one of the following:

■ A quoted name - Special characters are allowed.
■ An unquoted name - Special characters are disallowed.
Note:
❑ The objectname should be a pin name if the object_type is PIN.
❑ The objectname should be a net name if the object_type is NET.
❑ The objectname should be a block name if the object_type is BLOCK.
❑ The objectname should be a ppi name if the object_type is PPI.

assignmentInfo can be ONE OR MORE assignment groups whereas assignment group

can be one of the following:
■ Test Functions assignment
■ Clock Domain
■ Pipeline Depth
■ Pipeline Clock designation

For assignment of Test Functions:

TEST_FUNCTION = test function list

Specify Test Function using of the following forms:

❑ TEST_FUNCTION (mixed case is allowed)
❑ TEST FUNCTION (mixed case is allowed)
❑ FUNCTION (mixed case is allowed)
❑ TFUNC (mixed case is allowed)
❑ (blank)
❑ If specified (non-blank)

December 2019 162 Product Version 19.12

❑ Mixed case, i.e. Tfunc,TfUnC, etc.)

Equals (=) is OPTIONAL but cannot be specified if the test function is blank. If specified, use
the "=" character.

test function list consists of one or more test functions applicable for the object type. Each
test function may be separated by a space or comma. A test function MAY REQUIRE a
polarity (sign/stability) value, i.e. +SG; or it may not require a polarity, i.e. SO.

For a Clock Domain:

CLK_DOMAIN = clock domain data

The Clock Domain specification must start with one of the following:
■ CLK_DOMAIN (mixed case is allowed)
■ CLK DOMAIN (mixed case is allowed)
■ CLKDOMAIN (mixed case is allowed)
■ DOMAIN (mixed case is allowed)

Equals (=) is OPTIONAL. If specified, use the "=" character

clock domain data is one OR more comma-separated values. A value may be a string,
a quoted string, or a number. The comma is required if more than one value is specified.

For Pipeline Depth:

PIPELINE_DEPTH = pipeline depth data

Pipeline Depth must start with one of the following:

■ PIPELINEDEPTH (mixed case is allowed)
■ PIPELINE_DEPTH (mixed case is allowed)
■ PIPELINE DEPTH (mixed case is allowed)

Equals (=) is OPTIONAL. If specified. use the "=" character.

pipeline depth data can be a string, a quoted string, or a number.

Test Function Attribute Definition

The following sections summarize test functions and their usages.

December 2019 163 Product Version 19.12

Scan Inputs and Outputs

SCAN_IN (SI) Used on all scan data primary inputs in the design. There is
one SI primary input for each register that can be scanned
into (controllable register) on the design. This attribute has no
associated value.
Note: Placing the SI attribute on a PPI is not supported.
SCAN_OUT (SO) Used on all scan data primary outputs in the design. There is
one SO primary output for each register that can be scanned
out of (observable scan chain) on the design. This attribute
has no associated value.
CHANNEL_INPUT (CHI) Used to denote a block or a pin that is to be considered as the
starting point of an internal scan chain (channel). When
specified on a block, this attribute is propagated to all output
and bidirectional pins of the block. Note that the CHI attribute
is disallowed on a PRPG latch.
CHANNEL_OUTPUT (CHO) Used to denote a block or a pin that is to be considered as the
ending point of an internal scan chain (channel). When
specified on a block, this attribute is propagated to all output
and bidirectional pins of the block.

PRPG Definition in Pinassign Flile

patt_gen=“<PRPG Register name>" {
Register=(
“<PRPG bit 1>",
“<PRPG bit 2>",
……
“<PRPG bit n>“);
Register_Cell_Equation=(
“<PRPG bit 1>"=“<PRPG bit p>”+“<PRPG bit n>",
“<PRPG bit 2>"=“<PRPG bit 1>",
……
“<PRPG bit p>"=“<PRPG bit p-1>“,
…...
“<PRPG bit n>"=“<PRPG bit n-1>“);
};

December 2019 164 Product Version 19.12

(MISR) Definition in Pinassign File

sig_reg=“<MISR Register name>" {
Register=(
“<MISR bit 1>",
“<MISR bit 2>",
……
“<MISR bit n>“);
Register_Cell_Equation=(
“<MISR bit 1>"=“<MISR bit n>",
“<MISR bit 2>"=“<MISR bit 1>",
……
“<MISR bit p>"=“<MISR bit p-1>“+“<MISR bit n>",
…...
“<MISR bit n>"=“<MISR bit n-1>“);
};

Scan Chain Sequence Order

The order of the scan chains in the design can be determined by assigning sequence
numbers to the SCAN_IN test function. Controllable registers are numbered based on
scan_in. Observable scan chains are numbered based on scan_out. BIST channels are
numbered based on the MISR bit positions they feed. If a sequence number is not specified
with a SCAN_IN, Modus assumes a sequence order of zero. If a number is specified on
multiple scan ins, these scan chains are numbered according to an alphanumeric sort of the
respective pin names. Using scan chain sequencing offers the following benefits:
■ You can ensure the order of the scan chains in Modus matches the order they are
referenced in the design.
■ For stored pattern tests, if manual patterns are written in vector format and a subsequent
name change is made in the design, the manual patterns match the new scan chain
order without the task of reordering.

The following examples show some sample SCAN_IN test function assignments and indicate
the result of processing. The syntax shown here is the syntax of assignment statements
which may be coded in the mode definition file or test function pin assignment file.
■ Example 1:
assign pin1 test_function=SI1;
assign pin2 test_function=SI3;
assign pin3 test_function=SI4;
assign pin4 test_function=SI2;

December 2019 165 Product Version 19.12

The result is the scan chain fed by pin1 is #1; the one fed by pin4 is #2; the one fed by
pin2 is #3; and the one fed by pin3 is #4.
■ Example 2:
assign pin=pin1 test_function=SI;
assign pin=pin2 test_function=SI;
assign pin=pin3 test_function=SI;
assign pin=pin4 test_function=SI;

All the scan inputs have the same number, SI0, therefore, the sequencing is
alphanumeric by pin name.
■ Example 3:
assign pin=pin1 test_function=SI1;
assign pin=pin2 test_function=SI3;
assign pin=pin3 test_function=SI;
assign pin=pin4 test_function=SI2;
assign pin=pin5 test_function=SI2;

If a sequence number is not specified with a SCAN_IN, Modus assumes a sequence

order of zero.
In this example, the scan chain fed by pin3 becomes the first scan chain. The chain fed
by pin1 is #2; the one fed by pin4 is #3; the one fed by pin5 is #4; and the one fed by pin2
is #5.

Ordered CHIs and CHOs

For modes that require CHIs and CHOs to be specified it is possible to assign an ordering to
the pins. This allows you to direct the tool to an ordering for the Control and Observe chains
in these modes. Note that if ordering is used, it does not guarantee that the Control Chain fed
by CHIn corresponds to the Observe Chain feeding CHOn, for example, this means that
CHI45 and CHO45 do not necessarily form a Scan Chain, unless the DFT insertion was done
in such manner. Additionally, due to Control Chain correlation, if ordered CHIs are used, but
two Control Chains are determined by the tool to be correlated, the tool will use the ordering
specified by the lower ordering number. It is not a requirement that if some ordering is given
that all ordering be given, if there is a combination of ordered and unordered CHIs/CHOs, the
tool will order based off the given ordering, and then order the unordered chains based off
existing methods. Lastly, this support is recommended for use on an as-needed basis and is
not for general use.

Example:
Assign pin= COMPACTOR.SWBOX_SO[6] test_function= CHI1;
Assign pin= COMPACTOR.SWBOX_SO[1] test_function= CHI2;
Assign pin= COMPACTOR.SWBOX_SO[4] test_function= CHI3;
Assign pin= COMPACTOR.SWBOX_SO[3] test_function= CHI5;

December 2019 166 Product Version 19.12

In this case Control Chain 1 would be fed by COMPACTOR.SWBOX_SO[6], Control Chain 2

would be fed by COMPACTOR.SWBOX_SO[1], Control Chain 3 would be fed by
COMPACTOR.SWBOX_SO[4], and Control Chain 4 would be fed by
COMPACTOR.SWBOX_SO[3].
Assign pin= COMPACTOR.SWBOX_SI[6] test_function= CHO1;
Assign pin= COMPACTOR.SWBOX_SI[1] test_function= CHO2;
Assign pin= COMPACTOR.SWBOX_SI[4] test_function= CHO3;
Assign pin= COMPACTOR.SWBOX_SI[3] test_function= CHO5;

In this case Observe Chain 1 would feed COMPACTOR.SWBOX_SI[6], Observe Chain 2

would feed COMPACTOR.SWBOX_SI[1], Observe Chain 3 would feed
COMPACTOR.SWBOX_SI[4], and Observe Chain 4 would feed
COMPACTOR.SWBOX_SI[3].

System and Scan Clocks

Clock Functions

SYSTEM_CLOCK (SC) Used on all primary inputs that are intended to be used
as clocks for the system data function of latches, direct
set or reset of latches, or for controlling the write
operation of memory arrays. These primary inputs are
not used for the scan operation. The test function value
(+, 1, -, or 0) sets the clock off at the latches it feeds.
P_SHIFT_CLOCK (EC3) Used on all primary inputs intended to be used to load
data into memory elements following the scan
operation. The test function value (+, 1, -, or 0) sets the
clock off at the latches it feeds. There can be more than
one P_SHIFT_CLOCK.
P_SHIFT_SYSTEM_CLOCK (PS) Used on all primary inputs intended to be used as both
a system clock and a P_SHIFT_CLOCK.The test
function value (+, 1, -, or 0) sets the clocks off at the
latches they feed.

December 2019 167 Product Version 19.12

E_SHIFT_CLOCK (EC) Used on all primary inputs intended to be used to scan

data into edge-sensitive flip-flops during the scan
operation. There can be more than one
E_SHIFT_CLOCK. There is typically no value that
would turn the EC clock “off” at all the flip-flops it feeds,
so here are some hints for setting the value (+, 1, -, or
0):
■ The value on the clock input should flush the slave
(of the master-slave latch pair). This means the
master is off. This is especially important when the
master is a multi-port latch or when there is clock
gating.
■ If there is clock gating, the clock input to the gating
logic should be at the controlling value (for
example, at zero for an AND).
E_SHIFT_SYSTEM_CLOCK (ES) Used on all primary inputs intended to be used as both
a system clock and a scan_E_clock. (for example, in
a multiplexed edge-triggered scan design). The value
(+, 1, -, or 0) is set using the hints shown for the
E_SHIFT_CLOCK.

Scan Clock Sequence Number

To allow some control over the order in which scan clocks of a given type are pulsed during
the scan operation, Modus allows a sequence number to be specified with the scan clock test
functions. Two clock primary inputs that have identical scan clock test functions and sequence
numbers are pulsed simultaneously. Thus in Modus , the scan sequence (the sequence of
clock pulses, and possibly primary input stimulus, necessary to shift data one bit position from
scan-in to scan-out of a scan chain) is defined as follows:
■ Apply scan state
■ Pulse all E_SHIFT_CLOCKs in user-defined order (ECn/ESn)

Where n is the sequential order number. For example, if your test function specifications for
different pins are:
EC, EC5, ES15

Then the scan clock sequence is:

Event #
-------
5 Pulse EC

December 2019 168 Product Version 19.12

1 Pulse EC5
2 Pulse ES15

Notes:
1. There is no checking for race-free operation when multiple clocks are pulsed
simultaneously, as in event 9. If you cannot guarantee that such an operation is race-free,
you should assign a unique number to each clock so that only a single clock is pulsed at
a time.
2. There must be no blank between the flag and the number.
3. A blank following the flag is equivalent to a zero.

Oscillators

OSCILLATOR (OSC) Used on a primary input that is to be connected to a tester-supplied

oscillator signal, where the tester applies some constant number of
pulses on the pin in each tester cycle. This attribute identifies the
pin as a synchronous (tester-supplied) oscillator and specifies a
stability state (i.e. an OFF value). This attribute can be specified
only with either a + or - sign preceding it. This attribute is also
allowed on PPIs.
oTI This is a special case of the TEST_INHIBIT attribute, where the pin
is permanently connected to a free-running (asynchronous)
oscillator. In this case, the “value” the pin is tied to is coded as “o”.

Clock Gates
Note: These test function attributes are supported on pseudo primary inputs as well as
primary inputs.

CLOCK_ISOLATION (CI) Used on a primary input that controls the gating of combined
system and scan clocks (PS, ES) on the design. The test
function value (+, 1, -, or 0) causes the combined clocks to act
as scan clocks. The opposite of the specified value causes the
combined clocks to act as system clocks.

December 2019 169 Product Version 19.12

SCAN_ENABLE (SE) Used on any primary inputs that are required at a specific value
to force the network into the scan state. That is, they provide
pre-conditioning required to make the scan operation work. The
test function value (+, 1, -. 0, or Z) is the value the primary input
is set to before, and held at throughout, subsequent scan
operations. This is usually for the purpose of gating either a
shift clock or the scan data. After the scan operation is
completed, the scan_enable primary inputs can be switched
to a different value.
Note: Modus supports the use of SCAN_GATE (SG) as a
synonym for SCAN_ENABLE.

Note: If you have a bi-directional (inout) pin that is sourced by a three-state device you need
to ensure that the TEST_FUNCTION_PIN_ATTRIBUTE of the pin doesn’t cause three-state
burnout during scan. This can be accomplished by using a SCAN_ENABLE with a value of high
impedance (ZSE) on the inout pin. If the inout pin has a test function attribute of SCAN_OUT.
Modus automatically adds a TEST_FUNCTION_PIN_ATTRIBUTE of SCAN_ENABLE with a
value of Z (ZSE) to this pin.

If a custom scan sequence is used, the scan preconditioning sequence must stimulate this
pin to Z, and this is the responsibility of the user. Modus does not modify the custom scan
sequence definitions.

December 2019 170 Product Version 19.12

Test Inhibits, Test Constraints and Lineholds

TEST_INHIBIT (TI) Used on all primary inputs, pseudo primary inputs, and fixed value
latches that you want forced to a fixed value throughout test
generation (not only during scan, like the SE does). The test function
value (+, 1, -, 0, Z, X, or o) is forced on the primary input. Pseudo
primary inputs (PPIs) are forbidden to be designated as oTI (which
would be interpreted as permanently connected to an oscillator). All
other values listed are acceptable on a TI pseudo primary input. Z, X,
and o are not valid for fixed value latches. For fixed value latches, this
test function serves only for checking; it allows Test Structure
Verification to verify that all latches having a +TI test function are, in
fact, fixed value latches and were initialized to the specified state. For
additional information, refer to:
■ “Logic Test Structure Verification (TSV)” in the Modus : Guide
3: Test Structures.
TEST_INHIBIT can be used to:
■ Break feedback loops (for example, ring oscillators) that would
cause test generation problems.
■ Disable signals that would cause clock races.
■ Hold fixed value latches at the initialized state (for example, by
using a TI to force the clock inputs off at the latch).
■ Remove a section of logic from consideration during testing in
this testmode (for example, inhibit external logic during boundary
scan internal testing).

Additional TI Considerations:
■ Note that there is a difference between values asserted by TEST_INHIBIT pins and
those forced by TIE primitive blocks. The value provided by the TI pin or latch applies only
in the testmode being processed. This primary input or latch probably will be switched to
the opposite value during some functional mode of operation (or even in a different
testmode). A TIE primitive block is assumed to represent a permanent physical
connection to, say, a power rail, and has the same value in all testmodes and functional
modes.
■ A TI flag (or a Clock flag) can be assigned to a CIO only if the chip driver is guaranteed
to be in a safe (HIGH-Z) state. A safe chip driver can be guaranteed in one of two ways:
❑ Assign TI flags to other chip PIs (not CIOs) that will force the chip driver to a Z state.

December 2019 171 Product Version 19.12

❑ Provide a mode initialization sequence that first puts a Z on the CIO input, then sets
the chip driver to a Z state, then finally sets the TI value on the CIO. The internal chip
state that forces the chip driver to Z must be maintained throughout all testing in this
mode. Therefore, all other PIs that have to be held steady to maintain this chip
internal state would also have to be assigned TI flags. Note that this chip internal
state can not be influenced by any scannable latches in this mode.
See “Writing an Initialization Sequence” on page 249 for additional information.

TEST_CONSTRAINT (TC) Used on all primary inputs and pseudo primary inputs that you
want forced to a fixed value for test generation but not for
scanning. The test function value (+, 1, -, 0, or Z) is forced
during test generation, and may in turn cause certain latches
to then take on the TC characteristic.
LINEHOLD (LH) Used to hold a primary input pin or pseudo primary input to
value (+, 1, -, 0, or Z) during test generation. It has no test
significance other than that it has been determined that the
automatic test generation process would be most effective
with this pin held to the specified logic value. Lineholds can be
overridden or removed during individual test generation, fault
analysis, or macro structure verification runs. Lineholds are
ignored during other Modus applications.

Test Constraint Sequence Order

Turning a clock ON may cause some flip-flops to change state, and thus, turning ON multiple
clocks simultaneously increases the chance of races. The exposure to races is especially
great if the design responds to the clocks in question in a level-sensitive manner. For some
designs, one clock being ON may block the propagation of some other clock, and thus prevent
flip-flops from changing at all when the clocks are switched in the correct order.

To control the order of switching, append a number to the TC attribute to indicate the order in
which they are set to their value within the scan exit sequence. A TC pin with no number is
assigned a sequence number of 0, i.e. TC0. Subsequent ordering of TC pins can be specified
in the following manner: TC1, TC2 etc. The TC pins will be set to their designated TC states
in increasing order when leaving the scan state. When re-entering the scan state, those TC
pins that must be switched are set to their designated scan states in the reverse order (in
decreasing order).

A warning message is issued if there are multiple clocks that are TC’d ON, and that have no
TC number or have the same TC number.

December 2019 172 Product Version 19.12

Latches

FINITE_STATE_MACHINE (FSM) Used on latches only, this test function identifies a

latch which assumes a specific state after the
application of a homing sequence (which must be
included in the modeinit sequence) but that cannot
be brought to that state from an initial unknown
state by standard three-valued simulation. The logic
value assigned with this test function may be either
unspecified or else 1, +, 0 or -. If unspecified then
Modus will automatically determine the state that
this latch achieves through application of the
modeinit sequence. Refer to “Mode Initialization
Sequences” on page 247 for additional information.
FIXED_VALUE_LATCH_LINE_HOLD Used on latches only, this test function works like an
(FLH) LH on a primary input. The difference between FLH
and TI on a latch is that, as on primary inputs, the
linehold value can be overridden by the user for
specific test generation runs and the TI cannot. Test
Structure Verification verifies that all latches having
a +FLH test function are, in fact, fixed value latches
and were initialized to the specified state. Refer to
“Logic Test Structure Verification (TSV) in Modus :
Guide 6: Test Structures.
TEST_INHIBIT (TI) Refer to “Test Inhibit. Value held constant during
scanning and testing. These pins are always tied to
the specified value in this testmode.” on page 149.

Three-State Driver Control

BIDI_INHIBIT Used on a primary input that forces primary outputs fed by three-state
(BI) drivers (TSDs) to high-impedance (Z). The purpose of this primary
input is to enable manufacturing to easily generate a parametric test to
confirm that TSDs can achieve the high impedance state. If the
product contains TSDs, then Test Structure Verification checks that
such a pin exists and performs the inhibiting function for all TSDs that
directly drive primary outputs. The value (+, 1, -, or 0) is the value that
forces the outputs to Z. Refer to Three State Driver (TSD) Primitive for
additional information in Modus : Guide 1: Models.

December 2019 173 Product Version 19.12

Simultaneous Output Switching Control

OUTPUT_INHIBIT (OI) Used on a primary input or pseudo PI that disables output drivers
for the purpose of avoiding noise induced by crosstalk or
excessive power supply drain during switching. The test function
value (+, 1, -, or 0) is the value that inhibits the output drivers and
is the state at which the pin will be set during scanning.

Logic Built-In Self Test (LBIST) Controls

WEIGHT_SELECT (WS) Used on primary inputs and pseudo primary inputs that control
the channel input signal weight selection for an LBIST structure
that implements weighting. The test function value (+, 1, -, or 0)
is the value that causes the scan chain inputs to have a signal
probability of 0.5 -- equiprobable 1s and 0s -- when all WS pins
are set to their test function values. Refer to the description for
Channel input signal weighting in the “LBIST Concepts”
section of Automatic Test Pattern Test Generation User
Guide.

On-Product MISR Controls

These test function pins are specified when creating an On-Product MISR testmode. Prior to
creating this testmode, you must first create a testmode for diagnostics scan out. Refer to On-
product MISR (OPMISR) Testmode and Appendix 6, “ON_BOARD_MISR” for details.

MISR_OBSERVE (MO) Used to identify the output pins where the contents of a MISR
will be observed.

December 2019 174 Product Version 19.12

Tips:
■ MISR bits can feed to a MO pin through an XOR or XNOR network. This is useful when
there are more MISR bits than MO pins. See XOR Primitive Function and XNOR
Primitive Function in Modus : Guide 1: Models.
■ There is some increased chance of signature aliasing when MISR bits are XORed
together. It is suggested that no less than 16 MO pins be used. It is also suggested to
use multiple MISRs with different polynomials to help reduce the chance for aliasing.

MISR_RESET (MRST) Used to identify a clock that resets the MISR L1 latches
to logic zero when pulsed.
MISR_RESET_ENABLE (MRE) Allows the MISR_RESET clock to be shared with some
other clock function by shutting of the MSR_RESET
clock during all other functions. The ZMRE test function
pin may also be specified. ZMRE indicates the MRE will
have a value of Z when its test function is applied.
MISR_READ (MRD) Identifies a signal that causes the product MISRs to be
seen at the MISR_OBSERVE pins when all MRD pins
are asserted while the design is in the scan state.

Channel Masking Controls

Channel_Mask_Input (CMI) These are optional in that SI pins will be assumed to

be CMI pins. If there are no CMI pins defined and there
is a CML (or CML_A or CML_B) pin defined, a CMI
specification is generated for each SI pin.

December 2019 175 Product Version 19.12

Channel_Mask_Enable (CME) This pin defines how the channel masks are applied
based on scan cycle. The specified polarity identifies
the CME state that does not gate out any channel. A
maximum of four CME pins (excluding any pins that may
be correlated to a CME pin) may be specified. The
default is to add a TC to the same value for each CME
pin.
Specify a number (e.g. CME0 and CME1) to denote an
ordering for these pins when treated as a bus signal
(e.g. CME0,CME1 = 00). Digits 0-3 are supported. If a
digit is not specified, the testmode build process
assigns one automatically.
Channel_Mask_Load_Enable The polarity of the CMLE pins defines the design state
(CMLE) on top of the scan design state in which the channel
masks are to be loaded. CMLE pins are needed only if
the CML clock is also a scan clock such that the
application of the CMLE pins forces the CML clock to
perform its mask bit loading function rather than the
scan loading function. A CMLE pin should also be an
SG/SE pin of the opposite polarity; the testmode define
process adds this if has not been specified as such. If
an SE is specified to the same polarity on the CMLE pin,
a warning message is issued stating that it is unlikely to
work correctly. Opposite polarities are most likely to
work.
Channel_Mask_Load (CML) This clock, when pulsed in the CMLE design state, will
serially load in the mask bits from the CMI/SI pins. If
there is a CML pin defined, then there must be at least
one CME pin defined. This is assumed to be an edge-
based clock for the purpose of scan loading the
channel mask registers.
End of Channel Mask Shift An optional test function you can define in your assign
Register (EO_CMSR) file if the design has Channel Masking onboard. This
test function should be placed on the last register of the
Channel Mask Shift Register. If provided,
build_testmode will alert the user with a TTM-772 if
the tool is unable to reach this end-point of the Channel
Mask Shift Register. This test function does not take a
polarity.

December 2019 176 Product Version 19.12

All of these preceding signals with the exception of SCAN_IN_GATE, SCAN_OUT_GATE, and
SCAN_OUT_FILL may be specified only in the On-Product MISR testmodes.

OPCG Controls

Specify these test function pins when creating an OPCG testmode. Refer to OPCG
Testmodes for more information.

Oscillator (OSC) The specified stability value represents the OFF state of the
signal with regard to simulation of pulses along that signal.
Refer to “OSCILLATOR (OSC)” on page 169 for additional
information.
GO The specified stability value identifies the state of the GO signal
that holds the OPCG logic quiescent. Switching the GO signal to
its opposite value causes the launching of internally generated
clocks. The specified stability value is held on the GO signal at
all times except when launching an OPCG clocking sequence.
OPCG_Load_Input (OLI)
This test function identifies a scan data input pin used to serially
load an OPCG register. If an OLC (OPCG Load Clock) is
defined without any OLI pins being defined, all SI pins are
presumed to also be OLI pins. If Modus reports that it cannot
verify the loading of the OPCG Register Flip Flop or if a subset
of SI pins are the OLI pins then you must provide the OLI test
function as input.
End of OPCG Register An optional test function you can define in your assign file if the
(EO_OPCG): design has OPCG onboard. This test function should be placed
on the last register for the OPCG. If provided
build_testmode will alert the user with a TTM-773 if the tool
is unable to reach this end-point of the OPCG register. This test
function does not take a polarity.

December 2019 177 Product Version 19.12

RPCT Boundary Controls

BOUNDARY_DATA_PIN (BDY) Used on any primary input pin or primary output pin that
is to be contacted during RPCT boundary scan for
internal testing, but has no other test function. There is
no test function value for BDY. For mixed analog/digital
designs, use the BDY value to identify the pins that can
be controlled and/or observed during ATPG.
CONTROL_PIN (CTL) Used on any primary input pin or primary output pin that
has some unspecified test function which is of no
concern in the generation of test data. Modus treats
these the same as BDY; that is, it is a pin that will be
contacted during RPCT boundary scan internal testing.
Although Modus need not be aware of the pin's
function, this designation allows manufacturing to
distinguish it from uncontacted pins and RPCT boundary
data pins (BDY). There is no test function value for CTL.
NO_INTERCONNECT (NIC) Used on a chip pin to indicate that this pin is not to take
part in the interconnect test generation process for the
higher level structure (MCM/card). This specification is
ignored unless the Mode Definition includes
BOUNDARY=EXTERNAL, MODEL on the SCAN statement
(refer to “TEST_TYPES” on page 140 for more
information), indicating that the only purpose of this
testmode is to enable construction of a chip boundary
model for interconnect test generation. There is no test
function value for NIC.

December 2019 178 Product Version 19.12

1149.1 Boundary Controls

These controls are normally specified in the BSDL (Boundary Scan Design Language) but
can be specified in the model source or in the testmode definition file.

TEST_CLOCK (TCK) Used on a primary input that is intended to be the clock that
controls the IEEE 1149.1 test logic. A TCK value may be
specified, though it is automatically assumed to be 0 (the
inactive clock state). Any non-zero value, which is specified,
will be ignored and 0 will be used.
TEST_MODE_SELECT Used on a primary input that synchronizes IEEE 1149.1 test
(TMS) operations. This primary input is used with the TCK clock to
change states in the Test Access Port (TAP) Controller. A
logic value may be specified for this pin, but it is meaningless
and will be ignored, since the term “active state” does not
apply to the TMS pin. Depending on the present state of the
TAP Controller, a state change may take place with TMS
either at 0 or at 1 whenever TCK is pulsed.
TEST_RESET (TRST) Used on a primary input that is used for asynchronous reset
of the TAP Controller. To reset the TAP Controller
asynchronously this pin is set to 1-0-1. A logic value may
optionally be specified for this pin, but if it is anything other
than 1, the inactive state, the value will be ignored and 1
assumed.
TEST_DATA_INPUT (TDI) Used on a primary input that is the scan input for IEEE 1149.1
scan. There is no value specified with this test function.
TEST_DATA_OUTPUT Used on a primary output that is the scan output for IEEE
(TDO) 1149.1 scan. There is no value specified with this test
function.

Pin requirements for an 1149.1 testmode

In order for a testmode to be recognized by Modus as a legitimate 1149.1 testmode, it is
necessary that at least one each of the following pins be identified: TCK, TMS, TDI, and
TDO. The TRST pin is optional.

December 2019 179 Product Version 19.12

Test Function Pins for an 1149.1 Mode

The Boundary Scan Design Language (BSDL) file defines the test function pin attributes for
an 1149.1 testmode. The test function pins that support 1149.1 applications are TCK, TMS,
TDI, TDO, and TRST. TRST is optional when a TRST pin is not defined for the design.

For 1149.1 components that support multiple test strategies such as LSSD and 1149.1, there
may be a “compliance enable” pattern required for the component to put it into the 1149.1
testmode. The compliance enable pattern is a set of test function pins and their values which,
when applied to the device, enable and hold the device in the 1149.1 mode. The BSDL
statement COMPLIANCE_PATTERNS defines the compliance pattern for a design. Build
Testmode uses the information defined in the BSDL statements COMPLIANCE_PATTERNS
and scan port identification (for example, attribute TAP_SCAN_CLOCK) to define the test
function pins for an 1149.1 mode.

Refer to “Creating an 1149.1 Testmode for Boundary Scan Verification” in the Verification
and Analysis Reference for additional information.

Secondary Test Function Attributes for 1149.1 Stored Pattern Test Generation

If the testmode is for the purpose of 1149.1 stored pattern test generation, either TAP scan
or LSSD/GSD scan, then Modus automatically creates certain secondary test function
assignments for the 1149.1 pins. This is to allow test generation applications to process this
testmode normally, without having to be aware of its special 1149.1 nature. For example, if a
user assigns the TDI test function attribute to a pin, then while creating a testmode, Modus
automatically supplements the pin with an SI test function attribute.

The following table describes the automatic secondary test function assignments made by
Create a Testmode.
User-assigned test attribute Generated secondary test attribute
---------------------------- ----------------------------------

TAP scan GSD scan

-------- -------------
(1) TDI SI (none)
(2) TDO SO (none)
(3) TCK *** -ES -TI
(4) TRST *** +TI +TI (inactive)
(5) TMS *** (see box) +TI (to hold TLR state)

December 2019 180 Product Version 19.12

*** Polarity specification is optional for TCK, TRST and TMS pins.
If specified it is ignored.

Secondary test function for TMS pin:

The secondary test function assignment for a TMS pin depends on the TAP_TG_STATE
specified, according to the following table:
TAP_TG_STATE secondary TMS pin assignment
------------ ----------------------------
RUN_TEST_IDLE -TC
TEST_LOGIC_RESET +TC
PAUSE_DR -TC
SHIFT_DR -TI
CAPTURE_DR -TC

See “TAP_TG_STATE” on page 135 for additional information.

Power-Up Safe State Controls

These controls enable embedded devices to power-up in a safe state to either prevent
damage or hold the device configuration.

Determining Which Test Functions to Use

The following tables indicate the test functions you might use for different scan design styles/
test methodologies. These tables show the test functions for a “pure” implementation of the
specified scan design style. Since Modus supports mixed scan design styles, you should look
at the tables for each scan style you have included and ensure that your test function pin
specifications are complete. Modus is not rigid about the test function attributes you use. If
the attributes you define allow you to run Test Structure Verification smoothly, your test data
will be good.
GSD GSD GSD GSD
Test MUXed Clocked Gated Gated
Function Scan Scan Clock Data
_____________________________________________________

PC or PS
EC or ES Yes Yes Yes Yes
SC Opt Yes
SE Yes Yes (1) Yes
CI Yes (1)

TI Opt Opt Opt Opt

TC Opt Opt Opt Opt

FLH Opt Opt Opt Opt

December 2019 181 Product Version 19.12

SI Yes Yes Yes Yes

SO Yes Yes Yes Yes
OI Opt Opt Opt Opt
LH Opt Opt Opt Opt
_____________________________________________________

Test Built-In RPCT IEEE 1149.1

Function Self Test Boundary Scan Boundary Scan (2)
________________________________________________________________________

BI
BDY Yes
CTL Opt
TCK Yes
TMS Yes
TDI Yes
TDO Yes
TRST Opt
WS Opt
________________________________________________________________________

Notes:
1. Either a SE/SG or CI must be specified.
2. The test function definition for 1149.1 Boundary Scan will normally come in through the
use of BSDL (Boundary Scan Description Language). The capability to provide it through
attributes in the design source or in the testmode definition file is to allow for automatic
generation of BSDL from the Modus model without requiring a “skeleton BSDL” file as
input.

Valid Combinations of Test Functions

There are restrictions on the combinations of test function attributes that can be specified on
a primary input, primary output, pseudo primary input, or a latch for a single testmode. For an
obvious example, your scan_in pin cannot also be your system_clock. Note that Modus
supports a synonym of scan_gate for scan_enable.

December 2019 182 Product Version 19.12

The following is an overview of the test function attributes grouped according to the scope of
their application. Note that some attributes exist to identify the pin's function during scan
operations; other attributes apply for operations performed between scan operations.

scan-in Attributes that apply during scan-in operations.

With the exception of CI, all pins in this category can, in theory, have
some functional purpose that is not related to test. All of them,
including CI, are enforced only during scan; at other times they can
be manipulated freely according to the needs of a specific test or
functional operation.
scan-out Attributes that apply during scan-out operations.
non-scan Attributes that apply during non-scan operations. Modus supports
two attributes that fall into this category:
■ LH
The line hold attribute is unique in being the only one that can be
overridden during execution of test generation applications.
Whether originating from a test function attribute or a line hold
file, these specified values are not enforced during scan.
■ TC
The test constraint (TC) attribute applies to a pin that must retain
a fixed value for all phases of test generation but is permitted to
change for the scanning operation.
global Attributes that apply all the time (for both scan and non-scan
operations).
Clock states, even those for shift clocks, are in force at all times
unless explicitly stated otherwise by the appearance of a TC attribute
on the pin. The output inhibit (OI) attribute, by definition, must be
enforced during application of any patterns, either scan or non-scan,
to minimize switching activity on output drivers.
According to the strict definition of this category, one could argue that
NIC does not belong here, but it is included to make it fit the rules
defined below, and the rationale is that a NIC pin is not used for
interconnect test during both scan and non-scan operations.

December 2019 183 Product Version 19.12

manufacturing Attributes whose purpose is related neither to scan nor to non-scan

operations.
Generally speaking, this category of attributes has relevance only for
post- Modus applications, such as the test data converters and test
controllers. The bidi inhibit (BI) attribute was defined so that
Manufacturing can easily generate their own tests for high-
impedance measurements. BDY and CTL identify pins which are to
be contacted during internal boundary scan chain testing. The
proper use of BDY and CTL is on any internal boundary scan
contacted pin that does not have another test function. Modus
assumes that all test function pins are contacted for internal
boundary scan.
Allowed combinations of test function attributes that can be on the
same pin in the same testmode are depicted in Figure Figure 6-11
on page 255.
latches Attributes applied to latches/flops. Refer to “Latches” on page 173.
misr observe Attributes that are applied for an OPMISR testmode and whose
values are used in the MISR_OBSERVE design state. Refer to
“OPMISR Testmodes” on page 46 and “MISR Observe” on
page 275.
channel mask Test function attributes that support OPMISR or OPMISRplus
testmodes. Refer to “OPMISR Testmodes” on page 46.
OPCG Test function attributes that support an OPCG testmode. Refer to
OPCG Testmode.

The following examples assign information to a pin. Blocks, nets, ppis, or symbols may be
assigned the same way.

Test Function examples:

ASSIGN PIN = A1 Test_Function=-TC;
ASSIGN PIN A1 -TC; Note: shortest form: optional =, optional test_function

Other Test Function examples:

ASSIGN PIN = A1 Test_Function=-TC;
ASSIGN PIN = A1 TESt_FunCtion=-TC;
ASSIGN PIN = A1 Test Function=-TC;
ASSIGN PIN = A1 Tfunc=-TC;
ASSIGN PIN = A1 Tfunc=-TC;
ASSIGN PIN A1 Tfunc=-TC;
ASSIGN PIN = A1 -TC;

December 2019 184 Product Version 19.12

ASSIGN PIN = A1 Test_Function= SI;

ASSIGN PIN = 01 Test_Function= SO;

ASSIGN PIN = A1 -TC -CI; Note:shortest form with two test functions

Clock Domain examples:

ASSIGN PIN A1 -TC CLK_DOMAIN=2; Note: has test function and clock domain
ASSIGN PIN A1 CLK DOMAIN=2; Note: no test function
ASSIGN PIN A1 CLKDOMAIN=2;
ASSIGN PIN A1 DOMAIN=2;

Other examples
ASSIGN PIN = "A01" TEST_FUNCTION = +ES +MRST;

HISNT

This statement is used in designs that make use of bottom-up DFT with top-down ATPG, often
called hierarchical compression. For designs properly processed with Genus DFT, this
statement will be added when needed to the assign file. The syntax for this statement is:

Relative to PWD
HINST=inst_name MODULE=Verilog_Module_Name ASSIGNFILE=./path/to/lower/pinassign;

If WORKDIR is set, relative to WORKDIR

HINST=inst_name MODULE=Verilog_Module_Name ASSIGNFILE=WORKDIR/lower/pinassign;

Absolute path
HINST=inst_name MODULE=Verilog_Module_Name ASSIGNFILE=/path/to/lower/pinassign;

For Migrating Elastic Register Equations

HINST=<INSTANCE_NAME> MODULE=<MODULE_NAME> ASSIGNFILE=<path/to/assignfile>
HMAP=<path/to/HMAP>

HMAP is a file that is used for additional correspondence when needed. Currently, this is used
only for mapping core level SIs to chip level SIs for Elastic equations.

If the design does not require this file, you may omit this option. This can be start at the
WORKDIR, pwd, or /.

HMAP File Syntax

hpin:”core_pin”=<+/->”chip_pin” [chip level pipeline depth];

Where the polarity of the chip pin is determined by the number of inverters between the chip
and core
Odd=- Even=+ Zero=+

December 2019 185 Product Version 19.12

The chip level pipeline depth is the count of pipeline registers between the chip pin and the
core pin and does not include the count at core level.

Example:
hpin: “DFT_core_SI[O]”=+ “DFT_Top_SI[O]” [4];

For a pin that has no inversion and four top-level pipeline bits.

COREINSTANCE

The following mode definition statement is used in hierarchical test at the chip (SOC) level in
the mode definition or assignfile used as input to build_core_migration_testmode. It
is not used for build_testmode. Coreinstance identifies whether specific instances of
each core are to be targeted for migration or are to be bypassed. This is done by specifying
the name of the core testmode that sets it in that state; these testmode were built when the
core was processed out-of-context.
Note: Only one instance of one core may be targeted for migration. The rest must be in
BYPASS. If an instance of a core is not included, that instance is assumed to be in BYPASS
mode.

COREINSTANCE = core_instance_name TESTMODE = testmode_name ;

In this statement:

core_instance_name Specifies the name of the instance of the core on the chip
(SOC). It may be in full proper form
(Block.f.l.topcell.nl.hierarchical.name) or short
form (hierarchical.name).
TESTMODE Specifies required keyword that identifies that the value after it
is the name of a testmode that was built for the out-of-context
core. This testmode determines whether this core is targeted
for patten migration or is put into bypass.

December 2019 186 Product Version 19.12

COREMAXPIPEDEPTH

The following statement is used in a testmode that will be used for core migration in
hierarchical test. The statement is specified in the boundary=migrate testmode(s) that are
built in the out-of-context core processing flow. It may be specified in the mode definition file
or the assign file for the testmode. It identifies the maximum number of input or output pipeline
stages that will be added to the scan chains. The default is 5.

COREMAXPIPEDEPTH = depth ;

In this statement:

depth Specifies the maximum number of pipeline stages that must be

accounted for when migrating tests to the top level (Chip or
SoC)

CORRELATE/UNCORRELATE

The CORRELATE statement supports the correlation of pins within the mode definition.

CORRELATE corr_pin_na + rep_pin_name ;

Two pin names are specified, for example:

CORRELATE corr_pin_name + rep_pin_name

■ corr_pin_name
Specify the name of the correlated pin (also referred to as the dependent pin).
■ rep_pin_name
Specify the name of the representative pin.

December 2019 187 Product Version 19.12

A “+” between the pin names denotes correlated in-phase; a “-” denotes correlated out-of-
phase. There is no default, either “+” or “-” must be specified.

The UNCORRELATE statement removes pin correlation.

UNCORRELATE pin_nam ;

Example syntax:
CORRELATE in2 +in1;
CORRELATE out2 -out1;
UNCORRELATE in2s;
CORRELATE in799 -in1;
CORRELATE in5c +in5;
CORRELATE in6c +in3;
UNCORRELATE in9;
CORRELATE out2 -out1;

Maintain awareness of the following when using the CORRELATE statement:

During testmode creation:

■ All pins referenced in the CORRELATE statement must be a PI, PO, or technology I/O
cell. If they are not a PI, PO or technology I/O cell, an error message is issued and the
statement is ignored.
■ The testmode creation process disallows test functions to be defined on newly defined
(in the mode definition file) correlated pins. If found in a new CORRELATE statement, an
information message is issued and the pin is removed from the Test Function Pin list.
■ If a pin is defined to be a dependent pin, it cannot appear as a dependent pin nor a
representative pin in any other CORRELATE statement. The first statement sets the pin
characteristic as either correlated or representative.

Interaction with the logic model:

■ If the dependent pin in the CORRELATE statement is defined as a representative pin
through the CORRELATE attribute in the model, then all dependent pins correlated to the
old representative pin in the model will be correlated to the representative pin specified
in the CORRELATE mode definition statement.
■ Conflicts between attribute-defined correlation polarity and mode definition polarity are
won by the mode definition, with associated informational messages issued.
■ If the dependent pin in the CORRELATE statement is defined as a dependent pin (to a
different representative pin) through the CORRELATE attribute in the model, its

December 2019 188 Product Version 19.12

correlation is changed to comply with the mode definition and an informational message
is issued.
■ If a representative pin in the CORRELATE statement is defined as a dependent pin
through the CORRELATE attribute in the model, an error message is issued and the
statement is ignored.
See Specifying Differential I/tO and Other Correlated Pins in Modus: Guide 1: Models
for details on the CORRELATE attribute.

CUTPOINTS

This optional statement identifies internal nets in the product that are to be treated by Modus
as primary inputs. It associates each such net with a conceptual primary input (pseudo PI)
through which the state of the net is specified for all Modus processing. There is a 1:many
relationship between pseudo PIs and cut points; several cut point nets that have a common
logical signal are tied together by reference to the same pseudo PI. A cut point is defined so
that its state is either the true or the complement of the state of its associated pseudo PI.

In this statement:

netname The hierarchical name of a net in the design

ppiname The name of the pseudo primary input (defined either in the design source
or implicitly by reference in this statement) which Modus will use to
“control” this net. The associated sign tells whether to invert the pseudo
primary input value when placing the value on the net.

The following is an example CUTPOINTS statement:

CUTPOINTS "netnameA" = +ppi_name,
"netnameB" = +ppi_name,
"netnameC" = +ppi_name;
assign ppi=ppi_name test_function=+ES;

December 2019 189 Product Version 19.12

Tip
Quotations are required around net names for a multiple cutpoint definition.

DELETE

This optional statement specifies properties or objects to be “deleted” or ignored for this
testmode. There is no default.

In this statement:

CPLIST Specify a list of netnames that are defined as cut points in the design
source and are not to be treated as cut points. CUTPOINT attributes on the
listed nets will be ignored.
PPILIST Specify a list of pseudo primary inputs that are defined in the Design source
and are not to be used. Deleting a pseudo PI automatically deletes all
references to it, so any cut points defined by reference to a deleted pseudo
PI will not be considered to be cut points unless they are redefined (through
the mode definition CUTPOINTS statement).

December 2019 190 Product Version 19.12

FIXED_VALUE_DEFAULT

This optional statement specifies the test function for all fixed value latches that do not have
a test function explicitly specified for them. If this statement is omitted, and such fixed value
latches exist, then they will be assigned a test function of test_inhibit (TI).

IMPLICIT CHOPPERS

TEST_INHIBI
TI

FIXED_VALUE_DEFAULT = FIXED_VALUE_LATCH_LINEH ;

The IMPLICIT CHOPPERS statement provides a method to avoid unintentionally defining a

chopper in the testmode. An implicit chopper is an otherwise validly defined chopper design
that does not contain the normally requisite CHOPL or CHOPT block.

Refer to Clock Chopper Primitives and Implicit Clock Choppers in Modus : Guide 1:
Models for additional information.

IMPLICIT = yes ;

The default is no, to disallow implicit choppers.

The Implicit Chopper keyword can appear anywhere in the Mode Definition file and only has
an effect on the treatment of valid implicit clock choppers. Invalid clock choppers are always
treated as errors and require Pessimistic (X-source) simulation. See “InfiniteX Simulation” in
the Automatic Test Pattern Test Generation User Guide for related information.

ON_BOARD_MISR
sig_reg=“<MISR Register name>" {

December 2019 191 Product Version 19.12

Register=(
“<MISR bit 1>",
“<MISR bit 2>",
……
“<MISR bit n>“);
Register_Cell_Equation=(
“<MISR bit 1>"=“<MISR bit n>",
“<MISR bit 2>"=“<MISR bit 1>",
……
“<MISR bit p>"=“<MISR bit p-1>“+“<MISR bit n>",
…...
“<MISR bit n>"=“<MISR bit n-1>“);
};

ON_BOARD_PRPG
patt_gen=“<PRPG Register name>" {
Register=(
“<PRPG bit 1>",
“<PRPG bit 2>",
……
“<PRPG bit n>“);
Register_Cell_Equation=(
“<PRPG bit 1>"=“<PRPG bit p>”+“<PRPG bit n>",
“<PRPG bit 2>"=“<PRPG bit 1>",
……
“<PRPG bit p>"=“<PRPG bit p-1>“,
…...
“<PRPG bit n>"=“<PRPG bit n-1>“);
};

December 2019 192 Product Version 19.12

OPCG

The OPCG statement defines OPCG logic to automatically process cut points and collect
additional data. Multiple OPCG statements are accepted as long as they do not conflict with
each other. Multiple OPCG statements are composited and applied to the mode definition.

December 2019 193 Product Version 19.12

other_pll_statements:

PLL_IN_FREQ = { min_value, nom_value, max_value } ;

MHZ
GHZ
KHZ

pll_ppi_designation

,
PLL_OUT_TFUNC = test function ;

PLL_OUT_FREQ = { min_value, nom_value, max_value } ;

MHZ
GHZ
KHZ

PLL_OUT_MULT = { min_value, nom_value, max_value } ;

PLL_LOCK = number ;

net name
PLL_GO = ;
pin name

pll_latency

pll_program

pll_ppi_designation

PLL_OUT_PPI = ppi name ;

PLL_OUT_OSC = net name

pll_latency:

pll_go_latency pll_go_ref ;

pll_go_ref pll_go_latency

December 2019 194 Product Version 19.12

pll_go_latency:

PLL_GO_LAT = { min, max } ;

pll_go_ref:

PLL_GO_REF = net name ;

pll_program:

PLL_PROGRAM { pll_register }

pll_register:

PLL_REG = regname { pll_register_data }

pll_register_data:

pll_register_bits pll_register_type pll_register_values

pll_register_bits:
,
PLL_REG_BITS = { latch_name } ;

pll_register_type:

PLL_REG_TYPE = pll_type ;

pll_type:

PLL_MULTIPLIER ;
PLL_DIVIDER
PLL_CUSTOM

pll_register_values:
,

PLL_REG_VALUES = { bit string,“meanString” } ;

December 2019 195 Product Version 19.12

domain_statements:

domain_in_clock_statement domain_ppi_def domain_freq_statement other_domain_statements

domain_in_clock_statement:
net name
DOMAIN_IN_CLOCK = ;
pin name
domain_ppi_def:

DOMAIN_PPI = ppi name ;

DOMAIN_ROOT = net name

domain_freq_statement:
DOMAIN_FREQ = { min_value, nom_value, max_value } ;
MHZ
GHZ
KHZ
other_domain_statements:
,
DOMAIN_TFUNC = test function ;
DOMAIN_ACC = n.nn ;
p5
n5
f5
net name
DOMAIN_GO = ;
pin name

domain_latency

domain_program

domain_latency:

domain_go_latency domain_go_ref

domain_go_ref domain_go_latency
domain_go_latency:

DOMAIN_GO_LAT = { min, max } ;

December 2019 196 Product Version 19.12

domain_go_ref:

DOMAIN_GO_REF = net name ;

domain_program:

DOMAIN_PROGRAM { domain_register }

domain_register:

DOMAIN_REG = regname { domain_register_data }

domain_register_data:

domain_register_bits domain_register_type domain_register_values

domain_register_bits:
,
DOMAIN_REG_BITS = { latch_name } ;

domain_register_type:

DOMAIN_REG_TYPE = domain_reg_type ;

domain_program:
,
DOMAIN_PROGRAM [ domain_register ] ;

domain_register:
,
DOMAIN_REG [ domain_register _data ] ;

domain_register_data:

domain_register_bits domain_register_type domain_register_values

December 2019 197 Product Version 19.12

domain_reg_type:

DOWN_COUNTER
DOWN_COUNTER2
DOWN_COUNTER_HALF
PULSE_WIDTH
PULSE_WIDTH2
PULSE_SELECT
PULSE_SELECT2
SKEW_SELECT
CLOCK_HIGH_GATE_SR

CLOCK_LOW_GATE_SR
CUSTOM

domain_register_values:
,

DOMAIN_REG_VALUES = { bit string, “meanString” } ;

In this statement:

TYPE Specify one of the following options to indicate the type of

OPCG logic:
■ NONE to indicate no OPCG logic is defined
■ CUSTOM to indicate that customized OPCG logic is
implemented. Custom requires additional input, described
for opcg_details on page 199.
■ STANDARD to indicate that the OPCG logic is inserted by
Cadence Genus

December 2019 198 Product Version 19.12

LOAD_TYPE Specify one of the following methods to load OPCG

programming registers:
■ serial_setup to load registers via a serial scan that is
applied during a setup sequence.
■ scan to indicate that the registers are built into the standard
scan chains and will require reload on every scan_load
event. Refer to “Scan_Load” in the Test Pattern Data
Reference for additional information.
■ 1149.1 to indicate use of an 1149.1 instruction to load the
registers. Refer to “Automatically Generated Initialization
Sequence” on page 248 for additional information.
If using an 1149.1 instruction, specify one of the following
options to define the type of INSTRUCTION:
❍ A binary string to specify the binary bit string to be
loaded.
❍ The name of the 1149.1 instruction.
opcg_details Specify additional OPCG specifics to identify elements such as
PLL and clock domain information. Refer to the following:
■ “Specifying PLL Data”
■ “Specifying Clock Domain Data” on page 202

Specifying PLL Data

Specify PLL details using the syntax PLL_NAME=pll_name. The assigned name to each
PLL output must be unique. As a netlist attribute, specify a comma-separated list of names If
a specified netlist name begins with an ampersand (&), the name will have the containing cell
instance name prepended with an underscore (_).

The following are the PLL_NAME keyword options and syntax:

Note: The following keywords are optional unless specifically designated as required.

December 2019 199 Product Version 19.12

PLL_IN_OSC=Input_Oscillator_pin ;
Specify the name of the PLL oscillator input. As a keyword
option, the value must be a primary input pin or a net that can
be traced back to a PI or another PLL output (PLL_OUT for a
different PLL definition).
As an attribute, it must specify the input pin of the cell
containing the attribute or, if it is an instance attribute, the name
of a net connected to the cell instance.
In either case the pin or net must be traceable to locate the PI
that will be supplying the oscillator input. When a single
physical PLL has multiple outputs, they may all reference the
same IN_OSC.
PLL_IN_OSC is a required PLL_NAME keyword.
PLL_IN_FREQuency=(min,nom,max)[MHz|GHz|KHZ];
Specify the minimum, nominal and maximum input oscillator
frequencies supported by the PLL..
{PLL_OUT_PPI=Output_Oscillator_PPI}
Specify a Pseudo-PI (PPI) defined elsewhere that is used to
represent the PLL output as a free running clock. If this is
specified, OUT_OSC should not also be specified. This
keyword is mutually exclusive with PLL_OUT_OSC.
{PLL_OUT_OSC=Output_Oscillator_net} ;
Specify the name of the net for which a cutpoint and PPI will be
automatically defined. The PPI name will be generated from a
catenation of the PPI_NAME value with _PLL_PPI at the end.
Note that if the PLL_NAME attribute value begins with an
ampersand (&), the PPI name will have the instance name for
the cell containing the attribute included. This keyword is
mutually exclusive with PLL_OUT_PPI.
PLL_OUT_TFUNC = testfunction ;

December 2019 200 Product Version 19.12

Specify the test function to be associated with the PPI

corresponding to the PLL output. This is the only means of
specifying the intended test function for the PPI when
generating the PPI given the OUT_OSC net. If the PPI is already
defined, either this keyword or the ASSIGN statement may be
used to specify the PPI test function.
PLL_OUT_FREQuency = (min, nom, max) [MHz | GHz | KHz] ;
Specify the minimum, nominal and maximum output frequency
supported by the PLL output. The default unit is MHz.
PLL_OUT_MULT = (min, nom, max) ;
Specify the minimum, nominal and maximum multiplying factors
for the PLL. When a single physical PLL has multiple outputs,
only the highest frequency output requires PLL_OUT_MULT
specified for it.
PLL_LOCK = n ;
Specify the maximum number of input oscillator cycles before
the PLL is guaranteed to be locked. Specify this attribute only
on the PLL output used to do the locking of the PLL (this output
is fed back to compare input).
PLL_GO= GO_pin ;
Specify the GO signal used to control all domains run by the
PLL output.
PLL_GO_LATency = (min, max) ; PLL_GO_REF = pll_out_name ;
Specify the relative minimum and maximum latency between
when the GO primary input is triggered and the first possible
clock edge appears at any clock domain controlled by the PLL
output. Specify the minimum and maximum as cycle counts for
the PLL_GO_REF oscillator signal.
PLL_GO_REF is required if PLL_GO_LATency is specified.
Specify the reference oscillator used to estimate the latency
between GO switching and clock edges appearing on domain
clock tree roots.

December 2019 201 Product Version 19.12

[PLL_PROGRAM {
PLL_REG = regname {
PLL_REG_BITS=(bit_n-1, bit_n-2, ..., bit_0) ;
PLL_REG_TYPE = plltype ;
PLL_REG_VALUES = ( val_0, "meaning_0" ,
...., val_n, "meaning_n" ) ;

Specify the beginning of a block of PLL register definitions in

the mode definition or ASSIGN file.
PLL_REG - specify the name for the PLL program register. Use
a comma separated list of register names to specify as a netlist
attribute.
Within the mode definition or ASSIGN files, the following
keywords apply to this register up until the next REG keyword
specifies the start of information for a new register:
■ PLL_REG_BITS - specify a list of latches or flops that
comprise the PLL register, listed from the high-order bit to
the low-order bit. The bit ordering is important since values
will be assigned to the registers as binary values.
■ PLL_REG_TYPE - specify the type of the PLL register. The
valid PLL register types are: PLL_multiplier,
PLL_divider, and PLL_custom.
■ PLL_REG_VALUES - specifies a list of paired values and
meanings. The first value is a binary value representing a
value that can be loaded into the bits of the register. Specify
binary values (for example, 00101 for a 5-bit register). The
second value is a string providing some meaning to the
preceding value (for example, "multiply_by_5").
Separate the values with commas. Each pair constitutes
data for a single value. To specify register values via a netlist
attribute, specify the entire list of values and meanings as a
single string with commas separating the values from the
meanings

Specifying Clock Domain Data

Specify domain details using the syntax Domain_NAME=domain_name. {. The assigned

name to each domain must be unique. As a netlist attribute, specify a comma-separated list
of names If a specified netlist name begins with an ampersand (&), the name associated with
this instance of the domain will include a pre-pending of the hierarchical name of the instance
of the cell containing the attribute.

December 2019 202 Product Version 19.12

The following are the DOMAIN_NAME keyword options and syntax:

Note: The keywords are optional unless specifically designated as required.

DOMAIN_IN_CLOCK = in_clock ;
Specify the input oscillator clock used to run the domain’s
OPCG logic. When specified as a netlist attribute, it must
specify a cell pin name or a net name if it is on a cell usage/
instance. Tracing back through ungated logic from this pin or net
arrives at either an OSC node (PI or PPI output of a PLL) or the
ROOT (PPI) of another clock domain when there is a cascading
of domains.
DOMAIN_PPI = PPI_name ;
Specify the PPI representing the clock domain. when the PPI is
already defined for the testmode. This keyword is mutually
exclusive with DOMAIN_ROOT. Use DOMAIN_PPI when there
are multiple cutpoints as DOMAIN_ROOT identifies a single net
that will be the cutpoint for the PPI.
DOMAIN_ROOT = domain_root ;
Specify the name of the net for which a cutpoint and PPI will
automatically defined to represent the clock domain. This
keyword is mutually exclusive with DOMAIN_PPI.
DOMAIN_FREQ= (min, nom, max) [MHz | GHz | KHz] ;
Specify the frequency range and nominal value. The default unit
is MHz.
DOMAIN_TFUNC = testfunction ;
Specify the test function to be associated with the PPI
corresponding to the Domain Root. This is the only means of
specifying the intended test function for the PPI when
generating the PPI given the ROOT net. If the PPI is already
defined, either this keyword or the ASSIGN statement may be
used. Refer to TEST_FUNCTION - Indicates that the test
function will follow. The use of this keyword is only for
readability. on page 159 for description of the pins.

December 2019 203 Product Version 19.12

DOMAIN_ACCuracy = n.nn [ps | fs | ns] ;

Specify the relative skew between cutpoints associated with the
PPI of the clock domain. This is analogous to the TDR
specification of pin to pin accuracy for the tester.
DOMAIN_GO= GO_pin ;
Specifies the GO signal used to control all domains run by the
domain output.
DOMAIN_GO_LATency = (min, max) ; DOMAIN_GO_REF = domain_out_name ;
Specify the relative minimum and maximum latency between
when the GO primary input is triggered and the first possible
clock edge appears at any clock domain controlled by the
domain output. Specify the minimum and maximum as cycle
counts for the DOMAIN_GO_REF oscillator signal.
DOMAIN_GO_REF is required if DOMAIN_GO_LATency is
specified. Specify the reference oscillator used to estimate the
latency between GO switching and clock edges appearing on
domain clock tree roots.

December 2019 204 Product Version 19.12

[DOMAIN_PROGRAM {
DOMAIN_REG = regname {
DOMAIN_REG_BITS=(bit_n-1, bit_n-2, ..., bit_0) ;
DOMAIN_REG_TYPE = plltype ;
[DOMAIN_REG_VALUES = ( val_0, "meaning_0" ,
...., val_n, "meaning_n" ) ; ]

Specify the beginning of a block of OPCG program register

definitions in the mode definition or ASSIGN file.
DOMAIN_REG - specify the name for the OPCG program
register. Use a comma separated list of register names to
specify as a netlist attribute.
Within the mode definition or ASSIGN files, the following
keywords apply to this register up until the next REG keyword
specifies the start of information for a new register:
DOMAIN_REG_BITS - specify a list of latches or flops that
comprise the OPCG register, listed from the high-order bit to
the low-order bit. The bit ordering is important since values will
be assigned to the registers as binary values.
DOMAIN_REG_TYPE - specify the type of the OPCG register.
The following are valid register types:
■ DOWN_COUNTER counts down from the active edge of the
GO signal for the launching of pulses down the associated
clock domain.
■ DOWN_COUNTER2 is a counter whose clock runs at double-
speed (the counter’s clock is twice the frequency of the
domain input clock).
■ DOWN_COUNTER_HALF is a counter whose clock runs at
half the domain’s input clock frequency.
■ PULSE_WIDTH is an n bit binary register that is 1-hot such
that exactly 1 of its bits must be 1 if the domain is to be used.
■ PULSE_WIDTH2 is used when the pulse generation logic
runs at twice the domain’s input clock frequency. the earliest
possible trailing edge is the cycle after the leading edge of
the domain’s pulse.
■ PULSE_SELECT statically defines when additional pulses
beyond the first for a domain should appear.

December 2019 205 Product Version 19.12

■ PULSE_SELECT2 denotes that the domain OPCG logic is

running at twice the frequency of the domain input clock.
■ SKEW_SELECT is an n bit register whose binary value
selects from a set of available delays to add into the clock
domain when in OPCG mode. The skew amount added will
delay the start of all clock edges. If there are multiple OPCG
macros in various locations on a device that use the same
clock frequency, adding some skew to one may be useful for
dealing with timing between such regions of the same clock
domain in OPCG mode.
■ CLOCK_HIGH_GATE_SR contains the string of bits to be
used to gate the domain’s input clock when that clock is in
its high phase. This is a serially shifted register that outputs
a new value on the falling edge of the input clock so that it
is safe to use the register output to gate the clock high
phase. This register can be paired with a
CLOCK_LOW_GATE_SR register that gates the clock on the
low phase. This is used when the domain clock output is
generated by use of muxed clock gating on opposite phases
of the clock.
■ CLOCK_LOW_GATE_SR contains the string of bits to be used
to gate the domain’s input clock when that clock is in its low
phase. This is a serially shifted register that outputs a new
value on the rising edge of the input clock so that it is safe
to use the register output to gate the clock low phase. This
register can be paired with a CLOCK_HIGH_GATE_SR
register that gates the clock on the high phase. This is used
when the domain clock output is generated by use of muxed
clock gating on opposite phases of the clock. This register
is otherwise functionally equivalent to the
CLOCK_HIGH_GATE_SR.
■ BLOCK_DOMAIN_INPUTS contains a single bit that when
set to a BLOCK value will cause the functional flops of this
domain that receive values from other domains to have the
paths into them from other domains blocked. Valid value
meanings are BLOCK and ENABLE.

December 2019 206 Product Version 19.12

■ CUSTOM is used to define programming bits that are useful

to an OPCG design however are not recognized by Modus
. These may be of arbitrary length and Modus will not have
any understanding of what values to set into these registers
other than to apply the values specified to load into them.
DOMAIN_REG_VALUES specifies a list of paired values and
meanings. The first value is a binary value representing a value
that can be loaded into the bits of the register. Specify binary
values (for example, 00101 for a 5-bit register). The second
value is a string providing some meaning to the preceding value
(for example, "multiply_by_5"). Separate the values with
commas. Each pair constitutes data for a single value. To
specify register values via a netlist attribute, specify the entire
list of values and meanings as a single string with commas
separating the values from the meanings.

POWER_MODE

The following optional mode definition syntax is used to configure a reduced power testmode.
Refer to Configuring a Reduced Power Testmode Definition Statement in the Low Power
chapter in Modus: Flows.

Specify the following:

Power_Mode=powermodename

The specified name must match the name of a Power Mode specified with a
create_power_mode statement in the CPF file specified for the read_power_intent
command (-namemappingfile filename) or, if you are using UPF, is the name of a
POWER_MODE reported in the log of the read_power_intent command (-
powerintentfile filename).

December 2019 207 Product Version 19.12

SEQUENCE_DEFINITION

This statement specifies a file name that contains predefined input pattern sequences for a
testmode.

An example is the definition of a custom scan sequence for a part. Another is the specification
of a mode initialization sequence definition required for testmodes that have non-scannable
latches that must be initialized at the beginning of the testmode. Such latches would include
fixed-value latches and the latches that make up the LFSRs used in LBIST. Refer to “Unit or
Zero Delay Simulations for Testmode” on page 24 for more information about coding
sequence definitions. Also refer to “Custom Scan Sequences” on page 251.

SEQUENCE_DEFINITI = filename ;

In this statement:

filename The name of the file containing the sequence definition statements for the
testmode. If the file name starts with a slash, it is assumed to be a fully
specified path; otherwise, it is assumed a file of this name is found in the path
specified in the SEQPATH parameter.

SMARTSCANMAXSERIALPIPEDEPTH

The following statement is required in a SmartScan testmode with external pipelines. It

identifies the maximum pipeline depth on the serial path to SmartScan registers. The default
is 0.

SMARTSCANMAXSERIALPIDEPTH = depth ;

December 2019 208 Product Version 19.12

In this statement:

depth Specifies the maximum number of pipeline stages that must be

accounted for on the serial path to SmartScan registers.

TEST_REORDER

The TEST_REORDER statement specifies whether the tests are allowed to be reordered once
they leave the Modus environment. This statement is applicable only for compression
testmodes (XOR and OPMISR).
TEST_REORDER = ALL | NONE | PROCEDURE

In this statement

ALL Specifies that all the individual tests are allowed to be reordered after they
have been exported from Modus. OPMISR tests will have padding cycles as
needed and a Fix_MISR for each test allows correction of a prior test's
signature with overlap.
NONE Specifies that none of the individual tests are allowed to be reordered after
they have been exported from Modus. OPMISR padding cycles are not
computed and test signatures are computed with scan overlap and original
order assumed. This is the default for non-OPMISR compression
testmodes.
PROCEDURE Specifies that the tests are allowed to be reordered after exported from
Modus; however, reordering must be by Test_Procedure of tests in their
entirety - no reordering or dropping of tests within a Test_Procedure is
allowed. Test signatures are computed assuming that the scan of the last
test within a Test_Procedure is not overlapped with the first test of the next
Test_Prodcedure. This is the default for OPMISR testmodes.

Note: XOR output compression (without MISRs) currently supports only

TEST_REORDER=NONE.

Specifying Test Function Pin Attributes in Design Source

Test Function Pin Attributes apply to:
■ Primary Inputs (PIs) and Primary Outputs (POs)

December 2019 209 Product Version 19.12

■ Flip/Flops and Latches

■ Certain Hierarchical Blocks

The method of specifying test function pin attributes in a design source is similar to adding
any other model attribute. The attribute name is defined by you and the attribute value is one
of the Test Function Attribute Definitions.

The attribute is selected during build_testmode if the mode definition file contains the
following statement:
TEST_FUNCTION_PIN_ATTRIBUTES = <attribute name>

Note: Use attribute names of the form TB_<something> or ET_<something>. Modus

automatically saves any attributes that have this naming format. If a different name is used,
you may have to list the attribute name in an Attribute Control file on the build_model
command.

Refer to Modeling Logic Structures and Attributes in Modus : Guide 1: Models for more
information

Example 1: A Single Testmode

Verilog Design Source

module top_level (...);
...
(* ET_fullscan = "-SC" ,
ET_opmisr = "-TI" *) input reset ;
...
endmodule

Mode Definition File: myfullscan

TEST_FUNCTION_PIN_ATTRIBUTES = ET_fullscan ;

Command Example for myfullscan

build_testmode -workdir <directory> -modedefpath <directory>
-modedef myfullscan -testmode fullscan ...

When the testmode is built, primary input reset will have the test function -SC or (system
clock).

December 2019 210 Product Version 19.12

Example 2: A Second Testmode

Using the same design source, another testmode can be built using a different mode
definition file:

Verilog Design Source

module top_level (...);
...
(* ET_fullscan = "-SC" ,
ET_opmisr = "-TI" *) input reset ;
...
endmodule

Mode Definition File: myopmisr

TEST_FUNCTION_PIN_ATTRIBUTES = ET_opmisr ;

Command Example for myopmisr

build_testmode -workdir <directory> -modedefpath <directory>
-modedef myopmisr -testmode opmisr ...

When the testmode is built, primary input reset will have the test function -TI or (test inhibit).

Example 3: Multiple Attribute Names

It is possible to specify multiple attribute names in the TEST_FUNCTION_PIN_ATTRIBUTES

statement. If multiple attributes are specified, test functions associated with the first listed
attribute for a given pin are used to build the testmode. The
TEST_FUNCTION_PIN_ATTRIBUTES statement determines the order in which to search the
model for the attributes with matching names. For any pin, only the function pin attributes of
the first attribute name as identified by this search order will be applied.

However, this process has the following exceptions:

■ If a +/-BI or BDY is specified for a pin that occurs later in the search list, then that test
function is added to the pin
■ If TCK or TMS is specified after another clock test function, it overrides that clock test
function or TC
■ If TCK or TMS is specified before a clock test function, the clock test function overrides
the TCK
■ If TCK or TMS is specified before or after a TC or TI function, it is added to the test
functions for that pin

December 2019 211 Product Version 19.12

■ If TCK or TMS is specified after non-clock test functions, it overrides those test functions
except for BI and BDY which, in contradiction to exception #1, override the TMS or TCK
designation
■ Any TRST or TDI specified before TCK or TMS override them
■ CMI,CME, CMLE, and CML are not supported for the model source

Verilog Design Source

module top_level (...);
...
(* ET_fullscan = "-SC",
ET_opmisr = "-TI" *) input reset ;

(* ET_fullscan = "-SC" *) input system_clock ;

...
endmodule

Mode Definition File: myopmisr

TEST_FUNCTION_PIN_ATTRIBUTES = ET_fullscan, ET_opmisr ;

Command Example for myopmisr

build_testmode -workdir <directory> -modedefpath <directory>
-modedef myopmisr -testmode opmisr ...

When the testmode is built, primary input reset will have the test function -TI, and primary
input system_clock will have the test function -SC.

Example 4: Multiple Test Functions on One Pin

It is also possible to assign multiple attribute test functions to a single pin.

Verilog Design Source

module top_level (...);
...
(* ET_fullscan = "-SE, +TC" *) input scan_enable ;
...
endmodule

Mode Definition File: myfullscan

TEST_FUNCTION_PIN_ATTRIBUTES = ET_fullscan ;

December 2019 212 Product Version 19.12

Command Example for myfullscan

build_testmode -workdir <directory> -modedefpath <directory>
-modedef myfullscan -testmode fullscan ...

When the testmode is built, primary input scan_enable will have the test functions -SE and
+TC. During scanning, the pin will function as a scan enable with a value of 0. During test
generation, the pin will function as a test constraint held at a constant value of 1.

Tester Description Rules (TDRs)

In order to ensure that test data generated by Modus will adhere to the constraints of the
target tester on which the design is to be tested, Modus takes as input a description of the
tester's capabilities. This is called a tester description rule (TDR).

The TDR is a text file containing a simple and easily parsed set of statements that are used
to convey the tester attributes. A TDR is usually provided by the company that will be testing
the design, which is typically the chip, module or card manufacturer.

The TDR information identifying the owner of the TDR (the person or company who wrote the
TDR statements) is passed along with the test data produced by Modus to provide a contact
for the receiving manufacturer in case of any concerns about the correctness of the TDR.

The test data produced by Modus points to one and only one TDR. Therefore, if the same test
data is to be shared by two or more testers, the person creating the testmode definition must
ensure that a TDR exists that accurately describes the characteristics and limitations the test
data must comply with to be usable by all the testers. Refer to “Assign File Statements” on
page 146 for more information on testmode definition statements.

TDR Statement Syntax

The following sections describe the various statements that comprise a TDR. The
TDR_DEFINITION statement must be the first statement in the TDR, Other statements can
appear in any order. A sample TDR that you can use as a template is given in “Sample TDRs”
on page 242.

Each statement of the TDR must end with a semicolon.

The comment characters allowed in TDR statements are:

line comments:
❑ //

December 2019 213 Product Version 19.12

❑ --
❑ #
block comments:
❑ /*block of comments*/ - "/*" to start and "*/" to end block comments.
The block comments may appear any place white space may appear. The white
space is either a blank or a new line character.

Refer to the following for related information:

■ “ASSIGN” on page 147
■ “Resolving Internal and External Logic Values due to Termination” in the Modus :
Guide 5: ATPG.

SIGNATURES

The SIGNATURES statement specifies how often intermediate signatures should be

produced for LBIST. The purpose of intermediate, or "running" signatures is to support
diagnosis of failing product. This statement is optional and should be omitted if the tester does
not support signature analysis.

The syntax for the SIGNATURES statement is shown in the following figure.

December 2019 214 Product Version 19.12

Figure 6-2 SIGNATURES Statement Syntax

■ LATCHES:
Optional. This keyword is used to specify whether values for all the scannable latches
should be included in the test data. The term "scannable" refers to non-PRPG and non-
MISR latches that are scannable in the testmode.
❑ OPTional
Specifies that latch values will not be included unless requested by a run-time
parameter.
❑ None
Specifies that latch values should not be included.
❑ REQuired
Specifies that latch values are required (for diagnostics).
■ PRPG
Optional. This keyword is used to specify whether PRPG signatures are required at each
set of signatures in the test data.
❑ OPTional

December 2019 215 Product Version 19.12

Specifies that PRPG signatures can optionally be generated. This is the default if
the PRPG keyword is not specified.
❑ None
Specifies that PRPG signatures should not be generated.
❑ REQuired
Specifies that PRPG signatures are required (for diagnostics).
■ RUNning
Optional. This keyword is used to specify whether intermediate (running) signatures are
required at specific intervals in the test data. The types of intermediate signatures
produced are exactly those that are produced on final signatures, as determined by the
TDR-user setting of the PRPG and LATCHES keywords.
❑ OPTional
Specifies that running signatures may optionally be generated.
❑ None
Specifies that no running signatures should be generated.
❑ REQuired
Specifies that running signatures are required (for diagnostics).
■ MINIMUM
Optional. This keyword is used to specify the minimum number of tests (min_running) to
be applied before writing the next set of signature data. The default is one.
❑ min_running
Specifies the minimum number of tests between running signatures. The default
minimum is one.
■ MAXIMUM
Optional. This keyword is used to specify the maximum number of tests
(max_running) to be applied before outputting the next set of signature data. The
default is 2147483647.
❑ max_running
Specifies the maximum number of tests between running signatures. The default
maximum is 2147483647.

December 2019 216 Product Version 19.12

TDR_DEFINITION

The TDR_DEFINITION statement is used to identify who wrote the TDR and to which
tester(s) the TDR applies. This statement must be the first statement in the file. Up to seven
target testers can be specified. The character strings owner, target_tester, and
contact_info must each be less than 32 characters long or they will be truncated to the
first 31 characters.

If a TDR is defined that applies to multiple testers, its parameters must be specified such that
they are compatible with every tester in the set. It is up to the coder of the TDR to ensure this.
One case where this is useful is when the manufacturer wants to balance workload among
several different testers capable of testing the design.

The syntax for the TDR DEFINITION statement is shown in the following figure.

Figure 6-3 TDR_DEFINITION Statement Syntax

■ TESTER
Required. It is used to specify one or more manufacturing tester names for which test
data generated under the constraints specified in the TDR can be applied. One of the
tester names can be the reserved name PRODUCT, which implies that test data generated
for this TDR can be applied by the product (and possibly also by actual testers). For
example, chip or module self test could be applied under assumptions of both PRODUCT
and tester constraints.
❑ target_tester
A text string that identifies the tester this TDR applies to.
❑ PRODUCT
Indicates that the product itself can perform any tests which adhere to the limitations
of this TDR. This keyword is intended to be used for built-in self test (BIST), where
the design tests itself and there is no need for the tester.

December 2019 217 Product Version 19.12

■ OWNER
Required. Identifies the name or some other suitable identification of the owner.
■ (RELEASE) DATE
Required. Specify the date this TDR was last modified.
■ (RELEASE) TIME
Optional. Specify the time this TDR was last modified.
■ CONTACT
Optional. Identifies how to contact the owner; for example, address or phone.

TEST_PINS

The TEST_PINS statement is used to specify how many pins are available on the tester for
performing specific functions. It is a required statement.

The syntax for the TEST_PINS statement is shown in the following figure.

December 2019 218 Product Version 19.12

Figure 6-4 TEST_PINS Statement Syntax

■ FULL_FUNCTION_PIN_LIMIT
Required. Specifies how many full function (can be data input, data output, scan input,
scan output or a clock) pins the tester supports. This value represents the maximum
number of product pins that can be connected to the tester to have either stimulus or
measurement operations applied. For example, a 64-pin tester that supports clocks,
scan data inputs, scan data outputs or normal stim and response functions on each pin
would specify FULL_FUNCTION_PIN_LIMIT=64 to indicate that any number of clocks,
scan and data assignments can be made as long as the total number of pins contacted
is 64 or less. The total number of pins will not exceed 64 due to the assumption that there
is overlap.
■ STORED_PATTERN_DEPTH

December 2019 219 Product Version 19.12

Required. Specifies how many stimulus or response measurements can be

accommodated on any data pin in a single tester buffer load. This count can be used to
determine if the test data will fit in a single tester buffer load.
■ WEIGHT_DEPTH
The number of different weight sets that can be stored in the tester. This has meaning
only if you are using weighted random pattern testing. The default is zero.
■ CLOCK_PINS
Required. Specifies how many tester pins can deliver pulses to the product.
■ CLOCK_POLARITY
Specifies whether it is permissible for clock pins to change stability (off) polarity between
testmodes.
❑ SAME
Indicates that all clock pins must have the same stability polarity in all testmodes.
This is the default.
❑ DIFFERENT
Indicates that clock pins are allowed to have a different stability polarity in different
testmodes.
■ OSCILLATORS
Specifies the number of free-running oscillators that are supported by the tester.
■ SCAN_IN_PINS
Required. Specifies how many pins can be scan input pins. It is assumed that there can
be just as many scan output pins, provided that the FULL_FUNCTION_PIN_LIMIT
count is not exceeded. Since scan in/out pins usually require substantially more buffer
memory than data pins, some testers may place limits on the number of scan strings any
product may define. If there is no special consideration for scan I/O pins, simply use the
same value specified for FULL_FUNCTION_PIN_LIMIT.
■ STORED_PATTERN_SCAN_DEPTH
Required. Specifies how many stored pattern scan in or scan out values a single scan
pin can support within a single tester buffer load. This count can be used to determine if
the test data will fit in a single tester buffer load.
■ WEIGHT_SCAN_DEPTH

December 2019 220 Product Version 19.12

This relates to the size of the tester's memory that is usable for storing weights on a scan
data input pin. This number, divided by the length of the longest scan chain on the
product, gives an upper bound on the number of weight sets that can be stored on the
tester. num_scanin_weights is another bound on the number of weight sets. These
parameters are used only if you are doing weighted random pattern testing. The default
is zero.
■ PARAMETRIC_MEASURE_UNITS:
The number of parametric measurement units (PMUs) to be assumed by Modus
processing. This parameter is significant only if (a) driver & receiver testing is being
performed, or (b) the number of full-function pins is less than the number of active pins
on the product and static logic testing is being performed. In the latter case, most testing
should be done in a boundary scan (internal) testmode in which only the test function
pins need to be contacted. The PARAMETRIC_MEASURE_UNITS parameter limits the
number of data pins that can be stimulated or measured within the same test pattern.
The default is 4294967295 (2 to the 32nd power minus 1). It should be noted that Modus
always assumes that a full-function pin is capable of making parametric measurements,
so PARAMETRIC_MEASURE_UNITS should always be equal to or greater than
FULL_FUNCTION_PIN_LIMIT.
Modus has three types of support in relation to PMUs, which apply only to static logic
testing and driver/receiver testing. In defining the conditions where these types of
support apply, we assume that PARAMETRIC_MEASURE_UNITS =
FULL_FUNCTION_PIN_LIMIT.
❑ If PARAMETRIC_MEASURE_UNITS >= the number of product pins, then Modus
assumes all product pins can be contacted simultaneously. Otherwise:
❍ If PARAMETRIC_MEASURE_UNITS = FULL_FUNCTION_PIN_LIMIT,
then Modus assumes that non-test function attributed pins cannot be
contacted at all; and
❍ If PARAMETRIC_MEASURE_UNITS > FULL_FUNCTION_PIN_LIMIT,
then Modus assumes all test function attributed pins can be contacted and
only one non-test function attributed pin can be contacted at a time.
■ PMU_CAPACITY
The total number of pins that can be contacted by PMUs (see
PARAMETRIC_MEASURE_UNITS). These two parameters are different in the tester
where some PMUs can be multiplexed to different pins. Note that PMU_CAPACITY is not
the number of pins that can be simultaneously contacted by PMUs, but the total number
that can be accessed by PMUs. PMU_CAPACITY should be equal to or larger than
PARAMETRIC_MEASURE_UNITS. This parameter is optional; it defaults to the value of
the PARAMETRIC_MEASURE_UNITS parameter.

December 2019 221 Product Version 19.12

OSCILLATOR_PULSES_PER_TESTER_CYCLE

Some testers are capable of delivering multiple pulses on the same pin during a tester cycle.
This capability is useful for driving oscillator inputs to the design under test. Modus exploits
this by the oscillator events in TBD (Start_Osc, Wait_Osc, Stop_Osc). This parameter tells
how many oscillator pulses the tester is capable of producing on a single pin during each
tester cycle.

If the tester (or test compiler) does not support the synchronous oscillators as described
above, then code 0 for this parameter. If the tester can support several different numbers of
oscillator pulses per tester cycle, enter the list of numbers supported.

The syntax for the OSCILLATOR_PULSES_PER_TESTER_CYCLE statement is shown in

the following figure.

Figure 6-5 OSCILLATOR_PULSES_PER_TESTER_CYCLE Statement Syntax

■ integer
Specifies the number of pulses the tester can deliver on an oscillator pin in each tester
cycle. This must be a non-negative integer. Specify a list of one or more positive integers
if the tester has the flexibility to supply a variable number of oscillator pulses per tester
cycle. Specify 0 to indicate that the tester or test compiler does not support synchronous
oscillators. The integer list is required if this statement is used, but if the statement is
missing the default is 1.

TERMINATION

The syntax for the TERMINATION statement is shown in the following figure. See section
Termination Values in Modus: Guide 1: Models for related information.

December 2019 222 Product Version 19.12

Figure 6-6 TERMINATION Statement Syntax

■ TERMINATION
The TERMINATION statement is used to specify the tester's capabilities for terminating
three-state (high- impedance) outputs and bidirectional pins. It is also used to specify
what value should be propagated to internal nets from a bidirectional pin when the tester
is not driving and all three-state product drivers for that pin are at high-impedance. It is a
required statement.
❑ ZERO
Indicates that the tester can provide termination to zero.
❑ ONE
Indicates that the tester can provide termination to one.
Note: If both ZERO and ONE are specified, then the tester can terminate such pins
to either ZERO or ONE (but only one at a time).
❑ NONE
Indicates that the tester cannot provide termination to either zero or one.
■ DOMINANCE
Indicates whether tester supplied termination should be applied to pins which already
have product termination, and if so, which will dominate. Dominance applies only when
the tester can provide termination. It is optional.
❑ TESTER
Indicates that tester-supplied termination is applied to all three-state output pins
regardless of any product-supplied value for a pin. This is the default if DOMINANCE
is not specified.
❑ PRODUCT

December 2019 223 Product Version 19.12

Indicates that tester-supplied termination is applied only to pins without product-

supplied termination.
■ INTERNALLY_SEEN
Specifies whether the resolved termination value for an external three-state net should
be propagated into the internal (receiver) logic for bidirectional three-state pins, or that
an unknown, pessimistic assumption should be made. The default is to use termination
if there is any.
❑ TERMINATION
Specifies that internal logic should use the terminated value for a high impedance
(Z) on an external three-state net. This is the default if INTERNALLY_SEEN is not
specified.
❑ X
Specifies that even if an external three-state net has termination on it, a pessimistic
assumption should be made that forces a high impedance (Z) to be seen as an
unknown (X) value by the internal (receiver) logic.
Note: Specifying DOMINANCE=PRODUCT will override this behavior.

MEASURE

The MEASURE statement is used to specify certain measure options for producing the test
data. It is a required statement.

The syntax for the MEASURE statement is shown in the following figure.

December 2019 224 Product Version 19.12

Figure 6-7 MEASURE Statement Syntax

■ EXPLICIT
Optional. This keyword governs the extent to which primary output measure data is
written to the test data output of Modus . Primary output measures are not taken at the
tester except as requested by the test data. With EXPLICIT=YES, the default, measures
are written to the test data output only for those patterns for which output measures are
explicitly requested by either automatic test generation or by Measure_PO events in
manually generated test vectors. With EXPLICIT=NO, primary output measures will be
written for all patterns containing no scan activity, regardless of whether a primary output
was specifically targeted for fault detection. Specifying NO can significantly increase test
data volume over YES.
■ CURRENT
Specifies the maximum number of IDDq current measurement test vectors that should
be provided. The default value of zero indicates that the tester does not support IDDq
measurement of current.
■ PO
Optional.
Specify which measures to produce on POs during fault simulation. Specify faultdetect
to produce measures only on POs that detect faults. Specify all to produce measures on
all POs regardless of fault detection.
The default is all except for:
❑ driver/receiver tests

December 2019 225 Product Version 19.12

❑ logic tests where the number of active logic pins is greater than the full function pin
limit on the TDR
For the above two cases, the option is ignored and measures are produced only on POs
that detect faults.
■ HIGH_Z
Required. This keyword is used to specify how high-impedance (Z) values are to be
measured by the tester:
❑ TERM
Specifies that the product or tester termination (see the TERMINATION statement)
should be used to convert high_Z values into logic zero or one values.
❑ Z
Specifies that regardless of product or tester termination, if all three-state drivers
feeding a product I/O pin are inhibited, the measure response should be Z (high
impedance).
❑ X_OR_TERM
Specifies that the product or tester termination (see the TERMINATION statement)
should be used to convert high_Z values into logic zero or one values if termination
exists on the PO pad. Otherwise, X (unknown) should be measured. In case of no
termination, the value of Z will be measured as X (unknown).
❑ X
Specifies that regardless of product or tester termination, if all three-state drivers
feeding a product I/O pin are inhibited, the measure response should be X
(unknown).
■ DIAGNOSTIC_MEASURES
Specify a fault coverage percentage threshold that, when attained, test generation will
discontinue keeping diagnostic Scan_Unload events. The default is 100.
The default implies the test data will carry precomputed diagnostic expects.

PIN_TIMING

The PIN_TIMING statement is used to specify information about the timing capabilities, both
hardware and software, of the manufacturer's testers. All times are specified by a decimal
followed by ps, ns, us, ms or s. The smallest resolution is a picosecond (ps). For example, 2.5
ps resolves to 3 ps.

December 2019 226 Product Version 19.12

If the PIN_TIMING statement is not included in the TDR, timings can still be generated.
However, all the time and number fields are considered to be zero. Therefore, the
PIN_TIMING parameters that should be active must be specified at runtime.

The syntax for the PIN_TIMING statement is shown in the following figure.

Figure 6-8 PIN_TIMING Statement Syntax

■ TIMING_RESOURCE
Specify either PER_PIN or SHARED_RESOURCE.
❑ PER_PIN

December 2019 227 Product Version 19.12

Specify this option to indicate that the tester has timing capabilities that allow each
of its pins to be timed independently.
❑ SHARED_RESOURCE.
Specify this option to indicate that the tester does not have timing capabilities on
every pin, so individual timing generators must be shared across pins.
The timing generators are classified by Modus according to the type of product pins they
contact. The types are clocks (pins attached to pulse generators), non-clocks, and
Primary Outputs (POs). Within each group there is a maximum number of generators
allowed.
For example, if there are four product clocks and two timing generators, Modus may
relate two clocks to one pulse generator and two to the other or three to one pulse
generator and one to the other.
Note: When specifying the shared-resource pin counts, you should take the following
into consideration:
❑ The tester capabilities
❑ The capabilities of the software that generates the tester program from Modus
output
For example, the software-hardware interaction may require that you reserve a certain
number of pulse generators for scanning. These generators will not be included in the
clock count.
❑ CLOCKS
Required.
Specify the number of independently timed clock groups allowed to be pulsed during
the tester cycle.
❑ NON_CLOCKS
Required.
Specify the number of independently timed groups of non-pulsed pins allowed in the
tester cycle. This includes non-clock pins, as well as clock pins that are not pulsed.
❑ PO_STROBES
Required.
Specify the number of independently timed groups of measures allowed on the
output pins of the product.

December 2019 228 Product Version 19.12

■ MAX_PULSES
Required.
Specify the maximum number of pulses (pair of edge changes on a product input pin) on
a single pin during the tester cycle. Refer to the following example:

■ MAX_STIMS
Required.
Specify the maximum number of stims (single edge change on a product input pin) on a
single pin during the tester cycle. Refer to the following example:

■ MAX_MEASURES
Required.
Specify the maximum number of measures on a product output pin during the tester
cycle.
■ MAX_CYCLE_TIME
Required.

December 2019 229 Product Version 19.12

Specify the maximum tester cycle time.

■ MIN_CYCLE_TIME
Required.
Specify the minimum tester cycle time. Refer to the following example:

■ MAX_PULSE_WIDTH
Required.
Specify the maximum duration of a tester pulse.
■ MIN_PULSE_WIDTH
Required.
Specify the minimum duration of a tester pulse. This parameter applies in the absence
of an explicit clock or high function receiver min pulse width specifications, e.g,
AC_MIN_PULSE_WIDTH. This value should take into account tester and technology
capabilities and requirements.
■ AC_MIN_PULSE_WIDTH
Optional.
Specify the minimum duration of A_SHIFT_CLOCK (EC1) pulses. In the absence of this
value the MIN_PULSE_ WIDTH value will be used for all A_SHIFT_CLOCKs. If a PI is
both an A_SHIFT_CLOCK and a C-clock, the larger width specification will be used.
■ BC_MIN_PULSE_WIDTH
Optional.
Specify the minimum duration of B_SHIFT_CLOCK (EC2) pulses. In the absence of this
value the MIN_PULSE_ WIDTH value will be used for all B_SHIFT_CLOCKs. If a PI is
both a B_SHIFT_CLOCK and a C-clock, the larger width specification will be used.

December 2019 230 Product Version 19.12

■ SC_MIN_PULSE_WIDTH
Optional.
Specify the minimum duration of C-clock pulses. In the absence of this value the
MIN_PULSE_ WIDTH value will be used for all C-clocks. If a PI is both a C-clock and
either an A_SHIFT_CLOCK (EC1), B_SHIFT_CLOCK (EC2), or E-clock, the larger width
specification will be used.
■ EC_MIN_PULSE_WIDTH
Optional.
Specify the minimum duration of E-clock pulses. In the absence of this value the
MIN_PULSE_ WIDTH value will be used for all E-clocks. If a PI is both an E-clock and a
C-clock, the larger width specification will be used.
■ HF_MIN_PULSE_WIDTH
Optional.
Specify the minimum duration of a pulse which can be propagated by the high function
receivers. High function receivers are identified in the technology rule by the
HF_MIN_PULSE_WIDTH attribute on the receiver's input pin. In the absence of this
value, the MIN_PULSE_WIDTH value will be used for all high function receivers. If a high
function receiver is also a clock (AC, BC, SC, or EC), the clock minimum pulse width
value, if specified, will override this value.
■ MIN_PULSE_OFF
Required.
Specify the minimum time between pulses on the same pin. Refer to the following
example:

December 2019 231 Product Version 19.12

■ MIN_TIME_LEADING_TO_LEADING
Required.
Specify the minimum time between the leading edge of a pulse and the leading edge of
the next pulse on the same pin. Refer to the following example:

■ MIN_TIME_TRAILING_TO_TRAILING
Required.
Specify the minimum time between the trailing edge of a pulse and the trailing edge of
the next pulse on the same pin. Refer to the following example:

■ MIN_STIM_STABLE
Required.

December 2019 232 Product Version 19.12

Specify the minimum time that a non-clock pin must be stable before another event can
be applied to that pin. Refer to the following example:

■ ACCURACY
Required.
Specify the tester tolerance or difference in time (+ or -) between when an edge is
programmed to arrive and when it actually arrives at the product. Refer to the following
example:

■ RESOLUTION
Required.

December 2019 233 Product Version 19.12

Specify the smallest increment of time within the tester cycle. All edges must be placed
at multiples of this increment. Refer to the following example:

■ LEADING_PADDING
Required.
Specify the minimum time required between the beginning of a tester cycle and an edge
of a signal. Refer to the following example:

■ TRAILING_PADDING
Required.

December 2019 234 Product Version 19.12

Specify the minimum time required between the last signal edge and the end of the tester
cycle. Refer to the following example:

■ TERM_TIME_TO_1
Required if the tester supports termination.
Specify the longest time it takes for tester termination to pull a signal from high
impedance to a stable logic one. Refer to the following example:

■ TERM_TIME_TO_0
Required if the tester supports termination.
Specify the longest time it takes for tester termination to pull a signal from high
impedance to a stable logic zero.

December 2019 235 Product Version 19.12

■ STROBE_SETUP
Required.
Specify the minimum time data must be stable before the tester PO is strobed. Refer to
the following example:

■ STROBE_HOLD
Required.
Specify the minimum time after a PO is strobed that the data must be kept stable. Refer
to the following example:

■ MIN_SCAN_CYCLE_TIME
Required.
Specify the minimum tester cycle when scanning. This is a complete shift cycle (i.e., A-
E-B for GSD).
■ MIN_SCAN_PULSE_WIDTH

December 2019 236 Product Version 19.12

Required.
Specify the minimum pulse duration allowed for the scan clocks.
■ DC_CYCLE_TIME
Required.
Specify the size of the static cycles when timings are not generated. This is used when
there is no timing information on the product to generate timing data and for the
generation of timeplates during WGL Export.
■ DC_PULSE_WIDTH
Required.
Specify the pulse duration to be used when no timing information exists for the clock and
for the generation of timeplates during WGL Export.
■ CONTACTED_DRIVER_RECEIVER_DELAY
Optional.
Specify a delay duration. This parameter accounts for the additional delay across tester-
contacted Common Input/Output (CIO) pins. The extra delay is caused by the additional
RC of the probe and tester circuitry. Refer to the following example:

DELAY_PROCESSING

The DELAY_PROCESSING statement is used to specify information about how the delays
are to be processed by the delay calculator and the Modus Timing Tool.
DELAY_CALC_MODE and TESTER_CONDITIONS affect the delay calculation, and the
CLOCK_GATING keywords affect the Modus processing.

December 2019 237 Product Version 19.12

All times are specified by a positive decimal followed by ps, ns, us, ms or s. The VTT and VDD
values should be positive integers in terms of volts. The TEMP values should be positive
integers in terms of Centigrade.

The character string name must be less than 32 characters long or it will be truncated to the
first 31 characters.

If the DELAY_PROCESSING statement is not included in the TDR, a delay model can still be
generated and timing generation can still be performed. The parameters must be specified at
runtime.

The syntax for the DELAY_PROCESSING statement is shown in the following figure.

Figure 6-9 DELAY_PROCESSING Statement Syntax

■ DELAY_CALC_MODE
Required.
This specifies what portion of the delay rules the delay calculator should use to generate
the delays.

December 2019 238 Product Version 19.12

Specify one of the following:

■ ACTEST
This option tells the delay calculator to use the delay test portion of the delay rules. This
is needed since not all modes of the rules specify the paths within technology cells that
are used just during test.
■ SIM
If there are special modes within the rules used just for simulation these modes should
be used during the calculation.
■ NORMAL
This option specifies to generate the delays for the timing analysis tool. This uses the
default mode of the delay rules.
■ TESTER_CONDITIONS
Required.
This specifies the conditions under which the product will be tested. Each set of
conditions is given a name. For example, if scan chain tests and logic tests are run under
different conditions (i.e., scan chain test is run with Vdd = 3.0 volts TEMP = 85 C and
logic test is run with Vdd = 5.0 volts TEMP = 100 C), there will be a condition name for
the scan chain tests (for example, SRT) and a condition name for the logic tests (for
example, LOGIC). The condition name can be anything, but it is recommended that it
relate to the type of test being run. A DELAY_PROCESSING statement can have a
maximum of four TESTER_CONDITIONS attributes specified.
■ TEST_TYPES
This is the type(s) of tests the delays can be used for. There can be multiple conditions
that relate to a single TEST_TYPES.
■ VDD
Required.
Specify the voltage at which the product will be tested.
■ TEMP
Required.
Specify the temperature in Celsius at which the product will be tested.
■ VTT

December 2019 239 Product Version 19.12

Optional.
Specify the second power supply voltage at which the product will be tested.
■ CLOCK_GATING_HOLD
Required.
Specify the length of time that a gating signal must be stable after the trailing edge of a
clock pulse has arrived at another input of the same gate.
■ CLOCK_GATING_SETUP
Required.
Specify the length of time that a gating signal must be stable before the leading edge of
a clock pulse arrives at a clock gate.
■ CLOCK_GATING_PULSE_WIDTH
Required.
Specify the minimum duration of a clock pulse to propagate through a gate.

SCAN_REQUIREMENTS

SCAN_REQUIREMENTS is an optional statement present only if there are specific stim and
measure capabilities placed on the scan chains of the part.

The syntax for the SCAN_REQUIREMENTS statement is shown in the following figure.

December 2019 240 Product Version 19.12

Figure 6-10 SCAN_REQUIREMENTS Statement Syntax

Specify the types of SCAN_CHAINS which are acceptable. More than one type can be
specified. Any type not specified is unacceptable.
■ CONTROLLABLE_AND_OBSERVABLE
Scan chains which are both controllable and observable are acceptable. This is the
default.
■ CONTROLLABLE_ONLY
Scan chains which are only controllable are acceptable.
■ OBSERVABLE_ONLY
Scan chains which are only observable are acceptable.

Specify the type of SCAN_SEQUENCE that is acceptable.

■ SINGLE_VECTOR
A single vector scan sequence is the default.
■ MULTI_VECTOR

December 2019 241 Product Version 19.12

A multi-vector scan sequence is acceptable.

Sample TDRs
The following are example TDRs that illustrate how the statements might be coded.
/************************************************************/
/* Sample TDR */
/************************************************************/
TDR_Def
OWNER = "Owner Name"
DATE = yyyy/mm/dd
TESTER = "Dummy"
CONTACT = "Contact Name"
;

/* The TEST_PINs statement identifies the test pin resources that */

/* are available for the specified tester. Modus uses this */
/* information to determine if the circuit uses more resources than */
/* are available on the target tester. */

TEST_PINS
FULL_FUNCTION_PIN_LIMIT = 4096
STORED_PATTERN_DEPTH = 1000000
CLOCK_PINS = 64
SCAN_IN_PINS = 256
STORED_PATTERN_SCAN_DEPTH = 16383
;

/* The TERMINATION statement tells Modus whether the tester can */

/* provide a termination value for 3-state primary output or */
/* bidirectional pins. It also indicates whether the tester’s */
/* supplied termination will dominate any termination that may exist */
/* on the product. */

TERMINATION
ZERO, ONE
DOMINANCE = TESTER
INTERNALLY_SEEN = X
;
/* The MEASURE statement tells Modus how a high impedence (Z) */
/* should be measured by the tester. Either the tester will measure */
/* the value as resolved by the application of product and/or tester */
/* termination, or it will measure Z regardless of the termination. */

MEASURE
HIGH_Z = Z

/************************************************************/
/* Sample TDR for Delay Test */
************************************************************
TDR_Def
OWNER = "Owner Name"
DATE = yyyy/mm/yy
TESTER = "Dummy"
CONTACT = "Contact Name"
;

December 2019 242 Product Version 19.12

TEST_PINS
FULL_FUNCTION_PIN_LIMIT = 4096
STORED_PATTERN_DEPTH = 1000000
CLOCK_PINS = 64
SCAN_IN_PINS = 256
STORED_PATTERN_SCAN_DEPTH = 16383
PARAMETRIC_MEASURE_UNITS = 4096
;
TERMINATION
ZERO, ONE
DOMINANCE = TESTER
INTERNALLY_SEEN = X
;
MEASURE
HIGH_Z = Z
EXPLICIT = YES
CURRENT = 20
;

PIN_TIMING
TIMING_RESOURCE=SHARED_RESOURCE CLOCKS=2 NON_CLOCKS=2 PO_STROBES=1
MAX_PULSES = 1
MAX_STIMS = 1
MAX_MEASURES = 1
MAX_CYCLE_TIME = 1 MS
MIN_CYCLE_TIME = 10 NS
MAX_PULSE_WIDTH = 100 NS
MIN_PULSE_WIDTH = 5 NS
HF_MIN_PULSE_WIDTH = 2.5 NS
MIN_PULSE_OFF = 2 NS
MIN_TIME_LEADING_TO_LEADING = 10 NS
MIN_TIME_TRAILING_TO_TRAILING = 10 NS
MIN_STIM_STABLE = 2 NS
ACCURACY = 200 PS
RESOLUTION = 25 PS
LEADING_PADDING = 0 S
TRAILING_PADDING = 0 S
TERM_TIME_TO_1 = 50 NS
TERM_TIME_TO_0 = 75 NS
STROBE_SETUP = 100 PS
STROBE_HOLD = 300 PS
MIN_SCAN_CYCLE_TIME = 40 NS
MIN_SCAN_PULSE_WIDTH = 10 NS
DC_CYCLE_TIME = 200 NS
DC_PULSE_WIDTH = 50 NS
;

DELAY_PROCESSING
DELAY_CALC_MODE = ACTEST
TESTER_CONDITIONS = "Scan Chain Test"
TEST_TYPES=SR VDD = 3.0 TEMP = 20
TESTER_CONDITIONS = "Logic_&_Array_Test"
TEST_TYPES=LOGIC TEST_TYPES=MACRO
VDD = 5.0 TEMP = 60
CLOCK_GATING_HOLD = 500 PS
CLOCK_GATING_SETUP = 250 PS
CLOCK_GATING_PULSE_WIDTH = 2 NS

December 2019 243 Product Version 19.12

Boundary Scan Design Language

BSDL is recommended by the IEEE 1149.1 standard to specify boundary scan. This section
describes methods for:
■ “BSDL Extension - Port Alias” on page 244
■ “BSDL Extension for Identifying Image Unwired Ports” on page 246

Important
Do not use device names with binary patterns in BSDL as it will result in syntax
errors when running the verify_11491_boundary command. For example, using
“entity x1 is” will cause a syntax error.

BSDL Extension - Port Alias

Modus applications which use BSDL (Boundary Scan Description Language) require that the
BSDL port names correlate with the Modus model pin names. The Test_Port_Alias
BSDL extension allows you to correlate differently named ports that are logically the same,
without having to change the port names in the BSDL or the pin names in the design source.
For example, if the BSDL port name is CLK and the corresponding pin name in the Modus
model is AA100AA0[0], then you can include the following port alias statement in the BSDL
to enable Modus 1149.1 applications to make the name correlation:
attribute Test_Port_Alias :BSDL_EXTENSION;
attribute Test_Port_Alias of <entityname>: entity is
"CLK :AA100AA0[0]";

Note: no spaces are allowed in the Test_Port_Alias string.

Sample BSDL File

This sample BSDL has a Test_Port_Alias statement near the bottom of the file.
entity ttl74bct8374tda is generic (PHYSICAL_PIN_MAP : string := "DW_PACKAGE");

port (CLK:in bit; Q:out bit_vector(1 to 8); D:in bit_vector(1 to 8);

GND, VCC:linkage bit; OC_NEG:in bit; TDO:out bit; TMS, TDI, TCK:in bit);

use STD_1149_1_1990.all; -- Get Std 1149.1-1990 attributes and definitions

attribute PIN_MAP of ttl74bct8374tda : entity is PHYSICAL_PIN_MAP;

constant DW_PACKAGE:PIN_MAP_STRING:="CLK:1, Q:(2,3,4,5,7,8,9,10)," &

"D:(23,22,21,20,19,17,16,15)," &
"GND:6, VCC:18, OC_NEG:24," &
"TDO:11, TMS:12, TCK:13, TDI:14";

December 2019 244 Product Version 19.12

constant FK_PACKAGE:PIN_MAP_STRING:="CLK:9, Q:(10,11,12,13,16,17,18,19)," &

"D:(6,5,4,3,2,27,26,25)," &
"GND:14, VCC:28, OC_NEG:7," &
"TDO:20, TMS:21, TCK:23, TDI:24";

attribute TAP_SCAN_IN of TDI : signal is true;

attribute TAP_SCAN_MODE of TMS : signal is true;
attribute TAP_SCAN_OUT of TDO : signal is true;
attribute TAP_SCAN_CLOCK of TCK : signal is (20.0e6, BOTH);

attribute INSTRUCTION_LENGTH of ttl74bct8374tda : entity is 8;

attribute INSTRUCTION_OPCODE of ttl74bct8374tda : entity is

"BYPASS (11111111, 10001000, 00000101, 10000100, 00000001)," &
"EXTEST (00000000, 10000000)," &
"SAMPLE (00000010, 10000010)," &
"INTEST (00000011, 10000011)," &
"HIGHZ (00000110, 10000110)," & -- Boundary Hi-Z
"SETBYP (00000111, 10000111)," & -- Boundary 1/0
"CELLTST(00001100, 10001100)," & -- Boundary selftest normal
"SCANCN (00001110, 10001110)," & -- BCR Scan normal
"SCANCT (00001111, 10001111)"; -- BCR Scan test

attribute INSTRUCTION_CAPTURE of ttl74bct8374tda : entity is "10000001";

attribute REGISTER_ACCESS of ttl74bct8374tda : entity is

"BOUNDARY (CELLTST)," &
"BYPASS (SETBYP)," &
"BCR[2] (SCANCN, SCANCT)"; -- 2-bit Boundary Control Register

attribute BOUNDARY_REGISTER of ttl74bct8374tda : entity is

-- num cell port function safe [ccell disval rslt]
"17 (BC_1, CLK, input, X)," &
"16 (BC_1, OC_NEG, input, X)," & -- Merged Input/Control
"16 (BC_1, *, control, 1)," & -- Merged Input/Control
"15 (BC_1, D(1), input, X)," &
"14 (BC_1, D(2), input, X)," &
"13 (BC_1, D(3), input, X)," &
"12 (BC_1, D(4), input, X)," &
"11 (BC_1, D(5), input, X)," &
"10 (BC_1, D(6), input, X)," &
"9 (BC_1, D(7), input, X)," &
"8 (BC_1, D(8), input, X)," &
"7 (BC_1, Q(1), output3, X, 16, 1, Z)," & -- cell 16 @ 1 -> Hi-Z.
"6 (BC_1, Q(2), output3, X, 16, 1, Z)," &
"5 (BC_1, Q(3), output3, X, 16, 1, Z)," &
"4 (BC_1, Q(4), output3, X, 16, 1, Z)," &
"3 (BC_1, Q(5), output3, X, 16, 1, Z)," &
"2 (BC_1, Q(6), output3, X, 16, 1, Z)," &
"1 (BC_1, Q(7), output3, X, 16, 1, Z)," &
"0 (BC_1, Q(8), output3, X, 16, 1, Z)";

attribute Test_Port_Alias:BSDL_EXTENSION;

attribute Test_Port_Alias of ttl74bct8374tda: entity is

"CLK:TestClkPort," &
"Q(1):TestportQ1," &
"Q(2):TestportQ2," &
"Q(3):TestportQ3," &
"Q(4):TestportQ4," &
"Q(5):TestportQ5," &

December 2019 245 Product Version 19.12

"Q(6):TestportQ6," &
"Q(7):TestportQ7," &
"Q(8):TestportQ8," &
"D(1):TestportD1," &
"D(2):TestportD2," &
"D(3):TestportD3," &
"D(4):TestportD4," &
"D(5):TestportD5," &
"D(6):TestportD6," &
"D(7):TestportD7," &
"D(8):TestportD8," &
"GND:TestportGND," &
"VCC:TestportVCC," &
"OC_NEG:TestportOC_NEG," &
"TDO:TestportTDO," &
"TMS:TestportTMS," &
"TDI:TestportTDI," &
"TCK:TestportTCK";

end ttl74bct8374tda;

BSDL Extension for Identifying Image Unwired Ports

The purpose of the Test_Image_Unwired BSDL extension is to identify logical ports which
have no connection to any physical pins and to exempt them from Modus 's model to BSDL
correlation checking. An image unwired port is a primary input/output pin in the top cell of the
logic model that has no connection to a physical pin. An image unwired port appears in the
logic model but does not appear in the logical port statement nor in any physical pin map
statement appearing in a particular BSDL file. The port names appearing in the
Test_Image_Unwired BSDL extension must be Modus logic model pin names in simple
(short) name form (consistent with other Modus BSDL extensions).
attribute Test_Image_Unwired: BSDL_EXTENSION;

attribute Test_Image_Unwired of <entity name>: entity is

"<TB pin name>, " & -- port not required in BSDL
"<TB pin name>, " &
"<TB pin name>, " &
"<TB pin name> ";

December 2019 246 Product Version 19.12

Sequence Definition File (Optional)

The sequence definition file is used to define special sequences to Modus. During
build_testmode the mode initialization and scan sequences may be automatically
generated from the specification of the test structures in the input Mode Definition, Assign
File, and/or BSDL. In some cases, such as when using OPCG, you need to define your own
initialization and/or scan sequences. The following sections provide some information on
creating these sequences.

Mode Initialization Sequences

The risks of producing bad test data are minimized when the product operates synchronously,
under the control of one or more specific clock signals. Modus exercises proper control of the
clock signals to avoid races.

When the product has more than one mode of operation, the static signals that control or
select the operational mode have to be controlled carefully to avoid unpredictable behavior.
The control signals may be required to be set only during certain times, such as when a scan
operation is being applied; but sometimes control signals (TEST_INHIBITs) are used to
deactivate a function that is inherently asynchronous or not tractable for automatic test
generation. In the latter case, the control signals may have to be held fixed throughout all
testing operations in a given mode. Such static control signals may be accessible as primary
inputs or they may be implemented as fixed-value latches to avoid allocating precious
package pins for this purpose.

Yet another consideration in ensuring valid test patterns is the need to avoid three-state
contention--the application of conflicting signals to multi-source nets where the conflict could
damage the product. This is commonly the case when multiple CMOS drivers are connected
to a bus; damage may occur if two or more drivers are simultaneously given control of the bus.

Requirements of Initialization Sequences

The foregoing considerations lead to the requirement for an initializing sequence (sequence
type=modeinit) for each testmode, which:
■ Initializes any fixed value latches. It may also set an initial state for other latches such as
PRPG, MISR, or Floating Latches.
■ Leaves all clock signals at their stability values.
■ Establishes the necessary state of any primary inputs required to be held at fixed values
during test generation. These are the Test Inhibit (TI) and Test Constraint (TC) pins.

December 2019 247 Product Version 19.12

■ Leaves the design in a quiescent state, the Test Constraint and Clocks Off state, that is
devoid of three-state conflicts, and does all the foregoing without causing three-state
contention along the way.

Refer to Sequence Definition Application Objects in the Modus : Reference: Test Pattern
Data Format for additional information.

Automatically Generated Initialization Sequence

In the absence of a custom (user specified) mode initialization sequence, Modus will
automatically generate one and attach it to each test vector. Before relying on Modus to
generate the modeinit sequence, however, you must first realize that there are certain
circumstances that require an externally specified modeinit sequence. One example is any
test protocol that requires a parent mode for latch initialization. This is generally the case for
LBIST. Modus cannot automatically decide when an externally specified mode initialization
sequence is required; it is up to you to make that call, based on an understanding of your test
requirements and the automatic generation process. Refer to Writing an Initialization
Sequence on page 249 for additional information.

The automatically generated mode initialization sequence consists of a pattern which does
the following:
1. Sets all three-state pins to high-Z unless all internal drivers for that I/O are found to be
inhibited by either directly tying the driver's enable to ground or by applying just the TI test
function pins (applied below).
2. Sets all Scan Enable (SE, SGI, SGO) pins to their scan state value, unless set to a value
as defined below if it is also a TC test function pin. Just to be safe, if the scan enable is
3-state and the strong drivers are not all inhibited, the pin is set to Z as denoted in step 1.
3. Sets all TI and TC test function pins to their stability values.

1149.1 consideration
If this is an 1149.1 testmode then note the following:
■ The 1149.1 compliance enable pins, if any, are included among the set of TI pins. This
comes about as a natural consequence of their having been assigned the TI test
function attribute.
■ The TRST pin, if any, has the additional test function attribute of +TI assigned to it and
will therefore be set to a logic 1 by this pattern. This is its inactive state.

December 2019 248 Product Version 19.12

1. Sets all clock test function pins to their stability (OFF) values.
2. Sets the TMS pin to logic 1 if the testmode is 1149.1.

Following the above pattern, if the testmode is 1149.1, then patterns are added to the
modeinit sequence to bring the TAP controller to the Test-Logic-Reset state, either
asynchronously, if there is a TRST pin present, or through synchronous pulsing of the TCK
pin, if there is no TRST pin.

If this is an 1149.1 testmode with a TAP_TG_STATE and instruction(s) specified in the mode
definition file, there are additional patterns included which will load the 1149.1 instruction
register and then move the TAP finite state machine to the specified TAP_TG_STATE. If there
are multiple instructions associated with multiple scan chains and scan sections, the modeinit
sequence will load only the last instruction.

Writing an Initialization Sequence

There are testing scenarios for which the automatically generated mode initialization
sequence is inadequate. One case in particular where this is true is when there are memory
elements (RAM or latches) that must be initialized before beginning operations in a testmode,
and then Modus requires that the initialization sequence be given as an input file, called the
Sequence Definition File, to Build Testmode. Without your specifying the initialization
sequence, Modus has no way to know that some memory elements have to be pre-initialized
(except for the pattern generator and signature registers used in LBIST).

Also, if there are pseudo primary inputs defined in this testmode with clock, TI, or TC
attributes, then it is almost certain that a user-defined mode initialization sequence is
required, for Modus would not know how to get the required values on those internal nets
that are represented by the pseudo PIs.

The initialization sequence is specified as a Define_Sequence block in TBDpatt format. For

details on sequence definition, refer to Sequence Definition Application Objects in the Modus
: Reference: Test Pattern Data Format. You have complete flexibility in how the initialization
is performed, but for convenience it is recommended you switch to a different testmode in
which the latches are scannable whenever it is feasible to do so. If this is the case, you can
follow these steps:
1. Create a “parent” testmode. This is the testmode in which you will perform scan
operations to initialize the latches for the target testmode.
2. Create the TBDpatt file with the initialization sequence for the new testmode, specify the
file name in your testmode definition, and run build_testmode. To create this TBDpatt
file, use a text editor of your choice.

December 2019 249 Product Version 19.12

Before you create the initialization sequence, you must be familiar enough with the design to
know which latches must be initialized, and to what values they must be set. If you did not
create the design, you may need to contact the designer or look for some design
documentation that will identify the LBIST pattern generator, signature register, fixed-value
latches, and any other latches requiring special attention.

When you are ready to create the TBDpatt file, it may be helpful to first run the Create Vector
Correspondence tool in the parent testmode. This produces a file, TBDvect.
parentmodename, in the directory that contains the imported design. This file contains a
list of all the scannable latch names. Copy this list into the TBDpatt file you are creating,
eliminating those latches that you do not need to initialize. You will then need to do further
editing to specify the latch values and put it into correct TBDpatt syntax. The syntax and
structure of an initialization sequence are illustrated in Example 6-1. The example design has
a total of 50 latches, including a four-bit PRPG, a four-bit MISR, and one master-slave latch
pair. Only these nine latches needed to be mentioned in the initialization sequence for this
case.

Example 6-1 An Example Testmode Initialization Sequence in TBDpatt Format

# Mode Initialization sequence for an LBIST testmode
TBDpatt_Format (mode=node,model_entity_form=name);
[Define_Sequence INIT (modeinit);
[Pattern 1 (pattern_type = static);
Event 1 Begin_Test_Mode: lssd;
]Pattern 1;
[Pattern 2 (pattern_type = static);
Event 1 Scan_Load:
"ST100DH.0000001.slaveOutput"=1
"PR100BH.0000001.slaveOutput"=1
"PR100CL.0000001.slaveOutput"=1
"PR100DP.0000001.slaveOutput"=1
"PR100ET.0000001.slaveOutput"=1
"MI100EH.0000001.slaveOutput"=0
"MI100EL.0000001.slaveOutput"=0
"MI100EP.0000001.slaveOutput"=0
"MI100ET.0000001.slaveOutput"=0;
]Pattern 2;
[Pattern 3 (pattern_type = static);
Event 1 Stim_PI:
"T1"=1
"T2"=1;
]Pattern 3;
]Define_Sequence;

In the above example, pattern 1 identifies the parent testmode (lssd) with an instruction to
apply that testmode's initialization sequence. Pattern 2 contains a Scan_Load event that
specifies the initial values of those latches that we care about. The Scan_Load event
implicitly invokes the scan sequence of the current testmode, which is in this case the parent
mode that was established by the preceding pattern. Following the execution of pattern two,
the latches will have been initialized.

December 2019 250 Product Version 19.12

For convenience in coding mode initialization sequences, Modus supports some useful
attributes on the Scan_Load event. default_value=0|1 causes all unspecified latches to
be initialized to the specified state (0 or 1). default_value=scan_0|scan_1 causes all
unspecified latches to be initialized to the state that would result from setting a constant 0 or
1 on the scan data primary input while performing the scan operation.

The third pattern switches to the target testmode by switching those primary inputs whose
stability values differ from their stability values in the parent mode.

Note that if there had been three-state primary I/O nets being switched at pattern three, it
might have been necessary (and is generally recommended) to expand it into three patterns,
corresponding to the first three steps of the automatically generated initialization sequence
as described in “Automatically Generated Initialization Sequence” on page 248.

If pseudo primary inputs exist, then in addition to the necessary stimuli for the real primary
inputs you must specify the values that result on the pseudo primary inputs. The pseudo
primary input values may be thought of as “expects”, but Modus will use the pseudo PI
values as stimuli to the downstream logic. Pseudo PI values are specified in Stim_PPI,
Stim_PPI_Clock,, and Pulse_PPI .

In some situations, it may be desired to have the tester check certain signal values during the
mode initialization sequence. Modus supports this, but only if the signal is captured inside the
product (by clocking a latch) and a scan operation is used to unload the value. Use a
Scan_Unload event to specify a latch value to be observed in this way. Direct measurements
on primary outputs (Measure_PO events) are not supported inside the mode initialization
sequence.

It is possible to define an initialization sequence that doesn't require switching to a parent

testmode. When there is no parent mode, the first pattern of the mode initialization sequence
should set all three-state primary input pins to high-Z. build_testmode will help you by
automatically setting any pins unspecified on the first pattern to their stability values or high-
Z for three-state pins that do not have stability values. Non-three-state pins that don not have
stability values are left unspecified.

The initial stim to Z of all three-state PIs is a safety precaution to avoid any potential conflicts
with values that may initially be found at the product drivers at power-on.

Custom Scan Sequences

In most cases the scanop is automatically generated by Modus from the test function
attributes assigned to primary inputs. It may be, however, that your design requires a scan
protocol sufficiently out of the ordinary that it cannot be automatically derived. A case in point

December 2019 251 Product Version 19.12

is a design whose scan chains are not all scannable in parallel, or a design in which the scan
chain is gated by

non-scannable memory elements which must first achieve a particular state before scanning
can proceed. In such situations Modus cannot automatically derive the scan protocol, and
instead you must define it to Modus as a “custom scan sequence”.

It is necessary to define a custom scan sequence if any of the following is true:

■ There is no single primary input stimulus vector that will enable all scan data paths and
all scan clocks simultaneously.
■ The clock sequence necessary to shift data one bit forward along the scan chain is
something other than pulsing in all E_SHIFT_CLOCKs.
■ The scan operation requires values on pseudo primary inputs.

Refer to “System and Scan Clocks” on page 167 for details. and “Defining a Custom Scan
Sequence” on page 252 for additional information.

Once you have determined that it is necessary to define a custom scan sequence for your
design then you must go through the following steps:
1. Break down the scan protocol (scanop) into the set of constituent stimulus sequences
recognized by Modus. This is fully explained in the next section.
2. Create a file containing the scanop definition in TBDpatt (TBDseqPatt) format and feed
this file into the Build Testmode process of Modus by specifying the Sequence Definition
File Name (seqdef) and, optionally, Sequence Definition Path (seqpath).
For additional information, refer to:
❑ “TBDpatt and TBDseqPatt Format” in the Modus : Reference: Test Pattern Data
Format.
❑ “Buid Testmode Keywords of Interest” on page 21

From this point on there is no need for further user intervention on behalf of the custom scan
sequence.

Defining a Custom Scan Sequence

The fundamental way to develop a scanop is by first considering the sequence of primary
input events necessary to get to the scan state - i.e., the design state where scanning can
take place from scan-in to scan-out - and then the sequence of clock pulses necessary to
cause a one bit shift along the scan chain. The first of these sequences is called the Scan

December 2019 252 Product Version 19.12

Preconditioning Sequence (scanprecond) and the second is called the Scan Sequence
(scansequence). The scanop is thus seen to exist in its most elementary form as a
scanprecond sequence followed by a scansequence. (When the scanop is executed the
scansequence must of course be repeated the number of times necessary to completely
scan data through the scan chain.) We must go beyond this simple form, however, in
considering parts where not all latches can be scanned in parallel. When this is the case then
the scanop is broken into a sequence of “scan sections”, each of which scans one or more
scan chains that can be scanned in parallel. Each scan section has its own scan
preconditioning sequence as well as its own scan sequence. The scanop therefore takes the
following general form if there are multiple scan sections:
scanop
scansection 1
scanprecond for scan section 1
scansequence for scan section 1
scansection 2
scanprecond for scan section 2
scansequence for scan section 2
.
.
.
scansection n
scanprecond for scan section n
scansequence for scan section n

Important
The Scan Sequence (scansequence) used to define the actual scan shift operation
within each scan section must be unique. This is true even if multiple scan section
scan chains share the same SI, SO and Clock pins. Modus needs a unique place
holder to track the unique scan chain lengths.

December 2019 253 Product Version 19.12

Pin identification requirements

Any pin stimulated (other than to Z) or observed by a custom scan sequence must have a
test function pin attribute assigned to it. In particular:
■ Any pin pulsed in a custom scan sequence must have a clock test function pin attribute
of the proper polarity. Refer to “Clock Functions” on page 167.
■ Any pin used as a scan-in by the custom scan sequence must have either an SI or TDI
(1149.1) test function pin attribute.
■ Any pin used as a scan-out by the custom scan sequence must have either an SO or
TDO (1149.1) test function pin attribute.
■ Any pin used as a clock isolate pin in a custom scan sequence must have the
Clock_Isolate (CI) test function pin attribute.
■ Any pin that performs a scan gating function must have some test function attribute, at
least a BDY.

A custom scan sequence may, in general, manipulate pins quite freely, subject to the pin
identification requirements stated above. There are however the following restrictions:
■ No TEST_INHIBIT (TI) primary input is allowed to violate its attributed value.
■ All OUTPUT_INHIBIT (OI) pins must be at their inhibiting values throughout the scan
protocol.
■ The final design state resulting from application of the custom scan sequence must not
violate the Test Constraint and Clocks Off state. This is the state in which stored pattern
test generation is performed.
■ Any scan data output (SO) pin that is a bi-directional (inout) pin sourced by a three-state
device should be stimulated to Z in the scan preconditioning or scanentry sequence.
■ Multiple scan sections are not supported for WRPT or LBIST
■ Verify Macro Isolation and Create Macro Tests do not support custom scan sequences
■ The Apply event is the only allowable event for a scanop scansection. Refer to “Apply”
in the Modus : Reference: Test Pattern Data Formats for related information.

December 2019 254 Product Version 19.12

Custom Scan Sequence Example 1 - Multiple Scan Sections

The simple design structure depicted in Figure 6-11requires that a custom scan sequence be
defined because it is not possible to do a parallel scan of all its scannable flip-flops.

Figure 6-11 Design that Requires Multiple Scan Sections

The custom scan sequence (scanop), in TBDseqPatt syntax, takes the following form:
TBDpatt_Format (mode=node, model_entity_form=name);
[ Define_Sequence Scan_Preconditioning_Sequence_1 1 (scanprecond);
[ Pattern 1.1 (pattern_type = static);
Event 1.1.1 Stim_PI ():
"GATE"=0;
] Pattern 1.1;
] Define_Sequence Scan_Preconditioning_Sequence_1 1;

[ Define_Sequence Scan_Preconditioning_Sequence_2 2 (scanprecond);

[ Pattern 2.1 (pattern_type = static);
Event 2.1.1 Stim_PI ():
"GATE"=1;
] Pattern 2.1;
] Define_Sequence Scan_Preconditioning_Sequence_2 2;

[ Define_Sequence Scan_Sequence_1 3 (scansequence);

[ Pattern 3.1 (pattern_type = static);
Event 3.1.1 Measure_Scan_Data ():
"SO" ;
Event 3.2.1 Set_Scan_Data ():
"SI" ;
Event 3.3.1 Pulse ():
"EC"=+ ;
] Pattern 3.1;
] Define_Sequence Scan_Sequence_1 3;

[ Define_Sequence Scan_Sequence_2 4 (scansequence);

December 2019 255 Product Version 19.12

[ Pattern 3.1 (pattern_type = static);

Event 3.1.1 Measure_Scan_Data ():
"SO" ;
Event 3.2.1 Set_Scan_Data ():
"SI" ;
Event 3.3.1 Pulse ():
"EC"=+ ;
] Pattern 3.1;
] Define_Sequence Scan_Sequence_2 4;

[ Define_Sequence Scan_Section_1 5 (scansection);

[ Pattern 4.1 (pattern_type = static);
Event 4.1.1 Apply (): Scan_Preconditioning_Sequence_1;
Event 4.1.2 Apply (): Scan_Sequence_1;
] Pattern 4.1;
] Define_Sequence Scan_Section_1 5;

[ Define_Sequence Scan_Section_2 6 (scansection);

[ Pattern 4.1 (pattern_type = static);
Event 4.1.1 Apply (): Scan_Preconditioning_Sequence_2;
Event 4.1.2 Apply (): Scan_Sequence_2;
] Pattern 4.1;
] Define_Sequence Scan_Section_2 6;

[ Define_Sequence Scan_Operation_Sequence 7 (scanop);

[ Pattern 5.1 (pattern_type = static);
Event 5.1.1 Apply (): Scan_Section_1;
Event 5.1.2 Apply (): Scan_Section_2;
] Pattern 5.1;
] Define_Sequence Scan_Operation_Sequence 7;

Basic Scanop Structure

Based on the discussion of the previous sections we see that the basic scanop with
loadsuffix has the following structure:

December 2019 256 Product Version 19.12

Figure 6-12 Basic Scanop Structure

Advanced Scanop Structure

There are complex scan requirements for which the relatively simple scanop description of
the previous section is inadequate. A good example of this is a design that implements the
1149.1 Boundary standard. To adequately describe the scanop for an 1149.1 design it is
necessary to introduce the following additional components:
■ Scan Entry Sequence (scanentry)
■ Scan Exit Sequence (scanexit)
■ Non-Looped Scan Sequence (scanlastbit)
■ Section Exit Sequence (scansectionexit)

We will demonstrate by way of an example how each of these additional sequence types
enters into the picture. But first, here is the overall scanop structure:

December 2019 257 Product Version 19.12

Figure 6-13 Advanced Scanop Structure

The following section will show by way of an example the need for the additional sequence
types of scanentry, scanexit, scanlastbit and scansectionexit.

Custom Scan Sequence Example 2 - 1149.1

The example about to be presented requires an understanding of 1149.1 TAP Controller state
transitions, shown in Figure 6-14 on page 259.

December 2019 258 Product Version 19.12

Figure 6-14 TAP Controller State Diagram

December 2019 259 Product Version 19.12

Modus supports the generation of stored pattern tests in the Test-Logic-Reset (TLR) state of
the TAP Controller, with all scanning operations done exclusively through the TAP port. The
TLR state corresponds to the Test Constraint and Clocks Off state, which is the generic
state in which test generation is always performed. For the purposes of this example it is
assumed that the 1149.1 design has all scannable system memory elements linked into one
scan chain extending from TDI to TDO (of course some instruction must already have been
loaded into the Instruction Register (IR) in order to configure the memory elements into this
one long scan chain.) In order to scan data through scannable memory elements via the TAP
port it is necessary to traverse the TAP Controller state diagram from the TLR state to the
Shift-DR (SDR) state and from there come back to the TLR state in order to resume test
generation.

scanentry

For this simple example there is only one scan section, but in the most general case there
could be several scan sections, in which case it would be desirable to have all scan sections
start from compatible initial states. Run-Test/Idle (RTI) and Update-DR are compatible states,
in the sense that they both transition directly to the Select-DR-Scan state when TMS is held
at logic 1 and TCK is pulsed. So we therefore define a scanentry sequence which pulses
TCK once while holding TMS at a logic 1, thus moving from the TLR state to the RTI state.

scanprecond

The scanprecond sequence starts from the RTI state and proceeds to the Shift-IR state to
load the user-specified instruction. This is necessary because the TLR state, in which test
generation is done, forces the IR to either the BYPASS or the ID_CODE instruction. It is the
user-specified instruction that configures scan chains so that the following scansequence
will operate correctly, so it must be restored at this time. After loading the instruction we then
proceed to the Shift-DR state. The TMS pin is left at zero (0). Refer to Figure 6-16 on
page 309 for an example.

scansequence

The scansequence consists of nothing more than pulsing TCK while TMS is held at logic 0.
The scansequence is repeated as many times as necessary to scan data through the scan
chain except for the last bit. The reason for stopping short of scanning the last bit is that we
must eventually get back to the TLR state, and there is no way to do this without traversing
the Exit1-DR state. Going from the Shift-DR state to the Exit1-DR state causes one final shift
to occur, hence the name scanlastbit. Refer to Figure 6-17 on page 310 for an example.

December 2019 260 Product Version 19.12

scanexit

Once all scan sections have been executed it is necessary to return to the state in which test
generation is being conducted, the Test-Logic-Reset state. Refer to Figure 6-18 on page 310
for an example. If the latch is clocked in scanexit, the message TSV-315 is generated. If
you want to manipulate the scan clock in scanexit, the clock path to scannable latch should
be gated.

misrobserve

This sequence establishes the MISR Observe state by setting the MISR_READ pins to their
value. A Measure_MISR_Data event is then included to observe the MISR contents on the
MISR_OBSERVE pins. Another Stim_PI is then applied if needed to reset the values on the
MISR_READ pins back to the scan state. Refer to Figure 6-19 on page 310 for an example.

misrreset

This sequence immediately follows the MISR_Observe_Sequence. It establishes the MISR

Reset state by setting the MISR_RESET_ENABLE pins to their values, then pulses the MISR
Reset clock and pulses all the B clocks. Another Stim_PI is then applied if needed to reset
the values on the MISR_RESET_ENABLE pins back to the scan state. Refer to Figure 6-19 on
page 310 for an example.

channelmaskload

This sequence applies the channelmaskprecon, channelmaskcycle and channelmaskexit

sequences in order. Refer to Figure 6-19 on page 310 for an example.

Figure 6-15 Example scanprecond sequence for TAP scan SPTG,

TAP_TG_STATE=TLR
This example assumes the IR must be loaded with
instruction=1011. Note the inclusion of the
instruction value to keep the sequence name unique.

[ Define_Sequence Scan_Preconditioning_Sequence1011 1 (scanprecond);

[ Pattern 1.1 (pattern_type = static);
Event 1.1.1 Stim_PI (): "TMS"=1;
Event 1.1.2 Pulse (): "TCK"=+; # Enter Select-DR-Scan state
] Pattern 1.1;
[ Pattern 1.2 (pattern_type = static);
Event 1.2.1 Pulse (): "TCK"=+; # Enter Select-IR state
] Pattern 1.2;
[ Pattern 1.3 (pattern_type = static);
Event 1.3.1 Stim_PI (): "TMS"=0;
Event 1.3.2 Pulse (): "TCK"=+; # Enter Capture-IR state

December 2019 261 Product Version 19.12

] Pattern 1.3;
[ Pattern 1.4 (pattern_type = static);
Event 1.4.1 Pulse (): "TCK"=+; # Enter Shift-IR state
] Pattern 1.4;
[ Pattern 1.5 (pattern_type = static);
Event 1.5.1 Stim_PI (): "TDI"=1;
Event 1.5.2 Pulse (): "TCK"=+; # scan in right-most IR bit
] Pattern 1.5;
[ Pattern 1.6 (pattern_type = static);
Event 1.6.1 Stim_PI (): "TDI"=1;
Event 1.6.2 Pulse (): "TCK"=+; # scan in next IR bit
] Pattern 1.6;
[ Pattern 1.7 (pattern_type = static);
Event 1.7.1 Stim_PI (): "TDI"=0;
Event 1.7.2 Pulse (): "TCK"=+; # scan in next IR bit
] Pattern 1.7;
[ Pattern 1.8 (pattern_type = static);
Event 1.8.1 Stim_PI (): "TDI"=1
"TMS"=1; # move to exit1-IR and
Event 1.8.2 Pulse (): "TCK"=+; # scan in left-most IR bit
] Pattern 1.8;
[ Pattern 1.9 (pattern_type = static);
Event 1.9.1 Pulse (): "TCK"=+; # Enter Update-IR state
] Pattern 1.9;
[ Pattern 1.10 (pattern_type = static);
Event 1.10.1 Pulse (): "TCK"=+; # Enter Select-DR-Scan state
] Pattern 1.10;
[ Pattern 1.11 (pattern_type = static);
Event 1.11.1 Stim_PI (): "TMS"=0;
Event 1.11.2 Pulse (): "TCK"=+; # Enter Capture-DR state
] Pattern 1.11;
[ Pattern 1.12 (pattern_type = static);
Event 1.12.1 Pulse (): "TCK"=+; # Enter Shift-DR state
] Pattern 1.12;
] Define_Sequence Scan_Preconditioning_Sequence1011 1;

Figure 6-16 Example scansequence and scanlastbit sequences,

TAP_TG_STATE=TLR
[ Define_Sequence Scan_Sequence 2 (scansequence, repeat=n-1); # n is TDR length
[ Pattern 2.1 (pattern_type = static);
Event 2.1.1 Measure_Scan_Data (): "SO"
Event 2.2.2 Set_Scan_Data (): "SI"
Event 2.3.3 Pulse (): "TCK"=+; # shift TDR 1 bit
] Pattern 2.1;
] Define_Sequence Scan_Sequence 2;

[ Define_Sequence Scan_Last_Bit 3 (scanlastbit); # shift nth bit

[ Pattern 3.1 (pattern_type = static);
Event 3.1.1 Measure_Scan_Data (): "SO"
Event 3.1.2 Set_Scan_Data (): "SI"
Event 3.1.3 Stim_PI (): "TMS"=1; # move to Exit1-DR
Event 3.1.4 Pulse (): "TCK"=+; # and shift last bit
] Pattern 3.1;
] Define_Sequence Scan_Last_Bit 3;

Figure 6-17 Example scansectionexit and scanexit sequences, TAP_TG_STATE=TLR

[ Define_Sequence Scan_Section_Exit_Sequence 4 (scansectionexit);

December 2019 262 Product Version 19.12

[ Pattern 4.1 (pattern_type = static);

# TMS=1 already. Next TCK pulse moves to Update-DR state and updates
Event 4.1.2 Pulse (): "TCK"=+; # parallel (L3-like) outputs
] Pattern 4.1;
] Define_Sequence Scan_Section_Exit_Sequence 4;

[ Define_Sequence Scan_Exit_Sequence 5 (scanexit);

[ Pattern 5.1 (pattern_type = static);
Event 5.1.1 Stim_PI (): "TMS"=0;
Event 5.1.2 Pulse (): "TCK"=+; # Enter Run-Test/Idle state
] Pattern 5.1;
] Define_Sequence Scan_Exit_Sequence 5;

Figure 6-18 Example misrobserve, misrreset and channelmaskload Sequence

[ Define_Sequence MISR_Observe_Sequence 4 (misrobserve);
[ Pattern 4.1 (pattern_type = static);
Event 4.1.1 Measure_MISR_Data ():
"out[0]"
"out[10]"
"out[11]"
"out[12]"
"out[13]"
"out[14]"
"out[15]"
"out[1]"
"out[2]"
"out[3]"
"out[4]"
"out[5]"
"out[6]"
"out[7]"
"out[8]"
"out[9]" ;
] Pattern 4.1;
[ Define_Sequence MISR_Reset_Sequence 5 (misrreset);
[ Pattern 5.1 (pattern_type = static);
Event 5.1.1 Stim_PI ():
.........................................1....;
] Pattern 5.1;
[ Pattern 5.2 (pattern_type = static);
Event 5.2.1 Pulse ():

December 2019 263 Product Version 19.12

"mrc"=+ ;
] Pattern 5.2;
[ Define_Sequence ChannelMaskLoad_Sequence 7 (channelmaskload);
[ Pattern 7.1 (pattern_type = static);
Event 7.1.1 Apply (): ChannelMask_Cycle_Sequence;
] Pattern 7.1;
] Define_Sequence ChannelMaskLoad_Sequence 7;
[ Define_Sequence Scan_Section_Sequence 8 (scansection);
[ Pattern 8.1 (pattern_type = static);
Event 8.1.1 Apply (): Scan_Preconditioning_Sequence;
Event 8.1.2 Apply (): ChannelMaskLoad_Sequence;
Event 8.1.3 Apply (): Scan_Sequence;
Event 8.1.4 Apply (): MISR_Observe_Sequence;
Event 8.1.5 Apply (): MISR_Reset_Sequence;
] Pattern 8.1;

Restrictions for Custom Scan Sequence

■ Multiple scan sections are not supported for WRP or LBIST.
■ Neither Verify Macro Isolation nor Create Macro Tests support custom scan sequences.
■ There is no support for a scan configuration in which the same latch occurs in more than
one scan section.
■ The creation of dynamic tests by targeting static faults is not supported.
■ Skewed load and unload sequences are not supported for multiple scan sections.

Automatically Generated Initialization Sequence

For non-1149.1 testmodes, the automatically generated scan preconditioning (scanprecond)
sequence consists of a single pattern which does the following:
1. Sets all scan enable (SE, SGI, SGO) test function pins to their scan state value.
2. Sets to Z any 3-state bi-directional pins whose internal drivers are not disabled.

For 1149.1 testmodes, a more complicated scan sequence is generated with multiple
patterns as needed to bring the TAP state machine from the TAP_TG_STATE to the correct
state for scanning (usually the Shift_DR state). If there are multiple 1149.1 instructions and
scan chains to be shifted, there is a separate scan section defined for each instruction. When
there are multiple scan sections, there is a scanentry sequence created to move the TAP

December 2019 264 Product Version 19.12

finite state machine from the TAP_TG_STATE to a common state for all scan sections to start
and end in.

For non-1149.1 testmodes, the automatically generated scansequence sequence, which is

intended to define the complete sequence of clocks needed to shift 1 full bit and which should
be able to be completed within one tester cycle, consists of a single pattern which does the
following:
1. Indicates that all scan-out pins should be measured.
2. Indicates that all scan-in pins should have their new scan data applied
3. Pulses all defined shift E clocks. If there are multiple shift E clocks and they are
numbered, separate Pulse() events are generated to ensure the clocks appear in their
numerical order.

For 1149.1 testmodes, TCK is considered a shift E clock and additional scan clocks may also
be defined. Also, when the TAP_TG_STATE is no the Shift_DR state, there is a
scanlastbit sequence generated which shifts the last bit if the scan chains and moves the
TAP finite state machine into the Exit1_DR state.

For non-1149.1 testmodes, the automatically generated scanexit sequence, which is

intended to return the design from the scan state back to the TG state, consists of a single
pattern which does the following:
■ Sets all Test Constraint (TC) test function pins to their TC value.

Note that scan enable pins are left at their scan state value unless the pin is also specified to
be a Test Constraint (TC).

For 1149.1 testmodes, the automatically generated scanexit sequence moves the TAP
finite state machine from the Exit1_DR state (where the scanlastbit sequence ended) to
the TAP_TG_STATE.

The automatically generated scansection sequence does the following:

1. Applies the scanprecond sequence for this scan section.
2. Applies the scansequence sequence for this scan section.

The automatically generated scanop sequence does the following:

1. Applies the scanentry sequence (if any) for 1149.1 testmodes with multiple scan
sections.
2. Applies the scansection sequence(s) for all defined scan sections in the order they
appear in the mode definition file.

December 2019 265 Product Version 19.12

Applies the scanexit sequence (if any) for 1149.1 testmodes to get to the TAP_TG_STATE
or for non-1149.1 testmodes to get to the TG state when there are Test Constraint (TC) test
function pins defined.

Partition File (Optional)

Use a partition file as input to reduce, or partition, portions of active logic to accelerate ABIST
simulation. Partitioning of ABIST logic causes Modus fault simulation applications to
simulate only the active logic defined by the partition file. Either hierarchical blocks of interest
or starting/stopping points for a backtrace may be specified in the partition file. Refer to Active
and Inactive Logic on page 269 for additional information.

The file must contain specific keywords to execute properly during mode definition. The
available keywords (upper case required) are:
■ INCLUDE - marks all pins/nets in the specified block as active. Tracing is not performed,
therefore any internal latches that are not affected during backtracing do not have their
clocks backtraced as active.
■ REMOVE - unmarks all pins/nets in the specified block and identifies them as inactive.
■ STOP - tracing is stopped at the specified points. If a pin/net is a STOPPING point, the
pin/net is marked active, but no tracing is performed beyond that point. If a block is
marked STOP, the output of the block is marked active and tracing into the block is
discontinued.
■ BACKTRACE - backtraces the specified net/pin or all inputs of the specified block.
■ BACKTRACE INPUT - queues all inputs of the specified block for backtracing.
■ BACKTRACE OUTPUT - queues all outputs of the specified block for backtracing. If there
is logic in the block that does not feed the outputs, then this logic remains inactive. Also,
backtracing stops at scan latches; if there are scan latches inside the block, the tracing
stops there (clocks are fully backtraced).

Specify blocks, pins, and nets in the following format:

■ Block.f.l.blockName
■ Pin.f.l.pinName
■ Net.f.l.netName

Multiple blocks, pins, and nets maybe be specified as follows:

INCLUDE Block.f.l.blk.nl.xx.yy Block.f.l.blk.nl.xx.yz
BACKTRACE Pin.f.l.blk.nl.tt.rr

December 2019 266 Product Version 19.12

BACKTRACE Pin.f.l.blk.nl.tt.rz
BACKTRACE Pin.f.l.blk.nl.tz Net.f.l.blk.nl.ee.ss Block.f.l.blk.nl.yy.uu
Net.f.l.blk.nl.ee.sa Block.f.l.blk.nl.yy.ua

December 2019 267 Product Version 19.12

December 2019 268 Product Version 19.12

7
Testmode Concepts

Active and Inactive Logic

Inactive logic is logic that cannot be observed in the testmode. Since it cannot be observed,
it is not processed by the Modus commands. The logic may be unobservable due to things
in the design source such as “dangling logic” (logic that is not connected to anything) or TIE
blocks that keep values from propagating.

The use of Test Inhibit (TI) signals (on either primary inputs or fixed value latches) may cause
some logic to be inactive in that specific testmode. In addition, the use of Test_Constraint (TC)
signals may cause yet more logic to become inactive in the test constraint state (“test
generation state”).

Logic may be classified as inactive for the "test generation state" and active for the "scan
state" and vice-versa. Thus, most system-function logic may be inactive in the scan state,
resulting in improved application program performance when processing scan tests, for
example. Logic that is inactive in both the test generation state and the scan state is displayed
as greyed out in the GUI design schematic viewer.

For purposes of identifying inactive logic in the test generation state, TI and TC signals are
held at their specified states as described above. Similarly, for the identification of inactive
logic in the scan state, TI and SE signals are held at their specified states.

Yet another cause of inactive logic is the existence of cut points. Cut points cause the
upstream logic to be unobservable as far as Modus programs are concerned. Although the
logic is, in fact, observable, Modus marks logic that is observable only through cut points as
inactive. This logic is also given a special designation, “OPC”. Any node which is the source
of a cut point net is considered active (provided that the cut point net was active to begin with.

In the case of inactive logic unique to a testmode (due to the use of TI or TC signals), faults
in the inactive logic are also considered to be inactive in that testmode. A fault is considered
inactive in the testmode if it is on logic which is inactive in both the test generation state and
the scan state. Fault coverage statistics for a testmode are based on the testmode's active
faults only. For globally inactive logic (due to “dangling” or TIE blocks), untestable faults are
simply excluded from the fault model.

December 2019 269 Product Version 19.12

For Boundary Scan Internal or External testmodes, large sections of the design may be
considered logically inactive. For a Boundary Scan Internal testmode, the logic feeding only
to non-test function primary output pins will be inactive; also the logic between non-test
function primary input pins and boundary scan latches is inactive due to Test Inhibit (TI)
testmode controls, but this is not guaranteed because the logic may fan out to observable
points through paths not blocked by the TI signals. For a Boundary Scan External testmode,
usually only the logic between the I/O pins and the boundary scan latches is considered
active; most of the logic internal to the design is deemed to be inactive. An exception to this
occurs if it is necessary to supplement the normal external logic with chip PI-to-PO paths to
enable the creation of a kind of internal-external hybrid boundary model in support of AC path
testing at the MCM level. This is necessary if the MCM paths to be tested are more than just
the driver-to-receiver interconnect paths, but must also include some paths that traverse
whole chips. To accommodate this need, Modus supports the user specification of a set of
chip primary output nets which must be fully traced back to chip primary inputs. These traces
will supplement the normal external logic. For any testmode, all logic necessary for correct
operation of all defined scan chains is considered to be active. For Boundary Scan External
testmodes it is advisable to define only those scan chains necessary for scanning just the
boundary latches to avoid including too much active logic.

Reporting Inactive Logic

Use the report_faults command to report a list of faults that are identified as inactive. A
sample command is given below:
report_faults -inactiveallmodes yes -reportdetails yes

This will create a list of all the inactive faults associated with the inactive logic. You can then
determine the modules in the design that have the inactive logic.

Debugging Inactive Logic

You need to debug the inactive logic reported by build_testmode to increase the test
coverage for a testmode. A potential debug technique is to report the cause of inactive state
for each inactive instance and net in the testmode. The following is a sample debug script,
which when executed after build_testmode, reports wherever the logic has a hard tie or is
tied in the inhibit or constraint states:
set_db workdir .
set_context -testmode FULLSCAN
puts "\n\n";
puts "report_inactive_logic";
puts " Workdir [get_db workdir]";
puts " TestMode [get_db testmode]";

#
# get the number of nodes in the design

December 2019 270 Product Version 19.12

#
set maxNodes [get_count -node]
if {$maxNodes <= 0} {
puts "No nodes in the design";
return;
}

#
# go through all nodes looking for inactive ones
# store in an associative array
#
set inactive_nodes [dict create]
set inactive 0

get_db nodes -if {.is_active == false} -foreach {dict append inactive_nodes [get_db
$object .index] 0; incr inactive;}
#
# check whether the node is at a fixed state in the Test Constraint state
#

set states "test_constraint test_inhibit tie_only"

foreach state $states {

simulate_state $state
foreach key [dict keys $inactive_nodes] {
set object [get_object -node $key]
set valueStr [get_db $object .value]
if {$valueStr ne "X/X"} {
if {$state eq "test_constraint"} {
dict set inactive_nodes $key 1
}
if {$state eq "test_inhibit"} {
dict set inactive_nodes $key 2
}
if {$state eq "tie_only"} {
dict set inactive_nodes $key 3
}
}
}
}

#
# print the list of nodes and fixed states
#
foreach key [dict keys $inactive_nodes] {

set object [get_object -node $key]

set name [get_db $object .prim.name]
set value [dict get $inactive_nodes $key]

if {$name ne ""} {
puts -nonewline "Block $key [lindex $name 0]";
} else {
set name [get_db $object .highest_net.name]
if { $name ne "" } {
puts -nonewline "Net $key [lindex $name 0]";
} else {
puts -nonewline "Other $node";
}
}
if {$value == 3} {

December 2019 271 Product Version 19.12

puts " Hard Tie";

}
if { $value == 2 } {
puts " Tied in Test Inhibit";
}
if { $value == 1 } {
puts " Tied in Test Constraint";
}
if {$value <= 0 || $value > 3} {
puts "";
}
}

set inactiveStr $inactive.0

set percent_inactive [ expr {($inactiveStr*100)/$maxNodes} ]
puts "\n\n";
puts "Total nodes - $maxNodes";
puts "Inactive nodes - $inactive";
puts "Percentage inactive :- $percent_inactive%";
exit

Testmode Design States

The design states described in this section are those resulting from application of specific PI,
pseudo PI, and latch values that have particular significance in the testmode. Modus
applications use these design states as starting points for testability analysis and test
generation. To aid user analysis, these design states can be set with Reset circuit state on
the graphical user interface. For more information, refer to Reset Circuit State in the Modus:
Reference: GUI.

Tie Only
This state is essentially a “reset” of the design. All PIs and memory elements are set to X and
values from TIE-blocks are propagated into the logic.

Test Inhibit
In this state all PIs and memory elements are set to X, values from Tie blocks are propagated
into the logic, and Test Inhibit signals (on primary inputs, pseudo PIs, and fixed-value latches)
are set to the test function value and propagated into the logic. This is the base design state
which Modus never violates, either for test generation or for scanning.

December 2019 272 Product Version 19.12

Test Constraint
In this state all PIs and memory elements are set to X, values from Tie blocks are propagated
into the logic, and Test Inhibit signals (on primary inputs, pseudo PIs, and fixed-value latches)
and Test Constraint signals (on primary inputs, pseudo PIs, and latches) are set to the test
function value and propagated into the logic. This is the base test generation design state,
more confining than the Test Inhibit state (if there are TC primary inputs), which Modus test
generators never violate.

Test Constraint and Clocks Off

The test constraint and clocks off state forces the clocks off to all memory elements required
at a constant value for test generation, but not necessarily for scanning. To reach this state,
Modus sets:
■ all TIE Blocks to value
■ all TEST_INHIBIT pins and latches to value
■ all TEST_CONSTRAINT pins and test constraint latches to value
■ all clocks off

Modus will not allow more than one clock at a time to depart from the Test Constraint and
Clocks Off state in the process of test generation. (This state does not apply to the scanning
operation.)

Mode Initialization
The mode initialization state is the starting state for the mode. To reach this state, Modus
sets:
■ the design to the Test Constraint and Clocks Off state
■ the initial values on all latches as determined by the mode initialization sequence
■ the initial values on all RAMs as determined by the mode initialization sequence
■ the final stimulus on all primary inputs as determined by the mode initialization
sequence.

See Unit or Zero Delay Simulations for Testmode on page 24 for more information on Modus
mode initialization sequences.

December 2019 273 Product Version 19.12

Scan States
A scan state allows scan chains to be scanned. If the testmode allows all its scan chains to
be scanned in parallel (this is the usual case) then the scan operation for this testmode
consist of just one scan section. If it is not possible to scan all chains in parallel then the scan
operation consists of multiple scan sections, each of which scans in parallel one or more scan
chains. All defined scan sections are executed in sequence in order to scan all the scan
chains.

For each scan section there is defined a distinct scan state. When the Scan option of Set
circuit state is selected from the graphical user interface and there is only one scan section
then that section's scan state is displayed directly. If, however, there are multiple scan
sections then selecting the Scan state causes the Select a Scan Section window to be
displayed. This shows a list of scan sections from which one can be selected for display.

Modus supports scan-in and scan-out design states, differentiated as follows:

■ Scan In
This state requires that any pin defined in the scan in and global categories with polarity
must be applied to their values. The design must be at this state before any input scan
is performed (channel scan, Scan_Load, etc.)
■ Scan Out
This state requires that any pin defined as a SCAN_OUT_GATE (SOG) must be applied
to its value. The design must be at this state before any output scan unload is performed
(channel scan, Scan_Unload, etc.).

To reach these states, Modus sets:

■ all SCAN_ENABLE pins to the value required for scanning.
■ any CLOCK_ISOLATION pins to the value required to select the scan clock function.

For overlapped scan, the scan in and scan out states are identical.

However many scan sections there are, each has the following characteristics:
1. Each latch or scan-in PI is a function of only the single preceding latch or scan-in PI in
its scan chain.
2. All clock inputs to non-scan memory elements are held OFF (at test function value), even
when clocks required for shifting are manipulated.
3. Any shift clock to a latch may be turned ON (opposite of test function value) and OFF
(test function value) by changing the corresponding clock PI.

December 2019 274 Product Version 19.12

To reach this state Modus sets:

■ all SCAN_ENABLE (scan selects) to the value required for scanning.
■ any CLOCK_ISOLATION to the value required to select the scan clock function.
Note: If you use OUTPUT_INHIBIT pins to suppress output switching noise, they will also be
set to value in the scan state.

Nonscanflush Design State

The nonscanflush design state is produced when a nonscanflush sequence is defined as part
of testmode creation. The testmode creation process recognizes and analyzes the sequence,
replacing any Stim_PI values for pipelined pins with a Stim_PI for the associated PPIs.

Modus defines this design state as the PI and PPI state in which all of the nonscanflush
pipeline clocks are pulsed.

Refer to the following for additional information:

■ Mode Initialization Sequences
■ The description of nonscanflush sequence in the “Define_Sequence” section of the Test
Pattern Data Reference
■ Refer to prepare_pipeline_sequence -H or man
prepare_pipeline_sequence for the command syntax and supported options.

MISR Observe
This state is created by applying the values specified on the MISR_READ (MRD) pin(s) while
in the Scan In state. Note that the MRD test function may be specified on pins that have other
functions in the Scan In state (such as SE). In this case, the MRD value overrides the Scan
In state value. While in this state, the contents of the on-board MISR should be available on
the MISR_OBSERVE (MO) pins.

MISR Reset
This state is created by applying the MISR_RESET_ENABLE (MRE) pins to their value while
in the Scan In state. Note that the MRE test function may be specified on pins that have other
functions in the Scan In state (such as SE). In this case, the MRE value overrides the Scan
In state value. While in this state, the MISR latches can be reset to a known state if the
MISR_Reset clock pulse is done followed by a B clock.

December 2019 275 Product Version 19.12

Channel Mask Load

This state is created by applying the channelmaskprecond sequence on top of the scan
state. The Channel Mask Load design state allows analysis of problems in the loading of
channel masks. Channel mask pins denote from where mask bits are loaded, however if no
CML pins are specified, Modus assumes SI pins serve this function.

OPCG Load State

This state is created if at least one OPCG Load Clock (OLC) is present in the design. The
OPCG design state allows analysis of problems in the loading of OPCG registers. Refer to
OPCG Testmode in Modus: Flows for additional information.

December 2019 276 Product Version 19.12

Index
Numerics C
1149.1 CELL_BOUNDARY 145
test function pins 180 CHANNEL_INPUT (CHI) 164
1149.1, keyword of SCAN syntax 135 CHANNEL_OUTPUT (CHO) 164
1149.6 boundary scan CI (CLOCK_ISOLATION) 169
output boundary scan cell changes 99 circuit states
tap controller changes 95 description 272
test receiver 92 misr observe 275
verifying 112 misr reset 275
mode initialization 273
nonscanflush 275
A test constraint 273
test constraint and clocks off 273
ASSIGN statement syntax test inhibit 272
BLOCK 159 tie only 272
diagram and keywords 147 clock gates 169
DOMAIN 159 CLOCK_ISOLATION (CI) 169
PIN 160 clocks, system and scan 167
PIPELINE_CLOCK 159 COMET statement syntax
PIPELINE_DEPTH 159 comet_name 131
PPI 159 diagram and keywords 129
TEST_FUNCTION 159 comet_name, keyword of COMET
syntax 131
comments - mode definition 127
B comments - TDR syntax 213
compression, block level 75
BDY (BOUNDARY_DATA_PIN) 178 CONTROL_PIN (CTL) 178
BI (BIDI_INHIBIT) 173 create vector correspondence 250
BIDI_INHIBIT (BI) 173 creating BSDL
block level compression 75 input files 91
commands 78 CTL (CONTROL_PIN) 178
Boundary Register custom scan protocol
implementation by Test Synthesis 89 defining 252
boundary scan restrictions 264
Boundary Register 89 scanentry 260
IEEE 1149.1 architecture 86 scanop 256
boundary scan controls, IEEE 1149.1 179, scanop structure, advanced 257
181 scanop structure, basic 256
boundary scan controls, RPCT 178 scanprecond 260
BOUNDARY_DATA_PIN (BDY) 178 scansequence 260
BOUNDARY, keyword of SCAN customer service, contacting 14
syntax 137 CUTPOINTS statement syntax
BSDL extension - identifying image unwired diagram and keywords 190
ports 246 CUTPOINTS, keyword of DELETE
BSDL file syntax 190

December 2019 277 Product Version 19.12

D H
DELAY_PROCESSING 237 help, accessing 12
DELAY_PROCESSING statement
syntax 238
DELETE statement syntax I
CUTPOINTS 190
diagram and keywords 190 I/O wrap, keyword of TEST_TYPES
PPIS 190 syntax 142
DRIVER_RECEIVER, keyword of IDDq PROPAGATE, keyword of
TEST_TYPES syntax 145 TEST_TYPES syntax 145
DYNAMIC, keyword of FAULTS image unwired ports, identifying 246
syntax 132 IMPLICIT CHOPPERS statement syntax
DYNAMIC, keyword of TEST_TYPES diagram and keywords 191
syntax 142 IN, keyword of SCAN syntax 136
initialization sequence
automatically generated 248
E initialization sequence requirements 247
initialization sequences 247
E 186 automatically generated 248
E_SHIFT_CLOCK (EC) 167 coding externally specified 249
E_SHIFT_SYSTEM_CLOCK (ES) 168 overview 248
EC (E_SHIFT_CLOCK) 167 requirements 247
embedded devices, power-up controls 181 Instruction Decode Logic
ES (E_SHIFT_SYSTEM_CLOCK) 168 use of 89

F L
FAULTS syntax latches, test function pins 173
diagram and keywords 132 LENGTH, keyword of SCAN syntax 134
DYNAMIC 132 LFSR (linear feedback shift register) 35
NONE 132, 209 LH (LINEHOLD) 172
STATIC 132 LINEHOLD (LH) 172
filename, keyword of LOGIC, keyword of TEST_TYPES
SEQUENCE_DEFINITION syntax 142
syntax 208
FINITE__STATE_MACHINE (FSM) 173
FIXED_VALUE_DEFAULT syntax M
diagram and keywords 191
FSM (FINITE__STATE_MACHINE) 173 MACRO_MODE statement syntax
diagram and keywords
MACRO, keyword of TEST_TYPES
G syntax 142
MARKOFF, keyword of COMETS
GO test function pin 177 syntax 131
GSD, keyword of SCAN syntax 135 MEASURE 224
MEASURE Statement Syntax 225
misr observe circuit state 275
misr reset circuit state 275

December 2019 278 Product Version 19.12

MISR_OBSERVE (MO) 174 NONE 132, 209

MISR_READ (MRD) 175 NONE, keyword of TEST_REORDER
MISR_RESET_ENABLE (MRE) 175 syntax 209
MO (MISR_OBSERVE) 174 NONE, keyword of TEST_TYPES
mode definition file syntax 142
statements 128, 146 NONE 142
syntax 127 nonscanflush circuit state 275
use of 127
mode definition statement syntax
ASSIGN 140 O
COMET 192
COREINSTANCE 186 OI (OUTPUT_INHIBIT) 174
core_instance_name 186 OLI (OPCG_Load_Input) pin 177
testmode 186 ON_BOARD 137
CORRELATE 191 ON_BOARD_MISR statement syntax
CUTPOINTS 190, 214 diagram and syntax 214
DELETE 192 ON_BOARD_PRPG statement syntax
DIAGNOSTIC_MODE 191 diagram and keywords
FAULTS 146 on-product misr test function pins 174
FIXED_VALUE_DEFAULT 140 OPCBIST, keyword of TEST_TYPES
IMPLICIT CHOPPERS 191 syntax 144
ON_BOARD_MISR 214 OPMISRplus 52
ON_BOARD_PRPG 214 OSC (OSCILLATOR) 169
RAM_INITIALIZE_VALUE 139 OSCILLATOR (OSC) 169
SCAN 140 OSCILLATOR_PULSES_PER_CYCLE 22
SEQUENCE_DEFINITION 140 2
SIGNATURE_OBSERVATION_MODE OSCILLATOR_PULSES_PER_TESTER_C
209 YCLE statement syntax 222
statements 128, 146 oscillators 169
TEST_TYPES 140 oTI 169
TESTER_DESCRIPTION_RULE OUT, keyword of SCAN syntax 136
TYPE 134 OUTPUT_INHIBIT (OI) 174
mode initialization circuit state 273
model_attribute_name, keyword of
TEST_FUNCTION_PIN_ATTRIBUT P
ES
model_attribute_name 139 P_SHIFT_SYSTEM_CLOCK (PS) 167
MRD (MISR_READ) 175 padding, x-mask 63
MRE (MISR_RESET_ENABLE) 175 partition file 266
multiple test modes 35 PIN_TIMING statement syntax 227
PIN_TIMINGS 226
PIN, keyword of ASSIGN syntax 157
N port alias extension 244
PPIS, keyword of DELETE syntax 190
NET, keyword of ASSIGN syntax 158 PRIMITIVE_BOUNDARY, keyword of
NET 158 TEST_TYPES syntax 145
NIC NO_INTERCONNECT 178 PROCEDURE, keyword of
1149.1 boundary scan controls 179, TEST_REORDER syntax 209
181 PRPG_SAVE (PV) 174
NO_INTERCONNECT (NIC) 178 PS (P_SHIFT_SYSTEM_CLOCK) 167
NONE, keyword of FAULTS syntax 132 PV (PRPG_SAVE) 174

December 2019 279 Product Version 19.12

R SIGNATURE_OBSERVATION_MODE
statement syntax
RAM_INITIALIZE_VALUE statement syntax diagram and keywords
diagram and keywords testmodename 139
removes all committed test 167 SIGNATURES statement syntax 215
SIGNATURES, keyword of TEST_TYPES
syntax 144
S STATIC, keyword of FAULTS syntax 132
STATIC, keyword of TEST_TYPES
sample bsdl file 244 syntax 142
scan chain sequence order 165 STATS_ONLY, keyword of COMETS
scan clock sequence number 168 syntax 131
scan sequences, automatic syntax, tdr
description of DELAY_PROCESSING 237
SCAN statement syntax MEASURE 224
1149.1 135 OSCILLATOR_PULSES_PER_TESTER
BOUNDARY 137 _CYCLE 222
GSD 135 PIN_TIMING 226
IN 136 PRPG_DEFINITION 226
LENGTH 134 SCAN_REQUIREMENTS 240
TYPE 134 TDR_DEFINITION 214
SCAN_ENABLE (SE) 170 TERMINATION 222
SCAN_GATE (SG) 169 TEST_PINS 218
SCAN_IN (SI) 164 system and scan clocks
SCAN_IN (SI) test function 164 clock functions 167
SCAN_IN_GATE (SIG) 175 scan clock sequence number 168
SCAN_OUT (SO) 164 SYSTEM_CLOCK (SC) 167
SCAN_REQUIREMENTS 240
SCAN_REQUIREMENTS statement
syntax 241 T
scanentry 260
scanexit 261 TAP Controller
scan-in/scan-out circuit states 274 inputs and output 89
scanop 252 TC (TEST_CONSTRAINT) 172
scanop structure, advanced 257 TCK (TEST_CLOCK) 179
scanop structure, basic 256 TD_MIGRATION, keyword of TEST_TYPES
scansequence 260 syntax 142
sequence definition 247 TDI (TEST_DATA_INPUT) 179
SEQUENCE_DEFINITION statement TDO (TEST_DATA_OUTPUT) 179
syntax TDR (tester description rule)
diagram and keywords 208 introduction 213
filename 208 sample TDRs 242
sequences statement syntax 213
signature observation 113 TDR statement syntax
SG (SCAN_GATE) 169 diagram and keywords
SHIFT_REGISTER, keyword of tdrname 146
TEST_TYPES syntax 145 TDR_DEFINITION 217
SI (SCAN_IN) test function 164 TDR_DEFINITION statement syntax 217
SIG (SCAN_IN_GATE) 175 tdrname, keyword of TDR syntax 146
signature observation sequences 113 TERMINATION 222
TERMINATION statement syntax 223

December 2019 280 Product Version 19.12

test constraint and clocks off circuit DRIVER_RECEIVER 145

state 273 DYNAMIC 132, 142
test constraint circuit state 273 IDDq PROPAGATE 145
test constraint sequencing 172 LOGIC 142
test function attributes NONE 132, 142
definition OPCBIST 144
scan inputs and outputs 164 SHIFT_REGISTER 145
system and scan clocks 167 SIGNATURES 144
test function pins STATIC 132, 142
1149.1 180 TD_MIGRATION 142
1149.1 boundary scan controls 179, TIMED_TEST 143
181 tester description rule (TDR)
attributes introduction 213
circuit states 272 sample 242
clock gates 169 statement syntax 213
determining usage 181 testmodename, keyword of
latches 173 SIGNATURE_OBSERVATION_MOD
on-product misr 174 E syntax 139
OPCG controls 177 TI (TEST_INHIBIT) 171
oscillators 169 tie only circuit state 272
RPCT boundary scan controls 178 TIMED_TEST, keyword of TEST_TYPES
simultaneous output switching syntax 143
control 174 TMS (TEST_MODE_SELECT) 179
test constraints 172 TRST (TEST_RESET) 179
three-state driver control 173 TYPE, keyword of SCAN syntax 134
valid combinations 182
test inhibit circuit state 272
test mode U
multiple test modes 35
test mode, removing UNCORRELATE 188
performing using Modus
test mode, resetting online help 12
performing 39
TEST_CLOCK (TCK) 179
TEST_CONSTRAINT (TC) 172 X
TEST_DATA_INPUT (TDI) 179
TEST_DATA_OUTPUT (TDO) 179 x-mask padding 63
TEST_FUNCTION_PIN_ATTRIBUTES
syntax
diagram and keywords 139 Z
TEST_INHIBIT (TI) 171
TEST_MODE_SELECT (TMS) 179 ZMRE test function 175
TEST_PINS 218
TEST_PINS statement syntax 219
TEST_REORDER syntax
NONE 209
PROCEDURE 209
TEST_RESET (TRST) 179
TEST_TYPES syntax 140
CELL_BOUNDARY 145
diagram and keywords 140

December 2019 281 Product Version 19.12

Primetime Error Messages
No ratings yet
Primetime Error Messages
2,768 pages
LPG Sect1 06052009
No ratings yet
LPG Sect1 06052009
18 pages
ATPG LAB3d
No ratings yet
ATPG LAB3d
2 pages
Translating VCD and Ev CD To Ate
100% (1)
Translating VCD and Ev CD To Ate
13 pages
TPV Ug
No ratings yet
TPV Ug
263 pages
Synthesis
No ratings yet
Synthesis
6 pages
Getting Started Lab With Spyglass 450
100% (1)
Getting Started Lab With Spyglass 450
47 pages
RTL Lint Checking Lec
100% (1)
RTL Lint Checking Lec
49 pages
The Ultimate Online Tool Guide For Designers
No ratings yet
The Ultimate Online Tool Guide For Designers
15 pages
Kodak Preps 6
No ratings yet
Kodak Preps 6
44 pages
Modus Ug Pmbist
No ratings yet
Modus Ug Pmbist
261 pages
ET UserGuide
No ratings yet
ET UserGuide
354 pages
Lbist Ref
No ratings yet
Lbist Ref
764 pages
Tessent Plltest User'S Manual: Software Version 2014.1 March 2014
No ratings yet
Tessent Plltest User'S Manual: Software Version 2014.1 March 2014
146 pages
BSDXG PDF
No ratings yet
BSDXG PDF
238 pages
Mbist - GD
No ratings yet
Mbist - GD
350 pages
SpyGlass AdvancedLintMethodology GuideWare2.0 UserGuide
No ratings yet
SpyGlass AdvancedLintMethodology GuideWare2.0 UserGuide
42 pages
Lab1 DC Tmax 2012 1217 v1
No ratings yet
Lab1 DC Tmax 2012 1217 v1
43 pages
CPF User
No ratings yet
CPF User
207 pages
Primepower Functional Safety Manual: March 2018, Revision 1.5
No ratings yet
Primepower Functional Safety Manual: March 2018, Revision 1.5
29 pages
Boundary-Scan DFT Guidelines
100% (1)
Boundary-Scan DFT Guidelines
63 pages
XG Mode: User Guide
No ratings yet
XG Mode: User Guide
176 pages
Spy Glass Quick Guide
0% (1)
Spy Glass Quick Guide
18 pages
Atpg GD PDF
100% (1)
Atpg GD PDF
400 pages
DC Tutorial Using DV
No ratings yet
DC Tutorial Using DV
126 pages
MBIT Genus Flow
No ratings yet
MBIT Genus Flow
52 pages
01 - Xcelium, Nlint, Nwave, Verdi
No ratings yet
01 - Xcelium, Nlint, Nwave, Verdi
90 pages
Vcs /vcsi™ User Guide: Version F-2011.12-Sp1 May 2012
No ratings yet
Vcs /vcsi™ User Guide: Version F-2011.12-Sp1 May 2012
1,322 pages
Emory Epair Rimer: A Guide To Understanding Embedded Memory Repair Options and Issues
No ratings yet
Emory Epair Rimer: A Guide To Understanding Embedded Memory Repair Options and Issues
24 pages
GENUS-MODUS-LBIST Lab 20.10
No ratings yet
GENUS-MODUS-LBIST Lab 20.10
59 pages
GENUS-MODUS-LBIST - Overview 23.10
No ratings yet
GENUS-MODUS-LBIST - Overview 23.10
120 pages
Systemverilog 2-State Simulation Performance and Verification Advantages
100% (1)
Systemverilog 2-State Simulation Performance and Verification Advantages
45 pages
ATPG - Stuck-At and At-Speed - Semicon Shorts
100% (1)
ATPG - Stuck-At and At-Speed - Semicon Shorts
4 pages
SpyGlass MBIST Reference
No ratings yet
SpyGlass MBIST Reference
86 pages
LowPower Ref
No ratings yet
LowPower Ref
596 pages
CPF File
No ratings yet
CPF File
108 pages
DFTC1 2007.12 LabGuide-đã Chuyển Đổi
100% (1)
DFTC1 2007.12 LabGuide-đã Chuyển Đổi
123 pages
Fault Simulation
No ratings yet
Fault Simulation
13 pages
Low-Power Design and Test, Lecture 8
No ratings yet
Low-Power Design and Test, Lecture 8
35 pages
Design For Test by Alfred L Crouch
100% (1)
Design For Test by Alfred L Crouch
117 pages
Accessug
No ratings yet
Accessug
136 pages
ABCs of Synthesis Part One
100% (1)
ABCs of Synthesis Part One
37 pages
Et Ref Testpatterns
No ratings yet
Et Ref Testpatterns
338 pages
Route Opt Cheat Sheet 2007 12 Customer v1
No ratings yet
Route Opt Cheat Sheet 2007 12 Customer v1
25 pages
Asic Design Flow
No ratings yet
Asic Design Flow
2 pages
DFT Adviser PDF
No ratings yet
DFT Adviser PDF
445 pages
Sdc under DFT
100% (1)
Sdc under DFT
8 pages
Tessent Memorybist and Logicbist
100% (1)
Tessent Memorybist and Logicbist
11 pages
GenusTutorial PDF
No ratings yet
GenusTutorial PDF
13 pages
DFT 2006.06 SG 02 Ui
No ratings yet
DFT 2006.06 SG 02 Ui
34 pages
Synopsys
No ratings yet
Synopsys
3 pages
VC SpyGlass CDC Quick Start Guide
No ratings yet
VC SpyGlass CDC Quick Start Guide
28 pages
Cadence Modus DFT Software Solution - Cadence
100% (1)
Cadence Modus DFT Software Solution - Cadence
13 pages
Tessent Command Study Notes
No ratings yet
Tessent Command Study Notes
4 pages
Is Hold Always Checked On The Same Edge - PDF
No ratings yet
Is Hold Always Checked On The Same Edge - PDF
3 pages
dftxg1 PDF
No ratings yet
dftxg1 PDF
514 pages
WA1.3 Bhat Paper
100% (1)
WA1.3 Bhat Paper
16 pages
DFT Tutorial PDF
No ratings yet
DFT Tutorial PDF
5 pages
Logic synthesis Standard Requirements
From Everand
Logic synthesis Standard Requirements
Gerardus Blokdyk
No ratings yet
modus_ug_testmodes
No ratings yet
modus_ug_testmodes
279 pages
modus_ug_testvectors
No ratings yet
modus_ug_testvectors
96 pages
modus_ug_teststructures
No ratings yet
modus_ug_teststructures
265 pages
Et Ug Pmbist
No ratings yet
Et Ug Pmbist
40 pages
Etpll User
No ratings yet
Etpll User
172 pages
Third Party
No ratings yet
Third Party
74 pages
Iris-70
No ratings yet
Iris-70
1 page
Perl - 18 - Installing and Using Perl Modules
No ratings yet
Perl - 18 - Installing and Using Perl Modules
7 pages
Export Kalinga Calacatta Brochure
No ratings yet
Export Kalinga Calacatta Brochure
54 pages
MGC Lic RN
No ratings yet
MGC Lic RN
8 pages
MGC Licen
No ratings yet
MGC Licen
95 pages
EC 5.network Theory
No ratings yet
EC 5.network Theory
262 pages
Ijtag Ieee 1687
No ratings yet
Ijtag Ieee 1687
29 pages
Shri Mata Vaishno Devi University: Entry - No Student - Name Cgpa Sgpa
No ratings yet
Shri Mata Vaishno Devi University: Entry - No Student - Name Cgpa Sgpa
3 pages
Perl 05 Subroutines
No ratings yet
Perl 05 Subroutines
42 pages
TDS Tutorial - 2020 June
No ratings yet
TDS Tutorial - 2020 June
10 pages
Affidavit For Inclusion of Spouse Name On The Passport) (To Be Notorised On Non-Judicial Paper With Minimum Value)
No ratings yet
Affidavit For Inclusion of Spouse Name On The Passport) (To Be Notorised On Non-Judicial Paper With Minimum Value)
1 page
Institute Name: Shri Mata Vaishno Devi University (IR-O-U-0201)
No ratings yet
Institute Name: Shri Mata Vaishno Devi University (IR-O-U-0201)
18 pages
Institute Name: Shri Mata Vaishno Devi University (IR-E-U-0201)
No ratings yet
Institute Name: Shri Mata Vaishno Devi University (IR-E-U-0201)
14 pages
Institute Name: Shri Mata Vaishno Devi University (IR-E-U-0201)
No ratings yet
Institute Name: Shri Mata Vaishno Devi University (IR-E-U-0201)
7 pages
P1450.3 Ieee Standardtest Interface Language (Stil) Extension For Tester Resource Constraints (TRC)
No ratings yet
P1450.3 Ieee Standardtest Interface Language (Stil) Extension For Tester Resource Constraints (TRC)
60 pages
ICB-2 Software Test Engineer: Job Description
No ratings yet
ICB-2 Software Test Engineer: Job Description
2 pages
Agoda BID332218533
No ratings yet
Agoda BID332218533
1 page
Job Title: Applications Consultant - DFT Job Location: India - Bangalore Job Category: Sales Exp: 7 To 15 Years Job Duties
No ratings yet
Job Title: Applications Consultant - DFT Job Location: India - Bangalore Job Category: Sales Exp: 7 To 15 Years Job Duties
2 pages
Shree Nath Vyas: Internships Education
No ratings yet
Shree Nath Vyas: Internships Education
1 page
28n v1 0 IO Usage Guidelines
No ratings yet
28n v1 0 IO Usage Guidelines
44 pages
Bist Clock Gating
No ratings yet
Bist Clock Gating
1 page
Bugcrowd Vulnerability Rating Taxonomy 1.10
No ratings yet
Bugcrowd Vulnerability Rating Taxonomy 1.10
14 pages
Testing Adjusting Power Train D3B Cat
100% (1)
Testing Adjusting Power Train D3B Cat
23 pages
Rac MCQ
No ratings yet
Rac MCQ
78 pages
MODEL 131 Backfill Tamper: Specifications
No ratings yet
MODEL 131 Backfill Tamper: Specifications
1 page
Canon Ir2018 2030 Manuel D Utilisation
No ratings yet
Canon Ir2018 2030 Manuel D Utilisation
8 pages
Digitizing Contours in Petrel
No ratings yet
Digitizing Contours in Petrel
6 pages
TPSEC02
No ratings yet
TPSEC02
22 pages
2 Resort Hotel
No ratings yet
2 Resort Hotel
4 pages
DIP Chap 4 (Filtering in The Frequency Domain) Lect 11
No ratings yet
DIP Chap 4 (Filtering in The Frequency Domain) Lect 11
45 pages
Silo - Tips - Neuro Fuzzy Inference System For e Commerce Website Evaluation
No ratings yet
Silo - Tips - Neuro Fuzzy Inference System For e Commerce Website Evaluation
5 pages
Hydrophore and Calorifier
No ratings yet
Hydrophore and Calorifier
13 pages
UNIT V
No ratings yet
UNIT V
30 pages
Amazon A-Z Launch: Project Proposal
No ratings yet
Amazon A-Z Launch: Project Proposal
5 pages
Augmenting The Effective Field of View of Optical Tracking Cameras - A Way To Overcome Difficulties During Intraoperative Camera Alignment
No ratings yet
Augmenting The Effective Field of View of Optical Tracking Cameras - A Way To Overcome Difficulties During Intraoperative Camera Alignment
6 pages
27 Computer Programming CS100 Syllabus
No ratings yet
27 Computer Programming CS100 Syllabus
2 pages
Mcots-Dc Brochure
No ratings yet
Mcots-Dc Brochure
8 pages
Single-Shaft Shredder in Recycling Systems: Pallmann Maschinenfabrik GMBH & Co. KG
No ratings yet
Single-Shaft Shredder in Recycling Systems: Pallmann Maschinenfabrik GMBH & Co. KG
5 pages
Vci 76364660
No ratings yet
Vci 76364660
4 pages
Chapter 10 Computer Based Supply Chain Management and Information Systems Integration PDF
No ratings yet
Chapter 10 Computer Based Supply Chain Management and Information Systems Integration PDF
26 pages
4.5V To 25V Input, 1ch Synchronous Buck DC/DC Controller: Datasheet
No ratings yet
4.5V To 25V Input, 1ch Synchronous Buck DC/DC Controller: Datasheet
24 pages
NO - PW-JD/E-Tender/2023-24:, Dated 3
No ratings yet
NO - PW-JD/E-Tender/2023-24:, Dated 3
3 pages
Lab 2
No ratings yet
Lab 2
7 pages
Professional Practice in Interior Design
No ratings yet
Professional Practice in Interior Design
23 pages
ISO 27701 Service Sheet
No ratings yet
ISO 27701 Service Sheet
2 pages
Hollister - Abercrombie Refund Guide, by ScamMan
No ratings yet
Hollister - Abercrombie Refund Guide, by ScamMan
3 pages
Kami Export - Kami Tool Guide
No ratings yet
Kami Export - Kami Tool Guide
5 pages
Curriculum of Competency Unit (Cocu)
No ratings yet
Curriculum of Competency Unit (Cocu)
11 pages
Major Project Report
0% (1)
Major Project Report
63 pages