Modus Ug Pmbist

Modus: Guide 8: PMBIST
Product Version 18.11

August 2018
© 2003–2018 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.
Contents
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
List of Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Modus Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Getting Help for Modus and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Extended Command and Message Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contacting Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Modus and Diagnostics Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Modus Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1
Inserting Programmable MBIST Logic . . . . . . . . . . . . . . . . . . . . . . . . . 19
Inserting PMBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Prerequisite PMBIST Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Genus Synthesis Solution Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
PMBIST Interface Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
PMBIST Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
August 2018 3 Product Version 18.11

© 2003-2018 Cadence Design Systems, Inc. All Rights Reserved.
2
PMBIST Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Design Flow into Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Tester Description Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Create Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Pattern Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
CET Custom Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Setup for Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Selecting Keys for Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Scheduling Selected Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Write Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Pattern Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Direct Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
1149 TAP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Design Verification Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Pattern Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
1149 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Manufacturing Test Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pattern-related Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3
Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
How PMBIST Affects Static Timing in a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
PMBIST Module-level Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Design Timing with PMBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4
Boolean Equivalence Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Block Level Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Chip Level Insertion Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Multiple Block Merging Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5
Design Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Getting to Modus PMBIST Pattern Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Simulation Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
PMBIST Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
ROM Data Load Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Design and Technology Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Analyzing Pattern Class Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
irun to analyze_embedded_test Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
irun to CPP to analyze_embedded_test Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Special Handling of Four pin TAP controller in Simulation . . . . . . . . . . . . . . . . . . . . 101
Injecting Memory Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Changes in the Verilog Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Fault Injection Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Understanding analyze_embedded_test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Executing the Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Working with Simulation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Working with CPP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Analyzing and Debugging PMBIST Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . 114
Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
PMBIST Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Memory Connections and Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
PMBIST Comparators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Determining Miscomparing Registers from Simulation Logs . . . . . . . . . . . . . . . . . . 141
A
Customizing PMBIST Memory View and Configuration Files .
145
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Memory View File Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Configuration File Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

module Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

port_alias Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
port_action Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
address_limit Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
read_delay Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
data_order Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
write_mask_binding Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
address_partition Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
wrapper Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
redundancy Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
macro Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
name Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
port_access Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
port_alias Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
port_action Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
assertion_limit Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
memory_map Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
algorithm_constraints Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
algorithm Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
testplan Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
sharing_limit Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
clock Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
location Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
failure_recording Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
interface_control Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
testplans Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
ignore Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Memory View File Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Configuration File Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

List of Figures
Figure 1-1 PMBIST Preview Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 1-2 PMBIST Chip-level Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 1-3 PMBIST Block Insertion Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 2-1 Programmable Memory Built-In Self-Test Process Flow . . . . . . . . . . . . . . . . . 52
Figure 2-2 Custom Schedule Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 2-3 Scheduler Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 2-4 Loading Design Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 2-5 Selecting Keys for Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 2-6 Schedule Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 2-7 Warning of Scheduling Constraint Violation. . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 2-8 1149 TAP Access Production Pattern Abstract View. . . . . . . . . . . . . . . . . . . . 75
Figure 2-9 1149 TAP Access ROM Production Pattern Abstract View . . . . . . . . . . . . . . . 76
Figure 2-10 Production Pattern Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 3-1 PMBIST Timing Domain Crossings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 3-2 PMBIST Timing Cross-Domain Interference . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 5-1 Programmable Memory Built-In Self-Test Design Verification Flows. . . . . . . . 97
Figure 5-2 Verilog Memory Model Changes Supporting Fault Injection . . . . . . . . . . . . . 102
Figure 5-3 Verifying Proper seq_udp_delay Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 116
Figure 5-4 Viewing test cycle and pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 5-5 mainsim.v Header Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 5-6 Test Control Signal Stability Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Figure 5-7 Clock Controllability for JTAG Access Only . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 5-8 Clock Controllability for Direct Access Only . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 5-9 Clock Frequency Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 5-10 JTAG Concerns for hardwired testplans . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure 5-11 JTAG Concerns for programmed testplans . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 5-12 Direct Access Concerns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 5-13 Proper Startup Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Figure 5-14 Write Operation Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Figure 5-15 Read Operation Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure 5-16 Actual and Expect Data Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Figure 5-17 Done Register and Summary Failure Register Inspection . . . . . . . . . . . . . . 140
Figure 5-18 Analyzing Simulation Log Failing Registers . . . . . . . . . . . . . . . . . . . . . . . . . 143
Figure A-1 Memory with internal bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Figure A-2 read_delay 1 - asynchronous memory read timing . . . . . . . . . . . . . . . . . . . . 161
Figure A-3 read_delay 2 - synchronous memory read timing (default) . . . . . . . . . . . . . . 162
Figure A-4 read_delay 3 - memory with data output register read timing . . . . . . . . . . . . 162
Figure A-5 Linear Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Figure A-6 Muxed Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Figure A-7 Banked Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure A-8 Simple Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure A-9 Banked row and column redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figure A-10 Banked row and bit redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Figure A-11 Banked row redundancy with physical order variation. . . . . . . . . . . . . . . . . 186

List of Tables
Table 1-1 JTAG Instructions and Registers to Access PMBIST Logic . . . . . . . . . . . . . . . 21
Table 1-2 PMBIST Flow Options at Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Table 1-3 Memory cell/Wrapper pin usage status. [PMBIST-31] . . . . . . . . . . . . . . . . . . . 43
Table 1-4 Summary table for read_pmbist_memory_view. [PMBIST-41] . . . . . . . . . . . . . 43
Table 1-5 Summary table for algorithm constraints [PMBIST-42] . . . . . . . . . . . . . . . . . . . 44
Table 1-6 Memory Target and programmable BIST Engine Summary [PMBIST-21] . . . . 45
Table 1-7 PMBIST area overhead summary table [PMBIST-32]. . . . . . . . . . . . . . . . . . . . 46
Table 1-8 PMBIST area comparison table. [PMBIST-33] . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 2-1 createpatterns Option Relationship to Scheduling Options. . . . . . . . . . . . . . . . 60
Table 2-2 Scheduling Option Value Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 2-3 Assign File Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Table 2-4 Mode Initialization Sequence Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 2-5 Block and Chip Level Pattern Class Support . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 5-1 Design Verification Pattern Class Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 5-2 Memory Model Fault Injection Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Table 5-3 PMBIST SRAM Failure Indication Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Table A-1 Recognized Liberty File Base Port Names . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Table A-2 Internally Built-in Aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155


List of Examples
Example 2-1 ROM file containing binary data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Example 2-2 ROM file containing hexadecimal data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Example 2-3 Using the romdatamapfile option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


Preface
About This Manual

This manual describes the entire flow of programmable memory built-in self-test logic starting
from the insertion of the programmable memory built-in self-test logic within a design using
Design For Test in Genus Synthesis Solution followed by its pattern generation and
subsequent verification through simulation of testbenches generated using Modus.
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.

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

Preface
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

Preface
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 {option option}... provides the help for any valid option that
you request. For example, build_model help=designsource, cell 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.
■ 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
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

Preface
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 edahelp@us.ibm.com.
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.

Preface

1
Inserting Programmable MBIST Logic
■ Inserting PMBIST on page 20

❑ Prerequisite PMBIST Files on page 20
❑ Genus Synthesis Solution Prerequisites on page 20
❑ Design Flows on page 24
❍ Using the PMBIST Bottom-Up Flow on page 24
❍ PMBIST Preview Flow on page 26
❍ PMBIST Chip-level Insertion Flow on page 30
❍ PMBIST Block Insertion Flow on page 36
❑ PMBIST Interface Files on page 41
❑ PMBIST Reports on page 43

Inserting PMBIST
Depending upon the flow you choose, some PMBIST-specific input files are required prior to
inserting PMBIST in a design:
■ The PMBIST memory view file
■ The PMBIST configuration file
■ The PMBIST interface files
Other input files are required regardless of the selected flow: the memory module Liberty files
and the design description. Finally, certain Genus Synthesis Solution commands, attributes,
and constraints may be necessary to ensure proper insertion and controllability. The insertion
command itself must be constructed based on the prerequisites and the chosen design flow.
Prerequisite PMBIST Files

The memory view file contains the information about the memories used in the design. It
contains the description of the features defining the memory devices and possible memory
module and logic module wrapper found in the design. Refer to Appendix A, “Customizing
PMBIST Memory View and Configuration Files” for more details.
The configuration file contains the directives that control the insertion of PMBIST logic into
the netlist. It allows control over the characteristics of the PMBIST AMU (Algorithm Memory
Unit), SIU (Sequence Iterator Unit) and target memory collars, and the assignment of SIU to
target memories. Refer to Appendix A, “Customizing PMBIST Memory View and
Configuration Files” for more details.
PMBIST interface files are generated by write_dft_pmbist_interface_files

command as part of the chosen design flow. These files represent an abstract model of the
PMBIST structures inserted in a block. These interface files can then be used to integrate this
block into another level of a design hierarchy, carrying the PMBIST information forward in the
bottom-up flow. In such cases, read_dft_pmbist_interface_files is used to import
the abstract models and identify the abstract models of one or more blocks in this design with
PMBIST logic already inserted.
Genus Synthesis Solution Prerequisites

Before you start the PMBIST insertion, you must read in the libraries (including the Liberty
files for the memories in the design), PMBIST memory view file(s), and the design.
You must define the test signal used by PMBIST using the define_test_mode command
is required. Use the define_dft_cfg_mode command to describe this to Genus. If the test

signal is actually the decode of several mode control pins, a DFT configuration mode for
PMBIST use with the define_dft_cfg_mode command. Refer to the add pmbist
command for more information.
If you use a JTAG macro to access the PMBIST logic, define the JTAG instruction register and
the instructions used by PMBIST with the define_jtag_instruction_register and
define_jtag_instruction constraints, respectively. The JTAG macro must be built with
the PMBIST-specific user-defined instructions and their respective test data registers. The
test data registers inserted during PMBIST are required to access the PMBIST controllers.
Depending upon the desired level of PMBIST diagnostics, redundancy analysis, self-repair,
and the presence of read-only memories, additional user-defined instructions might be
required. You must specify these instructions prior to inserting PMBIST logic. The instructions
and registers have default names as shown in Table 1-1 on page 21. To change the default
names, use the define_jtag_instruction constraints. The new instruction names must
also be specified to the add_pmbist command.
Note: You must not specify the -private option when you use the
define_jtag_instruction command to define any PMBIST-related instruction.
Table 1-1 JTAG Instructions and Registers to Access PMBIST Logic
Instruction Test Data Register

Comments
(Default Name) (Default Name)
MBISTTPN MBISTTPN Required instruction and register for testplan
selection.
MBISTSCH MBISTSCH Required instruction and register for PMBIST
scheduling.
MBISTCHK MBISTCHK Required instruction and register for results
checking.
MBISTAMR MBISTAMR (Optional) instruction and register for
algorithm programming. Specified if
programmed testplan is used.
MBISTROM MBISTROM (Optional) instruction and register for testing
ROMs by programmed testplan.
MBISTDIAG MBISTDIAG (Optional) instruction and register for PMBIST
diagnostics. Specified if diagnostics is
desired.

Instruction Test Data Register

Comments
(Default Name) (Default Name)
MBISTROMDIAG MBISTROMDIAG (Optional) instruction and register for ROM
diagnostics. Specified if ROM diagnostics is
desired.
When the PMBIST logic is accessed and controlled via a JTAG macro which is IEEE 1149.x
compliant, you must insert the JTAG macro into your design. You can do so prior to or
following PMBIST logic insertion.
You can insert the JTAG macro using either the

■ add_jtag_boundary_scan command
■ Use the insert_dft boundary_scan command to insert the JTAG macro logic, the
boundary scan cells, and to build the boundary register chain.
■ add_jtag_macro command.
Use the add_jtag_macro command to insert only the JTAG macro logic.
Use the -connect_to_jtag option of the add_pmbist command to indicate that the
JTAG macro is already present in the design and the PMBIST logic should connect to it when
inserted.
Use the -dont_create_pmbist_ports option of the add_pmbist command to indicate

that PMBIST insertion is occurring at the top design level but no JTAG macro is yet present
in the design for PMBIST connection.
In situations where the JTAG macro is not present in the design when PMBIST is inserted at
the top design level, you must identify the TAP connections for the PMBIST logic using either
read_dft_jtag_boundary_file or define_jtag_tap_port.
When you use the direct access mechanism to access PMBIST, the required design ports
must already exist and be defined prior to executing add_pmbist. Use the define_
pmbist_direct_access command to define the ports. If you use the direct access
mechanism without the JTAG access mechanism, you must specify the
-direct_access_only option with the add_pmbist command to insert PMBIST.
You must define all MBIST clock sources using the define_mbist_clock constraint prior
to using them with the add_pmbist command. These mbist_clock objects are referenced
in the add_pmbist configuration file target sections using the clock Specification statement.
You can find the objects created by the define_mbist_clock constraints in:
/designs/design/dft/mbist/mbist_clocks

One Genus Synthesis Solution attributes may also require attention: instance attribute
pmbist_instruction_set. In a bottom-up design flow, when a block which has PMBIST
is instantiated into a higher level design, the user can identify the set of PMBIST instructions
which should be used with each instance.

Design Flows
The desired design flow is inferred by the PMBST insertion commands by the use of the
following add_pmbist command line options. Only the valid combinations are listed in
Table 1-2. The unlisted combinations cause an error during execution.
Table 1-2 PMBIST Flow Options at Insertion
dont_create_pmbist connect_to_j direct_access_o

_ports tag nly
no no no block level processing create PMBIST

internal JTAG and direct access design
ports
no yes no chip level processing connect PMBIST to
pre-existing JTAG macro
yes no no chip level processing JTAG macro
inserted and connected to PMBIST after
PMBIST insertion
do not create PMBIST internal JTAG and
direct access design ports
no no yes block level processing create PMBIST
internal JTAG (unused) and direct access
design ports
yes no yes chip level processing assumes that JTAG
macro may be inserted but not connected
to PMBIST.
do not create PMBIST internal JTAG and
direct access design ports
In the following design flow diagrams, the step labels are consistent. An explanation of these
step labels when relevant to the PMBIST insertion is included after each flow.
Using the PMBIST Bottom-Up Flow
The bottom-up flow enables progressive insertion and verification of DFT structures within
each specific design partition as it is created. The methodology first requires executing the
PMBIST flow shown in Figure 1-3 on page 36 with block-level insertion of structures and

excluding insertion of boundary-scan or JTAG_Macro logic. The

write_dft_pmbist_interface_files command will produce interface files to be used
as input for the next block-level PMBIST flow. The top-level iteration includes insertion of
boundary-scan or JTAG_Macro logic to stitch together the entire design and the need to
execute the read_dft_pmbist_interface_files command to include the interface
files from all of the instantiated blocks in which PMBIST was previously inserted.
As each PMBIST-inserted block is included in a higher level of design hierarchy, you can
re-assign the JTAG-accessed PMBIST instruction set for each instance of the block using the
pmbist_instruction_set instance attribute. This requires individual scheduling of
PMBIST logic in each of the unique instruction sets. It also allows the blocks to be merged
into one or more instruction sets only at the top level of the design.
The module file names produced by block-level insertion must be controlled with the
-module_prefix option. This option avoids overwriting existing module files over the
course of successive iterations. For example, specify -module_prefix block1 to append
the default name of tem with temblock1.
Flows
■ PMBIST Preview Flow on page 26
■ PMBIST Chip-level Insertion Flow on page 30
■ PMBIST Block Insertion Flow on page 36
Note: The PMBIST flows are demonstrated in the Rapid Adoption Kit (RAK) for
Programmable Memory Built-In-Self-Test (PMBIST). To download the RAK for PMBIST:
a. Go to http://support.cadence.com
b. From the Resources menu select Rapid Adoption Kits
c. Select Synthesis, Test and Verification flow
d. Download Modus and Genus Synthesis Solution: Programmable Memory

Built-In-Self-Test (PMBIST)

PMBIST Preview Flow
Figure 1-1 PMBIST Preview Flow
Start
Read libraries, HDL files, SDC
Elaborate
Define test related control signals

Define DFT configuration
Define MBIST clocks

Define PMBIST access
Generate PMBIST memory
Update view file if necessary
Read PMBIST memory view
Run DFT rule checker

Fix DFT violations
Task added
Generate PMBIST
Optional task
Write DB data
Update configuration file if PMBIST task
Test PMBIST insertion using
Check tables, errors,
Load DB data

PMBIST Preview Flow Steps
The PMBIST preview flow is used to enable the generation of the memory view file (if not
provided by the memory vendor), PMBIST configuration file, and (to perform) early phase
analysis of a post-elaborate design. Refer to the labs in the PMBIST RAK for the
demonstration of the PMBIST preview flow.
1. Specify the test signal(s) that control PMBIST.
❑ Define test-related test signal(s):
❑ define_test_mode -name test_signal_name...
❑ Use pmbist_use attribute to specify how the test signal should be used to control the
Programmable MBIST logic during ATPG. (Link reference to attribute)
set_db pmbist_use ...
for example:
set_db test_signal:TopBlock/TopBlock_test_enable .pmbist_use
test_rambypass
❑ In case of low power clock gating being utilized, use the following attribute to specify
the specific test-control signal used for clock-gating instances in the design.
PMBIST utilizes the following attribute and uses it for connecting to the test pins of
clock-gating instances within the PMBIST logic.
set_db lp_clock_gating_test_signal test_signal ...
2. If the test signal is the decode of several mode control pins, define DFT configuration
mode(s) for PMBIST.
define_test_mode -name test_signal_name...
define_shift_enable -name test_signal_name ...
...
define_dft_cfg_mode -name pmbist_cfg_mode ...
3. Define the MBIST clocks prior to referencing them in the PMBIST configuration file.
define_mbist_clock -name mbist_clock ...
Refer to clock Specification in Appendix A, “Customizing PMBIST Memory View and

Configuration Files” for more information.
Note: If the JTAG access method has been selected, define JTAG TCK as an MBIST
clock with the -is_jtag_tck option.
define_mbist_clock -name mbist_jtag_tck -is_jtag_tck ...
4. Define PMBIST access method(s). Either JTAG access, direct access, or both
❑ Define the PMBIST direct access interface pins or ports if direct access to the
PMBIST logic is desired.

define_pmbist_direct_access -function string ...
For more information on the function of the interface pins, refer to and the description
of the define_pmbist_direct_access command.
❑ Define the JTAG instruction register and PMBIST-specific instructions (see Table 1-1
on page 21) if JTAG access to PMBIST is desired.
define_jtag_instruction_register -name string ....
define_jtag_instruction -name string ...
...
Note: Use the define_jtag_macro command to define a pre-existing JTAG macro.

Any PMBIST required JTAG instructions must be defined using
define_jtag_instruction prior to insertion.
5. Generate the PMBIST memory view template using the preview option.
read_pmbist_memory_view -preview ...
6. Update memory view file if necessary.

Memory view file supplies information related to the memories in the design and
supplement the information available in the Liberty files. Refer to module Group in
Appendix A, “Customizing PMBIST Memory View and Configuration Files” for more
information.
7. Read PMBIST memory view file.
read_pmbist_memory_view -config_view_file ...
Verify the memory view file, making corrections and modifications as necessary to
correctly reflect actual memories. Use the warning and error message(s) in the log file
related to read_pmbist_memory_view to make changes where information is missing or
misunderstood.
8. Run DFT rule checker prior to insertion.
check_dft_rules...
Any DFT violation should be understood and fixed if necessary.

9. Generate PMBIST configuration file template to refine the PMBIST insertion process
add_pmbist -preview -dft_cfg_mode mode ...
Note: In case of using non-JTAG access method, use -alt_dft_configuration_mode

option to specify the configuration mode in which PMBIST will be operating.
10. Write DB data prior to PMBIST insertion.
write_db -to_file db_file ...
11. Update the configuration file if necessary.

Verify the configuration file, making corrections and modifications as necessary to

achieve the desired results. Use the warning and error messages in the log file related
to PMBIST insertion to make changes where information is missing or misunderstood.
12. Test PMBIST insertion.
add_pmbist -dft_cfg_mode mode -config_file config_file ...
The configuration file controls how Programmable MBIST logic being inserted into the
design. Refer to target Group in Appendix C, “Customizing PMBIST Memory View and
Configuration Files,” for more information.
13. Read previously saved DB data.
To create final configuration file, conditional experiment(s) are needed by loading
previously saved DB data file. It is recommended to check tables, warning, error reported
in the log file and go back to update configuration file step. Refer to “PMBIST Reports”
on page 43 for more information about tables generated by PMBIST.
14. Create the final configuration file.
The final configuration file lists the targeted memory instances or modules and their test
options. Refer to Appendix C, “Customizing PMBIST Memory View and Configuration
Files,” for details.

PMBIST Chip-level Insertion Flow
Figure 1-2 PMBIST Chip-level Insertion Flow

Start
Elaborate
Define test related control signals

Define MBIST clocks

Read memory views
Read PMBIST interface files
Fix DFT violations
Add testability logic
Scenario 1 Scenario 2
Insert boundary scan logic Insert JTAG Macro logic
Insert PMBIST logic

Task added
Write PMBIST interface files Optional task
Create Verilog testbenches to
PMBIST task
Run DFT ruledesign
Synthesize checkertoon MBIST
generic
Perform ATPG analysis and LEC

Check
Connect scan chains

Write PMBIST interface files

PMBIST Chip-level Flow Steps
The PMBIST chip-level insertion flow can be used to insert PMBIST logic in the entire design
at one point in time as part of top-down test synthesis flow. It can also be used as final
integration of the BISTed blocks at chip-level when a multi-block bottom-up approach is taken.
Refer to Lab 1 and 2 in PMBIST RAK for demonstration of the top-down flow using JTAG and
direct access methods. Refer to Lab 3 in PMBIST RAK for demonstration of chip-level
processing in a multi-block bottom-up flow.
❑ Define test-related test signal(s):
❑ define_test_mode -name test_signal_name...
Programmable MBIST logic during ATPG.
for example:
set_db test_signal:TopBlock/TopBlock_test_enable .pmbist_use
test_rambypass
PMBIST utilize the following attribute and use it for connecting to the test pins of
clock-gating instances within the PMBIST logic.
mode(s) for PMBIST.
define_test_mode -name test_signal_name ...
define_test_mode ...
...
define_dft_cfg_mode -name pmbist_cfg_mode ...
Refer to clock Specification inAppendix A, “Customizing PMBIST Memory View and

Configuration Files” for detailed information.
clock with -is_jtag_tck option.
4. Define PMBIST access method(s).

❑ (Optional) Define the PMBIST direct access interface pins or ports if direct access
to the PMBIST logic is desired.
For more information about the function of the interface pins, refer to the description
...
Note: Use the pmbist_instruction_set instance attribute for instantiated and

PMBIST-inserted blocks to reassign the PMBIST logic to different JTAG-accessed
PMBIST instruction sets.
Refer to “PMBIST Access Mechanisms” on page 604 for more information.
5. Read memory view files.
read_pmbist_memory_view -cdns_memory_view__file nput_file_name ...
correctly reflect actual memories. Refer to the warning and error message(s) in the log
file of the read_pmbist_memory_view command to update the memory view files as
required (refer to the later PMBIST report section).
6. (Optional) Read PMBIST interface files required for multi-block bottom-up flow.
read_dft_pmbist_interface_files -directory string ...
Note: PMBIST chip-level insertion flow could either serves as a top-down insertion flow
excluding execution of read_dft_pmbist_interface_files, or a chip-level iteration in
multi-block bottom-up flow using read_dft_pmbist_interface_files to import interface
files form all of the instantiated block(s) in which PMBIST was previously inserted. For
more information about the generation of PMBIST interface files at block-level, refer to
write_dft_pmbist_interface_files step in Figure 1-3 on page 36.
7. (Optional) Insert JTAG or boundary scan logic if JTAG access has been selected.
❑ Insert boundary scan logic.
add_jtag_boundary_scan ...
For more information, refer to “Inserting Boundary-Scan Logic” on page 503.

❑ Insert the JTAG macro.
add_jtag_macro ...

For more information, refer to section Inserting a JTAG Macro in Genus Design for
Test Guide for Common UI.
8. Insert PMBIST logic.
When a JTAG macro is already instantiated and you also optionally want to use the direct
access mechanism, use
add_pmbist -config_file config_file -connect_to_jtag...
When a JTAG macro will be inserted after PMBIST insertion and you also optionally want
to use the direct access mechanism, use
add_pmbist -config_file config_file -dont_create_pmbist_ports...
When only the direct access option is used, use

add_pmbist [-config_file config_file] -direct_access_only ...
Refer to “PMBIST Flow Options at Insertion” on page 24 for more information.

9. Write PMBIST interface files and testbench to allow early verification of inserted PMBIST
logic. Full PMBIST verification is recommended to optimize the simulation runtime.
10. Run DFT rule checker.
check_dft_rules ...
11. Connect scan chains.

connect_scan_chains ...
Note: Configure and connect scan chains post PMBIST insertion to include PMBIST
logic as part of design scan structure. For more information, refer to section Running the
Scan Configuration in Genus Design for Test Guide for UICommon.
12. Write PMBIST interface files.
write_dft_pmbist_interface_files -directory string ...
PMBIST interface files represent an abstract model of the current PMBIST insertion
process, supporting not only multi-block bottom-up flow for incremental PMBIST
insertion but also the generation of patterns to exercise the PMBIST logic from Modus
create_embedded_test command.
13. Generate the Verilog test benches and simulation scripts that allow verification of the
inserted PMBIST logic.
write_dft_pmbist_testbench ...
Note: Use -create_embedded_test_options to specify extra options to apply

when running Create Embedded Test in Modus. If only the generation of scripts is
required, set genscriptsonly option to yes option to avoids actually executing of the
generated scripts.

write_dft_pmbist_testbench \
-create_embedded_test_options {-genscriptsonly yes ...} \
...
See Chapter 2, “PMBIST Pattern Generation” for more information.

PMBIST Block Insertion Flow
Figure 1-3 PMBIST Block Insertion Flow

Start
Elaborate
Define test related control signals Iterate insertions

for each design
Define MBIST clocks

Read memory view
Read PMBIST interface files
Fix DFT Violations
Add testability logic
Insert PMBIST block-level
Write PMBIST interface files Task added
Optional task
Synthesize design to generic
PMBIST task
LEC
Perform ATPG analysis and Check
Connect scan chains

Write PMBIST interface files

PMBIST Block Insertion Flow Steps
The PMBIST block insertion flow is used to insert PMBIST logic into portions of the final
design incrementally using block-level insertion. This can be performed repetitively as the
design hierarchy grows until the final integration at chip-level. Refer to Lab 3 in PMBIST RAK
for the demonstration of the PMBIST block-level insertion flow.
❑ Define test related control signl(s):
define_test_mode -name test_signal_name ...
Programmable MBIST logic during ATPG.
PMBIST utilize the following attribute and allow Genus Synthesis Solution
connecting to the test pins of clock-gating instances.
mode(s) for PMBIST.
define_test_mode -name test_signal_name...
define_test_mode ...
...
define_dft_cfg_mode -name pmbist_configuration_mode....
Refer to clock Specification in Appendix A, “Customizing PMBIST Memory View and

Configuration Files” for more information.
clock with -is_jtag_tck option.
4. Define PMBIST access method(s).

❑ (Optional) Define the PMBIST direct access interface pins or ports if direct access
to the PMBIST logic is desired.
For more information about the function of the interface pins, refer to the description

...
5. Read memory view.

read_pmbist_memory_view -cdns_memory_view_file config_file ...
correctly reflect actual memories. Refer to the warning and error message(s) in the log
file of the read_pmbist_memory_view command to update the memory view files as
required (refer to the later PMBIST report section).
6. (Optional) Read PMBIST interface files.
read_dft_pmbist_interface_files ‘-directory string ...
Note: At block-level, use read_dft_pmbist_interface_files to include interface files

form all of the instantiated block in which PMBIST was previously inserted. The
pmbist_instruction_set attribute is NOT applicable to non-chip-level instance.
7. Insert PMBIST logic.

When a JTAG macro might be inserted after PMBIST insertion and you also optionally
want to use the direct access mechanism, use
add_pmbist -config_file config_file
-module_prefix string...
When only the direct access option is used, use

add_pmbist -config_file config_file -direct_access_only
-module_prefix string...
8. Write PMBIST interface files and testbench to allow early verification of inserted PMBIST
logic. Full PMBIST verification is recommended to optimize the simulation runtime.
9. Run DFT rule checker.
check_dft_rules...
10. Connect scan chains at block level.

connect_scan_chains ...
Note: Configure and connect scan chains post PMBIST insertion to include PMBIST
logic as part of design scan structure. For more information, refer to section Running the
Scan Configuration in Genus Design for Test Guide for Common UI.
11. Write PMBIST interface files.
write_dft_pmbist_interface_files -directory string ...

To support successive block level insertions, use the

read_dft_pmbist_interface_files command to include interface files for
instantiated blocks in which PMBIST has already been inserted.
12. Generate the Verilog test benches and simulation scripts that allow verification of the
inserted PMBIST logic.
write_dft_pmbist_testbench ...
Note: Use -create_embedded_test_options to specify extra options to apply

when running Create Embedded Test in Modus. If only the generation of scripts is
required, add -genscriptsonly yes option to avoids actually executing of the
generated scripts.
write_dft_pmbist_testbench \
-create_embedded_test_options {-genscriptsonly yes ...} \
...
See Chapter 2, “PMBIST Pattern Generation” for more information.

PMBIST Interface Files

PMBIST interface files are generated by executing
write_dft_pmbist_interface_files. These files represent an abstract model of the
PMBIST structures inserted in a block or chip. These interface files describe the PMBIST
structures inserted into the design. PMBIST interface files can then be either utilized by
Modus for pattern generation, or used to integrate BISTed block into another level of a design
hierarchy.
Each time you invoke the write_dft_pmbist_interface_files command, the

interface files are written to the directory specified by the required -directory option. The
files are named as follows:
■ design_pattern_control.txt contains the block’s PMBIST external interface and
pattern generation controls derived from the configuration file.
■ design_mbisttpn_tdr_map.txt identifies the MBISTTPN TDR definition.
■ design_mbistsch_tdr_map.txt identifies the MBISTSCH TDR definition.
■ design_mbistchk_tdr_map.txt identifies the MBISTCHK TDR definition.
■ design_mbistrom_tdr_map.txt identifies the MBISTROM TDR definition, when
ROM test is tested by programmed testplan.
■ design_mbistamr_tdr_map.txt identifies the MBISTAMR TDR definition, when
programed testplan(s) are required.
■ design_mbistdiag_tdr_map.txt identifies the MBISTDIAG TDR definition, when
diagnostic is required.
■ design_mbistromdiag_tdr_map.txt identifies the MBISTROMDIAG TDR
definition, when ROM diagnostic is required.
■ design_mbistrar_tdr_map.txt identifies the MBISTRAR TDR definition, when
self-repair is required.
■ design_test_def.txt contains the testplan information and calculated algorithm
constraints.
In case of the hierarchical integration, read_dft_pmbist_interface_files is used to

import interface files as abstract model(s) of one or more blocks instantiated in this design
with PMBIST logic already inserted. The -directory option is used to specify the directory
that contains the interface files. A set of interface files correlated to a particular design or
subdesign only need to be read in once even multiple instances exist. But, multiple executions
of read_dft_pmbist_interface_files are needed if multiple designs or subdesigns
are instantiated in the current design level.

In multi-block bottom-up flows, when multiple interface face file sets are processed, the
block-level files are merged into one or more interface file sets for the given design. One file
set is generated unless multiple PMBIST instruction sets are used. In the latter case, each
interface file is modified to include a non-zero positive integer index following the design
name. Later in Modus, create_embedded_test can generate patterns for a single
interface file set at each invocation.

PMBIST Reports
Prior to PMBIST insertion, the read_pmbist_memory_view command is used to load the
memory view files. After the read_pmbist_memory_view command has completed
analyzing the design memories and prior to the PMBIST-41 message, the tool reports a list
of all detected memory modules with the set of ports on each module and their disposition
during PMBIST. You can find these tables by searching for the PMBIST-31 message ID. Most
categories in the report are self-explanatory. Table 1-3 lists the report column headings and
associated data.
Table 1-3 Memory cell/Wrapper pin usage status. [PMBIST-31]
Memory/Wrapper
Base Port Name/Function Polarity Remarks
Port Name
port name {N/A, {N/A, {unused during BIST,

port_alias base_port_name, +, chip select, bist enable,
data read bus, -} bypass enable, output enable,
data write bus, write enable, write enable mask,
address bus, read enable, clock, address bus,
constant value} data read bus, data write bus,
connected to constant,
unconnected, unconnected and
unobserved}
You can find the summary table for read_pmbist_memory_view (see Table 1-4) by
searching for the PMBIST-41 message ID. This table indicates the status of the
read_pmbist_memory_view after processing the Liberty files and PMBIST memory view
file. It indicates if any problems exist with the memories targeted for PMBIST.
Table 1-4 Summary table for read_pmbist_memory_view. [PMBIST-41]

,
Number Instance Name Memory Cell/Wrapper Remarks
number full path name module hierarchy/ {Processed,

subdesign hierarchy Already Processed,
Missing,
Failed,
Examined,
Unused in design
Ignored}

The Remarks category is intended to summarize the detailed action of the read memory
view.
■ Processed indicates that memory specifications have been successfully processed for
this instance.
■ Missing indicates that required instance exists in the design but missing in the supplied
input memory view file.
■ Already Processed indicates that memory instance had already been successfully
processed in previous call of read_pmbist_memory_view command. You need to
remove existing specification if overwriting is desired.
■ Failed indicates that error occurred and read_pmbist_memory_view failed for this
instance.
■ Examined indicates that memory specifications have been examined for this instance.
But, the memory view specifications have not been updated to Genus Synthesis Solution
since error exists for some other memory.
■ Unused in design indicates that some memory is specified in the view file. Its
corresponding liberty file also exists. But there is no instance of this memory cell in the
design.
■ Ignored indicates that some memory is specified in the view file. Its corresponding
liberty file does not exist and there are no instances of this in the design. If there are
some instances of this in the design then the status will be Failed instead of Ignored.
Programmable MBIST logic is created and inserted using add_pmbist command. Each time
you invoke the add_pmbist command, the following information is generated:
■ Status reports of the insertion process (if automatic insertion was performed)
Four types of tables are generated in the Genus Synthesis Solution log file. After the
command has completed the insertion, it reports a list of all detected memory instances and
any action taken against those memory instances and algorithm constraints. You can find the
Summary table for 'algorithm constraints' (see Table 1-5) by searching for the message
PMBIST-42 ID. Refer to “algorithm_constraints Specification” on page 213 in Appendix A,
“Customizing PMBIST Memory View and Configuration Files”for more details. Table 1-5 lists
the report column headings and associated data.
Table 1-5 Summary table for algorithm constraints [PMBIST-42]

Information about algorithm constraints
Constraint Name Minimum Required Value User Supplied Value
Algorithm constraint {integer, {integer,

yes, yes,
no, no,
Not required} N/A}
You can find the programmable BIST Engine Summary table (see Table 1-6) by searching for
the PMBIST-21 message ID. Most categories in the report are self-explanatory. Table 1-6
lists the report column headings and associated data.
Table 1-6 Memory Target and programmable BIST Engine Summary [PMBIST-21]
Memory/Block Memory Module/

Status Amu Instance Siu Instance Dcu Instance
Instance Block Class
full path name {Target, {Libcell, full path name full path name full path name
Ignore, Memory Wrapper,
Merged Black-box, Logical Wrapper,
Merged ILM, Macro Interface,
Merged Libcell, Multiple View,
Checked and Merged} Block Instance}
The Status category indicates the summary action taken.

■ Target indicates that self-test was requested and successfully inserted into the design
for this instance.
■ Ignore indicates that user requested that PMBIST not be inserted for this instance
which is the memory instance was listed in the ignore group in the configuration file.
■ Merged Black-box indicates that a block with PMBIST previously inserted was
successfully merged into the design as a blackbox for this instance.
■ Merged ILM indicates that a block with PMBIST previously inserted was successfully
merged into the design as an interface logic model (ILM) for this instance.
■ Merged Libcell indicates that a block with PMBIST previously inserted was
successfully merged into the design as a Liberty file for this instance.

■ Checked and Merged indicates that a block with PMBIST previously inserted was
successfully merged into the design as a complete netlist. Consistency checking against
the corresponding interface files has been done as part of the merging.
The Memory Module/Block Class category is intended to summarize the class of the
memory/block instance. For Memory Module/Block Class, you can find the following
comments:
■ Libcell indicates that an memory libcell is being targeted for PMBIST.
■ Memory Wrapper indicates that an memory wrapper is being targeted for PMBIST. It
represents a PMBIST overlay at the memory Liberty file level.
■ Logic Wrapper indicates that a logic wrapper is being targeted for PMBIST. It
represents a PMBIST overlay at a hierarchical design level.
■ Macro Interface indicates that a macro interface is being targeted for PMBIST. A
test interface within the core or hierarchical module will be used to access the memories.
■ Multiple View indicates that two independent views of a given memory instance
where data width and some controls may vary, but address width is consistent. Only one
view can be targeted at a time.
■ Block Instance indicates that a block with PMBIST previously inserted was
successfully merged into the design for this instance. Only boundary level integration
consistency checks could be accomplished.
You can also find the area summary tables (see Table 1-7 and Table 1-8) by searching for the
PMBIST-32 and PMBIST-33 message IDs. The table associated with the PMBIST-32
message ID reports the area of the various blocks inserted by the add_pmbistadd_pmbist
command. This table is library domain aware. For each library domain in which PMBIST
inserts some logic, the tool generates a table.
Table 1-7 PMBIST area overhead summary table [PMBIST-32]
Library domain: domain name
Module Name Module type Number of Instances Area of all instances
module name type of module number of instances of area of instances of this particular
this particular module module
Table 1-8 associated with the PMBIST-33 message ID compares the design area against the
total PMBIST logic area inserted by the add_pmbist command. This table takes into
account the total PMBIST logic area of all affected library domains.

Table 1-8 PMBIST area comparison table. [PMBIST-33]
Design area vs PMBIST logic area
Initial Design Area Total PMBIST Logic

Total Design Area with PMBIST Logic
without PMBIST Logic Area
initial design area PMBIST logic area final design area after PMBIST insertion


2
PMBIST Pattern Generation
This chapter describes the Modus programmable memory built-in self-test pattern
generation. The pattern generation capability applies specifically to the programmable
memory built-in self-test logic inserted within a design using Design For Test in Genus
Synthesis Solution. Topics range from transferring the design from Genus into Modus,
programmable memory built-in self-test pattern generation, structure and export, and
supporting design verification and manufacturing test.
Topics covered include:

■ “Design Flow into Modus” on page 51 describes the possible paths to move from
insertion of programmable memory built-in self-test to pattern generation. This includes
the necessary inputs from the designer and outputs generated for subsequent use by the
designer.
■ “Tester Description Rule” on page 54 contains the default target tester capabilities used
to constrain the generation of patterns within Modus . In general, this default definition is
likely applicable to most patterns and testers.
■ “Create Embedded Test” on page 56 describes the command line invocation of the
create_embedded_test command, initiating the Modus programmable memory
built-in self-test scheduling and pattern generation application. The inputs, supported
pattern options, and outputs of the command are described in detail.
■ “Write Vectors” on page 73 is the command necessary to write patterns in a form useable
by other applications, either design verification or manufacturing test. The required
options of write_vectors for the various programmable memory built-in self-test
pattern classes are documented.
■ “Pattern Structure” on page 74 includes information related to the programmable
memory built-in self-test patterns based on access methods used, the general structure
of the patterns, the clocking and the flow of control within them.
■ “Design Verification Support” on page 77 includes descriptions of advanced verification
features and how to enable them as well as an introduction to the use of
analyze_embedded_test in the verification process.

■ “Manufacturing Test Support” on page 78 describes the features which help ensure the
consistent use of related files spanning the flow from generation of test patterns through
manufacturing test to failure data gathering and analysis.

Design Flow into Modus

Programmable memory built-in self-test can be implemented in several flows: a gate level
(generic or technology mapped) insertion methodology may be used, coupled with a top-
down (full chip, single insertion) or bottom-up (one or more blocks with inserted
programmable memory test integrated into a design for the chip) approach. Pattern
generation is supported in most cases for the combinations of these flows. Outlined in this
chapter are the relevant commands executed on the Genus Synthesis Solution side and the
required subsequent steps within Modus .
After inserting programmable memory built-in self-test within Genus,

write_dft_pmbist_testbench can be used within the same Genus session to execute
the Modus processing steps necessary to generate the patterns to execute the
programmable memory built-in self-test algorithms using the simulation scripts created for
Incisive Enterprise simulation. In this case, the build_model command is embedded within
the write_dft_pmbist_testbench command and uses an equation level model as input.
An alternative approach uses the Genus command write_et_mbist. This command

generates a script which can be executed within Modus to generate programmable memory
built-in self-test patterns for simulation as well as tester application. Another script can be
generated optionally to enable execution of Modus boundary scan verification, including
validation of the programmable memory built-in self-test IEEE1149.1 instructions and
registers.
For the remaining cases which rely upon the write_hdl command, the transition to pattern
generation relies upon entry into Modus at the build_model step. Several options are
available.

Figure 2-1 Programmable Memory Built-In Self-Test Process Flow
design files memory Liberty configuration

files file
Genus
gate-level flow
read_pmbist_memory_view
add_pmbist
write_dft_pmbist_interface_files
write_dft_pmbist_testbench write_hdl -abstract write_hdl -generic write_hdl
interface files abstract design generic design mapped design
verilog structural
ROM data load libraries
files
Modus
build_model
create_embedded_test
write_vectors
simulation scripts PMBIST patterns Verilog design
Incisive Simulator
irun
simulation log
CPP
analyze_embedded_test Modus

■ write_hdl design -abstract > design_abstract.v

In this case, the design is an abstract representation, including the top level ports only.
You must manually make a connection from some input to some output in the Verilog
description for Modus to handle this appropriately. Also, no reference to internal design
points in the interface files can be supported in this approach. If these conditions are
satisfied, create_embedded_test can successfully generate patterns using the
abstract model.
build_model cellname=design designsource=design_abstract.v WORKDIR=directory
■ write_hdl design -generic > design_generic.v

This approach writes a design containing Verilog primitives, allows for references to
internal design points in the interface files and does not require any technology libraries
to create a functionally correct model.
This option is useful in supporting a gate-level flow as it does not require Verilog
structural libraries as input to build_model. However, if technology cells exist in the
design, e.g. pad cells, the process of unmapping them may result in blackboxes
appearing in the Modus model.
build_model -cellname design -designsource design_generic.v -WORKDIR
directory
■ write_hdl design > design.v

A gate-level model with structural Verilog libraries is input to build_model in this option.
This supports not only programmable memory built-in self-test pattern generation but
permits detailed logic fault modeling as well.
build_model -cellname design -designsource design.v
-TECHLIB verilog_cell_libraries -WORKDIR directory

Tester Description Rule

In order to ensure the memory 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).
For programmable memory built-in self-test, a default TDR is shipped with the product that
contains a description that supports generation of memory test patterns that may exceed one
or more parameters of the target tester. Although most pattern groups are constrained by a
single clock source within create_embedded_test, this is not the default behavior for
directaccess and burnin patterns and parameters related to clocking capabilities should be
constrained by the engineer. Test engineers should ensure the target tester capabilities are
not exceeded prior to generating memory test patterns for manufacturing test.
The default programmable memory built-in self-test TDR can be found in $Install_dir/
tools.<ARCH>/tb/defaults/….A6672m.mbist. Relevant excerpts are listed below.
This TDR allows for a maximum of 32 clocks with a maximum of 32 pulses per clock per tester
cycle and a maximum clock frequency of 2GHz.
TEST_PINS
CLOCK_PINS = 32
SCAN_IN_PINS = 32
OSCILLATORS = 32
;
OSCILLATOR_PULSES_PER_TESTER_CYCLE = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,

15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 ;
PIN_TIMING
TIMING_RESOURCE = PER_PIN
MAX_PULSES = 32
MAX_STIMS = 1
MAX_MEASURES = 1
MAX_CYCLE_TIME = 1 MS
MIN_CYCLE_TIME = 500 PS
MAX_PULSE_WIDTH = 1 MS
MIN_PULSE_WIDTH = 250 PS
AC_MIN_PULSE_WIDTH = 250 PS
HF_MIN_PULSE_WIDTH = 250 PS
MIN_PULSE_OFF = 0 NS
MIN_TIME_LEADING_TO_LEADING = 500 PS
MIN_TIME_TRAILING_TO_TRAILING = 500 PS
MIN_STIM_STABLE = 0 NS

ACCURACY = 0 PS
RESOLUTION = 1 PS
LEADING_PADDING = 0 PS
TRAILING_PADDING = 0 PS
TERM_TIME_TO_1 = 125 NS
TERM_TIME_TO_0 = 125 NS
STROBE_SETUP = 0 NS
STROBE_HOLD = 100 PS
MIN_SCAN_CYCLE_TIME = 13250 PS
MIN_SCAN_PULSE_WIDTH = 2500 PS
DC_CYCLE_TIME = 100 NS
DC_PULSE_WIDTH = 20 NS
;
For further information regarding tester description rules, refer to the Tester Description Rule
(TDR) File Syntax in the Modus: Guide 2: Testmodes.

Create Embedded Test

create_embedded_test is the command which generates the programmable memory
built-in self-test patterns within the Modus session.
Inputs
create_embedded_test takes as necessary inputs the Modus design model from
build_model, the interface file set written by insert_dft pmbist in the Genus session,
and the ROM data load files for any ROMs in the design. Other command options are
selected as necessary for the pattern generation desired.
Basic Options
The working directory for Modus is indicated to create_embedded_test through the -

WORKDIR directory keyword.
The design is identified to create_embedded_test through the -block design and -

topshell design keywords. This identifies the top level module in the design. When
block is specified, it indicates to create_embedded_test that this is not chip level
processing and patterns are generated assuming any JTAG controller is not present in the
design. When topshell is specified, create_embedded_test infers chip level
processing and patterns are generated accordingly. If a JTAG controller was inserted in the
chip design and used to access the programmable memory built-in self-test, the BSDL file
should be specified to create_embedded_test through the -bsdlinput
BSDL_filename keyword.
The interface files are identified through use of the -interfacefiledir directory and
-interfacefilelist comma_separated_filenames options. The interface files
contain information describing the structures inserted into the netlist by add_pmbist and
pattern generation control information. They are an abstract model of the programmable
memory built-in self-test and targeted memories for create_embedded_test. For bottom-
up design flows inserting programmable memory built-in self-test into multiple design blocks
and/or creating multiple instances of blocks in which programmable memory built-in self-test
was inserted, it is possible to assign these blocks to different JTAG instruction sets requiring
unique interface file sets. create_embedded_test can generate patterns for a single
interface file set at each invocation.
The interface files should be specified in the format:

■ <block>_pattern_control.txt
■ <block>_<tdr>_tdr_map.txt

Where <tdr> = mbistsch, mbistamr, mbistchk, mbistdiag, mbistromdiag,

mbistrar, mbisttpn, mbistrom, FCURR, FCUTPN, FCUSCH, FCUCHK or FCUAMR.
If the specified pattern control file indicates that one of the multiple instruction sets is being
used (for example, the file name design_1_pattern_control.txt indicates 1 as the
instruction set index) all the files generated by create_embedded_test will be named with
the instruction set index appended to the design name.
If ROMs exist in the design and are targeted for programmable memory built-in self-test, the
data load files must be identified through the -ROMPATH
colon_separated_directories and -romcontentsfileco
mma_separated_filenames options, and optionally the -romdatamapfile
fully_qualified_filename option. The romdatamapfile option allows you to
specify unique ROM data load files for specific instances of ROMs in the design. This option
is used in conjunction with the ROMPATH and romcontentsfile options and takes higher
priority, therefore, when searching for ROM data load files, romdatamapfile is used first. If
the memory instance is not present in romdatamapfile, then the data load file is searched
using the ROMPATH and romcontentsfile options. Each line in romdatamapfile
contains a memory instance, followed by one or more white space characters and then a fully
qualified ROM load file. The memory instance name may start with the (/) character. If so,
the string found between the first two (/) characters is assumed to be the top-level design,
and removed for further processing by create_embedded_test. The ROM content files
contain an image of the data present in the read-only memories. These data load files are
typically created by the technology vendor ROM generators and used in logic simulation to
load the memory contents. The file name must include the name of the memory module as a
prefix within the filename: ROM_module_name. The files must be structured with one line
per address, with the first line containing address zero contents and the last line containing
the maximum address contents. The content of each line is a bit vector for that address, with
the most significant bit on the left and bit zero on the right. The vector is either a binary string
of ones and zeroes or a hexadecimal string with right-justified valid data.
Example 2-1 ROM file containing binary data
ROM cell name: ROM128X17. ROM contents file: ROM128X17_verilog.rcf.
ROM contains 128 addresses, and the data width is 17 bits.
Command line:
create_embedded_test ... ROMPATH=location_of_ROM_contents_file
romcontentsfile=ROM128X17_verilog.rcf
Contents of ROM128X17_verilog.rcf:
01000011101011011

10010110100011000
...
00001001010101000
There are 128 lines of data in the file, one for each address. There are 17 bits of data on each
line as the data width of the memory is 17 bits.
Example 2-2 ROM file containing hexadecimal data
ROM cell name: p10np_512x10cm16. ROM contents file: p10np_512x10cm16.hex
ROM contains 512 addresses, and the data width is 10 bits.
Command line:
create_embedded_test ... ROMPATH=location_of_ROM_contents_file
romcontentsfile=p10np_512x10cm16.hex
Contents of p10np_512x10cm16.hex:
28A
1FE
...
12C
There are 512 lines of data in the file, one for each address. There are 10 bits of usable data
on each line, as the data width of the memory is 10 bits. As the data is right justified, the 2
leftmost bits are ignored by create_embedded_test during processing.
Example 2-3 Using the romdatamapfile option
Command line:
create_embedded_test ... -ROMPATH location_of_default_ROM_load_files -
romcontentsfile ROM32X4.hex -romdatamapfile location_of_file/romdatamapfile
There are 2 instances of the ROM32X4 cell in this design:

/TopBlock/l1m1/rom
/TopBlock/l1m2/rom
Contents of the romdatamapfile:

/TopBlock/l1m1/rom location_of_instance_ROM_load_files/ROM32X4.hex.1
In this example, instance /TopBlock/l1m1/rom uses the ROM32X4.hex.1 ROM data load
file, and instance /TopBlock/l2m2/rom uses the ROM32X4.hex default ROM data load
file.
Housekeeping Options
Specifying -cleanstart yes results in deletion of existing files generated by

create_embedded_test, ensuring no conflicting or extraneous generated files exist from
one pass of pattern generation to the next.
-genmodeinitonly yes is used to implement a sequence of events to set a state in the

design prior to running memory test. This keyword causes create_embedded_test to
execute only the code to generate the programmable memory built-in self-test mode
initialization sequence used for JTAG access patterns and the mode initialization sequence
used for direct access patterns, if applicable. Comments are placed in this generated file to
permit the designer to insert a sequence of events at the designated place. After the updated
file is ready, specify the following keywords:
-cleanstart no -genmodeinitonly no -seqdef
jtag_access_mode_initialization_filename
These options enable use of this manually updated mode initialization sequence file in
programmable memory built-in self-test pattern generation for JTAG access patterns.
The following keywords enable use of a manually updated mode initialization sequence file in
programmable memory built-in self-test pattern generation for direct access patterns:
-cleanstart no -genmodeinitonly no -seqdefdirect
direct_access_mode_initialization_filename
The option -genscriptsonly yes enables the generation of the scripts executed within
the create_embedded_test command but avoids actually executing them. This provides
expert users more opportunity to vary the parameters of execution of the command.
The -BSDLPKGPATH colon_separated_directories keyword supports overriding

the default BSDL package used within the Modus installation.
Tester Description Rule Options
When the default programmable memory built-in self-test tester description rule is not
appropriate for pattern generation, three options exist which support varying degrees of
control.

-maxsupportedclocks positive_integer is used to control the number of clocks

that may be simultaneously controlled by the tester in a given tester cycle. -
maxclockpulses positive_integer specifies the maximum number of clock pulses
per tester cycle that may be applied to any of the active clocks in the pattern. These two
keywords may reduce the current values of the active tester description rule, but not exceed
them.
The option -testerdescriptionrule TDR_path/TDR_filename is used to replace

the default tester description rule for the pattern generation. If this keyword is specified, all
mode definition files used for test modes created by create_embedded_test are copied
from the default location, installation_dir/defaults/rules/modedef, to the
working directory. These copies of the mode definition files are then modified, so the
Tester_Description_Rule entry points to the specified tester description rule file.
If the testerdescriptionrule option is specified, TDR_filename is added to the

default test mode names created by create_embedded_test. Refer to the following
sections for more information on file name changes:
■ “Assign Files” on page 62
■ “Mode Initialization Sequences” on page 62
■ “File System Updates” on page 65
Pattern Generation Options
These keywords control the class of patterns and execution schedule followed during
generation of the programmable memory built-in self-test patterns during excecution of
create_embedded_test. createpatterns selects one or more pattern classes for
generation and the corresponding *schedule option selects the desired execution
schedule. Each *schedule option allows for a fully custom schedule to be selected and the
production patterns allow for one of four broader engine/device schedule values.
Table 2-1 createpatterns Option Relationship to Scheduling Options
Access Method createpatterns value corresponding *schedule

JTAG production prodschedule
diagnostic diagschedule
jtag_redundancy jtagredundancyschedule

Access Method createpatterns value corresponding *schedule

PMDA direct access directschedule
burnin burninschedule
pmda_diagnostic pmdadiagschedule
pmda_redundancy pmdaredundancyschedule
Table 2-2 Scheduling Option Value Descriptions
*Schedule Value AMU Programmable Memory BIST execution

schedule
custom Any Fully customizable execution schedule
[serial|parallel|s|p]_ Single The first directive schedules SIUs in series or
[serial|parallel|s|p] AMU parallel. The second directive schedules all
target devices in each SIU in series or parallel.
Default value is parallel.
[serial|parallel|s|p]_ Multiple The first directive schedules all AMUs in series
[serial|parallel|s|p]_ AMUs or parallel. The second directive schedules all
[serial|parallel|s|p] SIUs in series or parallel. The last directive
schedules all target devices in each SIU in
series or parallel.
Default value is parallel.
The buildtestmode option allows you to select if the testmodes created by

create_embedded_test for pattern generation are built or reused. You might want to
execute create_embedded_test for a specific group of patterns, and then execute another
invocation for different pattern types. By default, the testmodes used for pattern generation
are built during each invocation of create_embedded_test. When existing testmodes are
built again, any previously existing experiments are deleted automatically by the
build_testmode command. To keep all experiments available for a testmode, use -
buildtestmode no to force create_embedded_test to reuse the testmodes.
Design Verification Options
These keywords are only accessible from within the Genus session when the
write_dft_pmbist_testbench command is invoked. They exist to permit programmable
memory built-in self-test generation of Verilog testbench patterns. -outputverilog yes
enables Verilog patterns to be exported from Modus and -outputverilogdir
verilog_pattern_directory identifes the location where the files are written.

Assign Files
create_embedded_test typically generates the necessary assign files for its own pattern
generation based on interface file content. However, there may be situations where these
need enhancement by the designer. In such situations they may be edited in place and used
by specifying -cleanstart no on the create_embedded_test command line.
Table 2-3 Assign File Descriptions
File Name Content Usage

assignfile.design.patt_gen1 JTAG pins JTAG access patterns
DFT configuration pins
clock pins
assignfile.design.mda1 clock pins direct access patterns
1If the option

-testerdescriptionrule TDR_path/TDR_filename is used, the file
name is suffixed with _TDR_filename. If multiple instructions are detected based on the
interfacefiledir and interfacefilelist options being specified, then the string
design becomes design_instruction-set-index. The instruction set index is
extracted from the pattern control file name. For example, if the pattern control file specified
is design_1_pattern_control.txt, then the instruction set index would be 1.
Mode Initialization Sequences
A Modus test mode initialization sequence is used to establish a defined state of the design
under test. create_embedded_test generates the necessary sequences based on its
knowledge of the design and the pattern requirements. This includes
■ establishing the state of test control pins defined in the Genus session,
■ initializing the state of any JTAG controller and compliance enable pins,
■ initializing the state of any programmable memory built-in self-test direct access
mechanism,
■ and initializing the state of clock paths into the programmable memory built-in self-test
logic.
If the designer has additional requirements which must be satisfied, such as using the JTAG
controller to establish a design for test control mode or locking a PLL for use as a clock source

in programmable memory built-in self-test, these can be added manually to the sequences in
their predefined filesystem location and used by create_embedded_test.
In a mixed mode environment (where both JTAG and direct access are present), in order to
reset properly, both the mda_reset as well as JTAG reset signals need to be active at the
same time.
Table 2-4 Mode Initialization Sequence Usage
File Name Usage

TBDseqPatt.design.patt_gen1 JTAG access patterns initialization sequence
TBDseqPatt.design.mda1 direct access patterns initialization sequence
1If the option

-testerdescriptionrule TDR_path/TDR_filename is used, the file
name is suffixed with _TDR_filename. If multiple instructions are detected based on the
interfacefiledir and interfacefilelist option being specified, then the string
design becomes design_instruction-set-index. The instruction set index is
extracted from the pattern control file name. For example, if the pattern control file specified
was design_1_pattern_control.txt, then the instruction set index would be 1.
Pattern Classes
Patterns are classified in general terms by their execution time and failure analysis capability.
In general terms, as the granularity of the failure analysis increases, the execution time
increases. Programmable memory built-in self-test patterns can be generated for a design,
be it the block level or full chip, in most cases.
Table 2-5 Block and Chip Level Pattern Class Support
Block-level
Pattern Class Chip-level Support
Support
production yes yes
direct access yes yes
For the experiment names in the pattern classes which appear below, the clock-source
variable has a value based on the source of the programmable memory built-in self-test clock
selected for pattern generation:

■ stclk
clock-source = design-port-name
■ internal clock source

clock-source = ICS_design-port-name
Production
The production pattern, selected with -createpatterns production, performs the

execution of the specified testplans in each programmable memory BIST engine on its
associated scheduled devices. Failure recording is limited to possibly identifying the failing
algorithm memory unit (amu), sequence iterator unit (siu) and data compare unit (dcu) as
each selected testplan executes once per scheduled device.
Production pattern scheduling restrictions include the clock source and frequency.
Experiments are created within Modus 1149_patt test mode using the following naming
convention:
MBIST_ATE_PROD_positive-integer_clock-source
Direct Access
The direct access patterns, selected with -createpatterns directaccess or -

createpatterns burnin, perform the execution of the specified testplans in each
programmable memory BIST engine on its associated scheduled devices.
For directaccess patterns, the mda_done and mda_fail pins can be defined during the
insertion process to allow for determination if the test is complete (using mda_done), and if
there was a failure detected (using mda_fail). Contents of the MBISTCHK TDR are examined
after each test, and can be checked for on the mda_tdo pin (if defined during insertion).
For burnin patterns, the mda_fail pin can be defined during the insertion process to allow for
determination if there was a failure detected. Burnin patterns run through the applied test
repeatedly until the test engineer stops the test.
Direct access pattern scheduling restrictions include the limitations imposed by the tester
description rule and the create_embedded_test tester description rule option overrides.
Experiments are created within Modus mda test mode using the following naming convention:
MBIST_ATE_DIRECTACCESS_1
MBIST_ATE_BURNIN_1

As the names of the experiments created are not unique for direct access patterns, if multiple
sets of patterns are required, care must be taken to copy existing experiments to a different
name or location. They will be overwritten with the next invocation of
create_embedded_test.
Outputs
In addition to the assign files, mode initialization sequences, test modes, and experiments
create_embedded_test generates within Modus, several scripts and support files are
generated. The file system updates are noted below. Outputs are generated as requested on
the command line of create_embedded_test, but all possible files are show here.
create_embedded_test may also modify in place the input pattern control file when
programmable memory built-in self-test changes are made under pattern generation
scheduling constraints.
File System Updates
WORKDIR is an environment variable accessible within Modus. This points to the branch of
the directory tree where create_embedded_test reads input and writes user required
output by default.
WORKDIR/testresults/
logs/
. create_embedded_test logs and reports
scripts/
run.design.instruction2
run_sim.design.patt_gen1,2
run_sim.design.mda_build_testmode1,2
run_sim.design.mda_read_vectors1,2
testmode_data/
. sources/
assignfile.design.mda1,2
assignfile.design.patt_gen1,2
TBDseqPatt.design.mda1,2
TBDseqPatt.design.patt_gen1,2
MODE_JTAG.design.MBIST_instruction_name2
TBDseqPatt.design.MBIST_instruction_name2
TBDpatt.design.*2
1If the option -testerdescriptionrule TDR_path/TDR_filename is used, the test
mode string (located after the design name) in the file name is suffixed with
_TDR_filename.

2
If multiple instructions are detected based on the interfacefiledir and
interfacefilelist options being specified, then the string design becomes
design_instruction-set-index. The instruction set index is extracted from the
pattern control file name. For example, if the pattern control file specified was
design_1_pattern_control.txt, then the instruction set index would be 1.
The information available in the *.MBIST_instruction_name files support test data

register analysis within Modus .
Repeated invocations of create_embedded_test
Each invocation of create_embedded_test within a given Modus model results in the

recreation of the test modes by default, effectively deleting any generated patterns from a
previous invocation. This behavior can be changed by specifying -buildtestmode no,
causing create_embedded_test to reuse the existing testmodes. If multiple invocations
are required within a given WORKDIR, then either execute write_vectors after each
invocation of create_embedded_test to export the generated experiments for that
session, or specify -buildtestmode no after the initial invocation of
create_embedded_test so that the existing test modes and experiments are retained.

CET Custom Scheduling

The Custom Scheduler is a GUI-based utility that enables specification of execution step for
each memory instance target before create_embedded_test.
Using the Custom Scheduler you can modify the PCF (Input Pattern Control File) ,file and
update the interface files prior to create_embedded_test. The custom scheduling flow is
shown in red in Figure 2-2.
Figure 2-2 Custom Schedule Flow
Setup for Scheduling

1. Before opening the Scheduler, you need to set the working directory. You can either
invoke the Scheduler in a Modus working directory that contains the tbdata directory, or,
start Modus and then set the working directory using the set_db workdir command
as follows:
set_db workdir <path>
2. Invoke the CET Scheduler from the Modus Common User Interface:
gui_view_pmbist_scheduler
The Scheduler opens as shown in Figure 2-3

Figure 2-3 Scheduler Main Window
The scheduler contains the following tabs:

❑ Setup for Scheduler
❑ Scheduling Keys Selection
❑ Schedule
You need to provide the Input PCF (Input Pattern Control File) file and the corresponding
Top Design name in the Setup for Scheduler tab as shown in Figure 2-4.

Figure 2-4 Loading Design Details
3. After specifying the inputs click on the Load button.

4. Click on the Next button.
Selecting Keys for Scheduling

After the details of the design are loaded into the scheduler, the keys for scheduling are
displayed under the Scheduling Keys Selection tab. The keys include Testplan, Target,
Clock, AMU, SIU and DCU.

Figure 2-5 Selecting Keys for Scheduling
1. Using the Forward and Backward arrow buttons you can select the required keys for
custom scheduling. You can also arrange the sequence of the keys using the Up and
Down arrow buttons.
2. Click on the Next button to navigate to the Schedule tab.
Scheduling Selected Keys

Under the Schedule tab, the keys are displayed in the same sequence as specified under
the Scheduling Keys Selection tab.

Figure 2-6 Schedule Tab
1. From the available access modes- JTAG and MDA, select the desired access method.
2. Then select the pattern group for scheduling. The following pattern groups are available
for JTAG and MDA:
❑ JTAG
❍ Production
❍ Diagnostics
❍ Redundancy
❍ Fault Tolerance
❑ MDA
❍ Direct-Access
❍ Burnin
❍ Diagnostics
❍ Redundancy
❍ Fault Tolerance
Note: A pattern group is enabled only when the PCF contains the hardware for that group.
The column Step No. indicates the order of execution of testplan and corresponding
devices.. Testplans with step number “0” are not scheduled which means that they will not be
a part of the pattern and hence will not take part in the run..
■ To view details of targets under a step, click +, , for that testplan.

■ To sort the keys in ascending/descending order, select and click the key
as required.
■ To modify the step number of a testplan, double-click the step number for that testplan
and enter the required step number.
■ To disable a target in a specific testplan from the CET run, set the target to Step No. “0”.
After scheduling the keys from the input PCF file, you need to validate the changes before
saving the file for CET. To perform the same:
1. Click on the Validate button. If the modifications to the PCF file violates any scheduling
constraint, a warning message, as shown in Figure 2-7 is displayed and the changes are
corrected automatically.
Figure 2-7 Warning of Scheduling Constraint Violation
After the changes are validated the colour of the Validate button changes to green and
the Save and Save To buttons get enabled.
2. To save the changes to the PCF file, click the Save button.
OR
To save the PCF file and related interface files to a new directory, click the Save To
button.

Write Vectors
To export programmable memory built-in self-test patterns from Modus for use in design
verification or manufacturing test, use the write_vectors command. Certain options
should be applied for programmable memory built-in self-test patterns.
■ -compresspatterns no prevents the events from moving between test cycles,
allowing analysis software to reliably predict actions within the memory test patterns.
■ -cyclecount yes causes test cycle count informational comments to be added to the
generated STIL and WGL output formats.
■ -keyeddata yes causes information allowing consistency checks and failure data
analysis to be added as comments to the STIL and WGL output formats.
Programmable memory built-in self-test pattern creation relies upon certain relationships
between the applied stimulus, pulsed clocks, and measurements within a test cycle. The
following inequalities must be satisfied using the write_vectors options for proper pattern
generation:
testpioffset=testbidioffset < teststrobeoffset < testpioffset for JTAG TCK pin
testpioffset=testbidioffset < teststrobeoffset < testpioffset for MDA TCK pin
The default testpioffset value of 50% is used for JTAG and MDA TCK pins.
The generally recommended values are listed below.

-testpioffset=-testbidioffet=0
-teststrobeoffset 0.1*(TCK period)
-testpioffsetlist=TCK=0.50*(TCK period)
Typical values as they might be found on the write_vectors command line for a 20MHz JTAG
TCK clock follow.
-testtimeunits ps \
-testpioffset 0 -testbidioffset 0 \
-testperiod 50000 \
-teststrobeoffset 5000 \
-testpulsewidth 25000 \
-testpioffsetlist=TCK=25000 \

Pattern Structure
Programmable memory built-in self-test patterns are comprised of a mode initialization
sequence as described in “Mode Initialization Sequences” on page 62 followed by a pattern
generally comprising:
■ setup of the targeted tests using the programmable memory built-in self-test access
method
■ execution of the selected programmable memory built-in self-test testplans under control
of the system clocks
■ examination of the results using the programmable memory built-in self-test access
method.
This chapter describes these sequences, distinguished by access method, direct or 1149
TAP, and pattern class.
Direct Access
Direct access is limited to executing production class patterns, selected with -
createpatterns directaccess or -createpatterns burnin.
Refer to the Programmable Memory built-in self-test insertion in the Design for Test User
Guide within the Genus documentation for details regarding the finite state machine which
describes the direct access behavior.
1149 TAP Access

All pattern classes except direct access can be executed under control of the 1149 TAP
controller.

Figure 2-8 1149 TAP Access Production Pattern Abstract View
Manufacturing Test
Results generated using Automated Test Equipment must be converted to chip-pad-pattern

(CPP) format prior to analysis with Modus analyze_embedded_test command.

Figure 2-9 1149 TAP Access ROM Production Pattern Abstract View
Test algorithm:
■ For programmed testplans, create_embedded_test uses the ROM data load file to
compute a MISR signature. This computed signature is loaded in the MBISTROM TDR
and must match the signature calculated during simulation in order to determine a good
test.
■ For hardwired testplans, create_embedded_test verifies the ROM data load file
specified on the command line is the same as the ROM data load file that was used
during add_pmbist. If the files are different, an error message is issued.

Design Verification Support
Pattern Simulation
Verilog testbenches suitable for simulation of the programmable memory built-in self-test
patterns for a design can be generated directly from a Genus session by using
write_dft_pmbist_testbench or within a Modus session after executing
create_embedded_test by using write_vectors -language verilog. Using
Incisive Enterprise simulation logs, it is also possible to generate chip-pad-pattern data and
tester data logs. For certain analyses to proceed correctly, the exported Verilog testbenches
require subsequent modification using contrib scripts supplied in the Modus installation. This
enables verification of pattern execution within the designer’s simulation environment as well
as verification of the simulation-generated manufacturing test output.
The Modus analyze_embedded_test command is the results analysis tool.
1149 Verification
The default test mode created by verify_11491_boundary within Modus can be used to
validate the programmable memory built-in self-test JTAG instructions on a full chip design.

Manufacturing Test Support

A mechanism is required to correlate the patterns generated by Modus
create_embedded_test with the result logs generated during memory test in
manufacturing and subsequently analyzed by Modus’s analyze_embedded_test.
This data log must be converted to chip-pad-pattern data prior to Modus

analyze_embedded_test processing.
The STIL or WGL files exported from Modus should be in the CPP format. To converts tester
fail data to CPP, use the convert_failures_to_cpp command.

Pattern-related Data Flows

The data flow relevant to several pattern classes through manufacturing test and data log
analysis is shown in the following sections. Cadence capabilities and customer
responsibilities are identified in these flows.
Figure 2-10 Production Pattern Data Flow


3
Static Timing Analysis
How PMBIST Affects Static Timing in a Design

Once PMBIST is started, it operates in isolation as a set of closed-loop systems. Each
PMBIST engine drives controls, addresses, and data to its target memories which feed
memory data to their PMBIST comparators that in turn send results to their PMBIST engine.
The initiation of the PMBIST operation utilizes asynchronous domain crossing hardware to
avoid the need to statically time the control transfer across domains. This applies to the JTAG
initiation sequence as well as the direct access initiation sequence. Upon completion of
PMBIST execution, results are again transferred safely back to the clock domain which
initiated the operation, JTAG or direct access.
Figure 3-1 PMBIST Timing Domain Crossings
PMBIST initiation Asynchronous domain Gathering results PMBIST completion

crossing deglithcing logic temsiu*/l_tamromdsyn_reg
PMBIST execution PMBIST execution

MBIST clock
temamu*/l_tapsync_reg[1:0] temsiu*/l_chkrst_reg[1:0]
temsiu*/l_diagrst_reg[1:0] (if diagnostics is enabled)
temsiu*/l_romdsync[1:0] (if ROM diagnostics is enabled)
During PMBIST initiation, an asynchronous reset of the targeted PMBIST logic occurs. When
PMBIST is controlled by JTAG, create_embedded_test builds this reset into the
generated patterns either using the TRST port, if available, or forcing a synchronous reset of
the TAP controller through manipulation of the JTAG finite state machine. In either case, the
jtag_reset signal into the PMBIST AMU block is used for this purpose. If the direct access
interface is used to initiate PMBIST, the asynchronous reset pulse is created by the defined
mda_reset function. If the mda_reset function is accessible from a chip-level port,
create_embedded_test builds the asynchronous reset into the generated patterns similar
to JTAG access. If the mda_reset function is intended to be controlled by a user-supplied
internal point, a user-supplied mode initialization sequence is needed to ensure proper

asynchronous reset before PMBIST starts. In case of mixing JTAG and direct access, both
jtag_reset and mda_reset need to be active to trigger a valid asynchronous reset.
The domain crossing on l_tapsync_reg[1:0] in Figure 3-1 on page 81 occurs after this
asynchronous reset within the PMBIST logic. For JTAG-initiated operations, the domain
crossing occurs when the PMBIST TDRs are loaded and the TAP enters the Run-Idle state,
asserting the jtag_runidle input on the PMBIST AMU. For direct access controlled
PMBIST, it occurs when PMBIST direct access RUN or RUND instruction is loaded and finite
state machine enters runpm or runbi state.
The domain crossing on l_chkrst_reg[1:0] in Figure 3-1 on page 81 occurs after

PMBIST execution and captures the temamu_shift_mbistchk signal in SIU. The
temamu_shift_mbistchk is a multi-cycle TAM signal and causes reset of PMBIST
hardware and a series of resets prior to next PMBIST sequence is acceptable.
If diagnostics is enabled, the domain crossing on l_diagrst_reg[1:0] in Figure 3-1 on

page 81 occurs after PMBIST execution and captures the temamu_shift_mbistdiag
signal in SIU. The temamu_shift_mbistchk is a multi-cycle TAM signal and causes reset
of diagnostic hardware and a series of resets prior to next diagnostic sequence is acceptable.
If ROM diagnostics is enabled, the domain crossing on l_romdsync_reg[1:0]in Figure 3-

1 on page 81 occurs prior to PMBIST execution of ROM diagnostic and captures the
temamu_capture_mbistromdiag signal in l_tamromdsync_reg and decodes
l_romdsync_reg[1:0] in SIU. The temamu_capture_mbistromdiag is a single cycle
TAM signal.
The following is a list of asynchronous domain crossing deglitching logics:

■ tem_amu*/l_tapsync_reg[1:0]
■ tem_siu*/l_chkrst_reg[1:0]
■ tem_siu*/l_diagrst_reg[1:0]
■ tem_siu*/l_tamromdsyn_reg & l_romdsync_reg[1:0]
During simulation, timing checks on l_tapsync_reg[1], l_chkrst_reg[1],

l_diagrst_reg[1], and l_romdsync_reg[1] might need to be turned off to avoid X
propagation issue. Please be aware that name style of the individual bit of array might be
different based on the synthesis setup.Proper clock domain crossing between TAM clock
domain (JTAG TCK or PMDA TCK) and MBIST clock domain relies upon certain relationship.
The following inequalities must be satisfied:
■ TAM_clock_period >= Largest_PMBIST_clock_period;
After domain crossing, a set of internal synchronous reset sequences happens. Once the
frequency domain control transfer has occurred, the temamu_active[n] line(s) are
asserted from the activated PMBIST engine(s). This causes the PMBIST control, address,

and data paths to the target memories to be selected, either through external multiplexors or
multiplexors internal to the memory devices. The PMBIST finite state machine is started and
multiple MBIST clock cycles later, when the temsiu_si_done[n] asserts, the first PMBIST
operation is sent to the target memories. As a result, the temamu_active[n] signals is a
multi-cycle path. For details refer to chapter “Generating SDC Constraints for DFT
Constructs” in Genus Design for Test Guide for Common UI.
The static timing problem for PMBIST is therefore reduced to one of closing timing within the
PMBIST closed loop systems and avoiding any undesired interference across the boundaries
with the functional logic. At completion of PMBIST execution, the engines are idled and
results remain stable for inspection by the initiating control mechanism.

Figure 3-2 PMBIST Timing Cross-Domain Interference

AMU
mda_tdi
mda_tck temmda_active
l_mdafsm
mda_reset
mda_tdo
mda_done
mda_fail
jtag_tdi
jtag_tck
jtag_reset
jtag_runidle
l_tapsync[1:0]
jtag_shiftdr_state temamu_active SRU
jtag_capturedr_state mda_tck
l_mcdfsm
jtag_updatedr_state
jtag_tck
jtag_instruction_decode_inst_name
jtag_amu_tdo RRU
mbist_clk self_repair_clk
mbist_clk
SIU
optional clock
mda_tck l_tamromdsync_reg mux input memory
jtag_tck functional
clock data
mbist_clk
functional
ctl/addr/data
l_chkrst_reg[1:0] ctl/addr/data
l_diagrst_reg[1:0]
l_romdsync_reg[1:0] DCU
mbist_clk
Areas of potential interference between functional timing and PMBIST timing occur all around
the memory devices. These include the control, address, and data input paths to the
memories, possibly the clock input path(s), and the data propagation paths from the
memories. After establishing the PMBIST operational mode, the functional inputs to the target
memories terminate at the input of the multiplexors as the temamu_active[n] signals are
stable. The same claim can be made regarding the clock input path to the memories whether
the clock is multiplexed with a user-specified clock hookup point. The memory outputs,
however, fan out to functional paths as well as PMBIST DCU (Data Compare Unit) and may
show up in PMBIST timing analysis.
Clock selection logic between JTAG TCK and PMDA TCK exists in AMU, SIU, and SRU
feeding the shared PMBIST TDRs. The select single temmda_active is generated by
PMBIST direct access finite state machine. During the switching between JTAG TCK and

PMDA TCK, glitches could show up. But, the affected sink flops should have stable input D
and Q and extra cycles exist before PMBIST execution actually starts.
PMBIST Module-level Timing

As each PMBIST module can be synthesized during add_pmbist, the timing constraints are
established by the command based on the period specified for the clock driving that PMBIST
logic. The designer has no control at this level.
add_pmbist produces a summary of the synthesis timing step for each module indicating
whether the timing closed at the specified frequency. The following message in the Genus log
indicates that synthesis started for the specified module:
Info : Embedded test macro targeted to run at specified period. [PMBIST-20]

: Macro: 'tem*', domain: 'None'
: Period: '<value> picoseconds'.
On completion of the synthesis for the module, the following message appears in the Genus
log if the timing closed successfully:
Info : Synthesis ran successfully for module. [PMBIST-17] [add_pmbist]

: Module: <module_name>.
If timing closure was not successful during the module synthesis step, a message is issued
in the Genus log indicating this status along with the frequency at which the module could
close timing.
Warning : Timing optimization failed to achieve zero negative slack. [PMBIST-1015]
: Module: tem*
: Target period: <value> picoseconds
: Mininum period: <value> picoseconds.
: Could not eliminate negative slack for target period. Specify at most the
minimum period as a target period in the configuration file and re-run.
Design Timing with PMBIST

Design-level timing constraints created by add_pmbist are added to a timing mode based
on various sources of the information:
■ Clocks are created in the PMBIST timing mode based upon the define_
mbist_clock commands.

■ PMBIST DFT configuration mode signals are set to values in the PMBIST timing mode
based upon the applicable define_dft_cfg_mode, define_test_mode, and
define_shift_enable commands.
■ The balance of the constraints are applied at the boundaries of the inserted PMBIST
blocks in the PMBIST timing mode and non-DFT mode.
This approach allows the generation of the timing constraints by add_pmbist to be

independent of the PMBIST insertion flow that is chosen- top-down or bottom-up; block or
chip. PMBIST timing constraint generation is independent of all other timing modes and
makes no attempts to constrain them in any way.
For details on the SDC generation flow that includes importing, generating and exporting the
constraints, refer to chapter“Generating SDC Constraints for DFT Constructs” in Genus
Design for Test Guide for Common UI.

4
Boolean Equivalence Checking
Various PMBIST insertion flows exist within Genus. Memory devices may have variations in
ports. Some include ports for access exclusively by memory BIST and test-related scan
chains. The selection of the original design for the basis of comparison and the amount of
DFT logic inserted may vary as one performs equivalence checking under different
circumstances. Each of these factors can cause variations in the constraints necessary to
satisfy boolean equivalence checking. The standard flows and implicit support within
add_pmbist are documented in this chapter.
Methodology
The philosophy in all flows is to make the inserted PMBIST logic hidden to the boolean
equivalence checking when comparing to source RTL. This effort includes the PMBIST logic
itself, the extra design hierarchy pins added as a result of propagating connections with
PMBIST, and the change in functionality resulting from PMBIST connections at the memory
boundaries. The approach taken by the add_pmbist command assumes that:
■ All relevant DFT structures are inserted into the design prior to any checking.
■ All relevant DFT structures are inserted successfully.
■ The original design, prior to any DFT insertion in this Genus session, is used as the base
(golden) design for comparison. Note that within the Multiple Block Merging Flows, the
merged blocks either contain the previously inserted memory built-in self-test structures
and ports in the original (golden) design or are blackboxed or referenced as ILM models
in the original design with the previously inserted memory built-in self-test ports.
Designer modifications to the constraints may be necessary when deviating from this
approach. The details of the add_pmbist generated constraints are included below for
insertion into various design levels. Use command write_do_lec to generate constraints. For
more details, refer to Genus Command Reference.

Block Level Insertion Flow

Within Genus, if JTAG access to PMBIST is implemented, constraints are generated to make
PMBIST invisible when check against the golden or reference design which does not include
DFT structure.
Resulting LEC dofile contribution are as follows:

add pin constraints 1 jtag_reset -revised
add pin constraints 0 jtag_capturedr -revised
add pin constraints 0 jtag_updatedr -revised
add pin constraints 0 jtag_shiftdr -revised
add pin constraints 0 jtag_runidle -revised
add pin constraints 0 retention_pause_continue -revised
add ignored output retention_pause_active -revised
add ignored output jtag_amu_tdo -revised
If direct access to PMBIST is implemented, additional constraints are necessary for the ports
defined with define_pmbist_direct_access.
Resulting LEC dofile potential contributions are as follows:

add ignored output mda_tdo_pin_or_port -golden
add ignored output mda_done_pin_or_port -golden
add ignored output mda_fail_pin_or_port -golden
add pin constraints 1 mda_reset_pin_or_port -revised

add pin constraints 1 temmda_reset_sum -revised
add pin constraints 0 retention_pause_continue -revised
add ignored output retention_pause_active -revised
add ignored output temmda_tdo -revised
add ignored output temmda_reset -revised
add ignored output mda_tdo_pin_or_port -revised
add ignored output mda_done_pin_or_port -revised
add ignored output mda_fail_pin_or_port -revised
Test-wrapped memories are those memory devices which have ports specifically used by
memory BIST applications. The set of memory ports is described in , “port_alias
Specification” on page 153. A pair of constraints for each scalar port and vector port are
required. For each port the * wildcard is used in the statement to cover all bits of any
associated bus.
Resulting LEC dofile potential contributions:

add ignored input memory-module-test-port -module memory-module -golden
add ignored input memory-module-test-port -module memory-module -revised
Chip Level Insertion Flows

If JTAG access to PMBIST is implemented, constraints are generated to make PMBIST
invisible when check against the golden or reference design which does not include DFT
structure.
Resulting LEC dofile contribution are as follows:

add pin constraints 0 JTAG_TRST -golden
add ignored output JTAG_TDO -golden
add pin constraints 0 JTAG_TRST -revised

add primary input JTAG_MODULE/JTAG_RESET -pin -revised
add pin constraints 1 JTAG_MODULE/JTAG_RESET -revised
add ignored output JTAG_TDO -revised
If direct access to PMBIST is implemented, additional constraints are necessary for the pins
or ports defined with define_pmbist_direct_access.
Resulting LEC dofile potential contributions are as follows:


Test-wrapped memories are those memory devices which have ports specifically used by
memory BIST applications. The set of memory ports is described in “port_alias Specification”
on page 153. A pair of constraints for each scalar port and vector port are required. For each
port the * wildcard is used in the statement to cover all bits of any associated bus.
Resulting LEC dofile potential contributions:

add ignored input memory-module-test-port -module memory-module -golden
add ignored input memory-module-test-port -module memory-module -revised

Multiple Block Merging Flows

For each block which is not a blackbox and which previously had PMBIST inserted that is
merged into this design, the following actions are taken. The test mode and JTAG ports are
added to the block during add_pmbist by default. In this case, additional constraints are
necessary for the associated merged block ports.
Resulting LEC dofile contribution is as follows:

// When the test mode signal is unconnected in the original design
add primary input block_instance_name/test_mode_signal -golden
add pin constraints inactive-state block_instance_name/test_mode_signal -golden

add primary input block_instance_name/jtag_runidle -pin -golden
add pin constraints 0 block_instance_name/jtag_runidle -golden
add primary input block_instance_name/jtag_shiftdr -pin -golden
add pin constraints 0 block_instance_name/jtag_shiftdr -golden
add primary input block_instance_name/jtag_tdi -pin -golden
add pin constraints 0 block_instance_name/jtag_tdi -golden
add primary input block_instance_name/jtag_capturedr -pin -golden
add pin constraints 0 block_instance_name/jtag_capturedr -golden
add primary input block_instance_name/jtag_updatedr -pin -golden
add pin constraints 0 block_instance_name/jtag_updatedr -golden
add primary input block_instance_name/retention_pause_continue -pin -golden
add pin constraints 0 block_instance_name/retention_pause_continue -golden
add primary input block_instance_name/jtag_tck -pin -golden
add pin constraints 0 block_instance_name/jtag_tck -golden
add primary input block_instance_name/
jtag_instruction_decode_userDefinedMBISTInstructionName -pin -golden
add pin constraints 0 block_instance_name/
jtag_instruction_decode_userDefinedMBISTInstructionName -golden
add primary input block_instance_name/jtag_instruction_decode_mbist* -pin -golden
add pin constraints 0 block_instance_name/jtag_instruction_decode_mbist* -golden
add primary input block_instance_name/jtag_reset -pin -golden
add pin constraints 1 block_instance_name/jtag_reset -golden


If direct access to PMBIST is implemented, additional constraints are necessary for the
associated merged block ports. Only those present on the merged block are required in the
golden design.
Resulting LEC dofile potential contributions are:

add primary input block_instance_name/temmda_tdi -pin -golden
add pin constraints 0 block_instance_name/temmda_tdi -golden
add primary input block_instance_name/retention_pause_continue -pin -golden
add pin constraints 0 block_instance_name/retention_pause_continue -golden
add primary input block_instance_name/mda_reset_pin -pin -golden
add pin constraints 1 block_instance_name/mda_reset_pin -golden
add primary input block_instance_name/temmda_reset_sum -pin -golden
add pin constraints 1 block_instance_name/temmda_reset_sum -golden

For each block which is a blackbox and which previously had PMBIST inserted that is merged
into this design, the following actions are taken. The test mode and JTAG ports are added to
the block during add_pmbist by default. Additional constraints are necessary for the
associated merged blackbox or ILM model ports.
Resulting LEC dofile contributions are as follows:

add ignored input jtag_runidle -module blackbox_module_name -golden
add ignored input jtag_shiftdr -module blackbox_module_name -golden
add ignored input jtag_tdi -module blackbox_module_name -golden
add ignored input jtag_reset -module blackbox_module_name -golden
add ignored input jtag_capturedr -module blackbox_module_name -golden
add ignored input jtag_updatedr -module blackbox_module_name -golden
add ignored input retention_pause_continue -module blackbox_module_name -golden
add ignored input jtag_tck -module blackbox_module_name -golden
add ignored input jtag_instruction_decode_userDefinedMBISTInstructionName \
-module blackbox_module_name -golden
add ignored input jtag_instruction_decode_mbist* \
-module blackbox_module_name -golden

add ignored input jtag_runidle -module blackbox_module_name -revised

add ignored input jtag_shiftdr -module blackbox_module_name -revised
add ignored input jtag_tdi -module blackbox_module_name -revised
add ignored input jtag_reset -module blackbox_module_name -revised
add ignored input jtag_capturedr -module blackbox_module_name -revised
add ignored input jtag_updatedr -module blackbox_module_name -revised
add ignored input retention_pause_continue -module blackbox_module_name -revised
add ignored input jtag_tck -module blackbox_module_name -revised
add ignored input jtag_instruction_decode_userDefinedMBISTInstructionName \
-module blackbox_module_name -revised
add ignored input jtag_instruction_decode_mbist* \
-module blackbox_module_name -revised
If direct access to PMBIST is implemented, additional constraints are necessary for the
associated merged blackbox ports. Only those present on the merged blackbox are required
in the design.
Resulting LEC dofile potential contributions are:

add ignored input temmda_tdi -module blackbox_module_name -golden
add ignored input temmda_reset_sum -module blackbox_module_name -golden
add ignored input retention_pause_continue -module blackbox_module_name -golden
add ignored input mda_tdi_pin_or_port -module blackbox_module_name -golden
add ignored input mda_reset_pin_or_port -module blackbox_module_name -golden
add ignored input temmda_tdi -module blackbox_module_name -revised

add ignored input temmda_reset_sum -module blackbox_module_name -revised
add ignored input retention_pause_continue -module blackbox_module_name -revised
add ignored input mda_tdi_pin_or_port -module blackbox_module_name -revised
add ignored input mda_reset_pin_or_port -module blackbox_module_name -revised
For the actions to be taken for the top-level design, refer to “Block Level Insertion Flow” on
page 88 if it is a block and refer to “Chip Level Insertion Flows” on page 89 if it is a chip.

5
Design Verification
Topics covered in this chapter:

■ Getting to Modus PMBIST Pattern Simulation on page 94
❑ Simulation Scripts on page 94
❑ PMBIST Patterns on page 96
❑ ROM Data Load Files on page 96
❑ Design and Technology Libraries on page 97
■ Analyzing Pattern Class Simulation Results on page 97
❑ irun to analyze_embedded_test Flow on page 98
❑ irun to CPP to analyze_embedded_test Flow on page 99
❑ Special Handling of Four pin TAP controller in Simulation on page 101
■ Injecting Memory Faults on page 101
❑ Methodology on page 101
❑ Changes in the Verilog Memory Models on page 102
❑ Fault Injection Control Files on page 103
■ Understanding analyze_embedded_test Results on page 104
❑ Working with Simulation Logs on page 105
❑ Working with CPP Data on page 109
■ Analyzing and Debugging PMBIST Simulation Results on page 114

Design Verification
Getting to Modus PMBIST Pattern Simulation

This chapter describes the necessary analyses after Modus memory built-in self-test has
been inserted within a design using Design For Test in Genus Synthesis Solution. The
description design verification through simulation of testbenches generated using Modus.
This chapter also covers manipulation of manufacturing test data results relative to memory
built-in self-test using Modus applications.
To verify the operation of the memory built-in self-test logic inserted by Genus , patterns can
be created as described Chapter 2, “PMBIST Pattern Generation”. Figure 2-1 on page 52
shows the process flow through entry into the Incisive Simulator. The inputs in the process
flow are described in the following sections.
Simulation Scripts
The simulation script generated by the Genus write_dft_pmbist_testbench command
has the following structure:

Design Verification
The script executes programmable memory built-in self-test pattern simulations in zero delay
mode. To avoid race conditions, associated with sequential elements in the design, including
registers and latches, seq_udp_delay 10ps is included on the command line. This should
be sufficient to ensure proper propagation of values as clocks pulse for most modern
technology libraries.
The +TESTFILE1 line and the preceding line in the file above are described in section
PMBIST Patterns on page 96. The -y and -v lines in the given file reference the simulation
libraries passed through the write_dft_pmbist_testbench -ncsim_library
keyword. The line following these library specifications contains the reference to the actual
design description being tested. Such a script is generated for each experiment created by
write_dft_pmbist_testbench.
The -access +w and input irun.depositscript.testmode-name.experiment-

name are used to initialize all PMBIST logic to a known value. This can be useful in preventing
“X” propagating issues. These lines can be removed to speed up simulation on larger
designs.

Design Verification
If the Genus command write_dft_pmbist_testbench is not used to simulate the

programmable memory built-in self-test patterns, a comparable script must be created by the
designer.
PMBIST Patterns
The Modus Verilog output consists of two files for each experiment with default names using
the given formats.
■ VER.testmode-name.experiment-name.mainsim.v
This file contains the Verilog module, which instantiates the design under test. It creates
connections to all ports on the design, allowing it to stimulate inputs and monitor outputs.
The stimulation of inputs and measurement of outputs occur within a test cycle. The set
of test cycles comprises an experiment.
Test cycles may vary in their period and more than one may be used in the experiment.
In a typical programmable memory built-in self-test experiment, there exists a static test
cycle in which JTAG operates to load and unload test data registers. This test cycle
period is based on the JTAG TCK clock period. The following relationship must be
satisfied within the generated pattern for proper execution:
inputs stimulated < outputs measured < pulse JTAG TCK
The actual execution of the programmable memory built-in self-test algorithms usually
occurs within a set of dynamic test cycles whose period is based on the clock driving the
PMBIST logic. In these dynamic test cycles, only the PMBIST clock(s) are pulsed.
The generic test application driver within this module accepts instructions, input data
values, and expected output values from the given data file.
■ VER.testmode-name.experiment-name.data.logic.ex1.ts1.verilog
This file contains the information that the generic test application driver within the
*mainsim.v file used to control simulation of the patterns, applying values, and
expecting results during the required test cycles. The file is organized as a set of lines
each containing a three-digit instruction field followed by instruction-dependent data.
ROM Data Load Files

These files are necessary to load the contents of the ROMs during simulation of the read-only
programmable memory built-in self-test pattern execution. They must be placed in the
directory containing the simulation script. Their formats are described in the section “Basic
Options” on page 56.

Design Verification
Design and Technology Libraries

Verilog technology description libraries and files are referenced on the -y and -v lines in the
simulation script. These may be necessary when simulating a mapped design. In other cases,
they may be necessary to model higher level functions or analog devices. The file(s)
describing the design under test must be included in the simulation script. The number and
format are dependent on the output generated and selected from Genus Genus .
Analyzing Pattern Class Simulation Results

The Verilog format of the pattern classes which can be generated as part of programmable
memory built-in self-test may require some modification to support analysis in the various
design verification flows. These modifications, if necessary, are noted in the table below. The
design verification portion of Figure on page 94 is repeated in the following figure for easier
cross-reference with Table 5-1 on page 98.
Figure 5-1 Programmable Memory Built-In Self-Test Design Verification Flows
Incisive Simulator
irun
simulation log
CPP
Modus
analyze_embedded_test
Two design verification flows are supported from the Incisive Simulator command, irun, to
Modus command analyze_embedded_test.
Table 5-1 Design Verification Pattern Class Support

Design Verification
Access irun to irun to CPP to

Pattern Class
Method analyze_embedded_test analyze_embedded_test
block chip block chip
production yes yes no yes
JTAG
diagnostic yes yes no yes
access
redundancy yes yes no yes
directaccess yes yes no yes
Direct burnin yes yes no yes

access pmda_diagnostic yes yes no yes
pmda_redundancy yes yes no yes
irun to analyze_embedded_test Flow

In this flow, analyze_embedded_test interprets the results of the irun simulation log
directly. This flow depends upon the message format inserted by Modus Verilog pattern
generation. In most cases, block-level and chip-level programmable memory built-in self-test
pattern generation and simulation are supported. Valid analyze_embedded_test
command line templates for supported pattern classes with both JTAG access and direct
access are:
■ JTAG access
❑ pattern class: production
analyze_embedded_test -patterncontrolfile pattern-control-file
-analysis production -simlog simulation-log-file
-chktdr design_mbistchk_tdr_map.txt
-testdeffile design_test_def.txt
❑ pattern class: diagnostic

-analysis diagnostic -testdeffile design_test_def.txt
-chktdr design_mbistchk_tdr_map.txt -diagtdr esign_mbistdiag_tdr_map.txt
-schtdr design_mbistsch_tdr_map.txt
-simlog simulation-log-file
Note: Requires amrtdr specification if programmed testplan is used.

❑ pattern class: jtag_redundancy
-analysis jtag_redundancy -testdeffile design_test_def.txt

Design Verification
-chktdr design_mbistchk_tdr_map.txt -rartdr design_mbistrar_tdr_map.txt

-schtdr design_mbistsch_tdr_map.txt -simlog simulation-log-file

■ Direct access
❑ pattern class: directaccess
-analysis directaccess
❑ pattern class: burnin

-analysis burnin -simlog simulation-log-file
❑ pattern class: pmda_diagnostic

-analysis pmda_diagnostic -testdeffile design_test_def.txt
-diagtdr design_mbistdiag_tdr_map.txt
-schtdr design_mbistsch_tdr_map.txt -simlog simulation-log-file

❑ pattern class: pmda_redundancy
-analysis pmda_redundancy -testdeffile design_test_def.txt
-schtdr design_mbistsch_tdr_map.txt
irun to CPP to analyze_embedded_test Flow

The output of the irun simulation log can be translated to Chip-Pad-Pattern (CPP) format
prior to processing with analyze_embedded_test. This CPP format is the same
programmable memory built-in self-test format into which manufacturing automated test
equipment logs must be translated prior to using analyze_embedded_test. This permits
the simulator to generate and validate this manufacturing test flow. The flow depends upon
the message format inserted by Modus Verilog pattern generation. Only chip-level
programmable memory built-in self-test pattern generation and simulation are supported.
The CPP file must be generated from the simulation log file.
$Install_Dir/etc/tb/contrib/simlog2CPP -simlog simulation-log-file -cppfile
generated-cpp-file

Design Verification
Valid analyze_embedded_test command line templates for the supported pattern

classes with both JTAG access and direct access are:
■ JTAG access
❑ pattern class: production
-analysis production -cpp generated-cpp-file
❑ pattern class: diagnostic

-analysis diagnostic -testdeffile design_test_def.txt
-schtdr design_mbistsch_tdr_map.txt -cpp generated-cpp-file

❑ pattern class: jtag_redundancy
-analysis jtag_redundancy -testdeffile design_test_def.txt

■ Direct access
❑ pattern class: directaccess
analyze_embedded_test -patterncontrolfil =pattern-control-file
-analysis directaccess -cpp generated-cpp-file
❑ pattern class: burnin

-analysis burnin -cpp generated-cpp-file
❑ pattern class: pmda_diagnostic

-analysis pmda_diagnostic -testdeffile design_test_def.txt

❑ pattern class: pmda_redundancy
-analysis pmda_redundancy -testdeffile design_test_def.txt

Design Verification
Special Handling of Four pin TAP controller in Simulation

In the case where a four pin TAP controller is used, create_embedded_test will create a
testmode for pattern generation where the mode initialization sequence cannot use the reset
pin. In such a situation, the mode initialization sequence consists of holding the TMS signal
to the active state, pulsing TCK for 10 cycles, and setting TMS to the inactive state. However,
this is not enough to initialize all of the FSM latches inside the TAP controller.
If the Genus command write_dft_pmbist_testbench is used to simulate the

programmable memory built-in self-test patterns, a irun.depositscript.testmode-
name.experiment-name will be created and used to initialize the JTAG FSM latches to a
known value by using a deposit event.
An alternative approach to initialize the FSM latches is to manually assert the JTAG_TRST
signal just after TMS is activated by using a force event, run for small period cycles, and then
de-assert the JTAG_TRST signal by using another force event. When using the irun
command to perform simulation, it is necessary to use the -access rw option to allow force
events to occur. An example of the steps used is given below:
run 150ns
force path_to_tap_controller_instance.tap_instance.JTAG_TRST = ‘b0
run 10ns
force path_to_tap_controller_instance.tap_instance.JTAG_TRST = ‘b1
run
Injecting Memory Faults
Methodology
Many possible methods exist to inject faults within and around memories to verify detection
occurs during programmable memory built-in self-test. The recommended methodology
relies upon changes in the Verilog memory models used in simulation. By making the
changes indicated below, analyze_embedded_test can be used to determine that proper
faults were injected and detected during the various simulation flows as displayed in Figure 5-
1 on page 97.
■ Simulation memory models must be modified to support reading fault injection control
files, injecting memory errors on memory write operations, and recording the error
injection action in the simulation log file.
■ Fault injection control files must identify the desired stuck-at fault set. Fault sets are
bound to memory modules and not memory instances.
■ analyze_embedded_test can be used to determine if the PMBIST engines properly
detect the faults injected.

Design Verification
Changes in the Verilog Memory Models

Modified code snippets of a Verilog memory model for an Artisan memory are shown below.
The boldface and italicized text indicates additions to the original memory model which
support the stuck-at fault injection.
Figure 5-2 Verilog Memory Model Changes Supporting Fault Injection
module RF32X32 (
Q,
CLK,
CEN,
WEN,
A,
D
);
...
parameter UPM_WIDTH = 2;
parameter insert_SAF=1; // enable error injection when 1
parameter num_SAF=16;
output [31:0] Q;
...
// store tmpdata in memory
if (rren === 1'b1)
mem[a]=fi_d(a,tmpdata);
...
reg [15:0] SAF_row[0:num_SAF-1];
reg [7:0] SAF_col[0:num_SAF-1];
reg SAF_st[0:num_SAF-1];
initial $readmemb("RF32X32.row", SAF_row);

initial $readmemb("RF32X32.col", SAF_col);
initial $readmemb("RF32X32.st", SAF_st);
initial active_flag = 0;
function [BITS+1:0] fi_d;

input [ADDR_WIDTH-1:0] a;
input [BITS+1:0] d;
integer i;
begin
fi_d = d;
if (insert_SAF)
begin
for (i=0; i<num_SAF; i=i+1)

Design Verification
begin
if((a == SAF_row[i]) &&
(SAF_st[i] !== 1'bx))
begin
fi_d[SAF_col[i]] = SAF_st[i];
$display("insert fault in RF32X32 at address %d, column %d, state %d at Time %t",
a, SAF_col[i], SAF_st[i], $realtime);
end
end
end
end
endfunction
...
Fault Injection Control Files

From the previous example, it is evident that the $display statement identifies the filename
of the memory fault injection control files. Three fault injection control files are required:
■ memory_module_name.row
Used to identify the address at which to insert a stuck-at fault in the memory.
■ memory_module_name.col
Used to identify the bit at which to insert a stuck-at fault in the memory.
■ memory_module_name.st
Used to identify the state creating a stuck-at fault in the memory: 0 or 1. A value of x
indicates no stuck-at fault should be inserted for this entry.
These files are correlated by lines, the information at the same line number in each file is used
to create a stuck-at fault. The files are each expected to be num_SAF entries in size, one
entry per line in the file. Unused entries should be filled with zeroes in the row and col files,
and x in the state file.
The following sample files inject two failures into the RF32X32 memory model.

Design Verification
Table 5-2 Memory Model Fault Injection Control Files
RF32X32.row RF32X32.col RF32X32.st Injected Fault

0000000000000000 00000000 0 address 0, bit 0, SA0
0000000000010000 00011111 1 address 16, bit 31, SA1
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
0000000000000000 00000000 x none
Understanding analyze_embedded_test Results

The information presented by analyze_embedded_test after processing PMBIST
execution results, either simulation logs or CPP data, is limited by the amount of information
available within the pattern class:
■ directaccess patterns yield passing die indications;
■ production patterns yield passing memory instance indications;
When processing properly annotated simulation log files, analyze_embedded_test can

perform some additional consistency checks when injecting faults according to the

Design Verification
methodology described in the section Injecting Memory Faults on page 101. When
processing CPP data, such checks are not possible.
Executing the Command

Examples of analyze_embedded_test commands for different pattern classes can be
found at the end of the descriptions of the various simulation flows:
■ irun to analyze_embedded_test Flow on page 98
■ irun to CPP to analyze_embedded_test Flow on page 99
Working with Simulation Logs

For most of the pattern classes, sample analyze_embedded_test output is included with
a brief explanation interpreting the output. The examples have two stuck-at faults injected in
two memory devices running only the march_lr algorithm.
Direct Access
The Test Status indicates a failing test for the die due to the injected stuck-at faults.
Information is limited due to the direct access of the programmable memory built-in self-test.
INFO (TEM-500): Parsing the pattern_control file 'path_to_file/design_pattern_control.txt'. [end TEM_500]
INFO (TEM-311): Parsing the simulation log file 'path_to_file/sim.experiment-name.log'. [end TEM_311]
INFO (TEM-304): Total Failures Analyzed: 2 [end TEM_304]
--------------
Test Status
--------------
Failed
INFO (TEM-314): Successfully analyzed failures.

Output file is: 'path/log_analyze_embedded_test_time-stamp'. [end TEM_314]
Production
The Test Status indicates a failing test for the SIU 4, DCU 0, and SIU 5, DCU 0 due to the
injected stuck-at faults. This information appears in the JTAG-accessible MBISTCHK test
data register.

Design Verification
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistchk_tdr_map.txt'. [end
TEM_301]
INFO (TEM-507): Parsing the test definition file 'path_to_file/design_test_def.txt'. [end TEM_507]
INFO (TEM-507): Parsing the test definition file

'path_to_file/install/tools.lnx86/tb/defaults/mbist/predefined_algorithms.txt'. [end TEM_507]
INFO (TEM-500): Parsing the pattern_control file ‘path_to_file/design_pattern_control.txt'. [end TEM_500]
INFO (TEM-311): Parsing the simulation log file 'path_to_file/sim.experiment-name.log'. [end TEM_311]
---------------------------------------------------------------
Amu Siu Dcu Test Status
---------------------------------------------------------------
0 4 0 Failed
0 5 0 Failed

Diagnostic
Diagnostic patterns execute at PMBIST clock speeds, using a capture-and-rerun

methodology to capture the first new failures encountered on each loop. The number of
execution loops is set as failurelimit at pattern generation. As the prediction of the
failure is impossible to make, the test results are gathered as miscompares. For both JTAG
and direct access diagnostic patterns, miscompares will exist and must be analyzed by
analyze_embedded_test command. These miscompares are used to pass information
from the patterns to analyze_embedded_test.
During programmable memory built-in self-test, information exists in the MBISTDIAG,

MBISTCHK, MBISTSCH, and MBISTAMR test data registers is used to determine the failure
details shown in the tables below. Each defined testplan is broken down into different
scheduling units, which could be a hardwired testplan or an algorithm of a programmed
testplan.
In this test, six stuck-at faults were detected by the march_lr and march_sr algorithms as
shown in the TEM-304 table. For each scheduling unit, the failing address and corresponding
physical information have been displayed if there is any. Extra information, includes write port,
testplan, algorithm, sequence iterator (SI), address order (AO), address update (AU), and
data background (DB), is available in the same table. Look at scheduling unit 1, the first failure
is detected by the march_lr algorithm when SI 1 is applied to logical address 5 for data bit
10 using the solid data background. Look at march_lr algorithm below, sequence iterator
1 is dn(r0,w1) as sequence iterators start at 0.
algorithm {
name march_lr
{
(w0)
dn(r0,w1)
(r1,w0,r0,w1)

Design Verification
(r1,w0)
(r0,w1,r1,w0)
(r0)
}
The last table is a completion summary table that includes all scheduling units with the
indication of testplan type: hardwired (h) or programmed (p). The number of failures detected
by each scheduling unit is displayed. In this test, each scheduling unit detects three failures.
The suffix ‘*’ indicates additional failure(s) detected beyond the predefined failurelimit.
To detect additional failure(s), increase the value of the failurelimit when generating
patterns using create_embedded_test command. This would increase the simulation
execution time because of the additional execution loop(s).
TEM_301]
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistdiag_tdr_map.txt'. [end
TEM_301]
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistsch_tdr_map.txt'. [end
TEM_301]
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistamr_tdr_map.txt'. [end
TEM_301]
INFO (TEM-507): Parsing the test definition file 'path_to_file/predefined_algorithms.txt'. [end TEM_507]
INFO (TEM-311): Parsing the simulation log file 'path_to_file/sim.MBIST_ATE_DIAG_refclk_0_0.log'. [end

TEM_311]
Scheduling Unit 1 failures:

---------------------------------------------------------------------------------------------------------------
Write Logical Physical Value
Amu Siu Dcu Target Port Test Plan Algorithm SI AO AU DB Address Bit Bank Row Column Read
---------------------------------------------------------------------------------------------------------------
0 1 0 0 ... 1 testplan_1 march_lr 1 fast-row complement solid 5 10 0 5 0

---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
0 1 0 0 ... 1 testplan_2 march_sr 1 fast-column linear solid 0 3 0 0 0
---------------------------------------------------------------------------------------------------------------
Scheduling Unit Amu Siu Dcu Target Test Plan Algorithm AO AU DB Status Failures
---------------------------------------------------------------------------------------------------------------
1 (p) 0 1 0 0 ... testplan_1 march_lr fast-row complement solid Failed 3*
---------------------------------------------------------------------------------------------------------------
2 (p) 0 1 0 0 ... testplan_2 march_sr fast-column linear solid Failed 3*

Design Verification
Redundancy
Redundancy patterns execute at PMBIST clock speeds as production patterns but with
redundancy analysis enabled. The solution is dynamically calculated as redundancy analysis
unit examines the fail data from the memory. Since it is impossible to predict failures, the test
results are gathered as miscompares. For both JTAG and direct access redundancy patterns,
miscompares will exist and must be analyzed by analyze_embedded_test command.
These miscompares are used to pass information from the patterns to
analyze_embedded_test.
During programmable memory built-in self-test, information present in the MBISTRAR,

MBISTCHK, MBISTSCH, and MBISTAMR test data registers is used to determine the failure
details shown in the tables below. Each defined testplan is broken down into different
scheduling units, which could be a hardwired testplan or an algorithm of a programmed
testplan. The redundancy analysis for each scheduling unit begins with the message TEM-
304.
In this test, three failures have been analyzed as shown in the table below. The Defined
Rows Columns indicates the type(s) of spare or redundant capabilities that the memory
module contains. The Fixed Rows Columns Data Bits identify the physical location that
needs to be repaired. Status information indicates whether a memory is Repairable or
Unrepairable based on the defined redundancy capability and number of failures
detected. If a memory is identified as Unrepairable, an entry is printed in the table for each
redundant resource that was used. If no redundancy analysis is defined for the memory or if
there are no redundant resources available and failures are detected, the status will be
indicated as Failed.

Design Verification
TEM_301]
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistdrar_tdr_map.txt'. [end
TEM_301]
TEM_301]
TEM_301]
INFO (TEM-311): Parsing the simulation log file 'path_to_file/sim.MBIST_ATE_JTAG_REDUNDANCY_0_0.log'. [end

TEM_311]

-----------------------------------------------------------------------------------------------------------
Defined Fixed
Amu Siu Dcu Target Rows Columns Rows Columns Data Bits Bank Status
-----------------------------------------------------------------------------------------------------------
0 0 0 0 ... 0 1 - 6 5 - Repairable
0 0 1 0 ... 0 1 - 1 1 - Unrepairable
0 0 2 0 ... 0 1 - 1 1 - Repairable
Working with CPP Data

For most of the pattern classes, sample analyze_embedded_test output is included with
a brief explanation interpreting the output. The examples have two stuck-at faults injected in
two memory devices running only the march_lr algorithm.
Direct Access
The Test Status indicates a failing test for the die due to the injected stuck-at faults.
Information is limited due to the direct access of the programmable memory built-in self-test.

Design Verification
INFO (TEM-500): Parsing the pattern_control file 'path/design_pattern_control.txt'. [end TEM_500]
INFO (TEM-309): Parsing the chip pad pattern (cpp) file 'path/chip_pad_pattern_file'. [end TEM_309]
INFO (TEM-319): Chip: serialno_23_022_030.

Total Failures Analyzed: 2. [end TEM_319]
Lot: 000000104C01291-01
Wafer: 23
Wafer Position: 022,030
Testblockname: Tblknam
Testcondition: RSFN1
--------------
Test Status
--------------
Failed

Output file is: ‘path/log_analyze_embedded_test_time_stamp'. [end TEM_314]
Production
The Test Status indicates a failing test for the SIU 4, DCU 0, and SIU 5, DCU 0 due to the
injected stuck-at faults. This information appears in the JTAG-accessible MBISTCHK test
data register.
INFO (TEM-301): Parsing the test data register mapping file 'path/design_mbistchk_tdr_map.txt'. [end TEM_301]
INFO (TEM-507): Parsing the test definition file 'path/design_test_def.txt'. [end TEM_507]

'path/install/tools.lnx86/tb/defaults/mbist/predefined_algorithms.txt'. [end TEM_507]
INFO (TEM-309): Parsing the chip pad pattern (cpp) file 'path/chip_pad_pattern_file'. [end TEM_309]

Lot: 000000104C01291-01
Wafer: 23
---------------------------------------------------------------
---------------------------------------------------------------
0 4 0 Failed
0 5 0 Failed


Design Verification
Diagnostic

methodology to capture the first new failure encountered on each loop. The number of
execution loops is set as failurelimit at pattern generation. As the prediction of the
failure is impossible to make, the test results are gathered as miscompares. For both JTAG
and direct access diagnostic patterns, miscompares will exist and must be analyzed by
During programmable memory built-in self-test, information in the MBISTDIAG, MBISTCHK,

MBISTSCH, and MBISTAMR test data registers is used to determine the failure details shown
in the tables below. Each defined testplan is broken down into different scheduling units,
which could be a hardwired testplan or an algorithm of a programmed testplan.
In this test, six stuck-at faults were detected by the march_lr and march_sr algorithms as
shown in the TEM-319 table. For each scheduling unit, the failing address and corresponding
physical information have been displayed if any. Extra information which includes write port,
testplan, algorithm, sequence iterator (SI), address order (AO), address update (AU), and
data background (DB), is available in the same table. Look at scheduling unit 1, the first failure
is detected by the march_lr algorithm when SI 1 is applied to logical address 5 for data bit
10 using the solid data background. Look at march_lr algorithm below, sequence iterator
1 is dn(r0,w1) as sequence iterators start at 0.
algorithm {
name march_lr
{
(w0)
dn(r0,w1)
(r1,w0,r0,w1)
(r1,w0)
(r0,w1,r1,w0)
(r0)
}
The last table is a completion summary table that includes all scheduling units with the
indication of testplan type: hardwired (h) or programmed (p). The number of failures detected
by each scheduling unit is displayed. In this test, each scheduling unit detects three failures.
The suffix ‘*’ indicates additional failure(s) detected beyond the predefined failurelimit.
To detect additional failure(s), increase the value of the failurelimit when generating
patterns using create_embedded_test command. This would increase the simulation
execution time because the additional execution loop(s).

Design Verification
TEM_301]
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistdiag_tdr_map.txt'. [end
TEM_301]
TEM_301]
TEM_301]
INFO (TEM-311): Parsing the simulation log file 'path_to_file/sim.MBIST_ATE_DIAG_refclk_0_0.log'. [end

TEM_311]

Lot: 000000104C01291-01
Wafer: 23

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

---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
Scheduling Unit Amu Siu Dcu Target Test Plan Algorithm AO AU DB Status Failures
---------------------------------------------------------------------------------------------------------------
1 (p) 0 1 0 0 ... testplan_1 march_lr fast-row complement solid Failed 3*
---------------------------------------------------------------------------------------------------------------
2 (p) 0 1 0 0 ... testplan_2 march_sr fast-column linear solid Failed 3*
Redundancy
Redundancy patterns execute at PMBIST clock speeds as production patterns but with
redundancy analysis enabled. The solution is dynamically calculated as redundancy analysis
unit examines the fail data from the memory. Since the prediction of the failure is impossible
to make, the test results are gathered as miscompares. For both JTAG and direct access
redundancy patterns, miscompares will exist and must be analyzed by

Design Verification
During programmable memory built-in self-test, information in the MBISTRAR, MBISTCHK,

MBISTSCH, and MBISTAMR test data registers is used to determine the failure details shown
in the tables below. Each defined testplan is broken down into different scheduling units,
which could be a hardwired testplan or an algorithm of a programmed testplan. The
redundancy analysis for each scheduling unit begins with the message TEM-319.
In this test, three failures have been analyzed as shown in the table blow. The Defined Rows
Columns indicates the type(s) of spare or redundant capabilities that the memory module
contains. The Fixed Rows Columns Data Bits identify the physical location that needs
to be repaired. Status information indicates whether a memory is Repairable or
Unrepairable based on the defined redundancy capability and number of failures
detected. If a memory is identified as Unrepairable, an entry is printed in the table for each
redundant resource that was used. If no redundancy analysis is defined for the memory or if
there are no redundant resources available and failures are detected, the status will be
indicated as Failed.
TEM_301]
INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistdrar_tdr_map.txt'. [end
TEM_301]
TEM_301]
TEM_301]
INFO (TEM-311): Parsing the simulation log file 'path_to_file/sim.MBIST_ATE_JTAG_REDUNDANCY_0_0.log'. [end

TEM_311]

Lot: 000000104C01291-01
Wafer: 23

-----------------------------------------------------------------------------------------------------------
Defined Fixed
Amu Siu Dcu Target Rows Columns Rows Columns Data Bits Bank Status
-----------------------------------------------------------------------------------------------------------
0 0 0 0 ... 0 1 - 6 5 - Repairable
0 0 1 0 ... 0 1 - 1 1 - Unrepairable
0 0 2 0 ... 0 1 - 1 1 - Repairable

Design Verification
Analyzing and Debugging PMBIST Simulation Results

This section deals with user analysis and debug of programmable memory built-in self-test
simulation results. It is intended to serve as a guide into the more commonly encountered
issues when initially validating PMBIST operations. Nearly all integration and execution
problems can be diagnosed at the boundaries of the inserted PMBIST modules and their
associated memories. Incisive Simulator Simvision Waveform screen snapshots are used
extensively to identify PMBIST module and memory module ports which are examined to
determine correct operation.
The content of this section is divided into several topics with related items grouped under
those headings:
■ Simulation Environment on page 114
■ PMBIST Startup on page 118
■ Memory Connections and Activity on page 132
■ PMBIST Comparators on page 137
■ PMBIST Completion on page 139
■ Determining Miscomparing Registers from Simulation Logs on page 141
Simulation Environment
■ ‘timescale
The VER.testmode-name.experiment-name.mainsim.v testbenches set the

simulation timescale compiler directive to:
‘timescale 1 ps / 1 fs
supporting simulation time precision down to 1fs and a time unit of 1ps to avoid limiting the
precision of the design under test.
■ simulation delay mode: zero, unit, Standard Delay Format (SDF)
The simulation scripts generated by the Genus write_dft_pmbist_testbench

command utilize delay_mode zero. Although the simulations will generally run in unit delay
mode as well, any logic in the clock paths may cause false race conditions. Zero delay mode
simulation is recommended. In such situations, the seq_udp_delay value of 10ps is used
to ensure delays occur from data input to data output on sequential devices. Care must be
taken to ensure the time unit of individual modules in the design and libraries support this
value in their timescale directives. The proper application of seq_udp_delay can be

Design Verification
inspected on any registered signal in the simulation waveforms, as displayed in Figure 5-3 on
page 116, where the mbist_address output on the PMBIST engine changes value.
Back-annotated SDF simulation is also possible. Changes to the simulation scripts generated
by write_dft_pmbist_testbench are necessary to support this properly.

Design Verification
Figure 5-3 Verifying Proper seq_udp_delay Behavior
seq_udp_delay of 10ps
from clock edge
■ Modus patterns test cycle number and odometer readings
Test cycles may vary in their period and more than one may be used in the experiment. In a
typical programmable memory built-in self-test experiment, there exists a static test cycle in
which JTAG operates to load and unload test data registers. This test cycle period is based
on the JTAG TCK clock period.
The static test cycle boundaries (CYCLE in the waveform) and the Modus identifier used to
mark them uniquely, the odometer (pattern in the waveform), are visible in the simulation
waveforms for correlation with the pattern activity as displayed in Figure 5-4 on page 117.
The actual execution of the programmable memory built-in self-test algorithms usually occurs
within a set of dynamic test cycles whose period is based on the clock driving the PMBIST
logic. In these dynamic test cycles, only the PMBIST clock(s) are pulsed.

Design Verification
Figure 5-4 Viewing test cycle and pattern
■ Modus patterns test cycle event order
Programmable Memory built-in self-test pattern creation relies upon certain relationships
between the applied stimulus, pulsed clocks, and measurements within a test cycle. The
following inequality must be satisfied using the write_vectors options for proper pattern
generation:
testpioffset=testbidioffset < teststrobeoffset < testpioffset for JTAG TCK pin
testpioffset=testbidioffset < teststrobeoffset < testpioffset for mda_tck pin
This can be verified through examination of the header in the VER.testmode-

name.experiment-name.mainsim.v after generating the Verilog testbenches. From
Figure 5-5 on page 118, the extracted values are shown in the inequality.

Design Verification
Figure 5-5 mainsim.v Header Sample
0ps=testpioffset=testbidioffset < 5000ps=teststrobeoffset < 25000ps=testpioffset

for JTAG TCK/mda_tck pin
// PRO JE CT NA ME ... .. ... .. ... .p ro jec t_ nam e //
// //
// TES TM OD E.. .. ... .. ... .. ... .1 14 9_p at t //
// //
// INE XP ER IME NT ... .. ... .. ... .M BI ST_ AT E_P RO D_1 _r ef clk //
// //
// TDR .. .. ... .. ... .. ... .. ... .A 66 72m .m bis t //
// //
// TES T PE RIO D. ... .. ... .. ... .5 00 00. 00 0TE ST TI ME U NIT S. ... .. ... .. ps //
// TES T PU LSE W IDT H. ... .. ... .2 50 00. 00 0 //
// TES T ST ROB E OFF SE T.. .. ... .5 00 0.0 00 TE ST ST RO BE TY PE ... .. ... .. edg e //
// TES T BI DI OF FSE T. ... .. ... .0 .0 00 //
// TES T PI OF FS ET. .. ... .. ... .0 .0 00 X VA LUE .. .. ... .. ... .. ... .. X //
// //
// In di vi dua ll y s et PI s //
// "TC K" ( PI # 1) //
// TES T OF FSE T. ... .. ... .. ... .2 50 00. 00 0PU LS E W ID TH ... .. ... .. ... .. 250 00 .0 00 //
// SCA N OF FSE T. ... .. ... .. ... .2 4. 000 PU LS E W ID TH ... .. ... .. ... .. 8.0 00 //
// //
// "re fc lk " ( PI # 40 ) //
// TES T OF FSE T. ... .. ... .. ... .2 50 00. 00 0PU LS E W ID TH ... .. ... .. ... .. 250 00 .0 00 //
// SCA N OF FSE T. ... .. ... .. ... .2 4. 000 PU LS E W ID TH ... .. ... .. ... .. 8.0 00 //
// //
■ ROM data load accessible
If ROMs are being tested by PMBIST the data load files must be accessible in the simulation
environment. Ensure $readmem error messages like the given example do not exist in the
simulation log.
Warning! $readmem error: open failed on file "v2ss1_256x8cm16.hex"

File: ./v2ss1_256x8cm16.v, line = 133, pos = 49
Scope: testde_mda_MBIST_ATE_BURNIN_1.TopBlock_inst.l1b1.l2m3.sram.uut
Time: 0 FS + 0
PMBIST Startup
There are a number of simple checks covering the more common problems to verify that
PMBIST logic is operating properly at initiation.
■ dft configuration mode(s) stability
Whether a PMBIST DFT configuration mode was established or simply a test signal used, the
test signal input and any ATPG related signals to all PMBIST engines must be in non-
controlling states for PMBIST to operate.

Design Verification
Note: The two AMU signals, test_clock_select and test_block_async_reset,

should be static and controlled in inactive state under the PMBIST DFT configuration mode.
Refer to Figure 5-6 on page 119.
Figure 5-6 Test Control Signal Stability Check
remain in non-controlling state through test

Design Verification
■ Clock Controllability
All clocks connected to all PMBIST engines must be controlled throughout the PMBIST
execution. If the PMBIST is controlled only by the JTAG access interface, the Genus
insert_dft pmbist command ties the mda_tck input inactive at insertion. Refer to
Figure 5-7 on page 121.
If the PMBIST is controlled only by the direct access interface, the Genus insert_dft
pmbist command ties the jtag_tck input inactive at insertion. Refer to Figure 5-8 on
page 122.
All other situations are the responsibilities of the designer to ensure properly controlled clocks
to the PMBIST engines for jtag_tck, mbist_clk, and mda_tck inputs.

Design Verification
Figure 5-7 Clock Controllability for JTAG Access Only
stable jtag_tck pulses and

mbist_clk pulses as required

Design Verification
Figure 5-8 Clock Controllability for Direct Access Only
stable mda_tck pulses and

mbist_clk pulses as required

Design Verification
■ Clock Frequency Checks
Each PMBIST clock frequency is defined prior to insertion in Genus using define_
mbist_clock commands. Verifying the accuracy during pattern execution is essential as
these definitions are used in the calculation of PMBIST runtimes in the patterns run on the
tester. The given Genus command defines a design port refclk running at 100MHz
connected to a PLL with the same output frequency. This is verified by inspection of the
CYCLE, refclk, and mbist_clk waveforms in Figure 5-9 on page 124.
define_mbist_clock -name m_dsram_clk0 -hookup_pin DTMF_INST0/TEST_CONTROL_INST/
m_dsram_clk -period 10000 refclk

Design Verification
Figure 5-9 Clock Frequency Checks
50ns period
10ns period

Design Verification
■ JTAG Concerns
When the 1149.x Test Access Port is used to control PMBIST, verifying it is operating properly
at the PMBIST AMU (Algorithm Memory Unit) ports is relatively simple. The following activity
should be observed on the PMBIST AMU ports:
❑ jtag_reset should be pulsed high indicating the TAP was reset
❑ For the first test sequence, jtag_instruction_decode_mbisttpn should be
asserted to start the PMBIST operation
❑ jtag_shiftdr should be asserted while jtag_tck is pulsed to load the PMBIST
test data register
❑ After jtag_shiftdr drops, jtag_runidle is asserted, signaling the transfer of
control to the PMBIST AMU mbist_clk domain is commencing
❑ temamu_rst should be pulsed high to reset all the PMBIST logic
For details, refer to the following figure.

Design Verification
Figure 5-10 JTAG Concerns for hardwired testplans

Design Verification
Figure 5-11 JTAG Concerns for programmed testplans

Design Verification
■ Direct Access Concerns
When the direct access mechanism is used to control PMBIST, verifying it is operating
properly at the PMBIST engine ports requires observing the following activity on these ports:
❑ mda_reset should be pulsed high indicating the PMBIST logic was reset
❑ mda_tck is pulsed to load programmable direct access test data register(s)
❑ mda_tdi needs to be controlled before pulsing the mda_tck pin. mda_tdi serves
as control and data transfer input signal, which is used to control all the operations
in programmable direct access
❑ jtag_reset is held active or all JTAG PMBIST related instruction signals to the
PMBIST engine remain in their non-controlling states
For details, refer to the following figure.

Design Verification
Figure 5-12 Direct Access Concerns

Design Verification
■ Proper Startup Markers
Whether the JTAG or direct access mechanism is used to control PMBIST, the same actions
occur at transfer of control to the PMBIST engine mbist_clk domain. The following activity
should be observed on the PMBIST engine ports:
❑ After jtag_tck stays low, mbist_clk starts pulsing, signaling the transfer of
control to the PMBIST SIU mbist_clk domain is commencing
❑ temamu_rst should be pulsed high indicating the PMBIST SIU was reset
❑ temsiu_si_done is asserted low at the time the mbist_clk pulse occurs and the
set of scheduled memory devices associated with this SIU have their respective
output port activated
❑ temsiu_rwcs then activates to enable the associated set of memories
❑ temsiu_rwe activates as required to indicate the initial memory write operations of
the algorithm are commencing along with changes to the temsiu_rwaddr,
temsiu_rdata or temsiu_wdata ports
Refer to Figure 5-13 on page 131 for details in the waveforms.

Design Verification
Figure 5-13 Proper Startup Markers

Design Verification
Memory Connections and Activity

This section deals with rudimentary checks concerning properly controlled memory devices
associated with PMBIST engines during algorithm execution. The checks are performed at
both PMBIST and memory device ports to ensure proper transfer of information.
■ Write Operation Markers
Write controls, address, and data are supplied directly from the PMBIST engine to the target
devices in the same clock cycle. Controls must be in the proper state to enable the write
operations: ENABLE high and WR_EABLE high are examples. For more details, refer to
Figure 5-14 on page 133. Note the first write operation is being transferred to the memory
device starting with the clock edge at the red cursor.

Design Verification
Figure 5-14 Write Operation Markers
■ Read Operation Markers
Read controls, address, and data are supplied directly from the PMBIST engine to the target
devices in the same clock cycle. Controls must be in the proper state to enable the read
operations: ENABLE high and WR_EABLE low are examples. Refer to Figure 5-15 on

Design Verification
page 135 for more details. Note the first read operation is being transferred to the memory
device starting with the clock edge at the red cursor.
In this case, the memory device has a read_delay 1 value specified in the PMBIST
configuration view file, meaning it takes one clock cycle to transfer the read request to the
memory, access memory, and transfer data from the memory to the PMBIST comparator.
This should be verified in the waveforms or PMBIST execution failures will result. Also note
in this algorithm that two read and write operations are occurring for each memory address.

Design Verification
Figure 5-15 Read Operation Markers
lack of failure indications is a good

sign the memory read timing is correct
■ Memory Read Data Cycle Timing Variations
The number of clock cycles required to read memory data from presentation of the command
and address on the PMBIST engine signal interface to the memory device must be identified
in the memory module definition within the configuration view file supplied to the Genus

Design Verification
read_pmbist_memory_view command. Three likely scenarios are shown in the following

examples, distinguished by their corresponding PMBIST configuration view file read_delay
values.
read_delay 1 - Asynchronous Memory Read Timing
PMBIST command
and address C/A 1 C/A 2
memory read
Q1 Q2
PMBIST comparator
Q1 Q2
capture memory data
read_delay 2 - Synchronous Memory Read Timing (Default Case)
PMBIST command
memory read
Q1 Q2
PMBIST comparator
capture memory data Q1 Q2
read_delay 3 - Memory Output Data Pipeline Register Timing

Design Verification
PMBIST command
memory read
Q1 Q2
memory output
register Q1 Q2
PMBIST comparator
PMBIST Comparators
■ Actual and Expect Data Comparison
Comparison of data read from memory with expected values from the algorithms is how
PMBIST determines failures. Expected data values, temsiu_rdata, and a read enable-
temsiu_rportv, are supplied by the PMBIST engines to the comparators in the same cycle
as the read command and address are presented to the associated memories. Variations in
memory read timings are managed in the individual comparators to allow memory devices of
different characteristics to be tested simultaneously. The temdcu_fail signal from the
comparator indicates when a miscompare has occurred. Refer to the following figure for
details.

Design Verification
Figure 5-16 Actual and Expect Data Comparison
read commands commence in

the memory and comparator
■ Failure Indication Variations
For SRAMs, temdcu_fail asserted indicates a miscompare has been detected within the
PMBIST comparator on a given memory port in a given cycle. It can be asserted only as a
result of a valid read operation in which a miscompare is detected, otherwise it is zero. The
relationship between a particular memory read operation and the temdcu_fail signal is a
function of the read_delay of the memory and whether or not the memory read data is

Design Verification
registered within the comparator prior to analysis. Table 5-3 on page 139 summarizes this
relationship relative to the clock cycle in which the read command is presented on the
interface between the PMBIST engine and the associated memory device.
For ROMs, temdcu_fail is asserted from the beginning of the test, only deasserting at the
end of the test if an all zeroes signature results in the MISR.
In some cases, it is possible for a failure indication to occur at the output of a PMBIST
comparator but not be valid for capture within the corresponding engine. This situation may
arise for the unselected memory devices when a subset of the memories associated with a
PMBIST engine are scheduled for execution.
Table 5-3 PMBIST SRAM Failure Indication Timing
comparator
memory data
memory temdcu_fail
registered in
read_delay signal active in
comparator
cycle
1 no 2
1 yes 3
2 no 3
2 yes 4
■ PMBIST Completion
Once a PMBIST engine has completed execution, its done register is asserted and remains
asserted until reset by external controls. For JTAG-initiated PMBIST, the done state is
observed on the temsiu_si_done port and assert during shifting of the MBISTCHK test
data register when the jtag_instruction_decode_mbistchk input is active. Refer to
Figure 5-17 on page 140.

Design Verification
Figure 5-17 Done Register and Summary Failure Register Inspection
lack of failure indications is a good

sign the memory read timing is correct

Design Verification
■ Direct Access Done and Fail Inspection
The direct access done state is observed on the PMBIST SIU mda_done port. The fail state
is observed on the PMBIST SIU mda_fail port, allowing for a pass/failing die indication.
Determining Miscomparing Registers from Simulation Logs

The Modus analyze_embedded_test command has the capability to process simulation
log files to interpret failure data. This capability includes the generation of an auxiliary detailed
register miscompare simulation log file named as the original with a “.translated” suffix
appended and containing a line for each miscompare cross-referenced to the original
simulation log.
The simulation log file snippet for the production class test
WARNING (TVE-650): PO miscompare at pattern: 1.1.1.2.4.33 at Time: 42055000.00 ps

Expected: 0 Simulated: 1 On PO: TDO

INFO (TVE-201): Simulation complete on vector file:
path/VER.testmode-name.experiment-name.data.logic.ex1.ts1.verilog
INFO (TVE-206): The number of good comparing vectors for the file just completed is 88
INFO (TVE-205): The number of miscomparing vectors for the file just completed is 2
INFO (TVE-204): The total number of good comparing vectors is 88

INFO (TVE-203): The total number of miscomparing vectors is 2
is processed by analyze_embedded_test to yield a failing test status due to injected faults

INFO (TEM-301): Parsing the test data register mapping file
'path/design_mbistchk_tdr_map.txt'. [end TEM_301]
INFO (TEM-507): Parsing the test definition file 'path/design_test_def.txt'. [end TEM_507]
'path/install/tools.lnx86/tb/defaults/mbist/predefined_algorithms.txt'. [end TEM_507]
INFO (TEM-311): Parsing the simulation log file 'sim.experiment-name.log'. [end TEM_311]

---------------------------------------------------------------
---------------------------------------------------------------
0 4 0 Failed
0 5 0 Failed

Design Verification
and further analyzed for failing register data written into the corresponding *.translated file.
(sim log line: 1545) Amu: 0 Siu: 4 Dcu: 0

(sim log line: 1548) Amu: 0 Siu: 5 Dcu: 0
============================
Failing amu/siu/dcu summary:
============================
Amu: 0 Amu instance name: tem_amu0
- Siu: 4 Siu instance name: DTMF_INST0/tem_siu4
- Dcu: 0
- Siu: 5 Siu instance name: DTMF_INST0/tem_siu5
- Dcu: 0
This *.translated file also identifies within the design the PMBIST block(s) associated with the
detected miscompares.
An alternative involves manual lookup using the files referenced by

analyze_embedded_test. Figure 5-18 on page 143 contains an example of this process.

Design Verification
Figure 5-18 Analyzing Simulation Log Failing Registers
From the design_pattern_control.txt file find the first measure for the production
class pattern.
## TBD Odometer Values
production_first_measure=1.1.1.2.4.15.1
Then, subtracting this value from the miscomparing pattern value in the simulation
log file, 33 - 15 = 18 is the index into the design_mbistchk_tdr_map.txt file.

INFO (TVE-201): Simulation complete on vector file:
path/VER.testmode-name.experiment-name.data.logic.ex1.ts1.verilog
INFO (TVE-206): The number of good comparing vectors for the file just completed is 88
INFO (TVE-205): The number of miscomparing vectors for the file just completed is 2
INFO (TVE-204): The total number of good comparing vectors is 88

INFO (TVE-203): The total number of miscomparing vectors is 2
This identifies the summary fail register in PMBIST tem_siu4 within the design.
## Version information
...
0 0 . 9 DTMF_INST0/tem_siu0/l_siudone_reg
0 0 0 10 DTMF_INST0/tem_siu0/l_dcufail_reg[0]
...

Design Verification

A
Customizing PMBIST Memory View and
Configuration Files
■ Conventions on page 147

■ Memory View File Skeleton on page 148
■ Configuration File Skeleton on page 148
■ module Group on page 151
❑ port_alias Specification on page 153
❑ port_action Specification on page 158
❑ address_limit Specification on page 160
❑ read_delay Specification on page 161
❑ data_order Specification on page 163
❑ write_mask_binding Specification on page 166
❑ address_partition Specification on page 168
❑ wrapper Specification on page 178
❑ redundancy Specification on page 180
■ macro Group on page 193
❑ name Specification on page 195
❑ port_access Specification on page 196
❑ port_alias Specification on page 198
❑ port_action Specification on page 200
❑ assertion_limit Specification on page 202
❑ memory_map Specification on page 204

Customizing PMBIST Memory View and Configuration Files
■ algorithm_constraints Specification on page 213

■ algorithm Specification on page 217
■ testplan Specification on page 222
■ target Group on page 230
❑ sharing_limit Specification on page 233
❑ clock Specification on page 235
❑ location Specification on page 237
❑ failure_recording Specification on page 238
❑ interface_control Specification on page 246
❑ testplans Specification on page 253
■ ignore Group on page 254
■ Memory View File Syntax Summary on page 255
■ Configuration File Syntax Summary on page 256

Conventions
Syntax Conventions
The list below describes the syntax conventions used in the PMBIST memory view and
configuration file statements.
literal or boldface Nonitalic words indicate options that you must type literally.
They can only be used in the places indicated by the syntax.
Keywords are case insensitive.
italic Words in italics indicate user-defined arguments for which you
must substitute a name or a value.
| Vertical bars (OR-bars) separate possible choices for a single
argument.
[ ] Brackets denote options. When used with OR-bars, they
enclose a list of choices from which you can choose one.
{ } Braces denote arguments and are used to indicate that a
choice is required from the list of arguments separated by OR-
bars. You must choose one from the list.
{ argument1 | argument2 | argument3 }
... Three dots (...) indicate that you can repeat the previous
argument. If the three dots are used with brackets (that is,
[argument]...), you can specify zero or more arguments. If
the three dots are used without brackets (argument...), you
must specify at least one argument, but can specify more.
{ } Braces in bold-face type must be entered literally.
Comments
You can use two types of comments:
■ End of line comments—preceded with a double slash:
// This is a comment to the end of the line
■ Enclosed comments
/* A comment can be enclosed as well */
/* And again */

Memory View File Skeleton

{
module {
module_list
}
{
module_specifications
} |
macro {
macro_list
}
{
macro_specifications
}
}...
Configuration File Skeleton

{
target {
{module_list | macro_name_list | instance_list}
{
target_specifications
} |
ignore {
}
}...
algorithm_constraints {
algorithm_constraint_specifications
}
algorithm {
algorithm_specifications
}...
testplan {
testplan_specifications
}...
The memory view file(s) contains information about the memories used in the design and the
configuration file contains information about how to test these memories.
The memory view file contents are limited to descriptions of the features defining the memory
devices and possible memory module or logic module wrappers and macro interfaces found
in the design. This file or set of files must be specified as a cdns_memory_view_file input
to the read_pmbist_memory_view command(s). Only module and macro groups should
appear in these memory view files.
The configuration file contains the directives that control the insertion of PMBIST logic into
the design. It allows control over the characteristics of the PMBIST engines and target
memory collars, and over the assignment of PMBIST engines to target memories. Default

values exist for most options, allowing you to specify only those characteristics deemed
necessary or to override the existing defaults.
You may define PMBIST algorithms within the limits imposed by the algorithm language
description. Numerous algorithms are predefined to the PMBIST application and can be
selected by algorithm name. The optional algorithm_constraints defines the
capabilities of the hardware to support predefined and user-defined algorithms. If it is not
specified, the PMBIST application determines the algorithm support requirements based on
the selected predefined algorithms and user-defined algorithms within the configuration file.
testplan is used to bind algorithms, data backgrounds, and addressing functions to specific
target groups.
The configuration file consists of two types of groups: target, ignore, and three global
definitions: algorithm_constraints, algorithm and testplan. A configuration file
can have multiple instances of each of these specifications with the exception of
algorithm_constraints which should appear only once or not at all.
Within a configuration file, the instance names, macro instance names and memory module
names must be uniquely specified within a single target list. If a target group lists a certain
type or instance of a memory and the ignore group lists an identical type or instance of a
memory, an error is indicated and must be corrected.
Descriptions
algorithm Optional. Describes the read and write execution sequence of a

single PMBIST algorithm within the bounds imposed by the
algorithm language description.
algorithm_constraints Optional. Defines the capabilities of the hardware to support
predefined and user-defined algorithms.
ignore Optional group. Lists memory instances or modules within a
design that must not be targeted for self testing.
module Required group. Describes one or more memory modules in the
design. Typically you use a module group per memory module.

This group supplies various types of information when

information is missing or unrecognized conventions are used
within the memory module Liberty file. Such information may
include:
■ Physical information for a memory’s storage cell layout
■ The memory’s address range, especially if not a power of 2
■ Redundancy feature descriptions
■ Port naming and handling during test
macro Optional group. Describes one or more modules in the design
which have a defined memory test interface through which the
PMBIST logic accesses the embedded memories. Typically you
use a macro group per core module memory test interface.
target Required group. Describes how the targeted memories must be
tested by the PMBIST controller and provides information
needed to construct the inserted PMBIST hardware modules.
Target groups allow the specified set of memory instances to
share PMBIST resources.
testplan Required. Describes a plan of execution for a set of algorithms
coupled with a set of data backgrounds and memory
addressing functions. At least one testplan must be specified
and used in a target group.
Related Information
algorithm Specification on page 217
algorithm_constraints Specification on page 213
ignore Group on page 254
module Group on page 151
macro Group on page 193
target Group on page 230
testplan Specification on page 222

module Group
module {
module_list
}
{
}
Describes additional characteristics or parameters of the specified memory module(s) that

are either not available in the provided technology library file or described using unrecognized
conventions, and that are needed to accomplish the tasks described in target groups.
This information includes:

■ Physical information for a memory’s storage cell layout
■ The memory’s address range and partitioning into banks, rows and columns
■ Redundancy resource descriptions
■ The binding of write mask bits to data bits
■ Possible wrapper specification to redefine or avoid the need for Liberty file constructs
Note: The Liberty file is the memory’s main technology file. The Liberty file defines the
memory’s ports, clock(s) and the relationship between them. Refer to “Memory Built-In-Self-
Test Liberty File Requirements” in Genus Library Guide for details.
You can use a module group for each memory module in the design.
Descriptions
module_list Lists the Liberty memory modules to which the specifications

apply.

Describes the additional characteristics of the modules not

available or clear in the technology file. Following is a list of the
module specifications:
[port_alias_specification]
[port_action_specification]
[address_limit_specification]
[read_delay_specification]
[data_order_specification]
[write_mask_binding_specification]
[address_partition_specification]
[wrapper_specification]
[redundancy_specification]
Within a module group, each specification can appear only

once. The order of the module specifications is not relevant.
Related Information
address_limit Specification on page 160
address_partition Specification on page 168
data_order Specification on page 163
port_action Specification on page 158
port_alias Specification on page 153
read_delay Specification on page 161
redundancy Specification on page 180
wrapper Specification on page 178
write_mask_binding Specification on page 166

port_alias Specification
port_alias {
base_port [.integer ] aliased_port
[base_port [.integer ] aliased_port ]...
}
Aliases unrecognized port names to the base port names in the Liberty file or wrapper
module. Each port can be either a scalar or a vector. The .integer notation is available
only when the module definition includes a wrapper specification.
For a module defined using a wrapper specification, all memory ports must be defined and
the .integer notation is available. At minimum, a unique memory port contains an
address bus. Multiple port memories can utilize the .integer notation to bind signals
associated with individual memory ports. This is a requirement for all relevant base ports
when more than one memory port exists and any of the base port names a, d, q are specified
in the port alias specification. Base port names a, d, q are only available for use with wrapper
specifications.
The read_pmbist_memory_view command expects that the ports defined in the Liberty
file meet a specific naming convention. If the memory compiler does not generate memory
port names that are recognized, aliasing is required to aid read_pmbist_memory_view in
the interpretation. Table A-1 on page 153 lists the base port names for a memory which can
be used to identify memory port functionality.
Table A-1 Recognized Liberty File Base Port Names
Pin name (positive active) Pin name (negative active) Description

a n/a address input
awt awtn asynchronous write through

ay n/a test address output port for
memory bypass during ATPG, refer
to Figure A-1
be ben ATPG bypass enable
biste bisten bist enable
clk n/a clock
cre cren column repair enable

cra n/a column repair address

Pin name (positive active) Pin name (negative active) Description

cs csn chip select
d n/a data input
dy n/a test data output port for memory

bypass during ATPG, refer to
Figure A-1
oe oen output enable
q n/a data output
rb n/a repair bus
re ren read enable

rre rren row repair enable
rra n/a row repair address
srsi srsin serial repair shift register input

srso srson serial repair shift register output
srclk n/a serial repair shift register clock
sre sren serial repair shift register enable
srst srstn serial repair shift register

asynchronous reset
ta n/a test address
td n/a test data
te ten memory test enable

tprefix n/a test input port prefix
tq n/a test data input port for memory

bypass during ATPG, refer to
Figure A-1
we wen write enable
wem wemn write enable mask
ysuffix n/a test output port suffix
Test ports on memories are not always present, depending on the memory module design.
When a base port name is aliased, the add_pmbist command assumes all corresponding
test ports are also aliased similarly.The default t test input port prefix can be attached to a
base port name we[n], wem[n], cs[n], re[n], oe[n], clk above indicating a test input
port twe[n], twem[n], tcs[n], tre[n], toe[n], tclk corresponding to that functional

port name. The default y test output port suffix can be attached to a base port name we[n]y,
wem[n]y, cs[n]y, re[n]y, oe[n]y above indicating a test multiplexor output port
corresponding to the functional port name. These test port prefix and suffix characters can
also be aliased by using the tprefix and ysuffix base port names, respectively. Some
aliases are inherently supported by add_pmbist.
Figure A-1 Memory with internal bypass
Table A-2 Internally Built-in Aliases
Pin Name List of Built-In-Aliases

cs ce, me
csn cen, men
clk ck

When multiple ports of the same function exist, a unique port identifier must be specified,
possibly after the ysuffix. This unique port identifier is assumed to be a single alphanumeric
character. Port names are parsed by add_pmbist in the following fashion:
[tprefix]port_name[ysuffix][port_identifier]
Descriptions
aliased_port Specifies the port name that add_pmbist will find in the Liberty
file and/or on the memory module definition.
base_port[.intege Specifies the port name that add_pmbist recognizes and
r] associates with a predefined function. An optional port number,
integer, can be used to identify individual ports of a multiple
port memory when used in the wrapper specification. Specify
one of the port names found in Table A-1 on page 153.
Note: Overloading of port functions is neither supported nor permitted through this
mechanism. To clarify, if a port CS exists on a target device, a port XY on that device cannot
be aliased to CS, port_alias {CS XY}, unless the original CS port has its function
redefined as well, port_alias { te CS }.
Examples
■ In the following example, the add_pmbist command will interpret port
my_custom_write_enable_name as the write enable port, we, and so on.
{
module {
RAM_2000X32
}
{
port_alias
{
we my_custom_write_enable_name
re my_custom_read_enable_name
clk my_custom_memory_clock_name
ten my_custom_test_enable_name_NOT
}
}
}

■ In the following example module RAM_2000X32 has two write enable ports. To
distinguish the two ports a unique port identifier of a and b is assigned to the write enable
ports. Also, a prefix of Tst is assigned to the test ports for the memory.
{
module {
RAM_2000X32
}
{
port_alias
{
we wea
we web
tprefix Tst
}
}
}
■ In the following example module RAM_2000X32 has two read-write ports addressed by
aa and ab associated with write data buses da and db and output data buses qa and qb.
The memory also provides test input ports identified by a suffix "m", ama, amb, dma, dmb
corresponding to the functional address and data buses. The port aliasing mechanism
requires the following bindings to understand the test port functions.
{
module {
RAM_2000X32
}
{
port_alias
{
ta ama
ta amb
td dma
td dmb
}
}
}

port_action Specification
port_action {
port {0|1|U|X}
[port {0|1|U|X}]...
default {0|1|U|X} }
Specifies how to control the memory ports that are not used by the PMBIST engine. Each
port can be a scalar or a vector. If the port is a vector, you can either specify one value to
connect all bits of the bus in a similar fashion, or you can specify a value for each bit (referred
to as bit indexing). In the latter case, the tool will error out if the supplied bit-string does not
match the bus width. Vector notation requires the use of brackets, "[" and "]", to enclose bit
indices separated by a ":" when indicating a range of values.
The memories described in the technology Liberty files can have ports which are not used by
the PMBIST engine. Such ports might require some connection during the testing process to
prevent erroneous behavior of the memory. Usually these ports are handled in the RTL,
especially if the value is non-uniform and subject to change. For a uniform or stable value that
is to be constrained differently during test than in a functional mode, such as the parametric
test ports on the memory, the configuration file must specify how to these ports will be
controlled when add_pmbist is executed.
Descriptions
0 (1) Specifies the port is tied to 0 (1) during PMBIST operations.

The port will also be added to the observation-only test logic
as the logic_test option specifies in the target group that
references this memory module.
U Indicates to leave the specified port untouched but to include
the port in the observation-only test logic as the logic_test
option specifies in the target group that references this
memory module.
By default, the port will be left untouched, that is, as it is in the
RTL.
X Indicates to leave the specified port as both untouched and
unobserved, that is, to exclude the specified port from any
observation-only test logic.
default Specifies the default behavior for ports that are not used by the
PMBIST engine and that are not identified by port name.

port Specifies the memory port name that must be controlled when
the memory is tested.
Examples
■ In the configuration file below, the two tune ports, tune_1 and tune_2 are constrained
to a value, where the func_op pin was left untouched and the fuse pin excluded.
If a net is already connected to the tune ports, a multiplexer will be inserted on that net
and selected with the PMBIST operation control to choose between the two modes:
functional and memory test. If the tune ports are unconnected initially, the port will be
directly tied to the constant value specified in the port_action statement.
The func_op pin will be included in the observation-only test logic added when the
logic_test option so indicates but the fuse port is excluded from observation for this
module.
{
module {
RAM_2000X32
}
{
port_alias
{
we wea
we web
tprefix Tst
}
port_action
{
tune_1 0
tune_2 1
func_op U
fuse X
}
}
}
■ The following example shows two legal specifications for a bus. The first specification
indicates that all bits are connected to logical 1 for PMBIST. The second specification
specifies a different value for each bit. If the range of BWE is defined as BWE[2:0],
BWE[2] will be tied to 1 and BWE[1] to 0, while BWE[0] will be left untouched. The third
specification is illegal and will cause an error as the bit-string is not the proper length.
port_action BWE 1
port_action BWE 10X
port_action BWE 10

address_limit Specification
address_limit integer
Specifies the number of used or addressable words in the memory.
Example
In the configuration file below, the module name RAM_2000X32 indicates that the width of the
data bus is 32 and the size of the address space, the number of words, is 2000.
{
module {
RAM_2000X32
}
{
port_alias
{
we wea
we web
tprefix Tst
}
port_action
{
tune_1 0
tune_2 1
func_op U
fuse X
}
address_limit 2000
}
}

read_delay Specification
read_delay integer
Specifies the intrinsic read delay of the selected memory module(s) in system clock cycles.
Description
integer Indicates the number of system clock cycles required for new
data to appear on the data output ports once a read operation is
presented to the memory’s input ports.
The value is one if no clocked storage elements exist between
the read request input ports and the data output ports, usually
considered an asynchronous read operation.
Default: 2
The default value of two indicates that a register exists on the
input ports within the memory to capture the read request. The
memory read operation is launched from the values captured in
this embedded register.
Figure A-2 read_delay 1 - asynchronous memory read timing
PMBIST command and

address C/A 1 C/A 2
memory read
Q1 Q2
PMBIST comparator

Figure A-3 read_delay 2 - synchronous memory read timing (default)
PMBIST command and

address C/A 1 C/A 2
memory read
Q1 Q2
PMBIST comparator
Figure A-4 read_delay 3 - memory with data output register read timing
PMBIST command and

address C/A 1 C/A 2
memory read
Q1 Q2
memory output register

Q1 Q2
PMBIST comparator
Example
{
module { RAM_2000X32 }
{
port_alias {
we wea
we web
tsuffix Tst
}
port_action {
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
read_delay 1
}
}

data_order Specification
data_order {
{ bit | bit:bit }... |
{{ bit | bit:bit }...}...
}
Specifies the physical order of the data bits within the memory word positionally in the
expression above, from 0 on the left to highest index on the right, when they do not
monitonically increase or decrease or when physical memory cell subarrays exist. The bit
above represents the logical bit index at the data input and output ports of the memory
module.
Descriptions
bit Indicates one logical bit index within the memory word.
bit:bit Indicates a contiguous range of bits within the memory word.
Any bit value must exist within the valid set of bits contained
within the memory word and each bit must be specified only
once.
{{ bit | bit:bit }...}...
Specifies groups of data bits that are physically disjoint subsets
of the memory word. As an example, such a situation can arise
when the wordline address decoder exists in the horizontal
center of the physical memory cell array, effectively creating two
memory cell subarrays.
Default: 0:n
The default value indicates the logical bits of the memory word
are physically ordered in an ascending sequence based on bit
index within the word and physically contiguous.

Example
In the configuration below, the bits of the memory word are physically ordered with the low
order bits in ascending sequence and the high order bits in descending sequence.
RAM_2000X32
CS
CLK
WE
A[10:0]
D[31:0] Q[31:0]
D/Q 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
physical position 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
{
{
port_alias {
we wea
we web
tsuffix Tst
}
port_action {
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
data_order { 0:15 31:16 }
}
}

In the configuration below, the logial bits of the memory word are physically ordered with the
low order bits in ascending sequence and the high order bits in descending sequence. Here
the two halves of the memory word are indicated as physically separated memory subarrays
which can be treated independently from a memory test perspective.
{
{
port_alias {
we wea
we web
tsuffix Tst
}
port_action {
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
data_order { {0:15} {31:16} }
}
}

write_mask_binding Specification
write_mask_binding {
integer { {bit | bit:bit}... } ...
}
Specifies the association of write mask bits with the data bits of the memory words.
Descriptions
integer Indicates a write mask bit within the set available.

All mask bits must be included only once in the specification.
bit Indicates one logical bit index within the memory word.
bit:bit Indicates a contiguous range of logical bits within the memory
word.
Any bit value must exist within the valid set of bits contained
within the memory word and each bit may be specified only
once.
When multiple write ports exist on the memory, the write mask
binding applies to all write ports.
Default: When a write mask with the same number of bits as
the memory word exists on the memory, a 1:1 mapping
between the write mask and logical data bits is assumed when
this specification is not used. Otherwise, the
write_mask_binding must be specified.

Example
In the configuration below, four write mask bits control different 8 contiguous bit portions of
the memory word.
{
{
port_alias {
we wea
we web
tsuffix Tst
}
port_action {
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
0 {0:7}
1 {8:15}
2 {16:23}
3 {24:31}
}
}
}

address_partition Specification
address_partition {
[column {integer | integer:integer }...
[order [{ data { bit| bit:bit}... }] { address_list}]...]
row {integer | integer:integer }...
[order [{ bank { integer| integer :integer}... }]
[{ data { bit| bit :bit}... }]
{ address_list [: partial_address_list ] }]...
[bank {integer | integer:integer }]
}
Describes the memory’s physical storage cell layout and addressing scheme.
For linear memories, illustrated in Figure A-5, every value of the address will access a unique
row in the memory.
Figure A-5 Linear Memory
address_partition { row 3:0 } no column multiplexing

data bits
0 1 2 3
15
14
13
12
11
10
9
row 8
7
6
5
4
3
2
1
0

Muxed memories, illustrated in Figure A-6 on page 170, are constructed with multiple
columns per data bit. This results in a more regular shape for the memory.

Figure A-6 Muxed Memories
address_partition { row 3:2 column 1:0 } column mux factor = 4

data bits
0 1 2 3
3 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15
2 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11
row
1 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7
0 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
address_partition { row 3:2 column 1:0 order { 0 1 3 2} }

data bits
0 1 2 3
3 12 13 15 14 12 13 15 14 12 13 15 14 12 13 15 14
2 8 9 11 10 8 9 11 10 8 9 11 10 8 9 11 10
row
1 4 5 7 6 4 5 7 6 4 5 7 6 4 5 7 6
0 0 1 3 2 0 1 3 2 0 1 3 2 0 1 3 2
address_partition { row 3:2 order { 0 2 1 3 } column 1:0 order { 0 1 3 2} }

data bits
0 1 2 3
3 12 13 15 14 12 13 15 14 12 13 15 14 12 13 15 14
1 4 5 7 6 4 5 7 6 4 5 7 6 4 5 7 6
row
2 8 9 11 10 8 9 11 10 8 9 11 10 8 9 11 10
0 0 1 3 2 0 1 3 2 0 1 3 2 0 1 3 2
address_partition {row 3:2 order {0 2 1 3} column 1:0 order {data 0 2} {0 1 3 2}

order {data 1 3} {2 3 1 0}}
data bits
0 1 2 3
3 12 13 15 14 14 15 13 12 12 13 15 14 14 15 13 12
1 4 5 7 6 6 7 5 4 4 5 7 6 6 7 5 4
row
2 8 9 11 10 10 11 9 8 8 9 11 10 10 11 9 8
0 0 1 3 2 2 3 1 0 0 1 3 2 2 3 1 0

address_partition { row 3:2 column 1:0 order {data 0:1} {0 1 2 3} order {data 2:3} {3 2 1 0} }
data bits
0 1 2 3
3 12 13 14 15 12 13 14 15 15 14 13 12 15 14 13 12
2 8 9 10 11 8 9 10 11 11 10 9 8 11 10 9 8
row
1 4 5 6 7 4 5 6 7 7 6 5 4 7 6 5 4
0 0 1 2 3 0 1 2 3 3 2 1 0 3 2 1 0
When an address is applied to the memory to access a row, a portion of the address bits is
used to select the column from which to get the word. In the address, address bit “0” is
assumed to be the least significant bit, while address bit “n” is assumed to be the most
significant bit. The least significant bits are usually used to select the columns, while the most
significant bits are used to select the rows and possibly banks.
The order of the columns can change based on the physical layout of the memory. Some
memories can have the columns in ascending integer order. Some memories may have a
different order. The PMBIST hardware must understand the memory structure so that the
patterns can be correctly applied to test the memory based on its physical cell array layout.
A checkerboard will still be a true checkerboard pattern and so on for the other patterns.
The column structure of the first muxed memory shown in Figure A-6 has logical addresses
0, 1, 2 and 3 that are physically aligned. This is also the default order. The next two examples
have a column order within each data bit that has addresses 0, 1, 3, 2 contiguously aligned.
The fourth example has two column orders, the even data bits having addresses 0, 1, 3, 2
contiguously aligned and the odd data bits having addresses 2, 3, 1, 0 contiguously aligned.
The fifth example has two column orders, the low order data bits having addresses 0, 1, 2, 3
contiguously aligned and the high order data bits having addresses 3, 2, 1, 0 contiguously
aligned. Examples three and four show a non-monitonically increasing row order: 0, 2, 1, 3.
Memories may also employ the use of banks, whether explicitly or implicitly based on column
address wiring limits or collections of data bits. In either case, PMBIST assumes the patterns
written must account for the physical layout within the banks but that space filled with wires
and random logic exists both vertically and horizontally between banks. This avoids the need
to maintain consistency with any pattern written between adjacent banks in any direction.
Banked memory examples are illustrated in Figure A-7 on page 172. The first example splits
the memory vertically across the data word: the low order bits are in the left half and the high
order bits are in the right half. Notice the mirrored column addressing structure across the
halves. The data_order specification is used to convey this vertically-split bank structure.

As the patterns can properly fill the memory for each bank independently, two equivalent
means of representing the address partition are shown for this example. The second banked
example is split horizontally using bit 0 of the address. Notice the row order is mirrored across
the horizontal split and two address partition specifications can be specified. Again, the
proper patterns can fill the memory for each bank independently. The third banked example
uses the high order address to select the bank. The structure of each bank is consistent in its
row and column addressing.
Figure A-7 Banked Memories

- or -
address_partition { row 3:2 column 1:0 order {data 0:1} {0 1 2 3} order {data 2:3} {3 2 1 0} }
data bits
0 1 2 3
3 12 13 14 15 12 13 14 15 15 14 13 12 15 14 13 12
2 8 9 10 11 8 9 10 11 11 10 9 8 11 10 9 8
row
1 4 5 6 7 4 5 6 7 7 6 5 4 7 6 5 4
0 0 1 2 3 0 1 2 3 3 2 1 0 3 2 1 0
address_partition { bank 0 row 4:3 column 2:1 order { 0 1 2 3 } }

- or -
address_partition { bank 0 row 4:3 order {bank 0} {3 2} order {bank 1} {0 1}
column 2:1 order { 0 1 2 3 } }
data bits
0 1 2 3
3 25 27 29 31 25 27 29 31 25 27 29 31 25 27 29 31
2 17 19 21 23 17 19 21 23 17 19 21 23 17 19 21 23
row
1 9 11 13 15 9 11 13 15 9 11 13 15 9 11 13 15
bank 1 0 1 3 5 7 1 3 5 7 1 3 5 7 1 3 5 7
0 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6
1 8 10 12 14 8 10 12 14 8 10 12 14 8 10 12 14
row
2 16 18 20 22 16 18 20 22 16 18 20 22 16 18 20 22
bank 0 3 24 26 28 30 24 26 28 30 24 26 28 30 24 26 28 30

address_partition { bank 4 row 3:2 column 1:0 order { 3 2 1 0 } }

data bits
0 1 2 3
3 31 30 29 28 31 30 29 28 31 30 29 28 31 30 29 28
2 27 26 25 24 27 26 25 24 27 26 25 24 27 26 25 24
row
1 23 22 21 20 23 22 21 20 23 22 21 20 23 22 21 20
bank 1 0 19 18 17 16 19 18 17 16 19 18 17 16 19 18 17 16
3 15 14 13 12 15 14 13 12 15 14 13 12 15 14 13 12
2 11 10 9 8 11 10 9 8 11 10 9 8 11 10 9 8
row
1 7 6 5 4 7 6 5 4 7 6 5 4 7 6 5 4
bank 0 0 3 2 1 0 3 2 1 0 3 2 1 0 3 2 1 0
Descriptions
column { integer |integer:integer }...

Specifies the address bits that are used to select the columns.
Column address bits can be specified individually, as a
contiguous range of address bits, or as a combination of these
expressions.
The integer fields must lie within the valid address range.
They cannot overlap with the row or bank address definitions but
the bank address bits may be contained within the column bit
range.
order [{ data { bit | bit : bit} ...}] {address_list}...
The address list specifies the physical order in which the logical
columns or addressed words are aligned within the memory cell
array. The physical order is implied in the order of the address
list entries, with zero on the left and the highest address on the
right. Each entry in the address list is a logical column address
mapped to the corresponding physical location.

Identifies the memory address alignment of the columns. The

order is required if it is not strictly a binary decode of ascending
values. The range of the values is zero to 2(number of column
address bits)-1.
The number of values specified in the address list must be a

power of two and fill the range of values for that power of two.
The number of values must be less than or equal to the number
of column addresses.
Each column address within the range within each order
expression can be specified once only.
This information is important for proper creation of the desired
background patterns. Only a repeating interval need be
indicated in the configuration file. The remainder of the column
address range is assumed to follow the same pattern.
If more than one address list entry is required, a single {data
...} expression must be associated with each address list.
If the data bit notation is used, either a single data {bit}, a
contiguous range of data bits, {bit:bit}, or a combination of
these expressions must be specified with each order
expression and all memory data bits must be specified once
only.
Default: order { 0 1 }
row { integer |integer:integer }...
Specifies the address bits used to select the rows. Row address
bits can be specified individually, as a contiguous range of
address bits, or as a combination of these expressions.
They cannot overlap with the column or bank address definitions
but the bank address bits may be contained within the row bit
range.
order [{ bank{ integer | integer :integer }...}] [{ data{ bit| bit:bit}...}]
{address_list [: partial_address_list] } ...
Specifies the physical order in which the logical rows are aligned
within the memory cell array. The physical order is implied in the
order of the address list entries, with zero on the left and the
highest address on the right. Each entry in the address list is a
logical row address mapped to the physical location.

Identifies the memory address alignment of the rows. The order

is required if it is not strictly a binary decode of ascending
values. The range of the values is zero to 2(number of row address
bits)-1.
The number of values specified in the address list must be a

power of two and fill the range of values for that power of two.
The number of values specified in the partial address list must
be less than or equal to the number in the address list and fill
that range of values.
The number of values must be less than or equal to the number
of row addresses.
Each row address within the range within each order
expression can be specified once only.
This information is important for proper creation of the desired
background patterns. Only a repeating interval need be
indicated in the configuration file. The remainder of the row
address range is assumed to follow the same pattern. For
memories which have a number of rows that are not an integral
multiple of the repeating row group and deviating from the order
of the repeating row group, a partial address list is used to
specify the remaining partially populated row group order.
If more than one address list entry is required, a single {bank
...} expression and/or a single {data ...} expression
must be associated with each address list.
If the bank notation is used, either a single bank {integer}, a
contiguous range of banks, {integer:integer}, or a
combination of these expressions must be specified with each
order expression and all memory banks must be specified once
only.
If the data bit notation is used, either a single data {bit}, a
contiguous range of data bits, {bit:bit}, or a combination of
these expressions must be specified with each order
expression and all memory data bits must be specified once
only. This rule applies to all data bits present within each bank
when the bank notation is used.
Default: order { 0 1 }
bank { integer |integer:integer }

Specifies the address bits used to select the banks. Bank

address bits can be specified individually or as a contiguous
range of address bits.
They cannot overlap with the column or row address definitions.
Generally, the PMBIST hardware requires that each column,

row and bank fields be contiguous and aligned from most
significant address bit on the left to least significant bit on the
right. One exception is that the bank address field may be
contained in either the row or the column address field, by
splitting it into two subfields.
All memory address bits must be defined in the

address_partition statement.

Example
In the configuration below, address bits 2 down to 0 are used to select the columns. Address
bits 8 down to 3 are used to select the rows. Address bits 10 to 9 are the most significant
address bits and used to select one of four banks. The order indicates that the column
structure has addresses 0, 1, then 3 followed by 2 as the physical alignment. As there are 3
bits in the column address, 8 locations are stored in the data bit columns per row. The
hardware assumes the remaining columns are ordered 4,5,7,6 following the pattern to
complete each row.
{
module {
RAM_2000X32
}
{
port_alias
{
we wea
we web
tsuffix Tst
}
port_action
{
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
read_delay 1
address_partition
{
bank 10:9
row 8:3
column 2:0 order { 0 1 3 2 }
}
}
}

wrapper Specification
wrapper wrapper_module
Under certain conditions, a logical level of abstraction or a logical wrapper around a memory
module may be necessary. As an example, when supporting memory repair features exist
outside the memory module, a wrapper is necessary to encapsulate the repair logic and the
memory module. When a wrapper is specified, PMBIST makes connections to the wrapper
module rather than the memory module itself.
It is also possible to specify a memory wrapper at the level of the memory module itself. In
such a situation all pins of the memory module must be identified in the module specification
using port alias or port action statements. A Liberty file is required to define the cell to Genus
, but the memory constructs within the Liberty file that are normally used to identify a memory
and some of its features need not be present.
port_alias and port_action specifications should refer to ports on the wrapper module
in these situations and all memory ports must be defined when using the wrapper
specification.
Further, it is possible to specify two different views of a memory instance when enabled using
the attribute, pmbist_enable_multiple_views. In such situations, a logical wrapper
view can be paired either with a memory module or memory wrapper view of the same
memory. PMBIST connections are made to the appropriate ports. Both views should be
specified in the same target section.
Description
wrapper_module Indicates the module name of the hierarchical block or memory

core which contains the actual memory module and supporting
logic.
Default: none

Example
In the configuration shown below, row repair logic exists external to the memory and must be
controlled by the PMBIST. The repair ports are defined to the wrapper module in the port alias
specification.
RAM_2000X32_top
RAM_2000X32
CS CS
CLK CLK
WE WE
A[10:0] A[10:0]
D[31:0] D[31:0] Q[31:0] Q[31:0]
row
RRE repair
RRA[7:0] controls
{
{
wrapper RAM_2000X32_top
port_alias {
cs CS
clk CLK
we WE
a A
d D
q Q
rre RRE
rra RRA
}
address_limit 2000
read_delay 1
address_partition
{
bank 10:9
row 8:3
column 2:0 order { 0 1 3 2 }
}
}
}

redundancy Specification
redundancy {
{ row {integer | integer:integer }...
[data {{ bit| bit:bit}...}]
[bank_range {{ integer| integer:integer}...}]
[map { [srsi port srclk port [srst port] [sre port] [srso port]]
[enable port]
address range port {range | unused}
}]
| column [{integer | integer:integer }...]
[bank_range {{ integer| integer:integer}...}]
[enable port]
data range [port] [address range port] function
}]
} ...
}
Specifies the type(s) of spare or redundant capabilities that the memory module contains.
The following types or combination of types are supported:
spare rows
spare data bits
spare columns
spare rows and data bits
spare rows and columns
Each spare resource must be individually defined. The specified resource must include the
map expression when the PMBIST logic is expected to control the spare resource. The
redundant capability can be further bound to specific groups of data bits and memory words.
More than one contiguous row or column, in the case of multiplexed column memory
structures, can be treated as a configurable spare block resource. Full data IO redundancy is
covered as a subset of column redundancy where the number of columns in the spare block
is equal to the number of columns implementing the data bit.
Limitations:
■ bank, row and column address fields are each allocated fields within the address as
defined in the address_partition specification.
■ bank_range can be used to indicate that a particular spare resource is assigned per
bank or group of banks. The bank_range expression must be a subset of the range of
integer values available in the address_partition bank expression. The expression
may be uniquely specified for row and for column spare resources, and if used, fully
enumerated within each resource class.
■ row, when an incomplete specification of the address_partition row address field,
must be a contiguous range on the high end of the row address field, defining the row-

configurable unit as a block of rows sharing common low-order row address field bits not
included in the row expression. The row expression must be a subset of the
address_partition row expression.
■ column, when an incomplete specification of the address_partition column
address field, is a contiguous range on the high end of the column address field, defining
the column-configurable unit as a block of columns sharing common low-order column
address field bits not included in the column expression. The column expression must be
a subset of the address_partition column expression. When no address bits are
specified it represents data IO redundancy.
Figure A-8 Simple Redundancy

data bits
0 1 2 3
FRA
3 3 12 13 14 15 12 13 14 15 12 13 14 15 12 13 14 15
2 2 8 9 10 11 8 9 10 11 8 9 10 11 8 9 10 11
row
1 1 4 5 6 7 4 5 6 7 4 5 6 7 4 5 6 7
0 0 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 spare column
spare row
FBA 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3
FCA 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
In Figure A-8, the single spare column can replace any single column, identified by column
address bits 1 to 0, of any bit in the memory. As such, the redundancy specification could be
any of the following samples.
redundancy {column 1:0 data {0:3}}
redundancy {column 0:1 data {0 1 2 3}}
Similarly, the single redundant row may replace any single row, identified by row address bits
3 to 2, across all bits and columns in the memory words. Possible specifications include the
following.
redundancy {row 3:2 data {0:3}}
redundancy {row 2:3 data {0 1 2 3}}

Now consider that both the single row and the single column are available for use. Possible
specifications include the following.
redundancy {row 3:2
column 1:0
}
When repair operations are controlled by PMBIST, port mapping information is also
necessary. The description below shows the extensions to the example including connections
to relevant ports on the memory.
port_alias { rre RRE
rra FRA
cre CRE
cra FBA
cra FCA
}
redundancy { row 3:2
map {enable RRE address 0:3 FRA[1:0] 0:3}
column 1:0
map {enable CRE data 0:3 FBA[1:0] address 0:3 FCA[1:0] integer}
}
Figure A-9 Banked row and column redundancy
address_partition { bank 4 row 3:2 column 1:0 } column mux factor = 4

- or -
address_partition { bank 4 row 3:2 column 1:0 order {data 0:1} {0 1 2 3}
order {data 2:3} {3 2 1 0} }
data bits
0 1 2 3
3 28 29 30 31 28 29 30 31 31 30 29 28 31 30 29 28
2 24 25 26 27 24 25 26 27 27 26 25 24 27 26 25 24
row
1 20 21 22 23 20 21 22 23 23 22 21 20 23 22 21 20
bank 1 0 16 17 18 19 16 17 18 19 19 18 17 16 19 18 17 16
3 12 13 14 15 12 13 14 15 15 14 13 12 15 14 13 12
2 8 9 10 11 8 9 10 11 11 10 9 8 11 10 9 8
row
1 4 5 6 7 4 5 6 7 7 6 5 4 7 6 5 4
bank 0 0 0 1 2 3 0 1 2 3 3 2 1 0 3 2 1 0

Figure A-9 shows a memory with the data words split into two physical halves and the rows
split into two physical banks, resulting in four separate physical memory subarrays. In this
example, each of the four subarrays has a single 2-column configurable unit, implying that half
a data bit can be repaired in each subarray. Each of the left and right halves of the memory
has a single row which can be reconfigured to either of the two subarrays in that half of the
memory. A possible redundancy description follows:
redundancy { row 3:2 data {0 1}
column 1 data {0 1} bank_range {0}
row 3:2 data {2 3}
}
port_alias { rre RENF
rra RRAF[2:0]
rre RENS
rra RRAS[2:0]
cra CRAL[5:0]
cra CRAH[5:0]
}
redundancy { row 3:2 data {0 1}
map {enable RENF address 0:7 RRAF 0:7}
map {data 0:1 address 0:1 CRAL[5:3] shift_right_integer
}
map {data 0:1 address 0:1 CRAL[2:0] shift_right_integer
}
row 3:2 data {2 3}
map {enable RENS address 0:7 RRAS 0:7}
map {data 0:1 address 0:1 CRAH[5:3] shift_left_integer
}
map {data 0:1 address 0:1 CRAH[2:0] shift_left_integer
}
}
In the previous example, RENF/S are positive active row repair enable signals as defined in
the port alias specification and RRAF/S the failing address applied to the left or right half
spare partial row of the memory. The address range is a combination of the bank, address bit
4, and row, address bits 3 to 2, combined in the order required of the RRAF/S memory port
descriptions, memory address bits 4 to 2 in this example. For the column redundancy
expressions, half data IOs are being replaced where bit 0 of the address can be ignored in
the analysis. There is no explicit column repair enable signal, but the all zeroes value of
CRAL/H portion of the vector indicates that no column repair is being requested on that repair
interface. Note the repair vector in CRAH/L shifts the reconfigued column pairs toward the

spare structures in the middle of the physical cell array while removing the bad columns from
use, in effect, translating the failing logical data bit and column addresses to a physical
relocation value.
Figure A-10 Banked row and bit redundancy
address_partition { bank 4 row 3:2 column 1:0 } column mux factor = 4

- or -
address_partition { bank 4 row 3:2 column 1:0 order {data 0:1} {0 1 2 3}
order {data 2:3} {3 2 1 0} }
data bits
0 1 2 3
3 28 29 30 31 28 29 30 31 31 30 29 28 31 30 29 28
2 24 25 26 27 24 25 26 27 27 26 25 24 27 26 25 24
row
1 20 21 22 23 20 21 22 23 23 22 21 20 23 22 21 20
bank 1 0 16 17 18 19 16 17 18 19 19 18 17 16 19 18 17 16
3 12 13 14 15 12 13 14 15 15 14 13 12 15 14 13 12
2 8 9 10 11 8 9 10 11 11 10 9 8 11 10 9 8
row
1 4 5 6 7 4 5 6 7 7 6 5 4 7 6 5 4
bank 0 0 0 1 2 3 0 1 2 3 3 2 1 0 3 2 1 0
Figure A-10 shows a memory with the data words split into two physical halves and the rows
split into two physical banks, resulting in four separate physical memory subarrays. In this
example, each pair of subarrays horizontally has a single full data bit as a reconfigurable unit.
Each of the left and right halves of the memory has a single row which can be reconfigured
to either of the two subarrays in that half of the memory. A possible redundancy description
follows:
redundancy { row 3:2 data {0:1}
column bank_range {0}
row 3:2 data {2:3}
}

port_alias { rre RENF
rra RRAF[2:0]
rre RENS
rra RRAS[2:0]
cra CRAL[2:0]
cra CRAH[2:0]
}
redundancy { row 3:2 data {0:1}
map {enable RENF address 0:7 RRAF 0:7}
map {data 0:3 CRAL[2:0] shift_right_integer
row 3:2 data {2:3}
map {enable RENS address 0:7 RRAS 0:7}
map {data 0:3 CRAH[2:0] shift_right_integer
}
In the previous example, RENF/S are positive active row repair enable signals as defined in
the port alias specification and RRAF/S the failing address applied to the left or right half
spare partial row of the memory. The address range is a combination of the bank, address bit
4, and row, address bits 3 to 2, combined in the order required of the RRAF/S memory port
descriptions, memory address bits 4 to 2 in this example. For the column redundancy
expressions, full data IOs are being replaced. There is no explicit column repair enable signal,
but the all zeroes value of CRAL/H indicates that no column repair is being requested on that
interface. Note the repair vector in CRAH/L shifts the rightmost data bit towards the spare
structures on the right side of the physical cell array while removing the bad columns from
use, in effect, translating the failing logical data bit and column addresses to a physical
relocation value.

Figure A-11 Banked row redundancy with physical order variation
column mux factor = 4

address_partition { bank 0 row 4:3 order {0 1} column 2:1 order { 0 1 2 3 } }
- or -
address_partition { bank 0 row 4:3 order {bank 0} {3 2} order {bank 1} {0 1}
column 2:1 order { 0 1 2 3 } }
data bits
0 1 2 3
3 25 27 29 31 25 27 29 31 25 27 29 31 25 27 29 31
2 17 19 21 23 17 19 21 23 17 19 21 23 17 19 21 23
row
1 9 11 13 15 9 11 13 15 9 11 13 15 9 11 13 15
bank 1 0 1 3 5 7 1 3 5 7 1 3 5 7 1 3 5 7
0 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6
1 8 10 12 14 8 10 12 14 8 10 12 14 8 10 12 14
row
2 16 18 20 22 16 18 20 22 16 18 20 22 16 18 20 22
bank 0 3 24 26 28 30 24 26 28 30 24 26 28 30 24 26 28 30
In Figure A-11, the memory is split horizontally using address bit 0 to address the two banks.
The row order is mirrored across the horizontal axis. Also, a single two-row reparable block is
allocated to each memory bank. Note the redundancy specification ignores the physical row
order in defining the spare capabilities of each memory subarray.
redundancy{ row 4 bank_range {0}
row 4 bank_range {1}
}

port_alias { srsi RR_SI
srso RR_SO
srclk RR_CLK
rre srreg[3]
rre srreg[1]
rra srreg[2]
rra srreg[0]
}
redundancy { row 4 bank_range {0}
map {srsi RR_SI srso RR_SO srclk RR_CLK enable srreg[3]
address 0:1 srreg[2] 0:1}
row 4 bank_range {1}
map {srsi RR_SI srso RR_SO srclk RR_CLK enable srreg[1]
address 0:1 srreg[0] 0:1}
}
In the previous example, two block row repair structures are available, with one spare 2-row
block assigned to each bank of memory. In this situation, a repair register exists within the
memory module itself and is accessed via a serial shift interface. This is indicated by the port
alias definitions: the clock, RR_CLK, to shift the values into the memory-internal register,
srreg[0:3], ordered from shift input, RR_SI, to shift output, RR_SO. srreg[3]/[1] are
positive active row repair enable signals as defined in the port alias specification and
srreg[2]/[0] the failing address applied to the top or bottom bank of the memory. Note
the repair vector in srreg[2]/[0] identifies the reconfigured row pairs replaced by the
spare structures in the middle of the physical cell array while removing the bad row pairs from
use, in effect, translating the failing logical row addresses to a physical relocation value. It is
assumed the low order row address bit 3 can be ignored in the selection of the replaced row
pair.
Descriptions
row {integer| integer:integer }...

Specifies a spare row or contiguous row block available across
the memory or portions of the memory when data or
bank_range expressions described below further refine the
repair capability. When the row expression is used, the
integers must indicate bits of the memory address as defined
in the address_partition row specification. When a
contiguous block of rows is defined as a repair unit, the row
expression indicates address bits in the high end of the range.
The missing row address bits indicate the size of the repair
block, 2(number of missing row address bits).

Default: no row repair

column [{integer| integer:integer }...]
Specifies a spare column or column block available across the
memory or portions of the memory when data or bank_range
expressions described below further refine the repair capability.
When the column expression is used, the integers must
indicate bits of the memory address as defined in the
address_partition column specification. When a
contiguous block of columns is defined as a repair unit, the
column expression indicates address bits in the high end of the
range. The missing column address bits indicate the size of the
repair block, 2(number of missing column address bits). When a full
data IO is replaced, the expression {integer|
integer:integer]}... is not used.
Default: no column repair
data { { bit| bit:bit}... }
The memory word data expression is used, either a single data
{bit}, a contiguous range of data bits, {bit:bit} or a
combination of these expressions, to assign spare resources to
specific data bits of the memory word. All data bits bound to a
spare resource must be identified when the data expression is
used. These bit positions represent logical data bits. If physical
data bit reordering is done within the memory cell array, this
must be considered when grouping spare resources using
logical data bit specifications.
Default: entire data range of the memory word
bank_range {{ integer| integer:integer}... }
bank_range further refines the allocation of spare resources to
banks or subarrays of the memory within the limits imposed by
the address_partition bank definition. The expression
allows specification of values within the memory bank address
range to bind the spare resources to particular banks. The full
potential range of values is zero to 2(number of bank address bits)-1.
All banks bound to a spare resource must be identified when
the bank expression is used and the full range must be
specified. Different bank_range bindings are possible for spare
row resources and spare column resources.
Default: all available banks

map { [srsi port srclk port [srst port] [sre port] [srso port] ]
[enable port]
{ address range port {range | unused} |
data range [port] [address range port] function} }
}
map binds the spare resource allocation to values on ports or

memory module internal repair registers, srreg. If the interface
to the redundant feature is a parallel interface, specific ports are
used to control the data and address port references. An
enable port is specified if used by the memory module for the
redundant resource. Ranges associated with the port are
allowed in these expressions and must take the form of
port[integer] or port[integer:integer] where the
integers represent bit indices in the vectored port. The initial
range in range port range identifies the logical value or
range of values of the data or address fields. The final range
in range port range identifies the corresponding internal
value or range of values necessary to cause the spare feature
to be utilized when this value is presented to port. A value
range is represented by integer:integer.
When a spare row resource is available but not used, the
address range port unused expression is indicated. In
this case, the range is a single integer value applied to the
port. The enable, if available, is tied to its inactive state. This
is indicated by the port_alias specification of the enable or if
part of a single repair bus, the inactive state is assumed zero.
For spare column or data IO resources, function must be
selected from the following set. The data port and address
port are combined as described below and modified by the
selected function.
■ unused
data range port [address range port] unused
range must be a single integer value in both cases. Each

integer value is converted to a binary string and applied
right-to-left to the corresponding port and from right-to-left
within the vectored port when applicable.
data range port unused
range must be a single integer value. The integer value is

converted to a binary string and applied right-to-left to the
corresponding port.

■ integer
■ mask
■ shift_left_integer
■ shift_left_mask
■ shift_right_integer
■ shift_right_mask
If the interface to the redundant feature is a serial interface, a
shift register internal to the memory module already exists to
hold the repair solution. In this case, the register shift input,
srsi port, and register shift clock, srclk port, must be
defined to access the repair register. Optional register shift
asynchronous reset, srst port, register shift clock enable,
sre port, register shift output, srso port, may be specified
if they exist. Subsequently, port references in the enable,
data and address expressions must indicate
srreg[integer] or srreg[integer:integer] to refer
to the appropriate shift register bit(s).
The order of the specified spare resources is a function of the
bit positions within the memory internal shift register, srreg.
If the map expression is not used, PMBIST hardware must be
limited to determining a redundancy analysis solution, but no
PMBIST hardware is implemented to access the memory
module repair registers or any embedded non-volatile memory.
Any repair function is a responsibility of the designer in this
situation.
Default: none

Examples
■ In the configuration below, the redundant features are applicable to the entire memory
and indicate two spare rows which can be individually assigned and a single spare
column. In this example, no map expressions exist, indicating that the redundancy
analysis can be performed by the hardware, but repair is not directly controlled by the
inserted PMBIST.
{
module {
RAM_2000X32
}
{
port_alias
{
we wea
we web
tsuffix Tst
}
port_action
{
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
read_delay 1
address_partition
{
bank 10:9
row 8:3
column 2:0 order { 0 1 3 2 }
}
redundancy
{
row 8:3
row 8:3
column 2:0
}
}
}

■ In the configuration below, the redundancy is specified using banks and columns. The
module has four banks and two spare data bits per bank pair. In this example, no map
expressions exist, indicating that the redundancy analysis can be performed by the
hardware, but repair is not directly controlled by the inserted PMBIST.
{
module {
RAM_2000X32
}
{
port_alias
{
we wea
we web
tsuffix Tst
}
port_action
{
tune_1 0
tune_2 1
func_op U
}
address_limit 2000
read_delay 1
address_partition
{
bank 10:9
row 8:3
column 2:0 order { 0 1 3 2 }
}
redundancy
{
column bank_range {0:1}
}
}
}

macro Group
macro {
macro_list
}
{
}
Describes the set of memories contained within a core or hierarchical design module and the
block port connections necessary to test these memories when the PMBIST logic must
connect to these predefined macro ports.
This information includes:

■ The mapping from macro ports to internal memory module ports to enable physical
memory testing
■ The ability to slice physical memories into smaller testable units while still supporting
repair features spanning the full physical memory
■ The ability to control the valid address and data bit ranges within the physical memories
■ The ability to control the separation between consecutive memory requests while
constraining the time certain signals are held in their active states
A macro group should be defined for each independently controlled memory test interface
available within the macro.
Descriptions
macro_list Lists the design modules to which the specifications apply.

Following is a list of the macro specifications:
name_specification
[port_access_specification]
port_alias_specification
[port_action_specification]
[assertion_limit_specification]
memory_map_specification...
Within a macro group, each specification can appear only once

with the exception of the memory map specification. The order
of the macro specifications is not relevant.

Related Information
assertion_limit Specification on page 202
memory_map Specification on page 204
name Specification on page 195
port_access Specification on page 196
port_action Specification on page 200
port_alias Specification on page 198

name Specification
name [macro_instance_name:]macro_interface_name
Specifies the name associated with a macro statement and a memory test interface on that
macro. In some cases, where a macro is used more than once, it may be necessary to create
a unique macro view per instance. For these cases the macro_instance_name can be
included in the name value above to disambiguate each use.
Description
macro_instance_name Indicates an instance name of the macro, perhaps a partial

path name in the design, referenced in the target list to
connect memory BIST at some level of hierarchy within the
associated macro using the available memory test interface.
macro_interface_name Indicates the last qualifier of the name referenced in the
target list to connect memory BIST either at the boundary or
some level of hierarchy within the associated macro using the
available memory test interface.
Default: none
Example
In the configuration below, a two processor L1 cache memory test interface and an L2 cache
memory test interface are named against a common core.
{
macro {
mp_core
}
{
name mp_core_L1_mbist
}
}
{
macro {
mp_core
}
{
}
}

port_access Specification
port_access {
{ assign {port|pin} binary_string [tam] |
sample {port|pin} binary_string }...
}
Defines ports on the macro module boundary or pins internal to the macro module which can
be assigned values or sampled for values in the testplan prologue and epilogue
expressions, algorithm assign expressions, and memory_map expressions. Each port/
pin can be a scalar or a vector. Vector notation requires the use of brackets, "[" and "]", to
enclose bit indices separated by a ":" when indicating a range of signals.
Pin references are path names relative to the macro module boundary. "/" is used as the
hierarchical separator.
Description
assign {port|pin} binary_string [tam]
Indicates the port/pin can be assigned values during testing

by the memory BIST logic. The binary_string is a binary
integer indicating the inactive state of the signal. Bit values in
the string are assigned to vectored positions left to right
according to the order indicated in the vector notation.
Normally, the memory BIST logic controls and samples these
signals during testplan execution after binding these signals to
the execution register map (xmap), but it is also possible for the
test access method to manage assignment of certain signals
when test vectors are generated. For those signals which the
user wants to ensure are controlled via the test access method
testplans the tam option should be specified. This creates an
entry in the interface register map (imap).
sample {port|pin} binary_string
Indicates the port/pin can be sampled for values during

testing by the memory BIST logic. The binary_string is a
binary integer indicating the inactive state of the signal. Bit
values in the string are assigned to vectored positions left to
right according to the order indicated in the vector notation.
Default: none

Example
In the configuration below, a two processor L1 cache memory test interface and an L2 cache
memory test interface have handshaking signals which must be used to establish memory
BIST control of the memories prior to starting actual memory BIST operations. In this
situation, the mbreq1 and mbreq2 ports request PMBIST operations should commence and
the mback1 and mback2 signals acknowledge it is safe to start PMBIST operations on the
memories associated with the respective interfaces.
{
macro {
mp_core
}
{
port_access {
assign mbreq1[1:0] 00
assign mbcpid[1:0] 00
assign mblogarray1[1:0] 00
assign mbaddr1[10:7] 0000
sample mback1[1:0] 00
}
}
}
{
macro {
mp_core
}
{
port_access {
assign mbreq2 0
sample mback2 0
}
}
}

port_alias Specification
port_alias {
base_port [.integer ] aliased_port_or_pin
[base_port [.integer ] aliased_port_or_pin ]...
}
In the macro context, port_alias specifies how to bind the macro module ports or pins to
the base port names necessary to test the physical memories accessible through the macro
interface. Each port or pin can be either a scalar or a vector. The .integer notation is
available when multiple port memories exist within the macro and are supported by unique
control interfaces within the macro. For a macro, the minimum set of base port names which
must be defined include clk, a, d, q.
Description
For details refer to port_alias Specification on page 153.
Example
In the configuration below, the appropriate interface signals are defined within the module as
macro interface connection points for the PMBIST logic.
{
macro {
mp_core
}
{
port_access {
}
port_alias {
a mbaddr1[10:0]
clk CLK
we mbwe1
wem mbwem1
re mbre1
d mbdatain1[127:0]
q mbdataout1[127:0]
}
}
}

{
macro {
mp_core
}
{
port_access {
assign mbreq2 0
sample mback2 0
}
port_alias {
a mbaddr2[12:0]
clk CLK
we mbwe2
re mbre2
d mbdatain2[143:0]
q mbdataout2[143:0]
}
}
}

port_action Specification
port_action {
{port|pin} {0|1|U|X}
[{port|pin} {0|1|U|X}]...
default {0|1|U|X} }
In the macro context, port_action specifies how to control the macro module ports and
pins that are not used by the PMBIST logic but must remain in a stable state for the duration
of the PMBIST operations. Each port/pin can be a scalar or a vector. If the signal is a vector,
you can either specify one value to connect all bits of the bus in a similar fashion, or you can
specify a value for each bit, referred to as bit indexing. In the latter case, the tool will error out
if the supplied bit string does not match the bus width. Vector notation requires the use of
brackets, "[" and "]", to enclose bit indices separated by a ":" when indicating a range of
values.
Description
For details refer to port_action Specification on page 158.

Note: If more than one memory test interface is defined on a macro module, port actions may
be applied by any of the memory test interfaces. If these interfaces have overlapping
port_action specifications, those ports/pins commonly controlled should assert the same
value in all cases. Otherwise, this mechanism cannot be used to assert values and
testplan prologue signal assignments should be used instead.
Example
In the configuration below, certain DFT and power switch enable signals must be controlled
during PMBIST operations.
{
macro {
mp_core
}
{
port_access {
}
port_alias {

a mbaddr1[10:0]
clk CLK
we mbwe1
wem mbwem1
re mbre1
d mbdatain1[127:0]
q mbdataout1[127:0]
}
port_action {
dftse 0
dftmembypass 0
pwrupcpul1 11
}
}
}
{
macro {
mp_core
}
{
port_access {
assign mbreq2 0
sample mback2 0
}
port_alias {
a mbaddr2[12:0]
clk CLK
we mbwe2
re mbre2
d mbdatain2[143:0]
q mbdataout2[143:0]
}
port_action {
dftse 0
dftmembypass 0
pwrupl2 1
}
}
}

assertion_limit Specification
assertion_limit {
{{port|pin} integer }...
}
For a memory test interface on a macro that requires more than one cycle between
consecutive requests to the memory under test, it is possible that certain control signals must
remain asserted for fewer clock cycles than the period between requests. In such situations,
the assertion_limit can be used to indicate these signal constraints to PMBIST.
Description
{{port|pin} integer port/pin indicates the name of the macro module port or pin
}... while integer defines the number of PMBIST clock cycles the
asserted signal may remain active. This number of cycles must
be less than or equal to the spacing between consecutive
requests to the memory under test.
Default: the number of cycles between consecutive
requests to the memory under test
Example
In the configuration below, an L2 cache memory test interface permits memory requests
every two cycles. However, the read and write enable signals, mbre2 and mbwe2, activation
must be limited to a single cycle for proper memory opertions. All other signals controlled by
PMBIST on this interface can be asserted for the full two cycles.
{
macro {
mp_core
}
{
port_access {
}
port_alias {
a mbaddr1[10:0]

clk CLK
we mbwe1
wem mbwem1
re mbre1
d mbdatain1[127:0]
q mbdataout1[127:0]
}
port_action {
dftse 0
dftmembypass 0
pwrupcpul1 11
}
}
}
{
macro {
mp_core
}
{
port_access {
assign mbreq2 0
sample mback2 0
}
port_alias {
a mbaddr2[12:0]
clk CLK
we mbwe2
re mbre2
d mbdatain2[143:0]
q mbdataout2[143:0]
}
port_action {
dftse 0
dftmembypass 0
pwrupl2 1
}
assertion_limit {
mbwe2 1
mbre2 1
}
}
}

memory_map Specification
memory_map {
[target_map {
{port|pin} [{ binary_string[ binary_string]... }] ...
} ]
[port_action {
{port|pin} binary_string ...
} ]
read_delay integer [ + port_assign ]...
[request_latency integer [ + port_assign ]...]
[write_mask_binding {
} ]
segment {
memory_module module_name
[address_limit integer]
instances { instance_name[ instance_name]... }
[segment_map {
} ]
port_alias {
base_port[.integer] aliased_port_expression ...
}
} ...
}
Specifies the set of physical memories and their features associated with a logical memory
accessed from the boundary or within a hierarchical level of the macro. The mapping enables
PMBIST to test and repair individual physical memory instances while being connected to a
predefined interface to the macro.
Description
target_map { {port|pin} [{ binary_string[ binary_string]... }] ... }
The target_map is used to identify a set of ports/pins which

control access to a physical memory set comprising a logical
memory. Each port/pin is given its full range of binary values
unless constrained by the { binary_string[
binary_string]... } range expression which identifies the set
of values the port/pin may be assigned. Each unique set of
values across the set of ports in the target map represents a
unique physical memory or possibly more than one in cases
where the physical memory input and output data bits do not
share bit positions on the shared macro data interface.

Default: none
port_action { {port|pin} binary_string ...}
For situations where configuration controls affect the

characteristics of the target(s), and they can be modified at
runtime, these port_action statements can be used to
specify the values. They are considered constant for the
duration of the tests applied to the target(s). Each such port/pin
must have been previously defined by a port_access
assign... statement.
read_delay integer integer indicates the number of system clock cycles required for
[ + port_assign ]... new data to appear on the macro data output signals once a
read operation is presented to the macro test interface input
signals. This value includes all clock cycles due to memory
access and embedded pipeline register stages.
For situations where configuration controls affect this value at
runtime, one or more port_assign expressions, each being a
port/pin of a port_access assign... statement, can be
used as a source of information to adjust this read_delay
value. The unsigned integer value of each port_assign is
added to the integer value. The value for each port_assign
must appear in either a target_map, segment_map, or
port_action within the memory_map statement.
See read_delay Specification on page 161 for additional
information.
Default: none
request_latency integer integer indicates the number of system clock cycles between
[ + port_assign ]... consecutive requests presented to the macro test interface
input signals to test the designated memory.
For situations where configuration controls affect this value at
runtime, one or more port_assign expressions, each being a
port/pin of a port_access assign... statement, can be
used as a source of information to adjust this
request_latency value. The unsigned integer value of each
port_assign is added to the integer value. The value for
each port_assign must appear in either a target_map,
segment_map, or port_action within the memory_map
statement.
Default: 1

write_mask_binding {integer { {bit | bit:bit}... } ...}
Specifies the association of macro memory test interface write

mask bits with the macro write data input bits connected to the
memories in this memory_map specification.
■ integer indicates a mask bit in the macro write mask port.
■ bit indicates one logical data bit index while bit:bit
indicates a contiguous range of logical bits within the macro
write data input bus.
See write_mask_binding Specification on page 166 for
additional information.
Default: none
segment { memory_module module_name [address_limit integer] instances
{instance_name[ instance_name]...} [segment_map {{port|pin} binary_string ...}]
port_alias {base_port[.integer] aliased_port_expression ... } }
One or more segment expressions comprise a physical

memory module definition. A segment expression is required
for each unique binding of macro ports/pins to physical memory
ports. This can occur when multiple physical memories are
simultaneously accessed or when a single physical memory is
sliced into multiple testable units.
Identifies the memory module used by this physical set of

memories.
Default: none
address_limit integer
Specifies the number of used words in the memory.

Default: the number of addressable words in the
memory as defined in the associated memory
module definition

Lists the instance or instances of the physical memory module

associated with this segment specification. Instance names are
fully qualified names relative to the design module boundary on
which the macro interface exists using "/" as a hierarchy
separator. In cases where a target_map and/or
segment_map specification indicates a range of values, and,
therefore, a set of physical memories, this instance list should
be created in ascending sequence with a one-to-one
correspondence to the bit string created from the port/pin
assignments concatenated from top to bottom using any
target_map entries followed by any segment_map entries.
Default: none
■ A single optional segment_map {{port|pin}
binary_string ...} expression can be specified to
indicate signal value assignments which identify this
physical array during PMBIST. This is typically used to
indicate how a single physical memory is sliced into multiple
testable units that share redundant resources. Each port/
pin can be a scalar or a vector. Vector notation requires the
use of brackets, "[" and "]", to enclose bit indices separated
by a ":" when indicating a range of values. Bit values in the
string are assigned to vectored positions left to right
Each such port/pin must have been previously defined
using a port_access Specification on page 196.
■ A single required port_alias
{base_port[.integer]
aliased_port_expression ... } expression
specifies the binding of macro signals within
aliased_port_expression to predefined memory
base_port functions. Each signal within the
aliased_port_expression can be a scalar or a vector
which must have been defined previously in the macro
port_alias expression. Vector notation requires the use
of brackets, "[" and "]", to enclose bit indices separated by a
":" when indicating a range of values. The integer qualifier
supports binding different ports on a multiple port memory.
The default assumes a single memory port.
See port_alias Specification on page 153 for additional
information.

Default: none
aliased_port_expression is further defined as
[binary_string,]aliased_port_or_pin[,aliased_port_or_pin]... [,binary_string]
[=bit_range[,binary_string]]
The binary_string above allows for a portion of a memory

bus to be held at constant value. In conjunction with the
concatenation of multiple aliased_port_or_pin
expressions some flexibility is supported in connecting the
physical memory buses to macro interface ports/pins. Finally,
the expression following the "=" can be used with the data input
and output buses on the physical memory to indicate the actual
bit positions within the memory being accessed. The
bit_range requires the use of brackets, "[" and "]", to enclose
bit indices separated by a ":" when indicating a range of values.
This supports the capability to make some high-order and/or
low-order data bits inaccessible as well as supporting testing
data slices of the memory serially.
Default: none
Example
In the configuration below, two logical memories, mblogarray1, exist per two processors,
mbcpid, in the L1 memory test interface and two logical memories, mblogarray2, exist
within the L2 memory test interface. The first logical memory in the L1 interface uses two
instances, mbaddr1[8], of a ram128x64cm4, but only half of the memory can be tested at
a time as seen in the segment definitions using q and d base ports. The second logical
memory in the L1 interface uses four instances, mbaddr1[10:9], of a ram512x128cm2
and a write mask distributed one write mask bit per contiguous eight data bits.
The first logical memory in the L2 interface uses eight instances, mbaddr2[10:9], of a
ram512x72cm4 to implement a 144-bit wide logical memory as seen in the segment
definitions using q and d base ports. The second logical memory in the L2 interface uses
thirty-two instances, mbaddr2[12:8], of a ram256x64cm2. Consecutive requests to both
of these logical memories are minimally 2 cycles apart as seen in the request_latency.
{
macro {
mp_core
}
{
port_access {

}
port_alias {
a mbaddr1[10:0]
clk CLK
we mbwe1
wem mbwem1[15:0]
re mbre1
d mbdatain1[127:0]
q mbdataout1[127:0]
}
port_action {
dftse 0
dftmembypass 0
pwrupcpul1 11
}
memory_map {
target_map {
mbcpid[1:0] {00 01}
mblogarray1[1:0] {00}
mbaddr1[10:9] {00}
mbaddr1[8]
}
read_delay 8
segment {
memory_module ram128x64cm4
instances { cp[0]/lsram_0 cp[0]/lsram_1 }
cp[1]/lsram_0 cp[1]/lsram_1 }
segment_map {
mbaddr1[7] 0
}
port_alias {
a mbaddr1[6:0]
d mbdatain1[31:0]
we mbwe1
re mbre1
q mbdataout1[31:0]
}
}
segment {
instances { cp[0]/lsram_0 cp[0]/lsram_1 }
cp[1]/lsram_0 cp[1]/lsram_1 }
segment_map {
mbaddr1[7] 1
}
port_alias {
a mbaddr1[6:0]
d mbdatain1[31:0]=[63:32]
we mbwe1
re mbre1
q mbdataout1[31:0]=[63:32]
}
}
}
memory_map {
target_map {
mbcpid[1:0] {00 01}

mbaddr1[10:9]
}
read_delay 9
0 {0:7}
1 {8:15}
2 {16:23}
3 {24:31}
4 {32:39}
5 {40:47}
6 {48:55}
7 {56:63}
8 {64:71}
9 {72:79}
10 {80:87}
11 {88:95}
12 {96:103}
13 {104:111}
14 {112:119}
15 {120:127}
}
segment {
instances { cp[0]/diffram00 cp[0]/diffram01
cp[0]/diffram10 cp[0]/diffram11
cp[1]/diffram00 cp[1]/diffram01
cp[1]/diffram10 cp[1]/diffram11 }
port_alias {
a mbaddr1[8:0]
d mbdatain1[127:0]
we mbwe1
wem mbwem1[15:0]
re mbre1
q mbdataout1[127:0]
}
}
}
}
}
{
macro {
mp_core
}
{
port_access {
assign mbreq2 0
sample mback2 0
}
port_alias {
a mbaddr2[12:0]
clk CLK
we mbwe2
re mbre2
d mbdatain2[143:0]
q mbdataout2[143:0]
}
port_action {

dftse 0
dftmembypass 0
pwrupl2 1
}
assertion_limit {
mbwe2 1
mbre2 1
}
memory_map {
target_map {
mbaddr2[12:11] {00}
mbaddr2[10:9]
}
read_delay 10
request_latency 2
segment {
instances { l2ram00_lo l2ram01_lo l2ram10_lo l2ram11_lo }
port_alias {
a mbaddr2[8:0]
d mbdatain2[71:0]
we mbwe2
re mbre2
q mbdataout2[71:0]
}
}
segment {
instances { l2ram00_hi l2ram01_hi l2ram10_hi l2ram11_hi }
port_alias {
a mbaddr2[8:0]
d mbdatain2[143:72]
we mbwe2
re mbre2
q mbdataout2[143:72]
}
}
}
memory_map {
target_map {
mbaddr2[12:8]
}
read_delay 12
request_latency 2
segment {
instances { l2recram00 l2recram01 l2recram02 l2recram03
l2recram04 l2recram05 l2recram06 l2recram07
l2recram08 l2recram09 l2recram0a l2recram0b
l2recram0c l2recram0d l2recram0e l2recram0f
l2recram18 l2recram19 l2recram1a l2recram1b
l2recram1c l2recram1d l2recram1e l2recram1f }
port_alias {
a mbaddr2[7:0]
d mbdatain2[63:0]
we mbwe2
re mbre2

q mbdataout2[63:0]
}
}
}
}
}

algorithm_constraints Specification
[algorithm_limit integer ]
[access_limit integer ]
[repeat_limit integer ]
[log2b_limit integer ]
[pause_duration integer {ms|us}]
[macro_support {no | yes}]
[simple_instructions_only {no | yes}]
[cell_test_support {no | yes}]
[address_orders {
[ no-update | nu ]
[ fast-row | fr ]
[ fast-column | fc ]
[ fast-diagonal | fd ]
} ]
[address_updates {
[ linear | li ]
[ complement | ca ]
[ twos-power | 2i ]
[ worstcase | wc ]
[ shifted | s1 ]
[ next-physical | np ]
[ next-address | na ]
} ]
[data_backgrounds {
[ solid | s ]
[ checkerboard | cb ]
[ row-stripe | rs ]
[ column-stripe | cs ]
[ column-stripe-solid-pairs | cssp ]
[ column-stripe-checkerboard-pairs | cscbp ]
[ log2b]
} ]
}
Hardware resources are required to support execution of PMBIST algorithms. By default,

decisions are made by the PMBIST software establishing the minimum requirements
necessary to support the algorithms selected within the configuration file.
algorithm_constraints allows you to override these choices in favor of anticipated
future support should the need arise later in the testing process after PMBIST insertion.
The specification of any testplan as programmed in the configuration file forces the
insertion of programmable algorithm hardware into the PMBIST logic.
Descriptions
algorithm_limit integer

Defines the maximum number of memory accesses and macro

accesses as well as control instructions which can exist within
the algorithm memory register storage implemented in the
hardware. Set this to a number which can at least support the
largest algorithm requirement. See access_limit below for
more information.
Default: determined by used algorithms within the
configuration file.
access_limit Defines the maximum number of memory accesses and macro
integer accesses which can exist within a sequence iterator, the
minimum executable unit within the PMBIST engines. Each
memory access counts as one entry. Each macro access
containing a single memory access counts as two entries. Each
macro access containing n memory accesses if followed by a
macro access counts as n+1 entries while if followed by a
memory access counts as n+2 entries.
configuration file
repeat_limit Defines the maximum number of iterations any repeated macro
integer access may execute.
Default: the greater of requirements determined by used
algorithms within the configuration file and largest write enable
mask test requirements
log2b_limit Defines the log2 of the maximum number of contiguous ones
integer and contiguous zeroes, typically half the memory word size,
applied to the memory word data background.
Default: 1
pause_duration integer {ms | us}
Defines the time between successive memory accesses in an
algorithm when a pause instruction is specified. This is typically
on the order of 50ms or 100ms.
Default: 100ms
macro_suport {no | yes}
Defines whether macro accesses must be supported by the
inserted PMBIST hardware. If no is specified, the ability to
support any algorithm which requires such a capability is
removed.


configuration file
simple_instructions_only {no | yes}
Defines whether the instruction set supporting the used
algorithms can be limited to the simple set in the inserted
PMBIST hardware, thereby reducing PMBIST area cost.
If macro_support yes is specified,
simple_instructions_only no is forced by the PMBIST
application.
configuration file
cell_test_support {no | yes}
Defines whether cell-oriented testing must be supported by the
inserted PMBIST hardware. This is typically required only to
support the multiple port memory test algorithm, but may be
requested for any algorithm.
If cell_test_support yes is specified, macro_support
yes is forced by the PMBIST application.
Default: determined by used algorithms and targeted
memories within the configuration file.
address_orders { [no-update|nu] [fast-row|fr] [fast-column|fc]
[fast-diagonal|fd] }
address_orders control the manner in which the address
progresses through the physical memory cell space for the
algorithms within a testplan. insert_dft pmbist
analyzes the set of testplans to determine the minimum set
required, but the user can directly enable more implemented
hardware options using this expression. See “testplan
Specification” on page 222 for more details.
address_updates { [linear|li] [complement|ca] [twos-power|2i]
[worstcase|wc] [shifted|s1] [next -physical|np] [next-address|na] }

address_updates control the manner in which the address is

transformed prior to applying it to the memories under test.
More than one selection may be made within a testplan.
insert_dft pmbist analyzes the set of testplans to
determine the minimum set required, but the user can directly
enable more implemented hardware options using this
expression. See “testplan Specification” on page 222 for more
details.
data_backgrounds { [solid|s] [checkerboard|cb] [row-stripe|rs]
[column-stripe|cs] [column-stripe-solid-pairs|cssp] [column-
stripe-checkerboard-pairs|cscbp] [log2b] }
data_backgrounds control the manner in which data are
stored into the memory physical cell array taking into account
the physical row and column structure. More than one
data_backgrounds choice may be selected within a
testplan. insert_dft pmbist analyzes the set of
testplans to determine the minimum set required, but the user
can directly enable more implemented hardware options using
this expression. See “testplan Specification” on page 222 for
more details.
Example
The configuration file indicates a set of preferred limit values and hardware options.
algorithm_limit 64
access_limit 8
repeat_limit 256
pause_duration 50ms
macro_support yes
}

algorithm Specification
algorithm {
name algorithm_name
{
{wait integer |
pause |
address_direction (sequence_iterator) }...
}
}
address_direction =
{ null | up | u | down | dn | d }
sequence_iterator =
{memory_access | macro_access}[,{memory_access | macro_access}]...
macro_access =
{null | row | col | diag | integer | all}(memory_access[,memory_access]...)
memory_access =
{ {- | r | w}{0 | 1 | -}{ null | b | m | s} }
Algorithms are comprised primarily of sequences of memory read and write operations.
These sequences can be grouped into sets which are applied to a single memory address
at a time. We iterate through the memory address space, executing this sequence for each
memory address, prior to executing the next sequence. In this context, algorithms are
comprised of a set of sequence iterators.
Descriptions
name algorithm_name
Defines the name of the algorithm to enable reference in the
testplan specifications. Each name must be unique within
the context of the defining configuration file and not match any
of the pre-defined algorithm names.
Default: none
wait integer This expression causes the PMBIST engines to suspend
execution of the algorithm at the current point for integer
cycles. This is typically used for small delays associated with
extended function testing in user-defined algorithms.
The integer must not exceed the
algorithm_constraints repeat_limit value.
Default: none

pause This expression causes the PMBIST engines to suspend

execution of the algorithm at the current point for the interval
specified by algorithm_constraints pause_duration.
It is most often associated with memory retention testing.
Default: none
address_direction Indicates the direction the address updates between
consecutive executions of the sequence iterator, either by an
increasing or decreasing value.
■ { null | up | u }—Indicates an increasing value of
the address from one iteration to the next.
■ { down | dn | d }—Indicates a decreasing value of the
address from one iteration to the next.
Default: null
{null | row | col | diag | integer | all}
Indicates the class of the macro access for the memory
accesses contained within the associated parentheses for the
macro. Memory accesses within the macro are defined as
either base memory accesses or macro memory accesses. See
the memory access description below for further information.
■ null—Indicates the set of macro memory accesses
defined by this macro are applied to all addresses
associated with this memory, except the current address.
Any base memory accesses within the macro are
performed for each execution of the macro.
■ row—Indicates the set of macro memory accesses defined
by this macro are applied to all column addresses
associated with this memory row, except the current column
address. Any base memory accesses within the macro are
■ col—Indicates the set of macro memory accesses defined
by this macro are applied to all row addresses associated
with this memory column, except the current row address.
Any base memory accesses within the macro are

■ diag—Indicates the set of macro memory accesses

defined by this macro are applied to all row and column
addresses associated with this memory diagonal, except
the current row and column address. Any base memory
accesses within the macro are performed for each
execution of the macro.
■ integer—Indicates the set of base and macro memory
accesses defined by this macro are applied to the current
base and macro addresses, respectively, integer number
of times.
■ all—Indicates the set of macro memory accesses defined
by this macro are applied to all addresses associated with
this memory, including the current address. Any base
memory accesses within the macro are performed for each
execution of the macro.
Default: none
{- | r | w}{0 | 1 | -}{ null | b | m | s}
Defines the characteristics of the memory access.
■ {- | r | w}—Indicates the memory access is either a no
operation, -, a read, r, or write, w, reference. In multiple port
applications, a write access occurs to a single memory port
and all other ports receive no operation; a read access is
always applied to all memory ports capable of performing a
read access.
■ {0 | 1 | -}—Indicates the memory access makes a true
data background reference, 0, or an inverted data
background reference, 1. - can be used for read accesses
only to indicate the content of the memory access is
ignored, no data comparison occurs for this read access.
■ {null | b | m | s}—Indicates the memory access is
either using a base address, null or b, or a macro address,
m. The base address is effectively constant throughout each
execution of the sequence iterator. The macro address is
allowed to vary during execution of the macro as required by
the macro class and for certain selections of
address_updates as defined in the testplan. s is valid
only in conjunction with the log2b background as defined
in the testplan. It is used to force an alternating solid
background during the use of log2b background testing.

Examples
■ The example below is a March LR algorithm.
algorithm {
name march_lr
{
(w0)
dn(r0,w1)
(r1,w0,r0,w1)
(r1,w0)
(r0,w1,r1,w0)
(r0)
}
}
■ The example below is a March G algorithm which includes a data retention test indicated
by the two pause commands.
algorithm {
name march_g
{
(w0)
(r0,w1,r1,w0,r0,w1)
(r1,w0,w1)
d (r1,w0,w1,w0)
d (r0,w1,w0)
pause
(r0,w1,r1)
pause
(r1,w0,r0)
}
}

■ The following example uses the macro notation to perform a galloping pattern (GalPat)
test. The first sequence iterator, (w0), writes a true data background throughout memory
in an ascending address direction.
The second sequence iterator, (w1,(r0m,r1),w0), includes an unqualified macro
access, (r0m,r1). For each address referenced by the sequence iterator, called the base
address, the iterator first writes an inverted data background into the location, w1. Then
the macro access is repeated for all memory addresses starting with zero, applying a
read of the true data background to the updating macro address followed by a read of
the inverted data background to the current base address, with the exception that when
macro address equals base address, the macro read access is not performed. Finally a
write of the true data background is performed to the current base address, w0, restoring
the original data values. Then the base address is updated to the next ascending
address and the sequence iterator is repeated until all memory addresses have been
referenced as the base address.
The last two sequence iterators repeat the memory accesses of the first two sequence
iterators but using inverted data backgrounds.
algorithm {
name galpat
{
(w0)
(w1,(r0m,r1),w0)
(w1)
(w0,(r1m,r0),w1)
}
}

testplan Specification
testplan {
name testplan_name
[address_orders {
[ no-update | nu ]
[ fast-row | fr ]
} ]
[address_updates {
[ linear | li ]
[ complement | ca ]
[ twos-power | 2i ]
[ worstcase | wc ]
[ shifted | s1 ]
} ]
[data_backgrounds {
[ solid | s ]
[ row-stripe | rs ]
[ log2b ]
} ]
[data_orientation { word | cell }]
[prologue {
{assign xmap_register | imap_register } binary_string |
wait xmap_register binary_string |
wait integer }...
} ]
[algorithms {
algorithm_name ...
} ]
[epilogue {
{assign { xmap_register | imap_register } binary_string |
wait integer }...
} ]
[onetime]
[hardwired | programmed]
}
algorithm definitions specify the sequence of events for a given memory test. When macro
accesses are used they carry a pre-determined address_order. testplan definitions fill
in the remaining undefined characteristics of a set of algorithms to apply in a given memory
test. These include the order in which addresses are updated, the transformation applied to
each address prior to applying it to memory, and the data values to be written and
subsequently read within the memory cells. Further, the algorithms can generally be executed
in a manner which allows either a word-oriented test or a cell-oriented test. If a memory has
N address bits, it contains W=2N words of B bits with a total number of memory cells
n=W*B=2N*B. For any given algorithm, a word-oriented version of the test executes faster
than its corresponding cell-oriented version.

For each testplan, it is possible to execute an optional entry sequence, a prologue, which
is applied once prior to execution of any algorithm. After this step, execution of the set of
algorithms against the set of combinations of the selected address_orders,
address_updates, and data_backgrounds occurs. Finally, execution of an optional exit
sequence, an epilogue, occurs.
The testplan must be labeled with a name for specification in the target groups. The
testplan can be marked to be hardwired into the PMBIST logic or programmed via the
external access method.
Descriptions
name testplan_name Defines the name of the testplan to enable reference in the
target groups. Each name must be unique within the context
of the design.
address_orders { [no-update|nu] [fast-row|fr] [fast-column|fc]
[fast-diagonal|fd] }
address_orders control the manner in which the address
progresses through the physical memory cell space for the
algorithms in the testplan. More than one selection may
be made within a testplan.
■ no-update|nu—Indicates that neither the row nor the
column portion of the address are updated with higher
priority. This is useful only in conjunction with the
address_updates values of worstcase and shifted.
■ fast-row|fr—Indicates that the row portion of the
address is updated first, incrementing the row counter by
one. At each wrap of the row address portion, any column
portion of the address is updated. At each wrap of the row
and column address segments, any bank portion of the
address is incremented by one. When all valid address
segments wrap simultaneously, the sequence is complete.

■ fast-column|fc—Indicates that the column portion of

the address is updated first, incrementing the column
counter by one. At each wrap of the column address
portion, any row portion of the address is updated. At each
wrap of the row and column address segments, any bank
portion of the address is incremented by one. When all valid
address segments wrap simultaneously, the sequence is
complete.
■ fast-diagonal|fd—Indicates that the column and row
portions of the address are updated simultaneously,
incrementing the row and column counters by one except
when the row counter wraps it updates by two. At each wrap
of the row and column address segments, any bank portion
of the address is incremented by one. When all valid
address segments wrap simultaneously, the sequence is
complete.
Default: fast-column
address_updates { [linear|li] [complement|ca] [twos-power|2i]
[worstcase|wc] [shifted|s1] [next-physical|np] [next-address|na] }
address_updates control the manner in which the address is
transformed prior to applying it to the memories under test. A
final ones complement transformation is applied if the
address_direction of the sequence iterator is down. More
than one selection may be made within a testplan.
■ linear|li—The linear address counter is applied directly
as the memory address. A single pass through the address
range occurs.
■ complement|ca—The linear address is incremented
every second cycle as the memory address. On the
interleaved cycles, the ones complement of the preceding
linear memory address is presented. A single pass through
the address range occurs.
■ twos-power|2i—For each of the address bits a, where
0<=a<=N, a pass through the address range occurs where
the binary value of address bits 0 and a are swapped.

■ worstcase|wc—For each of the address bits a, where

0<=a<=N, a pass through the address range is
accomplished where the binary value of address bit a is
inverted on every memory macro access while the base
access is not. Using an algorithm macro access feature a
worst-case gate delay algorithm can be implemented.
■ shifted|s1—This address_update mechanism starts
at address zero and shifts a one through each address bit
a, where 0<=a<=N. It is intended for PMBIST connectivity
tests with minimal execution time by reducing the accessed
memory addresses to N+1.
This address_updates option must be used in
conjunction with address_orders no-update.
■ next-physical|np—Based upon the
address_orders option the appropriate address
segment, row or column, is converted to a physical address,
updated by plus one, then converted back to a logical
address prior to the memory access.
■ This address_updates option must be used in
conjunction with address_orders fast-row or fast-
column.
■ next-address|na—Based upon the address_orders
option the appropriate address segment, row or column,
has its least significant bit inverted prior to the memory
access.
Default: linear
data_backgrounds { [solid|s] [checkerboard|cb] [row-stripe|rs]
[column-stripe|cs] [column-stripe-solid-pairs|cssp] [column-
stripe-checkerboard-pairs|cscbp] [log2b] }
data_backgrounds control the manner in which data are
stored into the memory physical cell array taking into account
the physical row and column structure. A true pattern is stored
into the addressed location when a w0 memory access is
executed; an inverted pattern is stored when a w1 memory
access is executed. More than one data_backgrounds
choice may be selected within a testplan.
■ solid|s—A true pattern of zero is written to each
addressed memory cell.

■ checkerboard|cb—A true pattern of alternating zero and

one values is written to each even physical row in the
memory cell array and alternating one and zero values are
written to each odd physical row in the memory cell array.
■ row-stripe|rs—A true pattern of all zero values is
written to each even physical row in the memory cell array
and all one values are written to each odd physical row in
the memory cell array.
■ column-stripe|cs—A true pattern of all zero values is
written to each even physical column in the memory cell
array and all one values are written to each odd physical
column in the memory cell array.
■ column-stripe-solid-pairs|cssp—A true pattern of
all zero values is written to each even physical column pair
in the memory cell array and all one values are written to
each odd physical column pair in the memory cell array.
■ column-stripe-checkerboard-pairs|cscbp—A
true pattern of zero-one values is written to each row of
each even physical column pair in the memory cell array
and one-zero values are written to each row of each odd
physical column pair in the memory cell array.
■ log2b—A true pattern of repeated 2n(ones)&2n(zeroes) is
written to each memory word beginning from the least
significant bit in the word. The value of n can vary from 0 to
log2b_limit during the application of the data background.
■ Use of this data background has numerous restrictions
noted below.
Default: solid
data_orientation { word | cell }
data_orientation controls the manner in which data are
processed within the memory, either as words or cells. word-
oriented execution of an algorithm is always faster than the cell-
oriented version. In general, algorithms which require
consecutive memory accesses with topological or physical
address adjacency must be cell-oriented. Otherwise, word-
oriented testing should be used to reduce execution times.
■ word—The smallest addressable data unit is a memory
word, yielding a word-oriented memory test.

■ cell—The smallest addressable data unit is a memory

cell, yielding a cell-oriented memory test.
Default: word is the only valid option in this release
Default: none
assign { xmap_register | imap_register } binary_string
Indicates signal value assignments to PMBIST engine control

registers. Each xmap_register can be a scalar or vector
predefined register. Vector notation requires the use of
brackets, "[" and "]", to enclose bit indices separated by a ":"
when indicating a range of values. Bit values in the
binary_string are assigned to vectored registers left to right
imap_register references are limited to test-access-
method qualified testplans.
Default: none
wait xmap_register binary_string
Indicates signal value samples to PMBIST engine control

registers. This expression causes the PMBIST engines to
suspend execution of the testplan at the current point until the
value on the xmap_register matches the binary_string.
Each xmap_register can be a scalar or a vector. Vector
notation requires the use of brackets, "[" and "]", to enclose bit
indices separated by a ":" when indicating a range of values. Bit
values in the binary_string are compared to vectored
registers left to right according to the order indicated in the
vector notation.
Default: none
wait integer This expression causes the PMBIST engines to suspend
execution of the testplan at the current point for integer
cycles. This is typically used for small delays associated with
extended function testing in user-defined algorithms or in entry
and exit routines associated with macro PMBIST execution.
The integer must not exceed the
algorithm_constraints repeat_limit value.
Default: none

algorithms { algorithm_name ... }

Defines the ordered set of algorithms to be executed within the
testplan. For each algorithm_name, the set of
data_backgrounds for each address_order for each
selection of address_updates are executed.
Default: none
onetime
Specifying onetime indicates the testplan should be
executed once only for an experiment containing a set of
devices to be tested. Its use is limited to testplans containing
only a prologue or epilogue. For such a testplan containing
only a prologue, the testplan is executed prior to any other
testplans. For such a testplan containing only an epilogue,
the testplan is executed after all other testplans.
Default: not selected
hardwired | programmed |test-access-method
hardwired causes the testplan to be implemented in the
instantiated PMBIST algorithm memory unit. It can then be
referenced by target groups and executed during PMBIST
operations without the need for a program load of the
testplan. programmed defines the testplan for reference
in target groups, but it must be loaded into the PMBIST
algorithm memory unit prior to execution. test-access-
method defines the testplan for reference in target
groups, but it must be executed by the test access method
controlling PMBIST execution, not the PMBIST logic itself.
Burn-in testing and PMBIST direct access execution generally
require hardwired testplans.
Default: programmed
Example
The march-lr and march-g algorithms are defined in a testplan that uses multiple passes
through each algorithm for the combination of address_orders (2), address_updates
(2) and data_backgrounds (4), resulting in 2x2x4=16 executions of each algorithm. These
algorithms are hardwired into the PMBIST logic along with the selected test conditions.
testplan {
name march-group

algorithms { march-lr march-g }

data_backgrounds {
rs cs cssp cscbp
}
address_updates { li ca }
address_orders { fc fr }
hardwired
}

target Group
{
target {
}
{
}
}
The target group contains a list of target specifications for PMBIST construction and insertion
that apply to the specified modules or instances.
■ If the target is a module or module list, the target specifications are applied to all
instances of the specified module(s) in the design.
■ If the target is a list of macro interface name instances, the target specifications are
applied to all listed instances of the specified macro and its associated PMBIST interface
in the design.
■ If the target is a list of instances, the target specifications are applied to that grouping.
Specifying one or more instances allows for a clear representation of the grouping of
memories for test.
■ The list of instances or modules may be freely mixed within a target group.
In a configuration file, each module or instance can appear in only one target group.
Descriptions
instance_list Specifies the names of memory instances in the design.

You must specify the full path name starting from the design’s
top level.
macro_name_list Specifies the macro interface names of target macro module
and PMBIST test interface pairs instantiated within the design.
These are indicated as macro_instance_name :
macro_interface_name or macro_module :
macro_interface_name.
module_list Specifies the names of target memory modules found within the
vendor libraries and instantiated within the design.

Specify detailed information for PMBIST construction and

insertion. Following is a list of the target specifications:
[sharing_limit_specification]
clock_specification
[location_specification]
[failure_recording_specification]
[interface_control_specification]
testplans_specification
Examples
■ In the following example, the target specifications apply to all instances of modules
RAM_2048X32 and RAM_500x11 in the design.
{
target {
RAM_2048X32
RAM_500X11
}
{
}
}
■ In the following example, the target specifications apply to the specified instances.
{
target{
/DLX/Hier_A/RAM2TEST
/DLX/RAMTEST
}
{
}
}
■ In the following example, the target specifications apply to the MP instance of mp_core
and its L1 and L2 PMBIST interfaces which have been named previously in macro
definition statements.
{
target{
MP:mp_core_L1_mbist
MP:mp_core_L2_mbist
}
{
}
}

Related Information
clock Specification on page 235
interface_control Specification on page 246
location Specification on page 237
failure_recording Specification on page 238
sharing_limit Specification on page 233
testplans Specification on page 253

sharing_limit Specification
sharing_limit integer
Specifies the number of memory instances that can share an PMBIST engine. There are no
PMBIST restrictions on which memory devices may be listed within a target group to share
any given PMBIST engine or comparator.
The primary benefit of grouping memory instances is that it enables you to share an PMBIST
engine to test the multiple memories in the group. If the specified limit is less than the total
number of memory instances, multiple PMBIST engines are created and the grouping
happens in the order that the memory instances are listed.
Description
integer Indicates the number of memory instances that can share a

PMBIST engine.
Default: 1
By default, no sharing occurs: the tool will create one PMBIST
engine for each memory in the list. These PMBIST engines will
have the same characteristics as specified in the target
specifications. No attempt is made to balance the shared load
across BIST engines; each engine is assigned its quota and the
remainder, if any, is assigned to a final BIST engine instance.
Example
In the following example, the sharing is set to 2 in the first target group. Consequently,
memory instances /DLX/Hier_a/RAM2TEST and /DLX/Hier_a/RAM3TEST will share an
PMBIST engine. As instance /DLX/RAMTEST is in a separate target group, it will have its own
PMBIST engine.
{
target {
}
{
sharing_limit 2
}
target {
/DLX/RAMTEST
}
{

}
}

clock Specification
clock mbist_clock [clock_mux]
Specifies the PMBIST clock source that drives the PMBIST logic in the target group. The
clock must have been previously defined with the define_mbist_clock command.
If multiple port memories are controlled by different clocks, the clock with the highest
frequency should be selected for PMBIST operations. Also, to enable proper PMBIST multiple
port interaction testing, clock_mux must be specified for the target group to ensure use of
this common PMBIST clock.
If clock_mux is not specified, the insert_dft pmbist command verifies the following for
the specified dft_configuration_mode during PMBIST insertion:
■ All memories in the target group share the same clock source as the mbist_clock
■ All memories in the target group use the same clock edge; if the mbist_clock edge
is different, an inverter is added into the PMBIST logic clock path to align the phase
■ All instances of a memory module when contained within a multiply used design module
must consistently use or not use clock multiplexing on their clock ports
Descriptions
clock mbist_clock Specifies the clock source for the inserted PMBIST logic.
clock_mux Selects the clock driving the PMBIST logic to be multiplexed
into the target memory clock ports if the target memory clock
ports do not have the same source as mbist_clock.
Example
■ In the following example, CLK1X is the clock used for the PMBIST engine of the three
listed memory instances. CLK1X was defined using the define_mbist_clock
command.
{
target {
/DLX/RAMTEST
}{
sharing_limit 3
clock CLK1X

}
}

location Specification
location {instance_name | module_name }
Specifies a hierarchical instance or a module in the design in which the PMBIST engines for
this target group must be inserted.
By default, the PMBIST engines are inserted in the design in which you are executing the
insert_dft pmbist command.
Note: A module_name should be used when inserting PMBIST engines into a multiply
used module within the design.
Examples
■ In the following example, the location is specified as /DLX. Because this location is the
top level of the netlist (default), its specification could be omitted.
{
target {
/DLX/RAMTEST
}
{
sharing_limit 3
location {/DLX}
clock CLK1X
}
}
■ If the following example, the location /DLX/Hier_A is the lowest common hierarchical
location that contains both memories.
{
target {
/DLX/Hier_A/Hier_A1/RAM4TEST
/DLX/Hier_A/Hier_A2/RAM5TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
clock CLK1X
}
}

failure_recording Specification
failure_recording {
[diagnostics {
{none |
no_frc |
dedicated_fdb }
[disable_2d_algorithm_recording]
}
]
[fault_tolerance {
{none |
dedicated |
shared }
[solution_groups {{ all |
{module_list | instance_list |
macro_instance_name:macro_interface_name { instance_list...}... |
macro_module:macro_interface_name { instance_list...}...
}...}}]
}
]
[redundancy_analysis {
{none |
dedicated |
shared [solution_groups {{ all |
}...}}] }
[row_first_2d | column_first_2d]
}
]
[self_repair {
{none |
soft [enable_hri] }
}
]
}
Four primary classes of patterns are generated for the PMBIST operation: production
patterns, fault tolerance patterns, redundancy patterns, diagnostic patterns. The production
patterns give a basic indication of whether a memory passed or failed the tests performed
and whether these tests completed properly. When data compare units (DCU) are shared by
multiple memories, isolation of failures is limited to the level of the DCU.
Fault tolerance patterns are essentially production patterns with fault tolerance analysis
enabled. They augment the production results with status indicating whether or not a failing
memory or solution group can tolerate a single-bit error (single-bit correctable) using its
available error correction code (ECC) capabilities while providing the initial failure indication,
memory address and data bit, and an overflow or uncorrectable error indication. Additional
hardware is required to perform the fault tolerance analysis running at PMBIST clock speeds.
Redundancy patterns are essentially production patterns with redundancy analysis enabled.
They augment the production results with status indicating whether or not a failing memory
or solution group can be repaired using its available spare resources and provide the requisite

repair solution. Additional hardware is required to perform the redundancy analysis running
at PMBIST clock speeds. More hardware is inserted if self-repair is enabled to supply the
repair solution to the memory repair interface and optionally include an interface to the hard
repair controller.
Diagnostic patterns are run on a memory when performing failure analysis and yield more
detailed failure information while requiring a runtime directly proportional to the number of
detected failures. All tests are run at PMBIST clock speeds in a style called capture-and-
rerun. This approach allows the standard production tests to run at speed while capturing a
new failure, memory row and column with associated data value read, on each pass through
the test sequence. Hardware is required to store such failure data but this approach
minimizes the cost. The no_frc option requires the least hardware investment for
diagnostics, but supports with a single pass through the diagnostic patterns isolation only to
failing memories regardless of whether the assigned DCU is dedicated or shared.
Production patterns execute at PMBIST clock speeds once only for the set of tests within the
execution scheduling unit. The following data are available in each memory PMBIST engine:
■ siudone_reg bit—indicates whether the test finished normally in this sequence iterator
unit (SIU) (=1)
■ dcufail_reg bits—indicates whether the memory currently targeted in each DCU detected
a failure (=1)
Fault tolerance and redundancy patterns execute at PMBIST clock speeds once only for the
set of tests within the execution scheduling unit. In addition to the information provided by
production patterns, the following information is made available for each DCU with spare
resources at the end of the patterns:
■ rov_reg bits—indicate whether the memory or solution group currently targeted in each
DCU has overflowed the ault tolerance/redundant capabilities of the memory, it is
uncorrectable/unreparable (=1)
■ rmfx_reg bits—indicates whether the memory currently targeted in each DCU has a
failing resource class captured in the corresponding redundancy analysis register (=1)
■ Additional bits are used to capture information necessary to indicate the logical location
of the failing resources
If the rov_reg bit is active, the memory cannot be corrected/repaired given the failures
detected and the set of ECC/spare resources available. The redundancy analysis registers
contain the partial solution calculated in this case.
If self-repair is requested, the redundancy patterns can move the redundancy analysis repair
solution to the appropriate repair interface associated with each targeted memory or memory
solution group.


methodology to capture failure data at the time an error is encountered while blocking further
failure data collection through the remainder of the test. Upon restart, blocking continues until
after the current failing read access. The number of execution loops is set as a limit at pattern
generation. In addition to the information provided by production patterns, the following data
are provided:
■ frc_reg bits—indicate the count of the read operation detecting the failure within the
PMBIST engine
■ fdb_reg bits—if enabled at insertion, for each DCU, these bits contain the encoded failing
data bit value corresponding to the failed read operation
For any pattern type, the test results are shifted off the chip to the tester. After all the fail data
are gathered, the failure data must be converted to Chip-Pad-Pattern format and analyzed.
The analysis is done with the analyze_embedded_test Modus command that reports
pass/fail and reparable indications, bitfail maps, and redundancy analysis solutions.
Descriptions
diagnostics { {none | no_frc | dedicated_fdb }

[disable_2d_algorithm_recording] }
Specifies what type of detailed failure data collection should be
inserted in the PMBIST hardware:
■ none—No detailed diagnostic capability is provided in the
PMBIST hardware.
■ no_frc—The ability to determine the failing memory for
shared DCUs is added to the hardware and pattern
generation capability.

■ dedicated_fdb—A single failing read count register per

PMBIST engine is provided with a single failing data bit
register for each DCU associated with the PMBIST engine.
Isolation of the failure includes the following information
after postprocessing by Modus’s
analyze_embedded_test command.
❑ Algorithm, sequence iterator, and test conditions active
at failure detection
❑ Any memory which failed
❑ Logical and physical address of the failing read in each
failing memory
❑ Data bit which miscompared and the value read for
each failing memory
■ disable_2d_algorithm_recording—A single failing
read count register per PMBIST engine must be large
enough to handle the largest testplan scheduled. Two-
dimensional algorithms like galloping and walking tests can
double the size of the failing read count register. This option
allows the user to reduce the size of the failing read count
register but requires avoiding execution of two-dimensional
algorithms in diagnostic patterns.
This option is only valid when dedicated_fdb is
selected.
Default: none
fault_tolerance { {none | dedicated | shared }
[solution_groups { { all |
{ module_list | instance_list |
}...} }]
}
Specifies whether to insert the hardware fault tolerance analysis
unit(s) into the design to gather the fail data on each memory or
solution group with ECC resources in the design and calculate a
repair solution, if possible. The result (pass, single-bit
correctable error, or uncorrectable error) can be scanned out of
the chip if necessary.

■ none—No fault tolerance capability is provided in the

PMBIST hardware.
■ dedicated—Fault tolerance analysis hardware is added
to each DCU that is assigned a memory or macro assigned
to a solution group.
■ shared—Fault tolerance analysis hardware is added to the
PMBIST engine and shared by all targets assigned to a
solution group.
■ solution_groups— This permits the user to select one
or more memories to be tested as a unit for fault tolerance
analysis and share a common result generated. Certain
restrictions apply to solution groups:
❑ All memories within a solution group must have the
same underlying memory module structure, varying
only in the number of data bits.
❑ Either the complete set of entries in instance_list
or module_list or macro_name_list of the
target section must be present in one or more of
these expressions, even if no spare resources exist for
some instance or module or macro, or the option all
must be specified.
Default: none
redundancy_analysis { {none | dedicated |
shared [solution_groups { { all |
{ module_list | instance_list |
}...} }]}
[row_first_2d | column_first_2d] }
Specifies whether to insert the hardware redundancy analysis
unit(s) into the design to gather the fail data on each memory
with redundant resources in the design and calculate a repair
solution, if possible. The solution can be scanned out of the chip
and converted off-chip into controls that will perform soft fixes or
fuse blowing.
■ none—No redundancy analysis capability is provided in the
PMBIST hardware.

■ dedicated—Redundancy analysis hardware is added to

each DCU that is assigned a memory with spare resources.
This option requires the specification of
interface_control outputs comparators
dedicated in the target section.
If self_repair is enabled, a repair register is allocated to
each reparable memory.
■ shared—Redundancy analysis hardware is added to the
PMBIST engine and shared by all memories with spare
resources assigned to this engine.
This option supports the specification of
interface_control outputs comparators
dedicated or shared in the target section.
If self_repair is enabled and no solution_groups
are specified, a repair register is allocated to each
reparable memory.
■ solution_groups— This permits the user to select one
or more memories to be tested as a unit for redundancy
analysis and share a common repair solution generated.
Certain restrictions apply to solution groups:
❑ All memories within a solution group must have the
same underlying memory module (Liberty file
description).
❑ Either the complete set of entries in instance_list
or module_list or macro_name_list of the
target section must be present in one or more of
these expressions, even if no spare resources exist for
some instance or module or macro, or the option all
must be specified.
Use of this option is restricted to selection of
redundancy_analysis shared. This option also
requires the specification of interface_control
outputs comparators shared in the target section.
If self_repair is enabled, a repair register is allocated to
each reparable memory solution group.

■ row_first_2d or column_first_2d—In such cases

where both spare row and spare column redundant
resources exist, these options are used to guide the
redundancy analysis in making decisions to repair rows or
columns first when detecting failures. The default value if left
unspecified and required is column_first_2d.
Default: none
self_repair { {none | soft [enable_hri]} }
Specifies whether to include built-in self-repair features in the
design.
■ none—No logic is added to the design to enable PMBIST
hardware management of the memory repair interfaces.
■ soft—Logic is added to the design to enable redundancy
analysis logic distribution of calculated repair solutions to
the specific memory repair register units based on the
requirements of the redundancy_analysis expression.
Specification of enable_hri adds hard repair interface
logic to the repair register units to enable communication
with hard repair controllers implemented externally to the
PMBIST logic.
Default: none

Examples
■ The following example specifies the collection of memory diagnostic failure information
should be included in the PMBIST features.
{
target {
}
{
sharing_limit 3
clock CLK1X
failure_recording
{
diagnostics { dedicated_fdb }
}
}
}
■ The following example requests to insert a hardware analysis unit in the design to gather
the fail data on the chip and calculate a redundancy solution, but not implement self-
repair features for this PMBIST.
{
target {
}
{
sharing_limit 3
clock CLK1X
failure_recording
{
redundancy_analysis { dedicated }
}
}
}

interface_control Specification
interface_control
{
[inputs
{
[pipeline_stages integer |
{ {integer {module_list |
instance_list}}...} ]
}]
[outputs
{
{ {integer {module_list |
instance_list}}...} ]
[comparators { [memory_local | engine_local]
[shared | dedicated] ]
[enable_group_analysis] ]
}
}]
[logic_test {none | bypass [integer ] | registered_bypass [integer ]}
]
}
Controls the features of the logic inserted around the targeted memories, the interface
between the PMBIST engine and its associated memories.This interface consists of the
multiplexers inserted on memory ports when specific test ports are not available, optional
registered pipeline stages on the signals between PMBIST logic and the memory input
signals and output signals, optional logic to test interfaces around ports of the memories, and
the comparators that verify the actual memory data read against the expected data values.
All of the memory input interface logic and any logic to test interfaces around memory ports
are placed at the same hierarchical level as each targeted memory. One comparator is
required for each targeted memory, but these comparators can be shared across several
memories with no restrictions. While sharing comparators may reduce area overhead it forces
serial testing of the associated target memories. You can control the location of the
comparators.
Descriptions
comparators { [memory_local | engine_local] [shared | dedicated]

[enable_group_analysis]}
Controls the placement of the comparators assigned to the
target memories and whether they are dedicated to each
memory.

■ memory_local —Indicates the comparators should be

inserted physically and/or hierarchically close to the
memories assigned to them.
■ engine_local —Indicates the comparators should be
inserted physically and/or hierarchically close to the
PMBIST engines connected to them.
Default: memory_local
■ shared —Causes a single comparator to be bound to each
PMBIST engine in the group with all memory instances
assigned to each PMBIST engine sharing its respective
comparator. This reduces area overhead but forces serial
test execution of the memories assigned to each of these
PMBIST engines.
■ dedicated —Indicates a unique comparator is connected
to each memory instance in the target group.
Default: dedicated
■ enable_group_analysis —Indicates for target groups
with redundancy analysis and/or fault tolerance solution
groups when the members of these groups are assigned to
the same comparator they should be analyzed in parallel.
logic_test {none|bypass [integer] |registered_bypass [integer ]}
Specifies whether to insert bypass logic as part of the target
memory collar to enable testing of logic around the memories.
This removes the sequentiality of this part of the circuit,
enabling easier testing by ATPG, while still enabling the
checking of input signals of the memory instances and the
stimulation of output signals from the memory instances. You
can specify one of the following values:
■ none—Prevents bypassing and forces the appropriate
control ports, awt[n] or be[n], if present on the memories
to be inactive for PMBIST operations and random logic
testing. Data input ports not bypassed to data output ports
are never included in the observation-only test point logic.

■ bypass [integer]—Specifies to multiplex one data

input port into each data output port to allow logic testing
around the target memory. For target memories having extra
ports for test connection purposes, any inherent logic test
bypass capability is used, forcing the appropriate control
ports, awt[n] or be[n], if present on the memories to be
inactive for PMBIST operations but active for random logic
testing.
integer indicates the number of address and control
input signals that must be exclusively OR’ed in an
observation-only register per target memory. Data input
ports not bypassed to data output ports are included in the
observation-only test point logic. A value of zero indicates
that no observation-only registers are instantiated.
Default: 4
■ registered_bypass [integer]—Forces the
appropriate control ports, awt[n] or be[n], if present on the
memories to be inactive for PMBIST operations and random
logic testing.
integer indicates the number of data, address and
control input signals that must be exclusively OR’ed into
each control and observation register per target memory.
Each control and observation register is distributed to an
equal number of data output bit multiplexers spread across
the set of memory output data buses. A value less than or
equal to zero results in an error.
Default: 4
Default for logic_test: none
pipeline_stages integer |
{{integer {module_list | instance_list}}...}
Specifies whether to add registered pipeline stages in the signal
paths from PMBIST engines to the memory inputs and
separately in the signal paths from memory outputs to the
PMBIST comparators.
■ integer —indicates the number of register stages to add
for each signal for all of the targeted memory instances. A
value of zero indicates no registers are added into the signal
path.

■ integer {module_list | instance_list}

indicates the number of register stages to add for each
signal of the instances of instance_list or
module_list. A value of zero indicates no registers are
added into the signal path. The complete set of entries in
instance_list or module_list of the target
section must be present in one or more of these
expressions, even if no pipeline stages are required for
some instance or module.
Default: pipeline_stages 0

Examples
■ The following example uses the shared option for the comparators.
{
target {
}
{
sharing_limit 3
clock CLK1X
interface_control
{
outputs {comparators {shared} }
}
}
}
■ In the following example the memory bypass is selected with an integer of 8. The data-
in to data-out is unaffected by the integer, but eight input control signals, such as
address, write, read or chip enables, or any other input but the clocks will be formed into
groups of eight and exclusively ORed down to a single observe register.
{
target {
}
{
sharing_limit 3
clock CLK1X
failure_recording
{
diagnostics yes
}
interface_control
{
outputs {comparators {shared}}
logic_test bypass 8
}
}
}
■ In the following example the memory registered bypass is selected with a default integer
value of 4. Four data, input control signals, such as address, write, read or chip enables,
or any other input but the clocks will be grouped into groups of four and exclusively ORed
down to a single observe and control register. Additionally, each of the registers will
fanout to one or more memory data output port bypass multiplexers.
{
target {
}
{

sharing_limit 3
clock CLK1X
failure_recording
{
diagnostics yes
}
interface_control
{
logic_test registered_bypass
}
}
}
■ In the following example, the pipeline stages for all the signals of both memory instances
mentioned in the target section from the memory output to its comparator are specified
with an integer of 2.
{
target {
}
{
sharing_limit 3
clock CLK1X
interface_control
{
outputs
{
pipeline_stages 2
}
}
}
}

■ In the following example, the pipeline stages for all the signals from the BIST engine to
memory are specified as 2 and 3 for memory instances /DLX/Hier_A/RAM2TEST and /
DLX/Hier_A/RAM3TEST, respectively.
{
target {
}
{
sharing_limit 3
clock CLK1X
interface_control
{
inputs
{
pipeline_stages { 2 {/DLX/Hier_A/RAM2TEST}
3 {/DLX/Hier_A/RAM3TEST}}
}
}
}
}
■ In the following example, the pipeline stages for all the signals from the BIST engine to
memory are specified as 2 for memory instance /DLX/Hier_A/RAM2TEST. Nothing has
been specified for memory instance /DLX/Hier_A/RAM3TEST. This is an error condition
because all the entries of the target section must be present in the
pipeline_stages expression.
{
target {
}
{
sharing_limit 3
clock CLK1X
interface_control
{
inputs
{
pipeline_stages { 2 {/DLX/Hier_A/RAM2TEST} }
}
}
}
}

testplans Specification
testplans {
testplan_name
[ testplan_name]...
}
Specifies the testplan_name list that executes on the active PMBIST engine(s) in this
target group. Each testplan_name previously must have been defined using a testplan
Specification on page 222.
Note: The choice of testplans selected during PMBIST operations can be changed by using
the create_embedded_test command in Modus.
Description
testplan_name Specifies the name of the testplan the PMBIST engine must
execute.
Testplans are executed in the order specified.
Example
In the following example the selected testplan is march-group.

{
target {
}
{
sharing_limit 3
clock mbist_clock_object
interface_control
{
}
testplans
{
march-group
}
}
}

ignore Group
ignore {
{module_list | instance_list}
}
Excludes the specified list of memory modules and memory instances from PMBIST
insertion.
If a target group lists a certain type or instance of a memory and the ignore group lists an
identical type or instance of a memory, an error results which must be corrected.
Example
ignore {
/DLX/Hier_B/RAM_dont_test
/DLX/Hier_A/RAM_dont_test_me_either
RAM_2000X32
}

Memory View File Syntax Summary

{
module {
liberty_module [liberty_module]...
}
{
[port_alias { base_port[.integer] aliased_port
[base_port[.integer] aliased_port]... }]
[port_action { port {0|1|U|X} [port {0|1|U|X}]... default {0|1|U|X} }]
[read_delay integer]
[data_order { {bit | bit:bit}... | {{bit | bit:bit}...}...}]
[write_mask_binding { integer { {bit | bit:bit}... }... }]
[address_partition {
[column {integer | integer : integer }...
[order [{ data { bit| bit:bit}... }] { address_list}]...]
row {integer | integer : integer }...
[order [{ bank { integer| integer:integer}... }]
[{ data { bit| bit:bit}... }]
{ address_list [: partial_address_list ] }]...
[bank {integer | integer : integer }]
}]
[wrapper wrapper_module ]
[redundancy {
{ row {integer | integer : integer }...
[bank_range {{integer |integer:integer}...}]
[enable port]
address range port {range | unused}
}]
| column [{integer | integer : integer }...]
[bank_range {{ integer| integer:integer}... }]
[enable port]
data range [port] [address range port] function
}]
} ...
}]
}
}
{
macro {
macro_list
}
{
name [macro_instance_name:]macro_interface_name
[port_access {
{ assign {port|pin} binary_string [tam] |
sample {port|pin} binary_string }...
}]
port_alias { base_port[.integer] aliased_port_or_pin
[base_port[.integer] aliased_port_or_pin]... }
[port_action { {port|pin} {0|1|U|X} [{port|pin} {0|1|U|X}]...
default {0|1|U|X} }]
[assertion_limit { { {port|pin} integer }... }]
memory_map {

[target_map {
{port|pin} [{ binary_string[ binary_string]... }] ...
} ]
[port_action {
} ]
read_delay integer [ + port_assign ]...
[request_latency integer [ + port_assign ]...]
[write_mask_binding {
} ]
segment {
[segment_map {
} ]
port_alias {
base_port[.integer] aliased_port_expression ...
}
} ...
} ...
}
}
Configuration File Syntax Summary

{
target {
{module_list | macro_name_list | instance_list }
}
{
[sharing_limit integer ]
clock mbist_clock [clock_mux]
[location {instance_name | module_name }]
[failure_recording
{
[diagnostics {
{none |
no_frc |
dedicated_fdb}
[disable_2d_algorithm_recording]
}]
[fault_tolerance {
{none |
dedicated |
shared }
[solution_groups {{ all |
}...}}]
}
]
[redundancy_analysis {
{none |

dedicated |
shared [solution_groups {{ all |
}...}}] }
[row_first_2d | column_first_2d]
}
]
[self_repair {
{none |
soft [enable_hri]}
}]
} ]
[interface_control
{
[inputs {
{{integer { module_list | macro_name_list | instance_list}}...}]
}]
[outputs {
{{integer { module_list | macro_name_list | instance_list}}...}]
[comparators { [memory_local | engine_local]
[shared | dedicated]
[enable_group_analysis] ]
}]
[logic_test {none|bypass [integer ]|registered_bypass [integer ]}]
}]
} ]
testplans { testplan_name [testplan_name ]... }
}
}
{
ignore {
{module_list | macro_name_list | instance_list }
}
}
[algorithm_limit integer]
[access_limit integer]
[repeat_limit integer]
[log2b_limit integer]
[pause_duration integer {ms|us}]
[macro_support {no | yes}]
[simple_instructions_only {no | yes}]
[cell_test_support {no | yes}]
[address_orders {
[ no-update | nu ]
[ fast-row | fr ]
} ]
[address_updates {
[ linear | li ]
[ complement | ca ]
[ twos-power | 2i ]
[ worstcase | wc ]
[ shifted | s1 ]

} ]
[data_backgrounds {
[ solid | s ]
[ row-stripe | rs ]
[ log2b]
} ]
}
algorithm {
name algorithm_name
{
{wait integer |
pause |
address_direction (sequence_iterator) }...
}
}
testplan {
name testplan_name
[address_orders {
[ no-update | nu ]
[ fast-row | fr ]
} ]
[address_updates {
[ linear | li ]
[ complement | ca ]
[ twos-power | 2i ]
[ worstcase | wc ]
[ shifted | s1 ]
} ]
[data_backgrounds {
[ solid | s ]
[ row-stripe | rs ]
[ log2b]
} ]
[data_orientation { word | cell }]
[prologue {
wait integer }...
} ]
[algorithms {
algorithm_name ...
} ]
[epilogue {
wait integer }...

} ]
[onetime]
[hardwired | programmed | test-access-method]
}


Index
C
commands
add_pmbist 39
configuration file for MBIST insertion
intrinsic read 161
constraints
define_jtag_instruction 39
define_jtag_instruction_register 28, 33,
39
customer service, contacting 16
F
flows
test with MBIST insertion 30, 36
test with MBIST insertion, preview 26
H
help, accessing 14
M
macro Group 193
MBIST logic insertion
configuration file 20
interpreting reports 43
U
using Modus
online help 14


Modus Ug Pmbist

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modus Ug Pmbist

Uploaded by

Copyright:

Available Formats

Modus: Guide 8: PMBIST

Product Version 18.11

August 2018 3 Product Version 18.11

August 2018 4 Product Version 18.11

August 2018 5 Product Version 18.11

module Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

August 2018 6 Product Version 18.11

August 2018 7 Product Version 18.11

Figure 5-14 Write Operation Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

August 2018 8 Product Version 18.11

August 2018 9 Product Version 18.11

August 2018 10 Product Version 18.11

Example 2-1 ROM file containing binary data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

August 2018 11 Product Version 18.11

August 2018 12 Product Version 18.11

About This Manual

Typographic and Syntax Conventions

August 2018 13 Product Version 18.11

Modus Documentation Roadmap

Getting Help for Modus and Diagnostics

August 2018 14 Product Version 18.11

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

Extended Command and Message Help

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

August 2018 15 Product Version 18.11

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

will display the purpose of the command.

Contacting Customer Service

August 2018 16 Product Version 18.11

Contact IBM EDA Customer Services at 1-802-769-6753, FAX 1-802-769-7226. From

Modus and Diagnostics Tutorials

August 2018 17 Product Version 18.11

August 2018 18 Product Version 18.11

■ Inserting PMBIST on page 20

August 2018 19 Product Version 18.11

Prerequisite PMBIST Files

PMBIST interface files are generated by write_dft_pmbist_interface_files

Genus Synthesis Solution Prerequisites

August 2018 20 Product Version 18.11

Table 1-1 JTAG Instructions and Registers to Access PMBIST Logic

Instruction Test Data Register

August 2018 21 Product Version 18.11

Instruction Test Data Register

You can insert the JTAG macro using either the

Use the -dont_create_pmbist_ports option of the add_pmbist command to indicate

August 2018 22 Product Version 18.11

August 2018 23 Product Version 18.11

Table 1-2 PMBIST Flow Options at Insertion

dont_create_pmbist connect_to_j direct_access_o

no no no block level processing create PMBIST

Using the PMBIST Bottom-Up Flow

August 2018 24 Product Version 18.11

excluding insertion of boundary-scan or JTAG_Macro logic. The

b. From the Resources menu select Rapid Adoption Kits

c. Select Synthesis, Test and Verification flow

d. Download Modus and Genus Synthesis Solution: Programmable Memory

August 2018 25 Product Version 18.11

PMBIST Preview Flow

Figure 1-1 PMBIST Preview Flow

Define test related control signals

Define MBIST clocks

Update view file if necessary

Read PMBIST memory view