SIEMENS EDA

MBISTArchitect™
Reference Manual
Software Version 2021.2 and Later
Unpublished work. © 2021 Siemens

This material contains trade secrets or otherwise confidential information owned by Siemens Industry Software, Inc.,
its subsidiaries or its affiliates (collectively, "Siemens"), or its licensors. Access to and use of this information is
strictly limited as set forth in Customer's applicable agreement with Siemens. This material may not be copied,
distributed, or otherwise disclosed outside of Customer's facilities without the express written permission of
Siemens, and may not be used in any way not expressly authorized by Siemens.

This document is for information and instruction purposes. Siemens reserves the right to make changes in
specifications and other information contained in this publication without prior notice, and the reader should, in all
cases, consult Siemens to determine whether any changes have been made. Siemens disclaims all warranties with
respect to this document including, without limitation, the implied warranties of merchantability, fitness for a
particular purpose, and non-infringement of intellectual property.

The terms and conditions governing the sale and licensing of Siemens products are set forth in written agreements
between Siemens and its customers. Siemens' End User License Agreement may be viewed at:
www.plm.automation.siemens.com/global/en/legal/online-terms/index.html.

No representation or other affirmation of fact contained in this publication shall be deemed to be a warranty or give
rise to any liability of Siemens whatsoever.

TRADEMARKS: The trademarks, logos, and service marks ("Marks") used herein are the property of Siemens or
other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the owner of
the Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a source of a
product, but is intended to indicate a product from, or associated with, a particular third party. A list of Siemens'
trademarks may be viewed at: www.plm.automation.siemens.com/global/en/legal/trademarks.html. The registered
trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the
mark on a world-wide basis.

Support Center: support.sw.siemens.com

Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form
 Table of Contents

Chapter 1
Command Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Command Line Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
User-Defined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Add Bisa Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Add Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Add Concurrent Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Add Control Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Add Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Add Data Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Add Diagnostic Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Add Existing Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Add Mbist Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Add Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Add New Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Add New Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Add Pattern Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Add Pin Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Add Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Add Signal Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Add Verilog Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Add Vhdl Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Delete Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Delete Bisa Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Delete Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Delete Concurrent Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Delete Control Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Delete Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Delete Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Delete Controllers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Delete Data Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Delete Diagnostic Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Delete Mbist Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Delete Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Delete New Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Delete Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Delete Pattern Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Delete Pin Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Delete Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Delete Signal Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

MBISTArchitect™ Reference Manual, v2021.2 and Later 3

 Table of Contents

Delete Verilog Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Delete Vhdl Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Echo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Insert Bist Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Integrate Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Load Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Load Controller Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Load Design Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Load Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Load Procedure File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Printenv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Report Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Report Algorithm Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Report Bisa Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Report Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Report Concurrent Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Report Control Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Report Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Report Controllers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Report Controllers Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Report Data Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Report Design Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Report Diagnostic Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Report Drc Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Report Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Report Mbist Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Report Memory Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Report Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Report Misr Polynomial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Report New Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Report Pattern Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Report Pin Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Report Pin Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Report Pin Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Report Pipeline Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Report Signal Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Report Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Report Verilog Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Report Version Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Report Vhdl Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Reset State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Save Access File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Save Bist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Save Controllers Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

4 MBISTArchitect™ Reference Manual, v2021.2 and Later

Table of Contents

Save Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Save Driver Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Save History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Save Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Set Bist Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Set Bsdarchitect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Set Clock Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Set Comparator Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Set Controller Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Set Controller Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Set Controller Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Set Design Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Set Dofile Abort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Set Drc Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Set Message Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Set Pin Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Set Scan Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Set System Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Set Vhdl Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Setup Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Setup Clock Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Setup Comparator Failflag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Setup Controller Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Setup Controller Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Setup Design Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Setup Diagnostic Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Setup File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Setup Full_speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Setup Mbist Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Setup Mbist Compressor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Setup Memory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Setup Memory Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Setup Memory Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Setup Misr Polynomial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Setup Observation Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Setup Pipeline Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Setup Reset Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Setup Retention Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Write Block Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Chapter 2
Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Shell Command Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
mbistarchitect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Index
Third-Party Information

MBISTArchitect™ Reference Manual, v2021.2 and Later 5

 Table of Contents

6 MBISTArchitect™ Reference Manual, v2021.2 and Later

 List of Figures

Figure 1-1. Default Signal Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Figure 1-2. Additional Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 1-3. Control Logic Added to Active-Low Signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 1-4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 1-5. Control Logic Added to Active-High Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 1-6. rst_l synchronization logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 1-7. Logic Inserted Using Set Clock Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Figure 1-8. Using Set Scan Logic -NoScan -Reset -Control . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 1-9. RAM 4x4 with Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Figure 1-10. Default Memory Bypass Circuitry Example. . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Figure 1-11. Using Set Scan Logic -Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Figure 1-12. Using Set Scan Logic -Combinational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Figure 1-13. Compressor Downstream from the Memory . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Figure 1-14. BIST Architecture With a Compressor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Figure 1-15. Setup Memory Clock -System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Figure 1-16. Setup Memory Clock -Test NoInvert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Figure 1-17. Setup Memory Clock -Test Invert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Figure 1-18. LFSR MISR Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Figure 1-19. Pipelining Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Figure 1-20. Default Reset Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure 1-21. Reset Behavior with Three-Cycle Duration . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Figure 1-22. Reset Behavior with Three-Cycle Duration and test_h Delay . . . . . . . . . . . . . 250

MBISTArchitect™ Reference Manual, v2021.2 and Later 7

 List of Figures

8 MBISTArchitect™ Reference Manual, v2021.2 and Later

 List of Tables

Table 1-1. Conventions for Command Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Table 1-2. Truth Table for Active-Low Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 1-3. Truth Table for Active-High Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 1-4. Generated Pin Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Table 1-5. Pins on the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Table 1-6. Functionality of the Various Switch Combinations . . . . . . . . . . . . . . . . . . . . . . 209
Table 1-7. Output File Default Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Table 1-8. Compressor Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Table 2-1. Conventions for Shell Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

MBISTArchitect™ Reference Manual, v2021.2 and Later 9

 List of Tables

10 MBISTArchitect™ Reference Manual, v2021.2 and Later

 Chapter 1
Command Dictionary

This chapter contains descriptions of MBISTArchitect™ commands. For quick reference, the
commands appear alphabetically, with each command beginning on a separate page.
Command Line Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
User-Defined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Command Line Syntax Conventions

This manual uses the following command usage line syntax conventions:

Table 1-1. Conventions for Command Line Syntax

Convention Example Usage
UPPercase REPort ENvironment Required command letters are in uppercase; in
most cases, you may omit lowercase letters when
entering commands or literal arguments and you
need not enter in uppercase. Command names
and options are normally case insensitive.
Commands usually follow the 3-2-1 rule: the first
three letters of the first word, the first two letters
of the second word, and the first letter of the
third, fourth, etc. words.
Boldface ADD BIsa Hardware A boldface font indicates a required argument.
-COLumn
[ ] EXIt [-Force] Square brackets enclose optional arguments. Do
not enter the brackets.
Italic DOFile filename An italic font indicates a user-supplied argument.
{ } SAVe BIst { -VErilog | Braces enclose arguments to show grouping. Do
-VHdl } [-Fileprefix not enter the braces.
file_prefix ]
| DELete MEmory Model The vertical bar indicates an either/or choice
memory_name | -All between items. Do not include the bar in the
command.
Underline SET DOfile Abort ON | OFf An underlined item indicates either the default
argument or the default value of an argument.

MBISTArchitect™ Reference Manual, v2021.2 and Later 11

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
User-Defined Variables

Table 1-1. Conventions for Command Line Syntax (cont.)

Convention Example Usage
… ADD DAta Background An ellipsis follows an argument that may appear
background_pattern… more than once. Do not include the ellipsis when
entering commands.

User-Defined Variables
You can utilize user-defined variables and values on the command line, or within dofiles. You
can define, reference, and report on user-defined variables in the following manner:
• Defining
Use the following syntax to create and set a variable’s value. Define variables from the
tool’s command line, throughout a dofile, or from a startup file. Variable names are case
sensitive. After a variable is defined, you can reference it; see Referencing.
$variable = value
• Referencing
To refer to a variable causes its value to be substituted into a command. Multiple
variable references are allowed per tool command. You must define variables before
they are referenced. Multiple references are allowed in a single command. A reference
to an undefined variable results in a syntax error. You can overwrite a variable value by
redefining that variable.
• Reporting
Use the Report Variables command to display user-defined variables and values. The
Report Variables command displays variables previously defined and their
corresponding values. This reported list does not include environment variables defined
in the shell environment.
• Concatenating
If a variable is meant to be concatenated with any other string, it must be referenced as
${variable}, as in the following example:
$path = /U1/U2add new controller ${path}/cntr_inst -dofile bistgen.do mem1 ${path}/
U3/mem2
If a variable is not meant to be concatenated with any other string, it can be referenced as
$variable without the curly braces.

12 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
User-Defined Variables

Note
Variables are not expanded if there has been no definition. This condition behaves
like any other syntax error that might be present on the command line, or within a
dofile.

MBISTArchitect™ Reference Manual, v2021.2 and Later 13

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Command Descriptions

Command Descriptions
The remaining pages in this chapter describe the commands used in MBISTArchitect in detail.
The table provides a quick reference for MBISTArchitect commands. For more details on any
command, see the full command description.

Command Description

Add Bisa Hardware Generates BISA (Built-In Self-repair Analysis) logic within the
BIST controller to support repair strategies. BISA is additional
logic that examines detected errors and calculates the data
needed to effect a repair strategy.
Add Clocks Defines a signal as a system clock. The clock can be located at
the top level or within the design hierarchy, such as a PLL
clock.
Add Concurrent Group Specifies which controllers are to be grouped together in a
group that you specify for concurrent testing.
Add Control Background Associates a set of write enable masking patterns to a write
enable signal for a particular algorithm.
Add Control Logic Adds control logic to prevent memory corruption during a scan
shift.
Add Data Backgrounds Specifies one or more test patterns (test pattern data values) that
are other than all 0s and 1s, for all memory ports that use the
background data source testing algorithms.
Add Diagnostic Monitor Controls the set of items observed by the diagnostic module and
allows data items to be added to the observation set.
Add Existing Controller Declares a memory BIST controller which was generated in a
previous invocation of the tool, and schedules it for insertion in
this invocation.
Add Mbist Algorithms Adds one or more algorithms for BIST.
Add Memory Models Adds one or more memories to the set being tested by the BIST
controller currently being configured for generation.
Add New Controller Generates a BIST controller and one or more memory collars.
Add New Port Creates the specified port on the top level using the port name
and port direction you specify.
Add Pattern Translation Specifies the controllers for which pattern translation will be
performed at the next Integrate Patterns command.
Add Pin Mapping Maps a specified controller, collar, or block pin to a pin at the
top-level or to an internal pin.

14 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Command Descriptions

Command Description
Add Pin Sharing Maps the specified pin types to a single top-level or internal pin.
Add Signal Synchronization Adds the necessary logic into the BIST controller for
synchronization.
Add Verilog Include Causes the given file names to be included by the generated
BIST controller Verilog HDL.
Add Vhdl Library Adds a specified VHDL library clause and optionally use
clauses to the <model>_bist.vhd file.
Alias Specifies the shorthand name for a tool command, UNIX
command, or existing command alias, or any combination.
Delete Algorithms Removes from the current session any user defined algorithm
that you have previously loaded using the Load Algorithms
command.
Delete Bisa Hardware Deletes BISA logic from the memories and BIST module.
Delete Clocks Removes the clock identity previously defined by the Add
Clocks command from the specified signals.
Delete Concurrent Group Removes the specified controller group.
Delete Control Background Removes the specified control background.
Delete Control Logic Removes the specified control logic.
Delete Controller Deletes a specific memory BIST controller.
Delete Controllers Removes the controller description information that was loaded
Description through the Load Controller Description command.
Delete Data Backgrounds Deletes the specified data background patterns from the setup
configuration that were added using the Add Data Backgrounds
command.
Delete Diagnostic Monitor Deletes data items from the diagnostic module observation set.
Delete Mbist Algorithms Deletes one or more MBIST algorithms from the setup
configuration.
Delete Memory Models Deletes a memory models from the setup configuration that
were added using the Add Memory Modules command.
Delete New Port Deletes the specified port(s) created using the Add New Port
command.
Delete Patterns Deletes all of the translated (integrated) patterns in memory,
and sets the pattern set to empty.
Delete Pattern Translation Deletes all scheduled and all translated patterns. Removes
specified controller instances from the list of controllers to
translate patterns.

MBISTArchitect™ Reference Manual, v2021.2 and Later 15

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Command Descriptions

Command Description
Delete Pin Mapping Deletes all pins that were specified (added) through the Add Pin
Mapping command.
Delete Pin Sharing Deletes the pin type that was specified (added) by the Add Pin
Sharing command.
Delete Signal Deletes the signal out of the list to be synchronized in the BIST
Synchronization controller.
Delete Verilog Include Deletes all or some of the Verilog ‘include directives previously
specified by the command Add Verilog Include.
Delete Vhdl Library Removes either a specified VHDL library clause or a specific
use clause expression from the VHDL code structure, and lets
you remove the compiled package of an addressing
incrementing function.
Dofile Sequentially executes the commands that reside in a specified
file.
Echo Issues a user-defined string to the transcript or to a pathname, if
you use one of the file redirection operators.
Exit Terminates the application tool program and terminates the
BIST session, and returns control to the operating system.
Help Displays the syntax for the specified command and provides
quick access to information about a specific command.
History Displays a list of previously executed commands.
Insert Bist Logic Inserts the BIST access logic, mainly controllers, into the
specified locations.
Integrate Patterns Performs ATPG pattern translation and integration for the
controllers specified with the Add Pattern Translation
command.
Load Algorithms Loads user-defined algorithm from the specified files, and
makes these algorithms available for use within the current
BIST controller generation session.
Load Controller Description Loads the specified controller description files that were written
in the proprietary Siemens EDA CTDF (Controller Test
Description File) format.
Load Design Objects Loads the files that contain the RTL description of the
controllers and their associated collars.
Load Library Loads specific DFT MBIST library files that contain the
memory models.
Load Procedure File Loads a test_setup and/or a clock_run procedure file.

16 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Command Descriptions

Command Description
Printenv Prints out the values of the UNIX environmental variables.
Report Algorithms Generates a report that shows the pre-defined and user-defined
algorithms that have been loaded.
Report Algorithm Steps Generates a report that describes the number of clock cycles
used by each algorithm step and allows you to determine the
memory test time and the point at which retention delays need
to occur.
Report Bisa Hardware Generates a report of the Built-In Self-repair Analysis logic
repair status for all memories.
Report Clocks Reports the clock signals previously defined using the Add
Clocks and Delete Clocks commands.
Report Concurrent Group Generates a report on information about all controller groups,
including which controllers are grouped together and if they are
to be tested sequentially or individually.
Report Control Background Generates a report on information about the control background
added using the Add Control Background command.
Report Control Logic Generates a report on information about control logic added
using the Add Control Logic command.
Report Controllers Generates a report on the insertion of the specified memory
BIST controller.
Report Controllers Generates a report on information about controllers.
Description
Report Data Backgrounds Generates a list of the data background patterns you added with
the Add Data Backgrounds command.
Report Design Name Legal Modes: BISTGEN.
Report Diagnostic Monitor Generates a report on the data items from the scanned output of
the diagnostic observation set.
Report Drc Rules Generates a report of either specified rules or all rules for
Design Rule Checking.
Report Environment Generates a report on the current values of all the “set”
commands and the default names of the scan-type pins.
Report Mbist Algorithms Generates a list of currently assigned algorithms and their
corresponding ports.
Report Memory Instances Generates a report on the memory instances in the design and
their associated information.
Report Memory Models Generates a list of available or added memory models.

MBISTArchitect™ Reference Manual, v2021.2 and Later 17

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Command Descriptions

Command Description
Report Misr Polynomial Generates a report on the taps that will be used for the specified
size MISR polynomial.
Report New Port Generates a report on the list of ports created using the Add
New Port command.
Report Pattern Translation Generates a report on the list of controllers to be translated
during the next Run command.
Report Pin Mapping Generates a report on all pins that were specified through the
Add Pin Mapping command.
Report Pin Name Generates a report on the pin type and its current name of top-
level pins.
Report Pin Sharing Generates a report on information about which pin types are
sharing a single pin at SoC.
Report Pipeline Registers Generates a report on the information about your pipeline
register setup.
Report Signal Legal Modes: BISTGEN
Synchronization
Report Variables Generates a report on the user-defined variables and values.
Report Verilog Include Generates a report on the Verilog ‘include directives previously
specified by the command Add Verilog Include.
Report Version Data Generates a report on the MBISTArchitect software version
number.
Report Vhdl Settings Generates a report on all of the user specified VHDL libraries
and uses.
Reset State Eliminates the effects of commands issued since tool
invocation.
Run Instructs the tool to generate BIST logic and other test logic for
the controller memory or design, based on your setup
configuration.
Save Access File Saves the controller access file generated in the BIST Mode of
the Insertion Phase to a file you specify.
Save Bist Saves the BIST output files in the specified format.
Save Controllers Mapping Use to create a mapping file.
Save Design Saves the inserted BIST logic and original design to new files.
Save Driver Files Exports dofiles for gate-level verification, boundary scan
insertion, and logic synthesis.

18 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Command Descriptions

Command Description
Save History Saves the command line history file of previously executed
commands to the specified file.
Save Patterns Saves the “in memory” patterns to the specified file.
Set Bist Insertion Determines whether BIST insertion driver information is
produced.
Set Bsdarchitect Use this command if you intend to insert boundary scan logic
with BSDArchitect™ following BIST insertion.
Set Clock Gating Instructs the tool to insert clock gating logic on the bist_clk
input of the bist controller.
Set Comparator Test Defines comparator test states and instructs the tool whether to
include comparator test states in the finite state machine of the
controller.
Set Controller Debug Instructs the tool to generate a diagnostics engine inside the
controller.
Set Controller Delay Sets delays on the output signals from the BIST controller.
Set Controller Hold Causes a hold bit (hold_l) to be created that stops testing.
Set Design Name Changes the names for the modules/entities, instances, or
architectures generated by the tool.
Set Dofile Abort Specifies whether the tool stops or continues dofile execution if
an error condition is detected.
Set Drc Handling Specifies how the tool handles design rule violations and directs
the design rules checker to check your input against expected or
required values.
Set Message Handling Sets up a logfile for a BIST session.
Set Pin Name Changes the top-level pin names.
Set Scan Logic Instructs the tool to create a bypass circuitry to bypass the
memory during ATPG mode in order to test the logic
surrounding the memory.
Set System Mode Changes the system mode of the tool between Setup and either
Integration or BIST Insertion mode, depending on the current
phase.
Set Vhdl Description Determines whether the tool writes VHDL configuration
statements in the controller and connection files.
Setup Algorithm Selection Enables or disables support for runtime programmable online
algorithm selection.
Setup Clock Period Defines the controller clock period.

MBISTArchitect™ Reference Manual, v2021.2 and Later 19

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Command Descriptions

Command Description
Setup Comparator Failflag Defines how fail bits will be output during memory testing.
Setup Controller Clock Defines whether the controller clock is set to a positive or
negative edge.
Setup Controller Reset Defines how the BIST controller is reset with the rst_l signal
reset in either an asynchronous or synchronous mode.
Setup Design Sharing Sets the ability to share BIST memory collars within the same
controller.
Setup Diagnostic Clock Selects the clock used to shift out the diagnostic data.
Setup File Naming Explicitly defines the filenames for one or more of any of the
saved output file.
Setup Full_speed Sets the function of full-speed automatic BIST conversion to
either on or off.
Setup Mbist Algorithms Specifies the default BIST algorithms to be used by all
controllers on all memories.
Setup Mbist Compressor Instructs the tool to implement a BIST configuration that uses a
compressor (also called a Multiple Input Signature Register, or
MISR) to capture the output of the ROM under test.
Setup Memory Access Enables and disables simultaneous read access of multiple port
memories.
Setup Memory Clock Defines the memory clock settings and specifies whether the
clock is connected to the memories’ system clock.
Setup Memory Test Defines the testing method of the BIST controller.
Setup Misr Polynomial Defines the size and tap locations of a custom MISR
polynomial.
Setup Observation Scheme Defines the observation scheme of the BIST controller.
Setup Pipeline Registers Adds pipeline stages to meet timing requirements for high-
speed testing.
Setup Reset Duration Defines the BIST controller reset behavior for the test bench.
Setup Retention Cycles Defines the delay value used in a WGL, Verilog, VHDL, or
simulation testbench when waiting to assert the resume signal to
continue the BIST session following a retention test
synchronization delay.
System Passes the specified command to the operating system for
execution.
Write Block Description Writes out a block description in a specified file of which the
contents are similar to the contents of a CTDF.

20 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Bisa Hardware

Add Bisa Hardware

Legal Modes: BISTGEN
Prerequisites: Repairable memories must have been added.
Generates BISA (Built-In Self-repair Analysis) logic within the BIST controller to support
repair strategies. BISA is additional logic that examines detected errors and calculates the data
needed to effect a repair strategy.
Usage
ADD BIsa Hardware {{-COLumn nredundant [ -Format Bits | Index ]} |
{-ROW nredundant}} [ -All | -MEMids list… ]
Description
Generates BISA (Built-In Self-repair Analysis) logic within the BIST controller to support
repair strategies. BISA is additional logic that examines detected errors and calculates the data
needed to effect a repair strategy. It determines whether the errors can be masked by activating
the planned repair strategy. The repair information is reported at the end of BIST testing. The
BISA logic does not repair the memory.

If your memories do not have repair strategies, you can still report failure data using
diagnostics. For more information, see the Set Controller Debug command.

For more information on setting up BISA, see “BISA for Repair” in the MBISTArchitect
Process Guide.

Arguments
• -COLumn nredundant
A required switch and integer pair that specifies a column repair strategy and the number of
redundant columns available.
• -Format Bits | Index
An optional switch and literal pair that specifies the format of the column repair vector in
the BISA report. This switch is not for use with row repair strategies.
Bits
The size of a bit-formatted vector is equal to the memory data width. The report
indicates the failing column with a 1 in the corresponding bit position. For example,
an 8-bit wide memory with a failure in column 3 is reported as 00001000.
Index
The size of an index-formatted vector is equal to log2(memory data width). The report
indicates the failing column with the binary number corresponding to the column
index. For example, a failure in column 3 is reported as 11. Using this format makes
the BISA report smaller.

MBISTArchitect™ Reference Manual, v2021.2 and Later 21

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Bisa Hardware

• -ROW nredundant
A required switch and integer pair that specifies a row repair strategy and the number of
redundant rows available.
• -All
An optional switch that implements the specified strategy for all loaded memories. This is
the default. Do not use this switch if some of the added memories are not repairable.
Note
If you are using the old command syntax, MBISTArchitect generates BISA logic
and necessary signals for each memory that has a repair strategy defined in the
library. For information on using the old syntax, see column repair “Method 2” in the
MBISTArchitect Process Guide.

• -MEMids list…
An optional switch and integer list that designates the memory or memories for BISA
generation. Use the 0-based memory id number to specify each memory.
Examples
The following example adds BISA logic for two memories with different row repair strategies.
MemA has one redundant row, and memB has two redundant rows:

add memory model memA memB

add bisa hardware -row 1 -memids 0
add bisa hardware -row 2 -memids 1
report bisa hardware

The following example adds BISA logic for all memories with column repair strategies:

add bisa hardware -column -format index

Related Topics
Delete Bisa Hardware
Report Bisa Hardware

22 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Clocks

Add Clocks
Legal Modes: SETUP of the BIST Insertion Phase
Prerequisites: If you are defining a top-level clock, the top-level pin must either exist in the
design or be created using the Add New Port command.
Defines a signal as a system clock. The clock can be located at the top level or within the design
hierarchy, such as a PLL clock.
Usage
ADD CLocks { off_state clock_path_name }...
Description
Defines a signal as a system clock. The clock can be located at the top level or within the design
hierarchy, such as a PLL clock. After the clock signal is defined, you can map it to any of the
MBIST related clocks (bist_clk, diag_clk, misr_clk, etc.) using the Add Pin Mapping or Add
Pin Sharing command.

If you are defining a PLL clock, load a clock_run procedure using the Load Procedure File
command.

The Add Clocks command only defines the clock signal for use with other commands. It does
not make any connections in your design.

Arguments
• off_state
A required binary digit describing the off state of the clock. This can be either 0 or 1.
• clock_path_name
A required string that specifies the location of the clock signal.
Examples
Example 1
The following example defines a PLL clock with an off_state equal to 1:

add clocks 1 PLL/pll_clk

Example 2
The following example creates a new top-level pin, defines it as a clock signal with an off_state
of 0, and connects it to the bist_clk for all controllers:

add new port my_system_clk -direction in

add clocks 0 my_system_clk
add pin sharing bist_clk my_system_clk

MBISTArchitect™ Reference Manual, v2021.2 and Later 23

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Clocks

Related Topics
Add New Port
Add Pattern Translation
Add Pin Mapping
Add Pin Sharing
Delete Clocks
Load Procedure File
Report Clocks

24 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Concurrent Group

Add Concurrent Group

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Specifies which controllers are to be grouped together in a group that you specify for concurrent
testing.
Usage
ADD COncurrent Group group_name { controller_instance_pathname... | -All }
Description
Specifies which controllers are to be grouped together in a group that you specify for concurrent
testing. This allows the tool to run all controllers in the group concurrently. Once you create a
controller group, you still have the ability to select and run tests for an individual controller.
You can have the same controller in multiple groups. A controller group must include more than
one controller.

Arguments
• group_name
A required string that specifies the name of the group into which controllers are to be added.
• controller_instance_pathname
A required repeatable string that specifies the controller or memory collar instance(s) that is
to be added to the specified group_name.
• -All
A required literal that specifies for the tool to add all controllers to the specified group.
Examples
The following example groups all controllers into the specified group name, all controllers:

add concurrent group allcontrollers -all

Related Topics
Add New Controller
Delete Concurrent Group
Add Pin Mapping
Report Concurrent Group

MBISTArchitect™ Reference Manual, v2021.2 and Later 25

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Control Background

Add Control Background

Legal Modes: BISTGEN
Prerequisites: The memory model and user-defined algorithm must be added.
Associates a set of write enable masking patterns to a write enable signal for a particular
algorithm.
Usage
ADD COntrol Background algorithm memory_name/port_name {patterns…}
Description
Associates a set of write enable masking patterns to a write enable signal for a particular
algorithm.

The controller repeats the specified algorithm for each added pattern. If you specify a different
number of patterns per memory for a single algorithm, the controller repeats the algorithm for
the maximum number of patterns for all memories. For example, if you add four patterns to
memory1 and two patterns to memory2 for a mask algorithm, the controller applies the mask
algorithm four times to both memories. For the two additional algorithm iterations for
memory2, the controller applies an all-active pattern. This behavior applies to both sequential
and concurrent testing.

Arguments
• algorithm
A required string that specifies the name of the algorithm to which the write enable mask
patterns apply. The specified algorithm must contain the mask keyword to use the write
enable mask patterns. For more information, see “Setting Up The Write Enable Mask UDA
Part” in the MBISTArchitect Process Guide.
• memory_name/port_name
A required string that specifies the name of the write enable signal and memory to which the
patterns apply. The write enable signal must be mapped to a data bus using the
write_enable_map keyword in the memory model. For more information, see “Write Enable
Mapping” in the MBISTArchitect Process Guide.
• patterns
A required list of patterns to apply to the specified write enable signal. The controller
applies the patterns in the order specified. The list of patterns can be a combination of the
following:
o number — A numerical pattern is specified using either binary (11111110) or
hexadecimal (xFE) format. The width of the pattern should equal the width of the
write enable signal. If you have write enable signals of different widths, specify the
pattern for the widest signal. The pattern will be truncated for the smaller signals.

26 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Control Background

o walking0 — This literal is expanded into N patterns, where N is the width of the
control signal. For a 4-bit control signal, this would be expanded into 0001, 0010,
0100, and 1000.
o walking1 — This literal is expanded into N patterns, where N is the width of the
control signal. For a 4-bit control signal, this would be expanded into 1110, 1101,
1011, and 0111.
o checkerboard — This literal is expanded into two patterns: 1010… and 0101…,
where the length of the pattern matches the width of the control signal.
Examples
The following example adds eight patterns to RAM32x8/WEN, while only four patterns to
RAM32x4/WEN. The write_mask algorithm will be applied eight times to both memories.

add control background write_mask RAM32x8/WEN xFE xFD xFB xF7 xEF xDF xBF xB7
add control background write_mask RAM32x4/WEN 1110 1101 1011 0111

The following example adds control backgrounds using a mix of pattern formats:

add control background write_mask RAM32x8/WEN xFE 11111010

Related Topics
Delete Control Background
Report Control Background

MBISTArchitect™ Reference Manual, v2021.2 and Later 27

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Control Logic

Add Control Logic

Legal Modes: BISTGEN
Prerequisites: None
Adds control logic to prevent memory corruption during a scan shift.
Usage
ADD COntrol Logic { memory_name/port_name... [ -Active High | Low ] }
{-External_control_signal ext_ctrl_sig [ -Active High | Low] }
Description
Adds control logic to prevent memory corruption during a scan shift. This control logic forces
the memory to a known state that disables either the memory or the specified memory control
signals during scan shift mode. The memory is placed in a safe access state so the memory
operation does not interfere with the scan test process and vice-versa.

By default, for each memory control signal, MBISTArchitect adds a mux and a duplicate test
signal to control the memory during BIST. Figure 1-1 shows the mux for the write_enable
signal. For a BIST-ready memory, these muxes already exist in the memory model.

Figure 1-1. Default Signal Control

The test_h signal determines the mode of operation for the memory and the source of the control
signal. When test_h is low (0), the memory is operating in functional mode and the system path
(write_enable) is selected.When test_h is high (1), the memory is operating in BIST mode and
receives signals from the BIST controller (test_write_enable).

If your design includes scan logic for testing, the test_h signal may also be used to activate the
scan testing mode. Because test_h will simultaneously activate the BIST controller and the
memories, additional logic is required to prevent interaction between scan logic and the
memories. Figure 1-2 shows the additional signal and gates created by the Add Control Logic
command.

28 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Control Logic

Figure 1-2. Additional Control Logic

This logic creates an additional state to differentiate memory behavior during BIST testing and
scan testing. The gates inserted depend on the active behavior of the control signal. The control
logic functions such that during scan testing (test_h high) the write_enable signal, or other
memory control signal, can be set to the inactive value using the external_control, which is
connected at the top-level. See the examples at the end of this section for specific cases.

Arguments
• memory_name/port_name
A required, repeatable string that specifies the unique memory port for which you want to
add control logic. The following port types are available for control logic: write_enable,
read_enable, chip_enable, output_enable, and control. You must specify the port name
exactly as it is declared in the BIST definition library.
Note
For BIST ready memories, which already contain muxes and test signal ports, you
must specify the test signal port (driven by the BIST controller) for the port_name.
In Figure 1-1, this is the test_write_enable signal. If you specify the system signal
(write_enable), you will be controlling the system signal during test instead of the BIST
signal.

• -Active High | Low

An optional switch and literal pair that specifies the active state of the control signal. If the
-Active switch is not specified, the tool derives the active state from the BIST definition in
the ATPG library file.
• -External_control_signal ext_ctrl_sig
A required switch and string pair that specifies the name of the external control signal. If the
port does not exist, a new port is created at the top level.
• -Active High | Low
An optional switch and literal pair that specifies the active state of the external control
signal. The default value is low.

MBISTArchitect™ Reference Manual, v2021.2 and Later 29

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Control Logic

Examples
Example 1
In this example, suppose there is an active-low memory control signal ram_ctrl that disables the
memory when asserted high. During scan shift mode, the memory must be disabled; ram_ctrl
must be 1. Use the following command during BISTGEN to set up the control logic:

add control logic memory1/ram_ctrl -active low -external_control_signal x_control

Figure 1-3 illustrates the logic implemented by the above command. The truth table for this
logic is shown in Table 1-2.

Figure 1-3. Control Logic Added to Active-Low Signal

Table 1-2. Truth Table for Active-Low Signal

x_control test_h ram_ctrl Mode
0 0 ram_ctrl Functional Mode
0 1 test_ram_ctrl BIST Mode
1 0 1 Scan Shift Mode
1 1 1

Figure 1-4.

When x_control is high, the ram_ctrl signal is driven high, independent of the value of test_h,
and the memory is operating in scan shift mode (disabled). To automatically set x_control high
during a scan shift, you can connect x_control to the scan_en signal.

When x_control is low, the source of the ram_ctrl signal is determined by the test_h signal. If
test_h is low, the memory is operating in functional mode, or scan capture mode, and ram_ctrl is
driven by the system ram_ctrl signal. If test_h is high, the memory is operating in BIST mode,
and ram_ctrl is driven by the BIST test_ram_ctrl signal.

30 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Control Logic

Example 2
In this example, suppose there is an active-high memory control signal ram_ctrl that disables
the memory when low. During scan shift mode, the memory must be disabled; ram_ctrl must be
0. Use the following command during BISTGEN to set up the control logic:

add control logic memory1/ram_ctrl -active high -external_control_signal x_control

Figure 1-5 illustrates the logic implemented by the above command. The truth table for this
logic is shown in Table 1-3

Figure 1-5. Control Logic Added to Active-High Signal

Table 1-3. Truth Table for Active-High Signal

x_control test_h ram_ctrl Mode
0 0 ram_ctrl Functional Mode
0 1 test_ram_ctrl BIST Mode
1 0 0 Scan Shift Mode
1 1 0

When x_control is high, the ram_ctrl signal is driven low, irrespective of the value of test_h,
and the memory is operating in scan shift mode (disabled). To automatically set x_control high
during a scan shift, you can connect x_control to the scan_en signal.

When x_control is low, the source of the ram_ctrl signal is determined by the test_h signal. If
test_h is low, the memory is operating in functional mode, or scan capture mode, and ram_ctrl is
driven by the system ram_ctrl signal. If test_h is high, the memory is operating in BIST mode,
and ram_ctrl is driven by the BIST test_ram_ctrl signal.

Example 3
The following example creates control logic for an active-high write enable signal, WEN. The
external control is driven by scan_en, the scan shift enable signal, and writing to the memory is
prevented during scan shift mode.

add control logic RAM/WEN -active high -ext scan_en -active high

MBISTArchitect™ Reference Manual, v2021.2 and Later 31

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Control Logic

Example 4
The following example adds control logic to an active-low CEN0 port of a memory named
RAM32:

add control logic RAM32/CEN0 -active low -ext xControl

Example 5
The following example adds control logic to an active-high write enable signal for the
BIST-ready memory RAM32:

add control logic RAM32/test_wen -active high -ext scan_en

Example 6
The following example adds control logic to multiple control signals. In this example the -active
switch is not specified, therefore the definition from the memory is picked up from the BIST
definition library.

add control logic RAM32x6/sCtrl RAM32/xCtrl -ext xControl

// Adding Active Low control logic for memory control port RAM32/sCtrl
// Adding Active Low control logic for memory control port RAM32/xCtrl
Example 7
The following example adds control logic to the WEN and CEN0 ports of memory RAM64. In
this example the -active switch is not specified, therefore the definition from the memory is
picked up from the BIST definition library. The first port is active-high and the other is
active-low.

add control logic RAM64x8/WEN RAM64/CEN0 -ext xControl

// Adding Active High control logic for memory control port RAM64x8/WEN
// Adding Active Low control logic for memory control port RAM64x8/CEN0

Related Topics
Delete Control Logic
Report Control Logic

32 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Data Backgrounds

Add Data Backgrounds

Legal Modes: BISTGEN
Prerequisites: Adds a data background pattern to your selected algorithm. Data backgrounds
work with march2 and March3 algorithms and any user defined algorithms that use a
background data source. Data backgrounds will be ignored unless algorithms are scheduled
that need them. You must assign either the march2 or march3 algorithm to any port to which
you add data backgrounds.
Specifies one or more test patterns (test pattern data values) that are other than all 0s and 1s, for
all memory ports that use the background data source testing algorithms.
Usage
ADD DAta Backgrounds pattern1 [ pattern2 ] ...
Description
Specifies one or more test patterns (test pattern data values) that are other than all 0s and 1s, for
all memory ports that use the background data source testing algorithms. By default, the tool
assigns the march2 algorithm to all memory ports, unless you change the default with the Setup
Mbist Algorithms command.

A data background is the pattern that algorithms such as the march2 or march3 write or read
from each memory word. You can increase the test coverage of your memory by defining a data
background that you know finds faults not found with the default pattern. By default, the
march2 algorithm uses the data pattern of all 0s and all 1s.

The Add Data Backgrounds command lets you specify test patterns (test pattern data values)
such as 0011001100110011. The march2 algorithm causes the BIST controller to write and read
out each data pattern as pattern/inverse pattern pairs. For example, with a pattern of 0110, the
circuitry first writes 0110 to the memory cell, then reads it back, followed by a write and read of
1001 to and from the cell, respectively.

Data backgrounds can also be used by other defined algorithms that specify background data
source usage. They can be added by using the user-defined algorithm capability that use data
backgrounds. For more information, see “Step Definition” in the MBISTArchitect Process
Guide.

Arguments
• pattern1 [ pattern2 ]
A required repeatable binary or hexadecimal pattern that you want to apply to a port for
which a background-using algorithm, such as march2 or march3, is assigned.
You can use any binary or hexadecimal pattern. You must precede hexadecimal patterns by
an x to distinguish them from binary patterns. For example, x7b is a valid hexadecimal
background pattern. If the pattern is larger than the memory word size, the tool truncates

MBISTArchitect™ Reference Manual, v2021.2 and Later 33

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Data Backgrounds

unused bits, having started using them from the LSB of the value, at the MSB end of the
value. If the pattern is smaller than the memory word size, the tool zero fills it to the left.
The tool instantiates the complete test algorithm once for each pattern.
Examples
Example 1
The following setup configuration includes the minimum commands required for an
MBISTArchitect session and changes the background pattern to 0011001100110011 for all
memory ports that have the default march2 algorithm assigned:

load library dft.lib

add memory models ram16x16
add data backgrounds 0011001100110011
run
save bist

In this example, dft.lib is the DFT library filename and ram16x16 is the specific memory model
in the DFT library for which you want to add BIST logic. The Run command causes the tool to
generate BIST logic. The Save Bist command saves the output in a desired format. In this
example, you use no switches with the Save Bist command, so the tool generates the default
Verilog file formats.

Example 2
The following example adds multiple data backgrounds:

add data backgrounds 0011001100110011 xFB35

Related Topics
Add Mbist Algorithms
Delete Data Backgrounds
Load Algorithms
Report Variables
Run
Save Bist
Report Data Backgrounds

34 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Diagnostic Monitor

Add Diagnostic Monitor

Legal Modes: BISTGEN
Prerequisites: None
Controls the set of items observed by the diagnostic module and allows data items to be added
to the observation set.
Usage
ADD DIagnostic Monitor -Standard | item…
Description
Controls the set of items observed by the diagnostic module and allows data items to be added
to the observation set. A data item is a set of signals that is to be observed. The order in which
data items are added becomes the order of output and added items are appended to the end of the
set list.

Command Order
When the Set Controller Debug -on command and switch is processed, the set of data items is
implicitly selected as if Add Diagnostic Monitor -Standard had also been executed.

If you do not want the default set, you have to use the Delete Diagnostic Monitor command and
the Add Diagnostic Monitor <item> command and data item after the Set Controller Debug -on
command is issued.

Arguments
• -Standard
A required switch that specifies that you want the default standard set of data items to be
scanned out. These are the default items.
Data items for concurrent testing: dout, addr_reg, tstate.
Data items for sequential testing: dout, addr_reg, tstate, memnum.
• item…
A required command data value that specifies the data items and the order in which you
want to have them scanned out. The set of possible data items includes the following:
o dout
A data item of the standard set. The data item reported in dout is the actual value of
the port which was declared as “dout” in the memory model. The actual value is
reported because it did not match the expected value during test.
Concurrent Testing — For concurrent testing: width of dout = total width of data
from all memories. The active port data of all memories under test are scanned out
(unlike sequential test where only the active port data is included).

MBISTArchitect™ Reference Manual, v2021.2 and Later 35

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Diagnostic Monitor

Sequential Testing — For sequential testing: width of dout = total width of the
widest memory. For a multi-port memory, only the active port data of the active port
is included. This is unlike concurrent testing where all of the memories are scanned
out, not just the data from the active ports. In port_interaction testing, the first read
port is treated as the active port.
Order of RAMs — The order of RAMs that the diagnostic monitor will scan out
specifically corresponds to concurrent testing only. The data scanned out will be in
the same order as they were added.
o addr
The data item addr returns the value of the address inputs that are supplied to the
memory when the failure occurred. For multi-port memories, you get multiple
addresses included in the diagnostic data.
o addr_reg
The data item addr_reg returns the value of the address register within the BIST
controller. The value of the addr_reg could be different from the addr data item in
the following cases:
• multi-port memory testing, using unique address or port interaction algorithms.
• Using col_march1 algorithm with an addr_inc >= 2.
• When testing multiple memories with a single controller, addr_reg will go
through the sequence required by the largest memory.
o rw_state
The data item rw_state returns the value of the current position within the sequence
of activities that occur at each address. From this you can determine what part of a
complex cycle has been executed. In particular, many algorithms involve a read-
write-read step. rw_state can distinguish whether the error was detected on the first
or second read.
o tstate
A data item of the standard set. The tstate reports the current major state of the BIST
controller. From the tstate value, you can determine exactly what algorithm step is
being performed, and in the case of sequential memories, which memory is being
tested.
o failmap
A data item that returns the value of the failing bitmap, the XOR of the expected
data, and the data read from memory.
Concurrent Testing — Width of failmap = total width of data from all memories.

36 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Diagnostic Monitor

Sequential Testing — Width of failmap = data width of the widest memory. For a
multi-port memory, only the active port data is included. In port_interaction testing,
the first read port is treated as the active port.
o memnum
A data item of the standard set, but included only when doing sequential memory
testing. The data item memnum reports the number for the memory currently being
tested.

Note
The memnum item only works with sequential testing of multiple memories.

o test_addr_shift
A data item that will contain the neighboring address used during address decoder
algorithms: addressdecoder_bg0 or addressdecoder_bg1.
The width of test_addr_shift is the same as that of the addr_reg.
Note that when test_addr_shift is added as a data_item, the tool scans out
test_addr_shift and test_addr_reg. The signal test_addr_shift does not contain the
neighboring address directly, but it would be an XOR of addr_reg and test_addr_reg.

Note
The test_addr_shift item only works with address decoder algorithms.

More information about the addressdecoder_bg0 or addressdecoder_bg1 algorithm

can be found in the “Algorithms” chapter of the MBISTArchitect Process Guide.
o portnum
A data item that specifies the port number. This becomes helpful with multi-port
memories.
The portnum data item is only applicable for multi-port memories. For Single port
memory or 2-port register file, the port number is always 0, and therefore will be
excluded from the diagnostics monitor.
o port_isol_addr_reg_write
A data item used to capture the write address during the W_R operation for port
isolation test. The addr_reg monitor item captures the read address for the W_R
operation. For all other operations, the port_isol_addr_reg_write monitor item will
report a zero value, and the read addresses are captured by the addr_reg monitor
item.
You must add a port isolation algorithm (includes a W_R operation) to use this
diagnostic monitor item.

MBISTArchitect™ Reference Manual, v2021.2 and Later 37

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Diagnostic Monitor

Examples
The examples in this section show how to request diagnostic output that can support various
repair and diagnosis strategies. Although originally added to assist with failure mode diagnosis
and analysis, this information might be used during production test to determine how to correct
repairable memories. Appropriate choice of the output information can make the repair task
more straightforward. As discussed in the main description section, the Set Controller Debug
-On sets up the default set. The delete command clears that set. It is assumed for these examples
that you have issued the following commands:

set controller debug -on

delete diagnostic monitor -all

The following example shows support for spare word or row repair:

add diagnostic monitor addr // Only need the addresses of failures.

The following example shows support for spare logical column repair:

add diagnostic monitor failmap //"1"-bits indicate a problem on ’columns’

The following example shows support for any two or all three kinds of spares: Row, Column
and Word:

add diagnostic monitor addr failmap

The following example shows support for simple diagnosis. This will help identify stuck-at
faults:

add diagnostic monitor addr dout failmap

The following example shows support for advanced diagnosis:

add diagnostic monitor addr dout failmap tstate rw_state

The data items tstate, and rw_state, can help distinguish among transition faults, coupling faults,
and stuck-at faults. With detailed knowledge of the algorithms, you can eliminate dout as its
value can be deduced.

In all of the previous examples, if you are doing sequential testing of multiple memories, you
can include the data item memnum.

Related Topics
Add Mbist Algorithms
Report Diagnostic Monitor
Set Controller Debug
Delete Diagnostic Monitor
Setup Memory Access

38 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Existing Controller

Add Existing Controller

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Declares a memory BIST controller which was generated in a previous invocation of the tool,
and schedules it for insertion in this invocation.
Usage
ADD EXisting Controller controller_instance_path_name controller_name
[ -Diagnostic_configuration file_name ]
{ memory_instance BIST_collar_name}...
Description
Declares a memory BIST controller which was generated in a previous invocation of the tool,
and schedules it for insertion in this invocation. Declares an arbitrary number of BIST memory
collars which were generated in a previous invocation of the tool and schedules them for
insertion in this invocation. The controller drives the collars.

This command does not cause any new BIST circuitry to be generated. This command is used to
perform the insertion activity of the bottom-up insertion flow.

Separately you must specify the HDL file in which the BIST circuitry (controller and collars) is
defined, using the Load Design Objects command. You must also specify the CTDF file which
describes the existing controller, using the Load Controller Description command.

Tip
: Use the Add Pin Mapping command after all of the Add New Controller and Add Existing
Controller commands are used.

Arguments
• controller_instance_path_name
A required string that specifies the location, or path, where the controller should be inserted,
and the name which should be given to the controller instance when it is instantiated.
• controller_name
A required string that specifies the entity/module name of the previously generated BIST
controller.
• -Diagnostic_configuration file_name
An optional switch that instructs the tool to read the file_name.diagcfgb file and associate
the controller instance to a specified controller model. The output after running the Save
Bist command, is model file that is used by the Diagnosis tool for diagnostics.

MBISTArchitect™ Reference Manual, v2021.2 and Later 39

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Existing Controller

• memory_instance
The first of a required repeatable pair of strings. This string specifies the path and instance
name of a memory instance to be replaced by the BIST collar (Paired with the following
BIST_collar_name).
• BIST_collar_name
The second of a required repeatable pair of strings. This specifies the collar module name
(Paired with the previous memory_instance).
Examples
The following example commands will schedule the controller instance mbistc to be inserted in
/cpu:

add existing controller cpu/mbistc ram8x4_bist mem1 ram8x4_block_0 \

mem2 ram8x4_block_1

The following example command schedules the controller instance "Ux##1 " (escaped
identifier) to be inserted in /CT_C1:

add exist cont "/CT_C1/\Ux##1 " mycntr memB collar_1 memC collar_1

Related Topics
Add New Controller
Load Design Objects
Report Controllers
Load Controller Description
Delete Controller

40 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Mbist Algorithms

Add Mbist Algorithms

Legal Modes: BISTGEN
Prerequisites: User-defined algorithms must be loaded using the Load Algorithms command.
Adds one or more algorithms for BIST.
Usage
ADD MBist Algorithms {port_number algorithm1 [ algorithm2 ]... } | Port_interaction
Description
Adds one or more algorithms for BIST. Use this command to:

• Add algorithms for individual ports. The algorithms are applied to each memory with
the specified port. Use a separate command instance for each port number.
• Add the port_interaction algorithm. This algorithm is applied to all ports of multi-port
memories only. The port_interaction algorithm must be specified using a separate
command instance.
Using the Add Mbist Algorithms command removes the default algorithms you specified using
the Setup Mbist Algorithms command from the specified port. If you want to include algorithms
in addition to the default algorithms for a port, you must specify both the default and additional
algorithms with the Add Mbist Algorithms command.

Different algorithms target different types of faults, and the more algorithms you choose the
longer your test will take; therefore, it is important that you carefully select the most efficient
algorithms for testing the types of faults that are common for your controller memory. For more
information on each pre-defined algorithm, see the “Algorithms” chapter of the MBISTArchitect
Process Guide.

The BIST controller applies the algorithms in the order you specify with this command, except
for the comparator test and port_interaction test algorithms. Comparator test is always executed
first and port_interaction last. The comparator test algorithm is added by the Set Comparator
Test command.

Note
The Port Isolation Testing Algorithm is not a pre-defined algorithm. You must create and
load a UDA for this test before you can add it with either the Add Mbist Algorithms or
Setup Mbist Algorithms command. For more information, see the “User-Defined Algorithms”
chapter of the MBISTArchitect Process Guide.

MBISTArchitect™ Reference Manual, v2021.2 and Later 41

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Mbist Algorithms

Arguments
• port_number
A required integer that specifies the port number of the write or read/write port for which
you want to assign specific algorithms. The algorithms will apply to all memories with that
port.
For example, specifying “1” for the port_number and “march1” for the algorithm adds the
march1 algorithm to the first write (or read/write) port found in each memory model.
Specifying “2” for the port_number adds the algorithm to the second write (or read/write)
port found in each memory, and so on.
For a single-port memory, the only valid port number is 1. For a memory with four read/
write ports, the valid port numbers are 1, 2, 3, and 4.
For register files, port-isolation algorithms are only valid for the first port. If you add a port-
isolation algorithm to the second port, the algorithm will be applied, but the output from the
register file(s) will be ignored by the controller during testing.
• algorithm1 [ algorithm2 ]
A required, repeatable string that specifies the algorithm name(s) to add for the specified
port number. Use the Report Algorithms command to see a complete list of available
algorithms including any user-defined algorithms.
Note
If you specify the ROM1 or ROM2 algorithm, you need to provide a ROM content
file in the proprietary Siemens EDA Modelfile format.

• Port_interaction
A required literal that applies the port_interaction test algorithm to all ports (for multi-port
memories). This algorithm must be specified in a separate command instance. You cannot
specify a port number or any other algorithms on the same command line.
Note
Do not specify the port_interaction test algorithm if all memories have fewer than
two read ports.

Examples
Example 1
The following example shows a setup configuration that adds the port_interaction algorithm to
all loaded memories, then adds two different BIST algorithms to two different memory models
named ram16x16 and ram16x64. In this example both ram16x16 and ram16x64 have two read/
write ports each.

load library mbist.lib

report memory models -library
report memory models -model ram16x16
report memory models -model ram16x64

42 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Mbist Algorithms

add memory models ram16x16 ram16x64

report memory models
add mbist algorithms port_interaction
add mbist algorithms 1 march1
add mbist algorithms 2 unique
run
save bist

This example shows a normal progression, where you first load a DFT library, select and add
your memory models, add the Port_interaction algorithm to both memory models, and then add
the march1 algorithm to the first port of each memory model and the Unique algorithm to the
second port of each memory model. You then run the tool and save the output in the desired
format. In this example, you use no switches with the Save Bist command, so the tool generates
files in the default Verilog format.

Example 2
The following example uses the same dual-ported ram16x16 and ram16x64 models of the
previous example:

load library mbist.lib

add memory models ram16x16 ram16x64
add mbist algorithms 1 march1
run
save bist

As writable memories, the default algorithm on all controllers and memories is march2 (see the
Setup Mbist Algorithms command description regarding default algorithms). The default has
been overridden for port 1 only. Here is the algorithm usage summary:

Ram16x16, port 1: march1

Ram16x16, port 2: march2

Ram16x64, port 1: march1

Ram16x64, port 2: march2

Example 3
The following example shows how the order in which you specify the algorithms affects the
order of execution in the controller:

add mbist algorithms 1 march2 march3

add mbist algorithms 2 unique checkerboard

The test for the dual port memories uses the following sequence: March2, March3, Unique, and
CheckerBoard.

Related Topics
Delete Mbist Algorithms

MBISTArchitect™ Reference Manual, v2021.2 and Later 43

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Mbist Algorithms

Load Algorithms
Report Algorithms
Report Mbist Algorithms
Set Comparator Test
Setup Mbist Algorithms

44 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Memory Models

Add Memory Models

Legal Modes: BISTGEN
Prerequisites: First you must load the DFT library that contains the memory model(s) to which
you want to add BIST logic. If you want to set the synthesis environment to something other
than Synopsys, you must do so before you add memory models.
Adds one or more memories to the set being tested by the BIST controller currently being
configured for generation.
Usage
ADD MEmory Models { model_name [ -Filename name ] [ -Collar collar_module_name ]
[ -Bypass name ] [ -AddrScrambler name ] [ -DataScrambler name ] }...
Description
Adds one or more memories to the set being tested by the BIST controller currently being
configured for generation. BIST controllers can test one or more memories. This command also
causes the tool to generate a BIST collar hierarchy and to instantiate the BIST-related modules
and the memory only if the added memory model contains data or address scrambling
definitions.

Use the Report Memory Models command to list the added memory models. If you find
unwanted memory models, you can delete them by using the Delete Memory Models command.
Also, when you provide memory contents through the Add Memory Model command, use the
Report Algorithm Steps command to report final signatures of each MISR.

Naming Conventions
When you want to have your own naming convention for collars specific to each memory model
that you add, the -collar switch must be used with the corresponding memory name (see the
example section).

See also the -collar switch description.

Signature Comparison Testing

For signature comparison testing, this command also adds one or more memories to your setup
configuration. The signature is precomputed based on the ROM contents (for example, the
ROM file) and the ROM1 test algorithm. This feature supports only the propietary Siemens
EDA memory content format and supports only the ROM1 and ROM2 test algorithms. The
shifting out of signatures is also supported.

For signature comparison tests, the tool generates a controller that compares the MISR content
with a precomputed signature. This comparator is local to the BIST collar and is unique for each
MISR. If the signature does not match the BIST collar, the tool inserts an extra output pin that is
asserted to the “1” state.

MBISTArchitect™ Reference Manual, v2021.2 and Later 45

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Memory Models

BIST Controllers for Multiple Memories

When creating BIST controllers for multiple memories, the read/write cycles of each memory
should be functionally equivalent, as should the individual ports of a single memory. The
control signal assertions of control signals defined as write_enable, read_enable, output_enable,
and chip_enable must occur at the same points in all read and write cycles that use them.
Vendor, technology, assert_state, read cycle length, memory sizes, word sizes, and number of
ports need not be equivalent.

Arguments
• model_name
A required string that specifies the name of one or more memories to add to your setup
configuration.
• -Filename name
An optional switch and string pair used only for ROM memories that specifies the ROM file
describing the ROM content.
For more information, see “ROM Content File” in the MBISTArchitect Process Guide.
Note
You must specify a ROM content file using this switch if you also use the Setup
Mbist Compressor command with the -LocalComparator switch.

• -Collar collar_module_name
An optional switch and string pair with which you specify a name of your choice for each
memory collar module. The default allows the memory collar module to be named by the
composite of “bist controller module name” + “_memory module name” + “_block” +
“_serial number.”
• -Bypass name
An optional switch and string pair to specify, for a named model, a user-defined name for
the model’s bypass module. The name is used as-is with no prefixing/postfixing.
• -AddrScrambler name
An optional switch and string pair with which you specify, for a named model, a
user-defined name for the model’s address scrambler/descrambler module. This name is
used as is with no prefixing/postfixing.
• -DataScrambler name
An optional switch and string pair with which you specify, for a named model, a
user-defined name for the model’s data scrambler/descrambler module. This name is used
as is with no prefixing/postfixing.

46 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Memory Models

Examples
The following is a minimal MBISTArchitect session that generates and saves BIST logic:

load library dft.lib

add memory models ram16x16
run
save bist

Where dft.lib is the DFT library filename and ram16x16 is the specific memory model in the
DFT library to which you want to add BIST logic. Before you add a specific memory model,
you might want to report and examine the details of that model by using the Report Memory
Models command.

The following example command creates a single BIST controller to test multiple memories
where ram_1, ram_2, ram_3, and ram_4, are the RAM model names:

add memory models ram_1 ram_2 ram_3 ram_4

For multiple memories using the same model, the example command could be written as
follows:

add memory models ram_1 ram_1 ram_1 ram_1

For this example the memory models are identified as mem_1, mem_2, mem_3, and mem_4,
and for ease of operation assume that you want to re-name the collars to match this pattern.

add memory models mem_1 -collar collar_1 mem_2 -collar collar_2 mem_3 -collar collar_3
mem_4 -collar collar_4

Related Topics
Delete Memory Models
Load Algorithms
Setup Mbist Compressor
Report Memory Models
Report Algorithm Steps
Report Variables

MBISTArchitect™ Reference Manual, v2021.2 and Later 47

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add New Controller

Add New Controller

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Generates a BIST controller and one or more memory collars.
Usage
ADD NEw Controller controller_instance_name [ -Dofile mbist_dofile ]
{ memory_instance [ -Collar BIST_collar_name ] }…
Description
Generates a BIST controller and one or more memory collars. This BIST circuitry is then
scheduled for insertion. The BIST controller is generated using either the default dofile or a
user-defined dofile.

The default dofile contains the following commands:

reset state
add memory model
setup mbist algorithms march2
set bist insertion -on
set bsda -on
add signal synchronization test_h
set design name controller -module
set file naming -bist_model
set file naming -connected_model
set file naming -testbench
set file naming -script
set file naming -ctdl
set file naming -wgl
run
save bist -verilog -script -replace
exit -force

The Add New Controller command is normally part of the top-down insertion flow, but it can
also be used in the bottom-up insertion flow if you are adding new controllers to those
previously generated.

Tip
: The Add Pin Mapping command should be used only after all Add New Controller and
Add Existing Controller commands.

Arguments
• controller_instance_name
A required string that specifies the path and instance name where you want to insert the
generated BIST controller. For example, if you want to insert a controller with instance

48 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add New Controller

name “cntr_1” in a parent design at path “/U1/U2”, you would specify this argument as “/
U1/U2/cntr_1”.
• -Dofile mbist_dofile
An optional switch and string pair that specifies a user-defined dofile for generating the
BIST circuitry. If you do not use this switch, MBISTArchitect uses the default dofile as
shown in the command description above.
Caution
The user-defined dofile must contain the Exit command. If the dofile does not
include the Exit command, it will never finish processing and cause
MBISTArchitect to hang.

• memory_instance
A required, repeatable string that specifies the path and instance name where you want to
insert the generated memory collar(s).
• -Collar BIST_collar_name
An optional switch and string pair that specifies a name for the memory collar generated for
a memory_instance. If you do not include this switch for a memory instance,
MBISTArchitect uses a default name for the collar.
Note
You cannot use the -Collar switch if you are also using the -Dofile switch with this
command. To change the default naming of memory collar(s) generated with a user-
defined dofile, use either the Add Memory Models or Set Design Name command in
your generation dofile.

Examples
The following examples add controllers for various memories:

add new controller contr1 -dofile mbist.do mem0 mem1 /a/mem2

add new controller /blk1/contr2 mem3 /a/mem4
add new controller contr3 mem5 -collar mycollar mem6 /a/mem1

The following example shows the usage of escaped identifier "Ux##2 " as controller name:

add new controller "/pll_1/\Ux##2 " -dofile bistgen.do /chip_B/memA /chip_A/memA

Related Topics
Add Existing Controller
Delete Controller
Report Variables
Add Pin Mapping
Report Controllers

MBISTArchitect™ Reference Manual, v2021.2 and Later 49

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add New Port

Add New Port

Legal Modes: SETUP Mode of BIST Insertion Phase
Prerequisites: None
Creates the specified port on the top level using the port name and port direction you specify.
Usage
ADD NEw Port port_name -Direction port_dir
Description
Creates the specified port on the top level using the port name and port direction you specify.
Use this command to add a new port, then reference this port using commands like Add Pin
Mapping or Add Pin Sharing. For example, you might use this command to create a new port,
then use the Add Pin Mapping command to map to this port.

Arguments
• port_name
A required literal that specifies the name of the port.
• -Direction port_dir
A required switch and literal pair that specify the port’s direction of either in (input), out
(output), or inout (bidirectional).
Examples
The following example command creates a scalar input port named myPort on the top level:

add new port myPort -dir in

The following example creates an output bus port named myPort2[4:9] on the top level:

add new port myPort2[4:9] -dir out

The following example command creates a bidirectional port named myBidiPort1 on the
top-level:

add new port myBidiPort -dir inout

Related Topics
Add Pin Mapping
Delete New Port
Add Pin Sharing
Report New Port

50 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Pattern Translation

Add Pattern Translation

Legal Modes: INT (BIST Insertion and Gate-Level Verification Phases)
Prerequisites: None
Specifies the controllers for which pattern translation will be performed at the next Integrate
Patterns command.
Usage
ADD PAttern Translation -All | { controller_inst_name [ -Mode test_mode ] } |
{ concurrent_group_name [ { -Mode controller_inst_name/test_mode }… ] }
[ -Procedure clock_run_procedure_name ]
Description
Specifies the controllers for which pattern translation will be performed at the next Integrate
Patterns command. Only one controller instance or concurrent group can be specified per issue
of this command.

This tool gives you numerous possible combinations of controllers and test modes from which
to choose. You can specify different modes for each controller instance. You can specify to
translate patterns for all controller instances, for a single controller instance, or a concurrent
group, or you can specify multiple controller instance/mode combinations for concurrent
groups.

Multiple occurrences of the Add Pattern Translation command specify the order in which the
patterns appear in the output files. To view the current order, execute the Report Pattern
Translation command. The order in which the patterns are reported is the order used for the
output files. If you use the -all option, the order of the output patterns is arbitrary.

Arguments
• -All
A required switch that schedules all controller instances and concurrent groups. All modes
associated with the controller instances and groups will be translated. No other switches or
parameters can be specified when using the -all switch.
• controller_inst_name
A required replaceable string that specifies the instance-names of controllers for which
patterns are to be translated at the next Integrate Patterns command. You can optionally
specify the test_mode of each controller instance in the concurrent group that you want to
translate by using a -mode switch for each controller instance.
• -Mode test_mode
An optional literal switch that specifies the mode of a controller_instance_name pattern that
you want to have translated.

MBISTArchitect™ Reference Manual, v2021.2 and Later 51

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Pattern Translation

• concurrent_group_name
A required replaceable string that specifies that the pattern of a concurrent group that you
want to have translated. You have an option to specify the mode of the concurrent group
with the -mode switch. Only one concurrent group can be specified per Add Pattern
Translation command.
• -Mode controller_inst_name/test_mode
An optional switch to specify the mode when you choose all controller instances, an
individual controller instance, or a concurrent group.
The -Mode switch can be optionally named by a replaceable string test_mode, which is
repeatable when used to specify the mode of a controller instance, allowing more than one
mode to be specified.
When the -Mode switch is used to specify a concurrent_group_name, the -Mode switch
must be further specified by the required string controller_instance_name/test_mode.
If you specify multiple controller instances in a concurrent group and include the -Mode
switch for any of these controller instances you must specify the mode for all controller
instances. If no mode is specified, all modes are scheduled for translation. The -Mode
switch cannot be used with the -All switch.
• -Procedure clock_run_procedure_name
An optional switch and literal that specifies the name of your user-defined clock run
procedure. This switch allows you to translate/integrate the controller patterns considering
the events and timeplates defined in your clock run_procedure.
The -Procedure switch must be used on the Add Pattern Translation command in order for it
to take an effect. This is especially true when multiple clock_run procedures are loaded and
each one might be for a different BIST controller or concurrent group.
Examples
The following example specifies that the patterns for the IO/arm1 and IO/arm2 controller
instances should be translated, in that order, at the next Integrate Patterns command:

add pattern translation IO/arm1

add pattern translation IO/arm2

The following example specifies that the patterns for all controller instances should be
translated:

add pattern translation -all

For the following example, assume you have concurrent group grp1 which consists of an
instance of memory controller A called A1, an instance of controller B called B1, and an
instance of controller C called C1. Also assume that controller A has two test modes, a1 and a2,
controller B has test mode b, and controller C has test mode c. If you want to test concurrent

52 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Pattern Translation

group grp1 by using mode a1 for controller instance A1, but also want to test concurrent group
grp2 by using mode a2 for controller instance A1, you need to specify the following commands:

add pattern translation grp1 -mode A1/a1 -mode B1/b

add pattern translation grp2 -mode A1/a2 -mode c1/c

The following example uses the -Procedure switch. Even when the clock_run procedure is
loaded and parsed, its effect only takes place if it is used on the Add Pattern Translation
command. The following set of commands are expected to produce the same patterns:

Case 1:

add pattern translation -all // No clock_run procedure is loaded

integrate patterns

Case 2:

add pattern translation -all // No clock_run procedure is loaded

integrate patterns -mode_external

Case 3:

load procedure file run_clk_proc

add pattern translation -all // clock_run procedure is loaded but not used
integrate patterns -mode_external

In the following example, a PLL_clk will affect all controllers:

add pattern translation -all -procedure PLL_clk

In the following example, a PLL_clk will only be added to contr_1:

add pattern translation contr_1 -procedure PLL_clk

add pattern translation contr_2

Related Topics
Add Clocks
Delete Pattern Translation
Delete Patterns
Integrate Patterns
Load Procedure File
Report Pattern Translation

MBISTArchitect™ Reference Manual, v2021.2 and Later 53

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Pin Mapping

Add Pin Mapping

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Maps a specified controller, collar, or block pin to a pin at the top-level or to an internal pin.
Usage
ADD PIn Mapping target_pin_path_name [ -Invert ] [ -NOTop ] [ -NOControl ]
[ -Top_pin top_pin_name ] { instance_pin_path_name... } [ -Logic logic_type ]
Description
Maps a specified controller, collar, or block pin to a pin at the top-level or to an internal pin. If
the top-level pin does not exist, the tool creates a new pin with the specified name. Each bit of a
bus signal must be mapped separately.

By default, all controller pins are mapped to newly created pins at the top-level. This command
can override the default by specifying the user preferred mapping.

Tip
: Use the Add Pin Mapping command after all Add New Controller and Add Existing
Controller commands.

Arguments
• target_pin_path_name
A string that specifies the name of the target top-level or internal pin. This string is required
if the pin is associated with a clock, this string is optional otherwise. See the following note.
Note
If the pin type is associated with a clock pin (for example bist_clk), then the
target_pin_path_name must be first added using the Add Clocks command before
using the Add Pin Mapping command, otherwise you will receive an error.

• -Invert
An optional switch that instructs the tool to add an inverter in the path between the
target_pin_path_name and the instance_pin_path_name.
• -NOTop
An optional switch that instructs the tool to map a controller or collar pin to a wire and not a
pin. The tool will create a wire at the level where the controller or memory collar is inserted
if the wire does not exist at that level of hierarchy.
• -NOControl
An optional switch that instructs the tool to not insert any control logic to control
bidirectional port enables.

54 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Pin Mapping

For the following signals: test_h, rst_l, algsel_en, and misr_scan_en, the tool will not be
able to insert any control logic. Therefore, the tool will trace to see if there is a direct PI to
control the bidirectional (bidi) enable; if not, the tool will issue an error stating that it cannot
map this signal to a bidi port. You can bypass this error by using the -NOControl switch to
force the tool to do the mapping, and also to control the bidi enable you need to force it
through a test_setup procedure to the proper control value (0 or 1).
See also: “Sharing Top-Level Bidirectional Ports” in the MBISTArchitect Process Guide.
• -Top_pin top_pin_name
An optional switch and string pair that specifies the existing top-level pin name. The
-Top_pin option can only be used when mapping to an internal pin; for example,
target_pin_path_name is an internal pin path. An error is issued if target_pin_path_name
is a top-level pin.
Note
The system connection between target_pin_path_name and top_pin_name will not
be validated.

• instance_pin_path_name
A required string that describes the path to the controller or collar or block pin name.
• -Logic logic_type
An optional switch and string pair that instructs the tool to insert sharing logic between the
output pins mapped to the same target_pin_path_name. Valid control logic is as follows:
AND OR
NAND NOR
XOR

Examples
The following example connects bp_clk of memory collar M1 and bp_clk of memory block M4
to an internal wire named topclk (note that topclk is not a pin because of the use of the -notop
switch):

add pin mapping topclk -notop /M1/bp_clk /M4/bp_clk

The following example connects the scan_out pin of both M7 and M9 memory blocks to bit 9 of
an output pin x. Note that a mux will be inserted in this case:

add pin mapping x[9] /M7/scan_out /M9/scan_out -logic OR

The following example connects the topEnable pin to a controller test_h signal:

add pin mapping topEnable controller_A/test_h

MBISTArchitect™ Reference Manual, v2021.2 and Later 55

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Pin Mapping

The following example connects the PLL clock (clk) to a controller (contr_A) clock (bist_clk):

add pin mapping PLL/clk /contr_A/bist_clk

The following example connects the fail_h pin of both “Ux##1 “ (controller name is escaped
identifier) and contr_A controllers to output pin “fail##1 “ (escaped identifier):

For pin mapping always specify the pin path name between double quotes if escaped names are
involved.

add pin mapping fail##1 "/\Ux##1 /fail_h" contr_A/fail_h -logic or

The following example shows a way to specify the pin path name when controller name
"Ux##1" is an escaped identifier and controller is in "pll_2":

add pin mapping fail##1 "/pll_2/\Ux##1 /fail_h" contr_A/fail_h -logic or

The following example connects controller clock (bist_clk) to internal PLL clock and defines
PLL reference clock (ref_clk) as a top-pin.

add pin mapping /PLL/clk -top_pin ref_clk /contr_A/bist_clk

Related Topics
Add Clocks
Add Existing Controller
Add New Controller
Add Pin Sharing
Delete Pin Mapping
Load Procedure File
Report Pin Mapping

56 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Pin Sharing

Add Pin Sharing

Legal Modes: SETUP Mode and BIST Mode of the Insertion Phase
Prerequisites: For clock signals, the target pin must be defined as a clock using the Add Clocks
command.
Maps the specified pin types to a single top-level or internal pin.
Usage
ADD PIn Sharing pin_type [ -Logic logic_type ] [ target_pin_path_name ] [ -Invert ]
[ -NOTop ] [ -NOControl ] [ -Top_pin top_pin_name ]
Description
Maps the specified pin types to a single top-level or internal pin. All controllers and collar pins
of the specified pin type are mapped to the target pin name. If the target does not exist, it will be
created. If you do not specify a target pin name, a new pin will be created with a default name.

For sharing clock type signals, you must specify a target_pin_path_name that exists in the
design and has been identified as a clock using the Add Clocks command.

Each bit of a bus signal must be mapped separately.

Arguments
• pin_type
A required string that specifies the pin type to be shared. The pin_type and the pin_name are
often the same and share the same name. It is very important to verify that the pin_type
selected is truly a pin_type, and not just a pin_name. Refer to Table 1-5 on page 188 to find
the pin_type for default pin_names.
The following table lists the pin types generated by MBISTArchitect. You can also use any
other pin type that you have defined for your design.

MBISTArchitect™ Reference Manual, v2021.2 and Later 57

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Pin Sharing

Table 1-4. Generated Pin Types

Block Inputs Outputs
Controller algsel_scan_clk algsel_scan_out
algsel_scan_en diag_scan_out
algsel_scan_in fail_h 1
bist_clk1 start_retention_h
debugz repair_data_out
diag_clk repairable_h
diag_scan_in restart_h
hold_l1 tst_done
repair_data_clk
repair_data_in
rst_l1
test_h1
test_resume_h
Collar atpg_mode atpg_scan_out
atpg_scan_enable fail_h1
bist_clk1 misr_scan_out
bypass_clk
bypass_control
bypass_scan_en
hold_l1
misr_clk
misr_scan_en
rst_l1
test_h1
1. This pin type can be in both the controller and collar.

58 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Pin Sharing

• -Logic logic_type
An optional switch and string pair that inserts logic between the output pins mapped to the
same target_pin_path_name. The following are valid logic_types:
AND OR
NAND NOR
XOR

• target_pin_path_name
An optional string that specifies the name of the target top-level or internal pin. This
argument is required if the pin is associated with a clock signal, and the target pin must
exist. For all other pin types, a new pin will be created if the target_pin_path_name does not
exist.
• -Invert
An optional switch that inserts an inverter in the path between the target_pin_path_name
and the pin_type.
• -NOTop
An optional switch that maps the pin_type to a wire instead of a pin. The tool will create a
wire at the level where the controller or memory collar is inserted if the wire does not exist
at that level of hierarchy.
• -NOControl
An optional switch that prevents the insertion of control logic for bidirectional port enables.
For the following signals: test_h, rst_l, algsel_en, and misr_scan_en, the tool will not be
able to insert any control logic. Therefore, the tool will trace to see if there is a direct PI to
control the bidi enable; if not, the tool will issue an error stating that it cannot map this
signal to a bidi port. You can bypass this error by using the -NOControl switch to force the
tool to do the mapping, and also to control the bidi enable you need to force it through a
test_setup procedure to the proper control value (0 or 1).
• -Top_pin top_pin_name
An optional switch and string pair that specifies the existing top-level pin name. The
-Top_pin option can only be used when mapping to an internal pin; for example,
target_pin_path_name is an internal pin path. An error is issued if target_pin_path_name
is a top-level pin.
Note
The system connection between target_pin_path_name and top_pin_name will not
be validated.

MBISTArchitect™ Reference Manual, v2021.2 and Later 59

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Pin Sharing

Examples
The following example causes the debugz signal of all controllers to share a single pin:

add pin sharing debugz

The following example causes the bypass_clk signal of all collars to share a top-level pin named
myBypass_clk:

add pin sharing bypass_clk myBypass_clk

The following example ORs all of the controllers and the collars fail_h signals and connects the
outputs of the OR gate to a top-level pin named \A#3:

add pin sharing fail_h -logic OR A#3

Related Topics
Add Clocks
Add Pin Mapping
Delete Pin Sharing
Load Procedure File
Report Pin Mapping
Report Pin Sharing

60 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Signal Synchronization

Add Signal Synchronization

Legal Modes: BISTGEN
Prerequisites: None
Adds the necessary logic into the BIST controller for synchronization.
Usage
ADD SIgnal Synchronization signal_name…
Description
Adds the necessary logic into the BIST controller for synchronization. You need to specify any
signal name that you want synchronized in the BIST controller. The tool performs a rule check
and automatically adds the remaining possible signals’ synchronizers to ensure the proper work
of the controller dealing with unsynchronized input signals. You can only synchronize the
test_h, test_resume_h, and rst_l input signals. The test_resume_h signal synchronizer can be
added only when this pin is present in controller. Adding the rst_l signal synchronization logic
is possible only in the synchronous reset mode (Setup Controller Reset –synchronous).

Reducing Register Glitches

When you issue the Add Signal Synchronization command, the tool ensures that the generated
RTL for the BIST controller will add the necessary logic for synchronization. Signal
Synchronization adds a pipeline of two register stages between the input signals and the internal
logic of the BIST controller. These are sometimes referred to as deglitching registers.

Deglitching registers, among other things, have two main purposes. The input signals are driven
by circuitry whose clocking might not be synchronized with the BIST clock.

The following explains the two main purposes of deglitching registers:

• Reduce glitches caused by clock phase problems.

• Assist with meeting timing during synthesis, by isolating both the clock uncertainty and
the delay for external circuitry, from the operation of the internal circuitry.

Adding the rst_l Signal Synchronizer

In order to avoid possible race condition, the rst_l signal synchronizer is always superior to the
other synchronizers. It means that the synchronized version of the rst_l signal will be used to
reset the remaining synchronizers’ flip-flops. In case of the diagnostic monitor added to the
controller with “-slow_tester_clk” option constituting a separate “diag_clk” clock domain,
additional instance of the synchronizer will be added to synchronize the rst_l signal in the
“diag_clk” domain.

MBISTArchitect™ Reference Manual, v2021.2 and Later 61

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Signal Synchronization

Arguments
• signal_name…
A required, repeatable string that names the signal. Only rst_l, test_h, and test_resume_h are
supported.
Examples
Example 1
The following example illustrates enabling the rst_l signal synchronization logic and automatic
adding the test_h signal synchronization logic:

setup controller reset -synchronous

add signal synchronization rst_l
run
// Warning: Synchronization logic for test_h signal will be added as well
// to make sure that the BIST controller operates properly when the other
// signal is synchronized as requested.
// ** Successfully added BIST circuitry.

Example 2
The following schematic depicts a relationship between the rst_l synchronization logic for both
bist_clk and diag_clk clock domains.

Figure 1-6. rst_l synchronization logic

62 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Signal Synchronization

Related Topics
Delete Signal Synchronization
Report Signal Synchronization

MBISTArchitect™ Reference Manual, v2021.2 and Later 63

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Verilog Include

Add Verilog Include

Legal Modes: BISTGEN
Prerequisites: None
Causes the given file names to be included by the generated BIST controller Verilog HDL.
Usage
ADD VErilog Include include_file…
Description
Causes the given file names to be included by the generated BIST controller Verilog HDL. The
include file(s) must define a verilog function. You use these functions, and sets of address
parameters, to develop the address sequences for your user-defined algorithm(s).

Within the context of this command, the ‘include is used specifically for including HDL
Fragments that define Verilog Functions used by the “addr function” syntax of a User Defined
Algorithm. Do not use this command to ‘include arbitrary “user” HDL files.

For more information on using a Verilog function with your UDA, see “Address Sequences” in
the MBISTArchitect Process Guide.

You call the address increment function with two arguments: the current address register and
the number of bits in the address that is being incremented. The function must return a value
that is type equivalent to the current address register. The exact type of the current address
register is determined once the RTL is generated for the controller. With Verilog RTL, you use
an integer parameter and return value for address widths of less than the size of an integer. For a
wider address you need to use other suitable types. Since Verilog is not able to determine the
number of bits in the address register from the value passed in, the MBISTArchitect tool uses
the following defined constants:

• MAX_ADDRESS_SIZE — The width of the address register.

• MAX_DATA_SIZE — The width of the data being generated.
These constants will be emitted prior to any Verilog ‘include directives. Note that ‘include is a
Verilog compiler directive, but address incrementing functions are not “directives,” they are
Verilog functions.

Arguments
• include_file
A repeatable, required string that names a file and its relative path.

64 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Verilog Include

Examples
The following is an example of an MBISTArchitect dofile using the Add Verilog Include
command:

load lib mbist.lib

add me model ram16x4
add verilog include odd_even_address.v
load algorithms my_uda
add mbist al 1 odd_even
run
rep algor step
save bist -verilog -replace
exit -force

The following is an example of a User Defined Algorithm named my_uda, that describes the
address sequencing:

step w_even_addrUp;
addr function odd_even_address, 0 , 14, 8;
data checkerboard;
operation w;

step w_odd_addrUp;
addr function odd_even_address, 1 , 15, 8;
data seed;
operation w;

step r_even_addrUp;
addr function odd_even_address, 0 , 14, 8;
data checkerboard;
operation r;

step r_odd_addrUp;
addr function odd_even_address, 1 , 15, 8;
data seed;
operation r;

repetition odd_even;
seed 0;
begin
step w_even_addrUp;
step w_odd_addrUp;
step r_even_addrUp;
step r_odd_addrUp;
end
test odd_even;
repetition odd_even;

MBISTArchitect™ Reference Manual, v2021.2 and Later 65

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Verilog Include

The following is an example of Address function (odd_even_address.v):

function [3:0] odd_even_address;

parameter w = ‘MAX_ADDRESS_SIZE;
input [3:0] addr;
input [w-1:0] width;
integer c;
begin
odd_even_address = addr + 2;
end
endfunction

Related Topics
Delete Verilog Include
Report Verilog Include

66 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Add Vhdl Library

Add Vhdl Library

Legal Modes: BISTGEN
Prerequisites: None
Adds a specified VHDL library clause and optionally use clauses to the <model>_bist.vhd file.
Usage
ADD VHdl Library library_expression [ -Use use_expression… ]
Description
Adds a specified VHDL library clause and optionally use clauses to the <model>_bist.vhd file.
If you use Save Bist -script, then the output dcscript will have commands to read the use targets
as well.

Arguments
• library_expression
A required repeatable string that specifies the name of one or more libraries.
• -Use use_expression
An optional repeatable string to specify a use clause for the specified library. The
use_expression normally should be of the form “<library>.<package>.all”.
Examples
The following example adds a library clause only. The <model>_bist.vhd file will contain the
following user specified library statements: library mylibrary:

add vhdl library mylibrary

The following example adds two library clauses and three use clauses:

add vhdl library mylibrary -use mylibrary.myuse1.all

add vhdl library mylibrary -use mylibrary.myuse2.all
add vhdl library big_library -use big_library.myuse3_use.all

The <model>_bist.vhd file will include the following lines:

library big_library;
library mylibrary;

use big_library.myuse3_use.all;
use mylibrary.myuse1.all;
use mylibrary.myuse2.all;

MBISTArchitect™ Reference Manual, v2021.2 and Later 67

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Add Vhdl Library

The optional <model>_bist.vhd_dcscript file will include the following lines:

read -f vhdl ../src/myuse3_use

read -f vhdl ../src/myuse1
read -f vhdl ../src/myuse2

Note
Currently the tool expects use targets to be subdirectories in a directory “../src” relative to
the DC directory.

Related Topics
Delete Vhdl Library
Report Vhdl Settings

68 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Alias

Alias
Legal Modes: All modes
Prerequisites: None
Specifies the shorthand name for a tool command, UNIX command, or existing command alias,
or any combination.
Usage
ALIas [ synonym { !unix-command; | dft-command; | alias-synonym; }… ]
Description
Specifies the shorthand name for a tool command, UNIX command, or existing command alias,
or any combination.

Issuing the Alias command with no arguments will list all of the current aliased commands. If
you specify a shorthand name (synonym) and one of the command types, that shorthand name
can substitute for the command and any arguments that you specify.

You utilize the full power of the Alias command when you take advantage of the repeatable
nature of the second string, intermixing any number of command types, and separating them
with semicolons.

The command strings can be parameterized by using the formal parameters, $1 through $9,
inserted in the command string in any order. When you issue the synonym as a command, you
must supply the actual argument, which is substituted into the command prior to execution.

You can provide an optional startup file that contains tool-specific commands to be executed
prior to other batch or interactive commands. The primary purpose of this file is to execute alias
commands that tailor the command language to your requirements.

When you invoke the tool, the tool will search for the startup file in the following locations, and
in the follow order of preference:

• The directory pointed to by the MGCDFT_STARTUP environment variable.

• The local invocation directory.
• Your home directory.
The first startup file the tool finds is the only one the tool executes if you have startup files in
multiple locations. If the tool does not locate a tool-specific startup file, the tool searches the
same locations for the generic startup file named .mgcdft_startup.

MBISTArchitect™ Reference Manual, v2021.2 and Later 69

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Alias

Arguments
• synonym
An optional string that specifies a shorthand name, or synonym, for the specified UNIX or
tool command, or for a previously defined alias synonym. Separate multiple commands with
semicolons.
o !unix_command
An optional string that consists of any UNIX command, with its arguments, or
script. You must proceed this string with an exclamation point (!) to differentiate it
from a tool-specific command.
o dft-command
An optional string that consists of any well-formed MBISTArchitect tool command
and its arguments.
o alias_synonym
An optional, repeatable string that consists of any synonym previously defined with
the alias command.
Examples
The following example defines the alias command, watch, which uses a formal parameter. The
next line invokes it and supplies the actual parameter:

alias watch !ps -e | egrep $1;

watch netscape

The result of issuing this alias is to list all the process ids associated with the browser processes
on the host machine. The next example defines the new command, findlockup, which searches
the current directory for Verilog files and invokes egrep on each one in turn, looking for “lckup”
names:

alias findlockup !find . -name \*.v -print -exec egrep lckup {} \;

You could then use that new command within another Alias command.

Related Topics
Dofile
System
History

70 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Algorithms

Delete Algorithms
Legal Modes: BISTGEN
Prerequisites: None
Removes from the current session any user defined algorithm that you have previously loaded
using the Load Algorithms command.
Usage
DELete ALgorithms algorithm_name1 [ algorithm_name2 ]...
Description
Removes from the current session any user defined algorithm that you have previously loaded
using the Load Algorithms command. The pre-defined algorithms that are pre-loaded by the
tool, and available at session startup, cannot be deleted using this command.

Arguments
• algorithm_name1
A required string that specifies the name of the user-defined algorithm that you want to
delete.
• algorithm_name2
An optional repeatable string that specifies the name(s) of additional user-defined algorithm
that you want to delete.
Examples
The following example shows loading a user-defined algorithm file, listing the current
user-defined algorithm, and then deleting the specified user-defined algorithm:

load algorithms my_uda

report algorithms
delete algorithms my_uda

Related Topics
Load Algorithms
Report Algorithms

MBISTArchitect™ Reference Manual, v2021.2 and Later 71

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Bisa Hardware

Delete Bisa Hardware

Legal Modes: BISTGEN
Prerequisites: None
Deletes BISA logic from the memories and BIST module.
Usage
DELete BIsa Hardware { -All | -MEMids list… }
Description
The given memory will no longer have BISA logic generated for them when the BIST controller
is generated. The -all switch is required, and not a default. You must use either the -all switch or
designate the memory number or numbers with this command.

Arguments
• -All
A required switch that directs the tool to delete all BISA logic from the memories and BIST
module. This switch resets all flags that have been previously set to generate BISA logic.
• -MEMids list…
A required switch and repeatable integer that removes BISA logic from a list of memories.
Specify the 0-based memory id number.
Examples
The following example shows the command used to delete BISA logic from two memories, 5
and 6, that were previously selected to have BISA logic:

delete bisa hardware -memids 5 6

Related Topics
Add Bisa Hardware
Report Bisa Hardware

72 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Clocks

Delete Clocks
Legal Modes: SETUP of the BIST Insertion Phase
Prerequisites: None
Removes the clock identity previously defined by the Add Clocks command from the specified
signals.
Usage
DELete CLocks clock_path_name... | -All
Description
Removes the clock identity previously defined by the Add Clocks command from the specified
signals. The signal(s) are no longer available for clock related connections. This command does
not remove the signal from your design.

Arguments
• clock_path_name
A required, repeatable string that specifies the path name of the previously defined clock
signal. Separate each path with a space.
• -All
A required switch that removes all clock definitions previously specified by the Add Clocks
command.
Examples
The following example removes a previously defined clock signal definition:

add clocks 0 my_clk1 0 my_clk2 1 my_clk3

delete clocks my_clk2
report clocks
+-------+-----------------+-----------------+
| CLK # | Clock Path Name | Clock Off_State |
+-------+-----------------+-----------------+
| 1. | my_clk1 | 0 |
| 2. | my_clk3 | 1 |
+-------+-----------------+-----------------+

Related Topics
Add Clocks
Report Clocks

MBISTArchitect™ Reference Manual, v2021.2 and Later 73

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Concurrent Group

Delete Concurrent Group

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Removes the specified controller group.
Usage
DELete COncurrent Group -All | group_name...
Description
Removes the specified controller group. By default, this command removes all controllers’
groups created using the Add Concurrent Group command. You can also specify certain
controller groups to remove.

Arguments
• -All
A required literal that specifies for the tool to remove all controller groups created for
concurrent testing.
• group_name
A required repeatable string that specifies the names of the controller groups you want to
remove.
Examples
The following example removes all controller groups that were previously created:

delete concurrent group -all

Related Topics
Add Concurrent Group
Report Concurrent Group

74 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Control Background

Delete Control Background

Legal Modes: BISTGEN
Prerequisites: None
Removes the specified control background.
Usage
DELete COntrol Background -All | algorithm
Description
Removes the specified control background. By default, this command removes all control
backgrounds created using the Add Control Background command. You can also specify
certain control backgrounds to remove.

Arguments
• -All
A required literal that specifies for the tool to remove all control backgrounds that were
added.
• algorithm
A required string that specifies the name of the algorithm to delete the control background
from.
Related Topics
Add Control Background
Report Control Background

MBISTArchitect™ Reference Manual, v2021.2 and Later 75

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Control Logic

Delete Control Logic

Legal Modes: BISTGEN
Prerequisites: None
Removes the specified control logic.
Usage
DELete COntrol Logic { { memory_name/port_name }… | -All }
Description
Removes the specified control logic.

Arguments
• memory_name/port_name
The memory_name specifies the name of the memory. The port_name specifies the name
of the port. These must be used in a pair to uniquely identify the control port for which the
logic is to be deleted.
The wild card character “*” is supported for specifying the memory_name or port_name.
You can specify all the control ports of a memory using memory_name/*, or you can
specify all the memories for a port using */control_port. Additionally you can specify all
control ports for all memories using */*. for example, if there are two memories R1 and R2,
and each have control ports WEN, CEN, REN, and OEN.
o Using R1/* will expand to R1/WEN, R1/CEN, R1/REN, and R1/OEN.
o Using */OEN will expand to R1/OEN and R2/OEN.
o Using */* will expand R1/WEN, R1/CEN, R1/REN, R1/OEN, R2/WEN, R2/CEN,
R2/REN, and R2/OEN.
• -All
A literal that specifies for the tool to remove all of the control logic that was specified using
the Add Control Logic command. The -all switch is functionally similar to using the wild
card */* as explained previously.
Examples
In the following example, there are two memories R1 and R2, and each have control ports
WEN, CEN, REN, and OEN:

add control logic */* -ext extraControl

delete control logic */WEN
add control logic R1/WEN -ext someControl
add control logic R2/WEN -ext someControl

Related Topics
Add Control Logic

76 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Control Logic

Report Control Logic

MBISTArchitect™ Reference Manual, v2021.2 and Later 77

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Controller

Delete Controller
Legal Modes: SETUP and BIST Mode of the Insertion Phase
Prerequisites: None
Deletes a specific memory BIST controller.
Usage
DELete COntroller controller_instance | -All
Description
Deletes a specific memory BIST controller, either added by using the Add Existing Controller
command, or the Add New Controller command, with a particular memory instances.

Arguments
• controller_instance
A required string that specifies the path and name of the controller instance.
• -All
A required switch that instructs the tool to delete all instances of the memory controller.
Related Topics
Add Existing Controller
Report Controllers

78 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Controllers Description

Delete Controllers Description

Legal Modes: SETUP (BIST Mode of the Insertion Phase and Gate-Level Verification Phase)
Prerequisites: None
Removes the controller description information that was loaded through the Load Controller
Description command.
Usage
DELete COntrollers Description
Description
Removes the controller description information that was loaded through the Load Controller
Description command.

Arguments
None.
Related Topics
Report Controllers Description
Load Controller Description

MBISTArchitect™ Reference Manual, v2021.2 and Later 79

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Data Backgrounds

Delete Data Backgrounds

Legal Modes: BISTGEN
Prerequisites: You must define background patterns using the Add Data Backgrounds command
before you can delete them.
Deletes the specified data background patterns from the setup configuration that were added
using the Add Data Backgrounds command.
Usage
DELete DAta Backgrounds pattern1 [ pattern2 ]... | -All
Description
Deletes the specified data background patterns from the setup configuration that were added
using the Add Data Backgrounds command.

Arguments
• pattern1 [ pattern2 ]
A repeatable string that specifies the binary or hexadecimal background pattern that you
want the tool to remove.
• -All
Deletes all background patterns from the setup configuration.
Examples
The following example shows a setup configuration that defines the preliminary steps to run the
tool, adds two background patterns, lists the current background patterns, and then deletes the
0011001100110011 pattern:

load library dft.lib

add memory models ram16x16
add data backgrounds 0011001100110011
add data backgrounds 0000111100001111
report data backgounds
delete data backgrounds 0011001100110011
run
save bist

Related Topics
Add Data Backgrounds
Report Data Backgrounds

80 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Diagnostic Monitor

Delete Diagnostic Monitor

Legal Modes: BISTGEN
Prerequisites: None
Deletes data items from the diagnostic module observation set.
Usage
DELete DIagnostic Monitor -All | item...
Description
Deletes data items from the diagnostic module observation set. The diagnostic module requires
at least one data item to run correctly. By deleting and adding individual data items, you can
effectively edit the scan output, and the ordering of data items to the monitor as it suits your
specific needs.

The tool produces an error if you generate a controller with diagnostic capability and initiate a
run with no designated data items in the diagnostic monitor. If you delete all of the data items to
clear the module, you must either reintroduce one or more data items to the module using the
Add Diagnostic Monitor command.

Arguments
• -All
A required argument that deletes all of the data items, which includes the standard set from
the current diagnostic module.
• item
A required and repeatable string that specifies the name of one or more diagnostic data items
you want to delete from the diagnostic module. You can specify any of the following items:
tstate, addr, addr_reg, rw_state, dout, failmap, memnum, test_addr_shift, portnum, and
port_isol_addr_reg_write.
Examples
The following example specifies that the memory number memnum be deleted from the current
diagnostic observation set:

delete diagnostic monitor memnum

Related Topics
Add Memory Models
Report Memory Models

MBISTArchitect™ Reference Manual, v2021.2 and Later 81

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Mbist Algorithms

Delete Mbist Algorithms

Legal Modes: BISTGEN
Prerequisites: You must define the MBIST algorithms using the Add Mbist Algorithms
command before you can delete them.
Deletes one or more MBIST algorithms from the setup configuration.
Usage
DELete MBist Algorithms { port# { algorithm1 [ algorithm2 ]… | -All } | Port_interaction }
Description
Deletes one or more MBIST algorithms from the setup configuration. This command will delete
the specified algorithms from all memories.

There are some limits on how the options can be used on one line. For example, you cannot use
a port-specific syntax on the same line as the Port_interaction string. Also, -All cannot be used
with algorithm names. You may need to issue the command multiple times.

Note
Even if you remove all the added MBIST algorithms, the port still retains the default
MBIST algorithms that were specified with the Setup Mbist Algorithms command.

Arguments
• port#
A required string that specifies the name of the port from which you want to delete an
algorithm.
o algorithm1 [ algorithm2 ]…
A repeatable string that specifies the algorithm that you want to delete from the
selected port. Select this algorithm for the list in the Usage section of this command.
Available algorithms are: addressdecoder_bg0, addressdecoder_bg1, checkerBoard,
col_march1, march1, march2, march3, retentionCB, ROM1 (same as ROM),
ROM2, topChecker, and unique <uda_name>.
o -All
A switch that deletes all of the user-added MBIST algorithms from the selected port.
• Port_interaction
A literal that removes the port_interaction algorithm that was added to the controller using
the Add Mbist Algorithm command.

82 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Mbist Algorithms

Examples
The following example shows a setup configuration that defines the preliminary steps to run the
tool, adds two testing algorithms, lists the current MBISTArchitect algorithms, and then deletes
the Unique algorithm from port 2:

load library dft.lib

add memory models ram16x16
add mbist algorithms 1 march1
add mbist algorithms 2 unique
report mbist algorithms
delete mbist algorithms 2 unique
run
save bist

Related Topics
Add Mbist Algorithms
Report Mbist Algorithms

MBISTArchitect™ Reference Manual, v2021.2 and Later 83

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Memory Models

Delete Memory Models

Legal Modes: BISTGEN
Prerequisites: You must add memory models using the Add Memory Models command before
you can delete them.
Deletes a memory models from the setup configuration that were added using the Add Memory
Modules command.
Usage
DELete MEmory Models { model_name… | -All }
Description
Deletes a memory models from the setup configuration that were added using the Add Memory
Modules command.

Arguments
• model_name
A repeatable string that specifies the name of one or more memory models you want to
delete from the setup configuration.
• -All
A switch that deletes all memory models from the setup configuration.
Examples
To delete the ram16x16 memory model from the current setup configuration, enter:

delete memory models ram16x16

Related Topics
Add Memory Models
Report Memory Models

84 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete New Port

Delete New Port

Legal Modes: SETUP of BIST Insertion Phase
Prerequisites: None
Deletes the specified port(s) created using the Add New Port command.
Usage
DELete NEw Port port_name… | -All
Description
Deletes the specified port(s) created using the Add New Port command.

Arguments
• port_name
A required repeatable string that specifies to the tool to delete the specified port created
using the Add New Port command.
• -All
A required switch that specifies to the tool to delete all ports created using the Add New Port
command.
Related Topics
Add New Port
Report New Port

MBISTArchitect™ Reference Manual, v2021.2 and Later 85

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Patterns

Delete Patterns
Legal Modes: INT (BIST Insertion and Gate-Level Verification Phases)
Prerequisites: None
Deletes all of the translated (integrated) patterns in memory, and sets the pattern set to empty.
Usage
DELete PAtterns
Description
Deletes all of the translated (integrated) patterns in memory, and sets the pattern set to empty.
This command helps in saving patterns to different files.

This can be achieved as follows:

• Add pattern translations for one or more controllers.

• Integrate patterns.
• Save patterns into a file.
• Delete patterns.
You can repeat the previous for another set of controllers.

Arguments
None.
Related Topics
Add Pattern Translation
Save Patterns
Report Pattern Translation

86 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Pattern Translation

Delete Pattern Translation

Legal Modes: INT (BIST Insertion and Gate-Level Verification Phases)
Prerequisites: None
Deletes all scheduled and all translated patterns. Removes specified controller instances from
the list of controllers to translate patterns.
Usage
DELete PAttern Translation -All | { controller_inst_name [ -Mode test_mode ] } |
{ concurrent_group_name [ { -Mode controller_inst_name/test_mode}... ] }
Description
Deletes all scheduled and all translated patterns. Removes specified controller instances from
the list of controllers to translate patterns. You specify the controller instance and mode
attributes of the controllers to be deleted. You can specify to remove all controller instances, a
single controller instance, or a concurrent group.

Note
This command will also delete all of the translated (integrated) patterns in memory, the
same way as the Delete Patterns command works.

Using With a Concurrent Group

When you use the Delete Pattern Translation command with a concurrent group, either you
must omit the -mode switch, which will delete all scheduled translations that match the
concurrent_group_name, or the exact same combination of -mode switches must be specified
that was specified when that group was added with the Add Pattern Translation.

Only one controller instance or concurrent group can be removed per issue of the Delete Pattern
Translation command.

Arguments
• -All
A switch that specifies to delete all scheduled patterns and all translated patterns, and
remove all controllers from the list of controllers to translate at the next Integrate Patterns
command.
• controller_inst_name
A repeatable string that specifies the instance name of the controller to remove from the list
of controllers to be translated at the next Integrate Patterns command.
• -Mode test_mode
A switch and string pair that specifies to remove the controller mode from translation that
have the name test_mode.

MBISTArchitect™ Reference Manual, v2021.2 and Later 87

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Pattern Translation

• concurrent_group_name
A required replaceable string that specifies a concurrent group name that you want to
remove from the list. You have an option to specify the mode of the concurrent group with
the following -mode switch.
• -Mode controller_inst_name/test_mode
An optional switch that use to specify the mode when an individual controller instance, or a
concurrent group to be deleted. The -mode switch can be optionally defined by a replaceable
string, mode_name, which is repeatable, allowing more than one mode to be specified.
When the -mode switch is used to define a concurrent_group, the -mode switch can be
specified by the optional string controller_instance_name/mode_name.
o controller_instance_name/mode_name…
An optional pair of repeatable, replaceable string values that use to specifically
define the -mode switch when it is used to specify a concurrent group of controller
instances. The combination of -mode controller_instance_name/mode_name… is
only valid when a concurrent group is specified on the command line. The
controller_instance_name specified with the -mode switch must be a valid
controller_instance that is used within the named concurrent group.
Examples
To delete all scheduled and all translated (integrated) patterns, and all controllers to be
translated at the next Integrate Patterns command, enter the following:

delete pattern translation -all

For the following example, assume you want to delete a concurrent group called grp1 from the
list to be translated. And assume that this concurrent group has been added to the list using Add
Pattern Translation command (see the example in the Add Pattern Translation command),
which specified the group instances of controllers and test modes. To remove this concurrent
group you need to specify the following commands. Note that they exactly duplicate the
attributes that were defined with the Add Pattern Translation command. Also note that this will
delete all of the translated (integrated) patterns in memory.

delete pattern translation grp1 -mode A1/a1 -mode B1/b

Related Topics
Add Pattern Translation
Report Pattern Translation
Delete Patterns

88 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Pin Mapping

Delete Pin Mapping

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Deletes all pins that were specified (added) through the Add Pin Mapping command.
Usage
DELete PIn Mapping target_pin_path_name… | -All
Description
Deletes all pins that were specified (added) through the Add Pin Mapping command.

Arguments
• target_pin_path_name
A string that describes the internal or top-level pin name to map to.
• -All
Deletes all of the requested mapping via all previous Add Pin Mapping commands.
Related Topics
Add Pin Mapping
Report Pin Mapping

MBISTArchitect™ Reference Manual, v2021.2 and Later 89

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Pin Sharing

Delete Pin Sharing

Legal Modes: SETUP and BIST (BIST Insertion Phase)
Prerequisites: None
Deletes the pin type that was specified (added) by the Add Pin Sharing command.
Usage
DELete PIn Sharing pin_type... | -All
Description
Deletes the pin type that was specified (added) by the Add Pin Sharing command.

Arguments
• pin_type
A required, repeatable string that specifies for the tool to delete the specified pin type.
An example of valid pin types would be test_resume_h, diag_clk, hold_l, debugz, bist_clk,
rst_l, etc.
• -All
A required literal that specifies for the tool to delete all added pin types.
Examples
To delete the debugz and hold_l pin types from the list of shared pin types, enter the following
command:

delete pin sharing debugz hold_l

Related Topics
Add Pin Sharing
Report Pin Sharing

90 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Signal Synchronization

Delete Signal Synchronization

Legal Modes: BISTGEN
Prerequisites: None
Deletes the signal out of the list to be synchronized in the BIST controller.
Usage
DELete SIgnal Synchronization -All | signal_name…
Description
Deletes the signal out of the list to be synchronized in the BIST controller. You need to specify
the signals that you want to delete from the list. Currently you can only synchronize (and delete)
the rst_l, test_h, and test_resume_h signals.

When you issue the Add Signal Synchronization command, the tool ensures that the generated
RTL for the BIST controller will add the necessary logic for synchronization.

Arguments
• -All
A switch that deletes all signal names available in the synchronization list.
• signal_name
A required repeatable string that names the signal to be deleted out of the synchronization
list. Currently only rst_l, test_h, and test_resume_h are supported.
Related Topics
Add Signal Synchronization
Report Signal Synchronization

MBISTArchitect™ Reference Manual, v2021.2 and Later 91

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Delete Verilog Include

Delete Verilog Include

Legal Modes: BISTGEN
Prerequisites: None
Deletes all or some of the Verilog ‘include directives previously specified by the command Add
Verilog Include.
Usage
DELete VErilog Include -All | include_file…
Description
Deletes all or some of the Verilog ‘include directives previously specified by the command Add
Verilog Include.

Arguments
• -All
A required switch that deletes all Verilog Include directives available to the Verilog
Controller.
• include_file
A repeatable, required string that names a file and its relative path.
Related Topics
Add Verilog Include
Report Verilog Include

92 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Delete Vhdl Library

Delete Vhdl Library

Legal Modes: BISTGEN
Prerequisites: None
Removes either a specified VHDL library clause or a specific use clause expression from the
VHDL code structure, and lets you remove the compiled package of an addressing incrementing
function.
Usage
DELete VHdl Library [ library_expression | -Use use_expression ]
Description
Removes either a specified VHDL library clause or a specific use clause expression from the
VHDL code structure, and lets you remove the compiled package of an addressing incrementing
function.

Arguments
• library_expression
The specific library clause to be removed.
• -Use use_expression
The specific use clause to be removed.
Examples
The following example deletes the testuse1 library clause:

delete vhdl library -use testuse1

The following example deletes the work library clause, and all of the uses associated with it:

delete vhdl library work

The following example deletes the work library clause and all of the uses associated with it:

delete vhdl library work -use testuse2

Related Topics
Add Vhdl Library
Set Vhdl Description
Report Vhdl Settings

MBISTArchitect™ Reference Manual, v2021.2 and Later 93

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Dofile

Dofile
Legal Modes: All
Prerequisites: The existence of a properly formatted file that contains legal MBISTArchitect
commands.
Sequentially executes the commands that reside in a specified file.
Usage
DOFile file_name [ -History ]
Description
Sequentially executes the commands that reside in a specified file. When you want to issue a
series of commands, instead of executing each command individually, you can place all the
commands in a “dofile” in their desired order and execute them, using just the Dofile command.
You can specify a dofile at invocation by using the -dofile switch with the MBISTArchitect
invocation command.

Error Conditions
If execution of any command in the dofile causes an error, the tool stops executing the
commands and displays an error message. Both tools ignore lines that begin with a double slash
(//), treating them as comments. See also the command Set Dofile Abort.

Arguments
• file_name
A required string that specifies the name of the file that contains the MBISTArchitect
commands. By default, the tool looks for the filename in the current working directory. If
filename is not in the current working directory, you must define the full pathname.
• -History
An optional switch that adds the commands in the dofile to the command history. If you
later execute a history command later, all the dofile commands will be included.
Examples
To cause the tool to use an external file named MBISTA_setup.do (located in the current
working directory) as the source for a series of commands, enter the following command:

dofile MBISTA_setup.do

The following is an example of the contents of a dofile with the filename BISTA_setup.do:

load library ram4x4.atpg

add me m ram4x4
add mb al 1 march2
run
save bist -rep
exit

94 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Dofile

Related Topics
Set Dofile Abort

MBISTArchitect™ Reference Manual, v2021.2 and Later 95

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Echo

Echo
Legal Modes: All
Prerequisites: None
Issues a user-defined string to the transcript or to a pathname, if you use one of the file
redirection operators.
Usage
ECHo string [ { > | >> } file_pathname ]
Description
Issues a user-defined string to the transcript or to a pathname, if you use one of the file
redirection operators.

Note
Commands that use either the > or >> redirection operators are checked first for correctness.
Syntax errors are displayed on screen prior to the command execution. The redirection
operator does not hide these errors.

Arguments
• string
A required string that you want echoed to the transcript.
• >file_pathname
An optional redirection operator and pathname pair used at the end of the argument list for
creating or replacing the contents of file_pathname.
• >>file_pathname
An optional redirection operator and pathname pair string used at the end of the argument
list for appending to the contents of the string file_pathname.
Examples
The following example redirects output from several commands into a single output file,
my_bist_report. The first command creates or replaces the my_bist_report file. The second and
following commands append to the same file.

echo "----------- libraries ------------" > my_bist_report

report libraries >> my_bist_report
echo "----------- memory models ----------" >> my_bist_report
report memory models >> my_bist_report

96 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Exit

Exit
Legal Modes: All
Prerequisites: None
Terminates the application tool program and terminates the BIST session, and returns control to
the operating system.
Usage
EXIt [ -Force ]
Description
Terminates the application tool program and terminates the BIST session, and returns control to
the operating system. If you did not save the results of the last Run command and did not use the
-force switch, a warning message is issued. You must specify whether to continue the session
and save the output (exit), or exit without saving (exit -force).

Arguments
• -Force
An optional switch that causes the tool to exit without saving any generated logic or files.
This command does not affect data previously saved with the Save Bist command.
Examples
To exit without saving, enter the following command:

exit -force

To exit with a previously saved output, enter the following:

exit

Related Topics
Save Bist
Save Patterns
Save Design

MBISTArchitect™ Reference Manual, v2021.2 and Later 97

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Help

Help
Legal Modes: All
Prerequisites: None
Displays the syntax for the specified command and provides quick access to information about a
specific command.
Usage
HELp [ command_name ] [ -Manual ]
Description
Displays the syntax for the specified command and provides quick access to information about a
specific command.

When you type Help followed by a command name, the tool displays the usage of that
command. If you type Help without a command name, the tool lists all the commands, without
their syntax. You can display a list of certain groups of commands by entering Help and a
keyword such as Add, Delete, Save, and so on.

Arguments
• command_name
An optional string that includes all or part of a command name.
• -Manual
An optional switch that opens the documentation for the specified command.
If you type HELp and include only the -manual switch, the tool opens the InfoHub, giving
access to all the installed manuals.
Examples
The following example gives the usage and syntax for the Add Mbist Algorithms command:

help add mbist algorithms

The tool displays the following:

Usage: ADD MBist Algorithms <port#> <algorithm1> [algorithm2] ...

Available Algorithms: March1 March2 March3 Unique CheckerBoard ROM1

98 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
History

History
Legal Modes: All
Prerequisites: None
Displays a list of previously executed commands.
Usage
HIStory [ list_count ] [ -Nonumbers ] [ -Reverse ]
Description
Displays a list of previously executed commands. This command is similar to the Korn shell
(ksh) history command in Unix. By default, this command displays a list of all previously
executed commands, including all arguments associated with each command, starting with the
oldest.

Note
The HISTFILE and HISTSIZE ksh environment variables do not control the command
history of the tool. The Save History command controls where the tool stores the history
file.

You can perform command line editing if you set the VISUAL or EDITOR ksh environment
variable to either emacs, gmacs, or vi editing. Please see the ksh(1) man page for specifics on
the various editing modes.

A leading number precedes each command line in the history list that indicates the order in
which the commands were entered.

Arguments
• list_count
An optional integer that specifies for the tool to display only the specified number
(list_count) of most recent executed commands. If no list_count is specified, the tool
displays all previously executed commands.
• -Nonumbers
An optional string that specifies for the tool to display the history list without the leading
numbers. This is useful for creating dofiles. The default displays the leading numbers.
• -Reverse
An optional switch that specifies for the tool to display the history list starting with the most
recent command rather than the oldest.

MBISTArchitect™ Reference Manual, v2021.2 and Later 99

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
History

Examples
The following command displays the history list with leading numbers, starting with the oldest
command:

history
1 help hist
2 dof instructor/fault.do
3 add memory models
4 add diagnostic monitor
5 set controller debug
6 run
7 report memory models
8 report diagnostic monitor
9 history

Related Topics
Dofile
Save History

100 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Insert Bist Logic

Insert Bist Logic

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Inserts the BIST access logic, mainly controllers, into the specified locations.
Usage
INSert BIst Logic [ -Top | -Notop ]
Description
Inserts the BIST access logic, mainly controllers, into the specified locations. Replaces
memories with memory collar blocks, connects the controller to its associated memories, and
hooks up the controller signals to the top-level design. This command does not save the
modified design to a file; to do so, use the Save Design command.

Arguments
• -Top
This switch instructs the tool to insert all scheduled controllers (using the Add Existing
Controller, and the Add New Controller commands) in the specified hierarchy in the design.
The tool then replaces each memory instance with its associated memory block, and then
stitches these memory blocks to their associated controllers.
The tool then connects specified controller signals (for example: test_h, fail_h, etc.) to the
top level.
By default, new ports are created at the top level and hook up to the controllers signals. You
can direct the tool to share with existing pins on the top level, or rename the newly created
ports by using the Add Pin Sharing command, and/or the Add Pin Mapping command.
This switch represents the tool default flow.
• -Notop
This switch instructs the tool to insert all scheduled controllers (using the Add Existing
Controller command, and the Add New Controller command) in the specified hierarchy in
the design.
The tool then replaces each memory instance with its associated memory block, and stitches
these memory blocks to the controller.
No top-level connection is performed.
Related Topics
Add Existing Controller
Add New Controller

MBISTArchitect™ Reference Manual, v2021.2 and Later 101

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Integrate Patterns

Integrate Patterns
Legal Modes: INT (BIST Mode of the Insertion and Gate-Level Verification Phases)
Prerequisites: None
Performs ATPG pattern translation and integration for the controllers specified with the Add
Pattern Translation command.
Usage
INTegrate PAtterns [ -MODE_Internal | -MODE_External ]
Description
Performs ATPG pattern translation and integration for the controllers specified with the Add
Pattern Translation command. The switches allow you to integrate internal or external patterns.
External patterns are integrated by default.

Note
If multiple Integrate Patterns commands are executed, then the test sets are accumulated.

Arguments
• -MODE_Internal | -MODE_External
When integrating with -MODE_External patterns, the pulse statements and timeplates
defined in the internal mode of the clock_run procedure should match the BIST clock and
timeplates used in the WGL patterns created for the specified controller. The cycles and
timeplates in the external mode of the clock_run procedure will replace the cycles in the
WGL patterns that match the internal mode cycles. The definition of -MODE_External is
that all user added internal signals are removed, and if present, a clock_run procedure is
applied to translate the internal cycles to external cycles with the appropriate external clocks
and control signals being forced and pulsed. The internal patterns will enable you to
simulate the design without having the PLL modeled, while the external patterns only
exercise the PLL external clocks and control signal.
Examples
In order to save both internal and external patterns, you must execute the Integrate Patterns
command twice as follows:

add patterns translation -all -procedure pll_clk

integrate patterns -mode_external
save patterns ext_pat.wgl -wgl -replace
save patterns ext_pat.v -verilog -replace
delete patterns // to clear patterns from memory
integrate patterns -mode_internal
save patterns int_pat.wgl -wgl -replace
save patterns int_pat.v -verilog -replace

102 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Integrate Patterns

Related Topics
Add Pattern Translation
Delete Pattern Translation
Delete Patterns

MBISTArchitect™ Reference Manual, v2021.2 and Later 103

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Load Algorithms

Load Algorithms
Legal Modes: BISTGEN. In Setup mode this command can only be used in an Add New
Controller Dofile.
Prerequisites: None
Loads user-defined algorithm from the specified files, and makes these algorithms available for
use within the current BIST controller generation session.
Usage
LOAd ALgorithms filename1 [ filename2 ]…
Description
Loads user-defined algorithm from the specified files, and makes these algorithms available for
use within the current BIST controller generation session. This command reads the given files
in the sequence they are supplied, and makes the algorithms that are contained in the files
available for use within the current BIST generation session.

If a user-loaded algorithm name clashes with an already loaded algorithm name, the new
algorithm replaces the existing algorithm, and the system issues a warning message. The pre-
defined algorithms that are pre-loaded and available at session startup, cannot be overwritten by
the user-supplied algorithms.

Arguments
• filename1 [ filename2 ]…
A repeatable, required string that specifies the user-defined algorithm file that you want to
load.
Examples
The following example shows loading a user-defined algorithm file named mycheckerboard in
BISTGEN mode:

load algorithms mycheckerboard

Related Topics
Add Mbist Algorithms
Delete Algorithms
Report Algorithms

104 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Load Controller Description

Load Controller Description

Legal Modes: SETUP (All Phases)
Prerequisites: None
Loads the specified controller description files that were written in the proprietary Siemens
EDA CTDF (Controller Test Description File) format.
Usage
LOAd COntroller Description { directory_name | file_path_name }…
Description
Loads the specified controller description files that were written in the CTDF format.

Arguments
• directory_name
A string that specifies the path and name of the directory that contains the controllers
description information. All files in the specified directory and subdirectories will be
searched, and the files with the .ctdf extension will be loaded. Files without the .ctdf
extension will be skipped.
• file_path_name
A string that specifies the path and file name of the file that contains the controller
description information.
Examples
The following command loads a CTDF named cpu.ctdf:

load controller description cpu.ctdf

Related Topics
Delete Controllers Description
Report Controllers Description
Load Design Objects

MBISTArchitect™ Reference Manual, v2021.2 and Later 105

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Load Design Objects

Load Design Objects

Legal Modes: SETUP of BIST Insertion Phase
Prerequisites: None
Loads the files that contain the RTL description of the controllers and their associated collars.
Usage
LOAd DEsign Objects { directory_path_name | file_path_name }…
Description
Loads the files that contain the RTL description of the controllers and their associated collars.

Note
The design object loaded with this command should not be confused with the libraries
loaded with the -Lverilog switch used during tool invocation.

Arguments
• directory_path_name
A repeatable string that specifies the path and name of the directory that contains the files
that need to be loaded into the tool.
This command will read all files in the directory with a .v or .vhd extension depending on
the flow you selected when you invoked the tool (Verilog or VHDL). All subdirectories
within the specified directory will be searched for files with an extension of .v or .vhd. Files
without a .v or .vhd extension will be skipped over.
• file_path_name
A repeatable string that specifies the path and name of the netlist file that contains the design
model.
Examples
To load the design object model named ram4x4_bist.v, enter the following command:

load design object ram4x4_bist.v

For the following example, assume the following:

d1 contains {f1.v, and f2.vhd}

d2 contains {f3.v, and f3.txt, and d1}

The following command will cause f1.v and f3.v to be loaded into the tool:

load design object d2

106 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Load Design Objects

// WARNING: File d2/f3.txt is not a design file ...Ignored

// WARNING: File d2/d1/f2.vhd is not a design file ...Ignored

Related Topics
Add Existing Controller

MBISTArchitect™ Reference Manual, v2021.2 and Later 107

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Load Library

Load Library
Legal Modes: SETUP (BIST Mode of the Insertion Phase) and BISTGEN (BIST Generation
Phase)
Prerequisites: None
Loads specific DFT MBIST library files that contain the memory models.
Usage
For SETUP (BIST Mode of the Insertion Phase)
LOAd LIbrary { directory_name | file_name }
For BISTGEN (BIST Generation Phase)
LOAd LIbrary file_name
Description
Note
This command has different uses dependent on whether you are in the SETUP (BIST Mode
of the Insertion Phase) or in the BISTGEN (BIST Generation Phase) of the tool.

For SETUP (BIST Mode of the Insertion Phase)

Loads specific DFT MBIST library files that contain the memory models. You cannot load
Verilog.v libraries with this command. The library file contains the memory models to be
inserted in the BIST logic.

Note
Do not use the Load Library command to load Verilog.v libraries in the BIST insertion
mode. Verilog.v libraries must be loaded at the invocation of the tool.

For BISTGEN (BIST Generation Phase)

Loads specific DFT MBIST library files that contain the memory models. The library file
contains the memory models to generate BIST logic.

Arguments
• directory_name
A string that specifies the path of the directory that contains the MBIST information. All
files in the specified directory and subdirectories will be searched. Files with the .mbist
extension will be loaded, and files without the .mbist extension will be skipped.
• file_name
A required string that specifies the path and file name of the file that contains the memory
model(s) to add.

108 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Load Procedure File

Load Procedure File

Legal Modes: SETUP of BIST Insertion Phase
Prerequisites: None
Loads a test_setup and/or a clock_run procedure file.
Usage
LOAd PRocedure File file_name
Description
Loads a test_setup and/or a clock_run procedure file.

Arguments
• file_name
A string that specifies the file name of the test_setup procedure file and/or the clock_run
procedure file you want to load.
Examples
load procedure file PLL_test_proc

Related Topics
Add Clocks
Add Pattern Translation
Add Pin Mapping
Add Pin Sharing

MBISTArchitect™ Reference Manual, v2021.2 and Later 109

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Printenv

Printenv
Legal Modes: All
Prerequisites: None
Prints out the values of the UNIX environmental variables.
Usage
printenv
Description
Prints out the values of the UNIX environmental variables. This command allows the UNIX
printenv command to be available as an MBISTArchitect command. The printenv command
will display on screen the UNIX environmental variables.

Arguments
None.
Related Topics
System

110 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Algorithms

Report Algorithms
Legal Modes: BISTGEN
Prerequisites: None
Generates a report that shows the pre-defined and user-defined algorithms that have been
loaded.
Usage
REPort ALgorithms [ -Verbose ]
Description
Generates a report that shows the pre-defined and user-defined algorithms that have been
loaded. The report is split into two sections that show the pre-defined algorithms, which are
loaded automatically by the tool, and the user-defined algorithms that have been loaded. By
default, only the algorithm names are reported.

Arguments
• -Verbose
An optional switch that displays more detailed information on the user-defined algorithms.
Examples
The following example reports the user-defined and pre-defined algorithms that have been
loaded:

report algorithms -verbose

MBISTArchitect™ Reference Manual, v2021.2 and Later 111

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Algorithms

step wCheckerBoardUp;
data checkerboard;
addr min, max, up, 1;
operation w;
step rCheckerBoardUp;
data checkerboard;
addr min, max, up, 1;
operation r;
step wInvCheckerBoardUp;
data invcheckerboard;
addr min, max, up, 1;
operation w;
step rInvCheckerBoardUp;
data invcheckerboard;
addr min, max, up, 1;
operation r;
repetition checkerBoard;
begin
step wCheckerBoardUp;
step rCheckerBoardUp;
step wInvCheckerBoardUp;
step rInvCheckerBoardUp;
end
test checkerBoard;
repetition checkerBoard;

Related Topics
Add Mbist Algorithms
Delete Algorithms
Load Algorithms

112 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Algorithm Steps

Report Algorithm Steps

Legal Modes: BISTGEN
Prerequisites: None
Generates a report that describes the number of clock cycles used by each algorithm step and
allows you to determine the memory test time and the point at which retention delays need to
occur.
Usage
REPort ALgorithm Steps
Description
Generates a report that describes the number of clock cycles used by each algorithm step and
allows you to determine the memory test time and the point at which retention delays need to
occur.

This command generates a report of each algorithm step, where each step comes from, and the
number of clock cycles each step requires. The report also displays a cumulative count of the
number of clock cycles for each algorithm step.

The report generated is in table format and contains the following columns:

• Clock Cycles
o Cumulative
o Incremental
• Memory
• Port
• Tstate
• Step
When using only a single memory or concurrent testing, the output does not include the
Memory field. Likewise, when using only a single port, the output does not include the Port
field.

Note
This command is only available after the Run command has been successfully completed.

Arguments
None.

MBISTArchitect™ Reference Manual, v2021.2 and Later 113

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Algorithm Steps

Examples
The following is an example of the use of this command and a example report:

report algorithm steps

Clock Cycles Mem Port Tstate Step
Cumul. Increm.
1 1 0000 start_state
2 1 0001 mem_loop_init
3 1 0011 mem_loop
7171 7168 0 1 0010 march2/march2/wBackgroundUp
28675 21504 0 1 0110 march2/march2/rwrInvBackgroundUp
50179 21504 0 1 0111 march2/march2/rwrBackgroundUp
71683 21504 0 1 0101 march2/march2/rwrInvBackgroundDown
93187 21504 0 1 0100 march2/march2/rwrBackgroundDown
100355 7168 0 1 1100 march2/march2/rBackgroundDown
143364 1 1011 mem_loop_end
143365 1 0011 mem_loop_1 (added to track looping)
172037 28672 1 1 0010 march2/march2/wBackgroundUp
258053 86016 1 1 0110 march2/march2/rwrInvBackgroundUp
344069 86016 1 1 0111 march2/march2/rwrBackgroundUp
430085 86016 1 1 0101 march2/march2/rwrInvBackgroundDown
516101 86016 1 1 0100 march2/march2/rwrBackgroundDown
544773 28672 1 1 1100 march2/march2/rBackgroundDown
716806 1 1011 mem_loop_end_1 (added to track looping)
716807 1 1001 complete_state

Related Topics
Add Mbist Algorithms
Setup Mbist Algorithms

114 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Bisa Hardware

Report Bisa Hardware

Legal Modes: BISTGEN
Prerequisites: None
Generates a report of the Built-In Self-repair Analysis logic repair status for all memories.
Usage
REPort BIsa Hardware
Description
Generates a report of the Built-In Self-repair Analysis logic repair status for all memories.

For each memory the report displays the following:

• Memory ID number
• Memory model name
• Repair strategy for the memory
• Number of redundant rows or columns, if repair is enabled
• Number of original rows or columns, if repair is enabled
• Selected format for reporting
Arguments
None.
Examples
An example of this command is as follows:

add memory model memA memB memC

add bisa hardware -row 1 -memids 0
add bisa hardware -row 2 -memids 1
report bisa hardware
Built-In Self-Analysis Hardware Setup
Memid Model Strategy Nredundant Noriginal Format
0 memA row 1 512
1 memB row 2 1024
2 memC none 0 0

Related Topics
Add Bisa Hardware
Delete Bisa Hardware

MBISTArchitect™ Reference Manual, v2021.2 and Later 115

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Clocks

Report Clocks
Legal Modes: All modes of the BIST Insertion Phase
Prerequisites: None
Reports the clock signals previously defined using the Add Clocks and Delete Clocks
commands.
Usage
REPort CLocks
Description
Reports the clock signals previously defined using the Add Clocks and Delete Clocks
commands.

Arguments
None.
Examples
add clocks 0 my_clk1 0 my_clk2 1 PLL/my_clk3
report clocks
+-------+-----------------+-----------------+
| CLK # | Clock Path Name | Clock Off_State |
+-------+-----------------+-----------------+
| 1. | my_clk1 | 0 |
| 2. | my_clk2 | 0 |
| 3. | /Pll/my_clk3 | 1 |
+-------+-----------------+-----------------+

Related Topics
Add Clocks
Delete Clocks

116 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Concurrent Group

Report Concurrent Group

Legal Modes: SETUP, BIST, and INT of the Insertion Phase
Prerequisites: None
Generates a report on information about all controller groups, including which controllers are
grouped together and if they are to be tested sequentially or individually.
Usage
REPort COncurrent Group -All | group_name…
Description
Generates a report on information about all controller groups, including which controllers are
grouped together and if they are to be tested sequentially or individually.

Arguments
• -All
Reports all of the information about all controllers, regardless of their grouping.
• group_name
Reports information pertaining to the specified group.
Examples
report concurrent groups
+----------+------------+-----------------+
| Group # | Group Name | Group Instances |
+----------+------------+-----------------+
| 1. | group1 | /contr_A |
| | | /contr_B |
| | | |
+----------+------------+-----------------+

Related Topics
Add Concurrent Group
Delete Concurrent Group

MBISTArchitect™ Reference Manual, v2021.2 and Later 117

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Control Background

Report Control Background

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on information about the control background added using the Add Control
Background command.
Usage
REPort COntrol Background
Description
Generates a report on information about the control background added using the Add Control
Background command. The report contains the name of the algorithm, the name of the memory,
the control port, and the background pattern that was specified.

Arguments
None.
Examples
The following is an example of report control background:

add control background WriteMask_short RAMx16/WEN xF000 x0F00 x00F0 x000F \

checkerboard
add control background WriteMask_short RAMx4/WEN walking0 checkerboard
report control background
// command: report control background
--------------------------------------------------------
Algorithm Memory Control Port Background
--------------------------------------------------------
WriteMask_short ramx16 WEN xf000
ramx4 WEN xe
WriteMask_short ramx16 WEN x0f00
ramx4 WEN xd
WriteMask_short ramx16 WEN x00f0
ramx4 WEN xb
WriteMask_short ramx16 WEN x000f
ramx4 WEN x7
WriteMask_short ramx16 WEN x5555
ramx4 WEN x5
WriteMask_short ramx16 WEN xaaaa
ramx4 WEN xa
--------------------------------------------------------

Related Topics
Add Control Background
Delete Control Background

118 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Control Logic

Report Control Logic

Legal Modes: BIST (BIST Generation Phase)
Prerequisites: None
Generates a report on information about control logic added using the Add Control Logic
command.
Usage
REPort COntrol Logic
Description
Generates a report on information about control logic added using the Add Control Logic
command. The report will contain the name of the memory control signal, the external control
signal name, and the active state.

Arguments
None.
Examples
For a memory block corresponding to RAM64, the port xControl will be created. For the
memory block corresponding to RAM32, ports nextControl and xCtrl will be reported in the
following example:

report control logic

//control logic report
-------------------------------------------------------------------------
| Memory | ControlPort Activestate | ExternalControl |ExtCtrlActiveState|
-------------------------------------------------------------------------
| RAM64 | WEN High | xControl |Low |
| | CEN0 Low | xControl |Low |
| | sCtrl Low | xControl |Low |
| | xCtrl Low | xControl |Low |
| RAM32 | WEN High | xControl |Low |
| | CEN0 Low | xControl |Low |
| | sCtrl Low | nextControl |Low |
| | xCtrl Low | nextControl |Low |
-------------------------------------------------------------------------

Related Topics
Add Control Logic
Delete Control Logic

MBISTArchitect™ Reference Manual, v2021.2 and Later 119

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Controllers

Report Controllers
Legal Modes: SETUP, BIST, and INT of the Insertion Phase
Prerequisites: None
Generates a report on the insertion of the specified memory BIST controller.
Usage
REPort COntrollers
Description
Generates a report on the insertion of the specified memory BIST controller.

Arguments
None.
Examples
The following example shows a sample output from the report controller command. The report
details the relationship between the memory and its associated collar name.

report controllers
+----+---------+-------------+-------------+----------------------------+
|CNTR| Contr | Controller | Memory | Memory Module |
| # | Instance| Module | Instance | Memory Module |
+----+---------+-------------+-------------+----------------------------+
| 1. | /contr_A|ram4x4_bist_0| /chip_A/memA|ram4x4_bist_0_ram4x4_block_0|
| | | | /chip_B/memA|ram4x4_bist_0_ram4x4_block_0|
| | | | | |
| 2. | /contr_B|my_controller| /chip_A/memC| my_collar |
| | | | /chip_B/memD| my_collar |
| | | | | |
+----+---------+-------------+-------------+----------------------------+

Related Topics
Add Existing Controller
Add New Controller
Delete Controller

120 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Controllers Description

Report Controllers Description

Legal Modes: All (BIST Mode of the Insertion and Gate-Level Verification Phases)
Prerequisites: None
Generates a report on information about controllers.
Usage
REPort COntrollers Description
Description
Generates a report on information about controllers. Controller information includes the names
of the controllers, the test mode they are in, and the pattern files associated with them.

Arguments
None.
Examples
The following example shows the result of issuing the Report Controllers Description
command:

report controllers description

// Controller Information:
// Controller: ram8x4_multi_bist
// Test Mode: run_bist
// Pattern File: ram8x4_multi_bist.wgl

Related Topics
Delete Controllers Description
Load Controller Description

MBISTArchitect™ Reference Manual, v2021.2 and Later 121

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Data Backgrounds

Report Data Backgrounds

Legal Modes: BISTGEN
Prerequisites: None
Generates a list of the data background patterns you added with the Add Data Backgrounds
command.
Usage
REPort DAta Backgrounds
Description
Generates a list of the data background patterns you added with the Add Data Backgrounds
command.

Adding and Deleting Patterns

During the process of preparing to run the tool, you can add or delete several data background
patterns using the Add Data Backgrounds and Delete Data Backgrounds commands. Use the
Report Data Backgrounds command to verify which are the currently defined data background
patterns prior to running the tool.

Arguments
None.
Examples
The following setup configuration includes the minimum commands required for an
MBISTArchitect session, and uses the Report Data Backgrounds command to display
background pattern information:

load library dft.lib

add memory models ram4x4 ram8x4
add data backgrounds 0011
add data backgrounds 1111
add mbist algorithms 1 march1
report data backgrounds

Data Backgrounds are:

1. 0011
2. 1111

run
save bist

Related Topics
Add Data Backgrounds

122 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Data Backgrounds

Delete Data Backgrounds

MBISTArchitect™ Reference Manual, v2021.2 and Later 123

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Design Name

Report Design Name

Legal Modes: BISTGEN.
Prerequisites: None
Reports the module and instance names generated by the tool for the current configuration.
Usage
REPort DEsign Name
Description
Reports the module and instance names generated by the tool for the current configuration. If
you have modified the design names using the Set Design Name command, the new names are
displayed in the report.

Arguments
None.
Examples
The following example shows the modified design names for a simple configuration with five
different memory models:

set design name controller -module my_controller

set design name collar -module my_collar
report design name
------------------------------------------------------------------------
Memory DesignType Module Instance
------------------------------------------------------------------------
****** Controller my_controller my_controller_instance
mem_0 Collar my_collar_mem_0 my_collar_mem_0_instance_0
mem_1 Collar my_collar_mem_1 my_collar_mem_1_instance_0
mem_2 Collar my_collar_mem_2 my_collar_mem_2_instance_0
mem_3 Collar my_collar_mem_3 my_collar_mem_3_instance_0
mem_4 Collar my_collar_mem_4 my_collar_mem_4_instance_0
------------------------------------------------------------------------

Related Topics
Report Pin Name
Set Design Name
Set Pin Name

124 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Diagnostic Monitor

Report Diagnostic Monitor

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on the data items from the scanned output of the diagnostic observation set.
Usage
REPort DIagnostic Monitor
Description
Generates a report on the data items from the scanned output of the diagnostic observation set.
This command is used without an argument. This command generates the observed output data
items from the diagnostic module in the order that you have specified with the Add Diagnostic
Monitor command or the order of the default standard set.

Data Items
The set of possible data items are: tstate, addr, addr_reg, rw_state, dout, failmap, memnum,
test_addr_shift, portnum, and port_isol_addr_reg_write.

Field Size (Diagnostic Register Width)

One major issue is that the software does not have the ability to calculate how big the fields are
until after the run command is issued in the BIST generation mode.

For example, if dout is included, the width of the dout part is the total width of data from all
memories. The same is true of address(es).

Another problem is that the fail_map is chosen as the widest memory, or the sum of all of the
memories for concurrent testing.

Another complication is that field size can (and in some cases has to) change if more memories
are added. Some of the values in the code are only valid after other code has executed within the
run command in BIST generation mode.

Arguments
None.
Examples
The following example creates and reports a customized diagnostic monitor set:

delete diagnostic monitor -all

add diagnostic monitor addr addr_reg failmap dout memnum portnum \
port_isol_addr_reg_write
report diagnostic monitor

MBISTArchitect™ Reference Manual, v2021.2 and Later 125

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Diagnostic Monitor

------------------------------------
Monitor Width
------------------------------------
addr 24
addr_reg 6
failmap 8
dout 8
memnum 1
portnum 1
port_isol_addr_reg_write 6
------------------------------------

Related Topics
Add Diagnostic Monitor
Run
Delete Diagnostic Monitor
Set Controller Debug

126 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Drc Rules

Report Drc Rules

Legal Modes: SETUP (BIST Insertion Phase)
Prerequisites: None
Generates a report of either specified rules or all rules for Design Rule Checking.
Usage
REPort DRc Rules [ rule_id [ -Verbose | violation_id ] ]
Description
Generates a report of either specified rules or all rules for Design Rule Checking.

This command exhibits two behaviors.

• In any mode of the BIST Insertion Phase, the Report DRC Rules command returns a list
of DRC rules based upon your command elections.
• In the Gate-Level Verification phase, the Report DRC Rules command displays either a
summary of all the Design Rule Check (DRC) violations, or the data for a specific
violation as follows:
o Rule identification number.
o Current number of rule failures.
o Violation handling.
o ATPG analysis flag (if used).
o Rule verbosity flag (if used).
Arguments
• rule_id
An optional string that specifies the rule name of the DRC rule that you want to display. To
see a summary list of all DRC Rules from which you can choose, run the command without
a rule name. If a rule name is given without either of the switches, -Verbose or violation_id,
the tool will produce a summary of only that rule. The summary gives a brief description,
the violation count, the status of handling, and whether or not the particular rule can be
modified by the Set DRC Handling command.
• -Verbose
An optional literal that specifies for the tool to report the details of all violations of the
specified rule.
• violation_id
An optional string that specifies for the tool to report the details of this specific violation.

MBISTArchitect™ Reference Manual, v2021.2 and Later 127

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Drc Rules

Related Topics
Set Drc Handling

128 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Environment

Report Environment
Legal Modes: BISTGEN
Prerequisites: None
Generates a report on the current values of all the “set” commands and the default names of the
scan-type pins.
Usage
REPort ENvironment
Description
Generates a report on the current values of all the “set” commands and the default names of the
scan-type pins.

Arguments
None.
Examples
The following example reports the current values of the “set” commands and the default names
of scan-type pins after loading a memory model:

report environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 129

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Environment

MBIST Environment Report:

-------------------------
MBIST Synthesis Environment: Synopsys
Message Handling: OFF.
Filenames set are:
No Filenames given, defaults using the memory model(s) will be used.
Default Algorithms: march2
Controller info:
Entity Name: default
Architecture Name: behavior
Compiled Memory Library: <none>
Memory test: Concurrent
Connect: yes
Compare: yes
Comparator test: no
Debug: no
Hold: no
Fail flag: common
Bist Insertion data: no
BSDArchitect data: no
Memory clock: non gated, from system mode clock
Invert clock: no
Inputs: 1
Input Pipeline Stages: 0
Output Pipeline Stages: 0
Instance Input Pipeline Delay Registers: All
Instance Output Pipeline Delay Registers: All
Input Mux: Outside controller
Prevent Simultaneous Access: No controller
Padding in Synthesized Complex Cycles: No
Asymmetric Cycles: Yes, aggressive
Retention delay cycle count: 100
Control Signal Names: Test: (+) test_h Fail: (+) fail_h
Test done: (+) tst_done Hold: (-) hold_l
Debug: (+) debugz Scan Out: scan_out
Clock: (+) bist_clk Reset: (-) rst_l
Test resume:(+) test_resume_h Start retention: (+) start_retention_h
Bypass mode: (+) Test_mode Bypass clock: (+) bp_clk
Bypass scan in: scan_in Bypass scan out: scan_out
Diag clock: (+) diag_clk Bypass scan enable: (+) scan_en
Compressor info:
No Compressor info available.

Related Topics
Add Memory Models
Set Message Handling
Set Dofile Abort

130 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Mbist Algorithms

Report Mbist Algorithms

Legal Modes: BISTGEN
Prerequisites: None
Generates a list of currently assigned algorithms and their corresponding ports.
Usage
REPort MBist Algorithms
Description
Generates a list of currently assigned algorithms and their corresponding ports. You might use
this command to verify which BIST algorithms currently exist in the setup configuration prior
to running the tool.

During the process of preparing to run the tool, you may add or delete a number of BIST
algorithms.

Arguments
None.
Examples
The following example shows a setup configuration that defines the preliminary steps to run the
tool, adds two testing algorithms, and then uses the Report Mbist Algorithms command to list
the algorithms:

load library dft.lib

add memory models ram32x22
add mbist algorithms 1 march1
add mbist algorithms 2 unique
report mbist algorithms
run
save bist
Report Algorithms:
algorithm1
algorithm2

Related Topics
Add Mbist Algorithms
Delete Mbist Algorithms
Setup Mbist Algorithms

MBISTArchitect™ Reference Manual, v2021.2 and Later 131

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Memory Instances

Report Memory Instances

Legal Modes: SETUP, BIST, and INT of the Insertion Phase
Prerequisites: None
Generates a report on the memory instances in the design and their associated information.
Usage
REPort MEmory Instances
Description
Generates a report on the memory instances in the design and their associated information.

Arguments
None.
Examples
Consider the following dofile with the following commands:

load library mbist_lib

report memory instance
set system mode bist
add new controller mbistc1 -dofile mbist1.do /U1/regs_picdram /U3/regs_picdram
add new controller /U2/mbistc2 -dofile mbist2.do /U2/regs_picdram
report memory instances

The result of the first report memory instances command is as follows:

+-----------------------------+-------------+------------+-------------+
| Mem Memory Memory | Model | Controller | Controller |
| # Instance Model | File | Instance | Module |
+-----------------------------+-------------+------------+-------------+
| 1. /chip_A/memA ram4x4 | ram4x4.atpg | noBIST | noBIST |
| 2. /chip_B/memA ram4x4 | ram4x4.atpg | noBIST | noBIST |
+-----------------------------+-------------+------------+-------------+

The result of the second report memory instances command is as follows:

+-----------------------------+-------------+-----------+--------------+
| Mem Memory Memory | Model | Controller| Controller |
| # Instance Model | File | Instance | Module |
+-----------------------------+-------------+-----------+--------------+
| 1. /chip_A/memA ram4x4 | ram4x4.atpg | /contr_B | ram4x4_bist_0|
| 2. /chip_B/memA ram4x4 | ram4x4.atpg | /contr_B | ram4x4_bist_0|
+-----------------------------+-------------+------------+-------------+

Related Topics
Add Existing Controller
Load Design Objects

132 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Memory Instances

Add New Controller

Load Library

MBISTArchitect™ Reference Manual, v2021.2 and Later 133

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Memory Models

Report Memory Models

Legal Modes: BISTGEN
Prerequisites: A library file must be loaded.
Generates a list of available or added memory models.
Usage
REPort MEmory Models [-Library] | [-Model model_name]
Description
Generates a list of available or added memory models. This command also provides detailed
information on specific memory models from the library file. When used without a switch, this
command displays a list of all the memory models added using the Add Memory Model
command.

Arguments
• -Library
An optional switch that lists all of the available memory models from the loaded DFT
library file(s).
• -Model model_name
An optional switch and string pair that reports details about the specified memory model
from the library file. The following information is displayed for the model:
o Pin declarations
o Vendor name
o Technology name
o Version number
o Additional information
o Word total
Examples
The following example loads a library containing memory models and reports the available
models:

load library dft.lib

report memory models -library
Available Memory Models:
Name Vendor Technology
------------------------------------------------
ram4x4 sample sample1
ram8x4 sample sample1

134 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Memory Models

The following example reports details for a specific memory model:

report memory models -model ram8x4

Model ram8x4 da_o3, da_o2, da_o1, da_o0, db_o3, db_o2, db_o1, db_o0 =
aa2, aa1, aa0, ab2, ab1, ab0, wena, wenb, da_i3, da_i2, da_i1, da_i0,
db_i3, db_i2, db_i1, db_i0

Vendor: sample
Technology: sample1
Version: 1.0
Additional info: 8x4 RAM, ports = 2rw
Number of Words: 8

The following example reports memory models that have been added to the design:

add memory models ram8x4

report memory models
Added Memory Models:
Name Vendor Technology
------------------------------------------------
ram8x4 sample sample1

Related Topics
Add Memory Models
Delete Memory Models

MBISTArchitect™ Reference Manual, v2021.2 and Later 135

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Misr Polynomial

Report Misr Polynomial

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on the taps that will be used for the specified size MISR polynomial.
Usage
REPort MIsr Polynomial { size }
Description
Generates a report on the taps that will be used for the specified size MISR polynomial. The size
of the polynomial can be up to 512 bits.

Arguments
• size
A required integer value that designates the size of the polynomial in bits. The size of the
polynomial can be up to 512 bits.
Examples
The following example shows how to report the taps for a MISR polynomial that is 256 bits in
size and has eight taps:

report misr polynomial 256

The tool will report the following tap locations:

223 192 161 129 97 64 32 0

Related Topics
Add Memory Models
Report Algorithm Steps
Setup Misr Polynomial
Add Mbist Algorithms
Setup Mbist Algorithms

136 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report New Port

Report New Port

Legal Modes: All modes of the BIST Insertion Phase
Prerequisites: None
Generates a report on the list of ports created using the Add New Port command.
Usage
REPort NEw Port
Description
Generates a report on the list of ports created using the Add New Port command.

Arguments
None.
Related Topics
Add New Port
Delete New Port

MBISTArchitect™ Reference Manual, v2021.2 and Later 137

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Pattern Translation

Report Pattern Translation

Legal Modes: INT (BIST Insertion and Gate-Level Verification Phases)
Prerequisites: None
Generates a report on the list of controllers to be translated during the next Run command.
Usage
REPort PAttern Translation
Description
Generates a report on the list of controllers to be translated during the next Run command. The
order listed is the order in which the patterns are output.

Arguments
None.
Examples
The following example reports the pattern translation before executing integrate pattern
command:

report pattern translation

//Controller instance scheduled for translation:
//Controller Instance: /GCA1RAM1KX32C8_multi_bist_inst Mode:run_bist\
Status:Pending
//Controller Instance: /R1_100X46C2_multi_bist_inst Mode:run_bist\
Status:Pending

The following example reports the pattern translation after executing the integrate pattern
command:

//Controller instance scheduled for translation:

//Controller Instance: /GCA1RAM1KX32C8_multi_bist_inst Mode:run_bist\
Status:Success
//Controller Instance: /R1_100X46C2_multi_bist_inst Mode:run_bist\
Status:Success

Related Topics
Add Pattern Translation
Delete Pattern Translation
Delete Patterns

138 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Pin Mapping

Report Pin Mapping

Legal Modes: SETUP, BIST, and INT of the Insertion Phase
Prerequisites: None
Generates a report on all pins that were specified through the Add Pin Mapping command.
Usage
REPort PIn Mapping
Description
Generates a report on all pins that were specified through the Add Pin Mapping command.

Arguments
None.
Examples
The following is an example pin mapping report:

report pin mapping

+--+-------------+--------+------+----------+-------------------+-------+
| #|TargetPinPath|Inverted|nonTop|PadControl|Instance Pin Path |LogicTyp|
+--+-------------+--------+------+----------+-------------------+-------+
|1.| testFail | NO | NO | N/A |/contr_A/fail_h | OR |
| | | | | |/contr_B/fail_h | |
| | | | | | | |
|2.| db2 | NO | NO | Yes |/chip_A/memA/bp_clk| |
| | | | | | | |
|3.| db1 | NO | NO | NO |/contr_B/test_h | |
| | | | | | | |
+--+-------------+--------+------+----------+-------------------+-------+

Related Topics
Add Pin Mapping
Delete Pin Mapping

MBISTArchitect™ Reference Manual, v2021.2 and Later 139

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Pin Name

Report Pin Name

Legal Modes: All (BIST Mode of the Insertion Phase)
Prerequisites: None
Generates a report on the pin type and its current name of top-level pins.
Usage
REPort PIn Name
Description
Generates a report on the pin type and its current name of top-level pins.

The tool treats retention pins differently than other pins. Retention pins are created when an
algorithm with retention is used. Therefore if you were to examine the pre-BIST generation run
report, and the post-BIST generation run report, you might notice some difference. This is the
normal action of the tool.

For a list of valid pin types see the command “Set Pin Name” on page 188, and for a listing of
pin categories, see Table 1-5 on page 188.

Arguments
None.
Examples
Before a run command is issued, the report might look like the following example:

report pin name

---------------------------------------
Type Name
---------------------------------------
test_h test_h
fail_h fail_h
tst_done tst_done
bist_clk clk
reset rst_l
test_resume test_resume_h
start_retention start_retention_h
---------------------------------------

After a run command is issued, the report might look like the following example:

run
// ** Successfully added BIST circuitry.

report pin name

140 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Pin Name

---------------------------------------
Type Name
---------------------------------------
test_h test_h
fail_h fail_h
tst_done tst_done
bist_clk clk
reset rst_l
---------------------------------------

In the following example, the top-level signal name fail_h was re-named to fail_signal_high
using the Set Pin Name command, and the following would be returned:

report pin name

---------------------------------------
Type Name
---------------------------------------
fail_h fail_signal_high

Related Topics
Set Pin Name

MBISTArchitect™ Reference Manual, v2021.2 and Later 141

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Pin Sharing

Report Pin Sharing

Legal Modes: SETUP, BIST, and INT of the Insertion Phase
Prerequisites: None
Generates a report on information about which pin types are sharing a single pin at SoC.
Usage
REPort PIn Sharing
Description
Generates a report on information about which pin types are sharing a single pin at SoC.

Arguments
None.
Examples
The following is an example pin sharing report:

report pin sharing

+--+----------+----------+---------------+--------+------+-----------+
|# | Pin Type |Logic Type|Target Pin Path|Inverted|nonTop|Pad Control|
+--+----------+----------+---------------+--------+------+-----------+
|1.| bist_clk | | topClk | NO | NO | N/A |
| | | | | | | |
|2.| tst_done | AND | testComplete | NO | NO | N/A |
| | | | | | | |
|3.| fail_h | OR | db1 | NO | NO | Yes |
| | | | | | | |
|4.| rst_l | | db2 | NO | NO | No |
| | | | | | | |
+--+----------+----------+---------------+--------+------+-----------+

Related Topics
Add Pin Sharing
Delete Pin Sharing

142 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Pipeline Registers

Report Pipeline Registers

Legal Modes: BISTGEN and SETUP, BIST, and INT of the Insertion Phase
Prerequisites: None
Generates a report on the information about your pipeline register setup.
Usage
REPort PIpeline Registers
Description
Generates a report on the information about your pipeline register setup.

Arguments
None.
Related Topics
Setup Pipeline Registers

MBISTArchitect™ Reference Manual, v2021.2 and Later 143

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Signal Synchronization

Report Signal Synchronization

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on the signals names in the current synchronization list.
Usage
REPort SIgnal Synchronization
Description
Generates a report on the signals names in the current synchronization list. You can only
synchronize the rst_l, test_h, and test_resume_h signals. When you issue the Add Signal
Synchronization command, the tool ensures that the generated RTL for the BIST controller will
add the necessary logic for synchronization.

Arguments
None.
Related Topics
Add Signal Synchronization
Delete Signal Synchronization

144 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Variables

Report Variables
Legal Modes: All modes of the BIST Insertion and Generation Phase
Prerequisites: None
Generates a report on the user-defined variables and values.
Usage
REPort VAriables
Description
Generates a report on the user-defined variables and values. This command displays variables
previously defined and their corresponding values. This reported list does not include
environment variables defined in the shell environment.

For more information, refer to “User-Defined Variables”.

Arguments
None.
Examples
In this BIST Generation example, lib, pattern, and lang variables are defined as:

$lib = ram_model.mbista
$pattern = 0101
$lang = -verilog
load library $lib
add mem model mem1
add data background ${pattern}${pattern}
run
save bist $lang -replace
report variables

Consider the following BIST Generation and Insertion example bist_gen.do and bist_ins.do
dofiles:

bist_gen.do
reset state
add memory model $mem $mem
......

MBISTArchitect™ Reference Manual, v2021.2 and Later 145

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Variables

bist_ins.do
$mem = ram256x16
$path = /U1/U2
$mode = bist
report variables
$GO = insert bist logic
load library mbista.lib
set system mode $mode
add new controller my_cntr -dofile bist_gen.do \
${path}/memA ${path}/memB
$GO
$mode = INT
set system mode $mode
report variables
.....

The output of the first Report Variables command will be as follows.

path = /U1/U2
mem = ram256x16
mode = bist

The output of the second Report Variables command will be as follows.

path = /U1/U2
GO = insert bist logic
mem = ram256x16
mode = INT

Related Topics
User-Defined Variables

146 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Verilog Include

Report Verilog Include

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on the Verilog ‘include directives previously specified by the command Add
Verilog Include.
Usage
REPort VErilog Include
Description
Generates a report on the Verilog ‘include directives previously specified by the command Add
Verilog Include.

Arguments
None.
Related Topics
Add Verilog Include
Delete Verilog Include

MBISTArchitect™ Reference Manual, v2021.2 and Later 147

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Report Version Data

Report Version Data

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on the MBISTArchitect software version number.
Usage
REPort VErsion Data
Description
Generates a report on the MBISTArchitect software version number.

Arguments
None.
Examples
The Report Version Data command produces an output similar to the following:

report version data

MBISTArchitect v8.2003_4.10 Mon Nov 24 05:15:32 PDT 2003

Related Topics
Report Environment

148 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Report Vhdl Settings

Report Vhdl Settings

Legal Modes: BISTGEN
Prerequisites: None
Generates a report on all of the user specified VHDL libraries and uses.
Usage
REPort VHdl Settings
Description
Generates a report on all of the user specified VHDL libraries and uses.

Arguments
None.
Related Topics
Add Vhdl Library
Set Vhdl Description
Delete Vhdl Library

MBISTArchitect™ Reference Manual, v2021.2 and Later 149

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Reset State

Reset State
Legal Modes: BISTGEN
Prerequisites: None
Eliminates the effects of commands issued since tool invocation.
Usage
RESet STate [ -All ]
Description
Eliminates the effects of commands issued since tool invocation. This command is most useful
after you have saved a BIST controller for a set of memories and now want to generate a
controller for a different set of memories. This command has two levels of reset. Reset state
(without the -All switch) restores the defaults for everything except loaded libraries. Reset State
-All restores the defaults and eliminates the loaded libraries.

Note
Resetting the tool deletes all pending BIST results. You might want to use the Save Bist
command before resetting the state.

By default, using the Reset State command does not clear previously loaded libraries. If you
want to clear all settings, including the loaded libraries, use the -all switch.

Arguments
• -All
An optional switch that restores the defaults and deletes the loaded libraries.
Examples
The following example shows one use of the Reset State command:

load library dft.lib

add memory models ram16x16
run
reset state
add memory models ram16x16
set controller hold -on
run
save bist

This example shows a progression where you load the dft.lib library, add the ram16x16 memory
model, and use the default BIST configuration. You then decide that you want to generate hold
logic for your controller. You use the Reset State command to reset the state of the tool while
keeping the loaded library. Because you do not use the -all switch, there is no need to reload the
same library. However, all other information is reset, so you must add the memory model again.

150 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Reset State

Related Topics
Run

MBISTArchitect™ Reference Manual, v2021.2 and Later 151

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Run

Run
Legal Modes: BISTGEN
Prerequisites: You must define any BIST setup commands during the session before using the
Run command.
Instructs the tool to generate BIST logic and other test logic for the controller memory or
design, based on your setup configuration.
Usage
RUN
Description
Instructs the tool to generate BIST logic and other test logic for the controller memory or
design, based on your setup configuration.

You can execute the Run command more than once per session.

Arguments
None.
Examples
The following setup configuration includes the minimum commands required for an
MBISTArchitect session that generates and saves BIST logic:

load library dft.lib

add memory models ram16x16
set controller hold -on
run
save bist

This example shows a progression wherein you load library dft.lib, add the ram16x16 memory
model, use the default BIST structure, and then issue the Run command in the BIST Generation
(BISTGEN) mode to generate the BIST logic. You then save the output in the desired format. In
this example, you use no switches with the Save Bist command, so the tool generates the default
Verilog file formats.

Related Topics
Reset State
Setup Diagnostic Clock
Save Bist

152 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Access File

Save Access File

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Saves the controller access file generated in the BIST Mode of the Insertion Phase to a file you
specify.
Usage
SAVe ACcess File [ file_name ] [ -Replace ]
Description
Saves the controller access file generated in the BIST Mode of the Insertion Phase to a file you
specify.

Arguments
• file_name
An optional string that specifies the name of the file.
By default, the access file is saved to the current directory with the default name of
<top_level_design_filename>.access, where the top-level design_filename is the name of
the file that contains the top module.
• -Replace
An optional switch that specifies that you want to replace an existing file, if there is one. By
default, the file is not replaced.
Examples
The following command saves the access file to the current directory with the name
design1.access and replaces the file if it already exists:

save access file design1.access -replace

Related Topics
Insert Bist Logic
Save Driver Files
Save Design

MBISTArchitect™ Reference Manual, v2021.2 and Later 153

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save Bist

Save Bist
Legal Modes: BISTGEN
Prerequisites: You must first issue the Run command.
Saves the BIST output files in the specified format.
Usage
SAVe BIst [ -VHdl | -VErilog ] [ -Script [ -Format { Tcl | Dcshell } ] ] [ -Replace ]
[ -Write_diag_config ]
Description
Saves the BIST output files in the specified format. Upon invocation, the tool has a set of
default names that it uses when saving the output. You can save only one format at a time;
however, you can use the Save Bist command more than once per session.

Note
If you add multiple memory models during the setup phase of running the tool, the default
file names will include the term “multi” within the name.

You can use the Setup File Naming command to explicitly redefine the names of your saved
output files.

Arguments
• -VHdl
An optional switch that saves files in VHDL format.
• -VErilog
An optional switch that saves files in Verilog format. This is the default.
• -Script
An optional switch that generates a design compiler script to synthesize the BIST-generated
RTL.
• -Format Tcl | Dcshell
An optional switch and literal pair that specifies the format of the design compiler script that
is generated by the -Script switch. The default is Tcl.
• -Replace
An optional switch instructs the tool to overwrite existing output files of the same name.
• -Write_diag_config
An optional switch that writes the diagnostic configuration file for use with the Diagnosis
tool. The file has the .diagcfgb file extension.

154 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Bist

Examples
To save the MBISTArchitect Verilog output files, enter the following:

load library ram4x4/design/ram4x4.atpg

add memory models ram4x4
run
save bist -verilog
Saving MBIST Data:
Saved ram4x4_bist.v
Saved ram4x4_bist_con.v
Saved ram4x4_tb.v

To save a dc script file in Tcl format, enter the following:

setup file naming -script mycntr_dc

run
save bist -verilog -script -replace

MBISTArchitect™ Reference Manual, v2021.2 and Later 155

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save Bist

# Mon Sep 15 10:22:32 2008

# Design Compiler Script file for Verilog model mycntr.v
# To run this file use the following commands:
# at unix prompt: % dc_shell-t -f mycntr_dc

# Initialize DC variables.
set hdlin_translate_off_skip_text "TRUE"

# Define work library.

if {! [file exists WORK]} {exec mkdir WORK}
define_design_lib WORK -path "./WORK"

# Read input design file

read_file -format verilog mycntr.v
read_file -format verilog mycntr_con.v

# Current design is the BIST controller.

current_design mycntr
check_design

# Timing specification.
create_clock -period 100 -waveform {0 50} bist_clk
# Avoid clock buffering during synthesis.
set_clock_transition 0.0 bist_clk
set_dont_touch_network bist_clk

# Prevent feedthroughs in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile design.
uniquify
compile -map_effort medium

# Report design results.

report_area >> transcript_verilog_area.log
report_timing -path full -delay max >> transcript_verilog_timing.log

# Current design is Memory Block 0.

current_design collar_1
check_design

# Prevent feedthroughs in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile design.
uniquify
compile -map_effort medium

# Report design results.

report_area >> transcript_verilog_area.log
report_timing -path full -delay max >> transcript_verilog_timing.log

# Current design is the BIST Connected Model.

current_design mycntr_con
check_design

# Write final netlist for BIST Controller and Memory Blocks.

write -format verilog -hierarchy -output mycntr_con_g.v

156 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Bist

exit

Related Topics
Run
Setup Clock Period
Setup Diagnostic Clock

MBISTArchitect™ Reference Manual, v2021.2 and Later 157

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save Controllers Mapping

Save Controllers Mapping

Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Use to create a mapping file.
Usage
SAVe COntrollers Mapping controller_map_file [-Replace]
Description
Use to create a mapping file. Saves to file, a mapping between controller/memory instance and
the controller model. This mapping information is saved as a list of commands that is
understandable by the Diagnosis engine.

Arguments
• controller_map_file
A required string that specifies the name of the controller mapping file.
• -Replace
An optional switch that over-writes any previous controller_map_file.
Related Topics
Save Bist

158 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Design

Save Design
Legal Modes: BIST Mode of the Insertion Phase
Prerequisites: None
Saves the inserted BIST logic and original design to new files.
Usage
SAVe DEsign [ -Directory name ] [ -Suffix suffix_name ] [ -Include { Rtl | None } ]
[ -BlackBox ] [ -All ] [ -Replace ]
Description
Saves the inserted BIST logic and original design to new files. By default, only the modified
design files are saved to the current directory.

Preventing the Writing of Verilog Library Files

You can prevent the tool from writing out Verilog library elements, thus treating them as “don’t
touch” modules, by specifying the -Lverilog switch on the MBISTArchitect invocation
command.

Additionally, any Verilog modules listed between the celldefine and endcelldefine are also
treated as untouchable library modules.

Note
The tool does not save library cells.

Arguments
• -Directory name
An optional literal and string pair to specify the location of the saved files. If you do not
specify this option, the default directory is the directory in which the original design resides.
• -Suffix suffix_name
An optional literal and string pair that specifies the suffix for the names of all files written
out. The file names have the following form: xxxx_suffix_name.{vhd | v}. If you do not
specify a suffix name, the default suffix is “_mbist”. See the Example section for the usage
of this switch.
• -Include
An optional switch that specifies the tool to include either RTL files, or none.
Rtl — An optional item that specifies the tool to include all of the controllers RTL files
in the TopLevelDesignFileName_suffix.v. This is the default.
None — An optional item that specifies that you do not want to include any of the
controller’s RTL files in the TopLevelDesignFileName_suffix.v design file.

MBISTArchitect™ Reference Manual, v2021.2 and Later 159

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save Design

• -BlackBox
An optional switch that specifies the tool to write out the top-level module interface. This
switch is useful when you are doing the hierachical flow.
• -All
An optional switch that instructs the tool to save all inputs and outputs. If you do not specify
this option, the tool only saves files that have changed in the current session.
• -Replace
An optional switch that specifies to replace the file if it already exists. By default, the file is
not replaced.
Examples
Assuming that your top-level design file is named top.v, the following command will save the
top_mbist.v and overwrite the original file:

save design -suffix mbist -include rtl -replace

Note that you cannot specify a full output name as a target to the Save Design command. You
can name a suffix or output directory, but not the entire filename.

Related Topics
Add Existing Controller
Save Access File
Add New Controller
Save Driver Files

160 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Driver Files

Save Driver Files

Legal Modes: BIST Mode of the Insertion Phase
Prerequisite: You must first execute the Save Design command.
Exports dofiles for gate-level verification, boundary scan insertion, and logic synthesis.
Usage
SAVe DRiver Files [ -Logic_synthesis file_name [ -Format { Tcl | Dcshell } ] ]
[ -Bsda file_name ] [ -Replace ]
Description
Exports dofiles for gate-level verification, boundary scan insertion, and logic synthesis.

Arguments
• -Logic_synthesis file_name
An optional literal and string pair that specifies the name of the dofile used as an input to the
Synopsys Design Compiler™® synthesis tool. The dofile contains commands to synthesize
the modules that were added in the insertion phase.
• -Format Tcl | Dcshell
An optional switch and literal pair that specifies the format of the logic synthesis dofile. The
default is Tcl.
• -Bsda file_name
An optional literal and string pair that specifies the name of the BSDA dofile used as an
input to BSDArchitect.
• -Verification file_name
An optional literal and string pair that specifies the name of the driver file used as input to
the gate-level verification phase.
• -Replace
An optional switch that specifies to replace the file if it already exists. By default, the file is
not replaced.
Examples
To save the dofiles in the current directory and replace any existing files, enter the following
command:

save driver files -logic_synthesis design_compiler.do -replace

To save a dc script in Tcl format, enter the following command:

save driver files -logic_synthesis dc.do -replace

MBISTArchitect™ Reference Manual, v2021.2 and Later 161

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save Driver Files

# File Type: Design Compiler Tcl Script

# Date Created: Mon Sep 15 10:22:32 2008
# Tool Version: MGC MBISTArchitect v8.2008_4.10-prerelease
# To run the file:
# TCL format: dc_shell-t -f dc.do

# Initialize DC variables.*/
set hdlin_translate_off_skip_text "TRUE"
set bus_naming_style %s_%d_

# Define work library */

if {! [file exists WORK]} {exec mkdir WORK}
define_design_lib WORK -path "./WORK"

# Read input design file

read_file -format verilog mgc_utility.v

current_design mgc_latch
check_design

# Prevent feedthroughs in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile design
uniquify
compile -map_effort medium

# Report design results

report_area >> transcript_verilog_area.log report_timing -path full -delay
max >> transcript_verilog_timing.log current_design mgc_inv check_design

# Prevent feedthroughs in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile design
uniquify
compile -map_effort medium

# Report design results

report_area >> transcript_verilog_area.log report_timing -path full -delay
max >> transcript_verilog_timing.log current_design mgc_and check_design

# Prevent feedthroughs in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile design
uniquify
compile -map_effort medium

# Report design results

report_area >> transcript_verilog_area.log report_timing -path full -delay
max >> transcript_verilog_timing.log

# write out synthesized netlist

write -format verilog -hierarchy -output mgc_utility_gate.v { mgc_latch
mgc_inv mgc_and }

exit

162 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Driver Files

Related Topics
Save Access File
Save Design

MBISTArchitect™ Reference Manual, v2021.2 and Later 163

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save History

Save History
Legal Modes: All (All Phases)
Prerequisites: None
Saves the command line history file of previously executed commands to the specified file.
Usage
SAVe HIstory file_name [ -Replace ]
Description
Saves the command line history file of previously executed commands to the specified file. To
execute the file, use the Dofile command.

Arguments
• file_name
A required string that specifies the name of the file in which the tool saves the command line
history list.
• -Replace
An optional switch that specifies for the tool to overwrite the contents of filename, if a file
by that name already exists.
Examples
The following example displays the current history list, then saves it in a file called my_history,
which already exists:

dofile instructor/fault.do
run
history -nonumbers
save history my_history -replace

Related Topics
Dofile
History

164 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Save Patterns

Save Patterns
Legal Modes: INT (BIST Insertion and Gate-Level Verification Phases)
Prerequisites: None
Saves the “in memory” patterns to the specified file.
Usage
SAVe PAtterns filename [-Replace] [-Wgl | -VErilog | -Stil | -Fjtdl]
[-PARAMeter parameter_file_name]
Description
Saves the “in memory” patterns to the specified file. This command is available in the
Integration mode of the BIST Mode of the Insertion Phase as well as the Integration mode of the
gate-level verification phase.

Arguments
• filename
A string that specifies the path and prefix name of the pattern file. By default, the file is
saved to the current directory.
• -Replace
An optional switch that specifies to replace the file if it already exists. By default, the file is
not replaced.
• -Wgl
An optional switch that specifies the format of the patterns file is WGL. This is the default.
• -VErilog
An optional switch that specifies the format of the patterns file is Verilog.
• -Stil
An optional switch that specifies the format of the patterns file is STIL.
• -Fjtdl
An optional switch that specifies the format of the patterns file is Fujitsu TDL format.
• -PARAMeter parameter_file_name
An optional switch that specifies an optional parameter file which contains keyword-based
directives that are used to customize certain features of the pattern output files.
Specifying the keyword SIM_NO_MEASURE_IN < 1 | 0 > in the parameter file and setting
it to 1 will cause the Verilog testbench to not measure the value it forces on the input side of
a bidirectional pin. If not specified, the default will cause the testbench to measure the value
that was forced.

MBISTArchitect™ Reference Manual, v2021.2 and Later 165

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Save Patterns

The keyword WGL_PATTERN_NAME “string” can be used to specify the pattern name in
the WGL pattern file. The default, if this is not specified, is Bist_test.
Examples
The following example saves all mapped SoC patterns to a WGL file. The -replace switch
replaces the file if it already exists:

save patterns mapped_soc.wgl -replace -wgl

Related Topics
Add Pattern Translation
Delete Patterns
Report Pattern Translation
Save Access File
Save Design

166 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Bist Insertion

Set Bist Insertion

Legal Modes: BISTGEN
Prerequisites: None
Determines whether BIST insertion driver information is produced.
Usage
SET BIst Insertion -OFf | -ON
Description
Determines whether BIST insertion driver information is produced. The default of the tool is to
inline every mux regardless of this command being set to on or off. See also the Setup Design
Sharing command.

Arguments
• -OFf
A required switch that instructs the tool not to produce MBISTArchitect insertion driver
information.
• -ON
A required switch that instructs the tool to produce MBISTArchitect insertion driver
information. This includes adding the necessary attributes and parameters to the controller
and/or the collar.
Examples
The following example turns on the set BIST insertion driver information:

set bist insertion -on

Related Topics
System
Report Environment
Setup Design Sharing

MBISTArchitect™ Reference Manual, v2021.2 and Later 167

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Bsdarchitect

Set Bsdarchitect
Legal Modes: BISTGEN
Prerequisites: None
Use this command if you intend to insert boundary scan logic with BSDArchitect™ following
BIST insertion.
Usage
SET BSdarchitect -OFf | -ON
Description
Use this command if you intend to insert boundary scan logic with BSDArchitect™ following
BIST insertion. It generates the required specparams/attributes and additional ports on the BIST
controller for BSDA support. BSDA requires that a data register have both input and output
pins. By default, MBISTArchitect does not meet this requirement and creates only a diagnostic
output pin for the BIST controller.

If you set this command ON, MBISTArchitect performs the following two necessary processes:

1. Creates a pseudo input pin for the data-register in the output netlist.
2. Generates additional specparams/attributes that define the required number of shift
cycles to complete the scan out of the diagnostic data.
Once you have generated and inserted a BSDA-compliant design, issue the Save Driver Files
command to generate a BSDArchitect dofile that connects the BIST configuration to the TAP
controller.

Arguments
• -OFf
A required switch that specifies to use the default BIST configuration, which is not
compliant with BSDArchitect standards. This is the default upon invocation.
• -ON
A required switch that enables BSDA support and configures the BIST circuitry to be
compliant with BSDArchitect.
Examples
The following example creates a BSDArchitect-compliant BIST configuration:

set bsdarchitect -on

Related Topics
Save Driver Files
Report Environment

168 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Clock Gating

Set Clock Gating

Legal Modes: SETUP (BIST Insertion Phase)
Prerequisites: None
Instructs the tool to insert clock gating logic on the bist_clk input of the bist controller.
Usage
SET CLock Gating ON | OFf
Description
Instructs the tool to insert clock gating logic on the bist_clk input of the bist controller. By
default, the tool does not insert any clock gating logic on this input. This command does not
affect the gating of the misr_clk or bisa_clk.

Figure 1-7 shows the clock gating logic that is inserted to avoid any glitches in the clock line.

Figure 1-7. Logic Inserted Using Set Clock Gating

Arguments
• ON
A switch that instructs the tool to insert the gating logic that is shown in Figure 1-7.
• OFf
A switch that overrides the ON setting.

MBISTArchitect™ Reference Manual, v2021.2 and Later 169

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Clock Gating

Related Topics
Setup Controller Clock
Setup Diagnostic Clock
Setup Memory Clock
Report Environment

170 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Comparator Test

Set Comparator Test

Legal Modes: BISTGEN
Prerequisites: None
Defines comparator test states and instructs the tool whether to include comparator test states in
the finite state machine of the controller.
Usage
SET COmparator Test -OFf | -ON
Description
Defines comparator test states and instructs the tool whether to include comparator test states in
the finite state machine of the controller. Comparator tests can only be applied to a RAM since a
comparator test requires data to be written into the memory; therefore, this test could not be
applied to a ROM. Note that the comparator test is always executed first, before any other tests
or algorithms.

The test consists of the following sequence:

1. Write data to address 0.

2. Read address 0 and compare against inverse of data written. Expect fail flag to be set. If
the Setup Controller Debug is On, the tool will also scan out memory failure data.
3. Read address 0 and compare with data written in 1. Reset the fail flag if it was read OK,
otherwise the fail flag will stay asserted. The testbench will check that the fail flag goes
high and then low again at the appropriate times.
Arguments
• -OFf
A switch that instructs the tool to leave the finite state machine in the controller void of any
comparator test states. This is the invocation default; the controller does not test the
comparator.
If you use this command, you must use either the -off or -on switch.
• -ON
A switch that instructs the tool to add the comparator test to the controller’s finite state
machine.
If you use this command, you must use either the -off or -on switch.
Examples
This example shows how to add the comparator test to the controller’s finite state machine:

set comparator test -on

MBISTArchitect™ Reference Manual, v2021.2 and Later 171

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Comparator Test

Related Topics
Setup Observation Scheme
Report Environment
Setup Comparator Failflag

172 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Controller Debug

Set Controller Debug

Legal Modes: BISTGEN
Prerequisites: None
Instructs the tool to generate a diagnostics engine inside the controller.
Usage
SET COntroller Debug { -OFf | { -ON [ -NOSynchronization ] [ -NOHold ] [ -NORestart ]
[ -Recovery number ] [ -Parallel_output ] } }
Description
Instructs the tool to generate a diagnostics engine inside the controller.

With the Setup Comparator Failflag command turned on, each occurrence of a miscompare in
the comparator asserts the fail_h signal to the “1” state and causes the controller to serially scan
out through the “scan_out” pin.

During scan, the BIST controller is frozen and the test pauses. The failure data includes the
failing memory address, memory data outputs, and the state of the BIST finite state machine.

When the controller is run in diagnostic mode, the fail_h signal is asserted only to indicate there
is failure data that can be downloaded. After this data is transferred to the tester, signal fail_h is
unasserted. The signal fail_h is also asserted at the end of the test to indicate that one or more
miscompares occurred during the run.

Use the Add Diagnostic Monitor command to specify the failure data that you want scanned
out. When the diagnostic monitor is used, the Set Controller Debug command must use the -ON
switch or an error will result.

Recovering From a Hold Situation

There are situations when it is necessary or desirable to recover from a hold situation by:

1. Scanning out the error information from the one or two errors that caused the hold
condition, and then
2. Restarting the entire test process, but ignoring any errors until just past the point that the
hold occurred.
A reason this can be desirable is that coming out of a hold condition means the first few test
cycles are not at speed. In particular, if the hold has occurred at a point when the memory is
being read, the output will have been stable for many cycles. Similarly, the various address and
control signals will have been stopped.

A reason that the restart process can be necessary involves pipeline stages either within the
memory itself, or between the testing controller and the memory. Depending on the behavior of

MBISTArchitect™ Reference Manual, v2021.2 and Later 173

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Controller Debug

such stages, and whether they can be held in a timely fashion, it is possible the first couple of
cycles coming out of hold might result in false error detects.

These issues cannot occur if the testing controller resets after a hold, and is executing at-speed
when it gets back to the hold point.

Disadvantages with the Restart Approach

There are two disadvantages with the restart approach. First, it requires considerable logic.
Second, in the presence of very many errors, there will be many restarts and very long
diagnostics runs. To avoid these, implement a non-restart approach using the -norestart switch.
This will prevent the tool from creating “restart after hold” logic.

Area Overhead Using Restart

The downside to using the restart approach is that it requires a second register of the size of the
diagnostic monitor data. If you are performing multiple memory testing concurrently, this might
add considerably to your area overhead. See also: Pipeline Considerations.

Pipeline Considerations
One of the reasons for using the -restart approach is that the controller debug using the
-norestart approach can miss consecutive errors when there are one or more pipeline stage in the
path from the BIST controller to the memory and back to the controller. Some memories,
especially synchronous memories, implement one or more stages internally. See also: Area
Overhead Using Restart.

Full-Speed Diagnostics with Restart

See also: Full-Speed Diagnostics Using the -norestart Switch.

When the BIST controller is stopped due to a defect during diagnostics running “full-speed” the
BIST will restart the algorithm from the very beginning, skipping the previously processed
failures.

Restart means that the memory BIST controller will be reset and the entire BIST process will
start from the beginning. The restart takes place immediately after processing the data from all
pending failures.

The basic sequence of events are as follows:

1. If you specify the -on switch, the controller stops on the second error if the first error is
not completely scanned out, scans out all failing data, and then restarts BIST.

Note
If you specify the -on and -nohold switches together, the behavior is the same as in
step 1. MBISTArchitect issues a message warning you of this.

174 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Controller Debug

2. When a restart is initiated, all previously detected failures are masked until the controller
gets to the point that resulted in the last halt.
3. When the point is reached where the controller was previously stopped, the normal
BIST operation resumes.

Full-Speed Diagnostics Using the -norestart Switch

If you specify the -norestart switch, the controller stops at the first failure, scans out the failing
data, and then resumes BIST. If you specify both the -norestart and -nohold switches, the
controller stops on the second failure if the first failing data is not completely scanned out,
completely scans out all failing data, and then resumes BIST.

Arguments
• -OFf
A switch that prevents generation of logic that enables you to place the controller in the
debug state. If you specify the -off switch, you cannot set the controller in the debug state.
The -off switch is the default.
• -ON
A switch that specifies that the controller is put into debug state by taking the input port,
debugz, to the “1” state. If you use the -on switch, you can use any of the following
switches: -nosynchronization, -nohold, -norestart, or -recovery.
• -NOSynchronization
An optional switch that specifies that the tool does not use synchronization cycles. The
default is to have synchronization cycles.
• -NOHold
An optional switch that enables you to specify to not hold BIST function during diagnostic
scan operation. The invocation default is to hold the BIST controller.
The -nohold switch actually means HoldOnSecondError.
• -NORestart
An optional switch that prevents generation of “restart after hold” logic. When a no-restart
approach is either sufficient or will work with the memory set-up, use this switch to avoid
the disadvantages of the restart approach.
• -Recovery number
An optional switch and integer pair that specifies the number of BIST clock cycles you want
for the recovery and hold_recovery states. If not specified, the default number of BIST clock
cycles is 1.
With diagnostics active, the failure signal, fail_h, will be deasserted for the recovery cycles
after the diagnostic data is scanned out.

MBISTArchitect™ Reference Manual, v2021.2 and Later 175

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Controller Debug

The actual number of BIST clock cycles of deassertion will be either the specified value, or
one cycle longer, depending on some clock phase settings. Depending on other arguments,
including the -norestart and -nohold switches, it is possible for the generated BIST
controller to detect a second failure before the data from the first failure is scanned out. The
-recovery switch allows you to force a separation between the end of the first report, and the
beginning of the second, that might be needed for a slower ATE to be able to discern that
there were actually two failure reports.
• -Parallel_output
An optional switch that tells MBISTArchitect to add output pins (diag_monitor) to the BIST
controller, which allow visibility of the diagnostic monitor register in parallel. This does not
replace the existing serial output pin for diagnostic scanout nor change internal diagnostic
behavior. You can observe diagnostic data on the parallel outputs. To resume BIST at the
location that follows the error, toggle diag_clk for the width of the diagnostic monitor.
Note
The diag_monitor output bits will be in reverse order of the diagnostic register that is
inside the BIST controller.

Examples
The following example uses the -on switch and puts the controller in a debug state:

set controller debug -on

The following example uses the -on -norestart switches and generates a controller that stops on
the first error:

set controller debug -on -norestart

The following example uses the -norestart -nohold switches and generates a controller that stops
on the second error if the first error is not completely scanned out:

set controller debug -on -norestart -nohold

For the following example, assume there are three consecutive read operations denoted as read
operation r1 (set up address), r2 (read), and r3 (compare). Although the r2 data is read in the
second clock cycle, the results of comparison is not registered until the third clock cycle (r3).
The four read operations are pipelined to get back-to-back read operations (shown larger and in
bold).
clk1 clk2 clk3 clk4 clk5 clk6 clk7
addr0 r1 r2 r3
addr1 r1 r2 r3
addr2 r1 r2 r3
addr3 r1 r2 r3

176 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Controller Debug

Assume that the hold controller is used, and that there are two consecutive errors at addr0 and at
addr1. When the tool compares the value of addr0 in the third clock cycle (clk3), you will notice
that the addr_reg has been already updated with addr2 and the read from addr1 is some where in
the pipeline stages.

At this point the BIST controller is set to a hold state, and the data corresponding to addr0 is
scanned out. Once the tool resumes operation, the tool sees that the addr_reg is set to addr2, and
therefore, the read operation begins from that location. In the process, the second error that was
supposed to be detected in addr1 is missed.

Related Topics
Add Diagnostic Monitor
Report Diagnostic Monitor
Setup Controller Clock
Setup Pipeline Registers
Delete Diagnostic Monitor
Set Controller Hold
Setup Comparator Failflag
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 177

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Controller Delay

Set Controller Delay

Legal Modes: BISTGEN
Prerequisites: None
Sets delays on the output signals from the BIST controller.
Usage
SET COntroller Delay value
Description
Sets delays on the output signals from the BIST controller. For some designs, if you do not
place delays on the output signals from the BIST controller, the result can be race conditions
between the memory clock and the BIST control signals, which can cause the RTL simulation
to fail.

Arguments
• value
A required integer argument that specifies the amount of delay in nanoseconds.
Examples
This example shows both Verilog and VHDL code segments for a controller output when the
following command is issued:

set controller delay 2

Verilog:
/* Assign Outputs (Verilog) */
assign #2 M_1 = (test_h) ? Test_M_1 : M;

VHDL:
-- Assign Outputs (VHDL)
if test_h = ‘1’ then
M_1 <= Test_M_1 after 2 ns;
else
M_1 <= M after 2 ns;

178 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Controller Delay

Without the Set Controller Delay command, the default code segments for the preceding
controller output would appear as the following:

Verilog:
/* Assign Outputs (Verilog) */
assign M_1 = (test_h) ? Test_M_1 : M;

VHDL:
-- Assign Outputs (VHDL)
if test_h = ’1’ then
M_1 <= Test_M_1;
else
M_1 <= M;

Related Topics
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 179

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Controller Hold

Set Controller Hold

Legal Modes: BISTGEN
Prerequisites: None
Causes a hold bit (hold_l) to be created that stops testing.
Usage
SET COntroller Hold -OFf | -ON
Description
Causes a hold bit (hold_l) to be created that stops testing.

Arguments
• -OFf
A switch that prevents the generation of logic that would allow you to input a hold bit
(hold_l) to stop testing. This is the default.
• -ON
A switch that generates a hold_1 pin on the controller. If hold_l is asserted (low), the
controller and (if present) the compressor are held and no internal registers are updated. The
hold_l pin is user controlled. The name, hold_1, is the default and can be changed using the
Set Pin Name command.
Examples
The following example instructs the tool to output a single fail bit:

load library dft.lib

add memory models ram4x16
set controller debug -on
set controller hold -on
setup comparator failflag -common
run
save bist -vhdl

Related Topics
Set Controller Debug
Setup Controller Clock
Set Pin Name
Report Environment

180 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Design Name

Set Design Name

Legal Modes: BISTGEN
Prerequisites: None
Changes the names for the modules/entities, instances, or architectures generated by the tool.
Usage
SET DEsign Name design_type {[-Module module_name | -Entity entity_name]
[-Architecture arch_name] [-Instance instance_name]}
Description
Changes the names for the modules/entities, instances, or architectures generated by the tool.
Verify your naming changes with the Report Design Name command.

If you rename the controller module/entity, the tool also changes the following default file
names:

• BIST controller model: module_name.v (entity_name.vhd)

• Connection file: module_name_con.v (entity_name_con.vhd)
• Test bench: module_name_tb.v (entity_name_tb.vhd)
Only the default file names are changed. The file names specified by the Setup File Naming
command are not changed.

Arguments
• design_type
A required literal that specifies the design type of the object(s) you want to rename. Valid
design types include the following:
Address_scrambler CONtroller
BIsa_logic DIag_monitor
BYPass_logic DAta_scrambler
COLlar Misr

The design types are case-insensitive. The capitalization in the list above indicates the
minimum typing requirements.
You only can specify design types used in your BIST configuration. For example, if your
design is not configured for diagnostics, you cannot specify the “diag_monitor” design type.
Use the Report Design Name command to see a list of available design types for the current
configuration.

MBISTArchitect™ Reference Manual, v2021.2 and Later 181

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Design Name

• -Module module_name
An optional switch and string pair that changes the generated module name(s) for the
specified design type. For all design types except CONtroller, “module_name_” is
prepended to the original module name.
This switch also changes the default instance names of the module. However, it will not
change any instance names specified with the -Instance switch.
• -Entity entity_name
An optional switch and string pair that changes the generated VHDL entity name(s) for the
specified design type. This switch also changes the default instance names of the module.
However, it will not change any instance names specified with the -Instance switch.
• -Architecture arch_name
An optional switch and string pair that changes the generated VHDL architecture name for
the specified design type. Architecture names should be lowercase.
The -Architecture switch has no effect for Verilog designs.
• -Instance instance_name
An optional switch and string pair that changes the generated instance name(s) for the
specified design type. If there are multiple instances of a design type, such as ‘collar’, the
actual instance names will be appended with an instance number. For example,
instance_name_0, instance_name_1, and so on.
Examples
The following example reports the default design names for a simple configuration with three
memories:

report design name

---------------------------------------------------------------------------------
Memory DesignType Module Instance
---------------------------------------------------------------------------------
****** Controller ram_multi_bist ram_multi_bist_instance
ram Collar ram_multi_bist_ram_block ram_multi_bist_ram_block_instance_0
ram Collar ram_multi_bist_ram_block ram_multi_bist_ram_block_instance_1
ram Collar ram_multi_bist_ram_block ram_multi_bist_ram_block_instance_2
---------------------------------------------------------------------------------

The following example changes the collar module name to my_collar and reports the design
names:

set design name collar -module my_collar

report design name

182 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Design Name

-------------------------------------------------------------------------
Memory DesignType Module Instance
-------------------------------------------------------------------------
****** Controller ram_multi_bist ram_multi_bist_instance
ram Collar my_collar_ram my_collar_ram_instance_0
ram Collar my_collar_ram my_collar_ram_instance_1
ram Collar my_collar_ram my_collar_ram_instance_2
-------------------------------------------------------------------------

The following example changes the collar instance name to coll_inst and reports the design
names:

set design name collar -instance coll_inst

report design name
-------------------------------------------------------------------------
Memory DesignType Module Instance
-------------------------------------------------------------------------
****** Controller ram_multi_bist ram_multi_bist_instance
ram Collar my_collar_ram coll_inst_0
ram Collar my_collar_ram coll_inst_1
ram Collar my_collar_ram coll_inst_2
-------------------------------------------------------------------------

The following example changes the BIST controller module name to my_controller and reports
the design names:

set design name controller -module my_controller

report design name
-----------------------------------------------------------------------
Memory DesignType Module Instance
-----------------------------------------------------------------------
****** Controller my_controller my_controller_instance
ram Collar my_collar_ram coll_inst_0
ram Collar my_collar_ram coll_inst_1
ram Collar my_collar_ram coll_inst_2
-----------------------------------------------------------------------

Related Topics
Report Design Name
Report Environment
Set Pin Name

MBISTArchitect™ Reference Manual, v2021.2 and Later 183

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Dofile Abort

Set Dofile Abort

Legal Modes: All
Prerequisites: None
Specifies whether the tool stops or continues dofile execution if an error condition is detected.
Usage
SET DOfile Abort ON | OFf | Exit
Description
Specifies whether the tool stops or continues dofile execution if an error condition is detected.
By default, if an error occurs during the execution of a dofile, processing stops and the line
number causing the error in the dofile is reported. This command turns this functionality off,
and the tool continues to process all commands in the dofile.

Arguments
• ON
A literal that halts the execution of a dofile upon the detection of an error. This is set as the
default when the tool is started.
• OFf
A switch that forces dofile processing to complete all commands in a dofile regardless of
error detection.
• Exit
Exits the tool upon detection of an error. Care should be exercised using this switch, as it
will shut the tool down without saving any files.
Examples
The following example sets the Set Dofile Abort command off to ensure that all commands in
test1.dofile are executed:

set dofile abort off

dofile test1.dofile

The following example halts the execution of the dofile upon the detection of an error, and exits
the tool:

set dofile abort on exit

dofile test2.dofile

Related Topics
Dofile
Report Environment

184 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Drc Handling

Set Drc Handling

Legal Modes: SETUP (BIST Insertion and Gate-Level Verification Phases)
Prerequisites: None
Specifies how the tool handles design rule violations and directs the design rules checker to
check your input against expected or required values.
Usage
SET DRc Handling rule_id
{ Error | Warning [ -Verbose | -Noverbose ] | NOTe [ -Verbose | -Noverbose ] | Ignore }
Description
Specifies how the tool handles design rule violations and directs the design rules checker to
check your input against expected or required values. The CTDF rules are available exclusively
in Setup mode of the BIST Insertion Phase. The CTDF rules check controller definitions,
checking the contents of the CTDF and the netlist against one another.

Arguments
• rule_id
A required string that specifies the rule name of the message handling you want to change
for a specific design rule violation. Your rule name must be a valid DRC name. For a list of
all valid rule names, you use the command Report DRC Rules.
• Error
A required literal that specifies for the tool to treat the violation as an error condition,
immediately terminate the rules checking, and give an error message.
• Warning
A required literal that specifies for the tool to treat the violation as a warning condition and
give a warning message.
• NOTe
A required literal that specifies for the tool to display the message indicating violation for
that rule.
• Ignore
A required literal that specifies for the tool to not display any message for the rule
violations. The tool must still check some rules and they must pass to allow performance
later of certain functions.
• -Verbose
An optional switch that specifies for the tool to display the violation message for each
violation when a warning message or note is applicable.

MBISTArchitect™ Reference Manual, v2021.2 and Later 185

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Drc Handling

• -Noverbose
An optional switch that specifies for the tool to display only a summary of violations when
warning message or note is applied.
Examples
Not all rules are changeable. Use the report DRC Rules to figure out which rules are
changeable, for example, if you were to issue the following command, you would get a warning
that the rule is not changeable:

set drc handling CTDF2

// Error: The handling of ‘CTDF2’ cannot be changed.

Related Topics
Report Drc Rules
Report Environment

186 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Message Handling

Set Message Handling

Legal Modes: BISTGEN
Prerequisites: None
Sets up a logfile for a BIST session.
Usage
SET MEssage Handling -Logfile file_name [ -Replace | -Append ]
Description
Sets up a logfile for a BIST session. Use this command to generate a new logfile, replace an
existing logfile, or append information to a logfile that already exists. The tool can generate
logfiles in two ways: by using the -logfile switch when you invoke the tool, or by interactively
issuing the Set Message Handling command during the session.

Arguments
• -Logfile file_name
A required switch and string pair that specifies the name of the logfile that you want the tool
to generate.
• -Replace
An optional switch that instructs the tool to overwrite previously saved log files of the same
name.
• -Append
An optional switch that instructs the tool to append information to an already existing logfile
of the same name. If no logfile currently exists, the tool generates a new logfile.
Examples
The following example specifies mbist_logfile as the session logfile, replacing any existing
logfile by that name:

load library dft.lib

add memory models ram16x16
set message handling -logfile mbist_logfile -replace
run
save bist

Related Topics
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 187

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Pin Name

Set Pin Name

Legal Modes: BISTGEN
Prerequisites: None
Changes the top-level pin names.
Usage
SET PIn Name { pin_type pin_name }…
Description
Changes the top-level pin names. The valid pin_types are listed in Table 1-5 by feature
category. The BIST pin types are the default pins. Feature-specific pin types are only available
if the feature has been added to the BIST configuration. Additional pin types are available if you
defined a pin type in a loaded library file.

The pin types are capitalized in Table 1-5 to show minimum typing requirements. Use the
Report Pin Name command to see a complete list of available pin types for your BIST
configuration.
Table 1-5. Pins on the Top Level
Category Valid pin_type Default Top-Level Name
BIST TEST_H test_h
FAil_h fail_h
TSt_done tst_done
BIST_clk bist_clk
RESEt rst_l
Diagnostic DIAG_Clk diag_clk
DIAG_SCAN_Out scan_out
DIAG_Scan_In diag_scan
HOld hold_l
DEbugz debugz
RESTart_h restart_h
DIAG_Monitor diag_monitor
Retention Start_retention start_retention_h
TEST_Resume test_resume_h

188 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Pin Name

Table 1-5. Pins on the Top Level (cont.)

Category Valid pin_type Default Top-Level Name
Bypass BYPASS_Clk bp_clk
BYPASS_COntrol Test_mode
BYPASS_SCAN_In scan_in
BYPASS_SCAN_Out scan_out
BYPASS_SCAN_En scan_en
Repair REPAIRAble_h repairable_h
REPAIR_DATA_Clk repair_data_clock
REPAIR_DATA_Force repair_data_force
REPAIR_DATA_Out repair_data
MISR MISR_SCAN_In si
MISR_SCAN_En se
MISR_SCAN_Out misr_scan_out
MISR_Data_out misr_dataout
Algorithm Selection ALGSEL_SCAN_In algsel_scan_in
ALGSEL_SCAN_Out algsel_scan_out
ALGSEL_SCAN_En algsel_scan_en
ALGSEL_SCAN_Clk algsel_scan_clk

Arguments
• pin_type
A required string that specifies one of the valid pin_types, listed in Table 1-5.
• pin_name
A required string that specifies the new top-level name for the pin type.
Examples
The following example changes the test_h pin to start_bist, the tst_done pin to end_bist, and the
algsel_scan_en pin to alsen:

set pin name test_h start_bist tst_done end_bist

set pin name algsel_scan_en alsen

Related Topics
Report Pin Name

MBISTArchitect™ Reference Manual, v2021.2 and Later 189

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Pin Name

Report Environment
Set Design Name

190 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

Set Scan Logic

Legal Modes: BISTGEN
Prerequisites: None
Instructs the tool to create a bypass circuitry to bypass the memory during ATPG mode in order
to test the logic surrounding the memory.
Usage
SET SCan Logic [ model_name ] [ -Addr_observe number ]
[ -Data_observe number ] [ -CNtrl_observe number ]
{ [ -SCan | -NOScan ] [ -COntrol | -NOControl ] [ -Reset | -NOReset ] } | [ -COMbinational ]
Description
Instructs the tool to create a bypass circuitry to bypass the memory during ATPG mode in order
to test the logic surrounding the memory. This is done by XORing the address, the data input,
and the control signals. The output of the XOR logic is fed into scan or non-scan cells. These
cells are clocked by a special signal called bypass clock (bp_clk). The command also instructs
the tool to insert muxes on the memory data output, where the output of these muxes is
connected to dataout of the memory block. The select line of these muxes is a signal called
test_mode. By default, this is how the tool works.

If you specify this command without specifying any switches, the default behavior is that the
tool will insert sequential bypass logic.

If you choose to specify scan cells, the tool generates the following additional signals:

scan_enable

scan_in

scan_out

Note
You cannot have a mix of bypass-ready and non-bypass-ready memories on the same BIST
controller. For more information about bypass-ready memories, see “Bypass-Ready
Memories” in the MBISTArchitect Process Guide.

Arguments
• model_name
An optional string that specifies that the settings only apply to the memory model that you
specifically name. The memory model is the same as the model you specified in the Add
Memory Model command.

MBISTArchitect™ Reference Manual, v2021.2 and Later 191

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

• -Addr_observe number
An optional switch and positive integer pair that specifies the number of scan cells or
non-scan cells that you want to use to XOR the address signals. The number that you specify
must be a positive integer greater than zero, and less than or equal to the total number of
address signals.
The tool will accept a value of zero without an error being issued, but the address set will
not be observable.
• -Data_observe number
An optional switch and positive integer pair that specifies the number of scan cells or
non-scan cells that you want to use to XOR the data input signals. The integer that you
specify must be greater than zero, and less than or equal to the total number of data input
signals.
The tool will accept a value of zero without an error being issued, but the data set will not be
observable.
• -CNtrl_observe number
An optional switch and positive integer pair that specifies the number of scan cells or
non-scan cells used to observe the control signals. The four types of control signals that are
possible with this switch includes: read_enable, write_enable, chip_enable, output_enable,
and control.
The tool will accept a value of zero without an error being issued, but the control set will not
be observable.
Note
The tool will not accept a zero value in -Addr_observe, -Data_observe, and
-CNtrl_observe at the same time; however, you can specify a zero in any two
without an error being issued, although the zero specified switch will not be observable.

• -SCan
An optional switch that instructs the tool to place mux-style scan cells on the XOR lines that
it generates for both the address and data. To support the scan cells, the tool also places three
additional signals: scan_enable, scan_in, and scan_out.
• -NOScan
An optional switch that instructs the tool to place non-scan cells on the XOR lines that it
generates for both the address and data. This is the default.
Note
If you specify both the -noscan and -nocontrol switches, the memory bypass block
will not have any outputs (that is, they will not drive anything). The tool will
generate a warning message because this lack of outputs usually causes the bypass
circuitry to be optimized away during synthesis. To prevent this, you might need to
specifically constrain the synthesis tool.

192 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

• -CONtrol
An optional switch that instructs the tool to insert muxes on the memory data output. One
input of the mux is connected to the memory data output. The other input is from the newly
inserted scan or non-scan cells. The output of the mux is connected to the primary data
output of the memory block. To control the mux, the tool also places the test_mode signal.
This is the default except in the case of memories with bidirectional ports for which the
-control option is not supported.
For a bypass-ready memory, this switch connects the bypass block to the existing output
mux.
• -NOControl
An optional switch that instructs the tool not to insert muxes on the memory data output. See
the note following the -noscan switch description.
For a bypass-ready memory, this switch leaves the existing output mux but does not connect
the bypass block to it.
• -Reset
An optional switch that instructs the tool to make the registers in the bypass section have
reset inputs. This is the default.
Normally this switch is used to specify reset signals so that synthesis generates registers
rather then latches. In many design flows, all RTL specified registers need this signal in
order to pass lint or DRC checks.
• -NOReset
An optional switch that instructs the tool not to make the registers in the bypass section have
reset inputs.
This choice is made when the test logic that is hooked into scan chains should not get reset
logic that takes up area (real estate) on the chip, and requires the routing of the reset signal.
• -COMbinational
An optional switch that generates combinational bypass logic where the inputs are
compressed and are sent to the muxes on memory data output, and no registers are inserted.
Refer to Figure 1-12 on page 205 for additional details.
You cannot use the -COMbinational switch with the -SCan, -NOScan, -CONtrol,
-NOControl, -Reset, or -NOReset switches.
Testing Logic on the Output Side
The default -control switch option is provided to mux the scan/non-scan cell output to the
memory data output. This is helpful in testing logic on the output side of the memory during
scan test. The tool inserts one mux for each data output. It connects one input of the mux to
memory data output and the other input to the newly inserted scan/non-scan cells. The mux is
controlled by the test_mode signal.

MBISTArchitect™ Reference Manual, v2021.2 and Later 193

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

The bypass logic created by this command is placed in a hierarchical block called
memory_name_bypass. Also, a new level of hierarchy called memory_name_block is created if
it does not already exist. This memory_name_block is created or modified to contain both the
memory and the memory_name_bypass blocks. The description of the memory_name_bypass
and memory_name_block are in the same file as the BIST controller.
Memories That Generate Z Output
For memories that generate Z output, system operation will be affected if muxes are inserted on
data out for control, so be advised not to use the -control option for memories that generate Z
output. Currently, the tool does not have any way to identify memories that generate Z on data
outputs.
This command also causes the tool to generate a BIST collar hierarchy, and to instantiate the
BIST-related modules and the memory.
Observe Cells
The observe cells for address, data, and control signals are always processed in the order of the
smallest signal first, unless all of the signals are specified through user-defined values.
If the observe cells are user-defined, the tool will process the request sequentially; in other
words, the allocation for the observe cells will be done sequentially. During this sequential
processing of the respective values, the tool also checks for the feasibility of implementing the
user-defined values. Where feasible, the tool implements the values. When the tool deems it is
not feasible, the tool will issue a warning message, and will thereafter implement the best
feasible solution.
Observe Cell Calculation
The default behavior of this command is to associate the memory’s input signals into three
groups (address, data, and control signals), and to allocate the new cells among them
proportional to the size of each group versus the total number of input signals. The goal is to
make each input signal as easy as possible to observe via ATPG processing. However, if you
use one or more of the -addr_observe, -data_observe, or -cntrl_observe switches, you override
the default behavior, and the calculation methods change.
Absent any overrides, the approximate number of cells allocated is:
Average = Total Number of Input Cells ¸ Number of output cells
Cells for Group X = Integer part of (Size of Group X ¸ Average)
Examples
Example 1 - Observe Cell Calculation for Default Rule
The following memory example is for the default rule that is only applicable when no observe
cells are specified. This is the so-called Default Rule.
Signal Number of Signal Lines
Address 4
Data 8

194 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

Signal Number of Signal Lines

Control 2
Average Compression / Cell = Number of (address lines + data lines + control lines) ¸ Number
of data lines

= (4 + 8 + 2) ¸ 8

= 1.75

Processed in the order of smaller number of signals first. Also note that the results which yield a
decimal values will be truncated.

Control_observe cells = 2 ¸ 1.75 =1

Address_observe cells = 4 ¸ 1.75 = 2

Data_observe cells = 8 - (1 + 2) = 5

Example 2 - Observe Cell Calculation for User Defined Rule

Signal Number of Signal Lines

Address 4
Data 8
Control 2

In the following example the observe cells would be perfectly allocated as per the following
command, since the observe cells that are requested are within the limits of feasibility:

set scan logic -addr_observe 1 -data_observe 4 -cntrl_observe 2

The operation would be performed sequentially, with one observe cell for address lines, four
observe cells for data lines, and two observe cells for control lines.

Example 3 - Observe Cell Calculation for User Defined Rule

Signal Number of Signal Lines

Address 4
Data 8
Control 2

MBISTArchitect™ Reference Manual, v2021.2 and Later 195

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

In the following example the observe cells would be allocated for data; however, after the first
allocation there is only one observe cell available for address and control signals:

set scan logic -data_observe 7

The preference would fall for the address lines over the control lines. This also applies when
there is only one remaining observe cell after allocating observe cells for address through
user-defined values. The last cell would go to data lines, with no observe cells left for control
lines.

Total number of observe cells = number of observe cells for data = 8

User defined cells = 7

Number of observe cells remaining for allocation = 1

Therefore,

Number of observe cells for address = 1

Number of observe cells for control = 0

Example 4 - Observe Cell Calculation for User Defined Rule

Signal Number of Signal Lines

Address 4
Data 4
Control 3

In the following example all of the control lines will be allocated one observe cell each:

set scan logic -cntrl_observe 3

What about the address and data lines with only one cell to spare? Why is this different? The
tool adds observe cells for the address lines preferred over the data lines. Therefore the
remaining observe cells would be allocated to the address lines.

Total number of observe cells = number of data lines = 4

Number of observe cells allocated = number of observe cells for control lines = 3

Number of observe cells remaining = 1

Therefore,

Number of observe cells for address = 1

196 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

Number of observe cells for data = 0

Example 5 - Observe Cell Calculation for User Defined Rule

Signal Number of Signal Lines

Address 4
Data 8
Control 2

In the following example all of the control lines will be allocated one observe cell:

set scan logic -cntrl_observe 1

Total number of observe cells = number of data lines = 8

Number of observe cells allocated = number of observe cells for control line = 1

Number of observe cells remaining = 7

Therefore,

Number of address observe cells = (Number of address lines + Number of data lines)¸
Number of observe cells available = (4 + 8) ¸ 7 = 1.71 = 1 (tool truncated value) Number of
observe cells for data = 8 - (1 + 1) = 6

Rounding Down Problems

To avoid rounding down problems, the tool normally operates on the two smallest sets first.
Each will get the number according to the preceding formula unless the formula leads to zero
cells. In this case, if there are at least three output cells, the number is raised to one. The goal is
to make the input cells in the set observable.

After allocating the cells for the two smaller sets, the rest of the cells are allocated to the largest
set.

It is possible that this process can end up with some output cells not associated with any input
set. This is rare, but if it happens, those cells will be driven with zeroes.

If you use the observe override switches (-addr_observe, -data_observe, or -cntrl_observe), each
switch is honored as it is encountered. The number of cells associated with each set will be as
specified by the integer value subject to the following restrictions:

1. The number of cells allocated starts as being the lesser of the integer value and the size
of the associated input set.
2. That result can be reduced if there are fewer output cells left. The number of output cells
‘left’ is reduced after each observe switch is processed.

MBISTArchitect™ Reference Manual, v2021.2 and Later 197

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

If the number used is not the same as the integer specified, then a warning message is issued.

If you specify one, two, or all three of the -addr_observe, -data_observe, -cntrl_observe optional
switch integer pairs, then it is possible that not all scan logic output bits will be assigned to a set.
The probability is low, but it is due to the truncating in the “fair” allocation process. If a a scan
logic output bit was not assigned to a set, the leftover bit will be driven with zeroes. It is also
possible that truncation could lead to two smaller sets getting “less” than they should (a fraction
of a bit each). In these cases, the largest set will get the “extra” bit.

You can override the previous issue explicitly by stating the number of bits to use with each of
the -addr_observe, -data_observe, and -cntrl_observe switches.

If you use one of the previously named switches, the associated set gets the number of bits to
use, this is subject to the following constraints:

• The amount associated will be lesser of the number of bits to use, and the size of the
associated set of input bits.
• The amount associated will be the lesser of the first result above the number of scan
logic output bits.
• If the number allocated is less than you specified, the tool will issue a warning.
If you use a second and a third override each follows the same rules as for one switch override
except now it is limited by the number of not yet allocated bits in the scan logic output set.

If there has been at least one override, but not three, any remaining set scan logic output bits are
allocated in a “fair” or prorated manner, which is similar to the approach with one override.

198 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

Example 6 - Using Set Scan Logic with -NoScan -Reset -Control Switches
The following example is an overview of the block logic as a result of using the Set Scan Logic
command and using the -noscan, -reset, and -control switches:

Figure 1-8. Using Set Scan Logic -NoScan -Reset -Control

Example 7 - Using Set Scan Logic With Bypass

The following example is an overview of the block logic as a result of using the Set Scan Logic
command with bypass:

Optional 1: Resettable registers = default (Set Scan Logic [-Reset])

Optional 2: Provide hook up to scan chains (Set Scan Logic [-Scan])

MBISTArchitect™ Reference Manual, v2021.2 and Later 199

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

Figure 1-9. RAM 4x4 with Bypass

Note that the block containing the XOR Cloud and the registers in Figure 1-9 is added by the
MBISTArchitect tool.

200 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

Example 8 - Using Set Scan Logic Default Settings

The following example shows the default settings for the Set Scan Logic command (-noscan
and -control):

load library dft.lib

add memory models ram4x4
set scan logic
run
save bist

Figure 1-10 illustrates the default memory bypass circuitry for the previous commands. The
number of data output lines determines the number of control muxes and non-scan cells.
Because there are four data output lines, there are also four control muxes and four non-scan
cells. The memory’s address and data input lines are connected to the non-scan cells using the
default formulas. When the test_mode signal is active, the memory is bypassed.

MBISTArchitect™ Reference Manual, v2021.2 and Later 201

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

Figure 1-10. Default Memory Bypass Circuitry Example.

202 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

Example 9
The following example shows the use of the model_name, -addr_observe, -cntrl_observe, and
-data_observe input switches for multiple memories:

load library new_lib

add memory models ram4x4 MY_RAM4X16_bussed
// Adding 3 bypass scan cells, one each for address, data, and control.
set scan logic ram4x4 -addr_observe 1 -data_observe 1 -cntrl_observe 1 -
noscan -control
// Adding bypass flops for another memory model with a
// different configuration of bypass signals
set scan logic MY_RAM4X16_bussed addr 2 -data 13 -cotrl 1 -noscan -control
run
save bist -verilog -rep
exit -force
Example 10 - Using Set Scan Logic -Scan

Figure 1-11 shows the sequential bypass logic generated using Set Scan Logic -Scan command.

Figure 1-11. Using Set Scan Logic -Scan

MBISTArchitect™ Reference Manual, v2021.2 and Later 203

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

The following is an example of a snapshot of RTL for sequential bypass logic shown in
Figure 1-11:

module ram4x4_bypass_0 (
bp_clk,
rst_l,
scan_out,
scan_in,
scan_en,
Test_mode,
bpo_d_o,
bpi_d_o,
in_di,
in_addr,
in_WEN);
input bp_clk;
input rst_l;
output scan_out;
input scan_in;
input scan_en;
input Test_mode;
output [3 : 0] bpo_d_o;
input [3 : 0] bpi_d_o;
input [3 : 0] in_di;
input [1 : 0] in_addr;
input in_WEN;

reg [3 : 0] bpReg;
reg [3 : 0] bpo_d_o;
reg [3 : 0] nextBpReg;

assign scan_out = bpReg[3];

always @(Test_mode or bpReg or bpi_d_o)
begin : BypassAssignOutputs
if (Test_mode == 1'h1)
begin
bpo_d_o[0] = bpReg[0];
bpo_d_o[1] = bpReg[1];
bpo_d_o[2] = bpReg[2];
bpo_d_o[3] = bpReg[3];
end
else
bpo_d_o = bpi_d_o;
end

always @(bpReg or in_WEN or in_addr or in_di or scan_en or scan_in)

begin : BypassNextState
if (scan_en == 1'h1)
begin
nextBpReg[3 : 1] = bpReg[2 : 0];
nextBpReg[0] = scan_in;
end
else
begin
nextBpReg[0] = in_addr[0] ^ in_addr[1];
nextBpReg[1] = in_di[0] ^ in_di[1];
nextBpReg[2] = in_di[2] ^ in_di[3];

204 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set Scan Logic

nextBpReg[3] = in_WEN;
end
end
always @(posedge bp_clk or negedge rst_l)
begin : BypassUpdateRegister
if (rst_l == 1'h0)
bpReg <= 4'h0;
else
bpReg <= nextBpReg;
end

endmodule

Example 10 - Using Set Scan Logic -Combinational

Figure 1-12 shows the combinational logic generated using Set Scan Logic -Combinational.

Figure 1-12. Using Set Scan Logic -Combinational

MBISTArchitect™ Reference Manual, v2021.2 and Later 205

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Scan Logic

The following is an RTL example for the combinational bypass logic show in Figure 1-12:

module ram4x4_bypass_0 (
Test_mode,
bpo_d_o,
bpi_d_o,
in_di,
in_addr,
in_WEN);
input Test_mode;
output [3 : 0] bpo_d_o;
input [3 : 0] bpi_d_o;
input [3 : 0] in_di;
input [1 : 0] in_addr;
input in_WEN;

wire [3 : 0] bpReg;
reg [3 : 0] bpo_d_o;
reg [3 : 0] nextBpReg;

always @(Test_mode or bpReg or bpi_d_o)

begin : BypassAssignOutputs
if (Test_mode == 1'h1)
begin
bpo_d_o[0] = bpReg[0];
bpo_d_o[1] = bpReg[1];
bpo_d_o[2] = bpReg[2];
bpo_d_o[3] = bpReg[3];
end
else
bpo_d_o = bpi_d_o;
end

always @(in_WEN or in_addr or in_di)

begin : BypassNextState
nextBpReg[0] = in_addr[0] ^ in_addr[1];
nextBpReg[1] = in_di[0] ^ in_di[1];
nextBpReg[2] = in_di[2] ^ in_di[3];
nextBpReg[3] = in_WEN;
end

assign bpReg = nextBpReg;

endmodule

Related Topics
Add Memory Models
Report Environment
Report Memory Models

206 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Set System Mode

Set System Mode

Legal Modes: SETUP, BIST, and INT (BIST Mode of the Insertion and Gate-Level Verification
Phases)
Prerequisites: None
Changes the system mode of the tool between Setup and either Integration or BIST Insertion
mode, depending on the current phase.
Usage
BIST Mode of the Insertion Phase:
SET SYstem Mode { SEtup | Bist | Integration }
Gate-Level Integration Phase:
SET SYstem Mode SEtup | Integration
Description
Changes the system mode of the tool between Setup and either Integration or BIST Insertion
mode, depending on the current phase.

In the BIST Mode of the Insertion Phase you are not allowed to transition from Integration
mode to the BIST Insertion mode. In the BIST Mode of the Insertion Phase, when you transition
from the Setup to BIST mode, the tool performs DRC rules checking.

Arguments
• SEtup
A required literal that move the tool into the Setup mode.
• Bist
A required literal that moves the tool into the BIST Insertion mode.
• Integration
A required literal that moves the tool into the Integration mode.
Examples
To begin the BIST Insertion mode of the tool, enter the following:

set system mode bist

To begin the Integration mode of the tool, enter the following command:

set system mode integration

Related Topics
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 207

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Set Vhdl Description

Set Vhdl Description

Legal Modes: BISTGEN
Prerequisites: None
Determines whether the tool writes VHDL configuration statements in the controller and
connection files.
Usage
SET VHdl Description [ -Configuration { ON | OFf } ]
[ -Logic_type { STD_Logic | STD_Ulogic } ]
Description
Determines whether the tool writes VHDL configuration statements in the controller and
connection files. Determines whether the tool writes out STD_LOGIC or STD_ULOGIC in the
VHDL output files.

Arguments
• -Configuration { ON | OFf }
An optional switch that instructs the tool to generate VHDL configuration statements in the
controller and connection files. If you use the -configuration switch, you should select either
on or off, even though off is the default.
• -Logic_type { STD_Logic | STD_Ulogic }
An optional switch that selects between writing out STD_LOGIC, and STD_ULOGIC in
the VHDL output files. If you use the -logic_type switch, you should select either
STD_LOGIC or STD_ULOGIC, even though STD_LOGIC is the default.
Related Topics
Add Vhdl Library
Report Vhdl Settings
Delete Vhdl Library
Report Environment

208 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Algorithm Selection

Setup Algorithm Selection

Legal Modes: BISTGEN
Prerequisites: None
Enables or disables support for runtime programmable online algorithm selection.
Usage
SETup ALgorithm Selection
-OFf | -ON [ -Serial_load | -Parallel_load ] [ algorithm1… | -All | -None ]
Description
Enables or disables support for runtime programmable online algorithm selection.

When enabled, you can specify the algorithms you want to run. If no algorithm is specified, the
default algorithm is march2. For more information, refer to “Online Algorithm Selection” in the
MBISTArchitect Process Guide.

Specifying algSelReg to be the Primary Inputs of the Controller

In the case of a controller with algorithm selection, the tool generates an algorithm selection
register that is the same width as the number of algorithms added. The algorithm selection
register is then loaded after reset and before the start of BIST. For example, if there are four
controllers in your design, then there will be four algorithm selection registers. This might
results in significant area overhead, and sometimes unnecessary overhead if the controllers all
have the same algorithms.

To save the duplication of the algorithm selection registers, and specify the algorithms to be
loaded from either a register, or primary inputs, use either the -serial_load switch, or the
-parallel_load switch as described in the Arguments section.
Table 1-6. Functionality of the Various Switch Combinations
Switch Argument Generate Skip State algSelectReg Reset Testbench Vector to
Hardware Vector Scan In
-OFf No NA NA
-ON Yes 000...01 111...11
-ON -All Yes 111...11 111...11
-ON -None Yes 000...00 000...00
-ON <alg_list>1 Yes The value depends on the list of algorithms
added to the BIST controller, and added to
the selection list.

1 The <alg_list> string in the last row of the preceding table is a subset of the list of algorithms
that are to be added to the BIST controller. The list of algorithms added to the controller is

MBISTArchitect™ Reference Manual, v2021.2 and Later 209

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Algorithm Selection

specified through the Add Mbist Algorithm command, or Setup Mbist Algorithms command. If
no algorithm is specified, the default algorithm is march2.

Arguments
• -OFf
A required switch that disables support for runtime programmable online algorithm
selection.
• -ON
A required switch that enables support for runtime programmable online algorithm
selection.
• -Serial_load
An optional switch that specifies that the algorithm selection is specified through an
algorithm selection register (algselreg) of a width equal to the number of algorithms. This
switch generates hardware.
• -Parallel_load
An optional switch that specifies that the algorithm selection is controlled through an input
vector whose length is the number of algorithms. A typical use would be to drive this signal
with a JTAG register. This switch generates hardware.
• algorithm1
An optional repeatable string specifying the name(s) of the algorithm(s) you want to use.
• -All
An optional switch that forces the generation of a BIST controller with on-line algorithm
selection hardware, and the testbench will also run all the added algorithms. The reset value
of algSelectReg is all “1”.
• -None
An optional switch that forces the generation of an BIST controller with on-line algorithm
selection hardware, but the testbench will not run any of the algorithms. The reset value of
algSelectReg is all “0”.
Examples
To add all required algorithms which the BIST controller implement, you could enter the
following. Please note that entering the following creates hardware. See “Hardware Impact” in
the MBISTArchitect Process Guide.

add mbist algorithm 1 checkerboard march1 col_march1 march2 march3 retentioncb \

topchecker unique

To select all algorithms during runtime:

setup algorithm selection -on -serial_load -all

210 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Algorithm Selection

To select no algorithms during runtime:

setup algorithm selection -on -serial_load -none

To select only the march2 algorithm during runtime:

setup algorithm selection -on -serial_load march2

To select multiple algorithms:

setup algorithm selection -on -serial_load march1 march2 march3

To specify algorithm selection through primary inputs:

setup algorithm selection -on -parallel_load

Related Topics
Add Mbist Algorithms
Setup Memory Clock
Report Environment
Report Mbist Algorithms
Setup Mbist Algorithms

MBISTArchitect™ Reference Manual, v2021.2 and Later 211

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Clock Period

Setup Clock Period

Legal Modes: BISTGEN
Prerequisites: None
Defines the controller clock period.
Usage
SETup CLock Period value
Description
Defines the controller clock period. The default clock period is 100ns, but a user-defined value
can be entered.

Arguments
• value
A required positive integer or positive floating point number that defines the controller
clock period.
Examples
The following example sets the clock period to 50ns:

setup clock period 50

The following example sets the clock period to 125ns, and displays the corresponding testbench
and DC script file entries:

setup clock period 1.25E2

In the testbench:

parameter <clk_period>=125;

In the DC script file:

create_clock -period 125 -waveform [0,62.5} <clk_pin_name>

Related Topics
Setup Controller Clock
Report Environment
Setup Memory Clock

212 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Comparator Failflag

Setup Comparator Failflag

Legal Modes: BISTGEN
Prerequisites: None
Defines how fail bits will be output during memory testing.
Usage
SETup COmparator Failflag [ -Common | -SEparate ] [ -SInglefail | -Multifail ]
Description
Defines how fail bits will be output during memory testing. Instructs the tool to generate
comparator logic along with the BIST controller. The -common and -separate switches
determine the precision or faulty memory identification when testing multiple memories.

Arguments
• -Common
An optional switch that instructs the tool to set one fail flag for all memories sharing the
same controller. This is the default behavior.
• -SEparate
An optional switch that instructs the tool to set a separate fail flag for each memory sharing
the same BIST controller.
• -SInglefail
An optional switch that instructs the tool to assert the fail_h signal and keep it asserted
continuously. The fail flag goes high at the first mismatch. If the Set Controller Debug
command is set to off, fail_h stays high until the end of the simulation (stuck in the fail
position). However, if the Setup Controller Debug command is set to on, fail_h is asserted
for each failure, and is held high through the diagnostic scan unload.
Note
Beginning with MBISTArchitect, V8.2002_4.20, when the controller is run in
diagnostic mode, the fail_h signal is asserted to indicate there is failure data to
download. After this data is transferred to the tester, fail_h is deasserted. In earlier
versions, fail_h is also asserted at the end of the test to indicate that one or more
miscompares occurred during the run.

• -Multifail
An optional switch that instructs the tool to toggle the fail flag for each mismatch during the
simulation. If the Setup Controller Debug command is set to on, fail_h is asserted for each
failure and is held high through the diagnostic scan unload. If not running diagnostics, fail_h
is asserted for each error (for one BIST clock cycle). If errors have been detected, fail_h will
be asserted and held at the end of test.

MBISTArchitect™ Reference Manual, v2021.2 and Later 213

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Comparator Failflag

Examples
The following example instructs the tool to output a single fail bit:

load library dft.lib

add memory models ram4x16
set controller debug -on
set controller hold -on
setup comparator failflag -common
run
save bist -vhdl

The following example is shows the use of the -multifail switch. When the set controller hold -
on switch is used, the tool generates a hold_l pin on the controller. If hold_l is asserted (low),
the controller and compressor are held and no internal registers are updated. The hold_l is user
controlled. The name, hold_l, is the default, and can be changed using the Set Pin Name
command.

load library dft.lib

add memory models ram4x16
set controller debug -on
set controller hold -on
setup comparator failflag -multifail
run
save bist -vhdl

Related Topics
Set Controller Debug
Setup Memory Test
Report Environment
Setup Memory Access
Setup Memory Clock

214 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Controller Clock

Setup Controller Clock

Legal Modes: BISTGEN
Prerequisites: None
Defines whether the controller clock is set to a positive or negative edge.
Usage
SETup COntroller Clock -POsitive | -NEgative
Description
Defines whether the controller clock is set to a positive or negative edge.

Arguments
• -POsitive
A switch that indicates the controller clock is set to a positive (rising) edge. This is the
default setting.
• -NEgative
A switch that indicates the controller clock is set to a negative (falling) edge.
Examples
The following example sets the controller clock setting to a negative edge:

setup controller clock -negative

Use a Setup Controller Clock command with the -negative option to instruct the BIST state
machine to respond to the falling edge of the clock.

In this case, the falling edge of the clock input to the state machine causes the memory input
buses and control lines to change. One half cycle later, the rising edge of the clock input to the
synchronous memory captures the input data.

This scheme reduces the write cycle from four cycles to two, and thus cuts the write cycle test
time in half.

Related Topics
Setup Clock Period
Setup Diagnostic Clock
Setup Memory Clock
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 215

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Controller Reset

Setup Controller Reset

Legal Modes: BISTGEN
Prerequisites: None
Defines how the BIST controller is reset with the rst_l signal reset in either an asynchronous or
synchronous mode.
Usage
SETup COntroller Reset -Asynchronous | -Synchronous
Description
Defines how the BIST controller is reset with the rst_l signal reset in either an asynchronous or
synchronous mode.

Note
In the case of the synchronous reset mode, an improper reset of the controller could occur
due to the rst_l signal not being synchronized with the bist_clk. In this case, you can add the
rst_l signal synchronizer using the Add Signal Synchronization command (add signal
synchronization rst_l). This guarantees the proper resetting of all the sequential logic within
controller module.

Arguments
• -Asynchronous
A switch that instructs the tool to generate the BIST controller, so that it is asynchronously
reset when the rst_l signal goes from non-asserted to asserted. This is the default upon
invocation of the tool.
• -Synchronous
A switch that instructs the tool to generate the BIST controller so that it is reset
synchronously with the main controller clock when the rst_l signal is asserted.
Related Topics
Setup Controller Clock
Report Environment
Set Controller Hold

216 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Design Sharing

Setup Design Sharing

Legal Modes: BISTGEN
Prerequisites: None
Sets the ability to share BIST memory collars within the same controller.
Usage
SETup DEsign Sharing -Bist_collar { ON | OFf }
Description
Sets the ability to share BIST memory collars within the same controller. This command will
allow for the sharing of memory blocks, such that only one memory block is generated for each
type of memory model specified. This sharing can be applied to BIST-ready, non BIST-ready,
and ROM memory models.

The default of the tool is to inline every mux regardless of the Set Bist Insertion command being
set to ON or OFf.

Note
You cannot share memory collars across multiple controllers.

Sharing Memory Blocks

To share memory blocks, follow these steps:

1. Add all memory models for which the controller is generated using the Add Memory
Models command.
2. Turn on block sharing using the Setup Design Sharing command. This will instruct the
tool to generate a single memory block for every memory model.
3. Optionally, specify other controller parameters.
4. Run the BIST generation, and save the generated RTL.

Specparam Format
Due to block sharing, the specparam is defined in a specify/endspecify code block inside the
BIST controller (generated when the Set Bist Insertion command specifies the -on switch) and it
is updated to include the memory number. This is useful later on when preforming BIST
insertion.

The specparam format is as follows:

specparam mgc_dft_connect$ContrPinName = “BlockName/<MemNumber>/

BlockPinName”;

MBISTArchitect™ Reference Manual, v2021.2 and Later 217

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Design Sharing

Arguments
• -Bist_collar { ON | OFf }
A required switch and literal pair that turns the ability to share collars on or off. The tool
default is ON.
Note
Collar sharing is the tool default behavior (the ON switch). You must specify the
OFf switch if you want backwards compatibility.

Examples
In the following example, there are two types of memory models, a ram4x4 and a ram8x4. This
example will generate a controller to test six memories, three of each type. Since block sharing
is on, the tool will generate only two memory blocks, one for every memory type.

The following is an example of the BIST generation dofile and the RTL the tool generates:

add memory model ram8x4 -collar BLK_8x4

add memory model ram4x4 -collar BLK_4x4
add memory model ram8x4 ram8x4
add memory model ram4x4 ram4x4
setup design sharing -bist_collar on
set bist insertion -on
run
save bist

218 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Design Sharing

module ram8x4_multi_bist (
aa2_0,
aa1_0,
aa0_0,
ab2_0,
...
specify
...
specparam mgc_dft_connect$aa2_0 = “BLK_8x4/<0>/test_aa2”;
...
specparam mgc_dft_connect$DI0_5 = “BLK_4x4/<5>/test_DIO”;
...
endspecify
...
endmodule

module BLK_4x4 (
DO3, DO2, DO1, DO0, ...
...
endmodule

module BLK_8x4 (
da_03, da_o2, da_o1, da_o0,
endmodule

module ram8x4_multi_bist_con (
tst_done,
fail_h,
test_h,
clk,
rst_l,
...
BLK_8x4 BLK_8x4_instance_0 ( ... );
BLK_8x4 BLK_8x4_instance_1 ( ... );
BLK_8x4 BLK_8x4_instance_2 ( ... );
BLK_4x4 BLK_4x4_instance_0 ( ... );
BLK_4x4 BLK_4x4_instance_1 ( ... );
BLK_4x4 BLK_4x4_instance_2 ( ... );
...
endmodule

Related Topics
Add Memory Models
Report Environment
Set Bist Insertion

MBISTArchitect™ Reference Manual, v2021.2 and Later 219

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Diagnostic Clock

Setup Diagnostic Clock

Legal Modes: BISTGEN
Prerequisites: None
Selects the clock used to shift out the diagnostic data.
Usage
SETup DIagnostic Clock { -Bist_clk | -Slow_tester_clk }
Description
Selects the clock used to shift out the diagnostic data. Specify the -Bist_clk switch to use the
BIST clock. Specify the -Slow_tester_clk switch to use a separate clock.

Arguments
• -Bist_clk
A required switch that instructs the tool to use the BIST clock to shift out the diagnostic
data. This is the default setting.
• -Slow_tester_clk
A required switch that instructs the tool to use a separate clock to shift out the diagnostic
data. This creates a new test clock pin (diag_clk), in the controller pin list. The clock pin
will be toggled at half the BIST clock rate in the generated test bench. You can change the
name of this new pin using the Set Pin Name command.
Examples
The following example specifies that the diag_clk pin should be used to shift out the diagnostic
data:

setup diagnostic clock -slow_tester_clk

Related Topics
Setup Memory Clock
Setup Observation Scheme
Set Pin Name
Report Environment

220 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup File Naming

Setup File Naming

Legal Modes: BISTGEN
Prerequisites: None
Explicitly defines the filenames for one or more of any of the saved output file.
Usage
SETup FIle Naming [ -Bist_model filename ] [ -COnnected_model filename ]
[ -Testbench filename ] [ -Script filename ] [ -CTdl filename ] [-Wgl filename ]
[ -Prefix new_default_root ]
Description
Explicitly defines the filenames for one or more of any of the saved output file.

Sometimes the default filenames produce a different format than one that is most useful to you.
For example, your simulator might only accept files in a specific format. Using this command
you do not have to rename your files at a later time to fit a specific tool’s file name
requirements. Table 1-7 lists the output file default names. For more information, see
“MBISTArchitect Output File Naming” in the MBISTArchitect Process Guide.
Table 1-7. Output File Default Names
Model Verilog VHDL
bist_model prefix.v prefix.vhd
connected_model prefix_con.v prefix_con.vhd
testbench prefix_tb.v prefix_tb.vhd
script prefix.v_dcscript prefix.vhd_dcscript
ctdl prefix.v.ctdf prefix.vhd.ctdf
wgl prefix.wgl prefix.wgl

Note
The filenames that you define are used verbatim for the generated output files. That is, the
tool adds no additional prefixes or suffixes to the filenames you define. For example, if you
want the Verilog model that the tool produces to be named “4X4”, and you issue the command
“setup file naming -bist_model 4X4”, the tool creates a Verilog file named 4X4. If you then
issue the command “setup file naming -test_bench 4X4”, the tool creates a testbench file that is
also named “4X4”, and effectively overwrites your Verilog file. It is important that you choose
your file names very carefully.

MBISTArchitect™ Reference Manual, v2021.2 and Later 221

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup File Naming

Arguments
• -Bist_model filename
An optional switch and string pair that specifies the HDL model name that the tool writes
when you issue a Save Bist command.
By default, the tool produces the following file when you issue the Save Bist command:
“model_name_bist.in_file_suffix”
• -COnnected_model filename
An optional switch and string pair that specifies the connection file name that the tool writes
when you issue the Save Bist command.
By default, the connection file name is “model_name_bist_con.in_file_suffix”.
• -Test_bench filename
An optional switch and string pair that specifies the testbench name that the tool writes
when you issue the Save Bist command.
By default, the testbench name is “model_name_tb.in_file_suffix”.
• -Script filename
An optional switch and string pair that specifies the script name that the tool writes when
you issue the Save Bist command.
By default, the BIST synthesis script name is “model_name_bist.in_file_suffix_dcscript”
(for the Synopsys Design Compiler).
• -CTdl filename
An optional switch and string pair that specifies the name that the tool writes when you issue
the Save Bist command.
By default, the file name is “model_name_bist.v.ctdf”.
• -Wgl filename
An optional switch and string pair that specifies the WGL filename that the tool writes when
you issue the Save Bist command.
By default, the WGL file name is “model_name_bist.wgl”.
• -Prefix new_default_root
An optional switch and string pair that specifies a prefix for the tool to use when it generates
the names of the BIST model, connection, and testbench files.
Use the switches separately, or use the -prefix switch once to specify the same prefix for all
of the filenames.
Note
A name specified with the model takes precedence over the -Prefix switch when
used in the same command.

222 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup File Naming

Examples
A minimal MBISTArchitect session that generates and saves BIST logic that uses your explicit
file naming for the BIST model includes the following commands:

load library dft.lib

add memory models ram16x16
set file naming -bist_model ram16x16.vhdl
run
save bist -vhdl

The HDL model that the tool produces in this example has the name, “ram16x16.vhdl”. Had
you not used the Setup File Naming command, the default BIST model name would be
“ram16x16_bist.vhd”.

Related Topics
Save Bist
Report Environment
Set Design Name

MBISTArchitect™ Reference Manual, v2021.2 and Later 223

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Full_speed

Setup Full_speed
Legal Modes: BISTGEN
Prerequisites: None
Sets the function of full-speed automatic BIST conversion to either on or off.
Usage
SETup FUll_speed -ON | -OFf
Description
Sets the function of full-speed automatic BIST conversion to either on or off. Use this command
to direct the tool to automate BIST conversion of the specifications required for full-speed
testing. When the command is turned on, the tool will verify that the combination of memories
specified are compatible for full-speed specification. The verification will ensure that the read
and write cycles of all memories can be merged in a compatible way to generate internally a
full-speed version of read and write cycles.

The tool will analyze any memory model which does not conform to the full-speed
requirements. If the model is found to be non-conforming or asynchronous, the tool issues an
error and does not convert the model to a full-speed version. Otherwise, if the model is found to
be synchronous and to conform to the requirements, the model is internally converted to a
full-speed version. The tool processes the read/write cycles of the memory model and converts
them into single-cycle operations.

When all memories are verified, the tool determines the proper pipeline depth and automatically
defines the pipeline in the tool environment. If the tool fails to convert two or more memories to
full-speed with a single consistent read/write cycle, setup is illegal and the tool reports an error.

For more information, see the Setup Pipeline Registers command.

Arguments
• -ON
A switch that turns on full-speed automatic BIST conversion.
• -OFf
A switch that turns full-speed automatic BIST conversion off. This is the default setting.
Related Topics
Setup Pipeline Registers
Report Environment

224 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Mbist Algorithms

Setup Mbist Algorithms

Legal Modes: BISTGEN
Prerequisites: None
Specifies the default BIST algorithms to be used by all controllers on all memories.
Usage
SETup MBist Algorithms algorithm1 [ algorithm2 ]…
Description
Specifies the default BIST algorithms to be used by all controllers on all memories. If you do
not use this command, the default algorithm is march2 (for writable memories) or ROM1 (for
read-only memories). If you use this command and if you want the march2 (or ROM1)
algorithm, then you must specify them as algorithm arguments.

If you have a model with multiple ports, the algorithms you specify here are applied to all ports
of the memory in turn, unless you use the Add Mbist Algorithms command to override this
setup for a particular memory port.

Different algorithms target different types of faults, and the more algorithms you choose the
longer your test will take. Therefore it is important that you carefully select the most efficient
algorithms for testing the types of faults that are common for your controller memory.

If you want to setup a user-defined algorithm as a default, use the Load Algorithms command
first.

Note
The port isolation testing algorithm is not a built-in algorithm. You must first make a UDA
(User Defined Algorithm) using the w_r port isolation operation, and only then can you add
it with either the Add Mbist Algorithms command, or the Setup Mbist Algorithms command.
For more information, see “User-Defined Algorithms” in the MBISTArchitect Process Guide.

Arguments
• algorithm1 [ algorithm2 ]…
A required repeatable string that specifies the name of one or more algorithms that you want
to use as the default algorithms for all ports.
Available algorithms are:
o For writable memories: addressdecoder_bg0, addressdecoder_bg1, checkerBoard
(also called TopChecker), col_march1, march1, march2, march3, retentionCB,
unique, and <uda_name>.
o For read-only memories: ROM1 (same as ROM), and ROM2.
o Not available: comparator test, and port_interaction.

MBISTArchitect™ Reference Manual, v2021.2 and Later 225

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Mbist Algorithms

The BIST circuitry applies algorithms in the order in which you enter the algorithm names
here, except for comparator test and port interaction test, neither of which can be specified
with this command. The comparator test is always executed first, and port interaction test
last. Use the Set Comparator Test command for comparator test and use the Add Mbist
Algorithms command for port_interaction.
If you specify the ROM1 or ROM2 algorithm, you need to provide a ROM content file in
the propietary Siemens EDA Modelfile format.
Note
If you repeat algorithms in the command line, the tool generates a warning message.

Examples
Enter the following command to override the march2 algorithm, and define the march1,
march3, and the Unique as the default test algorithms for testing all memory ports:

setup Mbist Algorithms march1 march3 unique

In the following multi-port example the following is used to set up four ports:

setup mbist algorithm addressdecoder_bg0

add mbist algorithm 1 march2 unique
add mbist algorithm 3 addressdecoder_bg0

The result of this would be the following algorithms assigned to the following ports:

• Port 1: The march2 and unique algorithms.

• Port 2: The addressdecoder_bg0 algorithm (using the Setup Mbist Algorithm
command).
• Port 3: The addressdecoder_bg0 algorithm.
• Port 4: The addressdecoder_bg0 algorithm (using the Setup Mbist algorithm command).
Related Topics
Add Mbist Algorithms
Delete Mbist Algorithms
Report Algorithms
Report Environment
Report Mbist Algorithms
Setup Memory Test
Load Algorithms

226 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Mbist Compressor

Setup Mbist Compressor

Legal Modes: BISTGEN
Prerequisites: None
Instructs the tool to implement a BIST configuration that uses a compressor (also called a
Multiple Input Signature Register, or MISR) to capture the output of the ROM under test.
Usage
SETup MBist COMpressor [ -Scan | -NOScan ] [ -LOCalcomparator | -NOLocalcomparator ]
Description
Instructs the tool to implement a BIST configuration that uses a compressor (also called a
Multiple Input Signature Register, or MISR) to capture the output of the ROM under test.

The Setup Mbist Compressor command defines one or more compressors for use in
compressing test patterns and producing a test signature. You then compare the test signature
against a known, “good” test signature to determine the pass/fail state of the memory(s) under
test.

You must precompute the MISR signature and then implement the signature comparator to
create a go/nogo test. For ROMs, the signature is precomputed based on the ROM contents and
the ROM1 or ROM2 test algorithm. A correct MISR signature requires that the ROM content be
known.

Note
You cannot use this command if you add algorithms other than ROM1 or ROM2.
Additionally, only the proprietary Siemens EDA memory content format is supported.

Depending on your design requirements, you can place the compressor either directly at the
output of the memory model (Figure 1-14) or downstream in the design (Figure 1-13).

Figure 1-13. Compressor Downstream from the Memory

MBISTArchitect™ Reference Manual, v2021.2 and Later 227

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Mbist Compressor

Figure 1-14. BIST Architecture With a Compressor

The following table lists the input and output signals for the compressor:
Table 1-8. Compressor Signals
Name Description
Inputs
data The memory output data.
compress_h An active-high compressor control signal. Compress_h high
enables data compression. Works with test_h.
test_h An active-high compressor control signal. Test_h high enables
data compression. Works with compress_h.
hold_l An active-low signal that forces the compressor to pause its
process and maintain its current state. Add the hold logic to the
compressor by issuing the Set Controller Hold command with
the -On switch.
clk The compressor clock.
rst_l An active-low signal that initializes the compressor.
si The scan data input to the compressor.
se The scan data input enable. You must connect this signal at the
top level.
Outputs
q The compressed test signature.
so A serial output for the compressed test signature.

228 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Mbist Compressor

Arguments
• -Scan
An optional switch that generates additional logic for scanning out the MISR test signature.
This is the default.
• -NOScan
An optional switch that prevents generation of additional logic for scanning out the MISR
test signature.
• -LOCalComparator
An optional switch that generates a signature comparator in the memory BIST collar. When
you specify this switch the tool generates a controller that compares the end of test MISR
content to the precomputed signature. The BIST collar will have an extra output pin that will
be asserted to the state “1” if the signature does not match.
• -NOLocalcomparator
An optional switch that prevents the signature comparison of MISR content. This is the
default.
Examples
The following example shows a setup configuration that generates a single compressor for a
single memory. In this setup configuration, you load a library, list the available memory models,
examine a specific memory model, and then add it as the model for which you want to insert the
BIST logic. After adding the memory model, you define the test logic using the setup mbist
compressor command with the -Scan switch.

After issuing the Run command, save the output in the desired formats using the Save Bist
command.

load library dft.lib

report memory models -library
report memory models -model rom16x16
add memory models rom16x16
setup mbist compressor -scan
run
save bist

The following example shows a setup configuration that includes the Setup Mbist Compressor
command and generates a comparison of the end of test MISR content with a stored,
precomputed signature:

load library dft.lib

report memory -models -library
report memory -models -model rom16x16
add memory models rom16x16 -file rom16x16_data
setup mbist compressor -localcomparator
setup misr polynomial -size 64
run
save bist

MBISTArchitect™ Reference Manual, v2021.2 and Later 229

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Mbist Compressor

Related Topics
Run
Save Bist
Set Pin Name
Setup Misr Polynomial
Setup Observation Scheme
Report Environment

230 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Memory Access

Setup Memory Access

Legal Modes: BISTGEN
Prerequisites: None
Enables and disables simultaneous read access of multiple port memories.
Usage
SETup MEmory Access -Simultaneous | -Nosimultaneous
Description
Enables and disables simultaneous read access of multiple port memories.

Given a memory with N ports, when you use the add mbist algorithms P algname command,
you specify an algorithm for port P in 0..N-1. Assuming that you have one write_enable control
and one address bus per port, the write operations for the specified algorithm occur exclusively
on port P. When simultaneous setup memory access is enabled, read operations occur on all N
ports because there should be no unintentional writes. (If you have one shared write_enable
control for all ports then writes would occur on all N ports too, but that is not a likely multiport
memory design.)

Note
The port_interaction algorithm is not affected by the use of this command.

Arguments
• -Simultaneous
Enables simultaneous read access of multiple port memories. This is the default.
For example, given a memory with N ports and MBIST algorithms applied to port P, the
same address is driven to all N ports; not just port P. During a read the BIST comparator
checks the return value from all the memory ports, not just the memory port to which the
algorithms are applied. If you are using diagnostics and there is a miscompare on any port,
the diagnostic field portnum is the memory port to which the algorithms are applied (for this
example, port P).
• -Nosimultaneous
Disables simultaneous read access of multiple port memories by differentiating the binary
address of the read port being tested from the binary address of the other read ports.
Staggered addresses are driven to the memory ports. This is the same addressing scheme
used in the port_interaction algorithm, which checks the return value from all memory ports.
A march2 algorithm using Setup Memory Access -nosimultaneous is different because the
BIST comparator only checks the return value from the memory port to which the
algorithms are applied.

MBISTArchitect™ Reference Manual, v2021.2 and Later 231

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Memory Access

For example, given a memory with N ports and MBIST algorithms applied to port P, if P
gets address A, then the others get A+1, A+2, and so forth. Running a single-port test with
-nosimultaneous specified only compares the return value from port P.
Note
If your design includes a read-only port that cannot be paired with a write-only port,
the -nosimultaneous switch prevents the pre-defined algorithms from testing the
non-paired read-only port. You need to add the port_interaction algorithm that uses
multiple addresses and multiple ports. See also: “Setup Mbist Algorithms” on page 225.

Related Topics
Setup Memory Test
Report Environment
Setup Memory Clock

232 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Memory Clock

Setup Memory Clock

Legal Modes: BISTGEN
Prerequisites: None
Defines the memory clock settings and specifies whether the clock is connected to the
memories’ system clock.
Usage
SETup MEmory Clock { -System | -Test [ Noinvert | Invert ] | -Algsel_clk algsel_scan_clock }
Description
Defines the memory clock settings and specifies whether the clock is connected to the
memories’ system clock. Selects a separate clock for loading the algorithm selection register. It
can also be used to define test mode clock settings.

The -test switch adds the mux on the clock path, and causes the system mode clock to be
connected to one input of this mux and test mode clock signals to the other input of the mux.
The system clock connects to the memory’s system mode clock.

The test mode clock connects to the BIST controller, where it is driven from the bist_clock
signal. It supports two types of test clock connections: Noinvert and Invert. The -test switch
controls the signal inversion of the BIST clock when it is assigned to the memory clock.

Arguments
• -System
This switch preserves the original system clock path to your memory, as shown in
Figure 1-15. (The system’s memory clock signal is shown below as “mem_clk,” and the
memory clock port is shown as “clk.”) The tool will not insert a mux into the memory clock
path and will not attempt to have the BIST controller drive the memory clock. This is the
default. This is known as the “gate clock off” scheme.
Figure 1-15. Setup Memory Clock -System

MBISTArchitect™ Reference Manual, v2021.2 and Later 233

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Memory Clock

• -Test [ Noinvert | Invert ]

This switch alters the original clock path to your memory by inserting a mux which chooses
between the system’s normal memory clock and the test clock used by BIST. When test_h is
high, the BIST controller is performing test and the memory is clocked by bist_clk; when
test_h is low, your system is in normal operation and the memory is clocked by the system’s
memory clock. This is known as the “gate clock on” scheme. Noinvert is the default.
o Noinvert
A literal that instructs the tool to connect the BIST clock signal to the memory as
shown in the example in Figure 1-16. This is also known as the test clock scheme
with no clock inversion and is the default when you invoke the command using the
-test switch.
Figure 1-16. Setup Memory Clock -Test NoInvert

o Invert
A literal that instructs the tool to connect the inverted BIST clock signal to the
memory as shown in the example in Figure 1-17. This is also known as the test clock
scheme with clock inversion.
Figure 1-17. Setup Memory Clock -Test Invert

234 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Memory Clock

• -Algsel_clk algsel_scan_clock
Selects a separate clock for loading the algorithm selection register, when using the Setup
Algorithm Command of the online algorithm selection.
Related Topics
Setup Algorithm Selection
Setup Clock Period
Setup Controller Clock
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 235

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Memory Test

Setup Memory Test

Legal Modes: BISTGEN
Prerequisites: None
Defines the testing method of the BIST controller.
Usage
SETup MEmory Test [ -Concurrent | -Sequential [ Contiguous | Interleaved ] ]
Description
Defines the testing method of the BIST controller. The following testing methods are available:

• Concurrent — Default testing method. The controller simultaneously applies the

algorithms to all memories. However, there are instances when concurrent algorithm
testing is not feasible. For instance, memories sharing a common tri-state data bus can
only be tested with a BIST controller configured for sequential memory tests.
If the design contains any dual-ported memories, the algorithms are simultaneously
applied to the first port for all memories, then to the second port for all memories. If
some memories are single-ported, the output from those memories is ignored during the
second port tests.
• Sequential Contiguous — The controller applies all algorithms to each memory in
sequence, keeping all other memories inactive. Because the algorithms are repeated for
each memory, sequential testing takes significantly more time to complete than
concurrent testing. In particular, performing retention tests with sequential contiguous
testing multiplies the number of retention delays during BIST, once for each memory,
which is costly at the tester.
If the design contains any dual-ported memories, the algorithms are applied to each port
of a memory before proceeding to the next memory. If some memories are single-
ported, the algorithms for the second port are still applied to each memory, but the
output is ignored for the second port tests for a single-ported memory.
• Sequential Interleaved — The controller applies a single algorithm step to each
memory in sequence before proceeding to the next algorithm step. This testing method
may reduce the total test time as compared to sequential contiguous testing. For
example, retention delays will overlap as they are applied to each memory.
If the design contains any dual-ported memories, the algorithms are applied, step by
step, to the first port of every memory, then to the second port of every memory. If some
memories are single-ported, the output from those memories is ignored during the
second port tests.

Note
The tool does not support asynchronous memory testing.

236 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Memory Test

Arguments
• -Concurrent
An optional switch that instructs the controller to run algorithm tests on all memories at the
same time. This is the default.
• -Sequential [ Contiguous | Interleaved ]
An optional switch and literal pair that instructs the controller to perform algorithm tests on
the memories in sequence.
Contiguous
An optional literal that instructs the tool to complete algorithm tests one memory at a
time. This is the default sequential behavior.
Interleaved
An optional literal that instructs the tool to interleave algorithm steps between
memories.
Examples
By default, the controller tests multiple memories concurrently. To specify that the controller
tests each of these memories sequentially, use the following command option:

setup memory test -sequential

The following example shows how to enable sequential interleaved testing:

add mbist algorithms 1 march1 unique

setup memory test -sequential interleaved
run
save bist

There are multiple ways of implementing a comparator for sequential memory test. For
example, memory data outputs can be muxed on to a single comparator data input bus (for
example, only data out of the memory that is currently being tested could be passed to the
comparator). This dramatically reduces the number of data inputs to the comparator. The mux
itself can be implemented as one big, giant block or can be built from a cascade of 2-input mux
placed close to individual memories.

Related Topics
Add Mbist Algorithms
Report Environment
Setup Mbist Algorithms

MBISTArchitect™ Reference Manual, v2021.2 and Later 237

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Misr Polynomial

Setup Misr Polynomial

Legal Modes: BISTGEN
Prerequisites: None
Defines the size and tap locations of a custom MISR polynomial.
Usage
SETup MIsr Polynomial -Size size [ -Taps taps… ]
Description
Defines the size and tap locations of a custom MISR polynomial.

MISR is known as “Multiple-Input Shift Register” or “Multiple-Input Signature Register”. This

command applies only to ROM testing, where a MISR is used to calculate the output signature
of the memory.

If you do not specify a MISR for your ROM(s), MBISTArchitect will automatically add a
MISR with the following sizes:

• 32 bits — For ROM data sizes of 32 or smaller.

• ROM data size — For ROM data sizes between 33 and 64.
• 64 bits — For ROM data sizes greater than 64.
The MISR is implemented with a Type 1 external-XOR Linear Feedback Shift Register
(LFSR). Figure 1-18 illustrates a MISR of size 4 with taps at bits 3, 1, and 0. The LFSR logic is
shown in black, and the logic that configures the LFSR as a MISR is shown in red.

The LFSR shifts the data from the MSB to the LSB and the signature data is shifted out from the
output of the LSB. Tapped bits are XORed and feed back into the MSB (bit N-1, where N is the
MISR size). Additionally, the MISR receives feedback from the memory on every read cycle.
The red numbered inputs represent the data signals from the memory.

238 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Misr Polynomial

Figure 1-18. LFSR MISR Logic

Arguments
• -Size size
A required switch and integer pair that defines the size of the MISR polynomial in bits. The
maximum MISR size is 512. Larger MISRs are less likely to have aliasing problems.
If you specify a size smaller than the ROM data size, MBISTArchitect adds a spatial
compactor (XOR logic cloud), instantiated within the MISR module.
• -Taps taps…
An optional switch and list of integers that define the location of taps. The tap locations
must be listed in descending order. You can specify any number of taps, provided the first
tap is at the MSB (MISR size -1) and the last tap is at the LSB (0).
If you do not specify any taps, MBISTArchitect will use a default set of taps based on the
MISR size. The default number of taps is 8.
Examples
The following example adds the MISR polynomial in Figure 1-18:

setup misr polynomial -size 4 -taps 3 1 0

The following example shows how to create a MISR polynomial that is 256 bit in size and has
eight taps at various locations:

setup misr polynomial -size 256 -taps 255 192 161 129 97 64 32 0

Related Topics
Add Mbist Algorithms
Add Memory Models
Report Algorithm Steps
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 239

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Misr Polynomial

Report Misr Polynomial

Setup Mbist Algorithms
Setup Mbist Compressor

240 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Observation Scheme

Setup Observation Scheme

Legal Modes: BISTGEN
Prerequisites: None
Defines the observation scheme of the BIST controller.
Usage
SETup OBservation Scheme [ -COMPAre | -COMPRess ] [ -CONnect | -Noconnect ]
Description
Defines the observation scheme of the BIST controller.

Arguments
• -COMPAre
An optional switch that generates comparator logic along with the BIST controller.
• -COMPRess
An optional switch that generates compressor (MISR) logic along with the BIST controller.
The MISR module will be instantiated within the BIST collar.
• -CONnect
An optional switch that generates connections between the BIST controller, the memory
model, and the comparator. This is the default behavior.
You must also include the -COMPAre switch if you use the -CONnect switch.
• -Noconnect
An optional switch that prevents the generation of comparator connections.
Examples
Enter the following command to set the observation scheme to compressor:

setup observation scheme -compress

Related Topics
Setup Mbist Compressor
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 241

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Pipeline Registers

Setup Pipeline Registers

Legal Modes: BISTGEN
Prerequisites: Synchronous memories
Adds pipeline stages to meet timing requirements for high-speed testing.
Usage
SETup PIpeline Registers
[Expect_process {ON | OFf}] |
[Compare_result {ON | OFf}] |
[Output_block stages [-Instance [COLlar collar] [CONTROLLer controller]]] |
[Input_block stages [-Instance
[ALL [COLlar collar] [CONTROLLer controller]] |
{[DATA [COLlar collar] [CONTROLLer controller]]
[ADDRESS [COLlar collar] [CONTROLLer controller]]
[CONTROL [COLlar collar] [CONTROLLer controller]]}
]]
Description
Adds pipeline stages to meet timing requirements for high-speed testing. For more information
on high-speed testing, see “Full-Speed BIST” in the MBISTArchitect Process Guide.
Figure 1-19 shows the possible locations for pipelining.

242 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Pipeline Registers

Figure 1-19. Pipelining Locations

You can add pipelining to the following areas:

• Expect_process — Indexes the expected data and adds pipeline stages to the indexing
logic at location 11. Expect_process pipelining improves testing performance for wide
memories.
• Compare_result — Adds one pipeline stage at location 10. When running at high-
speeds, compare_result pipelining gives the comparator (XOR cone) an extra cycle to
compare the data before the result is sent to the FSM. This pipeline stage is included
automatically when you add diagnostics with restart.
• Output_block — Defines the pipeline stages for the output of the memory. The output
path is highlighted in red. The stages at location 7 represent the memory latency and are
defined by the memory model; however, you must include them when specifying to total
output stages with this command.
• Input_block — Defines the pipeline stages for the input of the memory. The input path
is highlighted in green.

MBISTArchitect™ Reference Manual, v2021.2 and Later 243

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Pipeline Registers

If you want to add pipelining to more than one of these areas (i.e. output_block and
input_block), you must use a separate command instance for each area. Successive commands
will overwrite the pipelining information for a given area. For example, if you specify
Input_block pipelining in two separate commands, the information from the first command is
discarded.

For Output_block and Input_block pipelining, you can add stages to the collar and/or the
controller. Collar pipeline stages are added to each memory collar; therefore, the total number
of registers added is multiplied by the number of memories. Controller stages are added once to
the controller and shared by all the memories. For designs with many memories, you may want
to add the pipeline stages to the controller to conserve area.

Arguments
• Expect_process { ON | OFf }
An optional literal pair that indexes and pipelines the expected data. By default, there is no
expect_process pipelining.
ON
Enables the expect_process pipelining.
OFf
Disables the expect_process pipelining.
• Compare_result { ON | OFf }
An optional literal pair that adds pipelining to the output of the comparator logic (XOR
cone). By default, MBISTArchitect does not pipeline the comparator result; however, if you
enable diagnostics with restart, the comparator result is pipelined automatically.
ON
Enables the comparator result pipelining. The output pipeline depth increases by one.
OFf
Disables the comparator result pipelining.
If there is already one register between the memory read_enable and the XOR gates, then
using “Compare_result ON” adds a second register on the output of the XOR cone inside the
BIST controller.
• Output_block stages
An optional literal and integer pair that specifies the total number of stages along the output
path. Figure 1-19 shows the output path in red.
The total stages is the sum of:
o Memory latency — The number of clock cycles between the assertion of the
read_enable signal and availability of the data output. This value is typically one for
a synchronous memory. The stages at location 7 represent the memory latency.

244 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Pipeline Registers

o New pipeline stages — The number of output block controller and/or collar stages
you want to add. These stages are specified following the -Instance switch and are
represented by locations 8 and 9.
o Fail_h register — One stage included at the end of the output path to register the
fail_h signal.
For example, if you want to add two output stages to the collar of a memory with a latency
of one, you would specify four (1 + 2 + 1) for the total stages.
Note
If you have enabled compare_result pipelining, do not include the resulting extra
stage in your total output stages.

• -Instance [COLlar collar] [CONTROLLer controller]

An optional switch set that specifies the number of output pipeline registers to instantiate in
the collar and/or controller.
COLlar collar
An optional literal and integer pair that instantiates the specified number of output
stages in the collar (location 8 in Figure 1-19) for each memory.
CONTROLLer controller
An optional literal and integer pair that instantiates the specified number of output
stages in the controller (location 9 in Figure 1-19).
• Input_block stages
An optional literal and integer pair that specifies the total number of stages to add along the
input path. In Figure 1-19, the output path is shown in green. You can instantiate pipeline
stages for the data, address, and/or control signals. The specified stages is the largest total
stages (controller and collar) for a single input path. For example, if you add two stages to
the address input and three stages to the data input, you would specify three for the total
input stages.
• -Instance
An optional switch that instantiates the input pipeline registers along each signal path (data,
address, control, or all). The total number of stages (collar and controller) for at least one
signal path must equal the specified input block stages. Figure 1-19 shows the locations for
input pipeline stages.
ALL [ Collar collar ] [ Controller controller ]
An optional literal and integer set that specifies the number of pipeline stages for all
signal paths (address, data, and control). Controller stages are added at locations 1, 2,
and 3, and collar stages are added at locations 4, 5, and 6.
DATA [ Collar collar ] [ Controller controller ]

MBISTArchitect™ Reference Manual, v2021.2 and Later 245

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Pipeline Registers

An optional literal and integer set that specifies the number of pipeline stages for the
data path. Collar stages are added at location 5, and controller stages are added at
location 2.
ADDRESS [Collar collar] [Controller controller]
An optional literal and integer set that specifies the number of pipeline stages for the
address path. Collar stages are added at location 6, and controller stages are added at
location 1.
CONTROL [Collar collar] [Controller controller]
An optional literal and integer set that specifies the number of pipeline stages for the
control path. Collar stages are added at location 4, and controller stages are added at
location 3.
Examples
Example 1
The following example turns on both the expect process indexing and pipelining and the
compare result pipelining:

setup pipeline registers expect_process on

setup pipeline registers compare_result on
Example 2
The following example removes the previously-added comparator indexing and pipelining:

setup pipeline registers compare_result off

Example 3
The following example specifies that the memories have a latency of 1 and 2 new pipeline
stages are instantiated at the output of the memories in the controller:

setup pipeline registers output_block 4 -instance controller 2

The total output stages is 4 because it includes the memory latency (1), the new pipeline stages
(2), and the fail_h register (1). The specified memory latency must match the actual memory
latency as defined in the memory data sheet. If you have manually modified your memory
models for full-speed testing (manually removed the “wait” statements), you must still use the
latency from the data sheet for your design to simulate correctly.

Example 4
The following example adds both input and output pipelining:

setup pipeline registers output 4 -instance collar 1 controller 1

setup pipeline registers input 5 -instance data collar 1 controller 1 address collar 2 \
controller 3 control collar 3 controller 1

246 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Pipeline Registers

---------------------------------------------------
| Block | Depth | Pipeline Instantiation in |
| | +----------------------------
| | | Controller | Collar |
|----------+----------|-------------+--------------
| Output | 4 | 1 | 1 |
| Data | 5 | 1 | 1 |
| Address | 5 | 3 | 2 |
| Control | 5 | 1 | 3 |
---------------------------------------------------

The Report Environment command displays the detailed report of the pipelining.

Input Pipeline Stages: 5

Data Pipeline Delay Register Instances:
Collar : 1 stage.
Controller : 1 stage.
Address Pipeline Delay Register Instances:
Collar : 2 stages.
Controller : 3 stages.
Control Pipeline Delay Register Instances:
Collar : 3 stages.
Controller : 1 stage.
Output Pipeline Stages: 4
Output Pipeline Delay Register Instances:
Collar : 1 stage.
Controller : 1 stage.
Comparator Pipeline Position: 3

Related Topics
Report Pipeline Registers
Report Environment
Setup Full_speed

MBISTArchitect™ Reference Manual, v2021.2 and Later 247

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Reset Duration

Setup Reset Duration

Legal Modes: BISTGEN
Prerequisites: None
Defines the BIST controller reset behavior for the test bench.
Usage
SETup REset Duration [ncycles] [-Delay_test_h]
Description
Defines the BIST controller reset behavior for the test bench. For this command to have an
effect, you must issue this command prior to the Run command.

Figure 1-20 illustrates the default reset timing for the controller.

Figure 1-20. Default Reset Behavior

The default reset duration is 2 clock cycles with the test_h signal asserted 1 clock cycle after the
assertion of the rst_l signal. For this command, the reset duration is specified in whole clock
cycles; however, the test_h and rst_l signals are actually asserted and deasserted, respectively,
0.1 clock cycle earlier than specified. For example, if the reset duration is set as 3 cycles, the
actual duration is 2.9 cycles. This is to avoid possible race conditions during simulation.

Arguments
• ncycles
An optional integer that specifies the number of bist_clk cycles to assert the BIST reset
signal. The default setting is two clock cycles.

248 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Reset Duration

Note
To avoid a possible race condition, do not set the reset duration to one cycle unless
you are also using the -Delay_test_h switch.

• -Delay_test_h
An optional switch that delays the assertion of the test_h signal to one clock cycle following
the deassertion of the rst_l signal.
Examples
The following example sets the reset duration to three bist_clk cycles. The modified behavior is
shown in Figure 1-21.

setup reset duration 3

Figure 1-21. Reset Behavior with Three-Cycle Duration

The following example sets the reset duration to three bist_clk cycles and delays the assertion of
test_h until after the reset. The modified behavior is shown in Figure 1-22.

setup reset duration 3 -delay_test_h

MBISTArchitect™ Reference Manual, v2021.2 and Later 249

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Setup Reset Duration

Figure 1-22. Reset Behavior with Three-Cycle Duration and test_h Delay

Related Topics
Report Environment

250 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Setup Retention Cycles

Setup Retention Cycles

Legal Modes: BISTGEN
Prerequisites: None
Defines the delay value used in a WGL, Verilog, VHDL, or simulation testbench when waiting
to assert the resume signal to continue the BIST session following a retention test
synchronization delay.
Usage
SETup REtention Cycles integer
Description
Defines the delay value used in a WGL, Verilog, VHDL, or simulation testbench when waiting
to assert the resume signal to continue the BIST session following a retention test
synchronization delay.

Arguments
• integer
A required integer that defines the delay value to be used in the WGL testbench. Use this
command to specify the delay value, as a multiple of the number of controller clock cycles.
The default value is 100 cycles.
Examples
In the following example, this command will set the retention cycle to 80:

setup retention cycle 80

Related Topics
Report Environment

MBISTArchitect™ Reference Manual, v2021.2 and Later 251

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
System

System
Legal Modes: All
Prerequisites: None
Passes the specified command to the operating system for execution.
Usage
SYStem os_command
Description
Passes the specified command to the operating system for execution. After execution, control
returns to the application. You can also use ! instead of SYStem.

Arguments
• os_command
A required string that specifies any legal operating system command.
Examples
To view the contents of the memory_bist.v file, enter:

system vi memory_bist.v

Related Topics
Printenv

252 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Command Dictionary
Write Block Description

Write Block Description

Legal Modes: INT (BIST Mode of the Insertion Phase)
Prerequisites: None
Writes out a block description in a specified file of which the contents are similar to the contents
of a CTDF.
Usage
WRIte BLock Description file_name [ -Replace ]
Description
Writes out a block description in a specified file of which the contents are similar to the contents
of a CTDF.

Arguments
• file_name
A string containing the name of the specified file.
• -Replace
An optional switch that replaces the content of the previous file with new content.

MBISTArchitect™ Reference Manual, v2021.2 and Later 253

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Command Dictionary
Write Block Description

254 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 2
Shell Commands

This section describes the shell command that you use to invoke MBISTArchitect. The
notational conventions are the same as those used in other parts of the manual.
Shell Command Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
mbistarchitect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Shell Command Syntax Conventions

This manual uses the following command usage line syntax conventions.

Table 2-1. Conventions for Shell Command Syntax

Convention Example Usage
UPPercase REPort ENvironment Required command letters are in uppercase; in
most cases, you may omit lowercase letters when
entering commands or literal arguments and you
need not enter in uppercase. Command names
and options are normally case insensitive.
Commands usually follow the 3-2-1 rule: the first
three letters of the first word, the first two letters
of the second word, and the first letter of the
third, fourth, etc. words.
Boldface ADD BIsa Hardware A boldface font indicates a required argument.
-COLumn
[ ] EXIt [-Force] Square brackets enclose optional arguments. Do
not enter the brackets.
Italic DOFile filename An italic font indicates a user-supplied argument.
{ } SAVe BIst { -VErilog | Braces enclose arguments to show grouping. Do
-VHdl } [ -Fileprefix not enter the braces.
file_prefix ]
| DELete MEmory Model The vertical bar indicates an either/or choice
memory_name | -All between items. Do not include the bar in the
command.
Underline SET DOfile Abort ON | OFf An underlined item indicates either the default
argument or the default value of an argument.

MBISTArchitect™ Reference Manual, v2021.2 and Later 255

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Shell Commands
Shell Command Syntax Conventions

Table 2-1. Conventions for Shell Command Syntax (cont.)

Convention Example Usage
… ADD DAta Background An ellipsis follows an argument that may appear
background_pattern… more than once. Do not include the ellipsis when
entering commands.

256 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Shell Commands
mbistarchitect

mbistarchitect
You can invoke MBISTArchitect in one of three phases.
Usage
BIST Generation Phase
mbistarchitect -Bistgen
[-LIBrary filename ]
[-LICense_wait {minutes | NONE | UNLimited}]
[-LOGfile name ]
[-Replace]
[-Dofile name ]
[-HIStory]
BIST Insertion Phase
mbistarchitect design_name [ -VErilog ] [ -INCdir search_path... ]
[-LICense_wait {minutes | NONE | UNLimited}]
-Insertion
{ -TOp name } { -LVErilog library | -HIerarchical } [ -MIXED_ANSI_PORTS ]
[ -LOGfile name ]
[ -Replace ]
[ -Dofile name ]
[ -HIStory ]
Gate-Level Verification Phase
mbistarchitect design_name [ -VErilog | - VHdl ] [ -INCdir search_path... ]
[-LICense_wait {minutes | NONE | UNLimited}]
-GAte-level_verification
[ -TOp name ] [ -LIB ATPG_library ] [ -SEnsitive | -INSENsitive ] [ -LOAd_warnings ]
[ -LOGfile name ]
[ -Replace ]
[ -Dofile name ]
[ -HIStory ]
Help and Information
mbistarchitect [ -Help | -Usage | -MANual | -VERSion ]
Description
You can invoke MBISTArchitect in one of three phases:

BISTGEN Phase — For BIST logic generation only. You cannot insert the BIST logic in this
phase.

BIST Insertion Phase — For BIST logic generation and insertion. You can create BIST logic
and insert controllers into your design or you can create your controllers and insert them at a
later time.

MBISTArchitect™ Reference Manual, v2021.2 and Later 257

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Shell Commands
mbistarchitect

Note
Gate-Level Verification Phase — For verification only. In this phase you can use the tool to
verify previously generated BIST logic, but you cannot generate or insert BIST logic.

Note
If you do not specify a phase, using the -Insertion, -Gate-level_verification, or -Bistgen
switches, MBISTArchitect will launch the BIST Generation Phase by default.

Arguments
• -Bistgen
A required switch that invokes the tool in the BIST Generation Phase. This is for
backwards-compatibility. The following switch is used specifically for the BIST Generation
Phase:
-Library file_name
An optional switch and string pair that specifies the ATPG library file containing
memory models.
• design_name
A string that specifies the file name of the design netlist. The netlist can be either RTL or
gate-level. This argument is required for the Insertion or Gate-Level Verification phases.
• -VERIlog
An optional switch that specifies the design format as Verilog.
• -VHdl
An optional switch that specifies the design format as VHDL.
Note
MBISTArchitect does not support VHDL for insertion.

• -INCdir search_path...
An optional switch and repeatable string that specifies the directories in which the tool
searches for Verilog files included with ‘include “filename”. You must include at least one
search_path argument. Separate multiple paths with a space. The search_paths can be one
of the following:
o A valid directory name relative to the current working directory.
o An absolute directory path name.
o A set of directories specified with the asterisk wild card character “*”. For example,
if you specify -incdir sp*, then every directory within the current working directory
that starts with sp is recognized as a search path.

258 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Shell Commands
mbistarchitect

Note
You cannot specify a file name. It must be directory name. The tool will issue an
error if the directory does not exist or issue a warning if the directory exists but is
empty.

The following behavior is observed while looking up an ‘include file target in search paths:
o The tool searches the directories, for the included file, in the order they appeared at
invocation.
o If the same target file name can be found in multiple search paths, then the tool uses
the first found file instance and ignores the remaining instances.
o The tool does not search within the sub-directories of a search path; however, if the
target includes a relative path, then the target path is appended to the search path.
Search paths take precedence over the current search criteria; however, the tool will return
to the normal search algorithm if the file is not found in a specified search path. The search
algorithm works as follows:
a. Look for the file name in the search path(s). If found, process the file and stop
searching.
b. Look for the file in a place relative to the directory containing the calling file. If
found, process the file and stop searching.
c. Look for the file in the current working directory (where the tool was invoked). If
found, process the file and stop searching.
d. Issue the following error message if the file was not found: Failed to open
<filename>.
This algorithm applies only for included file with relative path only. If an absolute path is
specified, the tool processes the file from the given path. If you do not use the -incdir switch,
the tool will perform steps 2, 3, and 4 of the search algorithm.
• -LICense_wait minutes | NONE | UNLimited
An optional switch and integer, or switch and literal, that specifies the tool’s response if the
license is unavailable.
Choose one of the following options:
minutes — An positive integer that specifies the number of minutes to wait for the
license.
NONE — A literal that directs the Tessent tool to exit immediately if no license is
available.
UNLimited — A literal that directs the Tessent tool to wait with no time limit for a
license. This is the default.

MBISTArchitect™ Reference Manual, v2021.2 and Later 259

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Shell Commands
mbistarchitect

• -Insertion
A required switch that invokes the tool in the BIST Insertion Phase. You can insert a
Verilog or VHDL formatted design. The following switches are used specifically for the
BIST Insertion Phase.
-TOp name
A required switch and string pair that specifies the top-level module/entity design
name.
-LVErilog library
A required switch and string pair that loads the Verilog library file(s) for the BIST
Insertion Phase. You can load a single file or a directory of library files by specifying
the path.
-HIerarchical
A required switch that starts a hierarchical flow for BIST Insertion.
-MIXED_ANSI_PORTS
An optional switch that enables the mixing of ANSI-style and non-ANSI-style
declarations.
• -GAte-level_verification
A required switch that invokes the tool in the Gate-level Verification phase. The following
switches are used specifically for the Gate-Level Verification phase.
-TOp name
An optional switch and string pair that specifies the top-level module/entity design
name.
-LIB ATPG_library
An optional switch and string pair that loads the ATPG library file that contains the
memory models you want to use during the Verification phase. You can also load a
library file after invocation using the Load Library command.
-SENsitive
An optional switch that specifies for the tool to consider design names, such as the
gate-level netlist, as case-sensitive. This switch may be useful if you had two design
names or netlists that were spelled identically but capitalized differently (myram
versus MyRAM). However, this naming practice is not recommended.
This switch only pertains to design names. The MBIST command names are always
case-insensitive.
-INSEnsitive
An optional switch that specifies for the tool to consider design names as
case-insensitive. This is the default.
This switch only pertains to design names. The MBIST command names are always
case-insensitive.

260 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Shell Commands
mbistarchitect

-LOAd_warnings
An optional switch that issues all warnings while loading the gate-level netlist and
library. The default is to summarize many.
• -LOgfile name
An optional switch and string pair that generates a logfile, with the specified name,
containing the session transcript.
• -Replace
An optional switch that overwrites a previously saved log file of the same name.
• -Dofile name
An optional switch and string pair that loads the specified file containing the application
commands you want to run.
• -HIStory
An optional switch that adds the commands from a dofile to the MBISTArchitect command
history list. By default, the commands executed from a dofile are not inserted into the
history list.
This switch is ignored if you do not use the -Dofile switch.
• -Help
An optional switch that displays the MBISTArchitect invocation usage line syntax with
descriptions for the available arguments.
• -Usage
An optional switch that displays only the MBISTArchitect invocation usage line syntax.
• -MANual
An optional switch that opens the documentation InfoHub.
• -VERSion
An optional switch that displays the version number of the tool.
Examples
The following example invokes the tool in the BISTGEN phase (BIST generation):

mbistarchitect -bistgen

To invoke the tool in the BIST Insertion Phase and load an example file named chip.v, use the
following:

mbistarchitect chip.v -insertion...

To invoke the tool in the hierarchical flow of the BIST Insertion Phase, and load an example file
named chip.v, use the following:

mbistarchitect chip.v -insertion -hierarchical...

MBISTArchitect™ Reference Manual, v2021.2 and Later 261

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Shell Commands
mbistarchitect

262 MBISTArchitect™ Reference Manual, v2021.2 and Later

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Index

BSDArchitect, 168
Index

—A—
Access file —C—
saving, 153 Cell calculation
Add new port command, 50 observe, 194
addr data item, 36 Clock gating
addr_reg data item, 36 setting, 169
Algorithm steps Clock period
reporting, 113 setting up, 212
Algorithms Commands
adding, 41 add bisa hardware, 21
deleting, 71 add concurrent group, 25
loading, 104 add data backgrounds, 33
online algorithm selection, 209 add diagnostic monitor, 35
reporting, 111 add memory models, 45
setting up algorithm selection, 209 add new controller, 48
Alias command, 69 add new port, 50
Application add pattern translation, 51
exiting, 97 add pin mapping, 54
Associating memory input signals, 194 add pin sharing, 57
add vhdl library, 67
—B— alias, 69
Background test patterns, 33 delete algorithms, 71
BISA delete bisa hardware, 72
repair strategy, 21 delete clocks, 73
BISA hardware delete concurrent group, 74
adding, 21 delete control background, 75
deleting, 72 delete controllers description, 79
reporting, 115 delete diagnostic monitor, 81
BIST delete memory models, 84
compressor architecture, 228 delete new port, 85
saving, 154 delete pattern translation, 87
BIST controllers for multiple memories, 46 delete pin sharing, 90
BIST insertion delete signal synchronization, 91
setting, 167 delete verilog include, 92
BIST logic delete vhdl library, 93
inserting, 101 echo, 96
Blackbox switch, 160 exit, 97
Block description getting help on, 98
writing, 253 help, 98

MBISTArchitect™ Reference Manual, v2021.2 and Later 263

 history, 99 set controller delay, 178
insert BIST logic, 101 set controller hold, 180
load algorithms, 104 set design name, 181
load design objects, 106 set dofile abort, 184
load library, 108 set drc handling, 185
mbistarchitect, 257 set message handling, 187
printenv, 110 set scan logic, 191
report algorithm steps, 113 set system mode, 207
report bisa hardware, 115 set vhdl configurations, 208
report clocks, 116 setup algorithm selection, 209
report concurrent groups, 117 setup clock period, 212
report control background, 118 setup comparator failflag, 213
report control logic, 120 setup controller clock, 215
report controllers, 121 setup controller reset, 216
report controllers description, 122 setup design sharing, 217
report data backgrounds, 122 setup diagnostic clock, 220
report design name, 124 setup file naming, 221
report diagnostic monitor, 125 setup full_speed, 224
report drc rules, 127 setup mbist algorithms, 225
report environment, 129 setup mbist compressor, 227
report mbist algorithms, 132 setup memory access, 231
report memory instances, 132 setup memory clock, 233
report memory models, 134 setup memory test, 236
report new port, 137 setup observation scheme, 241
report pattern translation, 138 setup pipeline registers, 244
report pin mapping, 139 setup reset duration, 248
report pin name, 142 setup retention cycles, 251
report pin sharing, 142 system, 252
report pipeline registers, 143 write block description, 253
report variables, 145 Comparator failflag
report verilog include, 147 setting up, 213
report version data, 149 Comparator test
report vhdl settings, 149 setting, 171
run, 152 Compare_result, 244
save access file, 153 Compressor
save bist, 154 architecture, 228
save design, 159 inputs, 228
save driver files, 161 outputs, 228
save history, 164 setting up, 227
save patterns, 165 Concurrent groups
set bist insertion, 167 adding, 25
set bsdarchitect, 168 deleting, 74
set clock gating, 169 reporting, 117
set comparator test, 171 with the Delete Pattern translation
set controller debug, 173 command, 87

264 MBISTArchitect™ Reference Manual, v2021.2 and Later

Concurrent testing reporting, 124
diagnostic monitor, 36 setting, 181
Control background Design objects
deleting, 75 loading, 106
reporting, 118 Diagnostic clock
Control logic setting up, 220
reporting, 120 Diagnostic monitor
Control signal, for controlling memory, 30 adding, 35
Controller clocks concurrent testing, 36
setting up, 215 deleting, 81
Controller debug order of RAMs scanned out, 36
setting, 173 reporting, 125
Controller delay sequential testing, 36
setting, 178 Diagnostics restart, 174
Controller hold Dofile, 12, 94
setting, 180 Dofile abort
Controller reset setting, 184
setting up, 216 Dofile examples, 146
Controllers dout data item, 35
reporting, 121 DRC handling
Controllers description setting, 185
deleting, 79 DRC rules
reporting, 122 reporting, 127
Driver files
—D— saving, 161
Data backgrounds, 33
adding, 33 —E—
reporting, 122 Echo command, 96
Data item Environment
addr, 36 printing with printenv, 110
addr_reg, 36 Escaped identifier
dout, 35 use of, 41, 50
failmap, 36 Exiting the application, 97
memnum, 37
port_isol_addr_reg_write, 37 —F—
portnum, 37 failmap data item, 36
rw_state, 36 File naming
test_addr_shift, 37 setting up, 221
tstate, 36 Full_speed
Deglitching registers, 61 setting up, 224
Delete BISA hardware command, 72 —H—
Delete clocks command, 73 Help command
Delete new port command, 85 finding command information, 98
Design History
saving, 159 saving, 164
Design name

MBISTArchitect™ Reference Manual, v2021.2 and Later 265

History command, 99 setting up, 236
Message handling
—I— setting, 187
Input signals MISR, 238
associating memory inputs, 194 precomputing the signature, 227
Invoking MBISTArchitect, 257 size, 239
—L— tap, 239
Library MISR polynomial
loading, 108 reporting, 136
Load algorithms command, 104 MISR signature
Load library command, 108 for ROM type memories, 227
Logic precomputing, 227
testing on the output side, 194 Multiple-input shift register, 238
Multiple-input signature register, 238
—M—
MBIST algorithms —N—
adding, 41 New controller
deleting, 82 adding, 48
reporting, 131 —O—
MBIST compressor Observation scheme
setting up, 227 setting up, 241
MBISTArchitect Observe cells, 194
compressor architecture, 228 calculation, 194
exiting, 97 default rule, 194
running, 257 Order of RAMs scanned out
memnum data item, 37 diagnostic monitor, 36
Memories that generate Z output, 194 Output_block, 244
Memory access
setting up, 231 —P—
Memory blocks Pattern translation
sharing, 217 adding, 51
Memory clock deleting, 87
setting up, 233 reporting, 138
Memory collars Patterns
sharing, 217 saving, 165
Memory input signals Pin mapping
associating, 194 adding, 54
Memory instances reporting, 139
reporting, 132 Pin name
Memory models reporting, 142
adding, 45 Pin sharing
deleting, 84 adding, 57
reporting, 134 deleting, 90
Memory test reporting, 142
performing sequential tests, 237 Pipeline registers

266 MBISTArchitect™ Reference Manual, v2021.2 and Later

 reporting, 143 Scan Logic
setting up, 244 setting, 191
port_isol_addr_reg_write data item, 37 Sequential memory tests
portnum data item, 37 performing, 237
Printenv, 110 Sequential testing
Printing out the environment, 110 diagnostic monitor, 36
Set scan logic command, 191
—Q— Setup algorithm selection, 209
Quitting the application, 97 Setup design sharing command, 217
—R— specparam format, 217
RAM control signal, 30 Setup mbist algorithms command, 225
Repair strategy Setup mbist compressor command, 227
using BISA, 21 Setup MISR Polynomial
Report example, 241
report algorithm steps command, 113 Sharing memory blocks, 217
report algorithms command, 111 Shell commands
report BISA hardware command, 115 mbistarchitect, 257
report clocks command, 116 Signal synchronization
report data backgrounds command, 122 adding, 61
report diagnostic monitor command, 125 deleting, 91
report MBIST algorithms command, 131 reporting, 144
report memory models command, 134 Signature comparison testing, 45
report MISR polynomial command, 136 Signature data
report new port command, 137 MISR, 238
report pipeline registers, 143 Slow_tester_clk, 220
report signal synchronization command, Specparam format
144 setup design sharing command, 217
report variables command, 145 System command, 252
Reporting version data, 149 System mode
Reset duration setting, 207
setting up, 248 —T—
Reset state command, 150 Test patterns
Restart background, 33
diagnostic, 174 test_addr_shift data item, 37
Retention cycles Testing
setting up, 251 logic on the output side, 194
ROM memories Testing logic on the output side, 194
MISR signature, 227 tstate data item, 36
Rounding down problems
avoiding, 197 —U—
Running MBISTArchitect, 257 User-defined variables, 12
rw_state data item, 36 reporting, 145
user-defined variables, 12
—S—
Save BIST command, 154

MBISTArchitect™ Reference Manual, v2021.2 and Later 267

—V—
Variables
user-defined, 12
Verilog include
deleting, 92
reporting, 147
Version data
reporting, 149
VHDL configurations
setting, 208
VHDL library
adding, 67
deleting, 93
VHDL settings
reporting, 149
—Z—
Z output
memories that generate it, 194

268 MBISTArchitect™ Reference Manual, v2021.2 and Later

 Third-Party Information
Details on open source and third-party software that may be included with this product are available in the
<your_software_installation_location>/legal directory.

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.