0% found this document useful (0 votes)

35 views343 pages

Modus Ug Pmbist

The document is the Modus Guide 8: PMBIST, detailing the PMBIST architecture, its features, and usage instructions for the Cadence Modus tool. It includes sections on memory repair support, fault tolerance, and design flow considerations, as well as guidelines for inserting programmable MBIST logic. The guide serves as a comprehensive resource for users looking to implement PMBIST in their designs.

Uploaded by

Rathnambiga Unnikrishnan

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

35 views343 pages

Modus Ug Pmbist

Uploaded by

Rathnambiga Unnikrishnan

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 343

Modus: Guide 8: PMBIST

Product Version 21.11

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

Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

List of Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Modus Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Getting Help for Modus and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Extended Command and Message Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contacting Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Modus and Diagnostics Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Modus Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
What We Changed for This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
21.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
21.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
PMBIST Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Memory Repair Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Fault Tolerance Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Power Domain Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

February 2022 3 Product Version 21.11

Library Domain Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

MMMC Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
PMBIST Access Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Supported Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Planning for MBIST Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Check Quality of Vendor Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CTL Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Use PMBIST in Preview Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Multiple Power Domain Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Multiple Library Domain Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
RTL or Gate-Level Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
MBIST Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2
Inserting Programmable MBIST Logic . . . . . . . . . . . . . . . . . . . . . . . . . 39
Inserting PMBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Prerequisite PMBIST Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Genus Synthesis Solution Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
PMBIST Interface Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
PMBIST Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3
PMBIST Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
PMBIST Operational Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Pattern Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Testplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
PMBIST Program Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Single Pattern Class Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Design Flow into Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Limitations for RTL Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

February 2022 4 Product Version 21.11

Tester Description Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Create Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Pattern Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
CET Custom Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Custom Scheduling Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Setup for Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Loading PCF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Selecting Keys for Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Filtering Selected Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Scheduling Selected Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Creating Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Building the Test Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Setup for programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Creating Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Creating Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Write Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Pattern Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Direct Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
1149 TAP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Design Verification Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Pattern Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
1149 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Manufacturing Test Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Pattern-related Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

4
Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
How PMBIST Affects Static Timing in a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
PMBIST Module-level Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Design Timing with PMBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

February 2022 5 Product Version 21.11

5
Boolean Equivalence Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Chip Level Insertion Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Multiple Block Merging Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6
Design Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Getting to Modus PMBIST Pattern Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Simulation Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
PMBIST Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
ROM Data Load Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Design and Technology Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Analyzing Pattern Class Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
irun to analyze_embedded_test Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
irun to CPP to analyze_embedded_test Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Special Handling of Four pin TAP controller in Simulation . . . . . . . . . . . . . . . . . . . . 164
Injecting Memory Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Changes in the Verilog Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Fault Injection Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Understanding analyze_embedded_test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Executing the Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Working with Simulation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Working with CPP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Analyzing and Debugging PMBIST Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . 178
Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
PMBIST Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Memory Connections and Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
PMBIST Comparators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Determining Miscomparing Registers from Simulation Logs . . . . . . . . . . . . . . . . . . 205

February 2022 6 Product Version 21.11

A
Customizing PMBIST Memory View and Configuration Files .
209
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Memory View File Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Configuration File Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
module Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
port_alias Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
port_action Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
address_limit Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
read_delay Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
data_order Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
write_mask_binding Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
address_partition Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
wrapper Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
redundancy Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
macro Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
name Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
port_access Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
port_alias Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
port_action Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
assertion_limit Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
memory_map Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
algorithm_constraints Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
algorithm Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
testplan Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
sharing_limit Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
clock Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
location Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
failure_recording Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
interface_control Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
testplans Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

February 2022 7 Product Version 21.11

ignore Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Memory View File Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Configuration File Syntax Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

B
PMBIST using Core Test Language (CTL) Memory Models . .
327
CTL Memory Model Skeleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Sample CTL Memory Model File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

C
Glossary of PMBIST Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

February 2022 8 Product Version 21.11

List of Figures
Figure 1-1 Programmable MBIST Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 2-1 PMBIST Preview Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 2-2 PMBIST Chip-level Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 2-3 PMBIST Block Insertion Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3-1 PMBIST Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 3-2 PMBIST Pattern Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 3-3 Programmable Memory Built-In Self-Test Process Flow . . . . . . . . . . . . . . . . . 92
Figure 3-4 Custom Schedule Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 3-5 Custom Scheduling Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 3-6 Scheduler Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 3-7 Loading Design Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Figure 3-8 Selecting Keys for Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 3-9 Filter Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Figure 3-10 Select values for expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Figure 3-11 A sample query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 3-12 Preview sample query for filtering targets . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 3-13 Schedule Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Figure 3-14 Warning of Scheduling Constraint Violation. . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 3-15 Creating Test Program Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Figure 3-16 Creating Test Program Flow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure 3-17 Test-Programming Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure 3-18 Setup for Programming tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 3-19 Experiment Creation tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 3-20 Test-Programming creation tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Figure 3-21 1149 TAP Access Production Pattern Abstract View . . . . . . . . . . . . . . . . . . 131
Figure 3-22 1149 TAP Access ROM Production Pattern Abstract View . . . . . . . . . . . . . 132
Figure 3-23 Production Pattern Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Figure 4-1 PMBIST Timing Domain Crossings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

February 2022 9 Product Version 21.11

Figure 4-2 PMBIST Timing Cross-Domain Interference . . . . . . . . . . . . . . . . . . . . . . . . . 143

Figure 6-1 Programmable Memory Built-In Self-Test Design Verification Flows. . . . . . . 161
Figure 6-2 Verilog Memory Model Changes Supporting Fault Injection . . . . . . . . . . . . . 166
Figure 6-3 Verifying Proper seq_udp_delay Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 180
Figure 6-4 Viewing test cycle and pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 6-5 mainsim.v Header Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figure 6-6 Test Control Signal Stability Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Figure 6-7 Clock Controllability for JTAG Access Only . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Figure 6-8 Clock Controllability for Direct Access Only . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Figure 6-9 Clock Frequency Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Figure 6-10 JTAG Concerns for hardwired testplans . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figure 6-11 JTAG Concerns for programmed testplans . . . . . . . . . . . . . . . . . . . . . . . . . 191
Figure 6-12 Direct Access Concerns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 6-13 Proper Startup Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Figure 6-14 Write Operation Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Figure 6-15 Read Operation Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 6-16 Actual and Expect Data Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Figure 6-17 Done Register and Summary Failure Register Inspection . . . . . . . . . . . . . . 204
Figure 6-18 Analyzing Simulation Log Failing Registers . . . . . . . . . . . . . . . . . . . . . . . . . 207
Figure A-1 Memory with internal bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Figure A-2 read_delay 1 - asynchronous memory read timing . . . . . . . . . . . . . . . . . . . . 225
Figure A-3 read_delay 2 - synchronous memory read timing (default) . . . . . . . . . . . . . . 226
Figure A-4 read_delay 3 - memory with data output register read timing . . . . . . . . . . . . 226
Figure A-5 Linear Memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Figure A-6 Muxed Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Figure A-7 Banked Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Figure A-8 Simple Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Figure A-9 Banked row and column redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Figure A-10 Banked row and bit redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure A-11 Banked row redundancy with physical order variation. . . . . . . . . . . . . . . . . 250

February 2022 10 Product Version 21.11

List of Tables
Table 2-1 JTAG Instructions and Registers to Access PMBIST Logic . . . . . . . . . . . . . . . 41
Table 2-2 PMBIST Flow Options at Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 2-3 PMBIST attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 2-4 Genus attributes controlled during PMBIST insertion . . . . . . . . . . . . . . . . . . . . 46
Table 2-5 Genus attributes affecting PMBIST insertion . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 2-6 Memory cell/Wrapper pin usage status. [PMBIST-31] . . . . . . . . . . . . . . . . . . . 68
Table 2-7 Summary table for read_pmbist_memory_view. [PMBIST-41] . . . . . . . . . . . . . 68
Table 2-8 Summary table for algorithm constraints [PMBIST-42] . . . . . . . . . . . . . . . . . . . 70
Table 2-9 Memory Target and programmable BIST Engine Summary [PMBIST-21] . . . . 70
Table 2-10 PMBIST area overhead summary table [PMBIST-32]. . . . . . . . . . . . . . . . . . . 71
Table 2-11 PMBIST area comparison table. [PMBIST-33] . . . . . . . . . . . . . . . . . . . . . . . . 72
Table 2-12 PMBIST repair register unit status table. [PMBIST-50] . . . . . . . . . . . . . . . . . . 72
Table 2-13 PMBIST repair channel status table. [PMBIST-50] . . . . . . . . . . . . . . . . . . . . . 72
Table 2-14 Summary table of PMBIST enabled feature set [PMBIST-52] . . . . . . . . . . . . 72
Table 2-15 Summary table for add_hard_repair. [PMBIST-49] . . . . . . . . . . . . . . . . . . 73
Table 2-16 Repair Logic Summary Table [PMBIST-36] . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 2-17 Repair area comparison table. [PMBIST-37]. . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 3-1 createpatterns Option Relationship to Scheduling Options. . . . . . . . . . . . . . . 102
Table 3-2 Scheduling Option Value Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Table 3-3 Pattern Generation Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table 3-4 Pattern File Output Directory Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table 3-5 Assign File Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table 3-6 Mode Initialization Sequence Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table 3-7 Block and Chip Level Pattern Class Support . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table 3-8 Scheduling options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Table 6-1 Design Verification Pattern Class Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Table 6-2 Memory Model Fault Injection Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Table 6-3 PMBIST SRAM Failure Indication Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

February 2022 11 Product Version 21.11

Table A-1 Recognized Liberty File Base Port Names . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Table A-2 Internally Built-in Aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

February 2022 12 Product Version 21.11

List of Examples

Example 3-1 ROM file containing binary data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

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

February 2022 13 Product Version 21.11

February 2022 14 Product Version 21.11

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.

February 2022 15 Product Version 21.11

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

Commands Messages

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.

February 2022 16 Product Version 21.11

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

February 2022 17 Product Version 21.11

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
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 / command -h / command -H 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 (standard and advanced). 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 designtop} will
display the help for the designsource and cell options.
■ help_option <option_name> gives the list of commands for which the specified
option is valid along with syntax and default value.
■ <command_name> -help advanced provides help for all the advanced options of
the command.
■ For help on Perl Extension methods, use man perlext to display the list of all Perl
methods and man perlext_<method_name> to display help for a specific method.

Contacting Customer Service

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

February 2022 18 Product Version 21.11

■ 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
Contact IBM EDA Customer Services at 1-802-769-6753, FAX 1-802-769-7226. From
outside the United States call 001-1-802-769-6753, FAX 001-1-802-769-7226. The e-
mail address is [email protected].

Modus and Diagnostics Tutorials

Modus and Diagnostics tutorials are provided through Rapid Adoption Kits (RAKs) that are
available on Cadence Online Support. To access the RAKs (Rapid Adoption Kits):
1. Login to Cadence Customer Online Support (COS) site.
2. Navigate to Resources > Rapid Adoption Kits.
3. Select Modus ATPG from All Products.

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

What We Changed for This Release

21.11
There are no changes to this version of the document.

21.10
There are no significant changes to this version of document.

February 2022 19 Product Version 21.11

February 2022 20 Product Version 21.11

1
Overview

This chapter contains the following topics:

■ Introduction
■ PMBIST Architecture
❑ Memory Repair Support
❑ Fault Tolerance Support
❑ Power Domain Support
❑ Library Domain Support
❑ MMMC Support
❑ PMBIST Access Mechanisms
❑ Supported Design Flows
■ Planning for MBIST Use
❑ Check Quality of Vendor Memory Models
❑ CTL Memory Model
❑ Use PMBIST in Preview Mode
❑ Multiple Power Domain Considerations
❑ Multiple Library Domain Considerations
❑ RTL or Gate-Level Insertion
❑ MBIST Clocking

February 2022 21 Product Version 21.11

Introduction
Programmable Memory Built-In-Self-Test (PMBIST) logic is inserted into a design to apply
and observe patterns written into targeted memories and to record the ability of these
memories to accurately store and retrieve these data patterns under test conditions. The
Genus solution incorporates a fully integrated PMBIST component. Design planning prior to
insertion is critical to understand the features required of and specified to the PMBIST
application.

This manual describes the PMBIST insertion, pattern generation, verification, and debug.
Theses capability applies specifically to the PMBIST logic inserted within a design using
Design For Test in Genus. Topics range from feature selection of the PMBIST within Genus,
file transferring from Genus into Modus DFT solution, PMBIST pattern generation, structure
and export, and supporting design verification, debug, manufacturing test and Power-On Self-
Test (POST).

Some of the key features of Programmable MBIST are:

■ Unified PMBIST engine which can test multiple memory types together
■ Optimized hardware for area/timing based on target devices and selected features
■ Support for embedded SRAMs, ROMs, Register Files and unrestricted multiple ports
■ Flexible interface: JTAG and Direct access
■ Extensible set of predefined algorithms
■ Extensible set of pre-defined testplans
■ Including of hardwired algorithms during PMBIST logic insertion
■ Developing programmable algorithms and/or applying it after PMBIST logic insertion
■ Support for both gate-level and RTL insertion
■ Top-down and multi-block bottom-up flows
■ Diagnostics enablement
■ Built-in redundancy analysis
■ Built-in self repair
■ SDC generation
■ Embedded memory bus support
■ Fault tolerant memory support

February 2022 22 Product Version 21.11

PMBIST Architecture
Figure 1-1 shows the Programmable MBIST Structure:

Figure 1-1 Programmable MBIST Structure

Algorithm FUSE
Test Access Test Access
Memory Unit Control Unit
Method(s) Method(s)
(AMU) (FCU)
Other
SIU(s)

PMBIST Engine Redundancy

Sequence Iterator Analysis Unit
Unit (SIU) (RAU)

Repair Channel
Register Unit Interface Unit FUSE
(RRU) (CIU)

Comparator
Data Compare
Unit (DCU)
Memory
Functional Functional
Logic Logic

Functional logic PMBIST logic PMBIST logic based on request

February 2022 23 Product Version 21.11

The PMBIST structure of consists of the following blocks:

■ Algorithm Memory Unit (AMU) - Can be shared across multiple Sequence Iterator
Units (SIU). You can select hardwired or programmed testplan and also select Pre-
defined algorithms that include current MBIST algorithms in a testplan. User defined
algorithms can be compiled and loaded into AMU via a programmable interface. The size
of AMU can be adjusted during compile time. It is to be noted that inclusion of user
defined/programmable algorithms affects AMU size.
■ Sequence Iterator Unit (SIU) - Can be shared across different types of memories. It
contains a single sequence iterator shift register and control logic necessary to execute
the commands in the sequence iterator once initiated. This is used to
❑ Insert logic for a configurable and optimized address generation
❑ Control signal interface and data background generation. Data Compare Unit (DCU)
■ Data Compare Unit (DCU) - It determines failures by comparing data read from
memory with expected values from the algorithm. Signal from the comparator indicates
that a miscompare has occurred. The DCU supports multiple read port memories.
■ Redundancy/Fault Tolerance Analysis Unit (RAU) - Can be shared by the set of
DCUs within an SIU or dedicated per DCU.
■ Repair Register Unit (RRU) - It is assigned to each repairable memory or solution
group
❑ Convert the logical repair solution to physical repair solution based on the
redundancy specification of the target memory.
❑ When hard repair is requested, it providers a hard repair interface to allow FCU/CIU
to access the repair channels.
■ Fuse Control Unit (FCU)
❑ The programmable unit to allow user select programmable or hardwired testplan to
control the access to the channels and NVM.
■ Channel Interface Unit (CIU)
❑ Interface macro between Fuses and RRU

Looking at the PMBIST structure diagram, the AMU is the interface. Not only because the
access methods connect to the AMU from a design structure point of view, but also it enables
the programming of PMBIST TDRs from an architecture point of view. The test access
interface on AMU can be viewed as a scan interface in the context of IEEE 1687. It enables
other custom macros to control the PMBIST. Potentially, it can communicate with other control
protocols through adapters. AMU can be shared across multiple SIUs which enables the

February 2022 24 Product Version 21.11

sharing of the stored testplans, algorithms, address_updates, address_orders, and data

backgrounds.

As the name indicated, SIUs generate the test sequences based on the select testplan and
apply the test sequences to the target memories. SIU also connects to a corresponding DCU
to collect any failure information. In the case of RAMs, the DCU compares the data read from
the memory against the expected data from SIU. For ROMs, a signature will be cumulated
during the test and check against the expected signature.

In the case of self-repair is requested, the RAU and RRU will be added. The RAU is used to
analyze any failure during the test and dynamically calculated the repair solution. The
generated solution can be applied to the memory by RRU. When an eFUSE/an NVM is
available for BISR, an FCU can be added to store and retrieve the repair solution to and from
the NVM. The bi-directional communicates between FCU and RRU indicates that.

Memory Repair Support

Support for memory repair is limited to built-in repair analysis (BIRA). It can be accomplished
through a hardware supported option and through post-processing test results using the
analyze_embedded_test command from Modus DFT solution. Soft-repair and/or hard-
repair interface can be enabled using the add_pmbist command. The FCU is added by the
add_hard_repair command. Refer to the Genus command line options for more
information.

Redundant row, column, row and column, and data bit repair mechanisms are supported
based on the MBIST logic options chosen at the time of insertion. Refer to redundancy
Specification in Appendix A, “Customizing PMBIST Memory View and Configuration Files” for
more information.

Fault Tolerance Support

When tolerating memory failures is necessary, the fault tolerance support allows
accumulation of the failure(s) within a logical memory or a solution group and reports
correctable failure (1 error per logical memory) or uncorrectable ones (>= 2 errors per logical
memory) with overflow indications.

Fault tolerance support is limited to two options. Option one allows only 1 error per logical
memory. Option two allows only 1 error per data splitting group. The user can specify solution
groups in the fault tolerance section as part of the configuration file.

February 2022 25 Product Version 21.11

Power Domain Support

No implicit support exists within the PMBIST application to identify the memories according
to power domain. However, the support for multiple instruction sets within the JTAG access
method allows for user-defined power domain awareness. You can assign a different PMBIST
instruction set to the memories of each power domain using a bottom-up flow. This allows you
to execute the PMBIST instructions only when that power domain is active.

Library Domain Support

The PMBIST application can identify and test the memories according to library domain.
Memories from the same as well as different library domains can be controlled with the same
PMBIST engine.

MMMC Support
PMBIST does support synthesis using Multi-Mode, Multi-Corner (MMMC) timing constraints.
When executing the add_pmbist and add_hard_repair commands, PMBIST checks for
analysis views associated with MMMC to determine if synthesis constraints for the parent
design were previously defined for Multi-Mode, Multi-Corner synthesis using the read_mmmc
command. For more details, reference to the MMMC in STA section.

PMBIST Access Mechanisms

The PMBIST logic can be accessed via the JTAG macro (which can be inserted without
boundary scan) and by direct pin or port control.

Both JTAG method and direct access method allow for some level of scheduling and
algorithm selection through program load and acquisition of diagnostic failure data. Any
shared resource during insertion might limited the scheduling during pattern generation.
Basically, it is a trade-off between area and test runtime.

Supported Design Flows

PMBIST can be inserted at the RTL level and the gate-level within the Genus solution. The
PMBIST application supports the following design flows:
■ Top-down flow
PMBIST can be inserted in the entire design at one point in time.

February 2022 26 Product Version 21.11

Prerequisite steps include defining the controlling test signal for PMBIST use, the MBIST
clocks, any PMBIST required JTAG instructions and control ports, and any utilized direct
access controls. The JTAG module can be inserted prior to or following the PMBIST
insertion.
■ Bottom-up flow
PMBIST can be inserted into portions of the final design incrementally using block-level
insertion. PMBIST insertion is performed in a design that is later instantiated one or more
times in an encompassing design. This can be performed repetitively as the design
hierarchy grows.
Prerequisite steps include defining the controlling test signal for PMBIST use, the MBIST
clocks, any PMBIST required JTAG instructions, and any utilized direct access controls.
Access mechanisms desired at the top level must be included in the block-level insertion
steps as well.

February 2022 27 Product Version 21.11

Planning for MBIST Use

To reduce the time needed to successfully perform PMBIST insertion and get the necessary
data at manufacturing test, it is recommended that you do some planning before you attempt
to insert PMBIST in the design. Consider the following steps:
■ Check Quality of Vendor Memory Models
■ Use PMBIST Insertion in Preview Mode
■ Design Flow Considerations

Check Quality of Vendor Memory Models

The Liberty files loaded in Genus solution are one possible source of information describing
the ports on the memories to the PMBIST application. The PMBIST application expects
certain constructs within the Liberty file memory descriptions to process them properly.
■ You can verify this information manually. Refer to Memory Built-In-Self-Test Liberty File
Requirements in Library Guide for Genus for details.
■ Alternatively, you can rely on the PMBIST application to iteratively verify the contents of
the Liberty files by using the add_pmbist command in preview mode (-preview).

The Cadence memory views are the primary source of information describing the ports and
other related information of the memories to the PMBIST application. The Cadence memory
views can be defined at multiple levels:
■ Memory Module
❑ Liberty file representation of a memory
❑ Identifies memory blocks and provides external connections with port bindings
■ Memory Wrapper or memory module wrapper
❑ Design module encapsulating the memory module and requiring the definition of all
memory ports
■ Logical Wrapper or logical memory wrapper
❑ One-to-one relationship between memory module and logical wrapper boundary
❑ Design module encapsulating the memory module or memory wrapper with
additional discrete logic, permitting the implementation of functions such as ECC
and repair outside the memory module itself but within the targeted device

February 2022 28 Product Version 21.11

■ Multi-view Memory
❑ Logical wrapper which supports two distinct views of the encapsulated memory
❍ First view is the boundary of memory module or memory wrapper
❍ Second view is the boundary of the logical wrapper
❍ pmbist_enable_multiple_views root attribute
■ Macro View
❑ Test memories through the defined embedded memory bus
❑ Manage static and dynamic control signals
❑ Support multi-cycle access and controlled programmable pipeline
❑ Comprised of one or more physical memories not necessarily the same size in both
dimensions

CTL Memory Model

CTL memory model provides an alternate way to describe test-related aspects of the
embedded memory and allows for interoperability between the producer and the consumers.
The user has the choice of importing the memory model from the memory provider. The
imported CTL model can be converted to Cadence memory view if desired. For more details,
refer to Appendix B, “PMBIST using Core Test Language (CTL) Memory Models”.

Memory core test language (memory CTL, or IEEE Std 1450.6.2™-2014) is an extension of
the core test language (CTL, or IEEE Std 1450.6™-2005) that allows the description of the
test-related aspects of memory blocks. For more information refer to IEEE 1450.6.2
standards.

Use PMBIST in Preview Mode

To create a memory view template, the user can run the read_pmbist_memory_view
command with -preview option. The generated memory view template will be stored in the
specified directory. The generated memory view template will include all the recognized
memories in the design. The port information will be extracted from the corresponding liberty
library file. For more details, refer to the PMBIST preview flow in the insertion chapter.

To create a configuration file template without performing insertion, the user can run the
PMBIST insertion in preview mode using the -preview option along with the -directory

February 2022 29 Product Version 21.11

option. The template file can be used to review configuration file content or as a basis to
further edit content.
add_pmbist -preview -directory ...

Multiple Power Domain Considerations

Currently, the PMBIST application cannot support this feature automatically. You should
consider inserting PMBIST in the design modules associated with these different domains
individually if you want to execute PMBIST based on active power domains. You must be
careful to ensure that the PMBIST access mechanism is active in all such operational modes.

Multiple Library Domain Considerations

When using multiple library domains, any logic that gets inserted by the application is mapped
to the library domain of its containing module. An PMBIST engine can be shared with the
memories from the same or multiple library domains if they belong to same memory type. You
can control this sharing by the mbist_enable_shared_library_domain_set design
attribute. You must be careful to insert proper level shifters for the logic that crosses library
domain boundaries after MBIST insertion.

RTL or Gate-Level Insertion

Genus supports both RTL and gate-level PMBIST insertion. The RTL insertion flow has some
limitations. For more information, refer to “Limitations for RTL Insertion Flow” on page 93. You
can consider the RTL flow for early verification as Verilog test benches can be generated
using the write_dft_pmbist_testbench command after PMBIST insertion.

MBIST Clocking
The following scenarios illustrate different MBIST clock sources, clock hookup points, and
insertion flows. The proper definition of the clocks enables improved MBIST access checks
and flexible pattern grouping at the tester.
■ External Clock Sources, Chip- or Block-Level Insertion, Pulsed Tester Clocks

February 2022 30 Product Version 21.11

In the scenario below, a single chip or block level port is used to feed two logic domains: one
running at 100MHz and the second running at 200MHz after a PLL is used to multiply the
clock frequency. The third domain is clocked by a second chip or block level port running at
333MHz.

sysclk_1 Y domain 1
[100Mhz] g1

pll_in pllclk_1
ref_port1 PLL domain 2
pll_1 [200Mhz]
ref_port2

sysclk_2 Y domain 3
[333Mhz] g2

The following commands define the clocks to PMBIST:

define_mbist_clock \
-name mbist_clk100 \
-period 10000 \
sysclk_1
define_mbist_clock \
-name mbist_clk200 \
-period 10000 \
-hookup_pin pll_1/pllclk_1 \
-hookup_period 5000 \
sysclk_1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
sysclk_2

To enable clock source checking through the PLL blackbox (indicated by the dashed arc
between the pins), set the following attribute:
set_db pll_1/pllclk_1 .dft_controllable "pll_1/pll_in non_inverting"

■ External Clock Sources, Chip-Level Insertion, Free-running Tester Clocks

February 2022 31 Product Version 21.11

Assuming that the sysclk_1 and sysclk_2 clocks in the previous scenario are connected
to free-running clock generators at the tester, two options are possible when performing
PMBIST insertion.
1. The clocks are treated independently which subsequently forces PMBIST test patterns
to be generated for each clock independently:
define_mbist_clock \
-name mbist_clk100 \
-period 10000 \
-internal_clock_source \
-hookup_pin g1/Y \
ref_port1
define_mbist_clock \
-name mbist_clk200 \
-period 10000 \
-internal_clock_source \
-hookup_pin pll_1/pllclk_1 \
-hookup_period 5000 \
ref_port1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
-internal_clock_source \
-hookup_pin g2/Y \
ref_port2
set_db pll_1/pllclk_1 .dft_controllable "pll_1/pll_in non_inverting"

ref_port1 and ref_port2 serve as test time control ports, described in the
define_mbist_clock command, for PMBIST pattern generation and execution, must
be tester accessible and not affect the operation of the PMBIST logic.
2. All PMBIST logic is grouped for concurrent PMBIST pattern generation and execution by
referencing a single test time control port:
define_mbist_clock \
-name mbist_clk100 \
-period 10000 \
-internal_clock_source \
-hookup_pin g1/Y \
ref_port1
define_mbist_clock \
-name mbist_clk200 \
-period 10000 \
-internal_clock_source \
-hookup_pin pll_1/pllclk_1 \
-hookup_period 5000 \
ref_port1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
-internal_clock_source \
-hookup_pin g2/Y \
ref_port1
set_db pll_1/pllclk_1 .dft_controllable "pll_1/pll_in non_inverting"

February 2022 32 Product Version 21.11

In both cases, the gates g1 and g2 must block the ability to trace the clock path to the original
source ports, sysclk_1 and sysclk_2, respectively, within the add_pmbist command
and the PMBIST DFT configuration mode. This is not usually an issue as these gates are
typically PLL blackboxes and lack of dft_controllable attributes will stop the clock
tracing at these blocks.
■ External Clock Sources, Bottom-up Insertion Flow, Pulsed Tester Clocks

In the scenario below, PMBIST insertion is done within the block1 block, and this design is
subsequently merged into the chip design where MBIST insertion is completed on the rest
of the design.

blkclk_1 domain 1
[100Mhz]

pll_in pllclk_1
PLL domain 2
pll_1 [200Mhz]

blkclk_2 domain 3
[333Mhz]
block1

sysclk_0 domain 4
[50Mhz]

pll_in pllclk_0 blkclk_1

ref_port1 PLL
pll_0 [100Mhz]
ref_port2 blkclk_2
block1
sysclk_2 domain 3
[333Mhz]
chip

February 2022 33 Product Version 21.11

The clocks for the block1 block must be defined prior to PMBIST insertion at the block level:
define_mbist_clock \
-name mbist_clk100 \
-period 10000 \
blkclk_1
define_mbist_clock \
-name mbist_clk200 \
-period 10000 \
-hookup_pin pll_1/pllclk_1 \
-hookup_period 5000 \
blkclk_1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
blkclk_2

Prior to PMBIST insertion and merging at the chip level, the clocks for chip and block1
must be defined:
define_mbist_clock \
-name mbist_clk50 \
-period 20000 \
sysclk_0
define_mbist_clock \
-name mbist_clk100 \
-period 20000 \
-hookup_pin pll_0/pllclk_0 \
-hookup_period 10000 \
sysclk_0
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
sysclk_2

To enable clock source checking through the PLL blackbox, set the following attribute:
set_db pll_0/pllclk_0 .dft_controllable "pll_0/pll_in non_inverting"

February 2022 34 Product Version 21.11

■ Internal Clock Sources, Bottom-up Insertion Flow, Free-running Design Clocks

In some cases the clock source is internal to the design, possibly driven from an analog logic
domain in the design. In the scenario below, MBIST logic is first inserted within the
digital_core block and this block is subsequently merged into the chip design where
PMBIST insertion is completed on the rest of the design.

sysclk_1 domain 1
[100Mhz]

pll_in pllclk_1
PLL domain 2
pll_1 [200Mhz]

sysclk_2 domain 3
[333Mhz]
digital_core

chip

sysclk_1
domain 1
[100Mhz]

pll_in pllclk_1
PLL domain 2
ref_port1 pll_1 [200Mhz]
ref_port2

sysclk_2
domain 3
[333Mhz]
analog_core digital_core

The clocks for the digital_core block must be defined prior to MBIST insertion at the block
level:
define_mbist_clock \
-name mbist_clk100 \
-period 10000 \
sysclk_1

February 2022 35 Product Version 21.11

define_mbist_clock \
-name mbist_clk200 \
-period 10000 \
-hookup_pin pll_1/pllclk_1 \
-hookup_period 5000 \
sysclk_1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
sysclk_2

When the sysclk_1 and sysclk_2 clocks are connected to free-running oscillators in the
analog domain, you have two options for performing PMBIST insertion at the chip level.
1. The clocks are treated independently which subsequently forces PMBIST test patterns
to be generated for each clock independently:
define_mbist_clock \
-name mbist_clk100 \
-period 10000 \
-internal_clock_source \
-hookup_pin digital_core/sysclk_1 \
ref_port1
define_mbist_clock \
-name mbist_clk200 \
-period 10000 -internal_clock_source \
-hookup_pin digital_core/pll_1/pllclk_1 \
-hookup_period 5000 \
ref_port1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
-internal_clock_source \
-hookup_pin digital_core/sysclk_2 \
ref_port2
set_db digital_core/pll_1/pllclk_1 .dft_controllable \
"digital_core/pll_1/pll_in non_inverting"

February 2022 36 Product Version 21.11

define_mbist_clock \
-name mbist_clk200 \
-period 10000 \
-internal_clock_source \
-hookup_pin digital_core/pll_1/pllclk_1 \
-hookup_period 5000 \
ref_port1
define_mbist_clock \
-name mbist_clk333 \
-period 3000 \
-internal_clock_source \
-hookup_pin digital_core/sysclk_2 \
ref_port1
set_db digital_core/pll_1/pllclk_1 .dft_controllable \
"digital_core/pll_1/pll_in non_inverting"

February 2022 37 Product Version 21.11

February 2022 38 Product Version 21.11

2
Inserting Programmable MBIST Logic

■ Inserting PMBIST on page 40

❑ Prerequisite PMBIST Files on page 40
❑ Genus Synthesis Solution Prerequisites on page 40
❑ Design Flows on page 44
❍ PMBIST Preview Flow on page 50
❍ PMBIST Chip-level Insertion Flow on page 54
❍ PMBIST Block Insertion Flow on page 60
❑ PMBIST Interface Files on page 66
❑ PMBIST Reports on page 68

February 2022 39 Product Version 21.11

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. When hard repair is requested, a separate configuration file is used to
control the characteristics of the PMBIST FCU (FUSE control Unit) and CIU (Channel
Interface Unit). 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.

February 2022 40 Product Version 21.11

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 2-1 on page 41. 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 2-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.

February 2022 41 Product Version 21.11

Instruction Test Data Register

Comments
(Default Name) (Default Name)
MBISTDIAG MBISTDIAG (Optional) instruction and register for PMBIST
diagnostics. Specified if diagnostics is
desired.
MBISTROMDIAG MBISTROMDIAG (Optional) instruction and register for ROM
diagnostics. Specified if ROM diagnostics is
desired.
FCUTPN FCUTPN Required instruction and register for FCU
testplan selection.
FCUSCH FCUSCH Required instruction and register for FCU
scheduling.
FCUCHK FCUCHK Required instruction and register for FCU
results checking.
FCUAMR FCUAMR (Optional) instruction and register for FCU
algorithm programming. Specified if
programmed testplan is used.
FCURR FCURR (Optional) instruction and register for repair
registers accessing.

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.

February 2022 42 Product Version 21.11

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.

February 2022 43 Product Version 21.11

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 2-2. The unlisted combinations cause an error during execution.

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

Other than the command line options, Genus attributes created for PMBIST, attributes
controlled by PMBIST, and attributes used by PMBIST can also affect the PMBIST insertion
flows. The attributes created for PMBIST are shown in the following table:

Table 2-3 PMBIST attributes

February 2022 44 Product Version 21.11

Affects
Attribute Comment
flow(s)
dft_pmbist_jtag_timing_mode_name JTAG flow SDC constraints for PMBIST
logic are added to this timing
mode for JTAG flow.
dft_pmbist_mda_timing_mode_name PMDA flow SDC constraints for PMBIST
logic are added to this timing
mode for PMDA flow.
dft_rtl_insertion RTL flow Enables RTL flow for PMBIST.
insert_pmbist_without_liberty_files All flows enables the PMBIST insertion
without memory liberty files.
mbist_enable_shared_library_domain_set All flows A way to indicate that a set of
library domains can be shared
as one domain for PMBIST
purpose.
pmbist_instruction_set Multi-block allows to bind the PMBIST
JTAG flows inserted block instance to a
particular instruction set.
Different instruction sets can be
used to bind two instances of a
same block.
pmbist_enable_multiple_views All flows Allows the logical wrapper (LW)
and memory wrapper/memory
(MW) specification of the same
memory to be tested.
pmbist_hri_async_reset All flows Specifies the pin or port to be
with used to asynchronously reset
hard-repair hard repair interface logic for
enabled PMBIST.
pmbist_use All flows Specifies how the test signal
should be used to control the
PMBIST logic during retention
test and ATPG.

To ensure a success insertion of PMBIST, the controlled attributes are shown in the following
table. If an attribute was set to an unexpected value, the tool will set the attribute to the

February 2022 45 Product Version 21.11

expected value for PMBIST insertion and restore it back to its original value when PMBIST
insertion is successfully complete.

Table 2-4 Genus attributes controlled during PMBIST insertion

Value used for

Attribute Affects flow(s)
PMBIST
bus_naming_style “%s[%d]” All flows
delete_unloaded_seqs true All flows
hdl_append_generic_ports true All flows
hdl_array_naming_style “%s[%d]” All flows
hdl_convert_onebit_vector_to_scalar false All flows
hdl_ff_keep_explicit_feedback true All flows
hdl_generate_index_style “%s[%d]” All flows
hdl_generate_separator “.” All flows
hdl_instance_array_naming_style “%s[%d]” All flows
hdl_parameterize_module_name true All flows
hdl_parameter_naming_style “_%s%d” All flows
hdl_preserve_unused_registers false All flows
hdl_reg_naming_style “%s_reg%s” All flows
lp_clock_gating_exclude true All flows(PMBIST
modules and l_rr*
flops)
lp_clock_gating_infer_enable false All flows
lp_clock_gating_test_signal

optimize_constant_0_flops true All flows

optimize_constant_1_flops true All flows
optimize_constant_latches true All flows
ovf_check_elab_consistency false All flows
ovf_mode false All flows

February 2022 46 Product Version 21.11

Value used for

Attribute Affects flow(s)
PMBIST
sdc_time_unit 1.0 SDC flow
ui_respects_preserve false All flows
ungroup_ok false All flows (Inserted
PMBIST modules)
ungroup_separator “_” All flows
uniquify_naming_style “%s_%d” All flows

Note: In the case of RTL flow, please pay extra attention to the attribute might affecting the
naming of the design. PMBIST try to control all the known attributes under the cover. As the
new attribute introduced or discovered, the list of the controlled attributes might grow.

The attributes used for PMBIST insertion are shown in the following table. In this case,
PMBIST only uses value without controlling it.

Table 2-5 Genus attributes affecting PMBIST insertion

Attribute Affects flow(s)

case_analysis_sequential_propagation Affects SDC generation for non-PMBIST
timing mode in all flows
clock_gating_integrated_cell Affects clock gate insertion in all flows
dft_apply_sdc_constraints Affects SDC generation for PMBIST logic
in all flows
dft_connect_scan_data_pins_during_mapping Affects synthesis of PMBIST logic in all
flows
dft_connect_shift_enable_during_mapping Affects synthesis of PMBIST logic in all
flows
dft_dont_scan Marks PMBIST logic as non-scannable in
all flows based on ‘dont_scan’ option.
Also marks repair registers as
non-scannable based on
‘dont_scan_repair_registers’ option

February 2022 47 Product Version 21.11

Attribute Affects flow(s)

dft_scan_map_mode Affects synthesis of PMBIST logic in all
flows
dft_scan_output_preference Affects synthesis of PMBIST logic in all
flows
dft_tap_tck_period Affects all JTAG flows
from_core_enable_active Affects checking of enable of PAD cells in
all flows
from_core_enable_pin Affects checking of enable of PAD cells in
all flows
to_core_enable_active Affects checking of enable of PAD cells in
all flows
to_core_enable_pin Affects checking of PAD cell enable in all
flows
hdl_rename_cdn_flop_pins Affects all flows
ilm_subdesigns Affects multi-block flows
liberty_attributes Affects all flows
lp_clock_gating_cell Affects clock gate insertion in all flows
lp_clock_gating_min_flops Affects all flows
lp_clock_gating_test_signal Affects all flows
lp_insert_clock_gating Affects clock gate insertion in all flows
non_dft_timing_mode_name SDC constraints are added to
non-PMBIST DFT timing mode
number_of_routing_layers Affects synthesis of PMBIST logic in all
flows

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 2-3 on page 60 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

February 2022 48 Product Version 21.11

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 50
■ PMBIST Chip-level Insertion Flow on page 54
■ PMBIST Block Insertion Flow on page 60
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)

February 2022 49 Product Version 21.11

PMBIST Preview Flow

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

February 2022 50 Product Version 21.11

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

February 2022 51 Product Version 21.11

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 2-1
on page 41) 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.

February 2022 52 Product Version 21.11

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

February 2022 53 Product Version 21.11

PMBIST Chip-level Insertion Flow

Figure 2-2 PMBIST Chip-level Insertion Flow

February 2022 54 Product Version 21.11

RTL GATE
FLOW FLOW Start
Read libraries, HDL files, SDC Task added
Set ’dft_rtl_insertion’ to true
Elaborate Optional task
Define test signals &
PMBIST configuration mode(s) PMBIST task

Define MBIST clocks

Define PMBIST access
Read memory views
Read PMBIST interface files
Run DFT rule checker
Fix DFT violations
Add testability logic
Add JTAG macro logic and/or
boundary scan logic

Add PMBIST logic

Add hard repair
Run DFT rule checker
Write DFT RTL model
-rtl option Write PMBIST interface files
-rtl option Write PMBIST testbenches
Synthesize the design
Perform ATPG analysis
LEC
and test point insertion Check
Connect scan chains
Write PMBIST interface files
Write PMBIST testbenches

February 2022 55 Product Version 21.11

PMBIST Chip-level Flow Steps

For PMBIST, the RTL flow and gate flow are the same for most of the steps. Looking at the
flow diagram, the RTL flow is indicated by the red arrows which goes through a set of steps.
On the other side, the gate flow is indicated by the black arrows.

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.

Both RTL and gate flow start with loading libraries, HDL files, and design constraints. Before
test control signals are defined, all the libraries, design files, SDC constraints are loaded, and
the design is elaborated with proper attributes.
1. (Required for RTL flow only) Set the root-level attribute dft_rtl_insertion to true
to enable the PMBIST RTL flow. Setting the attribute to true allows the tool to keep track
of the changes to the design. Later in the flow, the user-supplied RTL files will be
annotated with the RTL constructs for the inserted JTAG macro and MBIST structures
using the write_dft_rtl_model command.
set_db dft_rtl_insertion true

2. 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.
set_db <obj> .pmbist_use ...

For example:
set_db test_signal:TopBlock/test_enable .pmbist_use test_rambypass

❑ The specification of test_ramsequential serves other purposes in case of hard

repair. It is to ensure a safe state of the NVM during power-on by selecting the
functional path feeding the NVM until the PMBIST logic is reset and stabilized. It is
also used to protect the content of internal repair registers for interleaved testing by
blocking the clock.
set_db test_signal:TopBlock/test_mode .pmbist_use test_ramsequential

❑ In case hard repair is enabled, use the following attribute to specify the specific
test-control signal to asynchronously reset hard repair interface logic for
programmable MBIST.

February 2022 56 Product Version 21.11

set_db <obj> .pmbist_hri_async_reset {<port> active_high|active_low}

3. 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_test_mode ...
...
define_dft_cfg_mode -name pmbist_cfg_mode ...

4. Define the MBIST clocks prior to referencing them in the PMBIST configuration file.
define_mbist_clock -name mbist_clock ...

Refer to clock Specification inAppendix A, “Customizing PMBIST Memory View and

Configuration Files” for detailed information.
Note: If the JTAG access method has been selected, define JTAG TCK as an MBIST
clock with -is_jtag_tck option.
define_mbist_clock -name mbist_jtag_tck -is_jtag_tck ...

5. Define PMBIST access method(s).

❑ (Optional) 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 about the function of the interface pins, refer to the description
of the define_pmbist_direct_access command.
❑ Define the JTAG instruction register and PMBIST-specific instructions (see Table 2-1
on page 41) if JTAG access to PMBIST is desired.
define_jtag_instruction_register -name string ....
define_jtag_instruction -name string ...
...

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.
6. Read memory view files.
read_pmbist_memory_view -cdns_memory_view__file nput_file_name ...

February 2022 57 Product Version 21.11

Verify the memory view file, making corrections and modifications as necessary to
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).
7. (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 2-3 on page 60.

In case hard repair is enabled, the channel information is imported into the top-level
when reading the PMBIST interface files.
8. (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.
9. 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 44 for more information.

10. (Optional) Add PMBIST hard repair logic.
add_hard_repair -config_file config_file ...

February 2022 58 Product Version 21.11

For chip-level processing, either in a bottom-up flow or a top-down flow, the memory view
information of the targeting NVM should has been processed when reading the Cadence
memory view files.
When processing at the chip-level in a bottom-up flow, the processed blocks with hard
repair enabled should already have channels created and connected to the repair
interface on the block boundary. The information of the block-level channels is imported
to the top-level by reading the PMBIST interface files. The add_hard_repair command
will use the specified configuration file to create the FCU, CIU, and stitch the repair
channels, NVM, and all the building blocks together.
When processing at the chip-level in a top-down flow, the FCU, CIU, and repair channels
will be created. The tool will stitch all the building blocks together as part of the insertion.
11. Run DFT rule checker.
check_dft_rules ...

12. (Required for RTL flow only) Write DFT RTL models.
write_dft_rtl_model -directory ...

Writes out the RTL models of the design in Verilog when the DFT RTL insertion flow has
been enabled.
Note: The updated Verilog will include Hierarchical reference to indicate the updated
connection and structure. Comments will be added to indicate a change made by the
tool. For now, limit the use of RTL flow along with the hard repair feature.
13. Write PMBIST interface files and testbench to allow early verification of inserted PMBIST
logic. Full PMBIST verification is recommended to optimize the simulation runtime.
write_dft_pmbist_interface_files -directory ...
write_dft_pmbist_testbench -directory ...

In the RTL flow, an additional option, -rtl, should be used for both
write_dft_pmbist_interface_files and write_dft_pmbist_testbench commands to
generate the interface files and PMBIST testbenches.
write_dft_pmbist_interface_files -rtl -directory ...
write_dft_pmbist_testbench -rtl -directory ...

14. 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.
15. Write PMBIST interface files and the Verilog test benches and simulation scripts that
allow verification of the inserted PMBIST logic.

February 2022 59 Product Version 21.11

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.
16. 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 3, “PMBIST Pattern Generation” for more information.

PMBIST Block Insertion Flow

Figure 2-3 PMBIST Block Insertion Flow

February 2022 60 Product Version 21.11

RTL GATE Iterate insertions

FLOW FLOW Start for each block

Read libraries, HDL files, SDC Task added

Set ’dft_rtl_insertion’ to true
Elaborate Optional task

Define test related control signals

PMBIST task
Define DFT configuration
mode(s) for PMBIST
Define MBIST clocks
Define PMBIST access
Read memory view
Read PMBIST interface files
Run DFT rule checker
Fix DFT Violations
Add testability logic
Insert PMBIST block-level logic
Add hard repair
Run DFT rule checker

Write DFT RTL model

-rtl option Write PMBIST interface files

-rtl option Write PMBIST testbenches
Synthesize the design
Perform ATPG analysis and
test point insertion LEC
Check
Connect scan chains
Write PMBIST interface files
Create PMBIST testbenches

February 2022 61 Product Version 21.11

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.
1. (Required for RTL flow only) Set the root-level attribute dft_rtl_insertion to
true, to enable the PMBIST RTL flow. Setting the attribute to true allows the tool to keep
track of the changes to the design. The user-supplied RTL files will be annotated with the
RTL constructs for the inserted JTAG macro and MBIST structures using the
write_dft_rtl_model command.
set_db dft_rtl_insertion true

2. Specify the test signal(s) that control PMBIST.

❑ Define test related control signl(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.
set_db pmbist_use ...

❑ In case hard repair is enabled, use the following attribute to specify the specific
test-control signal to asynchronously reset hard repair interface logic for
programmable MBIST.
set_db <obj> .pmbist_hri_async_reset {<port> active_high|active_low}

❑ 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 utilize the following attribute and allow Genus Synthesis Solution
connecting to the test pins of clock-gating instances.
set_db lp_clock_gating_test_signal test_signal ...

3. 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_test_mode ...
...
define_dft_cfg_mode -name pmbist_configuration_mode....

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

February 2022 62 Product Version 21.11

Note: If the JTAG access method has been selected, define JTAG TCK as an MBIST
clock with -is_jtag_tck option.
define_mbist_clock -name mbist_jtag_tck -is_jtag_tck ...

5. Define PMBIST access method(s).

❑ (Optional) Define the PMBIST direct access interface pins or ports if direct access
to the PMBIST logic is desired.
define_pmbist_direct_access -function string ...

6. Read memory view.

read_pmbist_memory_view -cdns_memory_view_file config_file ...

Verify the memory view file, making corrections and modifications as necessary to
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).
7. (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.

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

9. (Optional) Add PMBIST hard repair logic.

add_hard_repair -config_file config_file ...

February 2022 63 Product Version 21.11

For block-level processing, the add_hard_repair command can be used to create the
block-level repair channels based on the specification from the configuration file.
10. Run DFT rule checker.
check_dft_rules...

11. (Required for RTL flow only) Write DFT RTL models.
write_dft_rtl_model -directory ...

Writes out the RTL models of the design in Verilog when the DFT RTL insertion flow has
been enabled.
Note: The updated Verilog will include Hierarchical reference to indicate the updated
connection and structure. Comments will be added to indicated a change made by the
tool. For now, limit the use of RTL flow with the hard repair feature.
12. Write PMBIST interface files and testbench to allow early verification of inserted PMBIST
logic. Full PMBIST verification is recommended to optimize the simulation runtime.
write_dft_pmbist_interface_files -directory ...
write_dft_pmbist_testbench -directory ...

In the RTL flow, an additional option, -rtl, should be used to for both
write_dft_pmbist_interface_files and write_dft_pmbist_testbench commands to
generate the interface files and PMBIST testbenches..
write_dft_pmbist_interface_files -rtl -directory ...
write_dft_pmbist_testbench -rtl -directory ...

13. Run DFT rule checker.

check_dft_rules...

14. 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.
15. 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.
16. Generate the Verilog test benches and simulation scripts that allow verification of the
inserted PMBIST logic.
write_dft_pmbist_testbench ...

February 2022 64 Product Version 21.11

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 3, “PMBIST Pattern Generation” for more information.

February 2022 65 Product Version 21.11

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 for inserted AMU(s).

In case hard repair is enabled, additional interface files are written to the specified directory.
The files are named as follows:
■ design_fcu_pattern_control.txt contains the block’s PMBIST external
interface and pattern generation controls derived from the configuration file.
■ design_fcutpn_tdr_map.txt identifies the FCUTPN TDR definition.

February 2022 66 Product Version 21.11

■ design_fcusch_tdr_map.txt identifies the FCUSCH TDR definition.

■ design_fcuchk_tdr_map.txt identifies the FCUCHK TDR definition.
■ design_fcurr_tdr_map.txt identifies the FCURR TDR definition.
■ design_fcu_test_def.txt contains the testplan information and calculated
algorithm constraints for inserted FCU(s).
Note: When generating interface files at the block-level with hard repair enabled, only the
design_fcurr_tdr_map.txt will be generated additionally. It contains the content of all
block-level repair channels and serves as a abstract model to migrate to the next level. When
processing the top-level, the block-information will be imported by executing the
read_dft_pmbist_interface_files command. The rest of the additional interface files will be
generated when FCU insertion is done, which most of case will be top-level processing.

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.

February 2022 67 Product Version 21.11

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 2-6 lists the report column headings and
associated data.

Table 2-6 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 2-7) 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 2-7 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}

February 2022 68 Product Version 21.11

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 2-8) by searching for the message
PMBIST-42 ID. Refer to “algorithm_constraints Specification” on page 277 in Appendix A,
“Customizing PMBIST Memory View and Configuration Files”for more details. Table 2-8 lists
the report column headings and associated data.

February 2022 69 Product Version 21.11

Table 2-8 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 2-9) by searching for
the PMBIST-21 message ID. Most categories in the report are self-explanatory. Table 2-9
lists the report column headings and associated data.

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

February 2022 70 Product Version 21.11

■ 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 2-10 and Table 2-11) 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 2-10 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 2-11 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.

February 2022 71 Product Version 21.11

Table 2-11 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

Table 2-12 PMBIST repair register unit status table. [PMBIST-50]

Programmable Repair Register Unit Status

Amu Instance Siu Instance Mbist Clock Domain Repair Register Unit Memory Instance

Instance name Instance name Defined MBIST clock Instance name of RRU Target memory
domain name

You can find the summary table for repair channel status by searching for the PMBIST-51
message ID. The table associated with the PMBIST-51 message ID reports the status of the
repair channels includes the channel number, channel length, and its corresponding RRU
instance.

Table 2-13 PMBIST repair channel status table. [PMBIST-50]

Repair channel status

Instance Name Channel Number Channel Length

Instance name of Channel Index number Length of channel in

corresponding RRU number of bits

You can find the summary table of PMBIST enabled feature set by searching for the
PMBIST-52 message ID. The table associated with the PMBIST-52 message ID reports all
the enabled features for each target instance.

Table 2-14 Summary table of PMBIST enabled feature set [PMBIST-52]

February 2022 72 Product Version 21.11

Status of PMBIST feature set available for memory devices

Instance Device Redundancy Fault

Diagnostics Repair Shadow Logic
Name Type Analysis Tolerance

Name of the {Mr, {none, {none, {none, {none, {none,

target Krw, dedicated, dedicated, no_frc, soft bypass,
memory MrNw, shared shared dedicated_fdb [enable_hir] registered_bypass
instance MrNwKrw } } } } }
}

You can find the summary table for add_hard_repair by searching for the PMBIST-49
message ID. The table associated with the PMBIST-49 message ID reports the summary of
the hard repair status.
■ Mr Memories possessing one or more read-only ports (Mr ROM).
■ Krw Memories possessing one or more ports used for reading and writing.
■ MrNw Memories possessing one or more read-only ports (Mr) and one or more
write-only ports (Nw).
■ MrNwKrw Memories possessing one or more read-only ports (Mr), and one or more
write-only ports (Nw), and one or more ports used for reading and writing (Krw).

Table 2-15 Summary table for add_hard_repair. [PMBIST-49]

Programmable hard repair status

Channel Previous Channel Instance Channel

Instance Name Status
Number Number Length Length

Channel index Instance name Previous channel Length of a Total length {checked and
number number from channel of the Merged Block,
block-level processing segment channel Repair Register
Unit,
Merged
Black-box,
Merged ILM
}

You can find the area information of the added repair logic by searching for the PMBIST-36
and PMBIST-37 message IDs. The table associated with the PMBIST-36 message ID
reports the area of the various blocks inserted by the add_hard_repair command. This

February 2022 73 Product Version 21.11

table is library domain aware. For each library domain in which PMBIST inserts repair logic,
the tool generates a table.
■ Checked and Merged Block indicates that a block with PMBIST previously inserted
was successfully merged into the design for this instance.
■ Repair Register Unit indicates the RRU inserted in current design during
add_pmbist.
■ 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.

Table 2-16 Repair Logic Summary Table [PMBIST-36]

Library domain: domain name

Module Name Module Type Number of Instances Area of All Instances Slack (ps)

module name type of module number of instances of area of instances of this Slack
this particular module particular module

The table associated with the PMBIST-37 message ID compares the design area against the
total PMBIST repair logic area inserted by the add_pmbist command. This table takes into
account the total PMBIST repair logic area of all affected library domains.

Table 2-17 Repair area comparison table. [PMBIST-37]

Design area vs Repair logic area

Initial Design Area Total Repair Logic

Total Design Area with Repair Logic
without repair Logic Area

initial design area Repair logic area Final design area with repair logic in total

February 2022 74 Product Version 21.11

3
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:

■ “PMBIST Operational Planning” on page 77
■ “PMBIST Program Creation” on page 89
■ “Design Flow into Modus” on page 91 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 95 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 97 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.
■ “CET Custom Scheduling” on page 110 describes how to use CET Scheduler, a GUI-
based utility to schedule different targets for available pattern classes and create multiple
experiments with the available pattern classes and combine them to create test-
programs and simulation script.
■ “Write Vectors” on page 128 is the command necessary to write patterns in a form usable
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.

February 2022 75 Product Version 21.11

■ “Pattern Structure” on page 130 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 133 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 134 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.

February 2022 76 Product Version 21.11

PMBIST Operational Planning

Cadence's PMBIST product, once inserted into a design, is controlled by the application of
different PMBIST programs being presented to the hardware. A PMBIST Program will be
made up of one or more PMBIST Pattern Classes. These Pattern Classes are based on a
type of operation the user may want to accomplish. Some Programs may only have one type
of Pattern Class (e.g. production) which can be applied directly to the design. Some Programs
are made up of a combination Pattern Classes (e.g. Self-Repair and Fault Tolerance), each
Pattern Class will contain one or more Experiment. Each Experiment will contain one or more
Testplan, each Testplan will include one or more Algorithm.

Figure 3-1 PMBIST Program

Programs
PMBIST programs can be developed to target the following:
■ Manufacturing Test (MFGT)
■ Power-On Self-Test (POST)
■ Mission-Mode Self-Test (MMST)

Manufacturing Test (MFGT) will have programs that are utilized during the design's
manufacturing process and targeting the Automatic Test Equipment (ATE). These are usually
geared to stress the memories in the design and assure highest product quality. This could
include the stressing of the memories with advanced testplans while analyzing the results and

February 2022 77 Product Version 21.11

calculating a repair solution. This would be a Redundancy Analysis Pattern Class, then
applying that solution to the Non-Volatile Memory (NVM) macro. This would be a Repair
Pattern class. This is the primary application of test programs.

Power-On Self-Test (POST) will have a program that has been designed to bring the
design up to an operational state when powered on. This will typically include reading of the
NVM and the propagation of that solution back to the memory repair registers and some
fundamental test experiments (if desired).

Mission-Mode Self-Test (MMST) will have a program that will step through its experiments
to assure that an accumulated quality level is met. Each experiment would need to meet the
available time windows in the functional operation of the design which allows test to occur.

Pattern Classes
The PMBIST pattern classes can be developed to target the following type of test:
■ Production
■ Redundancy Analysis
■ Fault Tolerance
■ Diagnostics
■ Repair

By default, experiments are created within Modus using the 1149_patt test mode for JTAG
access, and the mda test mode for PMDA access. The experiment name can be overridden
using the -customexperiment option. clock-source refers to a design level port name.

If MBIST clock domains are defined by using the -domain clock_domain option on the
define_dft mbist_clock command during insertion, then the clock-source mentioned
in the descriptions below is replaced with the clock_domain.

If internal clocks are used as defined by using the -internal_clock_source option on

the define_dft mbist_clock command during insertion, then clock-source is simply a
place holder for a design level port. For JTAG production and diagnostic patterns the following
rules apply:
■ The string ICS_ is added before the clock-source.
■ If the same clock-source has different periods, then _frequencyMHz is added after
clock-source.

Terms used below:

February 2022 78 Product Version 21.11

■ AMU = algorithm memory unit

■ FCU = fuse control unit
■ SIU = sequence iterator unit = MBIST engine
■ DCU = data compare unit
■ RCU = repair channel unit
■ Target = device = memory

Production

Are standard PMBIST testplan(s) with no special internal PMBIST hardwired capability
enabled, (i.e. Redundancy Analysis, Fault Tolerance Analysis, Diagnostics Analysis). They
are setup to run one or more testplans created and defined as part of the add_pmbist
command's configuration file to include one or more user defined or predefined algorithm.
These patterns are the primary memory testing vehicle for PMBIST in a design.

Production patterns are requested by specifying -createpatterns jtag_production

for JTAG and -createpatterns pmda_production or -createpatterns
pmda_burnin for PMDA patterns.

When scheduling production patterns, the following rules are enforced:

Experiment naming convention:

■ JTAG - MBIST_ATE_PROD_integer_clock-source
❑ Example: MBIST_ATE_PROD_2_ref_clka
■ JTAG (internal clock source) - MBIST_ATE_PROD_integer_ICS_clock-source
❑ integer is the step number from the first testplan, target running in the
experiment.
❑ Example: MBIST_ATE_PROD_2_ICS_ref_clka
■ JTAG (internal clock source with multiple clock-source periods) -
MBIST_ATE_PROD_integer_ICS_clock-source_frequenceyMHz

February 2022 79 Product Version 21.11

❑ Example: MBIST_ATE_PROD_2_ref_clka_100_0000MHz
■ PMDA - MBIST_ATE_DIRECTACCESS_1

Redundancy Analysis

Are the encapsulation of Production Patterns within the prologue and epilogue testplans
which enable and disable the internal failure analysis capability based on the redundancy
defined to the PMBIST application. This analysis is done with at-speed observation of failures
coming from the application of PMBIST testplans which are operating on the targeted
memory (a memory which is scheduled). The analysis will only be applied to memories which,
has redundancy capability within it and that redundancy which was defined to the application
as part of the memory model that was read into the PMBIST flow. Other memories that do not
have redundancy capability or its redundancy capability defined in its memory model will still
have the testplans selected applied to them, but they will run them as a production pattern
class, since no analysis can occur. These patterns are the building block patterns for both soft
and hard repair for PMBIST in a design.

Redundancy analysis patterns are requested by specifying -createpatterns

jtag_redundancy for JTAG and -createpatterns pmda_redundancy for PMDA.

When scheduling redundancy patterns, the following rules are enforced:

■ Shared DCU can only execute one target per time
This can be overridden by specifying enable_group_analysis in the configuration
file used by add_pmbist during insertion, and by specifying
enablegroupanalysis=yes to create_embedded_test.
■ For JTAG patterns, different clock sources cannot be grouped together
■ For PMDA patterns, different clock sources can be grouped together
■ Request latency must be the same for all targets on an engine
■ Cannot do redundancy on logical wrappers of a multiple view memory
■ Cannot have different targets on the same SIU executed together if redundancy analysis
is shared

Experiment naming convention:

■ JTAG - MBIST_ATE_JTAG_REDUNDANCY_integer1_integer2
❑ integer1 is the AMU number from the first target running in the first testplan in the
experiment.

February 2022 80 Product Version 21.11

❑ integer2 is the SIU number from the first target running in the first testplan in the
experiment.
❑ Example: MBIST_ATE_JTAG_REDUNDANCY_0_0
■ PMDA - MBIST_ATE_PMDA_REDUNDANCY_1

Fault Tolerance:

Are the encapsulation of Production Patterns within the prologue and epilogue testplans
which enables and disables the internal failure analysis capability based off the ECC word
setup in the solution group define to the PMBIST product as part of the add_pmbist
command's configuration file. This pattern class requires the targeted memories to have a
level of ECC across the logical word of the memory(s). There is no check of the logic to assure
that ECC is available but operates on the assumption that the user understands this
requirement and creates a PMBIST pattern that leverages this technology. Currently these
patterns will tolerate a single bit failure in the defined solution group. These patterns are
special patterns for designs that have ECC around their memories and have chosen this
solution over memory redundancy or conjunction with the redundancy analysis of the
memories.

Fault tolerance patterns are requested by specifying -createpatterns

jtag_faulttolerance for JTAG and -createpatterns pmda_faulttolerance for
PMDA.

When scheduling fault tolerance patterns, the following rules are enforced:
■ Shared DCU can only execute one target per time
This can be overridden by specifying enable_group_analysis in the configuration
file used by add_pmbist during insertion, and by specifying -enablegroupanalysis
yes to create_embedded_test.
■ For JTAG patterns, different clock sources cannot be grouped together
■ For PMDA patterns, different clock sources can be grouped together
■ Request latency must be the same for all targets on an engine
■ Cannot do fault tolerance on logical wrappers of a multiple view memory
■ Cannot have different targets on the same SIU executed together if fault tolerance is
shared

Experiment naming convention:

■ JTAG - MBIST_ATE_JTAG_FAULT_TOLERANCE_integer1_integer2

February 2022 81 Product Version 21.11

Diagnostics:

Are the looping execution of a Production Patterns to gather the specific failure occurrences
in the memories being targeted. Each loop of the Production Patterns captures a failure
location in the memory. The number of loops of the patterns is determine by the user
specification of the -failurelimit positive_integer option to
create_embedded_test and has no relationship to the possible number of failure that may
have occurred in the memory. These patterns are a special pattern class to characterize the
failure within the targeted memories and are not needed for repair, but when used with
analyze_embedded_test can create a failing bit map of the memory.

Diagnostic patterns are requested by specifying -createpatterns jtag_diagnostic for

JTAG and -createpatterns pmda_diagnostic for PMDA.

When scheduling diagnostic patterns, the following rules are enforced:

■ Shared DCU can only execute one target per time
■ For JTAG patterns, different clock sources cannot be grouped together
■ For PMDA patterns, different clock sources can be grouped together
■ Request latency must be the same for all targets on an engine
■ Diagnostics type must be the same for all targets
■ Read delays and fail delays must be the same for all targets
■ ROMs must have the same size (address width)

Experiment naming convention:

■ JTAG - MBIST_ATE_DIAG_clock-source_integer1_integer2
■ JTAG (internal clock source) - MBIST_ATE_DIAG_ICS_clock-
source_integer1_integer2

February 2022 82 Product Version 21.11

❑ integer1 is the AMU number from the first target running in the first testplan in the
experiment.
❑ integer2 is the SIU number from the first target running in the first testplan in the
experiment.
❑ Example: MBIST_ATE_DIAG_ICS_ref_clka_0_0
■ JTAG (internal clock source with multiple clock-source periods) -
MBIST_ATE_DIAG_ICS_clock-
source_frequenceyMHz_integer1_integer2
❑ Example: MBIST_ATE_DIAG_ICS_ref_clka_100_0000MHz_0_0
■ PMDA - MBIST_ATE_PMDA_DIAG_1

Repair:

Are patterns that are operational separate from PMBIST patterns. They focus on the access
and controlling of Non-Volatile Memory (NVM) for testing, reading and writing values and
distribution to repair channels defined and created using the add_hard_repair command
in Genus.

Repair patterns are requested by specifying -createpatterns jtag_fcurepair for

JTAG and -createpatterns pmda_fcurepair for PMDA.

When scheduling repair patterns, the following rules are enforced:

■ Shared RCU can only execute one target per time
■ For JTAG patterns, different clock sources cannot be grouped together
■ For PMDA patterns, different clock sources can be grouped together
■ Request latency must be the same for all targets on an engine

Experiment naming convention:

■ JTAG - FCU_ATE_JTAG_REPAIR_integer_integer
❑ integer1 is the FCU number from the first target running in the first testplan in the
experiment.
❑ integer2 is the SIU number from the first target running in the first testplan in the
experiment.
❑ Example: FCU_ATE_JTAG_REPAIR_0_0

February 2022 83 Product Version 21.11

■ PMDA - FCU_ATE_PMDA_REPAIR_1

Experiment
An experiment is created when running the create_embedded_test command. This
command will create a unique experiment for each pattern class specified as an option on the
command line. Within a pattern class, if the JTAG Access Method is used, it will also create
a unique experiment for each unique PMBIST clock domain which has memories targeted in
the schedule.

PMBIST experiment can have

■ Experiment_1
■ Experiment_2
■ Experiment_3 and so on

Each experiment is typically independent of other experiments created, with its own mode
initialization section to the pattern. There are cases, like memory repair, where the program
will contain multiple pattern classes and multiple experiments. In such cases, the experiments
can be dependent upon each other and are expected to run in a particular order. The user is
required to be aware of this when writing the experiments, for ATE or Verilog simulation
usage. The lead experiment is the only one that require a mode initialization sequence. If
other have one too, then the operation will not behave as expected. All experiments, but the
last experiment, will need to have the write_vector option of -finalnonscanpattern
set to no. The default is yes.

Testplan
A testplan is a wrapper around an algorithm that selects the data pattern that will be applied
to a memory's address space and how that memory space will be traversed. They also define
how the test is stored in the PMBIST logic, hardwired meaning the program of the testplan is
stored in the PMBIST logic and is executed upon selection or programmable meaning a
register to receive the program of the testplan is allocated and can be loaded via the
PMBIST's access mechanism.

Testplans are defined in the add_pmbist and/or add_hard_repair command's

configuration files depending on their target.

If the target is a memory to be tested with the PMBIST, the add_pmbist command's
configuration file will contain the user defined testplans at the bottom of that configuration file.

February 2022 84 Product Version 21.11

These testplans, by name, will be referenced in that same configuration file within the target
group section with testplan field:
{
target {
{module_list | instance_list }
}
{
sharing_limit integer
clock mbist_clock [clock_mux]

location {instance_name | module_name }

failure_recording {
[redundancy_analysis { ... }]
[self_repair { ... }]
[fault_tolerance { ... }]
}
interface_control {
inputs {}
outputs {}
}
testplans { testplan_name }
}
}

The default testplan execution order within a pattern class' experiment IS NOT the order of
the testplans referenced in the target groups testplans field, but the order of the defined
testplans at the bottom of the configuration file.

If the target is a NVM to be tested, read and written as part of PMBIST, the
add_hard_repair command's configuration file will contain the user defined testplans at
the bottom of that configuration file. These testplans, by name, will be referenced in that same
configuration file within the repair group section with testplan field:
{
repair
// NVM list
[{ { module_list | instance_list }
}]
{
[clock mbist_clock
location { instance_name | module_name }
testplans { testplan_name [testplan_name]… } ]
[channels {
{count integer [clock mbist_clock] | // channel count
length integer [clock mbist_clock ] | //register count
map { { [ rru_instance | hierarchical_instance repair_channel_index ]… |
reserved
}
}…
}
[ nvm_map { { nvm_instance [rows integer:integer] [bits integer:integer]
[copy] }…
} ]
} ]
}
}

The default testplan execution order within a pattern class experiment IS NOT the order of the
testplans referenced in the target groups testplans field, but the order of the defined testplans
at the bottom of the configuration file.

February 2022 85 Product Version 21.11

More information can be found on the target and repair group section in Chapter A,
“Customizing PMBIST Memory View and Configuration Files” of this document.

If the user does not know how best to define a testplan, examples are provided within the
Genus and Modus tools. The predefined testplans exist in the flowing files within these tools:
■ In MODUS -
@modus:root:/ 1> ls $env(Install_Dir)/defaults/mbist /*testplans.txt

■ In GENUS -
@genus:root: 1> ls $CDN_SYNTH_ROOT/share/synth/lib/vhdl/cdnpmbist/
*testplans.txt

These commands will be present the following files:

■ predefined_fcu_testplans.txt
■ predefined_testplans.txt

Within these files are example testplans that can be copied into the appropriate configuration
file. predefine_testplans.txt examples to the add_pmbist commands configuration file and
predefine_fcu_testplans.txt into the add_hard_repair configuration file. Thereafter, they
need to be reviewed for a specific application, modified and expanded upon, if necessary, to
meet the goals of that specific design.

Algorithm
An algorithm is a series of events that occur in a specific order which sets controls within the
PMBIST logic and/or on the targets interface, monitors signals, writes and/or reads a
targeting a memory's addressed location. Several predefined algorithms are available in files
located in the same directories as the predefined testplans:
■ In MODUS -
@modus:root:/ 1> ls $env(Install_Dir)/defaults/mbist /*algorithms.txt

■ In GENUS -
@genus:root: 1> ls $CDN_SYNTH_ROOT/share/synth/lib/vhdl/cdnpmbist/
*algorithms.txt

These commands are listed in the following files:

■ predefined_algorithms.txt
■ predefined_fcu_algorithms.txt

February 2022 86 Product Version 21.11

The predefined_algorithms.txt contain several algorithms defined in recent literature. The txt
file also shows how they can be referenced within a testplan. The predefined algorithms for
the PMBIST logic are:

Predefined PMBIST Algorithms

connectivity scan+ march_u walkcol
retention mats+ march_u hamr8
write_mask_test march_b march_samio hamw8
cs_test algorithm_b march_sam rom_test
sleep_test march_c- blif rom_test_hamr2
wcgd march_c+ blif+ romdiag
march_rw_s2pf- march_lr galpat rom_cs_test
march_s2pf- march_raw galrow
march_d2pf march_sr galcol
movi march_ss walk
scan march_g walkrow

The algorithms listed in the above table can be referenced directly by name within the testplan
defined in the add_pmbist configuration file. They do not need to be redefined in the
configuration file as they are already defined in the application.

A user can define their own algorithms to this list by adding them to the add_pmbist
configuration file and referencing them in their defined testplans.

The predefined_fcu_algorithms.txt contains operational algorithms for the fuse control unit
(FCU) to execute and are specific to Cadence access to a particular technology's NVM. They
are NOT accessed by reference as the wait statements will need to reflect the delays
specified in the design specific NVM datasheet. They will need to be redefined with the
designs specific timing in the add_hard_repair configuration file. The predefined
algorithms for the FCU logic are:

February 2022 87 Product Version 21.11

Predefined FCU Algorithms

read Reads a NVM word
read_and Reads NVM and compare values to the ones in the repair
compare_channel channels. Error is not the same.
read_and_compare_and_i Reads NVM and compare values to the ones in the repair
nvalidate channels. If the NVM read value is found to exist in the
repair channel, mark it as invalid in repair channel, so that
only the new repair value remains.

pgm Writes a single NVM bit

February 2022 88 Product Version 21.11

PMBIST Program Creation

Overview
PMBIST requires patterns to be created that will setup and program the PMBIST logic. These
patterns enable the PMBIST logic, selects memories to be targeted with test, selects
testplans to be applied to the memories and examines the results of these PMBIST
operations. These patterns are created within Modus directly or under the covers via Genus.

To help a user get started generating patterns for PMBIST operation and verification, there is
a methodology within Genus to write out the supporting files and scripts to create and set up
a basic validation program. This will be a starting point to expand. Here we will discuss those
elements that support PMBIST operation and verification by simulation. This methodology
starts after the insertion of the PMBIST logic within Genus.

This first starts with writing out of the design. The user has the option of inserting PMBIST in
a RTL flow or in a synthesis flow.

If a RTL flow is used, then use the Genus command: write_dft_rtl_model

If a Synthesized to gate flow is used, then use the Genus command: write_hdl

Once the design is written out of Genus, two additional commands are required to enable
pattern generation. The Genus command write_dft_pmbist_interface_files, writes
out several files that make up the abstraction of the inserted PMBIST logic in the design from
this level and below. Care should be taken with these files since they describe to the pattern
generation tool what the hardware does, if these files are altered from what the hardware
contains, then patterns can be generated that will setup the PMBIST logic incorrectly.

The other Genus command is write_dft_pmbist_testbench, which will write out a

Modus script, which will create PMBIST patterns using the options defined by the -
create_emebedded_test_option parameters set on the command line. An example of
this command within the RTL flow is as follows:
write_dft_pmbist_testbench \
-rtl \
-create_embedded_test_options "prodschedule=parallel_parallel" \
-irun_option "$vars(IRUN_OPTIONS)" \
-ncsim_library "$vars(INSTALL_DIR)/LIBS/verilog/
include_libraries_sim_pmbist.v" \
-directory $vars(_PMBIST_WORKDIR)/pmbist_tb \

Within this command's script a Modus model is built, and patterns are generated using the
create_embedded_test command, with options list added. An irun simulation script is

February 2022 89 Product Version 21.11

generated for each experiment created by create_embedded_test. The name of the

script is irun.simscript.<experiment>.

Single Pattern Class Programs

When developing patterns for PMBIST most of them are maintained within a single pattern
class, Production, Redundancy Analysis, Fault Tolerance, Repair, or Diagnostics. Each of
these pattern classes contain a single experiment. That experiment contains one or more
testplans, each containing one or more algorithms.
test_program_1 -> production-> expr_1 ->testplan_default_scan -->scan
->testplan_default_conectivity -->connectivity

This type of pattern is created in a single run of create_embedded_test. The experiment

created in Modus executes the testplans for the active memories, and can be written out of
Modus using write_vectors. This is done if the pattern is going to run by itself.

Figure 3-2 PMBIST Pattern Classes

February 2022 90 Product Version 21.11

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.

February 2022 91 Product Version 21.11

Figure 3-3 Programmable Memory Built-In Self-Test Process Flow

■ write_hdl design -abstract > design_abstract.v

February 2022 92 Product Version 21.11

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

Limitations for RTL Insertion Flow

Following is a list of known PMBIST RTL limitations:
■ No support for compressed HDL files in gzip format.
■ Avoid using positional or ordered port bindings when instantiating memory modules
(Liberty cells).
■ Avoid using unnamed primitives on connections to memories, except at the design level
where these are fully supported.
■ System Verilog
❑ Instantiating of memories within SystemVerilog interfaces

February 2022 93 Product Version 21.11

❑ PMBIST Testbench generation with SystemVerilog interfaces at block level

■ VHDL
❑ No direct VHDL insertion support
❑ Hierarchical references from Verilog module to Verilog module embedded within
VHDL are supported.
■ RTL flow restrictions:
❑ Do not use fix_dft_violations or any other command not tracking design
changes
❑ Tech libs are necessary once syn_gen or syn_map included for PMBIST logic
blocks
■ Avoid changes to default settings of some Genus attributes:
❑ hdl_generate_index_style
❑ hdl_generate_separator
■ Unsupported edit_netlist options:
❑ bitblast_all_ports, bitblast_port
❑ delete
❑ ungroup, group
❑ new_subport_bus
■ Partially supported edit_netlist options:
❑ new_primitive can be used when added at the design level
❑ connect can be used except when it references a primitive

February 2022 94 Product Version 21.11

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

February 2022 95 Product Version 21.11

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.

February 2022 96 Product Version 21.11

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 the
build_model command, the interface file set written by
write_pmbist_interface_files 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 option.

The design is identified to create_embedded_test through the -block design and -

topshell design options. 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 options.

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. If add_hard_repair has been run in Genus, there
will be an additional set of interface files that include “fcu” in the file name. 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.

You can also choose a subset of interface file wherein a subset of interface files needs to be
specified. Any files not specified will be searched for in the location specified by

February 2022 97 Product Version 21.11

interfacefiledir. This support may be helpful when using the

gui_view_pmbist_scheduler command to create a new schedule which is then written
out to a custom pattern control file. This file can then easily be specified to
create_embedded_test. Following is an example of such a usage:
create_embedded_test -interfacefiledir <intfdir> -interfacefilelist
TopBlock_pattern_control.txt_custom ….

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 -romcontentsfile
comma_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 3-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

February 2022 98 Product Version 21.11

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

February 2022 99 Product Version 21.11

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 option 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 options:
-cleanstart no -genmodeinitonly no
-jtag_modeinit 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 options 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
-pmda_modeinit 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 option supports overriding the

default BSDL package used within the Modus installation.

The option -backuppatterncontrolfile no disables the automatic backup up of the

pattern control file by the create_embedded_test command. Normally as the command
executes, it updates the pattern control file with additional information, and creates a backup
of the original version. This provides expert users an opportunity to prevent the creation of
this backup file.

February 2022 100 Product Version 21.11

The option -backuptestdeffile no disables the automatic backup up of the test

definition file by the create_embedded_test command. Normally as the command
executes, it updates the test definition file with additional information, and creates a backup
of the original version. This provides expert users an opportunity to prevent the creation of
this backup file.

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
options 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 option 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 105
■ “Mode Initialization Sequences” on page 106
■ “File System Updates” on page 108

Pattern Generation Options

These options control the class of patterns and execution schedule followed during
generation of the programmable memory built-in self-test patterns during execution of
create_embedded_test. The createpatterns option 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

February 2022 101 Product Version 21.11

selected and the production patterns allow for one of four broader engine/device schedule
values.

Table 3-1 createpatterns Option Relationship to Scheduling Options

Access Method createpatterns value corresponding *schedule

JTAG jtag_production jtag_productionschedule
jtag_diagnostic jtag_diagnosticschedule
jtag_redundancy jtag_redundancyschedule
jtag_faulttolerance jtag_faulttoleranceschedu
le
jtag_fcurepair jtag_fcurepairschedule
PMDA pmda_production pmda_productionschedule
pmda_burnin pmda_burninschedule
pmda_diagnostic pmda_diagnosticschedule
pmda_redundancy pmda_redundancyschedule
pmda_faulttolerance pmda_faulttoleranceschedu
le
pmda_fcurepair pmda_fcurepairschedule

Table 3-2 Scheduling Option Value Descriptions

*Schedule Value AMU Programmable Memory BIST execution

February 2022 102 Product Version 21.11

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.

The -customexperiment experiment_name and -customtestplans

testplan1,testplan2,... options allow the user to rename the default experiment
name and to specify which testplans will be scheduled to run. If -customexperiment is
specified, then -customtestplans must also be specified. Only one pattern type is allowed
to be specified using -createpatterns when the -customexperiment and -
customtestplans options are used.

The -testpatterndir <directory> specifies the directory to copy pattern information

to (TBDpatt files, assign files, mode initialization files and bsdl for chip level)

The following options allows the user to create STIL, WGL and TDL patterns. These options
add a write_vectors call to the script created by create_embedded_test to generate
STIL/WGL/TDL patterns.The script is automatically run if using the Genus
write_dft_pmbist_testbench command. If invoking create_embedded_test
directly, the user must execute the generated script.
Table 3-3 Pattern Generation Options
-outputstil <no | yes> Creates STIL patterns. Default is no
-outputwgl <no | yes> Creates WGL patterns. Default is no
-outputtdl <no | yes> Creates TDL patterns. Default is no

The directory where the generated patterns are to be placed can be specified by the options:
Table 3-4 Pattern File Output Directory Options
outputstildir=<path> Directory to place STIL patterns.
outputwgldir=<path> Directory to place WGL patterns.
outputtdldir=<path> Directory to place TDL patterns.

The -tdlconfigfile <input filename> specifies the file containing TDL design
configuration information. This option is used in conjunction with -outputtdl yes option.
The tdlconfigfile option is used to define the TDL design configuration information. The

February 2022 103 Product Version 21.11

file specified by <input filename> contains most of the ASIC_TITLE statement. The
required fields are "LIBRARY_TYPE", "CUSTOMER", "TI_PART_NUMBER",
"PATTERN_SET_NAME", "PATTERN_SET_TYPE", "PATTERN_SET_DESCRIPTION" and
"REVISION". All fields must be on a separate line followed by a equals sign and value.

The -updatepatterncontrolfileschedule <yes|no|copy> specifies whether the

pattern control file is automatically updated with new pattern schedule values if a pre-defined
schedule was chosen, or if fixes were required to a custom schedule. Default is yes. Use a
value of no turn off the automatic update, and use a value of copy to copy the new pattern
control file to the location specified by testpatterndir.

Assign File Options

■ -jtag_assignfile <input filename> specifies the custom assign file for JTAG
patterns
■ -pmda_assignfile <input filename> specifies the custom assign file for PMDA
patterns

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.

On-Demand Options

To support power-on self-test (POST), also known as on-demand PMBIST, new hardware is
added during the insertion phase. This new hardware, known as the application specific
sequencing unit (ASU), is added using the Genus command
add_pmbist_access_method. One of the inputs to add_pmbist_access_method is an
ASU vectors file. The ASU vectors are an optimized schedule (in terms of MBISTTPN and
MBISTSCH TDR loads), of hardwired testplans generated by create_embedded_test by
using the asu_vectors option. The ASU vectors file is named as
<design>_[fcu_]asu_vectors.txt and is located in the directory specified by the
interfacefiledir option. Following are the details of these options:
■ asu_vectors=<append | replace | none> - Generates ASU (on demand)
vectors. Default value is none. ASU vectors are stored in the interface file directory, in a
file called <design>_asu_vectors.txt (for AMU patterns) and

February 2022 104 Product Version 21.11

<design>_fcu_asu_vectors.txt (for FCU patterns). This file may or may not exist
when create_embedded_test is called.
If the file exists, specifying a value of append will cause CET to append newly generated
vectors for the pattern types requested in the file. Specifying a value of replace will
cause CET to replace vectors of the requested pattern type in the file.
If the file does not exist, either value of append or replace causes a new file to be
created. This file is then modified by the user to indicate what vectors are binded to what
mask.
■ amu_instance=<AMU instance> - Specifies an AMU instance to target for ASU
vectors. If there are multiple AMUs in the design, and ASU vectors are being generated,
an AMU instance must be specified on the command line. The
<design>_asu_vectors.txt contains vectors for only one AMU.
■ fcu_instance=<FCU instance> - Specifies an FCU instance to target for ASU
vectors. If there are multiple FCUs in the design, and ASU vectors are being generated,
an FCU instance must be specified on the command line. The
<design>_fcu_asu_vectors.txt contains vectors for only one FCU.

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 3-5 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 is set to 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

February 2022 105 Product Version 21.11

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

February 2022 106 Product Version 21.11

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

February 2022 107 Product Version 21.11

Direct Access

The direct access patterns, selected with createpatterns option set to directaccess
or createpatterns set to pmda_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/

February 2022 108 Product Version 21.11

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

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.

February 2022 109 Product Version 21.11

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

Figure 3-4 Custom Schedule Flow

Custom Scheduling Flow

Figure 3-5 shows the steps required to perform custom scheduling.

February 2022 110 Product Version 21.11

Figure 3-5 Custom Scheduling Flow Steps

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 3-6

February 2022 111 Product Version 21.11

Figure 3-6 Scheduler Main Window

The scheduler contains the following tabs:

❑ Setup for Scheduler
❑ Scheduling Keys Selection
❑ Filter
❑ Schedule

Loading PCF File

You need to provide the Input PCF (Input Pattern Control File) file that needs to be scheduled
and the corresponding Top Design name in the Setup for Scheduler tab as shown in Figure
3-7.

February 2022 112 Product Version 21.11

Figure 3-7 Loading Design Details

1. After specifying the inputs click on the Load button.

2. 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 key selection sets up the schedule’s
tab header and test grouping prioritization.The keys include
■ Testplan
■ Target num
■ Target – this is the full path of the instance
■ Target type
■ AMU num
■ AMU – this is the full path of the instance
■ SIU num
■ SIU
■ Clock
■ DCU num

February 2022 113 Product Version 21.11

■ DCU – this is the full path of the instance

■ Solution group
■ Group number
■ DA-FT-RA-SR-HR – DA=diagnostics, FT=fault tolerance, RA=redundancy, SR=soft
repair, HR=hard repair

Figure 3-8 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 Filter tab.

Filtering Selected Keys

After the scheduling keys are selected, you can filter the target details before scheduling. This
step is optional. Under the Filter tab, the keys available for making a expression is displayed.

Figure 3-9 shows the Filter tab.

February 2022 114 Product Version 21.11

Figure 3-9 Filter Tab

1. Using the Forward and Backward arrow buttons you can select the required keys for
creating the expression.
2. Use the AND / OR buttons to define AND / OR operation in between two sub-operation.
The selected keys and their values are displayed in the Expression and Define Query
Filter as shown below:

February 2022 115 Product Version 21.11

3. Define the operation between the values of the key by selecting the operator from the
Operator list. The available operators are equal and not equal.
Note: The values of the operator depends on the keys that are selected. For example,
the “Target” key has operations “with feature” and “without feature”. All keys have values
“equal” and “not equal”.
4. Click on the Value(s) Select button to select the values of the selected expressions. The
Search and Select dialog box is displayed as shown in Fig 3-10.

Figure 3-10 Select values for expressions

5. To show selected values in Choice List enter a regular expression from the available
values in the Search field. For example, entering “_base” will display the values that
match the search string in the Choice List as shown below:

The Search and Select Value dialog contains the following options:

February 2022 116 Product Version 21.11

❑ Add All - to add all values in selection list from available list
❑ Add - to add selected values in selection list from available list
❑ Remove All - to remove all values from selection list
❑ Remove - to remove selected values from selection list
6. Click OK.
Fig 3-11 shows a sample query for filtering testplan details.

Figure 3-11 A sample query

A preview of the query is displayed in the Schedule tab as shown in the following figure:

February 2022 117 Product Version 21.11

Figure 3-12 Preview sample query for filtering targets

Scheduling Selected Keys

Under the Schedule tab, the keys are displayed in the same sequence as specified under
the previous tabs. The Schedule tab allows you to schedule all the available targets for all
available pattern classes.

February 2022 118 Product Version 21.11

Figure 3-13 Schedule Tab

1. From the available access methods - 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
❍ FCU Repair
❑ MDA
❍ Direct-Access
❍ Burnin
❍ Diagnostics
❍ Redundancy

February 2022 119 Product Version 21.11

❍ Fault Tolerance
❍ FCU Repair
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. These testplan are disabled.
■ 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, or, right-click the mouse and select Update step
number.
■ To expand all/selected nodes to one level below, right-click the mouse and select
Expand - all / selected.
■ To collapse all/selected nodes to one level above, right-click the mouse and select
Collapse - all / selected.
■ To disable a target in a specific testplan from the create_embedded_test run, set the
target to Step No. “0”.

After customizing the testplans, targets as required:

1. After scheduling the keys from the input PCF file, you need to select an optimization
option to run the testplan. The options are:
❑ Allow one-time testplan to run only once in order
❑ Allow accumulation Start/End to run only once per solution group
2. Select scheduling type from Scheduling - Custom. The options are:

Table 3-8 Scheduling options

Scheduling
Description
Options
ss serial_serial

February 2022 120 Product Version 21.11

Scheduling
Description
Options
pp parallel_parallel
ps parallel_serial
pp parallel_parallel
sss serial_serial_serial
ssp serial_serial_parallel
sps serial_parallel_serial
spp serial_parallel_parallel
pss parallel_serial_serial
psp parallel_serial_parallel
pps parallel_parallel_serial
ppp parallel_parallel_parallel

You then need to validate the changes before saving the file for
create_embedded_test. To perform the same:
3. Click on the Validate button. If the modifications to the PCF file violates any scheduling
constraint, a warning message, as shown in Figure 3-14 is displayed and the changes
are corrected automatically.

Figure 3-14 Warning of Scheduling Constraint Violation

After the changes are validated the colour of the Validate button changes to green and
the Save button get enabled.
4. Save the changes to the PCF file. The available options are

February 2022 121 Product Version 21.11

❑ Overwrite file - to save changes to the PCF

❑ Create new file - to save changes to a new file
❑ Copy files to a new directory - to save the PCF file and related interface files to a
new directory
5. Click the Save button.
6. Copy the pattern types to a new group. The available groups include:
❑ Fault Tolerance
❑ Diagnostics
❑ Production
❑ Redundancy

Creating Test Programs

Figure 3-15 Creating Test Program Flow

Figure 3-16 shows the steps required to create test programs using scheduler.

February 2022 122 Product Version 21.11

Figure 3-16 Creating Test Program Flow Steps

You can create test program by selecting the Test-Programming tab from the Scheduler
Main window. The Test-Programming tab is shown in the figure 3-17:

Figure 3-17 Test-Programming Tab

February 2022 123 Product Version 21.11

The Test-Programming contains the following tabs:

❑ build_model
❑ Setup for programmimg
❑ Experiment creation
❑ Test-programming creation

Building the Test Model

The first step in creating the test programs is to build the test model. If the design detail does
not exist in the Modus session, you need to load it by running the build_model command.
This step is not required if build_model has already been executed.

To run build_model
1. In the build_model tab, click on Browse to select the design netlist.
2. Enter a design name in Top Name and click Run.
3. In case the command has been executed from the command prompt earlier, refresh the
scheduler with the details by clicking Refresh.
4. Click Next to proceed to the Setup for Programming tab.

Setup for programming

After building the test model, you need to load the interface files to the Scheduler using the
Setup for Programming tab. The tab is shown in Fig 3-18.

February 2022 124 Product Version 21.11

Figure 3-18 Setup for Programming tab

1. Use the Input interface file directory to specify the directory containing the pcf files.
Click Browse to select the directory that contains the interface files.
2. Use the Input BSDL file to specify the bsdl file. Click Browse to select the bsdl file This
is an optional step
3. Click Load to load the details to the schedule.
4. Click Next to navigate to the Experiment creation tab.

Creating Experiments
In this tab, under Experiment options you can specify details of the experiment you need to
create with the available pattern classes. The Experiment creation tab Fig is shown in 3-19.

Figure 3-19 Experiment Creation tab

February 2022 125 Product Version 21.11

1. Enter an Experiment name.

2. Specify an output directory in the Output directory text box. If the directory does not
exist, create a new one and specify the same.
3. Select the Pattern Type. You can select the pattern classes available under JTAG or
MDA.
4. Select the type of scheduling from the Scheduling list. Refer to Table 3-8 for the
scheduling options.
The testplans that are available for the selected pattern classes are displayed in
Available testplan.
5. Select the available tesplans for the given experiment by using the Forward and
Backward arrow buttons.
6. Specify the values for the following options of the create_embedded_test command:
❑ finalnonscanpatterns
❑ includemodeinit
❑ cleanstart
7. You can also specify other create_embedded_test option in
create_embedded_test options. All the options that have been specified in the above
steps are displayed in the Experiment options summary box.
8. Click Create experiment. create_embedded_test gets executed in the background.
If an experiment is created successfully then a message is displayed that indicates
successful creation of experiment and the Create experiment button changes to green,
else, a warning message will is displayed. In such a case, check the log file for more
details. The experiment name is <experiment name>_<name of the clock>.

Creating Test Program

Click on Test Programming creation to navigate to the Test Programming Test Program tab.
Use this tab to create the xrun script by specifying the sequence in which the created
experiments are to be executed. Figure 3-20 shows the Test Programming Test Program
tab.

February 2022 126 Product Version 21.11

Figure 3-20 Test-Programming creation tab

All the experiments that have been created in the previous steps are displayed in Available
experiment.
1. Use the Forward and Backward arrow buttons to select and deselect the available
experiments.
2. Use the Up and Down arrow buttons to arrange the sequence in which the experiments
are to be run.
3. Select the design by specifying the verilog file in Design File.
4. If the design contains a chipware component, specify the path of the library containing
the chipware component, e.g. /home/genus/logs/191002/tcli/lib/chipware.
5. If required, specify the path to the Simulation library.
6. Finally, specify the xrun options and click Create Test-Program to create the xrun script.
7. Specify a name to the script file in the Save File dialog and click Save. A message
showing successful file creation is displayed and the Create Test-Program button
changes to green.

February 2022 127 Product Version 21.11

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.
■ -includemodeinit yes causes the mode initialization sequence to be included in the
generated patterns. This is the default value for write_vectors. Using a value of no
may be required depending on the sequence of experiments being simulated. If multiple
experiments are being simulated, only the first experiment should include the mode
initialization sequence.
■ -includefinalnonscanpattern yes causes the final non scan pattern to be
included in the generated patterns. This is the default value for write_vectors. Using
a value of no may be required depending on the sequence of experiments being
simulated. If multiple experiments are being simulated, only the last experiment should
include the final non scan pattern.

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.

February 2022 128 Product Version 21.11

-testtimeunits ps \
-testpioffset 0 -testbidioffset 0 \
-testperiod 50000 \
-teststrobeoffset 5000 \
-testpulsewidth 25000 \
-testpioffsetlist=TCK=25000 \

February 2022 129 Product Version 21.11

Pattern Structure
Programmable memory built-in self-test patterns are comprised of a mode initialization
sequence as described in “Mode Initialization Sequences” on page 106 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 set to pmda_production or createpatterns set to pmda_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.

February 2022 130 Product Version 21.11

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

February 2022 131 Product Version 21.11

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

February 2022 132 Product Version 21.11

Design Verification Support

Pattern Simulation
Verilog testbenches can be generated by two different commands. The first way is within
Genus using the write_dft_pmbist_testbench command, this approach supplies a
very fixed testplan set and schedule. This command is typically used for a quick entry into
verification of the MBIST logic and not really used for planning test to be done for full
verification or going to the tester. The second way is within Modus using the
create_embedded_test command, or using the gui_view_pmbist_scheduler
command for a graphic planning of mbist test which can be written out using
write_vectors -language verilog. Using Xcellium's simulation logs, analysis can be done.
A verilog assertions file is supplied with the testbench do that detailed debug can be done on
the testbench if mis-compares occur.

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.

February 2022 133 Product Version 21.11

Manufacturing Test Support

A mechanism is required to correlate the patterns generated by Modus's
create_embedded_test command with the result logs generated during memory test in
manufacturing and the verification step of the MBIST operation during simulation for detailed
analysis. This analysis is done by Modus's analyze_embedded_test command.

Modus's exportation of the patterns generated by create_embedded_test can be done by

using the command write_vectors with STIL, WGL or Verilog format option. STIL and
WGL is used on the ATE where Verilog is used for simulation verification. These vectors need
to be written out with keyeddata setup for PMBIST patterns when the patterns are targeting
ATE, but this is not needed when the patterns are targeting simulation for verification.

When a simulation is complete, the Xcelium sim log can be processed directly by the
analyze_embedded_test command to determine location of injected failures.

When a failure log from ATE are provided, they first need to be converted to CPP format using
convert_failures_to_cpp command. This CPP file need to be manually updated with a
header statement and constructed from the Keyeddata and tester fail log information to build
the correlation with the pattern. Once modified, the CPP data file can then be referenced
directly by analyze_embedded_test for processing and locating error found in the
memories under test.

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.

February 2022 134 Product Version 21.11

Figure 3-23 Production Pattern Data Flow

From the above figure, Steps 1, 2 and 3 can be mapped as given below:
1. Execute the write_vectors command with the keyeddata option to write out
PMBIST patterns. For more information on keyeddata, use the command
write_vectors -help keyeddata.
To specify the PMBIST Keyeddata information to the file an additional option is needed
to identify that this information needs to be added.
2. Use the keyeddatakey option with the string, “PMBISTFailDataSync”. This will add the
needed information into the pattern.
3. If the fail data is returned from the tester, use the convert_failures_to_cpp
command to create a base CPP file.
4. Then add the Keyed Data Headers to the CPP data file.
A sample header is shown below:
Chip serialno Lot 000000104C01291-01 Wafer 23 WaferX 022 WaferY 030
Testblockname Tblknam Testcondition RSFN1 PMBISTFailDataSync "n/a modeinit
write_vectors=n/a n/a"
Chip serialno Lot 000000104C01291-01 Wafer 23 WaferX 022 WaferY 030
Testblockname Tblknam Testcondition RSFN1 PMBISTFailDataSync "AMU
pmda_faulttolerance
write_vectors_options=finalnonscanpattern=yes,includemodeinit=yes
MBIST_ATE_PMDA_FAULT_TOLERANCE_1"

a. From the failure log extract the following information and place it into

February 2022 135 Product Version 21.11

Chip serialno Lot 000000104C01291-01 Wafer 23 WaferX 022 WaferY 030

Testblockname Tblknam Testcondition RSFN1

b. From the KeyedData within the patterns complete the header field with
PMBISTFailDataSync "AMU pmda_faulttolerance
write_vectors_options=finalnonscanpattern=yes,includemodeinit=yes
MBIST_ATE_PMDA_FAULT_TOLERANCE_1"

A sample KeyedData that is to be added is shown below:

Chip serialno Lot 000000104C01291-01 Wafer 23 WaferX 022 WaferY 030
Testblockname Tblknam Testcondition RSFN1 PMBISTFailDataSync "n/a modeinit
write_vectors=n/a n/a"
Chip serialno Lot 000000104C01291-01 Wafer 23 WaferX 022 WaferY 030
Testblockname Tblknam Testcondition RSFN1 PMBISTFailDataSync "AMU
pmda_faulttolerance
write_vectors_options=finalnonscanpattern=yes,includemodeinit=yes
MBIST_ATE_PMDA_FAULT_TOLERANCE_1"
Chip serialno Pad PMDA_TDO Pattern 1.1.1.2.22.15 Position -1 EAWoffset: -1
Value 1
Chip serialno Pad PMDA_TDO Pattern 1.1.1.2.22.16 Position -1 EAWoffset: -1
Value 0
Chip serialno Pad PMDA_TDO Pattern 1.1.1.2.22.17 Position -1 EAWoffset: -1
Value 0
.....
.....

Within the CPP file, a header section is required at the beginning of each mode
initialization section and experiment. These headers will be separated by the measure
value statement that occurred in the MBIST pattern. Since the mode initialization
typically does not have measures within it's pattern section, the header for the mode
initialization is followed by the header for the first experiment within the pattern. If there
are additional mode initialization or experiments sections within the pattern, the
corresponding measure value statements will be in-between them.
In the above CPP file, two headers are added, one for the mode initialization experiment
section (which has no measures value statements) followed by another for the
experiment that follows the mode initialization sequence (which does have measure
value statements). The pattern only had one experiment beyond that mode initialization
sequence experiment.

Following is a sample AET output that shows the keyed data for the mode init and experiment
added in the CPP file. It contains:

February 2022 136 Product Version 21.11

■ Information on mode init

■ Diagnostic patterns

■ Summary Report

February 2022 137 Product Version 21.11

February 2022 138 Product Version 21.11

4
Static Timing Analysis

How PMBIST Affects Static Timing in a Design

From an operation point of view, once PMBIST is started after a proper reset, 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.

From a clock point of view, the PMBIST logic uses the test access mechanism (TAM) clock to
load and unload the PMBIST TDRs. The at-speed MBIST clocks are used to achieve at-
speed memory testing. Consider the case of self-repair, additional repair related clock(s)
might be required to access the repair channels and non-volatile memories (NVMs). All those
clocks can be asynchronous to each other.

Proper clock domain crossing between TAM clock domain (JTAG TCK or PMDA TCK) and
MBIST clock domain relies upon certain relationship. The following requirements must be
satisfied:
■ Clock period of TAM clock, either JTAG TCK or PMDA TCK should larger than or equal
to every defined MBIST clock period. In other word, the following inequalities must be
satisfied:
TAM_clock_period >= Largest_PMBIST_clock_period;

■ The mda_reset input into the PMBIST logic is a glitch-free signal.

■ The jtag_reset input into the PMBIST logic is a glitch-free signal.
■ Other static control signals are expect to be glitch-free.
■ Use of free-running clocks for TAM clock(s), either JTAG TCK or PMDA TCK, requires
proper alignment of dynamic and static tester cycles on AET.

February 2022 139 Product Version 21.11

Figure 4-1 PMBIST Timing Domain Crossings

Mode-init
Async-reset
PMBIST Gathering PMBIST
initiation Asynchronous domain results completion
crossing deglitching logic

PMBIST execution PMBIST execution

TAM clock
MBIST clock
temamu*/l_tamtapsync_reg temsiu*/l_tamchkrst_reg
temsiu*/l_tamdiagrst_reg (if diagnostics is enabled)
temsiu*/l_tamromdsync_reg[1:0] (if rom diagnostics is enabled)

temamu*/l_tapsync_reg[2:0] temsiu*/l_chkrst_reg[1:0]
or tapsynch/ffsync_reg or chkrsth/ffsync_reg
temsiu*/l_diagrst_reg[1:0] (if diagnostics is enabled)
or diagrsth/ffsync_reg
temsiu*/l_romdsync[1:0] (if rom diagnostics is enabled)
or romdsynch/ffsync_reg

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. With
the D = Q = value of reset for the flops in the target clock domain during reset removal,
the deassertion of the asynchronous reset is claimed to be safe.

The domain crossing between l_tamtapsync_reg and l_tapsync_reg[2:0] in

Figure 4-1 on page 140 occurs after this asynchronous reset within the PMBIST logic. For
JTAG-initiated operations, the control signals from a TAP are combined and latched in the
l_tamtapsync_reg register first. 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

February 2022 140 Product Version 21.11

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 between l_tamchkrst_reg and l_chkrst_reg[1:0] in Figure 4-

1 on page 140 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 between l_tamdiagrst_reg and

l_diagrst_reg[1:0] in Figure 4-1 on page 140 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 between l_tamromdsync_reg[1:0]

and l_romdsync_reg[1:0]in Figure 4-1 on page 140 occurs prior to PMBIST execution of
ROM diagnostic and captures the temamu_capture_mbistromdiag signal in
l_tamromdsync_reg[1:0] 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_tamtapsync_reg & tem_amu*/l_tapsync_reg[2:0]
■ tem_siu*/l_tamchkrst_reg & tem_siu*/l_chkrst_reg[1:0]
■ tem_siu*/l_tamdiagrst_reg & tem_siu*/l_diagrst_reg[1:0]
■ tem_siu*/l_tamromdsync_reg[1:0] & l_romdsync_reg[1:0]

During simulation, timing checks on l_tapsync_reg[2](or tapsynch/ffsync_reg),

l_chkrst_reg[1] (or chkrsth/ffsync_reg), l_diagrst_reg[1] (or diagrsth/
ffsync_reg), and l_romdsync_reg[1] (or romdsynch/ffsync_reg) 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 flow and setup. The name of the first flop of the
synchronizer has been updated in the newer version to enable the replacement of the
synchronizer flop. In case of safety critical designs, the user has the choice of replacing the
flop of the synchronizer with a metastability flop from the enhancement cell library if available.

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

February 2022 141 Product Version 21.11

multi-cycle path. For details refer to chapter “Generating SDC Constraints for DFT
Constructs” in Genus Design for Test Guide.

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.

The MMMC support for PMBIST is covered in PMBIST Multi-Mode, Multi-Corner (MMMC)
Timing Support section in Genus Design for Test Guide.

February 2022 142 Product Version 21.11

Figure 4-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
l_tamtapsync_reg
jtag_runidle
l_tapsync[2: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 fcu_clk
mbist_clk
SIU
optional clock
mda_tck l_tamromdsync_reg[1:0] mux input memory
jtag_tck functional
l_romdsync_reg[1:0] clock data
mbist_clk
functional
l_tamchkrst_reg ctl/addr/data
l_tamdiagrst_reg ctl/addr/data
l_chkrst_reg[1:0]
l_diagrst_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

February 2022 143 Product Version 21.11

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.

February 2022 144 Product Version 21.11

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

February 2022 145 Product Version 21.11

February 2022 146 Product Version 21.11

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

February 2022 147 Product Version 21.11

Gate RTL
Flow Flow

Golden RTL Design Golden RTL

RTL

Add
PMBIST
Logic
Hide Hide Hide
DFT DFT write_dft_rtl_model DFT
Structures Structures Structures
write_hdl

Revised Netlist ELAB Netlist Design + Revised Design

+ PMBIST PMBIST RTL + PMBIST RTL

Synthesize
To
Map

Revised Netlist
MAP Netlist
+ PMBIST
Golden Netlist
Connect
Scan
Chains

Revised Netlist
MAP Netlist
+ PMBIST

When running the LEC in a RTL flow, the following is recommended:

■ Before elaborating the original design, enable the LEC non-default flow by setting the
following attribute.
set_db wlec_write_lec_flow false

■ Use the following two options when executing the write_do_lec command:
-hierarchical_reference
-rtl_revised

February 2022 148 Product Version 21.11

Note: If the user passes -rtl_revised option, then there is no need to specify the
-revised option to include the files generated by the write_dft_rtl_model
command. If the user choose to specify the -revised option, a user-provided list of
files will be used. If the user wants to supply a design as golden RTL, the user needs to
use the -golden option.

As the generated RTL source files can be loaded into a different Genus section. To validate
the design with or without PMBIST logic, LEC can be done between RTL.0, ELAB.0, RTL.1,
and ELAB.1 as the following. The RTL.0 is the RTL source files for initial Genus section. The
Elab.0 is the back-annotated design files with PMBIST logic inserted after elaboration. The
RTL.1 is the back-annotated design with PMBIST logic which can be loaded into another
Genus section. The ELAB.1 is the elaborated one in another Genus section.
■ Check RTL.0 as golden against ELAB.0 as revised.
write_do_lec -hierarchical_reference \
-golden_design ${rtl_0} \
-revised_design ${elab_0} \
-logfile ${path}/write_do_lec.log > ${path}\${do_script}

■ Check RTL.0 as golden against RTL.1 as revised.

write_do_lec -hierarchical_reference \
-golden_design ${rtl_0} \
-revised_design ${rtl_1} \
-logfile ${path}/write_do_lec.log > ${path}\${do_script}

■ Check RTL.1 as golden against ELAB.0 as revised.

write_do_lec -hierarchical_reference \
-no_dft \
-golden_design ${rtl_1} \
-revised_design ${elab_0} \
-logfile ${path}/write_do_lec.log > ${path}\${do_script}

Note: As part of the back-annotation in RTL flow, the design changes are denoted as
Verilog hierarchical references. When loading the RTL.1 into another Genus section, the
hierarchical references will become connections and Genus automatically created pins
or ports if necessary.
■ Check ELAB.0 as golden against ELAB.1 as revised.
write_do_lec -hierarchical_reference \
-golden_design ${elab_0} \
-revised_design ${elab_1} \
-logfile ${path}/write_do_lec.log > ${path}\${do_script}

Currently, PMBIST LEC flow still utilize the old LEC flow for the support of Verilog hierarchical
reference.

February 2022 149 Product Version 21.11

Golden RTL.0 Golden

Hide
DFT
Structures
Hide
DFT
Structures
Revised

Revised ELAB.0 RTL.1

Golden (+ PMBIST) (+PMBIST)
Revised Golden
Full equivalence
Check RTL
Full equivalence back-annotation
Check Genus
reload

Revised ELAB.1
(+ PMBIST)

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

February 2022 150 Product Version 21.11

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

add ignored output mda_tdo_pin_or_port -golden

February 2022 151 Product Version 21.11

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 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 memory devices which have ports specifically used by memory
BIST applications. The set of memory ports is described in “port_alias Specification” on
page 217. 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 pin constraints 0 JTAG_TRST -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

February 2022 152 Product Version 21.11

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

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.

February 2022 153 Product Version 21.11

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 pin constraints 0 JTAG_TRST -golden
add ignored output JTAG_TDO -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
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
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

February 2022 154 Product Version 21.11

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

February 2022 155 Product Version 21.11

February 2022 156 Product Version 21.11

6
Design Verification

Topics covered in this chapter:

■ Getting to Modus PMBIST Pattern Simulation on page 158
❑ Simulation Scripts on page 158
❑ PMBIST Patterns on page 160
❑ ROM Data Load Files on page 160
❑ Design and Technology Libraries on page 161
■ Analyzing Pattern Class Simulation Results on page 161
❑ irun to analyze_embedded_test Flow on page 162
❑ irun to CPP to analyze_embedded_test Flow on page 163
❑ Special Handling of Four pin TAP controller in Simulation on page 164
■ Injecting Memory Faults on page 165
❑ Methodology on page 165
❑ Changes in the Verilog Memory Models on page 166
❑ Fault Injection Control Files on page 167
■ Understanding analyze_embedded_test Results on page 168
❑ Working with Simulation Logs on page 169
❑ Working with CPP Data on page 173
■ Analyzing and Debugging PMBIST Simulation Results on page 178

February 2022 157 Product Version 21.11

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 3, “PMBIST Pattern Generation”. Figure 3-3 on page 92
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:

February 2022 158 Product Version 21.11

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

February 2022 159 Product Version 21.11

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

February 2022 160 Product Version 21.11

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.

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 158 is repeated in the following figure for easier
cross-reference with Table 6-1 on page 162.

Figure 6-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 6-1 Design Verification Pattern Class Support

February 2022 161 Product Version 21.11

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
-analysis production -simlog simulation-log-file
-interfacefiledir intfdir
-topshell design

❑ pattern class: diagnostic

analyze_embedded_test
-interfacefiledir intfdir
-topshell design
-analysis diagnostic
-simlog simulation-log-file

❑ pattern class: jtag_redundancy

analyze_embedded_test
-analysis jtag_redundancy
-simlog simulation-log-file

February 2022 162 Product Version 21.11

-interfacefiledir intfdir
-topshell design

■ Direct access
❑ pattern class: directaccess
analyze_embedded_test
-analysis directaccess
-interfacefiledir intfdir
-topshell design
-simlog simulation-log-file

❑ pattern class: burnin

analyze_embedded_test
-interfacefiledir intfdir
-topshell design
-analysis burnin
-simlog simulation-log-file

❑ pattern class: pmda_diagnostic

analyze_embedded_test
-interfacefiledir intfdir
-topshell design
-analysis pmda_diagnostic
-simlog simulation-log-file

❑ pattern class: pmda_redundancy

analyze_embedded_test
-interfacefiledir intfdir
-topshell design
-analysis pmda_redundancy
-simlog simulation-log-file

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

Valid analyze_embedded_test command line templates for the supported pattern

classes with both JTAG access and direct access are:

February 2022 163 Product Version 21.11

■ JTAG access
❑ pattern class: production
analyze_embedded_test
-analysis production
-interfacefiledir intfdir
-topshell design

❑ pattern class: diagnostic

analyze_embedded_test
-analysis diagnostic
-interfacefiledir intfdir
-topshell design

❑ pattern class: jtag_redundancy

analyze_embedded_test
-analysis jtag_redundancy
-interfacefiledir intfdir
-topshell design

■ Direct access
❑ pattern class: directaccess
analyze_embedded_test
-analysis directaccess
-interfacefiledir intfdir
-topshell design

❑ pattern class: burnin

analyze_embedded_test
-analysis burnin
-interfacefiledir intfdir
-topshell design

❑ pattern class: pmda_diagnostic

analyze_embedded_test
-analysis pmda_diagnostic
-interfacefiledir intfdir
-topshell design

❑ pattern class: pmda_redundancy

analyze_embedded_test
-analysis pmda_redundancy
-interfacefiledir intfdir
-topshell design

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

February 2022 164 Product Version 21.11

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 6-
1 on page 161.
■ 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.

February 2022 165 Product Version 21.11

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

February 2022 166 Product Version 21.11

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.

February 2022 167 Product Version 21.11

Table 6-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

February 2022 168 Product Version 21.11

methodology described in the section Injecting Memory Faults on page 165. 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 162
■ irun to CPP to analyze_embedded_test Flow on page 163

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.

February 2022 169 Product Version 21.11

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]

INFO (TEM-304): Total Failures Analyzed: 2 [end TEM_304]

---------------------------------------------------------------
Amu Siu Dcu Test Status
---------------------------------------------------------------
0 4 0 Failed
0 5 0 Failed

INFO (TEM-314): Successfully analyzed failures.

Output file is: 'path/log_analyze_embedded_test_time-stamp'. [end TEM_314]

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)

February 2022 170 Product Version 21.11

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

INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistchk_tdr_map.txt'. [end
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/design_test_def.txt'. [end TEM_507]

INFO (TEM-507): Parsing the test definition file 'path_to_file/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.MBIST_ATE_DIAG_refclk_0_0.log'. [end

TEM_311]

INFO (TEM-304): Total Failures Analyzed: 6 [end TEM_304]

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_1 march_lr 1 fast-row complement solid 6 10 0 6 0
0 1 0 0 ... 1 testplan_1 march_lr 2 fast-row complement solid 0 3 0 0 0

Scheduling Unit 2 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_2 march_sr 1 fast-column linear solid 0 3 0 0 0
0 1 0 0 ... 1 testplan_2 march_sr 1 fast-column linear solid 1 2 0 1 0
0 1 0 0 ... 1 testplan_2 march_sr 1 fast-column linear solid 5 10 0 5 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*

February 2022 171 Product Version 21.11

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,

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.

February 2022 172 Product Version 21.11

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

INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistdrar_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/design_test_def.txt'. [end TEM_507]

INFO (TEM-507): Parsing the test definition file 'path_to_file/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.MBIST_ATE_JTAG_REDUNDANCY_0_0.log'. [end

TEM_311]

INFO (TEM-304): Total Failures Analyzed: 3 [end TEM_304]

Scheduling Unit 1 failures:

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

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.

February 2022 173 Product Version 21.11

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

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.

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]

INFO (TEM-507): Parsing the test definition file

'path/install/tools.lnx86/tb/defaults/mbist/predefined_algorithms.txt'. [end TEM_507]

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

---------------------------------------------------------------
Amu Siu Dcu Test Status
---------------------------------------------------------------
0 4 0 Failed
0 5 0 Failed

INFO (TEM-314): Successfully analyzed failures.

Output file is: 'path/log_analyze_embedded_test_time-stamp'. [end TEM_314]

February 2022 174 Product Version 21.11

Diagnostic

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

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

February 2022 175 Product Version 21.11

INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistchk_tdr_map.txt'. [end
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/design_test_def.txt'. [end TEM_507]

INFO (TEM-507): Parsing the test definition file 'path_to_file/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.MBIST_ATE_DIAG_refclk_0_0.log'. [end

TEM_311]

INFO (TEM-319): Chip: serialno_23_022_030.

Total Failures Analyzed: 6. [end TEM_319]

Lot: 000000104C01291-01
Wafer: 23
Wafer Position: 022,030
Testblockname: Tblknam
Testcondition: RSFN1

Scheduling Unit 1 failures:

Scheduling Unit 2 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_2 march_sr 1 fast-column linear solid 0 3 0 0 0
0 1 0 0 ... 1 testplan_2 march_sr 1 fast-column linear solid 1 2 0 1 0
0 1 0 0 ... 1 testplan_2 march_sr 1 fast-column linear solid 5 10 0 5 0

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
analyze_embedded_test command. These miscompares are used to pass information
from the patterns to analyze_embedded_test.

February 2022 176 Product Version 21.11

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

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.

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

INFO (TEM-301): Parsing the test data register mapping file 'path_to_file/design_mbistdrar_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/design_test_def.txt'. [end TEM_507]

INFO (TEM-507): Parsing the test definition file 'path_to_file/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.MBIST_ATE_JTAG_REDUNDANCY_0_0.log'. [end

TEM_311]

INFO (TEM-319): Chip: serialno_23_022_030.

Total Failures Analyzed: 3. [end TEM_319]

Lot: 000000104C01291-01
Wafer: 23
Wafer Position: 022,030
Testblockname: Tblknam
Testcondition: RSFN1

Scheduling Unit 1 failures:

February 2022 177 Product Version 21.11

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 178
■ PMBIST Startup on page 182
■ Memory Connections and Activity on page 196
■ PMBIST Comparators on page 201
■ PMBIST Completion on page 203
■ Determining Miscomparing Registers from Simulation Logs on page 205

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

February 2022 178 Product Version 21.11

inspected on any registered signal in the simulation waveforms, as displayed in Figure 6-3 on
page 180, 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.

February 2022 179 Product Version 21.11

Figure 6-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 6-4 on page 181.

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.

February 2022 180 Product Version 21.11

Figure 6-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 6-5 on page 182, the extracted values are shown in the inequality.

February 2022 181 Product Version 21.11

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

February 2022 182 Product Version 21.11

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 6-6 on page 183.

Figure 6-6 Test Control Signal Stability Check

remain in non-controlling state through test

February 2022 183 Product Version 21.11

■ 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 6-7 on page 185.

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 6-8 on
page 186.

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.

February 2022 184 Product Version 21.11

Figure 6-7 Clock Controllability for JTAG Access Only

stable jtag_tck pulses and

mbist_clk pulses as required

February 2022 185 Product Version 21.11

Figure 6-8 Clock Controllability for Direct Access Only

stable mda_tck pulses and

mbist_clk pulses as required

February 2022 186 Product Version 21.11

■ 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 6-9 on page 188.
define_mbist_clock -name m_dsram_clk0 -hookup_pin DTMF_INST0/TEST_CONTROL_INST/
m_dsram_clk -period 10000 refclk

February 2022 187 Product Version 21.11

Figure 6-9 Clock Frequency Checks

50ns period

10ns period

February 2022 188 Product Version 21.11

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

February 2022 189 Product Version 21.11

Figure 6-10 JTAG Concerns for hardwired testplans

February 2022 190 Product Version 21.11

Figure 6-11 JTAG Concerns for programmed testplans

February 2022 191 Product Version 21.11

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

February 2022 192 Product Version 21.11

Figure 6-12 Direct Access Concerns

February 2022 193 Product Version 21.11

■ 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 6-13 on page 195 for details in the waveforms.

February 2022 194 Product Version 21.11

Figure 6-13 Proper Startup Markers

February 2022 195 Product Version 21.11

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 6-14 on page 197. Note the first write operation is being transferred to the memory
device starting with the clock edge at the red cursor.

February 2022 196 Product Version 21.11

Figure 6-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 6-15 on

February 2022 197 Product Version 21.11

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

February 2022 198 Product Version 21.11

Figure 6-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

February 2022 199 Product Version 21.11

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
and address C/A 1 C/A 2

memory read
Q1 Q2

PMBIST comparator
capture memory data Q1 Q2

read_delay 3 - Memory Output Data Pipeline Register Timing

February 2022 200 Product Version 21.11

PMBIST command
and address C/A 1 C/A 2

memory read
Q1 Q2

memory output
register Q1 Q2

PMBIST comparator
capture memory data Q1 Q2

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.

February 2022 201 Product Version 21.11

Figure 6-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

February 2022 202 Product Version 21.11

registered within the comparator prior to analysis. Table 6-3 on page 203 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 6-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 6-17 on page 204.

February 2022 203 Product Version 21.11

Figure 6-17 Done Register and Summary Failure Register Inspection

lack of failure indications is a good

sign the memory read timing is correct

February 2022 204 Product Version 21.11

■ 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

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]
INFO (TEM-507): Parsing the test definition file
'path/install/tools.lnx86/tb/defaults/mbist/predefined_algorithms.txt'. [end TEM_507]

INFO (TEM-500): Parsing the pattern_control file 'path/design_pattern_control.txt'. [end TEM_500]

INFO (TEM-311): Parsing the simulation log file 'sim.experiment-name.log'. [end TEM_311]

INFO (TEM-304): Total Failures Analyzed: 2 [end TEM_304]

---------------------------------------------------------------
Amu Siu Dcu Test Status
---------------------------------------------------------------
0 4 0 Failed
0 5 0 Failed
INFO (TEM-314): Successfully analyzed failures.
Output file is: 'path/log_analyze_embedded_test_time-stamp'. [end TEM_314]

and further analyzed for failing register data written into the corresponding *.translated file.

February 2022 205 Product Version 21.11

(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 6-18 on page 207 contains an example of this process.

February 2022 206 Product Version 21.11

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

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]
0 1 . 11 DTMF_INST1/tem_siu1/l_siudone_reg
0 1 0 12 DTMF_INST1/tem_siu1/l_dcufail_reg[0]
0 2 . 13 DTMF_INST2/tem_siu2/l_siudone_reg
0 2 0 14 DTMF_INST2/tem_siu2/l_dcufail_reg[0]
0 3 . 15 DTMF_INST3/tem_siu3/l_siudone_reg
0 3 0 16 DTMF_INST3/tem_siu3/l_dcufail_reg[0]
0 4 . 17 DTMF_INST0/tem_siu4/l_siudone_reg
0 4 0 18 DTMF_INST0/tem_siu4/l_dcufail_reg[0]
0 5 . 19 DTMF_INST0/tem_siu5/l_siudone_reg
0 5 0 20 DTMF_INST0/tem_siu5/l_dcufail_reg[0]
0 6 . 21 DTMF_INST1/tem_siu6/l_siudone_reg
0 6 0 22 DTMF_INST1/tem_siu6/l_dcufail_reg[0]
...

February 2022 207 Product Version 21.11

February 2022 208 Product Version 21.11

A
Customizing PMBIST Memory View and
Configuration Files

■ Conventions on page 211

■ Memory View File Skeleton on page 212
■ Configuration File Skeleton on page 212
■ module Group on page 215
❑ port_alias Specification on page 217
❑ port_action Specification on page 222
❑ address_limit Specification on page 224
❑ read_delay Specification on page 225
❑ data_order Specification on page 227
❑ write_mask_binding Specification on page 230
❑ address_partition Specification on page 232
❑ wrapper Specification on page 242
❑ redundancy Specification on page 244
■ macro Group on page 257
❑ name Specification on page 259
❑ port_access Specification on page 260
❑ port_alias Specification on page 262
❑ port_action Specification on page 264
❑ assertion_limit Specification on page 266
❑ memory_map Specification on page 268

February 2022 209 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

■ algorithm_constraints Specification on page 277

■ algorithm Specification on page 283
■ testplan Specification on page 288
■ target Group on page 296
❑ sharing_limit Specification on page 299
❑ clock Specification on page 301
❑ location Specification on page 303
❑ failure_recording Specification on page 304
❑ interface_control Specification on page 312
❑ testplans Specification on page 319
■ ignore Group on page 320
■ Memory View File Syntax Summary on page 321
■ Configuration File Syntax Summary on page 324

February 2022 210 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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

February 2022 211 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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 {
{module_list | macro_name_list | instance_list}
}
}...
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

February 2022 212 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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.

February 2022 213 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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 283

algorithm_constraints Specification on page 277

ignore Group on page 320

module Group on page 215

macro Group on page 257

target Group on page 296

testplan Specification on page 288

February 2022 214 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

module Group
module {
module_list
}
{
module_specifications
}

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
■ Port naming and handling during test
■ 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.
module_specifications

February 2022 215 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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 224

address_partition Specification on page 232

data_order Specification on page 227

port_action Specification on page 222

port_alias Specification on page 217

read_delay Specification on page 225

redundancy Specification on page 244

wrapper Specification on page 242

write_mask_binding Specification on page 230

February 2022 216 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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

February 2022 217 Product Version 21.11

© 2003-2022 Cadence Design Systems, Inc. All Rights Reserved.
Modus: Guide 8: PMBIST
Customizing PMBIST Memory View and Configuration Files

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

February 2022 218 Product Version 21.11

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

February 2022 219 Product Version 21.11

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

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

February 2022 220 Product Version 21.11

■ 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
}
}
}

February 2022 221 Product Version 21.11

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.

February 2022 222 Product Version 21.11

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

February 2022 223 Product Version 21.11

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

February 2022 224 Product Version 21.11

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
capture memory data Q1 Q2

February 2022 225 Product Version 21.11

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
capture memory data Q1 Q2

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
capture memory data Q1 Q2

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

February 2022 226 Product Version 21.11

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.

February 2022 227 Product Version 21.11

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

{
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
data_order { 0:15 31:16 }
}
}

February 2022 228 Product Version 21.11

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.
{
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
data_order { {0:15} {31:16} }
}
}

February 2022 229 Product Version 21.11

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.

February 2022 230 Product Version 21.11

Example

In the configuration below, four write mask bits control different 8 contiguous bit portions of
the memory word.
{
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
write_mask_binding {
0 {0:7}
1 {8:15}
2 {16:23}
3 {24:31}
}
}
}

February 2022 231 Product Version 21.11

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

February 2022 232 Product Version 21.11

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

February 2022 233 Product Version 21.11

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

February 2022 234 Product Version 21.11

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

February 2022 235 Product Version 21.11

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

address_partition { row 3:2 column 1:0 } column mux factor = 4

- 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

February 2022 236 Product Version 21.11

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.

February 2022 237 Product Version 21.11

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.
The integer fields must lie within the valid address range.
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.

February 2022 238 Product Version 21.11

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 }

February 2022 239 Product Version 21.11

Specifies the address bits used to select the banks. Bank

address bits can be specified individually or as a contiguous
range of address bits.
The integer fields must lie within the valid address range.
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.

February 2022 240 Product Version 21.11

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

February 2022 241 Product Version 21.11

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

February 2022 242 Product Version 21.11

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

{
module { RAM_2000X32 }
{
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 }
}
}
}

February 2022 243 Product Version 21.11

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 }...]
[data {{ bit| bit:bit}...}]
[bank_range {{ integer| integer:integer}...}]
[map { [srsi port srclk port [srst port] [sre port] [srso port]]
[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-

February 2022 244 Product Version 21.11

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

address_partition { row 3:2 column 1:0 } column mux factor = 4

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

February 2022 245 Product Version 21.11

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

February 2022 246 Product Version 21.11

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}
column 1 data {0 1} bank_range {1}
row 3:2 data {2 3}
column 1 data {2 3} bank_range {0}
column 1 data {2 3} bank_range {1}
}

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 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}
column 1 data {0 1} bank_range {0}
map {data 0:1 address 0:1 CRAL[5:3] shift_right_integer
}
column 1 data {0 1} bank_range {1}
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}
column 1 data {2 3} bank_range {0}
map {data 0:1 address 0:1 CRAH[5:3] shift_left_integer
}
column 1 data {2 3} bank_range {1}
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

February 2022 247 Product Version 21.11

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 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}
column bank_range {1}
}

When repair operations are controlled by PMBIST, port mapping information is also

February 2022 248 Product Version 21.11

necessary. The description below shows the extensions to the example including connections
to relevant ports on the memory.
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}
column bank_range {0}
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}
column bank_range {1}
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.

February 2022 249 Product Version 21.11

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

February 2022 250 Product Version 21.11

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

February 2022 251 Product Version 21.11

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

February 2022 252 Product Version 21.11

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.

February 2022 253 Product Version 21.11

■ 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

February 2022 254 Product Version 21.11

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

February 2022 255 Product Version 21.11

■ 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}
column bank_range {0:1}
column bank_range {2:3}
column bank_range {2:3}
}
}
}

February 2022 256 Product Version 21.11

macro Group
macro {
macro_list
}
{
macro_specifications
}

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:

■ Port naming and handling during test
■ 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.

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

February 2022 257 Product Version 21.11

Related Information

assertion_limit Specification on page 266

memory_map Specification on page 268

name Specification on page 259

port_access Specification on page 260

port_action Specification on page 264

port_alias Specification on page 262

February 2022 258 Product Version 21.11

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
}
{
name mp_core_L2_mbist
}
}

February 2022 259 Product Version 21.11

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

February 2022 260 Product Version 21.11

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
}
{
name mp_core_L1_mbist
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
}
{
name mp_core_L2_mbist
port_access {
assign mbreq2 0
assign mblogarray2[1:0] 00
assign mbaddr2[12:8] 00000
sample mback2 0
}
}
}

February 2022 261 Product Version 21.11

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.

Pin references are path names relative to the macro module boundary. "/" is used as the
hierarchical separator.

Description

For details refer to port_alias Specification on page 217.

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
}
{
name mp_core_L1_mbist
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
}
port_alias {
a mbaddr1[10:0]
clk CLK
we mbwe1
wem mbwem1
re mbre1
d mbdatain1[127:0]
q mbdataout1[127:0]
}
}
}

February 2022 262 Product Version 21.11

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

February 2022 263 Product Version 21.11

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.

Pin references are path names relative to the macro module boundary. "/" is used as the
hierarchical separator.

Description

For details refer to port_action Specification on page 222.

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
}
{
name mp_core_L1_mbist
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
}
port_alias {

February 2022 264 Product Version 21.11

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

February 2022 265 Product Version 21.11

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.

Pin references are path names relative to the macro module boundary. "/" is used as the
hierarchical separator.

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
}
{
name mp_core_L1_mbist
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
}
port_alias {
a mbaddr1[10:0]

February 2022 266 Product Version 21.11

clk CLK
we mbwe1
wem mbwem1
re mbre1
d mbdatain1[127:0]
q mbdataout1[127:0]
}
port_action {
dftse 0
dftmembypass 0
pwrupcpul1 11
}
}
}

February 2022 267 Product Version 21.11

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 {
integer { {bit | bit:bit}... } ...
} ]
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 ...
}
} ...
}

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.

February 2022 268 Product Version 21.11

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

February 2022 269 Product Version 21.11

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 230 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.
memory_module module_name

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
instances { instance_name[ instance_name]... }

February 2022 270 Product Version 21.11

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
according to the order indicated in the vector notation.
Each such port/pin must have been previously defined
using a port_access Specification on page 260.
■ 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 217 for additional
information.

February 2022 271 Product Version 21.11

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
}
{
name mp_core_L1_mbist
port_access {
assign mbreq1[1:0] 00
assign mbcpid[1:0] 00

February 2022 272 Product Version 21.11

assign mblogarray1[1:0] 00
assign mbaddr1[10:7] 0000
sample mback1[1:0] 00
}
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 {
memory_module ram128x64cm4
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}
mblogarray1[1:0] {01}

February 2022 273 Product Version 21.11

mbaddr1[10:9]
}
read_delay 9
write_mask_binding {
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 {
memory_module ram512x128cm2
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]
}
}
}
}
}

February 2022 274 Product Version 21.11

dftse 0
dftmembypass 0
pwrupl2 1
}
assertion_limit {
mbwe2 1
mbre2 1
}
memory_map {
target_map {
mblogarray2[1:0] {00}
mbaddr2[12:11] {00}
mbaddr2[10:9]
}
read_delay 10
request_latency 2
segment {
memory_module ram512x72cm4
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 {
memory_module ram512x72cm4
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 {
mblogarray2[1:0] {01}
mbaddr2[12:8]
}
read_delay 12
request_latency 2
segment {
memory_module ram256x64cm2
instances { l2recram00 l2recram01 l2recram02 l2recram03
l2recram04 l2recram05 l2recram06 l2recram07
l2recram08 l2recram09 l2recram0a l2recram0b
l2recram0c l2recram0d l2recram0e l2recram0f
l2recram10 l2recram11 l2recram12 l2recram13
l2recram14 l2recram15 l2recram16 l2recram17
l2recram18 l2recram19 l2recram1a l2recram1b
l2recram1c l2recram1d l2recram1e l2recram1f }
port_alias {
a mbaddr2[7:0]
d mbdatain2[63:0]
we mbwe2
re mbre2

February 2022 275 Product Version 21.11

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

February 2022 276 Product Version 21.11

algorithm_constraints Specification
algorithm_constraints {
[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

February 2022 277 Product Version 21.11

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.
Default: determined by used algorithms within the
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.

February 2022 278 Product Version 21.11

Default: determined by used algorithms within the

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.
Default: determined by used algorithms within the
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 288 for more details.
address_updates { [linear|li] [complement|ca] [twos-power|2i]
[worstcase|wc] [shifted|s1] [next -physical|np] [next-address|na] }

February 2022 279 Product Version 21.11

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 288 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 288 for
more details.

Example

The configuration file indicates a set of preferred limit values and hardware options.
algorithm_constraints {
algorithm_limit 64
access_limit 8
repeat_limit 256
pause_duration 50ms
macro_support yes
}

Algorithm Constraints Table

February 2022 280 Product Version 21.11

algorithms = connectivity | algorithm_limit = 44 | access_limit = 12 |

February 2022 281 Product Version 21.11

algorithms = march_sam | algorithm_limit = 223 | access_limit = 27 |

February 2022 282 Product Version 21.11

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

February 2022 283 Product Version 21.11

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
performed for each execution of the macro.
■ 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
performed for each execution of the macro.

February 2022 284 Product Version 21.11

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

February 2022 285 Product Version 21.11

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

February 2022 286 Product Version 21.11

■ 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)
}
}

February 2022 287 Product Version 21.11

testplan Specification
testplan {
name testplan_name
[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 ]
} ]
[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 xmap_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.

February 2022 288 Product Version 21.11

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.

February 2022 289 Product Version 21.11

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

February 2022 290 Product Version 21.11

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

February 2022 291 Product Version 21.11

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

February 2022 292 Product Version 21.11

■ 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
according to the order indicated in the vector notation.
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

February 2022 293 Product Version 21.11

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

February 2022 294 Product Version 21.11

algorithms { march-lr march-g }

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

February 2022 295 Product Version 21.11

target Group
{
target {
{module_list | macro_name_list | instance_list}
}
{
target_specifications
}
}

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

February 2022 296 Product Version 21.11

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
}
{
target_specifications
}
}

■ In the following example, the target specifications apply to the specified instances.
{
target{
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
/DLX/RAMTEST
}
{
target_specifications
}
}

■ 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
}
{
target_specifications
}
}

February 2022 297 Product Version 21.11

Related Information

clock Specification on page 301

interface_control Specification on page 312

location Specification on page 303

failure_recording Specification on page 304

sharing_limit Specification on page 299

testplans Specification on page 319

February 2022 298 Product Version 21.11

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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 2
}
target {
/DLX/RAMTEST
}
{

February 2022 299 Product Version 21.11

}
}

February 2022 300 Product Version 21.11

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/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
/DLX/RAMTEST
}{
sharing_limit 3
clock CLK1X

February 2022 301 Product Version 21.11

}
}

February 2022 302 Product Version 21.11

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/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
/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
}
}

February 2022 303 Product Version 21.11

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 |
{module_list | instance_list |
macro_instance_name:macro_interface_name { instance_list...}... |
macro_module:macro_interface_name { instance_list...}...
}...}}] }
[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

February 2022 304 Product Version 21.11

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.

February 2022 305 Product Version 21.11

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

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.

February 2022 306 Product Version 21.11

■ 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 |
macro_instance_name:macro_interface_name { instance_list...}... |
macro_module:macro_interface_name { 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.

February 2022 307 Product Version 21.11

■ 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 |
macro_instance_name:macro_interface_name { instance_list...}... |
macro_module:macro_interface_name { 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.

February 2022 308 Product Version 21.11

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

February 2022 309 Product Version 21.11

■ 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

February 2022 310 Product Version 21.11

Examples
■ The following example specifies the collection of memory diagnostic failure information
should be included in the PMBIST features.
{
target {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
clock CLK1X
failure_recording
{
redundancy_analysis { dedicated }
}
}
}

February 2022 311 Product Version 21.11

interface_control Specification
interface_control
{
[inputs
{
[pipeline_stages integer |
{ {integer {module_list |
instance_list}}...} ]
}]
[outputs
{
[pipeline_stages integer |
{ {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.

February 2022 312 Product Version 21.11

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

February 2022 313 Product Version 21.11

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

February 2022 314 Product Version 21.11

■ 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

February 2022 315 Product Version 21.11

Examples
■ The following example uses the shared option for the comparators.
{
target {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{

February 2022 316 Product Version 21.11

sharing_limit 3
location {/DLX/Hier_A}
clock CLK1X
failure_recording
{
diagnostics yes
}
interface_control
{
outputs {comparators {shared}}
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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
clock CLK1X
interface_control
{
outputs
{
pipeline_stages 2
}
}
}
}

February 2022 317 Product Version 21.11

■ 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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
clock CLK1X
interface_control
{
inputs
{
pipeline_stages { 2 {/DLX/Hier_A/RAM2TEST} }
}
}
}
}

February 2022 318 Product Version 21.11

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 288.
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 {
/DLX/Hier_A/RAM2TEST
/DLX/Hier_A/RAM3TEST
}
{
sharing_limit 3
location {/DLX/Hier_A}
clock mbist_clock_object
interface_control
{
outputs {comparators {shared}}
}
testplans
{
march-group
}
}
}

February 2022 319 Product Version 21.11

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
}

February 2022 320 Product Version 21.11

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} }]
[address_limit integer]
[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 }...
[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 }...]
[data {{ bit| bit:bit}...}]
[bank_range {{ integer| integer:integer}... }]
[map { [srsi port srclk port [srst port] [sre port] [srso port]]
[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 {

February 2022 321 Product Version 21.11

[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 {
integer { {bit | bit:bit}... } ...
} ]
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 ...
}
} ...
} ...
}
}

Example
Following is an example of Cadence Memory View wherein the bank bits that are in the
middle of the row address bits:
{
module { sram_sp_hslve } {
/*
* Address limit needs to be set to the actual number of addresses
* present in the memory.
*/
address_limit 4096
wrapper sram_sp_hslve
read_delay 2
port_alias {
ren REN
tren TREN
csn CEN
tcsn TCEN
clk CLK
bisten TEN
d D
td TD
q Q
a A
ay AY
csny CENY
weny GWENY
ta TA
wen GWEN
twen TGWEN
be DFTRAMBYP

February 2022 322 Product Version 21.11

cre CRE1
cra FCA1
cre CRE2
cra FCA2
rre RRE1
rra FRA1
}
port_action {
SMCLK X
SSCLK X
SBYPCLK X
SI[0] X
SI[1] X
SO[0] X
SO[1] X
SE X
STOV X
EMA[2] X
EMA[1] X
EMA[0] X
EMAW[1] X
EMAW[0] X
EMAS X
RET1N X
}
port_Test {
AY[11:0]
CENY
GWENY
Default X
}
/*
* Address bus partitioning must be described to reveal the
* memory's physical layout. Refer to the documentation for
* details.
*/
address_partition { bank 6:5 row 11:7 4:3 order { 0 1 } column 2:0 order
{ data 0 1 4 6 8 10 12 14 } { 0 1 } order { data 2 3 5 7 9 11 13 15 } { 1 0 } }
/*
* The "data_order" must be described to reveal the physical
* order of the data-bits of the memory. Refer to the documentation
* for details.
*/
data_order {
0 2 1 3 4 5 6 7 8 9 10 11 12 13 14 15
}
redundancy {
column data{0:7} map { enable CRE1 data 0:7 FCA1[2:0]
shift_left_integer }
column data{8:15} map { enable CRE2 data 0:7 FCA2[2:0]
shift_left_integer }
row 11:7 4:3 bank_range { 0:3 } map { enable RRE1 address 0:511
FRA1[9:0] 0:511 }
}
}
}

February 2022 323 Product Version 21.11

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 |
{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 |
{module_list | instance_list |
macro_instance_name:macro_interface_name { instance_list...}... |
macro_module:macro_interface_name { instance_list...}...
}...}}] }
[row_first_2d | column_first_2d]
}
]
[self_repair {
{none |
soft [enable_hri]}
}]
} ]
[interface_control
{
[inputs {
[pipeline_stages integer |
{{integer { module_list | macro_name_list | instance_list}}...}]
}]
[outputs {
[pipeline_stages integer |
{{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 ]}]
}]

February 2022 324 Product Version 21.11

} ]
testplans { testplan_name [testplan_name ]... }
}
}

{
ignore {
{module_list | macro_name_list | instance_list }
}
}
algorithm_constraints {
[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-address | na ]
[ 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]
} ]
}
algorithm {
name algorithm_name
{
{wait integer |
pause |
address_direction (sequence_iterator) }...
}
}
testplan {
name testplan_name
[address_orders {
[ no-update | nu ]
[ fast-row | fr ]
[ fast-column | fc ]
[ fast-diagonal | fd ]

February 2022 325 Product Version 21.11

} ]
[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]
} ]
[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 xmap_register binary_string |
wait integer }...
} ]
[onetime]
[hardwired | programmed | test-access-method]
}

February 2022 326 Product Version 21.11

B
PMBIST using Core Test Language (CTL)
Memory Models

■ CTL Memory Model Skeleton on page 328

■ Sample CTL Memory Model File on page 330

February 2022 327 Product Version 21.11

CTL Memory Model Skeleton

STIL 1.0 {
Design 2005;
CTL 2005;
}
Variables (VARIABLES_DOMAIN) {
( IntegerConstant CONST_NAME := INTEGER; )*
}
Signals {
(signal_name_expr < In | Out | InOut | Supply | Pseudo >; )*
}
Procedures ( PROCEDURE_DOMAIN_NAME ) {
( PROCEDURE_NAME {
( PATTERN-STATEMENT )*
} )*
}
Environment <memory_name>_mbist{
CTLMode {
Internal {
( DataType ( data_types)+ ; )*
( DataType ( data_types)+ {
( ActiveState
< ForceDown | ForceUp | ForceOff | ForceValid
| ExpectLow | ExpectHigh | ExpectOff| ExpectValid >;
)
})*
}
Relation {
( Port signals_expression (integer) ; )*
( WriteEnableMap mask_signal write_sig_expression; )*
}
MemoryPhysicalOrganization {
FunctionalConfigurationDefinition {
NumberOfWords INTEGER ;
WordSize INTEGER ;
AddressSize INTEGER ;
RowAddress { ValueRange INTEGER INTEGER ; AddressPartition
address_expr ;}
( ColumnAddress { ValueRange INTEGER INTEGER ; AddressPartition
address_expr ;} )
( BankAddress { ValueRange INTEGER INTEGER ; AddressPartition
address_expr ;} )
}
ColumnMultiplexing INTEGER ;
ScrambleDefinition {
( PhysicalRowAddress[INTEGER] RowAddress_statement_expr;)+
( PhysicalColumnAddress[INTEGER] ColumnAddress_statement_expr;)*
( PhysicalData[INTEGER] write_data_bit;)*
}
BitDistribution INTEGER ;

February 2022 328 Product Version 21.11

( BitDistributionMirroringPeriod INTEGER ; )
Relation {
( FunctionalConfigurationMap FUNC_CONF_NAME {Port INTEGER} )*
( ScrambleMap SCRAMBLE_NAME {( Port INTEGER ; )+} )+
}
}

MemoryRepair {
(RepairResource (REPAIR_RESOURCE_NAME) {
Type <Column | Row | IO> ;
(Width INTEGER;)
(DataRange {(ValueRange INTEGER INTEGER;)+})
(EnableConnectivity {
(REDUNDANCY_CONTROL_SIGNAL {
RepairSignal addr_sig_expression;
}) + // End of REDUNDANCY_CONTROL_SIGNAL
}) // End of EnableConnectivity
(DataConnectivity {
(REDUNDANCY_CONTROL_SIGNAL {
({RepairValue vec_data; (AssociatedSignal {
Data[INTEGER];})})+
({DisableValue vec_data;}
}) + // End of REDUNDANCY_CONTROL_SIGNAL
}) // End of DataConnectivity
(AddressConnectivity {
(REDUNDANCY_CONTROL_SIGNAL {
RepairSignal addr_sig_expression;
}) + // End of REDUNDANCY_CONTROL_SIGNAL
}) // End of AddressConnectivity
})+ // End of RepairResource
} // End of MemoryRepair

PatternInformation {
Procedure PROCEDURE_NAME { Purpose ( purpose_name)+ ;}
}
}
}

February 2022 329 Product Version 21.11

Sample CTL Memory Model File

// Define CTL version.
STIL 1.0 {
Design 2005;
CTL 2005;
}

Variables {
IntegerConstant MaxData := 63;
IntegerConstant MaxAdd := 8;
IntegerConstant DataWidth := 64;
IntegerConstant AddrWidth := 9;
} // end Variables
Signals {
Q1 [MaxData..0] Out;
Q2 [MaxData..0] Out;
.....
.....
} // end Signals

Procedures Memory_access {
read_cycle_A {
W "_default_WFT_";
...
...
V { CLK1 = P;
CEN1 = 0;
GWEN1 = 1;
TBISTE1 = 1;
WEN1[MaxData..0] = \rFULLData 0;
A1[MaxAdd..0] = \rFULLAdd #;
TIE_HIGH_SIGNAL1 = 1;
TIE_HIGH_SIGNAL2 = 1;
Q1[MaxData..0] = \rFULLData #;
OUTSIG = #;
}
}
}
.....
.....
bist_read_cycle_A {
W "_default_WFT_";
C {
all_inputs = \rFULLAdd N \rFULLAdd N \rFULLData N 0N \r3 N \r3 N 0N 0N;
all_outputs = \rFULLData X \rFULLData X X;
}
V { CLK1 = P;
TCEN1 = 0;
TGWEN1 = 1;
TBISTE1 = 0;
TWEN1[MaxData..0] = \rFULLData 0;
TA1[MaxAdd..0] = \rFULLAdd #;
TIE_HIGH_SIGNAL1 = 1;
TIE_HIGH_SIGNAL2 = 1;
Q1[MaxData..0] = \rFULLData #;
OUTSIG = #;
}
}

February 2022 330 Product Version 21.11

write_cycle_A {
C {
all_inputs = \rFULLAdd N \rFULLAdd N rFULLData N 0N \r3 N \r3 N 0N 0N;
all_outputs = \rFULLData X \rFULLData X X;
}
V { CLK1 = P;
CEN1 = 0;
GWEN1 = 0;
TBISTE1 = 1;
WEN1[MaxData..0] = \rFULLData 0;
A1[MaxAdd..0] = \rFULLAdd #;
D1[MaxData..0] = \rFULLData #;
TIE_HIGH_SIGNAL1 = 1;
TIE_HIGH_SIGNAL2 = 1;
Q1[MaxData..0] = \rFULLData #;
OUTSIG = #;
}
}
bist_write_cycle_A {
W "_default_WFT_";
C {
all_inputs = \rFULLAdd N \rFULLData N 0N \r3 N \r3 N 0N 0N;
all_outputs = \rFULLData X \rFULLData X X;
}
V { CLK1 = P;
TCEN1 = 0;
TGWEN1 = 0;
TBISTE1 = 0;
TWEN1[MaxData..0] = \rFULLData 0;
TA1[MaxAdd..0] = \rFULLAdd #;
TD1[MaxData..0] = \rFULLData #;
TIE_HIGH_SIGNAL1 = 1;
TIE_HIGH_SIGNAL2 = 1;
Q1[MaxData..0] = \rFULLData #;
OUTSIG = #;
}
}
} // end Procedures Memory_access
Environment "MY2PortRAM_mbist" {
CTLMode MBIST {
TestMode Normal;
Internal {
Q1 [MaxData..0] { DataType TestData MemoryData; }
OUTSIG { DataType Functional; }
A1 [MaxAdd..0] { DataType TestData MemoryAddress; }
.....
} // end Internal
Relation {
Port 'A1[MaxAdd..0] + TA1[MaxAdd..0] +........
WriteEnableMap WEN1[0] 'D1[0] ';
WriteEnableMap WEN1[1] 'D1[1] ';
WriteEnableMap WEN1[2] 'D1[2] '
......
......
WriteEnableMap WEN2[63] 'D1[63] '
} // end Relation
MemoryPhysicalOrganization {
FunctionalConfigurationDefinition FCD1 {
NumberOfWords 512 ;
WordSize 64 ;

February 2022 331 Product Version 21.11

AddressSize 9 ;
ColumnAddress { ValueRange 0 7; AddressPartition A1[2..0] ;}
RowAddress { ValueRange 0 63 ; AddressPartition A1[8..3] ;}
}
ColumnMultiplexing 8 ;
BitDistribution 1 ;
ScrambleDefinition SDblk {
PhysicalColumnAddress[0] 'ColumnAddress[0]';
PhysicalColumnAddress[1] 'ColumnAddress[1]';
.....
.....
PhysicalRowAddress[0] '(RowAddress[1] ^ RowAddress[0])';
}
Relation {
ScrambleMap SDblk {Port 0; Port 1;}
FunctionalConfigurationMap FCD1 { Port 0 }
FunctionalConfigurationMap FCD2 { Port 1 }
}
} // end MemoryPhysicalOrganization
PatternInformation {
Procedure bist_read_cycle_A {
Purpose MemoryRead { Target MemoryTest; Port 0; }
}
......
.....
}
} // end PatternInformation

MemoryRepair {
RepairResource RRIO1 {
Type IO; Width 1;
DataRange { ValueRange 0 31; }
DataConnectivity {
CRAL[5..0] {
{DisableValue 0;}
{ RepairValue 1 ; AssociatedSignal {Data[0];} }
{ RepairValue 2 ; AssociatedSignal {Data[1];} }
.....
.....
{ RepairValue 32 ; AssociatedSignal {Data[63];} }
}
}
}
RepairResource RRrow1 {
Type Row;
Width 4;
RowAddressRange { ValueRange 0 63; }
EnableConnectivity {
RRE1{ { RepairValue 1; } }
}
AddressConnectivity {
RRA1[8..5] { RepairSignal A1[8..5]; }
}
}
} // end MemoryRepair
} // end CTLMode
} // end Environment

February 2022 332 Product Version 21.11

February 2022 333 Product Version 21.11

February 2022 334 Product Version 21.11

C
Glossary of PMBIST Terms

Term/Acronym Definition
Algorithm Fundamental write/read pattern to the memory for testing
BIRA Built-In Redundancy Analysis
BISR Built-In Self Repair
eFuse An electronic fuse macro that can be written (blown)/read on
and off the tester
EGA Enable Group Analysis
FT Fault Tolerant, only valid on ECC wrapped memories
Hard Repair A mechanism in which memory repair solution is retained in
non-volatile memory between design power cycles
LW Logical Memory Wrapper
MMST Mission-Mode Self-Test, test that are applied in time windows
of functional operation
NVM Non-Volatile Memory, basically same as eFuse
PMBIST Programmable Memory Built-In Self-Test
PMDA PMBIST Direct Access
POST Power-On Self-Test, test that are applied every time the
design is powered on
RA Redundancy Analysis
Soft Repair A mechanism in which memory repair solution is lost when the
design is powered off
SR Self Repair
ST Self Test

February 2022 335 Product Version 21.11

Testplan Wrapper around algorithms to vary back ground pattern,

address update and order

February 2022 336 Product Version 21.11

February 2022 337 Product Version 21.11

February 2022 338 Product Version 21.11

February 2022 339 Product Version 21.11

February 2022 340 Product Version 21.11

February 2022 341 Product Version 21.11

February 2022 342 Product Version 21.11

Index
B S
Boolean Equivalence 147 STA
Multi-Mode Multi-Corner Timimg 142
Static Timing Analysis 139
C module-level 139

commands
add_pmbist 63 U
configuration file for MBIST insertion
intrinsic read 225 using Modus
constraints online help 16
define_jtag_instruction 63
define_jtag_instruction_register 52, 57,
63
CTL Memory Model Skeleton 328
Custom Scheduling 110
customer service, contacting 18

F
flows
test with MBIST insertion 54, 60
test with MBIST insertion, preview 50

H
help, accessing 16

M
macro Group 257
MBIST logic insertion
configuration file 40
interpreting reports 68

P
PMBIST Architecture 23

February 2022 343 Product Version 21.11

Allegro PCB Editor User Guide 17.2-2016 S603 PDF
0% (1)
Allegro PCB Editor User Guide 17.2-2016 S603 PDF
339 pages
Difference Between General and Technical Communication
No ratings yet
Difference Between General and Technical Communication
7 pages
Assessing Affective Learning Outcomes
50% (2)
Assessing Affective Learning Outcomes
45 pages
Modus Ug Testvectors
No ratings yet
Modus Ug Testvectors
96 pages
Modus Ug Testmodes
No ratings yet
Modus Ug Testmodes
281 pages
Modus Ug Testmodes
No ratings yet
Modus Ug Testmodes
279 pages
SAP MM Interview Questions
100% (1)
SAP MM Interview Questions
11 pages
Advice From Finance Professionals
No ratings yet
Advice From Finance Professionals
177 pages
CoSM Vision Plan 2018 Small
No ratings yet
CoSM Vision Plan 2018 Small
64 pages
1651 Operators Handbook
100% (1)
1651 Operators Handbook
438 pages
Modus Ug Teststructures
No ratings yet
Modus Ug Teststructures
265 pages
Genus Lowpower
No ratings yet
Genus Lowpower
306 pages
10050-Sharing EDT Clock With Scan Clock
50% (2)
10050-Sharing EDT Clock With Scan Clock
10 pages
Chap 4
No ratings yet
Chap 4
23 pages
I Pai Wu - Determination of Peak Discharge and Design Hydrographs For Small Watersheds in Indiana
No ratings yet
I Pai Wu - Determination of Peak Discharge and Design Hydrographs For Small Watersheds in Indiana
135 pages
Communication
No ratings yet
Communication
33 pages
Voltus UG
No ratings yet
Voltus UG
758 pages
Genus Messages
No ratings yet
Genus Messages
2,933 pages
IMSO 19th Preparation Statement - Final
No ratings yet
IMSO 19th Preparation Statement - Final
1 page
Simulink Gui
No ratings yet
Simulink Gui
726 pages
Tempus Cui Ug
No ratings yet
Tempus Cui Ug
567 pages
2-5 Acceleration: Distance Above The Floor, Showing Its Position at Regular Time Intervals As It Falls
No ratings yet
2-5 Acceleration: Distance Above The Floor, Showing Its Position at Regular Time Intervals As It Falls
9 pages
Testing 2
No ratings yet
Testing 2
43 pages
ARS122 Engine Spare Part Catalogue PDF
100% (2)
ARS122 Engine Spare Part Catalogue PDF
134 pages
For Your Salvation
No ratings yet
For Your Salvation
455 pages
Ds4700 Determination Problem
No ratings yet
Ds4700 Determination Problem
242 pages
Apb SVT Uvm User Guide
No ratings yet
Apb SVT Uvm User Guide
60 pages
Cross Coverage
No ratings yet
Cross Coverage
31 pages
Amphion Standard Operator Guide
No ratings yet
Amphion Standard Operator Guide
362 pages
BK 9
No ratings yet
BK 9
137 pages
Modelsim User
No ratings yet
Modelsim User
820 pages
BM DS8910F Model 993rack Mounted Storage System
No ratings yet
BM DS8910F Model 993rack Mounted Storage System
58 pages
Grade 11 (Kinematics)
No ratings yet
Grade 11 (Kinematics)
27 pages
Pci 32 gsg260
No ratings yet
Pci 32 gsg260
34 pages
Project Object Elemenst 4.0
No ratings yet
Project Object Elemenst 4.0
580 pages
Operator's Handbook Alcatel 1661SM-C 2.5 Gbits Compact AddDrop Multiplexer
0% (1)
Operator's Handbook Alcatel 1661SM-C 2.5 Gbits Compact AddDrop Multiplexer
450 pages
PPC464-S IV Databook
No ratings yet
PPC464-S IV Databook
228 pages
Chap 9
No ratings yet
Chap 9
50 pages
PR 2 Group 3
No ratings yet
PR 2 Group 3
41 pages
Resume Columbia
No ratings yet
Resume Columbia
1 page
DFT Training Tracker Populated
No ratings yet
DFT Training Tracker Populated
2 pages
Eetop - CN Apb SVT Uvm User Guide
No ratings yet
Eetop - CN Apb SVT Uvm User Guide
61 pages
Fast Recompilation Application Note 1.0
No ratings yet
Fast Recompilation Application Note 1.0
17 pages
Done DFT
No ratings yet
Done DFT
95 pages
Energy Storage Targets 2030 and 2050 Full Report
No ratings yet
Energy Storage Targets 2030 and 2050 Full Report
36 pages
SW Cap
No ratings yet
SW Cap
19 pages
POINT I/O Very High-Speed Counter Modules: User Manual
No ratings yet
POINT I/O Very High-Speed Counter Modules: User Manual
46 pages
Cybersecurity Mesh
No ratings yet
Cybersecurity Mesh
12 pages
ME 142L Gear Pump Test Experimentmade
No ratings yet
ME 142L Gear Pump Test Experimentmade
8 pages
Shift Registors
No ratings yet
Shift Registors
7 pages
Group Assignment Guideline - HMO102.
No ratings yet
Group Assignment Guideline - HMO102.
8 pages
Apex Voltage To Current Conversion
No ratings yet
Apex Voltage To Current Conversion
4 pages
Routine EEE UG Spring2024
No ratings yet
Routine EEE UG Spring2024
41 pages
06 TM Test Compression
No ratings yet
06 TM Test Compression
7 pages
Micrologix 1400 Programmable Controllers: Instruction Set Reference Manual
No ratings yet
Micrologix 1400 Programmable Controllers: Instruction Set Reference Manual
658 pages
SDC File
No ratings yet
SDC File
2 pages
Modus Ug Pmbist
No ratings yet
Modus Ug Pmbist
261 pages
Chap 1
No ratings yet
Chap 1
15 pages
Img 20240313113733
No ratings yet
Img 20240313113733
154 pages
Crack Propagation in Ansys
100% (2)
Crack Propagation in Ansys
24 pages
UNIT 7 Reference Words
No ratings yet
UNIT 7 Reference Words
9 pages
Badger m2000 Hart Manual
No ratings yet
Badger m2000 Hart Manual
24 pages
Bateni 2014
No ratings yet
Bateni 2014
9 pages
1651 Operators Handbook PDF
No ratings yet
1651 Operators Handbook PDF
438 pages
Questa Sim User PDF
No ratings yet
Questa Sim User PDF
1,978 pages
Power Windows Description and Operation
No ratings yet
Power Windows Description and Operation
4 pages
Proces Rm014 en P
No ratings yet
Proces Rm014 en P
574 pages
E FUSE
No ratings yet
E FUSE
2 pages
Verification Plan
No ratings yet
Verification Plan
2 pages
Alaris Medley Model 8000 Version 7
No ratings yet
Alaris Medley Model 8000 Version 7
46 pages
Kolibri
No ratings yet
Kolibri
104 pages
On Linear Diophantine Equation Dr. D. Ramprasad
No ratings yet
On Linear Diophantine Equation Dr. D. Ramprasad
2 pages
Etw9b 3
No ratings yet
Etw9b 3
4 pages
AviMet LLWAS Maintenance Manual
No ratings yet
AviMet LLWAS Maintenance Manual
152 pages
Eetop - CN Atb SVT Uvm User Guide
No ratings yet
Eetop - CN Atb SVT Uvm User Guide
61 pages
Soft Error Mitigation Controller v4.1
No ratings yet
Soft Error Mitigation Controller v4.1
125 pages
Twido Programmable Controllers: Software Reference Guide
No ratings yet
Twido Programmable Controllers: Software Reference Guide
636 pages
Apollo Cost Analysis
No ratings yet
Apollo Cost Analysis
6 pages
MAG-AS-01087-EN - M2000 Modbus Memory Map
No ratings yet
MAG-AS-01087-EN - M2000 Modbus Memory Map
28 pages
MDX Ii
No ratings yet
MDX Ii
249 pages
En ACS850 Control Panel UG A
No ratings yet
En ACS850 Control Panel UG A
48 pages
Cadence Design With RTL Compiler Physical PDF
No ratings yet
Cadence Design With RTL Compiler Physical PDF
108 pages
GFK 1918S PDF
No ratings yet
GFK 1918S PDF
178 pages
User Guide Molecular Diagnostic Software
No ratings yet
User Guide Molecular Diagnostic Software
71 pages
33003788K01000 PDF
No ratings yet
33003788K01000 PDF
472 pages
Troubleshooting Guide
No ratings yet
Troubleshooting Guide
118 pages
Manual Proficy
No ratings yet
Manual Proficy
178 pages
Badger Meter M2000 Profibus DP Manual
No ratings yet
Badger Meter M2000 Profibus DP Manual
20 pages
M221 Programming Guide - EIO0000001360.03 PDF
No ratings yet
M221 Programming Guide - EIO0000001360.03 PDF
180 pages
Violin Memory Array Software Configuration Guide R3.4
No ratings yet
Violin Memory Array Software Configuration Guide R3.4
163 pages
Hspice Integ
No ratings yet
Hspice Integ
440 pages
Uart Core With Apb
No ratings yet
Uart Core With Apb
31 pages
Hart Protocol User Manual: For Use With Procomm Converter
No ratings yet
Hart Protocol User Manual: For Use With Procomm Converter
15 pages
Tsunami A2MP-81XX-CPE - ReferenceManualv2.2 - SWv2.3.5
No ratings yet
Tsunami A2MP-81XX-CPE - ReferenceManualv2.2 - SWv2.3.5
88 pages
Proficy - Logic Developer - PLC 7.0 Getting Started, GFK-1918P
No ratings yet
Proficy - Logic Developer - PLC 7.0 Getting Started, GFK-1918P
176 pages
TSX Quantum 140 ERT 854 10 Manual Eng
No ratings yet
TSX Quantum 140 ERT 854 10 Manual Eng
116 pages
Cds 1 Phase Submersible Dewatering Pumpset Compressed
No ratings yet
Cds 1 Phase Submersible Dewatering Pumpset Compressed
2 pages
File 2025 07 07T06 39 07 735Z
No ratings yet
File 2025 07 07T06 39 07 735Z
3 pages
Evolution MK 461C
No ratings yet
Evolution MK 461C
20 pages
Et Ug Pmbist
No ratings yet
Et Ug Pmbist
40 pages
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
From Everand
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
Michael Basler
No ratings yet
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
1/5 (1)
Content Creation Revolution with chatGPT
From Everand
Content Creation Revolution with chatGPT
Maria Cowen
No ratings yet
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet